AWS security audit guidelines

On a periodic basis. You should perform the steps described in this document at regular intervals as a best practice for security.

If there are changes in your organization, such as people leaving.

If you have stopped using one or more individual AWS services. This is important for removing permissions that users in your account no longer need.

If you've added or removed software in your accounts, such as applications on Amazon EC2 instances, AWS OpsWorks stacks, AWS CloudFormation templates, etc.

If you ever suspect that an unauthorized person might have accessed your account.

Be thorough. Look at all aspects of your security configuration, including those you might not use regularly.

Don't assume. If you are unfamiliar with some aspect of your security configuration (for example, the reasoning behind a particular policy or the existence of a role), investigate the business need until you are satisfied.

Keep things simple. To make auditing (and management) easier, use IAM groups, consistent naming schemes, and straightforward policies.

Review your Amazon S3 bucket policies and ACLs.

Review your Amazon SQS queue policies.

Review your Amazon SNS topic policies.

Review your AWS OpsWorks permissions.

Review your AWS KMS key policies.

Turn on AWS CloudTrail in each account and use it in each supported Region.

Periodically examine CloudTrail log files. (CloudTrail has a number of partners who provide tools for reading and analyzing log files.)

Enable Amazon S3 bucket logging to monitor requests made to each bucket.

If you believe there has been unauthorized use of your account, pay particular attention to temporary credentials that have been issued. If temporary credentials have been issued that you don't recognize, disable their permissions.

Enable billing alerts in each account and set a cost threshold that lets you know if your charges exceed your normal usage.

As a best practice, attach policies to groups instead of to individual users. If an individual user has a policy, make sure you understand why that user needs the policy.

Make sure that IAM users, groups, and roles have only the permissions that they need.

Use the IAM Policy Simulator to test policies that are attached to users or groups.

Remember that a user's permissions are the result of all applicable policies—user policies, group policies, and resource-based policies (on Amazon S3 buckets, Amazon SQS queues, Amazon SNS topics, and AWS KMS keys). It's important to examine all the policies that apply to a user and to understand the complete set of permissions granted to an individual user.

Be aware that allowing a user to create an IAM user, group, role, or policy and attach a policy to the principal entity is effectively granting that user all permissions to all resources in your account. That is, users who are allowed to create policies and attach them to a user, group, or role can grant themselves any permissions. In general, do not grant IAM permissions to users or roles whom you do not trust with full access to the resources in your account. The following list contains IAM permissions that you should review closely:

Make sure policies don't grant permissions for services that you don't use. For example, if you use AWS managed policies, make sure the AWS managed policies that are in use in your account are for services that you actually use. To find out which AWS managed policies are in use in your account, use the IAM GetAccountAuthorizationDetails API (AWS CLI command: aws iam get-account-authorization-details).

If the policy grants a user permission to launch an Amazon EC2 instance, it might also allow the iam:PassRole action, but if so it should explicitly list the roles that the user is allowed to pass to the Amazon EC2 instance.

Closely examine any values for the Action or Resource element that include *. It's a best practice to grant Allow access to only the individual actions and resources that users need. However, the following are reasons that it might be suitable to use * in a policy:

Examine policy names to make sure they reflect the policy's function. For example, although a policy might have a name that includes "read only," the policy might actually grant write or change permissions.

IAM Users and Groups in the IAM 用户指南.

Permissions and Policies in the IAM 用户指南.

IAM Roles (Delegation and Federation) in the IAM 用户指南.

IAM Policy Simulator in the Using IAM Policy Simulator guide.

Network and Security in the Amazon EC2 用户指南（适用于 Linux 实例）.

Demystifying EC2 Resource-Level Permissions on the AWS Security Blog.