Our New Blog Series: Your AWS Account From Scratch
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:
- 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.
- A hardware key from a few selected third-party providers, e.g. as a USB device or card.
- 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.
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.
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.
Password policies can be set for IAM users using either the GUI, or CLI, or even API. All three procedures with steps can be found here.
Must-Have 4: RBAC And ABAC
A 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.
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.
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 may be 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.
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.
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. Feel free to look into this blog for updates or follow us on social networks where we will be announcing new articles.
This blog is part of our Your AWS Account From Scratch blog series.