When a partner moves their existing accounts to a distributor to gain financial and operational benefits via distribution, the financial responsibility and risk moves over to the distributor. To be able to cover this risk, the distributor requires full access to the Payer account. This article will cover how to delegate access in a secure and financially responsible manner.
- When a partner moves their existing accounts to a distributor to gain financial and operational benefits via distribution, the financial responsibility AND risk moves over to the distributor.
- To be able to cover this risk, the distributor requires full access to the Payer account, including root user access.
- By attaining root access, the distributor ensures that the required finance control access and data (which is core to their business) is reliably available to them.
- Moreover, some task (managing support level on behalf of partner) require root user access as well.
- The issue is with the newly granted root account access, guidance is needed on how a distributor can manage said access and delegate credentials to the Payer accounts in a way that adheres to AWS best practices. This blog post will address this concern with prescriptive guidance on how to delegate access in a secure and financially responsible manner.
Standard Guidance for Distributors with Customers/Distribution Sellers Requesting Root
While the Distribution Program requires the Payer account to be owned by the Distributor, some customers need to have or maintain ownership of the Program Management Account due to security requirements even if this means that the Distributor (1) exposes its billing and margin, (2) is at risk of getting locked out of accounts for which they are financially responsible and (3) become noncompliant with program terms.
In order to address customer concerns regarding security, partners can enable the following:
Two-Factor Authentication on the Payer Account
With this option, the Distributor would own the email address for the Payer account and the customer would own a Multi-Factor Authentication device (YubiKey, RSA, etc.). The Distributor would have an IAM Billing Admin login to access details for re-billing while the partner would use IAM from a security point of view to manage organisations. (For information and instructions on access via Admin Role see https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html)
Anytime the root account has to be accessed, both parties would have to engage with one another. It is worth noting that there are very few actions that require root access (see https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html ) and this list is even shorter for Payer accounts, since they are usually non-production accounts.
The partner signs a services agreement directly with AWS (either the click-through Customer Agreement or a negotiated Enterprise Agreement). In this arrangement, the Distributor leverages the end customer account model (ECAM) so that child accounts are owned by the customer. This arrangement, however, would still require that the Distributor own the Payer account.
- NOTE: Account ownership across many AWS groups including the Support and Strategic Customer Engagements teams will include a cross-check of a matching email domain with the Distributor. This means that Distributors engaged in support or private pricing deals will be expected to demonstrate ownership of accounts by, among other things, ensuring the email domain associated with the Payer account belong to the Distributor.
Setting Permission Boundaries
Under the stipulations of the Distribution Program Agreement, if the Distributor maintains administrator privileges, the partner may ask for Admin level permissions within the Program Management Account account albeit as mentioned earlier, the likelihood is rare.
For these scenarios, the distributor can give Admin level permissions to the partner for the operation of majority of resources, but may need to limit some permissions for example: the ability to view certain distribution specific files in S3, or even restricting access to certain views of Cost Explorer that show defaults. In addition, the distributor needs to account for the possibility where the distributor has a governance tool running that is part of their contract with the partner that they need to make sure the partner does not have capability to remove.
Using permissions boundaries to limit the scope of the “admin” users created for the partner, and to limit their ability to escalate privileges (create a new admin) helps give the customer access needed to AWS Organisations while ensuring Distributor sensitive information can be kept only to the root user and distributor created IAM entities.
To use permissions boundaries to limit the scope of IAM users and roles and prevent privilege escalation, please review the blog post: https://aws.amazon.com/blogs/security/when-and-where-to-use-iam-permissions-boundaries/ It includes the use of IAM policies to restrict access to permitted services on AWS through the use of Deny rules for alteration of privilege and to restrict specific billing access privileges to specific user groups.
AWS Reference Guide: Best practices to protect your account's root user
Very few tasks require root, and it should be used only when it is necessary to monitor the root activity or send out alerts. Kindly refer to this Reference Guide: https://docs.aws.amazon.com/accounts/latest/reference/best-practices-root-user.html for more information
Optional: Github Reference Design and Code to Monitor Root Activities
Refer to this code repository https://github.com/aws-samples/aws-iam-root-user-activity-monitor to create a monitoring system to track the activities made by the IAM root user. It helps distributors to set up a hub-and-spoke solution to monitor multiple AWS accounts under the distributor and centralises management and reporting in a single account aka the hub account.