Best Practices For a Secure Cloud Part 1

Whether you’re running on premise datacenter, using a private or public IaaS (Infrastructure as a Service) hosting platform, security is extremely important. We’ve all seen the horror stories in the news when companies experience data security breaches. The fact of the matter is no one wants to end up in this position and there are tons of bad actors on the internet that have malicious intent.
Cyber attacks have become more and more prevalent over the past few years, whether this be in the form of the more traditional trojan horses and phishing, or through man in the middle exploits (see the numerous OpenSSL vulnerabilities (HeartBleed, POODLE, etc), to distributed denial of service attacks (dDOS), cross site scripting, SQL injection, and ransomware (cryptolocker). The unfortunate juxtaposition of this is that those perpetrating cyber attacks have little to lose and don’t have much at stake. On the other side of this organizations have limited budgets, tight deadlines to meet, and increasing demand to deliver newer, better, and faster services with higher expectations regarding disaster recovery and high availability. While this blog post is not intended to make your infrastructure an impenetrable fortress that keeps all the bad guys out, because despite best efforts it's impossible to protect against everything, this is intended to lay down some best practices surrounding security in a cloud environment.

Some of the topics we’ll go over in this post may be old news to those of you who are already security conscious and some of them may even seem like common sense, but it can be surprising how often the simple things are ignored or assumed leading to unnecessary vulnerabilities. The primary focus of this blog post will be on Amazon AWS environments, however the same concepts apply to other IaaS platforms and on premise datacenters. The biggest thing I want to emphasize before we jump in is that taking the time to plan and architect a secure and well designed private cloud will go a long ways to preventing future issues. Even if you’ve already built your cloud environment some of these items can be implemented without massive retooling, others may require parallel build and migrate actions. This will be a multi-part series as there is simply too much information to cover in one post.

Securing Account Access with IAM

While this is written with a focus on AWS IAM, these same concepts can be applied to on premise architecture. From the Amazon AWS perspective before you build your first EC2 instance, create your first S3 bucket, or use any other AWS service you must create an account (or log into an existing one). The first thing you should do with a new account is to create an IAM (Identity and Access Management) account for your administrator user, setup multi-factor authentication, then disable access to the root account. The problem with the root account is that it’s all powerful, is a single point of vulnerability, and organizations who share the root credentials among their ops teams lose the ability to track who was logged in as the root user when actions (creating, modifying, or deleting) on your AWS resources.

A well defined IAM architectures allows you to accomplish a plethora of security best practices, notably use of RBAC (role based access control), least privilege user accounts, AAA (Authentication, Authorization, and Accounting), and Mutli-Factor authentication. While this can all seem like a giant overwhelming storm of acronyms and concepts I’ll take the time to delve into this a chunk at a time.

Role Based Access Control (RBAC)

Role Based Access Control  is a security concept that’s been around a long time and can be seen within LDAP and Active Directory environments and many other places. Essentially in IAM you can create groups such as Developers, DevOps, Management, Accounting, etc. Within these roles you can assign permissions, for example your DevOps or SysOps team will generally need the ability to create AWS resources but perhaps you don’t want them to have the ability to manage IAM permissions for other users, maybe you only want managers to be able to make these changes. Or in another scenario, your accounting and finance teams need to be able to access AWS billing and view AWS resources but not be able to create, modify, or terminate any of these resources. IAM allows you to use fine grained permission schemes with groups and individuals. One of the biggest mistakes I see made with IAM is when permissions are assigned on a per user basis. This may work well when your organization is small, but this doesn’t scale well and can lead to mismatched permission levels or worse yet too many permissions being assigned to someone. With groups you can simply add users to a group and the user will inherit those permissions. Users can be members of multiple groups and permissions are aggregate unless there are explicit deny permissions, then the explicit deny will override any aggregated allows. By default anything not explicitly allowed is implicitly denied.

RBAC dovetails nicely with the concept of least privilege user accounts. Least privilege essentially boils down to giving users the minimum permission levels needed to accomplish their job functions. One of the handy things about the fine grained permissions in Amazon’s IAM is that you can grant temporary permissions at a fine grained resource level. For example you have an intern that’s working with your team that doesn’t have the ability to create new load balancers and you’ve given them a project that involves creating 5 new load balancers or modifying an existing one. You can confidently grant them the permissions do this without granting the permissions to terminate anything.

AAA (authentication, authorization, and accounting) like RBAC is a longstanding concept in IT. Breaking this down into its individual bits we have the following:

• Authentication: Authentication is derived for authentic, it’s essentially a way to validate you are who you say you are. With the prevalence of phishing, brute forcing logins, etc this has become much more complicated than simply requiring a username and password. With IAM you can require multi-factor authentication (MFA) which requires use of a secondary device such as a hardware MFA device or an app like Duo or Google Authenticator which generates a random code that changes every 30 to 60 seconds depending MFA device. This way if the username and password are compromised there is a second line of defence to ensure you in fact are who you say you are. In addition to making MFA a requirement it’s also a good idea to setup your password complexity requirements and password rotation policies. This includes determining minimum password length, whether or not to require numbers, uppercase letters, and special characters. Additionally you can choose how often passwords have to be changed or rotated, and how many previous passwords are stored and cannot be reused for that period of time The big caution with this is to make sure that you are balancing secure passwords with passwords that are memorable. If you make your password requirements so strong that no one can possibly remember their password they will resort to doing horribly insecure things (yes i’ve seen passwords on sticky notes attached to monitors (not at Metal Toad but elsewhere). There are several good secure password vaults on the market, and most have a random password generator which can help to make strong passwords and prevent people from doing insecure things.

• Authorization: Great so we can log in, now what? Authorization refers to the level of access that you’ve been granted. By default when you create a new IAM user they have no authorization to do anything, they can only login. Authorization is granted as part of the individual account or group policies discussed earlier in the RBAC section. This can also be quite important in protecting you from yourself. What do I mean by that? There’s this lovely handy little AWS Android and iOS app that allows you manage your EC2 instances (which can be handy if you need to reboot a server that’s not accessible on the go), however the terminate button is dangerously close to the restart button. By using our concept of authorization you can make a mobile admins group that is restricted from the ability to terminate instances and make sure that your normal admin group is prevented from logging in with mobile.

• Accounting: For organizations that have to comply with certain regulatory requirements (typically government, health care, or financial institutions), the ability to track who did what and when is extremely important. Amazon has their CloudTrail service which will automatically log when a user logged in, and what actions were taken, allowing for painless record collection and reporting.

One of the awesome things with AWS IAM is that you can use single sign-on with SAML providers. If your organization uses Active Directory as its central point of authentication for all the things in your environment, you can setup Active Directory Federation Services (ADFS) and deploy federation with IAM as a SAML provider. This means the user will authenticate against Active Directory and be signed onto AWS via SAML authentication through AWS.

The final point I will make before we wrap up this session on from the Securing Account Access section is that you can apply IAM access to more than just users. You can also create IAM roles for EC2 instances. You may be asking yourself why this matters. The answer is quite simple, if you need to use AWS API keys it’s not recommended to store these within the instance. You technically can, however if you utilize that same API key in multiple places the chance of it becoming compromised are greater. By launching an instance with an IAM role is that the permissions get associated with the EC2 instances without having to store the API keys on the machine itself. The caveat here is that IAM roles can only be attached to an instance at the time of instance creation and you cannot retroactively apply these roles to existing instances. What you can do however is to clone the instance and re-launch it with the desired EC2 role.