Companies beginning to move their workloads into the Amazon Web Services typically start by creating an AWS account and beginning to develop. The downside to this approach is that the company ends up with multiple accounts owned by business units that are either not centrally managed or the extreme opposite — everything in one account with it being only a matter of time before someone interrupts another team’s project. Neither of these scenarios are ideal.
In addition to cost allocation, the use of multiple Amazon Web Services accounts should be a default consideration for any company planning on managing production workloads in the cloud. AWS describe the multiple account strategy in the context of a billing strategy, but I urge for the investigation of Organizations as a technical and operational investment of your time.
Walking through an account’s lifecycle, we start with creation. With the use of Organizations from the billing account, child accounts can be created without the requirement of going through the new account setup. The use of the CLI allows the create-account call to spawn new accounts. By the addition of the --create-role switch, a role is created that can be assumed from the Org billing account. Think of this as a break-glass. Creating accounts like this leaves the root password unset. Failure to set the root password will allow setting the password by anyone with access to the email address. The recommendation here would be to reset the password and enable MFA until AWS allow for better management of root access for Organizations-created accounts.
The distribution of workloads into separate accounts provides for distribution of risk. Acting as a hard boundary for access within AWS, accounts provide for segmentation. This separation prevents unintentional development changes from affecting production environments. Equally as important, in the event of a compromise, it functions as another layer of security towards defense-in-depth. Further aggregation of logs by use of a centralized logging account provides log integrity and availability, as the beginnings of a single collection of data which will be useful for analytics and monitoring in the future.
Now that the account has been created, use CloudFormation, CLI, SDK, etc. to deploy well-designed governance and security controls. While Organizations is not a requirement for CloudFormation, the use of the Organizational Units allows for easier mass deployments and differing levels of standards for each OU. (Seen screenshot below.) Reference the AWS Multi Account Billing Strategy for more details on ideas of how to set up the OUs.
In addition to organization and deployment of governance and standards, Organizational Units enable the use of Service Control Policies. These are like IAM policies for accounts. These allow administration of what services and actions are allowed and denied with granularity, but do not grant those permissions to any entities in the account. This can be used as IAM guardrails. An example of this would be denying the permission to StopLogging on the CloudTrails named a specific way as seen below.
{
"Sid": "DenyStopLoggingCloudTrail",
"Effect": "Deny",
"Action": "cloudtrail:StopLogging",
"Resource": "arn:aws:cloudtrail:*:*:trail/Security-*-CloudTrail"
}But before going and implementing the example above, Organizational-level CloudTrail has made it obsolete. When creating a CloudTrail from the Organizations billing account, the console offers another option:
Programmatically, the inclusion of the --is-organization-trail switch on the create-trail CLI command will also accomplish this (when executed from the Organizations account).
As the number of accounts grows, the use of account tags within the service provides further data about the accounts that may have been previously kept outside of the service that created them. Being able to make changes based on these tags provides another method for organizational-wide changes. Without going into much detail, the tags provide addition metadata on each account that allows a determined script ninja to cut through and execute commands from the Organizations account at a scale which should require change management.
Upon creation, an Organization is given a 12-digit, alphanumeric ID starting with o-, which can be used as a logical identifier for conditions in resource policies. A use case for this would be providing a centralized S3 bucket for providing CloudFormation templates. That bucket policy could provide access to * as long as the condition included “StringEquals”: {“aws:PrincipalOrgID”: “o-abc123def4”} without ever triggering a Public evaluation. Hopefully we will see this functionality extended to individual OUs as well. This prevents the need to include new accounts as principals in policies on resources that are intended to provide access to all accounts.
Implementation of Organizations shouldn’t be looked at as a task intended for large organizations, but instead viewed as another service AWS has created to address an issue their existing customers have expressed.
From my experiences, I’d like to provide some guidance:
- Naming conventions are essential. As you deploy governance and security controls across multiple accounts, think about how these will can be referenced in IAM policies for denying access to these centrally deployed resources (i.e. Names of CloudFormation StackSets, standard IAM roles, Lambdas executing Security Operations tasks).
- Design a simple Organizational Units strategy early. OUs are not like Microsoft OUs. Keep it simple. Refer back to the AWS Multi Account Billing Strategy for examples and recommendations from AWS.
- Whitelist for added control. By default “FullAWSAccess” is a *:* SCP that allows all accounts to have access to all services and actions. As AWS roll out new service, these services will be allowed with no restrictions and prior to your ability to evaluate their ability for exploitation (intentionally or not).
- Do not rely on a hardware MFA token. Use an off-cloud system to store the root passwords and QR codes. Use of a credential manager that provides an audit trail would be ideal. Make sure that the passwords and MFA code are rotated upon their very rare use.
