Many recent high-profile data breaches have resulted from misconfigured AWS Identity and Access Management (IAM) permissions. While AWS is very secure when configured correctly, it is trivial to make a mistake in your configuration that exposes significant data and software systems. It is estimated that some 73% of companies have critical AWS misconfigurations.
This article outlines four basic concepts to configure and manage your AWS IAM to prevent your organization from becoming part of the 73%.
AWS CONFIGURATION SECURITY: IDENTITY ACCESS MANAGEMENT
Amazon Web Services (AWS) Identity and Access Management (IAM) is a web service which allows users to assign granular AWS permissions to people and applications. If you’re not familiar with identity already, I would highly recommend that you watch the video Identity in Ten Hundred Words. In this video, Sarah Squire of Engage Identity, defines identity concepts using only the one thousand most used words in the English language.
1 – SECURE YOUR ROOT KEY (AND DON’T USE IT)
The most common AWS security vulnerability also has the greatest impact to your AWS environment. If an attacker gains access to your root key, they will have access to everything within your AWS, including billing.
Except for a minimal number of exceptions, such as changing billing and other critical tasks, you do not need to use your root key on a regular basis. Print it out and put it in a safe or safety deposit box.
If you must store it digitally, encrypt it and store it on a device that is not connected to a network such as a thumb drive. Do not store the decryption key on the same device and be sure to rotate the root key regularly in case it has become unknowingly compromised.
Similarly, don’t use your AWS Root account for any task that doesn’t require it. Create an individual IAM user with administrative privileges to access and manage your account.
2 – HARDEN YOUR AUTHENTICATION PROCESS
HAVE A STRONG PASSWORD POLICY
The most secure way to administer passwords is to create and assign them to users directly. This will give you control over the strength of the password. You can allow your AWS users to set their passwords, but ensure the requirements are up to modern day complexity standards.
REQUIRE TWO-FACTOR AUTHENTICATION
Two-factor authentication protects your user accounts against spearphishing attacks involving credentials. You can configure your AWS account to require two-factor authentication for all users or specify for different groups.
The most secure and recommended configuration is to include all users in this requirement and to require users to rotate their passwords regularly.
3 – ONLY ASSIGN PERMISSIONS NEEDED FOR THE JOB
USE AWS DEFINED POLICIES
Whenever possible, use the predefined AWS policies to give permissions to your users. These policies are regularly updated by AWS and are one less thing for you to manage within your environment.
AVOID GRANTING USER-LEVEL PERMISSIONS
Instead of granting individual users permissions, create groups based upon role and job functions, then assign that user to the group. This will easily allow you to update a single user permission and avoid having to keep track of what a user does and does not have access.
FOLLOW THE PRACTICE OF LEAST PRIVILEGE
Only assign users to groups with permissions that the user needs to perform their job. Anything more than that is too much and is an avoidable unnecessary risk.
ASSIGN ROLES TO APPLICATIONS AND OUTSIDE USERS
Applications that need credentials to access AWS services should be given permissions through roles. Roles should be used for any entity that isn’t either a user or a group within your AWS environment. If a user from another AWS account needs access, grant permissions using Roles.
4 – CONDUCT ONGOING AWS IAM MONITORING AND REVIEW
AWS includes excellent tools to provide a visual overview of all the policies, services, and actions in your account.
Go through this checklist once a quarter to review your configuration and make sure that your account configuration isn’t out of date:
- Remove or restrict unused accounts
- Remove permissions that are no longer used due to a change in workflow or process
- Review unusual activity
- Adjust permissions that are overly broad to be more granular. For example, do all of the accountants need access to everything in the accounting office? Or are there lower-level analysts who require access to a desk, but not any safes or filing cabinets?
- Break up roles that are overly broad into multiple smaller roles
TRACK TROUBLESHOOTING AND TEST CREDENTIALS
It is common to grant additional user permissions to a user, group, or role when troubleshooting AWS IAM configurations, but not everyone remembers to revoke the permissions granted during the troubleshooting process.
Track any changes you don’t intend to be permanent so you can reverse them once the issue is resolved. The same goes for any test accounts credited for a particular purpose. Always ensure those accounts are either deleted, or permissions revoked when they are no longer needed.
SUMMARIZED AWS PERMISSION CONFIGURATIONS
To summarize and recap best practices to avoid common pitfalls with AWS IAM:
- Secure Your Root Key
- Don’t User Your Root Account (unless you must)
- Implement Two Factor Authentication for all users
- Require strong passwords and rotate them regularly
- Use AWS Defined Policies to grant permissions
- Use Groups to assign user permissions, Roles for applications or external users
- Operate under least privilege
- Conduct ongoing reviews and audits of IAM permissions
Correctly configuring AWS IAM settings requires a significant initial investment as well as ongoing maintenance. Taking these simple steps to configure your AWS IAM can help your organization avoid many vulnerabilities associated with AWS permission levels.
These basics will help you avoid the major mistakes that the 73% of companies unknowingly make.
>> Learn more about preventing common misconfigurations in the AWS S3 research post.
