|« PreviousNext »|
|Did this page help you? Yes | No | Tell us about it...|
This article presents a list of suggestions for using the AWS Identity and Access Management (IAM) service to help secure your AWS resources.
Any request you make for an AWS resource requires credentials so that AWS can make sure you have permission to access the resource. You can use access keys (an access key ID and secret access key) to make programmatic requests to AWS. However, we recommend that you do not use your AWS account access keys. The access key ID and secret access key for your AWS account give you access to all your resources, including your billing information. (For more information about credentials for working with AWS, see Types of Security Credentials in the Amazon Web Services General Reference.)
Therefore, protect your AWS account credentials like you would your credit card numbers or any other secret in these ways:
If you don't already have a set of access keys for your account, don't create them unless you absolutely need them. Instead, use your account password to sign in to the AWS Management Console and create an IAM user for yourself that has administrative privileges—see the next section.
If you do have a set of AWS access keys for your account, delete them. If you want to keep them, make sure that you rotate (change) the access keys credentials regularly. To delete or rotate your AWS account access keys, go to https://console.aws.amazon.com/iam/home?#security_credential and sign in with your account's email address and password. You can manage your access keys in the Access Keys section.
Never share your AWS account password or access keys with anyone. The remaining sections of this document discuss various ways to avoid having to share your account credentials with other users and to avoid having to embed them in an application.
Use a strong password to help protect account-level access to the AWS Management Console. For information about managing your AWS account password, see Changing Your AWS Account Password.
Enable AWS multi-factor authentication (MFA) on your AWS account. For more information, see Using Multi-Factor Authentication (MFA) Devices with AWS.
Don’t use your AWS root account credentials to access AWS, and don’t give your credentials to anyone else. Instead, create individual users (using the IAM console, the APIs, or the command line interface) for anyone who needs access to your AWS account. Create an IAM user for yourself as well, give that IAM user administrative privileges, and use that IAM user for all your work.
By creating individual IAM users for people accessing your account, you can give each IAM user a unique set of security credentials. You can also grant different permissions to each IAM user. If necessary, you can change or revoke an IAM user’s permissions any time. (If you give out your AWS root credentials, it can be difficult to revoke them.)
Before you set permissions for individual IAM users, though, see the next point about groups.
Instead of defining permissions for individual IAM users, it's usually more
convenient to create groups that relate to job functions (
Accounting, etc.), define the relevant
permissions for each group, and then assign IAM users to those groups. All the
users in an IAM group share the same permissions. That way, you can make changes
for everyone in a group in just one place. As people move around in your company,
you can simply change what IAM group their IAM user belongs to.
For more information, see the following:
When you create IAM policies, follow the standard security advice of granting least privilege—that is, granting only the permissions required to perform a task. Determine what users need to do and then craft policies for them that let the users perform only those tasks. Similarly, create policies for individual resources (such as Amazon S3 buckets) that identify precisely who is allowed to access the resource, and allow only the minimal permissions for those users. For example, perhaps developers should be allowed to write to an Amazon S3 bucket, but testers only need to read from it.
It’s more secure to start with a minimum set of permissions and grant additional permissions as necessary, rather than starting with permissions that are too lenient and then trying to tighten them later.
Defining the right set of permissions requires some research to determine what is required for the specific task, what actions a particular service supports, and what permissions are required in order to perform those actions.
A good way to start is to use the built-in policy templates in the console. These templates include predefined permissions for common use cases (administrator, power user, etc.) in individual services.
You can also create custom policies that set permissions precisely. When you do, you need to be familiar with how Allow and Deny work in policies, and how policies are evaluated when more than one policy is in force during a request for a resource. (In cases where the right combination of permissions is complex, it can be tempting to loosen up the permissions—even to grant "all access" privileges—to make sure users have access to resources. But we do not recommend this approach; as noted, standard security advice is to grant least privilege.) You’ll also need to test thoroughly to make sure that users can do their work and that policies are working as you intend.
For more information, see the following:
If you allow users to change their own passwords, make sure that they create strong passwords. In the Password Policy section of the IAM console, you can choose options for password policy, such as the password’s minimum length, whether it requires a non-alphabetic character, and so on.
For more information, see Setting an Account Password Policy for IAM Users.
For extra security, enable multi-factor authentication (MFA) for privileged IAM users (users who are allowed access to sensitive resources). With MFA, users have a device that generates a unique authentication code (a one-time password, or OTP) and users must provide both their normal credentials (like their user name and password) and the OTP. The MFA device can either be a special piece of hardware, or it can be a virtual device, such as an app that runs on a smartphone.
For more information, see Using Multi-Factor Authentication (MFA) Devices with AWS.
Applications that run on an Amazon EC2 instance need credentials in order to access other AWS services. To provide credentials to the application in a secure way, use IAM roles. A role is an entity that has its own set of permissions, but that isn't a user or group. Roles also don't have their own permanent set of credentials the way IAM users do. Instead, a role is assumed by other entities. Credentials are then either associated with the assuming identity, or IAM dynamically provides temporary credentials (in the case of Amazon EC2).
When you launch an Amazon EC2 instance, you can specify a role for the instance as a launch parameter. Applications that run on the EC2 instance can use the role's credentials when they access AWS resources. The role's permissions determine what the application is allowed to do.
For more information, see Granting Applications that Run on Amazon EC2 Instances Access to AWS Resources.
You might need to allow users from another AWS account to access resources in your AWS account. If so, don’t share security credentials, such as access keys, between accounts. Instead, use IAM roles. You can define a role that specifies what permissions the IAM users in the other account are allowed, and from which AWS accounts IAM users are allowed to assume the role.
For more information, see Cross-Account Access: Sharing Resources Between AWS Accounts.
Change your own passwords and access keys regularly, and make sure that all IAM users in your account do as well. That way, if a password is compromised without your knowledge, you limit how long the password can be used to access your resources.
To make it easier to rotate credentials, let your users manage their own passwords.
For more information, see Rotating Credentials.
To the extent that it's practical, define the conditions under which the policy allows access to a resource. For example, you can write conditions to specify a range of allowable IP addresses for a request, or you can specify that a request is allowed only within a specified date range or time range. You can also set conditions that require the use of SSL or MFA. For example, you can require that a user has authenticated with an MFA device in order to be allowed to terminate an Amazon EC2 instance. The more explicitly you can define when resources are available (and otherwise unavailable), the safer your resources will be.
For more information, see Condition.
The following video includes a conference presentation that covers these best practices and shows additional details about how to work with the features discussed here.