Tackling MFA for AWS Organization Member Accounts
With the recent advice published by AWS around best practice for MFA on AWS Organisations (not a typo :AU: :wink:) management and member accounts, I thought it would be a good chance to write up how I tackled this is a previously and hopefully provide some guidance for others.
It’s interesting how quite a simple process in nature does become quite manual when you need to protect these much like you would master encryption keys, for example.
What was most pleasing to see was that our approach in the most part, tightly aligns with the new recommendations.
Goals
The goals of the process are to securely setup root accounts on all AWS Organisation Member Accounts with -
- strong passwords
- assigned to group email addresses (routed to Security Team)
- Virtual MFA assigned
- with all sensitive details secured in relation to their data classification and CIA requirements. (more on this below)
Preparation
To achieve the goals listed above, you’re going to need the following, or at least in our case, this was our approach.
- 1Password/KeePass/BitWarden or another password management system where you have access to the password DB/vault. Cloud hosted Password Management is an option, however not recommended for this data classification.
- Multiple (at least 4) secure, waterproof, shockproof etc USB drives
- A Virtual MFA tool, Authy etc.
- RBAC NTFS/OneDrive etc storage
- Secure physical storage, safe, bank vault, offsite secure server room etc
- Access to a printer
Threat Modelling
So, what exactly are we trying to prevent here? The goal is to ensure that even if some got either -
- Access to the password vault, or
- Access to the MFA virtual seeds
That they would not have access to both to enable a successful root login on an AWS Account.
So, to prevent this, we need to make sure the above is
- segregated (priority)
- protected
- secure
We also want to prevent (DR/BCP) loss if our office is destroyed due to fire/natural disaster etc.
So, to prevent this, we need to make sure that we have the above, but also replicated securely off site.
Process
If you are dealing with ‘lots’ of new root accounts to secure, you are very likely using Landing Zone or Control Tower. Either way, it doesn’t really matter, let’s just assume you are about to login to the root account for the first time and setup MFA, this is where the process begins.
Prepare KeePass/Password Vault
I would highly recommend a new password vault, specifically for AWS Root Account Credentials only.
Goes without saying, but a very strong Master password should be used.
Print the Emergency Sheet
Fill out the details here, include the RBAC protected network location, and the physical location where the manual backups will reside.
Always plan for human error. Call out what this database is for and what is not be stored here. You can also set your default user name for new entries, as this will be root for everything, will save you a few seconds per entry.
Again, tooltips wherever possible are a good idea.
Start adding your entries
This will generally follow the standard process for an initial root user login. Submit a password reset to the associated email, pass the captcha, etc etc.
Generate your secure password in KeePass, copy it, then save the KeePass entry.
Set the password on root user via the AWS console. Then navigate to IAM.
Next, move to set your Virtual MFA (if you company has a policy that you must set a hardware MFA for root users, then this wont apply) and ensure you click,
“Show secret key for manual configuration”
Take this value, and add it to a .txt / .csv with the following information.
| Account # | Account Name | Account Email | MFA Seed | --------------------------------------------------
12345678 | lz_log_archive | security+lz_log_archive@mydomain.com | 098789287597453
87654321 | lz_security | security+lz_security@mydomain.com | 6544646465498744
Next add the seed to Authy/MFA tool, generate the 2 Authentication Codes and ensure MFA is activated correctly. Once you have the MFA activated and the seed recorded, you can safely remove the token from the MFA tool itself. Hopefully, you’ll never need it.
Rinse and repeat as required/necessary.
You may have only a few accounts, or you could have hundreds, regardless, a consistent format is key if you ever need this account information.
Wrapping up, securing and segregating.
You should now have the following artefacts to secure.
- Password Vault — stored securely on a RBAC NTFS/One Drive etc and USB. Also the KeePass safety sheet — PDF on the same USB and printed copies in case of USB corruption
- .txt with MFA Seeds — Stored on a 2nd USB key and printed in case of USB corruption
There is really only one rule here — separate these artefacts physically and securely.
Again, if on network/cloud storage, strong RBAC must be applied. For the physical assets, make sure they are secured in places that are locked down to only those require it, server rooms, safes, lockable cabinets etc. When in doubt, refer to your Information Classification policy or similar, or talk to your Security team, threat model it with our requirements from earlier in mind.
The image below shows some possible scenarios.
Help! I need to login as root..
No problems.
I’ll assume that you have access to the password vault on NTFS/Cloud Storage etc, so therefore all that is required is to.
- retrieve password from the vault above
- retrieve the associated virtual MFA seed from a secured USB drive. Fire up Authy, re-add the token. Delete after use.
The rest of this process is really only there in case your office is destroyed/not accessible or file and USB corruption occurs.
Other
Put this to the pub test, is there anything here you think could be improved or anything that could potentially be dangerous, let me know in the comments!
Lastly, a reminder of why your root account should be secured, locked and only used in the following scenarios.
- Change your account settings.This includes the account name, email address, root user password, and root user access keys. Other account settings, such as contact information, payment currency preference, and Regions, do not require root user credentials.- View certain tax invoices. An IAM user with the aws-portal:ViewBilling permission can view and download VAT invoices from AWS Europe, but not AWS Inc or Amazon Internet Services Pvt. Ltd (AISPL).- Close your AWS account.- Restore IAM user permissions. If the only IAM administrator accidentally revokes their own permissions, you can sign in as the root user to edit policies and restore those permissions.- Change your AWS Support plan or Cancel your AWS Support plan. - Register as a seller in the Reserved Instance Marketplace.- Configure an Amazon S3 bucket to enable MFA (multi-factor authentication) Delete.- Edit or delete an Amazon S3 bucket policy that includes an invalid VPC ID or VPC endpoint ID.- Sign up for GovCloud.
