Securing AWS accounts with IAM is very important to ensure the AWS accounts created are safe. The following are recommendations to secure your AWS accounts, especially the root account.
1. Using a group email address instead of an individual email address for the root account (if possible)
Securing the root account. An email account is required to create the root account for a new account. Unless this is a personal account, ideally the email address is a distribution list that is made up of multiple people’s email addresses. This will reduce to risk of delays in responding to emails sent.
2. Use a complex password for the root account
The security of your account’s root user depends on the strength of its password. A complex password is a must. The complex password should be at least 30 characters long and contains numbers, upper case letters, lower cases and non-alphanumeric characters. Use a password manager such as Lastpass, Dashlane, Keeper to generate and store the passwords.
3. Enable multi-factor authentication using a hardware device for the root account
A hardware-based MFA is crucial to secure the root account. AWS support multiple hardware devices from Thales or U2F security key from Yubikey. Although virtual MFA applications exist such as LastPass Authenticator, Microsoft Authenticator or Google authenticator for the root account hardware-based MFA is preferred. If hardware devices are used, check the battery life of these devices. If virtual MFA applications are used ensure that adequate protection is enabled on the mobile device also usually not enabled by default. LastPass Authenticator and Microsoft Authenticator supports this.
4. Ensure the root access has no access key assigned to it
Root account access key grants full access to all your resources for all AWS services, including your billing information. These keys are the keys to the kingdom as far as your AWS account is concerned. So it is crucial not to have them.
5. Limit the use of the root account and instead use other IAM users for day to day stuff
Ideally, the root account also is used only for specific tasks and not for day-to-day operations. Create normal IAM users with the appropriate roles and permissions to perform the tasks required.
There are also specific tasks that require the root user to be used such as:
● Changing the accounts settings such as account name, email address, root user password, and root user access keys.
● Restore IAM user permissions if no IAM administrator exists (deleted by mistake or IAM permissions were revoked by mistake),
● Enable IAM access to the Billing and Cost management console
● Terminate and close the AWS account
● Change or cancel the Support plan
● Signup for Govcloud
● Register as a seller in the Reserved instance marketplace
● Configure MFA delete for your S3 bucket
● Edit or delete S3 bucket policy with invalid VPC id or VPC endpoint ID
6. Ensure Root accounts usage is logged and notifications are configured
Since the root account is used for ’emergencies’ or specific tasks it is important to track the actual account usage. Using Cloudwatch events, any root user activity can trigger a Lambda function to publish a message to SNS topic which will send an email notification to the subscribers of the SNS topic.
7. Restrict console access from specific IPs
Restricting access by source IP can be useful if any user accounts credentials are stolen. IP addresses can be spoofed but at least try to minimize the risk
8. Ensure dormant users are at least disabled or even better deleted
Any not active users should be disabled or deleted. AWS provides a credential report to verify non-active credentials. The important fields to check from the credential report are:
● Password_enabled
● Password_last_used
● access_key_1_active & access_key_2_active
● access_key_1_last_used_date & access_key_2_last_used_date
The number of days for the password last used and access_key_1_last_used_date & access_key_2_last_used_date should be less than X number of days defined.
Recommended Dates: (Check the security policies associated with your organisation)
For highly sensitive environments 30 days (or even less)
For medium secure environments 45-60 days
For less secure environments 75-90 days
To generate the credential reports click
9. Ensure security contact is enabled in all accounts
Any important security notifications will use this security contact. If there was a security breach or potential security issue, timely action is required therefore the use of the security contact is crucial to be set similarly to the Billing and operations contacts.
To activate the security contact click on the account name details from the top right-hand corner and click on the Account menu
The next step is to click edit in the Alternate Contacts section and fill in the details required and click update
10. Ensure the security challenge questions are properly done
In eventually owner identification is required, the security challenge questions are needed. Similarly to the security contacts, these are required and can be configured in another section from the step 9 procedure. It is important that such details are saved in a password manager
11. Ensure a proper IAM password policy is set up.
A password policy will ensure complex passwords are used by the local accounts created. Depending on the security policy set by the organisation different settings may be used. Personally, I recommend at least the following:
To set the password policy from the IAM console click Account setting and in the password policy section choose change password policy
12. Ensure only the appropriate required permissions are configured to use the least privilege possible for users and roles
There are a number of roles and policies pre-configured but it is important to use the least privileged approach. Using the AdministratorAccess policy grant you full access to all services. In practice, I am not using a particular service but I still have access since I am using the AdministratorAccess.
If in practice, I need only route53, Cloudfront, WAF, Shield, Cloudwatch and support, a group is created with the associated required policy only. This will ensure only the required services are allowed. The same principle can also be applied to roles.
For groups use-case: Choose user groups
Choose create group
Enter the group name and add users to the group and in the Attach permission policies add the required policies
For our use case search for route53 choose the required policy (will use AmazonRoute53FullAccess and select it. Repeat the process for all the services required.
Once finished attaching all the policies click create group
For the roles use-case, the process is very similar, click the role option and choose the required AWS service, verify the permission required and click create role at the end of the wizard. If the service is not listed you can use the Custom trust policy
Select the use case
13. Enable identity providers to authenticate users
For a small organisation with a small number of accounts, account management can be manageable but having a lot of accounts, account management can become a nightmare. Having centralised authentication mechanisms such as Azure AD, Okta, Active directory, Ping Identity will serve the purpose. AWS support SAML and Openid connect.
