AWS Identity and Access Management (IAM)
AWS Identity and Access Management (or IAM) is a service that offers secure access control mechanisms for all of your AWS services and in some cases resources. AWS IAM is at the heart of AWS security because it empowers you to control access by creating users and groups, assigning specific permissions and policies to specific users, setting up multi-factor authentication for additional security, and so much more. And the cherry on top, IAM is free to use!
Here, we will demystify the fundamentals of AWS IAM to offer you a complete overview of IAM, help you identify its unique benefits, and learn how to start empowering users to safeguard your AWS accounts
IAM in a Nutshell
Security in the Cloud remains one of the biggest barriers to Cloud adoption. For SecOps and SysOps teams, it becomes paramount to follow security best practices to ensure a smooth transition with a strong foundation. With all the scrutiny and public attention surrounding major Cloud platforms, it’s admirable that AWS IAM follows an incredibly granular approach in providing permissions and access control within your environments. IAM lets you control who can use your resources (authentication) and in which ways (authorization). This is why it’s possible to create exceedingly secure environments using AWS.
Key Features
- Authentication: AWS IAM lets you create and manage identities such as users, groups, and roles, meaning you can issue and enable authentication for resources, people, services, and apps within your AWS account. In the next section, we’ll look at authentication in detail.
- Authorization:Access management or authorization in IAM is made of two primary components: Policies and Permissions. In the next section, we’ll also look at each of these.
- Fine-grained permissions:Consider this — you want to provide the sales team in your organization access to billing information, but also need to allow the developer team full access to the EC2 service, and the marketing team access to selected S3 buckets. Using IAM, you can configure and tune these permissions as per the needs of your users.
- Shared access to AWS accounts:Most organizations have more than one AWS account, and at times need to delegate access between them. IAM lets you do this without sharing your credentials, and more recently, AWS released Control Tower to further simplify multi-account configurations. We also published a quick, hands-on tutorial on Securing Multi-Account Access on AWS.
- AWS Organizations:For fine-grained control for multiple AWS accounts, you can use AWS Organizations to segment accounts into groups and assign permission boundaries.
- Identity Federation: Many times, your organization will need to federate access from other identity providers such as Okta, G Suite, or Active Directory. IAM enables you to do this with a feature called Identity Federation.
Authentication in IAM
Authentication or identity management in AWS IAM consists of the following identities:
- Users:An IAM user is a person that needs to interact with your AWS resources or services either from the AWS Console or with the AWS CLI. When you create a new user, no credentials are assigned, and the user does not have any permission to access your AWS resources.
- Groups:An IAM group is a collection of users and permissions assigned to those users. Groups provide a convenient way to manage permissions for users with similar needs by categorizing them according to their job function/role, department, or any other requirement. Then, permissions for all those users can be managed at once through the group.
- Roles:An IAM role is an entity within AWS which defines a set of permissions the role can perform, and what entities can assume the role. A role is not directly linked to a person or a service, rather it can be assumed by any resource that the role grants permission to. Role credentials are always temporary and rotated periodically by the AWS Session Token Service (STS). For this reason, it is recommended to use roles over directly granting user or group permissions. Additionally, Roles allow you to grant multi-account access to your AWS resources from users, services, and apps that aren’t part of your business. The concepts of users and groups will be familiar to most system administrators, but IAM Roles can often be unfamiliar. Let’s dive into more details below.
IAM roles fulfill a unique and powerful niche in the identity and access management landscape. Instead of assigning permissions to an entity directly, roles allow an entity to be granted permissions temporarily (on an as-needed basis) to perform tasks. This enforces the least privilege principle which is based on both identity and time, as you can restrict entities to both the minimum amount of access needed as well as the minimum amount of time needed to complete a task.
Authorization in IAM
Authorization or access management in IAM is controlled by Policies that grant Permissions.
WHAT IS A POLICY?
A policy is a document with a set of rules, having one or more statements. Each policy grants a specific set of permissions and can be attached to any of the IAM identities we covered earlier — users, groups, and roles. Policies are always written in JSON or YAML format and each policy has a name.
There are two types of policies you should know about:
- Managed policies: Managed policies can be created and attached to multiple entities. AWS has built-in managed policies that cover a wide variety of use cases. Managed policies can also be mixed and matched to provide generalized access to roles, users, or groups. AWS customers can also create their own managed policies.
- Inline policies: These policies are directly applied to IAM entities, and do not have distinctive ARNs. You use inline policies for a specific objective, which makes them non-reusable.
AWS recommends the use of managed policies instead of inline policies so that permissions are more standardized and can be reused.
WHAT ARE PERMISSIONS?
Permissions enable you to perform actions on AWS resources. When a new user or group is created, it has no permissions and a policy must be attached to allow actions to be taken on AWS resources.
You can assign permissions to all AWS identities (users, groups, and roles). Permissions are assigned in the following two ways:
- Identity-based: Policies attached directly to users, groups, or roles
- Resource-based: Policies attached to AWS resources, such as S3 Buckets, ECR Repositories, and more
When writing new policies, the following resources can be helpful:
- Manage IAM Permissions: This page offers quick reference to help you assign and manage IAM permission
- Actions, Resources, and Condition Keys: A comprehensive reference to all possible actions that can be taken on various AWS services
- AWS Policy Simulator: Validate that newly created policies work end-to-end by creating access simulations
Generally, policies should follow the principle of least privilege, which means only the absolute minimum set of access should be granted to get the job done. Policies can be extremely specific — consider the following code block, for example:
Or policies can be broadly defined, such as in the following code block:.
Finding the right balance is important, as overly granular policies lead to undue overhead, and overly broad policies can lead to inappropriate access, which is a major factor in security breaches. Following the principle of least privilege can go a long way in ensuring that only a minimal amount of damage occurs during unexpected security events.
AWS IAM Analyzer
IAM Access Analyzer helps you generate a comprehensive report for all your AWS resources that could be accessed publicly i.e. outside of AWS accounts. This also includes “service last accessed” data which essentially is a timestamp of what resources and services were accessed by which users and roles. By using Access Analyzer, admins can examine thousands of policies in their environments in a matter of seconds. Access Analyzer is part of Amazon’s Provable Security efforts to achieve the highest levels of security using automated reasoning technology and mathematics logic. IAM Access Analyzer (also includes Access Analyzer for Amazon S3, had its separate press release) is in line with the overall ethos of AWS IAM service, meaning it involves no additional cost and is included as part of the IAM console.
Implementation Guideline
The threat landscape changes rapidly, which is why it’s more important than ever before to continuously tighten your security practices. Great security practices in the cloud are often the simplest of steps designed around access management and control.
Setting up a Password Policy for your AWS account using IAM
- Navigate to the AWS IAM console and click on Account settings as shown here:
- Next, click on the Set password policy button
3. You can now set up your password policy by defining a set of rules and selecting the complexity requirements for the password an IAM user can set. The example below meets the standards recommended by the Center for Internet Security (CIS):
Setting up Multi-Factor Authentication (MFA) using AWS IAM
Multi-Factor Authentication (MFA) protocols offer a great way to improve the overall security posture of your AWS cloud services and resources. This simple step could even prove instrumental in preventing costly breaches for your organization. In this tutorial, we will show you how to set up MFA using a mobile device.
- Go to the AWS console, and select your username in the top right corner
- In the dropdown menu, select the My Security Credentials button
- Scroll down the page until you reach the section titled Multi-factor authentication (MFA), then select the Assign MFA Device button
4. Select virtual or hardware MFA device as appropriate.
5. If a virtual MFA device was selected, scan the QR code with your MFA app (such as Duo Mobile, Google Authenticator, Microsoft Authenticator, etc.) and input two subsequent codes. Select the Assign MFA button and you’re all set!
6. If instead, you wish to use a hardware MFA device (such as a yubikey) for additional security, you will be prompted to insert the MFA device and tap the button. Your web browser may inform you that aws.amazon.com is requesting information about your hardware device. If so, grant it. Now your hardware MFA device is ready to go.4. Select virtual or hardware MFA device as appropriate.
AWS IAM Best Practices
Amazon takes the security of its services and resources very seriously. One of the areas that Amazon has focused on is providing a robust access control service to its Amazon Web Services (AWS) customers. AWS’s identity and access management (IAM) service allows customers to manage users, groups, roles, and permissions. But it’s entirely up to AWS customers to properly configure IAM to meet their security and compliance requirements. To help you make the most of Amazon’s built-in controls, we’ve compiled the top 13 AWS IAM best practices every organization should follow –
1. Restrict use of the AWS root account – When you register an account with AWS, the initial user account created is known as the root account. This account has complete access to every AWS resource (including billing information), making it the most privileged user account. Since root account credential permissions can’t be restricted, it is recommended that access to the root account be restricted to tasks that can only be completed using the root account (like creating the first admin account). For all other tasks, create an IAM user that has administrative privileges, and use that account to manage your AWS environment on a day-to-day basis.
2. Rotate root account access keys and enable multifactor authentication (MFA) – Regardless of how seldom the AWS root account is used, it is highly recommended that the account access keys are rotated on a regular basis using the security credentials page, and MFA is enabled to use the root account.
3. Never share AWS account credentials – Instead of sharing AWS accounts, create individual IAM users for employees that need to access AWS resources. This will allow you to assign a unique set of permissions to different users based on their job requirements.
4. If possible, use AWS managed policies to assign permissions – Amazon provides a pre-defined set of policies that are completely managed by AWS and customers aren’t allowed to edit the permissions. These policies are designed to serve common use cases while making it easier to enforce access policies than creating policies yourself from scratch.
5. Assign permissions at IAM group/role level rather than individual IAM user level – AWS allows policies to be defined at the IAM user/group/role level when a new user/group/role is created (known as inline policies). AWS customers can also apply customer-managed policies (which could be derived from cloning AWS managed policies) to a set of IAM users, groups, or roles. As a best practice, avoid assigning customer-managed policies to individual IAM users or defining inline policies when creating an IAM user. Instead, assign policies to a group of IAM users or write inline policies when creating an IAM group. This streamlines the process of making changes to multiple user permissions and decreases the risk of accidentally giving individual users an unnecessarily high set of permissions.
6. Never grant privileges beyond the minimum required for a user or group to fulfill their job requirements – One of the more common mistakes made when provisioning AWS users is granting them privileges that go beyond what’s minimally required. While it may be faster to create IAM users without scrutinizing the assigned privileges, unfettered access to AWS significantly increases the potential damage in the event of lost or stolen user credentials.
Verizon’s Data Breach Investigations Report 2020 further underscores the threat from compromised accounts. The report finds that an alarming 81% of data breaches were caused by stolen or insecure passwords in 2016. It’s therefore important for IT security to ensure that AWS administrators perform adequate research in order to define the right set of permissions.
Tip: if you’re not sure whether users/groups/roles have minimal required privileges, use the Access Advisor tab (found in the IAM console details page) to analyze a user/group/role, which will tell you which services are actually being used by them. This can help determine which services should be blocked.
7. Set a regular cadence to review IAM permissions – As a security best practice, it’s important to regularly review your organization’s AWS IAM policies to ensure they’re granting least privileges. Each policy comes with a policy summary, which is a good place to start when auditing IAM policies. AWS provides four levels of access for each of its services: list, read, write, and permissions management.
The write and permissions management access levels should be granted with caution. Write permits users to create, delete, or modify resources. Permissions management allows a user to grant or restrict resource permissions for entire organization and its AWS users. For this reason, permissions management should be granted to as few IAM users as possible.
8. Enforce a strong password policy for all AWS users – When left to their own devices, most users will select an easy to guess password despite its security risks. According to Skyhigh, the top 20 most common passwords account for 10% of all passwords, with gems like “123456” and “password” accounting for over 5% of all passwords. This means that a hacker can infiltrate one out of twenty user accounts without any brute-force attacks if he just uses the two aforementioned passwords. It’s possible, however, to create highly secure and easy to remember passwords and taking the following steps can help ensure IAM credentials are protected:
- Define a minimum password length of at least 14 characters
- Require non-alphabet characters, at least one uppercase alphabet, and a symbol
- Set up a password expiration policy and disallow password reuse
- Discourage privileged users from using dictionary words in their passwords
9. Enable multi-factor authentication (MFA) for all IAM users – Organizations should assume that at least some of their cloud service user credentials have already been compromised. Since employees have a tendency to re-use passwords across services, enabling MFA should be a requirement not just for AWS but any cloud service that is being used at an organization.
Configuring AWS with a single sign-on provider such as Okta, Ping Identity, or Azure Active Directory can ease the friction introduced by enabling MFA by standardizing authentication factors across all applications employees use.
10. Use IAM roles for custom applications running on AWS EC2 – Any app that requires access to another AWS service in order to function will need its own credentials. As a security best practice, use IAM roles to provide credentials to the application. Roles can have their own set of permissions without any users/groups needing to be attached to them.
When a user first launches an EC2 instance, they can determine the role for that instance, and any application that is deployed on that EC2 instance can then use the role’s credentials to access other AWS resources. The credentials will be dynamic and AWS will rotate them automatically for additional security.
11. Remove unused, stale, or unnecessary IAM users/credentials – To minimize the risk of IAM user credentials being stolen, all unnecessary IAM users should have their access terminated. Employees who no longer work at an organizations or those who have moved on to a different department that don’t need AWS access should not have access to AWS. Organizations should audit their IAM user activity to see which users haven’t logged into AWS for at least 90 days, and revoke their permissions as well.
12. Organizations working with highly sensitive or regulated information (e.g. healthcare, finance, federal government) should use policy conditions as an added security measure – Policy conditions are boolean operators that determine whether a match exists between a policy and a request. There are a near limitless number of conditions that can be used for IAM policies. Policy conditions are especially useful when working with partners and third-party vendors who need access to your organization’s AWS resources. Below are some of the recommended conditions that should be employed:
- Use date/time conditions to limit access to resources such that IAM users are only able to access a resource during weekdays for the duration of their workday/shift.
- Set up conditions that whitelists IP addresses that are allowed to access AWS resources to ensure only trusted IP addresses are able to gain access to an AWS resource.
- For contract employees/partners, set up date conditions that block access to AWS resources after the termination date of the contract.
Only use policy conditions that meet your organization’s security and compliance requirements without hindering employee productivity.
13. Monitor user activity in all cloud services (including IAM user activity) to identify anomalous activity indicative of threats arising from a compromised account, or malicious/negligent internal employee – Amazon supports AWS activity monitoring with AWS CloudTrail. However, organizations should monitor AWS activity alongside all other cloud services to attain a unified view of all cloud activity. This will help to accurately separate a true threat from a false positive alert and also provide insight into cross-cloud threats that would go undetected by only looking at each cloud service in isolation. A cloud access security broker (CASB) provides cross-cloud visibility into user activity to support comprehensive activity monitoring and threat protection.
Conclusion
With all its amazing capabilities and potential, the learning coverage around IAM lacks the gravitas it deserves. As the biggest cloud platform and provider, AWS has introduced several measures to improve security, and IAM is the most critical of all of them. However, security and IAM is a complex subject, which is why AWS launched the Shared Responsibility Model aimed at establishing and sharing the responsibility for security and compliance between both customers and AWS.
