[ This article was originally published here ]
Have you ever heard the saying that the greatest benefit of the cloud is that limitless resources can be spun-up with just a few clicks of the mouse? If so, you would be best served by forgetting that saying altogether. Just because cloud resources can be spun-up with a few clicks of the mouse does not mean that they should be. Rather, prior to launching anything in the cloud, careful consideration and planning are a necessity. Otherwise, your company or governmental entity might end up in the news for a security blunder that was easily avoidable.
This blog series will focus on three Amazon Web Services (AWS) security steps that any entity can employ to immediately and dramatically improve their cybersecurity preparedness. Specifically, we will discuss 1) setting up Identity and Access Management (IAM) properly, 2) avoiding direct Internet access to AWS resources, and 3) encryption for data in transit or at rest. These steps can be followed for entities that are either new to AWS or existing customers. Read on to find out if your organization is already following this easy guidance.
Step 1: Use IAM the correct way
According to AWS, IAM enables account administrators to “specify who or what can access services and resources in AWS, centrally manage fine-grained permissions, and analyze access to refine permissions across AWS.” . When entities first create an AWS account, the only user that exists is the root user. This user has the proverbial “keys to the kingdom” and can literally launch cloud environments that would rival Fortune 500 companies in a short amount of time. In turn, bills commensurate with a Fortune 500 can quickly be accrued, too. Accordingly, as we will discuss below, protecting the root account is a crucial first step.
Protect the root account
In addition to creating a sufficiently complex password, multifactor authentication (MFA) must be enabled. MFA is achieved by using a third-party authentication mechanism. Since usernames and passwords are stolen with alarming frequency, incorporating login credentials with MFA makes it much more difficult to compromise an account. This is because the malicious user would need to know a user’s login name, password, and possess the user’s third-party authentication mechanism. As long as the latter is securely protected, account compromise is nearly impossible (Note: sessions authenticated with MFA can still be compromised via cross-site scripting (XSS) attacks. As we will learn later, AWS offers a defense against XSS).
AWS supports the following MFA mechanisms: Virtual MFA devices (e.g., Google Authenticator, Twilio Authy, etc.); FIDO security key (i.e., a USB device); and Hardware MFA device (i.e., a physical device that generates random numbers). . Conveniently, Virtual MFA can literally be setup in minutes and has no cost associated with it.
Additionally, if the AWS root account was created with programmatic access keys, they should be deleted immediately. Even with MFA in place, if these keys fall into the wrong hands, they can be used to launch everything and anything. These keys are akin to “God mode.” Something as simple as accidentally posting the keys on a repo like GitHub is all an attacker would need to take over an account. Hence, it is necessary to delete them and follow the principle of least privilege by divvying up permissions to IAM users, groups, and roles instead. Let’s discuss how to securely create each of these IAM principals now.
Create IAM users
If all AWS users shared the same login credentials, accountability for individual actions would not be possible. For example, if ten people have access to the root login account and the account was used to provision Bitcoin mining instances, it would be impossible to determine the culprit.
Conveniently, AWS provides entities with the ability to provision individual user accounts via the AWS console (users can also be created in the AWS CLI and AWS API). For each user created, AWS lets you specify what the user is authorized to do with AWS resources on a granular level. For instance, if a user in the marketing department needs read only access to a specific folder within an S3 bucket, an IAM policy can created to enable this functionality. By following the principle of least privilege, the user only gets access to what they need to perform their job. By limiting what a user can do within AWS, it has the effect of reducing the blast radius of the damage that can be caused by a compromised account or disgruntled employee.
Luckily, AWS has done a lot of the heavy lifting and has already created IAM policies that are unique to job duties. Account administrators merely need to associate users with the policies that align with their role. If customization of a policy is required, AWS provides tools that make this process relatively simple as well. To learn more about creating IAM users, click here: .
However, for business with hundreds or thousands of IAM users, manually associating policies with each user is not feasible. Especially if job duties frequently change. Thankfully, AWS has addressed this problem with IAM groups.
Create IAM groups
If employees perform the exact same job duties and need access to the same AWS resources, they should be placed in an IAM Group. The IAM group has a policy (or policies) associated with it that provides access to specific AWS resources. Therefore, every IAM user associated with the IAM group has access to the same resources and they are also bound by the same constraints. Moreover, changes to the policy associated with the group are implemented with immediate effect. Hence, IAM groups make end user management convenient and efficient. To learn more about creating IAM groups, click here: .
At this point, you may be wondering how AWS resources like EC2 instances can securely access other AWS resources, or how entities with active directory (AD) can avoid the creation of duplicate AWS user accounts? The answer to these questions is IAM roles.
Create IAM roles
AWS resources like EC2 instances or Lambda functions can assume an IAM role with predetermined permissions to access, create, update, or terminate other AWS resources. Likewise, users federated with a Web Identity Provider (e.g., Facebook, Google, etc.), corporate Active Directory, or another AWS account can assume an IAM role with the same functionality. Like IAM policies associated with users and groups, an IAM role affords the same level of granular control regarding what an AWS resource or federated user can and cannot do.
Thus, for AWS resources assuming a role, the security implications associated with hardcoding an IAM user’s credentials in an application can be avoided. Furthermore, entities with AD or other Web Identity Providers will not require their users to create separate AWS login credentials. To learn more about IAM roles, click here: .
Now that you know the basics and most important aspects of AWS IAM (in this author’s opinion), the next blog in the series will move on to the next step associated with securing your AWS account – limiting direct Internet access to your resources.
Ad