If you have an Amazon Web Services (AWS) presence in your organization, hopefully you are at least a little familiar with Identity and Access Management (IAM). This blog post will aim to familiarize you with some core IAM concepts, as well as some things you can do to align your organization with best practices.
Identity and Access Management is a system of security controls which define access policies for users and other entities. In AWS, IAM allows organizations to control access to AWS resources. Here are a few key terms any team using AWS should be familiar with:
- Permissions – specifications of access to AWS resources. Can be granted to IAM entities such as users, groups, and roles.
- Policy – A set of permissions. AWS has many pre-built policies for a variety of use cases, and you can also create your own custom policies.
- User – an IAM User is an entity with individual security credentials. A person can use their IAM User credentials to access AWS resources via the AWS Console or the AWS CLI.
- Group – A collection of IAM users. Permissions applied at the group level affect each user in the group.
- Role – An IAM identity not associated with a specific person. IAM Roles use keys that are valid for short durations, and can be assumed by IAM Users, AWS Services, Application Code, or federated users.
- Account – an account with Amazon Web Services.
- Root User – Credentials (email and password) used to create the AWS account.
Now that we have some vocab under our belt, we’ll cover 10 things you can do to improve your IAM security. Many of these items are adapted from AWS’s CIS Foundations Benchmark, and can also be found in both the AWS Config and AWS Security Hub dashboards, where recommendations for logging, monitoring, and networking security are also detailed.
- DO NOT use the Root User as your primary form of access to AWS resources.
Instead, you should access AWS with IAM user credentials. See more about creating IAM users here. If your primary reason for using your Root User is to access billing data, you can grant billing access to IAM Users. You should go ahead and store the Root User creds in a top secret location and only access them when you need to do one of these things (which will not be on a daily basis). If you created access keys for your root user, you should remove them.
- Enable Multi-Factor Authentication (MFA) for the Root user and all IAM users.
MFA is always a good idea, as it limits AWS access to users who have physical possession of an authorized MFA device. Here’s a guide for setting up MFA.
- Set password length requirements.
The CIS AWS Foundations benchmark disagrees with me on this, but I’ll say it anyway. Forcing your users to add numbers, uppercase, and symbol characters does not significantly increase password security, it’s length that creates greater password entropy, and therefore greater security. Don’t believe me? Here are a few other resources about password entropy. You can absolutely require numbers and symbols, but you ought to at least create a password policy with a minimum password length of 14 characters or greater.
- Rotate your IAM access keys regularly (AWS recommends every 90 days).
You can do this via the AWS console or AWS CLI. At 1Strategy, we use this slick tool to automate IAM key rotation.
- Terminate unused credentials.
As much of a hassle as it is, it’s absolutely crucial that you clean up IAM users and access keys often. The best recommendation I can give here is to add this to the list of “what we do when someone leaves the company.”
- Don’t give everyone administrative access.
I know you know not to do this, but we often do it against our better judgement because we trust our users, we are doing it only temporarily…but then ‘temporarily’ becomes permanently. This can be mitigated by following tips seven and eight.
- Attach permissions to IAM groups, rather than directly to users.
Picture this: you’re new to AWS. You create a handful of users for your team, and—trying to do the right thing—attach a fairly restrictive policy to your users. Sally is working hard to develop something, and needs permission X, so you attach it for her. Bob needs permission Y, so you attach it to his IAM user. Months go by and your IAM users grow, and you realize you have no idea which permissions each user has. Then one day, Joe accidentally skyrockets your AWS bill by doing something he shouldn’t have been able to do in the first place.
If this sounds like your account, there is hope! Leverage IAM Groups that align with job functions in your organization. A group for engineers, a group for the security team, a read-only group for contractors or accounting folks. Permissions attached to a group apply to all members of that group, so users actually don’t need permissions attached directly to them at all.
- Don’t keep your production resources in the same AWS account as your development resources.
Ok I admit, if you are already established in a single AWS account, then this one might not fall into the “simple fix” category for you. A multi-account structure in AWS has many benefits, including scalability, protection of production resources, and fewer brushes with service limits. We recommend segregating production resources because the easiest way to prevent people from accidentally touching things they shouldn’t touch is by blocking access to the account altogether. Therefore, your IAM groups and policies can be simplified to align with your needs for a given AWS account. For example, someone with PowerUser privileges in the development account may only need ReadOnly for production resources. Setting up a multi-account structure can be streamlined using AWS Organizations and AWS Control Tower.
- Use IAM Role assumption.
Role assumption is a powerful IAM functionality that can be used across AWS accounts. You likely have used roles for AWS services, usually to enable them to access other AWS services. Similarly, an IAM user can assume a role to access AWS services. One successful pattern we see many clients use is setting narrowly scoped permissions for IAM users, essentially only allowing users to assume a role, and that role has the necessary permissions for the job function. For example, one group might be “SecurityTeam.” The policies applied to the group are those which would allow a user read-only access to most things, write access to manage their own credentials and MFA, and the ability to assume the SecurityRole. This role-based access strategy can be established using AWS Control tower, which leverages AWS Single Sign-On (SSO). Using AWS SSO, your users can have one-click access to a given role in a given account, such as “AdminRole” in your development account.
- Tighten up your IAM policies.
The truth is, IAM isn’t something you configure once and forget about. Like many other services, it requires tuning, modifications, and maintenance over time. Set aside time to regularly review your IAM policies and remove superfluous permissions.
Following these 10 tips will support your organization in securing your AWS resources. Some of the items on this list are one-time fixes, but many of these activities will be ongoing for your organization. I promise, the benefits of securing your account dramatically outweigh the costs! Remember, security is everyone’s responsibility, and successful teams are unified in their understanding and execution of security measures.
Want help tackling these or other daunting tasks in AWS? Not sure which identity solution is the best fit for your organization, or where to start? We are here to help! Just reach out to us at info@1strategy.com, we would love to work with you!
