Secure Access Management in AWS

PL version here

In the last paper I published here, I included security best practices based on my experience conducting the AWS Well-Architected Review. In this article, I want to share with you a topic that seems so basic and so obvious that sometimes I skip certain components, which is my mistake. Recently, during a new “project” in which I had the opportunity and pleasure to take part, and about which I’ll soon say more, I came across the fact that not everything, even for me, is obvious. During a spontaneous conversation, I sometimes find it difficult to clearly explain to a layman, e.g. what the automatic rotation of credentials in AWS is. On the one hand, I feel bad because I’m in security, but on the other hand, I have further points with which I can work more in practice, which will translate into better understanding of the topic, and therefore greater confidence that I’ll indeed help others understand the topic.

Who has access to what?

The basis of security management in AWS is the policy of who can access what. This concept is divided into two main categories: “who” — including developers, applications, workloads and automated tasks, and “what” — including AWS resources, such as Amazon S3 resources, Lambda functions. IAM connects these entities through access control and permissions, defining and enforcing who can access what resources and under what conditions.

Security key

Below I’ll answer the question what is the foundation for building all rules regarding the safe use of AWS services, including IAM.

Zero Trust

The Zero Trust Principle is based on the assumption that any access attempt may be a potential threat, so by default no one is trusted — neither internal nor external users. Zero Trust highlights several essential points:

1. Even when an internal service tries to access another internal service, verification is required.
2. Build access permissions with the assumption that every access is a potential security breach.
3. Restrict access and permissions as much as possible without interfering with users’ daily work.

By adopting a Zero Trust model, you can reduce the risk of unintentionally granting access to unauthorized users. IAM and Zero Trust work perfectly together to ensure that IAM policies and procedures are always followed, regardless of user access needs.

Principle of Least Privilege

This principle refers to the Zero Trust and involves limiting access and permissions as much as possible without disrupting the normal work of users.
To ensure security, users and roles should only be granted the minimum permissions needed to perform their tasks, so IAM policies should be designed to limit access to the bare minimum, with the option to extend permissions as needed. This process requires defining, auditing, and adjusting permissions to minimize the risk of excessive access.

AWS Identity and Access Management (IAM)

Basic AWS service, closely related to security in the cloud environment. This service enables granular management of access to services and all AWS resources. IAM identities, i.e. users, user groups, roles, provide control over who is authorized to perform activities in AWS accounts. Below I briefly present the division in terms of the mentioned identities.

AWS primary user (root)

After creating an AWS account, we start with a single login identity — “root” — that has full access to all AWS services and resources in that account. This is the so-called the root user of the AWS account, which is accessed by logging in using the email address and password used to set up the account (it’s also recommended to use multi-factor authentication — MFA). The root account should not be used for everyday tasks. Keep your login details secure and only use them for tasks that require the highest level of privileges.

IAM users

An IAM user is an identity with specific permissions for one person or application. A better practice is to use temporary credentials (these credentials may have a more limited set of permissions than standard IAM user credentials and automatically expire after a specified period of time), rather than creating IAM users with long-term credentials such as passwords and access keys. If we already create IAM users, they can be added to the so-called IAM groups, which makes it easier to manage permissions for many users at the same time.

Root & IAM user

• Root user
  As I mentioned above, root credentials allow full access to all resources and services in your AWS account, so you cannot restrict root access via IAM policies. The only solution is AWS Organizations service control policies, which may impose some restrictions on the root user.
• IAM user
  IAM users are identities created within an AWS account that represent people or services that interact with AWS resources. They may be assigned specific permissions tailored to their role and needs, thus limiting the scope of access to AWS resources. IAM users may have long-term credentials such as a username and password or access keys that allow them to access the AWS console, AWS CLI, or by leveraging AWS APIs.

Key Differences
1. The root account has access to all resources and services in the AWS account, while IAM user permissions can be customized in detail.
2. Root credentials should only be used for selected account and service management tasks that require the highest level of privileges, while IAM users are recommended for daily access to AWS resources, allowing privileges to be limited to the minimum necessary.
3. Security best practices say to secure root credentials and use additional security measures like MFA. Security policies, including MFA, can also (and should) be applied to IAM users.

IAM user groups

An IAM group is an identity that defines a set of IAM users. Groups cannot be used for logging in, but they allow you to define permissions for many users at once, which makes it easier to manage permissions for sets of users such as developers.

IAM roles

An IAM role is another identity with specific permissions, similar to an IAM user, but not assigned to a specific person. This type of identity with temporary credentials is used in situations such as federated user access, temporary IAM user permissions, cross-account access, and cross-service access. You can find more about the situations mentioned here.

A key practice in managing access in an AWS environment is using roles to delegate permissions. Instead of placing access keys in code or instances, it is recommended to use IAM roles and generate temporary security credentials, which allows you to take over the IAM role using AWS Security Token Service (STS) operations or by switching to a role in the AWS console, which is much more secure than using long-term passwords or access keys. Applications running on AWS EC2 instances that need access to other AWS services, such as writing and reading data to Amazon S3, should also use IAM roles. This avoids the problem of securely distributing and managing credentials on each instance by eliminating the need to create IAM users with access keys.

In other words, a role is an entity that has its own specific set of permissions, but is neither a defined user nor a user group. Unlike IAM users, roles do not have a fixed set of credentials. Instead, Amazon EC2 provides instances with temporary credentials that are automatically renewed, improving security and easier management.

AWS IAM concept

Policies

AWS IAM includes several types of policies, enabling granular control over access to AWS resources by users, groups, and roles.

Managed policies by AWS

For users new to AWS, considering using predefined policies managed by AWS is a convenient solution. These policies cover common use cases and are tailored to common IT functions, and are automatically updated when AWS introduces new services or APIs. However, please note that policies managed by AWS do not guarantee the principle of least privilege, which may pose a security risk.

Inline policies

The best practice is to apply the principle of least privilege by creating your own customer-managed policies. They allow you to precisely define the necessary permissions for user groups, while offering functions such as reuse, central change management, versioning and management of delegated permissions. Built-in policies are used when there is a close relationship between the policy and the identity assigned to it, which prevents permissions from being accidentally assigned to the wrong identity.

Best practices

In this part, I’ll focus on presenting best practices for managing access in the AWS environment.

Recommendations for IAM policies

• Defining conditions in IAM policies allows for greater control over access, such as limiting access to resources from specific IP ranges or requiring MFA authentication to perform certain actions. However, it’s better to avoid overcomplicating policies :)
• You should verify both the syntax of the JSON file that defines the policy and its logic. For this purpose, the IAM Access Analyzer can be useful to help evaluate policies and suggest changes to limit overly broad permissions.
• Using analysis of activity recorded by AWS CloudTrail, you can generate policy templates that reflect the permissions actually used, making it easier to align policies with the principle of least privilege.
  Regularly reviewing IAM policies, including assigned access levels (List, Read, Write, Permissions management, Tagging) for each action in the service, is crucial to maintaining the security of your AWS account.

IAM centralization

• Use separate AWS accounts for different environments (e.g. development, test, production) for maximum separation of resources and permissions. AWS IAM Identity Center provides a central set of identities, access to accounts across your AWS organization, connection to your existing identity provider, temporary credentials, MFA, and single sign-on for all AWS account permissions.
• Delegate access to resources between AWS accounts by creating roles in one account and allowing users from another account to assume those roles to avoid unnecessary repetition of user, role, and policy definitions.

IAM role instead of IAM user

IAM roles should be used for applications running on Amazon EC2 instances that make requests to AWS, mobile applications that make requests to AWS, or when users in a company are authenticated to the corporate network and want to use AWS without having to log in again.

So when and why should you create IAM users instead of roles? Creating IAM users is only recommended in cases that are not supported by federated users. Such cases may include workloads that cannot use IAM roles, external AWS clients that do not support access through the IAM Identity Center, access to AWS CodeCommit, and, in certain cases, access to Amazon Keyspaces (for Apache Cassandra).

Don’t use the root account

• The root account should only be used to create an IAM administrator. Root user credentials should be stored safely and used only in exceptional situations, as I wrote above.
• Delete the root access key or rotate the access keys regularly if you choose to keep them.

Multi-factor authentication (MFA)

Enable MFA for all users to further secure your AWS account, even if your password or access keys are compromised.

Security credentials

• Implement a custom password policy that requires users to create strong/more complex passwords and rotate them regularly.
• Delete IAM passwords and access keys you don’t use, and delete the credentials of users who don’t need console access or only use the console.
• Change passwords and access keys regularly not only for IAM users but also for AWS services.

To increase your security level, it is recommended to implement security credential rotation automation using AWS IAM, AWS Secrets Manager, AWS Lambda, and AWS CloudTrail integrations. AWS IAM enables precise management of user identities and their access keys, offering control over permissions and access to AWS resources. AWS Secrets Manager is a key component in this architecture, providing solutions for securely storing access keys, secrets, and automating their rotation. The rotation automation mechanism uses AWS Lambda functions to generate new access keys and update stored secrets in Secrets Manager on a scheduled schedule. This action allows applications to seamlessly use current and secure credentials, minimizing the risk of potentially using outdated or compromised keys. Additionally, AWS CloudTrail performs an auditing function, logging all operations performed on credentials, which provides an additional layer of control and the ability to verify compliance with security policies. This monitoring allows you to quickly identify and respond to any unauthorized or suspicious activity in your AWS environment.

The introduction of the described solution not only increases security by ensuring continuous rotation of credentials, but also reduces the complexity of credential management by automating processes that previously required manual intervention. This is particularly important in dynamically changing cloud environments, where the speed and automation of security processes are crucial to maintaining a high level of data and resource protection.

Automation

Instead of manually managing IAM resources through the AWS console, it is better to use automation tools such as Terraform or CloudFormation to minimize the risk of human error and facilitate auditing and reporting for compliance requirements.

Example use cases for AWS IAM

1. Creating and managing user identities, managing their access rights to AWS resources.
2. Grant permissions to AWS resources for applications and services without the need to hardcode access keys in application code.
3. Delegate permissions to users, applications or services using IAM roles without having to share access keys.
4. Limiting user and service access to the absolute minimum needed to complete their tasks.
5. Integration with external authentication systems such as Active Directory or OpenID Connect identity providers to allow users to use their existing credentials to access AWS resources.
6. Strengthen security by requiring users to use an additional form of authentication in addition to a password.
7. Using AWS CloudTrail and other tools to monitor and record IAM-related activities for audit and compliance purposes.
8. Automate the creation and management of IAM users, groups, roles, and policies with Infrastructure as Code (IaC) and the AWS CLI or SDK.
9. Create advanced access policies that restrict access based on various conditions such as IP address, time of day, and MFA authentication.
10. Systematic rotation of IAM access keys and certificates to reduce the risk of compromise.

Conclusion

In this post, I touched on an issue that may seem obvious, but is often overlooked — the basics of security management in AWS. In the next entry, I’ll try to present the topic of further security services, and in the meantime, I encourage you to constantly learn and adapt security practices to effectively manage access and security in your cloud environment.