Best Practices with IAM
While IAM in AWS provides many exciting capabilities, its complexity can cause organizations to make fatal mistakes when working with the service. This section highlights some best practices that can save you from making such mistakes.
You should consider following most (if not all) of these recommendations:
Use the root account for as little as possible: This is the account you established when you signed up for AWS. The root account is the all-powerful administrator account: It has the power to delete the whole AWS account! In addition to being able to delete (cancel) the AWS account itself, the root account might be needed to change account settings, restore IAM user permissions, activate IAM access to the Billing and Cost Management console, or sign up for AWS GovCloud. You should therefore use it as infrequently as possible. A best practice is to create AWS admin accounts of varying privilege levels and use them instead of using the root account.
Store root user access keys securely: You have already seen how important it is to use the root user account for your AWS implementation infrequently. In addition, it is critical that you protect the access key ID and secret access key for this account. You must ensure that you have these credentials protected in your own infrastructure and treat them with the utmost care. In fact, in a high-security environment, you should consider not defining access keys for the root account. Instead, use the email address, a complex password, and physical multifactor authentication instead for the rare times this account must be used.
Create individual IAM users: Because it is a best practice to use the root account for your AWS implementation infrequently, it is critical that you create additional user accounts, including one for yourself so that you are not left using the root account. In larger organizations, you will have a large team working on AWS. You must create multiple accounts for your staff to ensure that everyone is authenticating and being authorized for only those resources and permissions that are required for the members to do their jobs. You will most likely have at least one account in IAM for every person who requires administrative access.
Use groups to assign permissions to IAM users: Even though it might seem silly, if you are the sole administrator of your AWS implementation, you will want to create a group and assign permissions to this group. Why? If you ever need to grow and hire another administrator, you can just add that user account to the group you created. You always want your AWS implementations to scale, and using groups helps ensure scalability. It should also be noted that applying permissions to groups instead of to individual user accounts will help eliminate assignment errors, as it minimizes the number of permissions you must grant.
Use AWS-defined policies for permissions: Amazon was very kind in defining a ton of policies you can easily leverage when working with IAM. What’s more, AWS maintains and updates these policies as it introduces new services and API operations. The policies that AWS has created are defined around the tasks you most commonly need to perform. They make up an excellent starting place for your own policies. You can copy a given policy and customize it to make it even more secure. Oftentimes, you will find that the default defined policies are too broad with access.
Grant the least privileges possible: One reason you are likely to end up with many different accounts for yourself in AWS is that you always want to sign in with the account that provides the least privileges for what you are trying to accomplish. That way, if an attacker manages to capture your security credentials and begins acting as you in the AWS architecture, they can do a limited amount of damage. For example, if you need to simply monitor the files in AWS S3 buckets, you can use an account with only read permissions on these buckets. This would certainly limit the damage an attacker could carry out if they obtained your credentials.