Root Account Protection

Avoid the use of root

It is recommended to avoid using the root user, and root account in multi-account scenarios, except in cases where it is strictly necessary.

The recommendation is to use a Centralized user repository such as AWS Directory Services (Active Directory / SimpleAD), Active Directory on EC2, Okta, PingIdentity, Azure Active Directory, OneLogin. If you don’t currently have a user repository, it’s preferable to use IAM users than using root until the directory is implemented, but keep in mind that IAM users are not a best practice, as they may not be removed when the employee is terminated, and the Access Keys associated to IAM users are durable credentials that you have to periodically rotate.

It is advisable to audit your root account usage via AWS CloudTrail and generate usage alerts with Amazon Simple Notification Service (SNS) notifications.

Limit root usage to administrative tasks that require root credentials:

  • User management - Emergency
  • Payment Options
  • Change Support Plan
  • Billing Information
  • Update Contact Information…

Centralize or disable the use of Root

You can centralize the use of root removing the need to manage and protect root accounts on member accounts. This way you will only have to secure one root account with MFA and other best practices mentioned here. Centralize Root

Alternatively you can disable deny all actions of the root accounts of member accounts using AWS Control Tower: Disabling Root using Control Tower

or using Service Control Policies (SCPs) 

 
{
  "Version": "2012-10-17",
  "Statement": [
    {
    "Sid": "RestrictRootOnMemberAccounts",
    "Effect": "Deny", 
    "Action": "*", 
    "Resource": "*", 
    "Condition": { "StringLike": { "aws:PrincipalArn": [ "arn:aws:iam::*:root" ]} }
    }
  ]
}

Additional Best Practices for root

  • Remove Access Keys (you should never enable access keys on root, as they are unrestricted - Not aligned with least privilege)

  • Create alerts for root usage: as root usage should be avoided, we recommend you to set up alerts when root logs in.

  • The management account (org root) is not affected by Service Control Policies (SCPs), therefore it’s critical to implement MFA on root in the management account, ideally with two-person controls, having one person that knows the password, and another that has access to the MFA device (ideally a hardware token, or access to the device with the TOTP/Authenticator app). Be sure to limit who has physical access to the second factor.

  • By configuring MFA on root you will also be strenghtening the bypass procedures (“MFA device is lost or stops working”). See also the Security contracts recommendation

How to check

Risk Mitigation

  • [Credential Access] An unauthorized user that compromised the organization’s mail server may attempt to reset root passwords to gain access to your AWS Accounts, unless they are disabled or protected with MFA.
  • Accountability: It’s harder for investigators to identify who was root at a given time.
  • By definition root is not compliant with least privilege, daily/frequent usage of root increments the probability of an unauthorized user gain those credentials and cause more damage than a limited user.

Guidance for assessments

  • Are you regularly using root ? any access key configured to the root users?
  • Are you using any kind of vault for storing root credentials ? what are you using ?
  • Are all permissions on root accounts blocked with AWS Control Tower or SCPs ?

More details in the documentation: