Identity Management
There are two types of identities you need to manage when approaching operating secure AWS workloads.
-
Human Identities: The administrators, developers, operators, and consumers of your applications require an identity to access your AWS environments and applications. These can be members of your organization, or external users with whom you collaborate, and who interact with your AWS resources via a web browser, client application, mobile app, or interactive command-line tools.
-
Machine Identities: Your workload applications, operational tools, and components require an identity to make requests to AWS services, for example, to read data. These identities include machines running in your AWS environment, such as Amazon EC2 instances or AWS Lambda functions. You can also manage machine identities for external parties who need access. Additionally, you might also have machines outside of AWS that need access to your AWS environment.
Rely on a centralized identity provider: For workforce identities, rely on an identity provider that enables you to manage identities in a centralized place. This makes it easier to manage access across multiple applications and services, because you are creating, managing, and revoking access from a single location. For example, if someone leaves your organization, you can revoke access for all applications and services (including AWS) from one location. This reduces the need for multiple credentials and provides an opportunity to integrate with existing human resources (HR) processes.
For federation with individual AWS accounts, you can use centralized identities for AWS with a SAML 2.0-based provider with AWS IAM. You can use any provider—whether hosted by you in AWS, external to AWS, or supplied by the AWS Partner Network (APN)—that is compatible with the SAML 2.0 protocol. You can use federation between your AWS account and your chosen provider to grant a user or application access to call AWS API operations by using a SAML assertion to get temporary security credentials. Web-based single sign-on is also supported, allowing users to sign in to the AWS Management Console from your sign in portal.
For federation to multiple accounts in your AWS Organization, you can configure your
identity source in AWS Single Sign-On (AWS SSO)
AWS SSO integrates with AWS Organizations, which enables you to configure your identity provider once and then grant access to existing and new accounts managed in your organization. AWS SSO provides you with a default store, which you can use to manage your users and groups. If you choose to use the AWS SSO store, create your users and groups and assign their level of access to your AWS accounts and applications, keeping in mind the best practice of least privilege. Alternatively, you can choose to Connect to Your External Identity Provider using SAML 2.0, or Connect to Your Microsoft AD Directory using AWS Directory Service. Once configured, you can sign into the AWS Management Console, command line interface, or the AWS mobile app, by authenticating through your central identity provider.
For managing end-users or consumers of your workloads, such as a mobile app, you
can use
Amazon Cognito
Leverage user groups and attributes: As the number of users you manage grows, you will need to determine ways to organize them so that you can manage them at scale. Place users with common security requirements in groups defined by your identity provider, and put mechanisms in place to ensure that user attributes that may be used for access control (for example, department or location) are correct and updated. Use these groups and attributes to control access, rather than individual users. This allows you to manage access centrally by changing a user’s group membership or attributes once with a permission set, rather than updating many individual policies when a user’s access needs change. You can use AWS SSO to manage user groups and attributes. AWS SSO supports most commonly used attributes whether they are entered manually during user creation or automatically provisioned using a synchronization engine, such as defined in the System for Cross-Domain Identity Management (SCIM) specification.
Use strong sign-in mechanisms: Enforce minimum password length, and educate your users to avoid common or reused passwords. Enforce multi-factor authentication (MFA) with software or hardware mechanisms to provide an additional layer of verification. For example, when using AWS SSO as the identity source, configure the “context-aware” or “always-on” setting for MFA, and allow users to enroll their own MFA devices to accelerate adoption. When using an external identity provider (IdP), configure your IdP for MFA.
Use temporary credentials: Require identities to dynamically acquire temporary credentials. For workforce identities, use AWS SSO, or federation with IAM, to access AWS accounts. For machine identities, such as EC2 instances or Lambda functions, require the use of IAM roles instead of IAM users with long term access keys.
For human identities using the AWS Management Console, require users to acquire temporary
credentials and federate into AWS. You can do this using the AWS SSO user portal or
configuring federation with IAM. For users requiring CLI access, ensure that they
use AWS CLI v2, which
supports direct integration with AWS Single Sign-On (AWS SSO)
For cases where you need to grant consumers access to your AWS resources, use Amazon Cognito identity pools and assign them a set of temporary, limited privilege credentials to access your AWS resources. The permissions for each user are controlled through IAM roles that you create. You can define rules to choose the role for each user based on claims in the user's ID token. You can define a default role for authenticated users. You can also define a separate IAM role with limited permissions for guest users who are not authenticated.
For machine identities, you should rely on IAM roles to grant access to AWS. For EC2 instances, you can use roles for Amazon EC2. You can attach an IAM role to your EC2 instance to enable your applications running on Amazon EC2 to use temporary security credentials that AWS creates, distributes, and rotates automatically. For accessing EC2 instances using keys or passwords, AWS Systems Manager is a more secure way to access and manage your instances using a pre-installed agent without the stored secret. Additionally, other AWS services, such as AWS Lambda, enable you to configure an IAM service role to grant the service permissions to perform AWS actions using temporary credentials.
Audit and rotate credentials periodically: Periodic validation, preferably through an automated tool, is necessary to verify that the correct controls are enforced. For human identities, you should require users to change their passwords periodically and retire access keys in favor of temporary credentials. We also recommend that you continuously monitor MFA settings in your identity provider. You can set up AWS Config Rules to monitor these settings. For machine identities, you should rely on temporary credentials using IAM roles. For situations where this is not possible, frequent auditing and rotating access keys is necessary.
Store and use secrets securely: For credentials that are not IAM-related, such as database logins, use a service
that is
designed to handle management of secrets, such as AWS Secrets Manager
