In my previous post, I went into several best practices to deploy in your AWS account that add security to your account from the start. In this post, I'll be digging into some ideas that assist you to secure IAM even further. These Items continue to build an IAM security framework in AWS.
What user account do I log in with?
AWS root user account is not an account for everyday use. THE recommended first step to secure your AWS account is to create new a IAM user and use this new account for daily tasks.
Do not share the root credentials. Lock the root credentials away and only use them as a break glass or when you need to perform root functions. Schedule a recurring meeting on your calendar for reviewing AWS credential reports. The purpose of these audits is to confirm no one is logging into the root account.
Log in with an IAM user account with MFA, How to enable MFA, and least privileges.
A great idea for the root account's email address:
You are almost done with deploying best practices on the root account.
In your organization create an email distribution list for your cloud security alerts ex: CloudSecurityAlerts@secframe.com. Add the members of the security team to this distribution list. For every AWS account created in your environment, set the root email address as an alias on the distribution list. If someone attempts to change the password on any root AWS account, the entire security team gets alerted through this distribution list. If there are alerts sent by AWS to the root account, the entire security team gets alerted.
Who gets an account?
Each individual using AWS will have at least one account. In most scenarios, you will see that one user maps to one IAM user account. 4 Reasons she needs an admin account is a great post that goes into criteria for creating accounts for Active Directory. It can be used as a good framework for when people need accounts with privileges.
In more advanced AWS environments a best practice to deploy is to create a read-only account for a user to log into. When a person wants to make changes in AWS, they change or 'assume' a privileged role.
If you ever need more assistance finding administrators throughout your organization, you can always for help. For a list of all users created in IAM with a certain role, I created a script for that. To a detailed guide on the code, please read "Get All AWS Admins with Powershell"
Shared user accounts
There is no scenario where it is OK to share an IAM user across teams. If you have these users in your accounts, they often look like networkAdmin, DbaAdmin, or AccountsAdmin. You need to enforce that each individual person using AWS gets a unique IAM user. Each user turns on MFA.
If there is a network administrator who needs access to AWS, he gets a user. If network admin #2 needs to do work in AWS, she gets a separate account. With this standard, each individual action performed in AWS is tied back to an individual user.
How should you name IAM users in your environment?
Start by creating a naming standard. With a standard in place, it is easy for any auditor to find out which IAM user ties to which person at your company. If your business has a naming standard in place for users, you can easily piggyback off that. If you need a place to start and want some help leading the discussion.
Often the naming convention at organizations combine first and last name and/or employee numbers. Here are a few naming standards for our favorite employee at secframe, John Smith employee ID # 1234
|First initial + last initial + employee id||JS1234|
|First name + _ + last name||John_Smith|
|First initial + last name||JSmith|
|Company Initials + Employee ID||SF1234|
Prevent password reuse attacks
IAM users should have unique passwords different from their network logins. Having unique passwords for different applications your organization removes risk from password reuse attacks. NIST and Microsoft have great guidelines in place about their policy on passwords. In my Microsoft Password Policy Post, I go into some great detail on the topic. Please read that for further details.
What happens if you name an IAM user the same as your root account?
When you create a new IAM user, do not give that user the same exact name as your root email address.
Let's play out a scenario: Admin John Smith at SecFrame.com decides to create an AWS account. He sets up the AWS account using his work email 'email@example.com'. He created his first IAM user for himself named 'firstname.lastname@example.org'.
John logs out of the root account and attempts to log back into AWS with the IAM user. The username he created for this user is identical to the root user account. When he logs in and runs a credential report, he sees that the IAM user has never logged in. This is because when you use the same account name for an IAM user as the root user, the root user account takes precedence and the login occurs as the root user.
If you want to discuss what benefits you might get from an AWS security roadmap please continue reading with my AWS Security Guide or please contact me: