In this post, we discuss a recent change from AWS which allows for updating the root user email address for any member account that are attached to an AWS Organization. Along with the associated security considerations of that change.
What’s new?
AWS recently announced the ability to centrally manage the root email addresses of member accounts within the AWS Organizations service using the AWS CLI, SDK, or console.
Previously, administrators had to log as the existing root user into each account individually to update the root email. This update enables root email changes from the management account and I quote “makes it easier for AWS Organizations customers to centrally manage the root email address of member accounts.”
Indeed, it simplifies this type of change. However, it highlights the importance of managing user access control for the Management Account, given that it now grants privileged permissions across all member root user accounts where it is likely your production applications and data reside.
Why is this change important?
Securing access to an AWS Management account is crucial as it serves as the gateway to your entire AWS environment. The management account holds the authority to control permissions, create or delete accounts, and manage billing for all AWS resources in your organization. If compromised, malicious actors can gain unrestricted access to sensitive data, modify critical configurations, or disrupt services.
Below, I have outlined some approaches for reducing that risk.
Role based access control (RBAC)
So, what is RBAC? RBAC operates on several core principles, which aim to enhance security and simplify user access management:
- Roles: Permissions are assigned to roles rather than individual users. Roles reflect job functions (e.g., admin, developer)
- Users: Individuals or systems are granted roles based on their responsibilities
- Permissions: Defined actions (read, write, execute) are associated with each role, specifying what resources a role can access
- Separation of Duties: Critical tasks are divided among different roles to minimize risk
- Least Privilege: Users are granted the minimum access necessary to perform their role
In order to reduce the attack surface and risks associated with privileged user access to the AWS Management Account it is crucial that:
- Role based access control is implemented within the business
- Privileged role access to the AWS Management Account is restricted to the minimum amount of trusted employees.
- The user accounts of those trusted employees have strong controls in place
- Consider taking it to the next level with a “Two-person authentication” policy!
Security Controls 101
To enhance security of your AWS Management Account that are some simple approaches that can be applied to user access, including:
- Enforcing strong password policies
- Enabling multi-factor authentication (MFA)
- Regularly rotate access keys
- Monitoring access logs and alerting of suspicious activities
However, how do we protect against internal threats?
Two-person authentication
Consider implementing a policy for the Management Account which requires “Two-person authentication” (TPA). TPA requires that two authorized individuals jointly complete a sensitive action or session to access critical systems. It may sound an extreme approach, but consider that privileged access to the management account permits the user the ability to access and decommission all services and data within all member accounts
For example, within your organisation, each (granted) engineer has access to their own IAM credentials (username / password) for accessing the management account as part of their role. However, the MFA device* associated with their IAM user is only available to the companies InfoSec Governance Board. A privileged engineer requires a second person to authenticate the access, ensuring oversight and reducing the risk of fraud, mistakes, or malicious behavior. This method increases security by introducing accountability and reducing insider threats.
*For additional auditing and accounting, the (soft) MFA device can be stored in a solution such as 1Password so we can track accessing the OTPs for all members of that InfoSec Gov. board.
How to change the root user email address of a member account…
If you are ready to proceed making the change to the member account, step by step guide is included below.
A how to guide, using the Console UI
Here’s how you can update the root user email of a member account using the AWS Organizations console:
- Sign in as the root user of the management account in your organization or as a user with equivalent IAM permissions.
- Navigate to the AWS Accounts page and select the member account whose email needs updating.
- In the Account Details section, choose Actions and select Update Email Address.
- Enter the new email address, after which AWS will send a One-Time Password (OTP) to that email. Once you receive the OTP, enter it in the Verification Code field to complete the update.
A how to guide, using the CLI and SDK Options
For users who prefer to use automation tools, AWS offers the ability to update root emails via the AWS CLI or SDKs. These options are particularly useful for organizations that want to incorporate email updates into their infrastructure as code (IaC) pipelines.
The key commands include:
- GetPrimaryEmail: Retrieve the root user email
- StartPrimaryEmailUpdate: Initiate the update process by sending an OTP to the new email
- AcceptPrimaryEmailUpdate: Complete the process by verifying the OTP
References
Announcement – Centrally manage member account root email addresses across your AWS Organization
Documentation – Updating the root user email address for a member account with AWS Organizations
About
With over 20 years in the technology sector, Keith has spent the last decade providing consultancy, support, and strategic direction to customers across multiple cloud platforms.
Disclaimer: The information shared on this blog is for informational purposes only and should not be considered as professional advice. The opinions presented here are personal and independent of any affiliations with tech companies or organizations.