7 Must-Haves For Ultimate AWS Security

In our new series, we help you to set up an AWS account from scratch. Read this article to learn the seven must-haves of AWS security.

AWS makes our life easier in many ways. But, as it often happens, in an attempt to address all possible needs, it ended up with just too many features to keep an eye on. Newbies or small teams that cannot have a dedicated AWS admin, may get lost or spend too much time managing and configuring it.

In our new series, we want to help everyone in setting up an AWS account completely from scratch.
We will be sending you to the AWS docs quite often. Our goal for writing this blog series is to have all useful links for you in one place and to point you to the facts that may have skipped your attention before.

We start with security.

AWS Security Must-Haves

Following general and AWS-based security best standards, we will walk you through the following settings:

• Creating an IAM user.

• Multi-factor-authentication (MFA).

• Secure password policy.

• Role-based access control (RBAC) or attribute-based access control (ABAC).

• Safe browsing of AWS instances with read-only access.

• Monitoring the activity in your AWS account with logs.

• Data backup.

Before we start, you may want to get the AWS CLI console. It can be used to manage certain things and code junkies will love it as an alternative to the GUI.

You can find the one suitable for your operating system here. Download and install it like any other app.

Must-Have 1: Create an IAM User

Creating an AWS account is pretty easy. It only requires you to sign up and add an Identity and Access Management (IAM) user. Theoretically, the latter remains optional, but we highly recommend it – as AWS also does – for security reasons that are explained in the AWS docs together with the two steps for account creation. Besides, it is an essential prerequisite for some of the security measures that we propose later in this article. 

You can save the IAM link somewhere in your browser, e.g. add it to the bookmarks pane. This comes in handy for logging into your AWS account quickly.

Now, we are ready to deal with your AWS account security.

Must-Have 2: Activate and Enforce 2FA

Purpose and Options

An activated MFA makes your users use one more authentication method in addition to entering their AWS/IAM credentials. AWS offers you to select between the following:

<!--[if !supportLists]-->1.     <!--[endif]-->Software that generates a time-based one-time password (TOTP). It can be installed on your smartphone, tablet, or even PC/Mac. The most popular authenticators, such as Google, are included.

<!--[if !supportLists]-->2.     <!--[endif]-->A hardware key from a few selected third-party providers, e.g. as a USB device or card.

<!--[if !supportLists]-->3.     <!--[endif]-->Other hardware MFA devices.

Obviously, the two last methods mean additional costs. Besides, you need to make sure that the main user device is compatible with the hardware key.

Enforcing MFA

In AWS, you cannot set the MFA method for other users. They can only do it by themselves. But you can force them to add an MFA device.

The steps are explained in this article. Once you configure the MFA policy, users cannot perform the majority of actions before they activate MFA.

Activating MFA

Every user activates and manages their MFA devices from the IAM console, accessible with the link you saved before. The steps can be found here. 

MFA can be used for root users, too. To do so, you need to log in to your root user account.

Must-Have 3: Create a Robust Password Policy

We lean on the password guidelines provided by the [American] National Institute of Standards and Technology (NIST), also known as NIST Special Publication 800-63B.

NIST proposes two main goals for your password policy that are relevant for AWS security:

• Motivate users to create unique passwords by making password creation easier.

• Do not force their creativity too often.

The implementation of these goals lies in your hands.

Smooth User Experience For Better Passwords

In a nutshell, NIST suggests that you depart from the complex passwords and arrive at long, but human-looking ones. For instance, "monkeys-draw-silver-cars" is better than "!k§jd". It is easier for users to memorize which means that they won’t be reusing passwords for different accounts. When a password is leaked, only one system is affected. 

No Password Expiration

The necessity to reset passwords too often leads to password re-use or passwords that are created using certain patterns, such as a concatenation of the name and year of birth, that can be easily cracked by hackers. 

However, we recommend forcing users to change their passwords on their first login.

How-To

Password policies can be set for IAM users using either the GUI, CLI, or even API. All three procedures with steps can be found here.

Must-Have 4: RBAC And ABAC

Granular access control is an important security prerequisite. Only if you know who can do what and where you can (hope to) avoid data leaks.

RBAC vs ABAC

On one side, the AWS permission concept is service-centered. You grant or restrict access to certain services.

On the other hand, AWS also offers the ABAC model that is instance-centered and allows you to give access rights only to certain instances across all services or within only one service.

Rights and restrictions are then “aggregated” into policies that can be further “aggregated” and assigned to a role one-by-one or in a combination. The roles are then assigned to users or groups of users.

Indeed, the biggest power of those models lies in their synergy. 

Before Implementation

Both RBAC and ABAC model implementation starts with a security matrix. 

A security matrix divides all users into a few groups where each group has a certain range of access rights. On one end of the spectrum is the admin that can do pretty much everything, and on the other end usually is a read-only user. In-between, you can place users that can access only certain resources or only in a certain manner (read or write them).

The matrix needs to have at least two dimensions: services and instances.

Least Privilege Rule

How do you decide which permission rights to grant?

We recommend sticking to the least privilege rule: Do not grant permissions as long as there is no explicit need for them. In other words, do not grant any permissions “just in case”. Remember that it all has nothing to do with your personal trust in a colleague of yours. It’s about the danger of any of your colleagues being hacked and their AWS credentials landing in the wrong hands. The fewer access rights your team members have, the lower is the chance the hackers have for success!

Prerequisite For Using The ABAC Model

Before you can use this model on one of the implementation steps, you need to tag your AWS instances. See more in the AWS documentation on using tags. 

How-To

See our forthcoming tutorial on implementing RBAC/ABAC.

Must-Have 5: Read-Only Access For Safe Browsing

In addition to restricting some users to only read access, those who can change any resources may want to stick to this safety measure: browsing with read-only access. By doing this, you reduce human errors that can always happen when someone has to work under pressure or maybe new to the team or be less experienced in general.

AWS allows users to switch IAM roles and gain/lose permissions, depending on the assumed role. As long as the user is not intended to change anything in the AWS instance, it is safe to move within it assuming a restricted role.

You need to create a user group and attach to it a predefined policy. Add users to this group and enable them to switch their roles. 

The switch can happen while working with the GUI, CLI, and API. The instructions can be found here. 

Must-Have 6: Get Activity Logs

In many cases, data breaches happen because a malicious agent got in possession of AWS account credentials. Therefore, it is important to monitor AWS user activities. The best practice would be to do it programmatically to be able to detect suspicious patterns. However, the first step is to start generating logs for every user and any kind of access, be it via GUI, CLI, SDK, or API.

AWS even offers a native service for this, called CloudTrail. The actual logs can be stored in S3. 

Must-Have 7: Data Backups

Regardless of the reason that caused a data breach, not only does your data get exposed but it can also be lost. 

AWS backup is possible for any AWS-native service and a few selected third-party services, EC2 and S3 included. You can find features and tutorials here.

Conclusion

We hope to have shed some light on the AWS security must-haves.

As you can see, a complete account security configuration requires quite an effort on your side. We are currently working on a few tutorials that will help you to implement these must-haves in your AWS instance. 

Relevant Blogs:

How to Choose the Best Encryption Methods for Databases 

5-Step Cyber Threat Hunting Process 

Data Breach: A 5-Step Response Plan 

Why You Need Both IT and OT Cybersecurity