alphaspirit - Fotolia
AWS root account access is a treasure for attackers
Don't fall victim to a hacked root account. Create and work within new AWS accounts, and then apply the least amount of privilege necessary to prevent a costly mistake.
Every day, an AWS user falls victim to the simple human fault of inattention. You don't want to be that person, so make AWS root account security a top priority.
AWS makes it easy to create an account; just enter your email and credit card information, and after a few clicks, it's ready to go. AWS doesn't require customers to sign a contract or undergo a lengthy approval process. Account setup takes minutes to complete, and AWS accounts can belong to the finance department, senior management or anyone else with access to a company credit card.
While account creation is almost effortless, it does not diminish the accompanying responsibility to secure those accounts. An AWS root account has unlimited access and control, and the person who creates the account becomes the root user for it. This root user poses a great risk. An IT staff member -- preferably one with AWS experience -- should support the initial account creation and setup. The business should also follow these best practices to reduce risk and fully secure an AWS root account.
When to use -- and not use -- an AWS root account
The root user account is not recommended for any daily tasks. Ideally, the IT organization does not use a root account after the initial setup is complete. Best practices dictate that you only use the root account to create a first user with administrative privileges and provide that account with all the necessary permissions for its purpose. After that, IT teams should secure and store the root account and only use it when specifically required, such as to modify an AWS support plan, payment options and user details -- email and password -- or to terminate the account.
To prevent an AWS root account from being compromised, avoid using root access keys, which facilitate programmatic access for teams that rely on AWS software development kits, representational state transfer APIs or Query API operations. Instead, create access keys for an AWS Identity and Access Management (IAM) user, and give them the least amount of necessary privileges. That way, if your keys end up in the wrong hands, they will have limited capability to do harm.
Keep a close eye on the root account -- if you must use it
If you use the root account regularly, audit that account activity as if your job depended on it. To audit the root and IAM accounts, enable AWS CloudTrail logging, and designate a Simple Storage Service bucket to store logs. CloudTrail logs provide the history of API calls in an AWS account.
Some services, such as an Auto Scaling group and Elastic Load Balancing, use the root to access resources in an account. When that occurs, the name of the service appears in the invokedBy field of the CloudTrail log.
Whether or not you use a root account on a regular basis, enable multifactor authentication for better AWS account authority. This provides the user with additional security and ensures that if an unauthorized person obtains your root password, the account stays secure.
Lost credentials and compromised accounts
It's bad when you lose root account credentials; passwords are recoverable. But a compromised root account can be catastrophic, endangering or even shutting down the business.
If someone gains access to your AWS root account and locks you out with a password change, there isn't much that can be done except to contact AWS support. It can take as much as 48 hours to recover your account, which gives a malicious actor time to cause irreversible damage. The attacker could delete resources and backups and ensure complete data loss. The attacker could also start multiple expensive instances -- such as the P2 type, which costs between $0.90 and $14.40 per hour -- in various regions and let them run to rack up charges. AWS adheres to a shared responsibility model that clearly places credential management responsibility on its customer. It's up to you, and you alone, to use best practices to protect AWS accounts.
