AWS Identity Health Checks

AWS recommends completing ten Identity health checks to improve security of your AWS accounts. ‘Identity’ is the system you use to authenticate users and authorize them access to the services and APIs needed to do their job. Completing these checks will help you understand your IAM health, prioritize improvements to your IAM implementation, and operationalize effective access management processes.

These health checks are the most important IAM jobs to be done when securing an AWS environment.

This article quickly explains the Ten identity health checks to improve security in the cloud from Cassia Martin’s talk at AWS re:Invent 2020 and links to deeper supporting materials.

Identity health check categories

Figure 1. AWS IAM health check categories

AWS groups the Identity health checks into three categories: 

• Build foundations for identity and access management
• Establish necessary IAM users and roles for people and applications
• Evolve IAM permissions towards least privilege

The Identity health checks

Let’s quickly define and explain each check.

Build Foundations

Identity Health Checks 1 through 3 build your identity foundation.  These checks and are generally performed once, when architecting and initially deploying your workloads. It’s common to improve the Service Control Policies in check 3 occasionally.

1 – Use multiple AWS accounts

Use multiple accounts to separate workloads by use case. Leverage the isolation granted by AWS account boundaries and centrally manage those accounts using policies in AWS Organizations.

2 – Create intentional organizational unit structure

AWS organizational units (OUs) should reflect your enterprise’s needs and management structure. Model your OUs and accounts as a hierarchical tree.  Use OUs to group AWS accounts for business units or related use cases together.  This helps you govern and protect your accounts with service control policies. 

Depending on how your enterprise works, you might create OUs for:

• Enterprise Central Services: security, audit, shared services, delivery
• per-Business Unit: accounts for each stage of software delivery

Checks 1 & 2 are closely related and very important. Learn how to organize Cloud accounts and create a strategy for isolating workloads if you have not done this yet. 

3 – Use service control policies

Setup Service Control Policies (SCPs) that establish guardrails for what can happen within an account in your organization.  SCPs are very powerful and limit what can happen by denying operations to all Account principals, even the root user.

Service Control Policies can be applied at any time and are often used to: 

• prevent use of non-compliant AWS services
• limit AWS deployments to specific regions
• prevent specific dangerous operations from occurring such as deleting databases in particular accounts

Establish Principals

Identity Health Checks 4-7 configure principals that use the account and how they will authenticate.  These checks are performed at initial deployment and as application workloads change.

4 – Secure root user

An AWS account’s root user is too powerful for everyday use.  Logging in with the root user should be done rarely, usually for ‘break glass’ scenarios dealing with major problems. Create IAM users and roles  with administrative privileges and use those instead of the root user.  Restrict root’s capabilities using SCPs, monitor root’s activity, and tightly control access.

5 – Federate identity for human users

Federate access from a corporate directory to AWS user identities using an identity provider or AWS Single Sign On (SSO). AWS SSO can connect to your existing identity source, including Active Directory and Okta, or you can create and manage user identities in AWS SSO’s identity store.

6 – Use roles

Strongly prefer creating and granting access to IAM roles for both people and applications. Avoid granting permissions to IAM users directly. Instead grant access to roles and enable users to assume roles, as appropriate. Roles used in this way enable least privilege access control and grant temporary, limited-privilege credentials. Federated access only works with roles.

7 – Validate trust policies

A trust policy is a security policy attached to an IAM role that allows another principal such as an IAM user or an AWS service like ec2 to use it. Only grant the ability for other principals to use your IAM roles if they need it, in accordance with Principle of Least Privilege. Avoid chaining or overloading roles.

Evolve Permissions

Checks 8-10 continuously review what principals are authorized to access.  It’s critical to track the effective change in permissions as policies, principals, and resources are created or changed. However, Cloud engineers evolving permissions may be overwhelmed analyzing access to hundreds of principals and thousands of resources in a given AWS account (details). k9’s monitoring service enables you to continuously complete the ‘Evolve Permissions’ Identity Health Checks quickly and with confidence.

8 – Continuously review your policies

Principals should have the least privilege they need to perform their function. Review each principal’s access and identify excess privileges. Excess privileges come in these forms:

• principal does not need access to the AWS service at all
• principal does not need all of the access it has to an AWS Service or resource, e.g. has privileges to read and write to S3, but only ever reads
• principal uses all its access capabilities, but the principal is overloaded and supports multiple distinct use cases with a single principal, e.g. all our API services execute with the same IAM role

Every principal access review should start with identifying principals with administrative access to IAM, which provides full control within the account.  A fine-grained review usually reveals unnecessary access to many specific actions or entire classes of actions. Avoid allowing service-name:* permissions.

9 – Audit IAM for unused principals

Identify and remove unused principals. Consider how long a principal needs to remain unused before action should be taken per your organization’s information security policy and compliance requirements.  Look for orphaned, outdated, or never-used IAM users and roles.  Actively used AWS accounts accrue unused principals quickly.  The portion of unused IAM principals in an account that is several years old is frequently 25% or more.

10 – Monitor your resource access

Discover which principals have access to a resource, not just which principals have already accessed that resource. Review resources that have a one-to-many relationship with principals and consider whether any of those relationships should be made one-to-one. Review principals with permission to access many resources.

Summary

These health checks describe the jobs to be done when architecting, engineering, and operating an effective AWS Identity management system. You should be able to plan and prioritize outstanding work for your own environments.

k9 Security is happy to help you on your journey.  Build your foundations and establish principals with the k9 Cloud Library (free) and professional services.  Evolve permissions using the access monitoring service and pre-built access management processes built and designed to scale in your organization.

Go Fast, Safely

We’d love to help you go fast, safely.  Learn how k9 simplifies AWS IAM security for the entire team or demo today.