In the ever-evolving landscape of cloud computing, Amazon Web Services (AWS) stands out as a leading provider, empowering organizations to scale and innovate. However, the power of AWS comes with the responsibility of ensuring robust security measures. Among the foundational pillars of AWS infrastructure security is Identity and Access Management (IAM).
This blog post will delve into the crucial IAM best practices that organizations must adopt to secure their AWS infrastructure effectively.
Understanding IAM
IAM is an AWS framework of policies and technologies that dictates who can access the cloud, what they can access specifically and what actions they can perform with regards to technology resources available in the cloud.
The two fundamental components in IAM are “roles” and “policies.” Roles are IAM identities used to assign permissions under a common label for ease of management, while policies are about defining those permissions and the conditions under which they apply. This system allows for efficient, secure and highly customizable management of access to resources in an IT environment.
Roles
A role is an AWS IAM entity used for fine-grained access control, in combination with policies that are attached to them. These determine what permissions are granted to entities that assume the role (what the specific role can and cannot do). For instance, a 'Database Administrator' role may include permissions to create, modify, and delete databases and database users.
IAM roles allow CTOs to follow the best practices when it comes to securing their infrastructure on AWS. Using roles helps in managing user permissions more efficiently, as it allows the grouping of several permissions under a single role.
Unlike IAM users, roles do not have standard long-term credentials (like a password or access keys) associated with them. Instead, when a role is assumed, it provides temporary security credentials for that session.
Roles also enable cross-account access, allowing entities in one AWS account to assume a role in another account.
We can distinguish between two different types of roles: instance roles and service roles. Both are critical for managing permissions in a secure and scalable way in AWS. They allow for fine-grained access control and ensure that best practices in security are followed, such as the principle of least privilege (only granting the permissions necessary to perform a task).
Instance roles
An instance role is a role that an EC2 instance can assume to grant applications or services running on the instance the necessary permissions to access AWS resources. These are used to avoid using and storing AWS credentials directly on the EC2 instance.
Using credentials always carries a number of risks: leaking, being subject to cyber attacks, compromise or loss. To avoid these risks, the instance is given a role, and any application running on that instance can use the role's permissions to access AWS resources. What the instance can and cannot do will be defined by the policies to the role.
Service roles
A service role is an IAM role that a service assumes to perform actions on behalf of the user. They are used to grant AWS service permissions to access resources in your account. Service roles are necessary because AWS services themselves do not have their own AWS credentials, and they need a way to interact with your cloud infrastructure securely.
For example, if you're using AWS Lambda, you need to create a service role that defines what the Lambda function is allowed to do (like accessing a database or writing logs to CloudWatch).
Like instance roles, service roles are associated with policies that define their permissions, but in this case, the role is assumed by the AWS service rather than by an EC2 instance or a human user.
Trust Relationships
Trust relationships in IAM refer to the policies and configurations that allow roles to access resources under the control of another entity. This is often used in scenarios where resources are spread across different domains or cloud services. There are two components CTOs need to be aware of: "trusting" and "trusted" entities. They form the foundation of RBAC and delegation. The relationship between the trusting and trusted entities must be explicitly defined through trust policies.
Trusting entity
The trusting entity, often referred to as the "trustor," is the entity that allows access to its resources. It is the owner of the resource or the account that holds the resource. In the context of IAM, the trusting entity is typically an IAM role or an account that defines a trust policy.
The trust policy is a document attached to the IAM role. It specifies the conditions under which the role can be assumed. The trust policy answers the question, "Who is allowed to assume this role?"
Trusted entity
The trusted entity, or "trustee," is the entity that is given permission to assume the role and access resources. This can be a user, an account, or a service. In IAM, the trusted entity assumes the role defined by the trustor. By assuming the role, the trusted entity inherits the permissions associated with that role.
The process of assuming a role involves the trusted entity making a request to the IAM service to take on the role and its permissions. This request must satisfy the conditions laid out in the trust policy.
Example Scenario
Imagine a company with two AWS accounts: Account A (Trusting Entity) and Account B (Trusted Entity). Account A has an S3 bucket with sensitive data and has created an IAM role named "DataAccessRole." The trust policy attached to "DataAccessRole" specifies that only Account B can assume this role. Account B needs to access the S3 bucket in Account A for data processing tasks. An IAM user or service in Account B assumes the "DataAccessRole" from Account A, thereby gaining access to the S3 bucket as defined by the permissions of the role.
Policies
Policies in IAM are JSON documents that specify the permissions and actions allowed or denied for AWS resources. They are broadly categorized into identity-based and resource-based.
It’s critical to understand some policies function to limit permissions, whereas others serve to provide access. Employing a mix of various policy types enhances your overall security framework and simultaneously reduces the potential impact in the event of a security breach.
Identity-based policies
Identity-based policies are attached to IAM identities: users, groups, or roles. They define what an identity that assumes a role can and cannot do. Every role will be assigned at least one policy.
Policies can be very granular, specifying not just what resources a user can access, but also under what conditions. For instance, a policy might allow access to a resource only from a certain IP address or during certain times of the day. Or, it can allow a user to launch an EC2 instance but not to delete one.
Policies consist of one or more statements, each containing an effect (Allow or Deny), an action (the specific AWS service operation), and a resource (the AWS resource on which the action can be performed).
There are three different types of identity-based policies: managed policies, customer policies and inline policies.
Managed policies
These are created and managed by AWS. They are designed to provide permissions for many common use cases. There are numerous, read-made policies available and ready-to-use, which adds convenience for small organizations with basic security requirements. However, these policies are quite general. More complex organizations with non-standard requirements should make use of their own policies, or customer policies.
Customer Policies
Created and managed by your organization’s cloud admin. They allow for more precise control over your resources through policies that are fully specified by you. These policies allow you to specify exactly what actions are allowed or denied for AWS resources and what roles they should be attached to, and thus who can perform those actions. They’re sometimes referred to as Customer Managed Policies.
Inline Policies
These are also custom-built policies, but, unlike customer policies, inline policies are not standalone objects like customer managed policies, but are an integral part of the entity they are attached to. These are embedded directly into a single user, group, or role. They are useful when you want to maintain a strict one-to-one relationship between a policy and the identity it's applied to. Since inline policies are attached to individual entities, the size and number of these policies are bound by the quota limits of the IAM entity they are attached to.
Resource-based policies
Unlike identity-based policies, resource-based policies are attached to the resources themselves (e.g., an S3 bucket, an SQS queue, or a Lambda function). These policies specify which principals (identities from the same account or other accounts) are allowed to access the resource and the actions they can perform.
Resource-based policies are particularly useful for granting access to resources to users from different AWS accounts.
AWS Organizations
AWS Organizations are important in the context of IAM, as they allow the application of policies outlined earlier. This is an AWS service that allows admins to manage their cloud resources, especially when they need to scale. It's particularly useful for large enterprises or businesses with complex organizational structures.
They allow to organize accounts into a hierarchy of Organizational Units (OUs). This hierarchical structure helps in managing policies and resources according to the different needs of various departments, teams, or projects within the organization.
With AWS Organizations, we have to introduce yet another concept: Service control policy (SCP).
With AWS Organizations, we have to introduce yet another concept: Service control policy (SCP).
Service control policies
SCPs are a type of policy used to manage permissions and control access across all accounts within your AWS infrastructure. They apply to all IAM entities (users, groups, and roles) and AWS resources within an AWS account, including OUs.
SCPs provide centralized control over the maximum available permissions for all accounts in your organization. They allow you to specify the services and actions that users and roles can or cannot use in the accounts to which the SCPs are applied.
However, SCPs do not grant permissions; instead, they act as a filter. They define a boundary of permissions that IAM policies (attached to users, groups, or roles) cannot exceed. For instance, if an SCP blocks access to a specific AWS service, no user or role in the affected accounts can access that service, even if their IAM policies allow it.
We are now ready to demonstrate a scheme that every CTO taking care of AWS infrastructures should be familiar with.
AWS access evaluation scheme
This is an AWS service that helps to evaluate your IAM policies. It’s immensely helpful especially in those cases where you’ve set up your IAM policies and find they don’t work. This sequence diagram, which demonstrates what resources or policies you should investigate and in what order, will help you find errors in your policies.
Principle of Least Privilege
The principle of least privilege, a fundamental concept in IAM, advocates providing individuals or systems with the minimum levels of access or permissions required to perform their tasks. This principle is oriented at reducing the potential attack surface and mitigating security risks by limiting unnecessary access, thereby minimizing the impact of security breaches.
The principle focuses on allowing users to do the minimum they need to do. It greatly simplifies security management in AWS. For instance, if a number of files goes missing from a location, then the principle of least privilege will greatly narrow down the search process - as long as the principle has been applied correctly.
Who grants these permissions? Depending on the size of the organization and its needs, as few people as possible should have such capabilities. That person will have to figure out what roles, groups and policies to create depending on the exact needs of a given team. All in all, it’s that person’s job to find out precisely what kind of permissions should be granted, to whom and to what resources. It’s critical that this person also establishes what a given role shouldn’t do and shouldn’t have access to.
Applying the principle of the least privilege also minimizes potential harm. Let’s assume that some credentials that give access to a single microservice leaked. Applying the principle of the least privilege correctly will guarantee that, even if somebody does use these credentials, they won’t be able to access anything outside of these microservices. They won’t be able to launch a new EC2 instance, won’t be able to delete files or browse through clusters on S3. That’s what a solid security policy should guarantee via IAM - always granting access the the very minimum, a tiny percentage of resources.
Apply the bounded permissions framework
Bounded permissions refer to the practice of restricting permissions to the minimum a user requires to to perform their tasks. It's an application of the principle of least privilege that stipulates that the scope of permissions should be tightly defined and limited, and that IAM entities (users, groups, roles) aren’t granted more access than they need.
Bounded permissions are tightly related to policies - while the latter specify "what" permissions are granted or denied, bounded permissions dictate "how much" or "to what extent" those permissions should be applied.
For example, if a user only needs to read data from a specific S3 bucket, a policy reflecting bounded permissions would grant s3:GetObject access only for that bucket, rather than s3:* access, which would include unnecessary permissions for writing, deleting, or accessing other buckets.
Use Amazon Resource Names (ARN)
When you write an IAM policy, you should use Amazon Resource Names ARNs to specify which resources the policy applies to. For example, you might specify a certain S3 bucket or a specific EC2 instance. This allows you to finely control what actions a user or service can perform on a given resource. ARNs are also used to grant access to resources in different AWS accounts, allowing to securely share resources across accounts.
ARNs typically have the following format:
Utilize Role-Based Access Control (RBAC)
Utilize RBAC to define and assign roles based on job responsibilities. Each role should have the minimum set of permissions necessary for the associated tasks. You should focus on streamlining access management and ensuring that individuals only have the privileges required for their specific roles. RBAC is also relevant in the context of setting Trust Relationships in IAM (we explain this further below).
Set granular permissions
This is about defining fine-grained permissions rather than providing broad, all-encompassing access. You should break down permissions into smaller, more specific actions, so that you limit the potential for abuse or accidental misuse of privileges. A good example is differentiating between read and write permissions.
Apply the principle of justification
Whenever a team member approaches you asking to grant them certain permissions, ask them to justify the need for those before you grant them. You have to make sure any access is granted based on actual business requirements rather than convenience. Your goal here is to avoid setting up over-privileged accounts.
Grant temporary privileges
Grant temporary access when needed instead of providing permanent privileges. Temporary access can be granted for a specific task or project and revoked once the task is completed. This will help you limit the exposure to potential threats and unauthorized activities.
Embrace the Zero Trust security model
This approach, which assumes that no user or system, even those within the organization, should be inherently trusted, should be your guiding principle when enforcing the principle of the least privilege. Require verification and authorization for every access attempt, regardless of the user's location or network.
Multi-Factor Authentication (MFA) and Security Credentials Report
Configuring the MFA rests with each person that owns an AWS account. It’s clearly specified in the Shared Responsibility Model: AWS offers resources and provides a host of different options to secure these resources, but doing so is actually a user’s responsibility. MFA is one of those options.
The Root account, the most important account as it holds all of the possible permission in AWS, is the first account on which MFA should be set up. Lack of MFA on this account will certainly be signaled by AWS, but it won’t force the user to set it up. Similarly, with other types of accounts, AWS won’t require setting up MFA - it is the user’s responsibility to do so.
As part of IAM best practices, Root account holders should:
- have several MFA methods set up, in case one of them fails. In case of a Root account, one of these options should include logging in via token activated with a fingerprint. Such devices have to be assigned to the Root account. A good option is to have a virtual MFA with two security keys installed.
- enforce that all users set up MFA upon their first login, which is possible to do from the level of the Root account. Good options include external authenticator apps, codes sent to mobile devices
Security Credentials Report
CTOs should be familiar with this feature within the IAM service. It provides a detailed list of all AWS IAM users within an account, including the status of their various credentials like passwords, access keys, MFA devices, and when these credentials were last used. This includes information on whether the passwords or access keys are active, expired, or have not been used within a specific period. CTOs can use the report to identify users with stale or unused credentials, which can be a security risk.
As such, this feature is greatly helpful in identifying and managing the credentials of all users. The report is also invaluable for audit purposes, allowing organizations to comply with various regulatory standards that mandate strict control and monitoring of access credentials.
Rotating credentials
It's a prudent move to regularly rotate credentials such as access keys and secret keys is a crucial practice. By doing this frequently, you significantly reduce the risk of unauthorized access or breaches.
However, there's a balancing act involved here. You want to rotate credentials often enough to maintain high security, but not so often that it becomes a major headache for your developers. If the process is too disruptive, it can slow down productivity or lead to workarounds that might compromise security.
The trick is to find a sweet spot where credential rotation happens routinely but doesn't throw a wrench in the development workflow. Automation can be a game-changer in this aspect. Setting up automated processes for credential rotation helps maintain consistent security practices without placing too much manual burden on your team.
Security audits and assessments
Keeping your AWS infrastructure hinges a lot on how well you handle IAM. To ensure you’re always on top of how you manage access and identities in your AWS infrastructure, You have to regularly dive into some key security audits and assessments. Here's what you should be focusing on:
- Reviewing IAM policies: take a look at the policies linked to your IAM users, groups, roles, and resources. The goal is to keep it tight – only give enough permissions for what's necessary. Keep these policies up to date and remove any permissions that aren't needed anymore.
- Reviewing IAM identities: scope out your IAM users and roles. Are there any that haven't been active in a while? It might be time to say goodbye to them. Also, double-check that multi-factor authentication (MFA) is on for everyone.
- Reviewing boundaries on permissions: make sure roles don't go beyond what they're supposed to do.
- Reviewing cross-account access: these can get tricky, so make sure you have a grip on who and what can access your resources across different accounts.
- Keeping a close look on the Root Account: delegate everyday tasks to regular IAM users and roles.
IAM Access Analyzer
The Access Analyzer can generate comprehensive reports that lay out in detail which users have accessed specific AWS resources. This isn’t just a list; it’s a granular breakdown of user-resource interactions. You can see who accessed which resource, when, and what actions they performed. It’s like having a detailed ledger of every move made within your AWS environment.
Examining these reports can help you in conducting a thorough review of the IAM policies you’ve set up. This is crucial because, let’s face it, even the most meticulously crafted policies can have oversights. The report acts as a reality check, showing you how your policies translate into actual access patterns.
How RST software can help you secure your AWS infrastructure
IAM plays a crucial role in ensuring the security of AWS environments: it provides a robust framework for managing access to AWS resources. IAM allows you to control who (identities) can do what (permissions) on which resources, enhancing overall security and governance.
There are a number of aspects related to IAM that are critical to maximizing security of your cloud infrastructure: fine-grained access control, principle of least privilege, identity federation, credentials policies and MFA are just a few of them. As an official, certified AWS partner we can apply our two-decade-long experience to secure your cloud resources, or help you migrate and optimize your expenditures throughout the process. Contact us via this form today to discuss our competences in greater detail - we’ll get back to you.
