AWS Security – Account Protection

Security is often one of the first discussions to be had when talking about cloud computing and migrations, however it is something that can very easily be poorly implemented and understood. It is present among all areas of cloud applications from the server and network level all the way up to user access and permissions. This article will be most useful to people who are new to AWS and want to ensure they are being security conscious while using the platform.

When security is missed at any stage of a projects lifecycle it can pose huge risks, from data leaks to full-scale unauthorised access to an account or system. This blog article will be discussing some of the most simple security measures that every person and organisation can and should be implementing on every AWS account. The steps detailed in this article are easy to implement yet yield some of the greatest security benefits when it comes to securing your accounts.

This is the first in a two-part blog series, in part one we will discuss the security of your AWS account. The AWS account is the key access point to all of your infrastructure and data that runs inside it, so protecting it is a top priority!

Protect the Root User

The root user is the account you are provided with when creating and AWS account, it holds access to every action within the AWS account and cannot be limited in any way.

The standard recommended approach to securing the root user account is to set it up with a complex password (ideally 11+ random characters with a mix of upper and lower case, numbers & symbols). This formula will prevent common forms of password cracking and brute forcing from guessing it correctly.

Once you have setup your strong password on the root user, you next should look at creating a delegate IAM user with full administrative permissions that you can use to manage your account from. They key with this is that if the IAM user gets compromised, the root user can remove access, change the password or delete the IAM user, the same cannot be said if it were the opposite.

It is then recommended that the root user gets MFA enabled (discussed below) with an MFA device and is then no longer used unless absolutely needed, as almost every other action can be taken by your newly created delegate IAM user.

What if I have nothing important on my account? Well, keeping the root user secure should still be of upmost importance as even if you have no sensitive data and apps running, your AWS account is still a target. Oftentimes when people gain unwanted access to an account they may not be trying to steal your data, but instead use your AWS account to create their own resources which you will then have to pay for. A common occurrence is for people to gain access to an account and create lots of high powered EC2 instances to mine crypto currency and keep the profits, while you’re stuck footing the bill – wishing you’d secured your root user.

If you do suffer any unwanted access to your account and or see resources running that you didn’t create you’re first action should always be to contact AWS support and make them aware of the situation, they will then be able to advise you on next steps.

Multi-factor Authentication (MFA)

Multi Factor Authentication is the process of setting up a secondary authentication method on your accounts alongside your password. Microsoft has stated that MFA can block over 99.9% of account compromise attacks – if that doesn’t show you that MFA is a must-have then I’m not sure what will!

MFA can be either a physical device that you plug into your computer to authenticate such as a YubiKey, or a virtual one like the Google Authenticator app. Both are valid options, however for high profile accounts like an AWS Root user a hardware device would be preferred.

One easy way to make sure all of your IAM users have MFA enabled is to add a simple permissions policy to deny the user all permissions unless MFA is enabled. Other access that is given will remain attached to the user, but will not be usable until they have setup MFA. In the below policies section there will be a short code snippet that can be added to any policy or set as a standalone to prevent actions unless MFA is enabled.

Policies

Policies are a set of rules attached to a user or resource that set out what actions the user can or cannot take and work similar to most other user permissions systems such as SharePoint, Active Directory or any other of your corporate applications.

A permissions model that AWS recommends it’s users to follow is principal of least privilege. This model aims to only give users the permissions that they need to do their job and nothing more. It reduces your liability either by accident or with intention. Users cannot accidentally see data in an S3 bucket they were not meant to for example, and if their account gets compromised the attacker will only have a limited scope of access to cause damage. AWS also recommends that you frequently evaluate users permissions to determine if they are still needed, and if not – remove them!

AWS has a handy tool called the IAM Access Analyzer that helps you determine if users have any unused permissions based on their usage patterns within AWS. Setting a periodic review of these results can keep you on track with the least privilege model.

Policies are evaluated in a specific way with explicit denies being read and executed first, meaning that if a user has allow permissions for a service but also a deny permission they will not be able to access the service even though they have an allow.

One way to combine two of the points talked about in this article is to have a policy set on all users that denies access to all actions on AWS unless MFA is enabled, and as we now know, an explicit deny policy will always win over any granted permissions from other policies. An easy way to implement this is to create a group that all users will be added to which contains the below policy statement, stopping users from taking any actions unless MFA is enabled. The below code snippet shows a policy statement that will not allow the user to take any actions except adding MFA to their account until MFA has been enabled, it can be run as a standalone policy (with some alterations) or added to an already pre-existing one.

Conclusion

In this blog we discussed three important security practices for any AWS account. Firstly avoiding using the root user account as much as possible and securing it with a strong password and MFA as this is the highest level account in your AWS environment. Secondly the importance of MFA and why it should be implemented on all users, and finally IAM Policies and the principal of least privilege permissions model to tighten down any access your users do have.

This was an insight into some of the security practices that everyone should be following no matter what size your company or account is. In the next part of this blog series we will discuss some of the important resource protection security practices including securing your S3 buckets and avoiding the use of the default VPC.