AWS Identity and Access Management Security Guidelines
AWS Identity and Access Management (IAM) is an AWS service that helps control access to AWS resources. There are three fundamental processes for secure identity and access management:
- Authentication – Who can use your AWS resources?
- Authorization – What resources they can use and in what ways?
- Accounting – Who did what?
Best practices for Authentication
- Remove access keys from root account – The root account has unrestricted access including billing information, and these permissions can’t be modified. That means that anyone who has the access keys of the root account has the keys to the castle.
- Remove unnecessary passwords and access keys – Access keys are usually required by applications, so passwords can be removed from application users. Also, users don’t usually require access keys, so they can be removed as well. Tip: When creating new users, always remove the “Generate an access key for each user” option.
- Use IAM roles instead of access keys – When your application requires access to an AWS service and runs on an AWS EC2 instance, assign a role to the instance and grant it the permissions that the application requires. Tip: When launching an EC2 instance, always assign a role (without any permission) in case it will be needed in the future. Otherwise, you will be forced into creating a new instance and terminating the old one which requires some downtime, or use access keys which are insecure.
- Enable Multi-factor Authentication (MFA) for all users – with MFA, users have a virtual token (e.g. Google Authenticator) or physical token that generates a one-time password. When users log in, they have to provide the one-time password in addition to their password.
- Identity Provider
- Use Identity Federation –Provides single sign-on and identity management for cloud-based applications. Recommended services: Onelogin, Okta, Ping Identity. These services support MFA as well.
- Use AWS Directory for AWS user management – Sign in to AWS applications using your Active Directory credentials. There are several available options in AWS:
- AD Simple – supports basic AD features, including user accounts, group memberships, domain-joining EC2 instances, Kerberos-based SSO and GPO.
- Microsoft AD – Provides many Microsoft AD features including adding trust relationships.
- AD Connector – This service is an Active Directory proxy for your on premise AD.
- Configure a strong password policy – The following is our recommended configuration:
- Minimum password length: 8
- Require at least one uppercase letter, lowercase letter, number and non-alphanumeric character
- Allow users to change their own password
- Enable password expiration. Period: 90 days
- Prevent password reuse. Number of passwords to remember: 4
- Use Cross-Account Access roles instead of sharing access keys– In case you need to allow users from another AWS account to access your AWS account, don’t share any credentials. You can use Cross-Account access roles to allow access.
Best practices for Authorization
Use groups to assign permissions to users instead of defining permissions for individual users. Recommended groups are:
- Admins – Permission name: AdministratorAccess. Provides full control to AWS console except billing. Users in this group should be aware of their capabilities and responsibility.
- PowerUsers – Permission name: PowerUserAccess. Similar to AdministratorAccess but lacks IAM permissions. Most Admins don’t require creating or modifying users, so this group should be more appropriate then Admins.
- ReadOnlyUsers – Permission name: ReadOnlyAccess. Add users to this group when they don’t require making any changes in your environment.
Use IAM policy conditions to allow access during specific hours, or from specific IP ranges.
In general use the least privilege principle. Users and roles should be granted with only the necessary permissions that are required to carry out specific operations. This is especially important in production environments. E.g. If an application requires only writing files to a specific S3 bucket, allow only the PutObject action on the specific S3 bucket, rather than allowing any action on that S3 bucket, or granting the AmazonS3FullAccess permission.
Best practices for Accounting
Avoid using the root account and accounts that are used by applications- This guarantees that each action will point to a specific person.
Don’t share credentials between users. Each user is accountable for his own account.
Enable Cloudtrail on all regions – Cloudtrail records all actions taken via the AWS Management Console, AWS SDKs or AWS CLI. This allows you to investigate security issues, resource change tracking, spikes in AWS bill and compliance auditing.