Identity and access management

Note

Securely manage human and machine identities and their permissions to cloud services and resources.

Identity and access management determines who has access to what in AWS. You need robust identity and permissions management to make sure that the right people, machines, and services have access to the right resources under the right conditions.

In this section, we're focused on how people and machines access your AWS accounts and resources; identity and access management for the applications you deploy in AWS is a topic for another paper.

The scope of this topic extends beyond the AWS Identity and Access Management IAM service itself, to include all of the identity-related controls and features in AWS. Even if you don't use every capability, a comprehensive perspective will verify that your identity and access management practices remain scalable and responsive to business needs.

Identity and access-related decisions for AWS will be made continuously by a variety of stakeholders throughout the enterprise. Define and communicate a strategy to inform those decisions. Your strategy might include: 

• Objectives - The desired outcomes of your IAM strategy

• Tenets - Guiding principles so that delegated decisions support your objectives

• Delegation model - To align stakeholder understanding of roles and responsibilities for access management (such as a RACI matrix)

Sample objectives

• Provide a safe place for builders to experiment, fail, and innovate at speed. This includes tools to quickly determine how and why their access is limited, and where to get help when needed. 

• Minimize the possibility of over provisioning permissions and enforce separation of duties to satisfy risk appetite, best practices, compliance, and regulatory requirements.

• Focus your security experts on high-impact outcomes that only humans can deliver; automate the rest, such as guardrails checking roles and policy creation and changes.

• Nearly continuous compliance: automate attestation and reporting, to deliver on-demand the insights that auditors and leaders need. An example is security in the CI/CD pipeline, and a Professional Services offering for Automated Continuous Compliance focused on GxP in Healthcare and Life Sciences.

Sample tenets

• Guardrails, not gates - Design controls to minimize friction around AWS Identity and Access Management in AWS. Use centralized, blocking, manual workflows only when there is no safe alternative. Strive for self-service. 

• Security as code (SaC) - Publish your security baseline as consumable code. Enforce governance in the toolchain. Make the best developer experience a side effect of strong security outcomes.

• Adopt the principle of least privilege - This is a process of continuous improvement. Start simple and iterate. Use automation, detective controls, and analytics to continually rightsize permissions for each role and environment.

• Keep people away from data - At each stage of your software development lifecycle (SDLC), implement IAM policies, mechanisms, and tools to decrease the need for direct access to data stores.

• Use temporary credentials like AWS IAM roles by default - Static users, passwords, and access keys are a last resort, issued by exception only. Where static credentials are used, secure them in a purpose-built secrets management system and rotate them regularly.

Sample delegation model

Delegation of responsibility for overlapping access controls is key to achieving defense in depth. Using AWS IAM, you can avoid delays, mistakes, and missed opportunities that may come with fully centralized access management. As you consider who should be responsible for what, and where to implement particular controls, keep in mind the following:

• Access management for people needs a different approach than access management for machines and services.

• Changes should be approved and made by people with the best knowledge of the business and data being protected.

• Agility and scalability require that developers and data custodians understand permissions management in AWS.

• Permissions policy space in AWS is finite – use the best policy type for each control and make efficient use of all available policy types.

  Policy maximum size is one the few AWS service quotas that cannot be increased from defaults. For more details:

  • Watch Choosing the Right Mix of AWS IAM Policies for Scale (video)

  • Read IAM Policy Types - How and When to Use Them (blog)

Review sample access controls delegation model (R = responsible) in the following table.

AWS access control mechanism	Central cloud governance team	Central cloud IAM/ engineering team	Central security team	Workload /resource owners	AWS account owner
Organization structure	R
Organization policies (SCPs, AWS Control Tower Guardrails)	R
Identity policies for baseline human access		R
Identity policies for baseline account controls & services		R
Permissions boundaries			R
Resource policies for workloads				R
Identity policies for workloads				R
AWS account root password			R
AWS account root MFA token					R

The example delegation model in Table 1 shows separation of duties, which makes it hard for any lone actor to circumvent all of the access controls that protect your AWS environment. Your teams may vary, but no single team or person should have authority over all of the access controls shown. 

Use AWS services for orchestration

AWS often offers more than one solution to common problems. Sometimes this arises from customer feedback, which leads to the launch of new higher-level features to orchestrate existing lower-level ones. Two such examples are AWS Control Tower and AWS IAM Identity Center, which are offered at no extra charge. The costs of a custom solution will outweigh the benefits for most customers in the long term, especially as AWS continues to innovate.

Start

Bootstrap identity and access management for your AWS environment.

Credential management

AWS account root user management is the first capability needed to secure your AWS accounts. Your most sensitive AWS account is the one designated as your AWS Organizations management account and access to it should be strictly controlled. All AWS account root users, especially the management account root user, need a strong password in addition to multi-factor authentication (MFA). AWS account root users must be protected with due care and should be controlled by two people. For example, the individual or team that controls the root password of an AWS account should not also control its MFA token. Use a trusted password/privileged access management (PAM) solution to secure these secrets. Understand and periodically exercise the procedures for resetting AWS account root passwords and root MFA devices.

Add MFA immediately to all accounts that allow password-based login to AWS. Use your existing enterprise MFA solution, if possible. For AWS account root users and IAM-users;, configure MFA in AWS IAM. For federated users, configure MFA in your existing identity provider (IdP) or in AWS IAM Identity Center. Treat static AWS IAM credentials as toxic and prohibit them by default. People access AWS through federated authorization. Evaluate AWS IAM Roles Anywhere for on-premises or other non-AWS systems that need access to your AWS environment. Question vendors whose products require static IAM-users; and access keys; issue them only as a last resort and under a formal exception process, with automatic expiration.

Federation

To do anything in AWS, you first must grant access to the people who will build the foundation (landing zone) on which everything else is deployed. Federate your IdP with AWS. In this way, any adaptive authorization, entitlements management, compliance, and reporting capabilities associated with your IdP will apply to AWS as well. The recommended approach is to connect your IdP to AWS IAM Identity Center. AWS IAM Identity Center expands the capabilities of AWS Identity and Access Management (IAM) to centralize the administration of workforce access to AWS accounts. With Identity Center, you administer all human users and their permissions for your AWS Organizations in one place.

When enabled in your management account, AWS IAM Identity Center is deployed in the currently selected AWS Region only. This choice does not limit access to other AWS Regions. However, if your chosen Identity Center Region were unavailable, your users would be unable to access Identity Center to authenticate to AWS or other applications. Consider the risks of such an event and create a backup access plan that satisfies your resiliency needs.

Whatever federation solution you choose, you must define the job functions, roles, and responsibilities that team members will use to do their work in AWS. Start simple and iterate. In the beginning, no more than two to three roles should be necessary. If you use AWS Control Tower to deploy a landing zone (see the following section), you can get started by using its default roles. Keep in mind the YAGNI principle and resist the urge to create several job or task-specific roles until you know how they'll be used. Role and policy sprawl can quickly become technical debt that can weaken your security posture and complicate audit and compliance matters.

Landing zone

Each AWS account is a security boundary for the identities and resources that it contains. This is why you need a multi-account strategy as described in the AWS whitepaper Organizing Your AWS Environment Using Multiple Accounts. Create a landing zone by configuring a multi-account environment according to AWS best practices and your business requirements. Workloads are then deployed atop the landing zone.

For every AWS account in your landing zone, you'll need a consistent baseline configuration including a default set of permissions for people and services. Some elements of the baseline will be constants, but overall composition will vary depending on the purpose of the target AWS account. For example, non-production accounts should allow developers freedom to experiment, while production accounts should restrict all unnecessary services and actions. In either case, AWS CloudTrail should be enabled in every account, regardless of its purpose. Enforce using various types of AWS IAM policies that work together with orchestrated management.

The preferred way to deploy and manage your landing zone is using AWS Control Tower. Control Tower automates AWS account creation and baseline configuration. It gives you a practical set of default permissions to start, and consistent governance across all of your AWS accounts as your needs evolve. Follow guidance in this AWS whitepaper Organizing Your AWS Environment Using Multiple Accounts. This embodies AWS best practices based on years of feedback and learning from our most successful customers.

Guardrails

Service Control Policies (SCPs) are a powerful tool for simplifying permissions management across your AWS Organizations. SCPs restrict permissions at the AWS account level, unlike other IAM policies that apply to individual identities or resources. To make efficient use of SCPs, you must organize your AWS accounts in a hierarchy of organizational units (OUs) and apply SCPs to those OUs.

Use SCPs for coarse-grained controls that don't change often. SCPs can impact multiple AWS accounts, and modification requires access to the management account. Therefore, updates should be strictly controlled, tested to the extent practical, and relatively infrequent as mistakes could interrupt all users and workloads in the specific OU.

A good SCP use case is to restrict access to AWS Regions where your company doesn't operate. You can implement Regional restrictions directly in SCPs or use the Region Deny control in AWS Control Tower. Another good use of SCPs (and AWS Control Tower default) is to prevent local changes to resources that are deployed as part of your configuration baseline. Refer to AWS Control Tower recommended controls and AWS Organizations example SCP's documentation for more information.

Start using SCPs immediately. The risk of deploying major control changes via SCPs can be high, so it's best to start simple. Take an iterative approach to both the controls you implement and associated testing and deployment procedures. That way, when you need to make significant control change using SCPs, you'll have the mechanisms in place to do it safely and confidently.

Advance

Establish programs, procedures, and automation to govern identity and access management.

Metrics and monitoring

As soon as your initial landing zone is deployed, begin measuring your identity and access controls in AWS. Understanding current state (benchmarking) is the first step toward continuous improvement. It's important to measure cost-effectively, objectively, and consistently. Focus on fundamentals and measure things that are relevant to your security decision makers.

AWS Foundational Security Best Practices Standard (FSBP) is a good place to start. FSBP defines IAM best practice controls that should be monitored in all of your AWS accounts. Compliance with FSBP IAM controls alone is not sufficient. Non-compliance means that key controls are either missing or ineffective and in need of prompt attention. Monitoring FSBP compliance is a push-button operation in AWS Security Hub.

Create an AWS IAM Access Analyzer with your AWS Organization as the zone of trust, then monitor the findings. Access Analyzer findings show when your AWS resources grant access to external principals. In other words, Access Analyzer findings help you identify security risks due to unintended access.

An Access Analyzer finding indicates that the resource in the finding allows access to an external entity. (Access Analyzer findings do not tell you if external access has occurred.)This could be intentional, such as access granted to a vendor or partner, or it could be unintentional. It's important to investigate all active findings promptly so you can correct misconfigurations and prevent unauthorized access. Use archive rules to hide findings related to expected, authorized access.

Implement an organization-wide detective control that alerts on logins by AWS account root users. Triage each alert immediately. Any alert that can't be correlated to an approved change request should be escalated immediately to your security incident response team. Establish a program to remove all unnecessary root access, including weekly reporting and reviews by your CISO to drive compliance.

Security as code

Security as code (SaC) is an extension of the infrastructure as code (IaC) concept, which says that security controls are codified in templates and managed as software. When modified templates are committed, automation verifies, tests, and deploys the updated controls to your AWS environment in a reliable, repeatable way.

As reflected in the sample delegation model shown in Table 1 preceding:

• Developers manage IAM resources for their application as part of its infrastructure code.

• Separate, central teams manage IAM resources that span your AWS environment (for example, SCPs, permissions sets, baseline roles, and policies) as standalone workloads or as components of a security baseline workload.

This approach lets you apply consistent governance via continuous integration/continuous deployment (CI/CD) toolchain automation, without the concentration risk of a central team that creates or approves all AWS permissions. To begin, you must get all IAM resources (for example, roles, policies, service configurations, and others) codified and stored in an enterprise-managed version control system. Ideally, your version control system should support fine-grained access control, code review, approval workflows, and simplified CI/CD integration. Now that you're relying on a decentralized IAM model, use those features to implement preventive controls that enforce separation of duties and stop policy violations before they reach AWS.

For example, consider a version control repository that contains templates defining IAM policies/permission sets used by common roles in all your AWS accounts. Block all direct commits to the repository by default and require merge requests to be peer reviewed before being merged. Configure the merge process to initiate a pipeline that uses AWS IAM Access Analyzer policy validation to check the updated IAM policies, blocking the pipeline if problems are found. When the problems are resolved by a subsequent commit, the pipeline can continue through remaining stages and deploy the updated policies.

Permissions boundaries (PB) enable you to safely delegate authority over IAM roles. A PB is an advanced policy type that sets the maximum permissions available to an identity, regardless of what's allowed in any other attached policies. Because PB can be independently controlled, you can use them to enforce conditions that can't be overridden elsewhere by delegates. Prevent over permissive access creation by developers in the identity policies. Grant them permission to use IAM, but add conditions requiring attachment of a specific PB to any role they create or update. If the PB is missing, AWS IAM will prevent the change.

Use AWS Cloud Development Kit (AWS CDK) (CDK) to generate the roles and policies needed by your applications. You can attach a permissions boundary to all roles in an application with just a few lines of code. CDKs Construct Programming Model also lets you create a library of AWS resources customized to your security policies and environment, which developers can then consume as usual. Include cdk-nag rules in your constructs to encourage best practices. CDK is a powerful tool for decentralized governance enforcement.

Least privilege automation

At scale, least privilege is a pursuit that requires automation to drive continuous improvements. Take an iterative approach, using preventive and detective controls to rightsize permissions throughout your SDLC.

To refine permissions for a role, use AWS IAM Access Analyzer policy generation to generate a policy template based on the role's access history, as captured in AWS CloudTrail. Then use AWS IAM Access Analyzer policy validation in your CI/CD pipelines to validate policies against grammar and best practices, before deployment. Together, these features take the guesswork out of creating initial permissions and periodically rightsize them to maintain least privilege.

AWS IAM features like credential reports, last-accessed information, AWS CloudTrail integration, account summary, and account authorization details provide valuable data about identities, permissions, and access history in AWS. You can also collate, enrich, and analyze outputs using services like Amazon Athena, AWS Glue, and QuickSight to identify more opportunities to rightsize permissions and strengthen your security posture. Products from AWS Partners such as Sonrai Security and Ermetic can go further to produce sophisticated, identity, and access related insights that can help make faster, risk-informed decisions.

Excel

Focus on efficiency, continuous improvements, and operational excellence.

Zero Trust

AWS has long led with a Zero Trust approach to security, using Transport Layer Security (TLS) and SigV4 to authenticate and authorize every single API call, regardless of its origin. AWS capabilities enable you to implement Zero Trust concepts for your part of the AWS Shared Responsibility Model. But Zero Trust is not a universal solution. For more details:

• Read Zero Trust architectures: An AWS perspective (blog)

• Watch Zero Trust on AWS: Steve Schmidt, VP of Security Engineering & CISO, AWS (11:12) (video)

Security controls should be chosen based on the use case and business value of the assets to be protected.

Data perimeter

Build a data perimeter to protect your AWS accounts and resources. A data perimeter overlays your existing, fine-grained controls with coarse-grained ones that allow access only if a request exclusively involves trusted identities, trusted resources, and expected networks. To establish a data perimeter, implement preventive controls that restrict access from outside of your AWS Organizations boundary. Those permissions are applied primarily using SCPs, resource-based policies, and Virtual Private Cloud (VPC) endpoint policies. For detailed guidance and examples, see the AWS whitepaper Building A Data Perimeter on AWS.

ABAC

As you scale and implement more sophisticated authorization strategies, some permissions management use cases can be simplified by using attribute-based access control (ABAC). ABAC is part of IAM, and you can use ABAC, role-based access control (RBAC), or both together based on your needs. Implement ABAC in AWS by attaching tags to IAM entities like roles and users, and to resources like Amazon Elastic Compute Cloud (Amazon EC2) instances or AWS Key Management Service (AWS KMS) keys. Then write policies that allow or deny access, based on the values of those tags. In the case of a data perimeter, use ABAC to exempt specific users or roles from specific controls, without making high-risk policy changes.

If consistent resource tagging is already in place, ABAC will be easier to implement. Use tag policies and detective controls for enforcement. Don't wait until you need ABAC to get started with tag governance. With ABAC, tags are a key element of your authorization security controls. Implement trust policies over your IAM roles. Tag values can be set statically on IAM entities or you can use session tags to set values dynamically. For federated/human user access, AWS IAM Identity Center provides the most straightforward use of ABAC and session tags across all of your AWS accounts and Region