Security OU - Organizing Your AWS Environment Using Multiple Accounts

Security OU

The Security OU is a foundational OU. Your security organization should own and manage this OU along with any child OUs and associated accounts.

We recommend that you create the following accounts in the Security OU:

  • Log archive

  • Security tooling

  • Security read-only access

  • Security break-glass

Depending on your initial requirements, you might not need to establish all of these accounts. See Patterns for organizing your AWS accounts for example sets of OUs and accounts that are commonly used in the early stages of adopting AWS.

Log archive account

The log archive is an account that acts as a consolidation point for log data that is gathered from all the accounts in the organization and primarily used by your security, operations, audit, and compliance teams.

For example, in this account, we recommend that you consolidate AWS API access logs recorded in AWS CloudTrail, logs of changes to AWS resources recorded in AWS Config, and other logs that have security implications. If you use VPC peering between accounts, then you might also benefit from consolidating VPC Flow Logs data in this account.

It’s a common practice to integrate this consolidated log data with a security information and event management (SIEM) solution.

If you are using AWS Control Tower to manage your overall AWS environment, then CloudTrail is automatically enabled in each account, and the CloudTrail logs are consolidated in an Amazon S3 bucket in a Log archive account.

Operational log data

Operational log data used by your infrastructure, operations, and workload owning teams often overlaps with the log data used by security, audit, and compliance teams.

We recommend that you consolidate your operational log data into the log archive account. Based on your specific security and governance requirements, you may need to filter operational log data saved to this account. You may also need to specify who and what has access to the operational log data in the log archive account.

Immutable log data

Log data housed in the log archive account is considered immutable in that it is never changed.

Managing access to this account

We strongly recommend that you only house log data in this account and refrain from also including workloads in this account that act on the log data. By doing so, you can greatly limit access to this account.

Workloads and tools that need to consume the consolidated log data are typically housed in your other accounts and are granted cross-account access via IAM roles to access the log data in a read-only, least privileged manner.

Security tooling accounts

We recommend the use of one or more security tooling accounts to contain broadly applicable security-oriented workloads in the form of security services, tools, and supporting data. The number of security tooling accounts you choose to use should be based on taking into consideration the Design principles for organizing your AWS accounts.

Common examples of AWS services

Common examples of security capabilities and AWS services that can be centrally accessed and managed via security tooling accounts include:

Detection

AWS Security Hub

We recommend that you enable AWS Security Hub across all of the accounts in your AWS organization. You can specify one of your security tooling accounts as the delegated administrator for Security Hub.

Amazon GuardDuty

We recommend that you enable Amazon GuardDuty across all of the accounts in your AWS organization. You can specify one of your security tooling accounts as the delegated administrator for GuardDuty.

AWS Config

We recommend that you configure an AWS Config aggregator in one of your security tooling accounts so that you have an aggregated view of your AWS resources, your AWS Config rules, and the AWS resources’ compliance state.

Identity and Access Management

IAM Access Analyzer

We recommend that you use IAM Access Analyzer configured with the entire AWS organization as the zone of trust so that it’s easier for you to quickly look across resource policies and identify resources with public or cross-account access you may not intend. We recommend that you configure this analyzer in one of your security tooling accounts.

Incident Response

Amazon Detective

We recommend that you designate one of your security tooling accounts as the delegated administrator for Amazon Detective, Amazon GuardDuty, and AWS Security Hub. By doing so, you can take advantage of the integration between these services.

Data Protection

Amazon Macie

If you intend to use Amazon Macie across your AWS organization, we recommend that you specify one of your security tooling accounts as the delegated administrator for Macie.

Infrastructure Protection

AWS Firewall Manager

If you intend to use AWS Firewall Manager across your AWS organization, we recommend that you specify one of your security tooling accounts as the delegated administrator for Firewall Manager.

Third-party cloud security monitoring tools

You can also house third-party cloud security monitoring services and tools in your security tooling accounts. For example, these accounts typically contain security information and event management (SIEM) tools and vulnerability scanners.

Automated detection and response workflows

Automated detection and response workflows that act on data collected through these types of services are normally contained in your security tooling accounts.

Incident response (IR) support

Tools to support manual incident response (IR) procedures are typically housed in your security tooling accounts.

See the AWS Security Incident Response Guide for more information.

Security team access

Security team members need access to these services and applications on a day-to-day basis to interact with and potentially configure features of the security services and tools. This access should be minimal and scoped to the needed actions (for example, viewing or acting on the security tool’s console or dashboard).

Where possible, we recommend that your security team use infrastructure-as-code (IaC) techniques to automate the underlying configuration of services and tools residing in your security tooling accounts.

Security read-only access account

In support of auditing, exploratory security testing, and investigations, your security team members will need read-only access to accounts in your AWS environment when centrally located logs and other instrumentation is insufficient.

A common approach is to use federated access to provide direct read-only access to your accounts. With direct federated access to your AWS accounts, you do not need to use a security read-only access account.

However, if you prefer to use cross-account roles instead of direct federation, then we recommended that you use this security read-only account. For example, in the early stages of investigating a suspected security incident, your security team members first access this account and use a read-only IAM cross-account role to access other accounts to review and monitor the state of resources.

Typically, this account does not contain persistent workloads. Rather, team members exclusively use this account to interactively access other accounts.

If you plan to use a security read-only account, we recommend that you use federated access to this account for your security team members. Once your security team members access this account via federated access, it’s recommended that cross-account IAM roles be used to provide security team members cross-account access to each account of interest.

Security break-glass account

In support of security incidents and exceptional cases in which your standard access mechanisms are not available, you should have a process by which authorized administrators can temporarily gain required access to your accounts.

Depending on your overall process for providing authorized administrators with temporary break-glass access to your accounts, you may not need a security break-glass account. However, if your overall break-glass process involves use of cross-account roles, you may benefit from using a security break-glass account.

Such an account is rarely used, but is available to members of your security and operations teams to enable extensive write access to your accounts when standard access mechanisms are not available. Special authorization is required for security and operations team members to gain access to this account at the onset of an incident, and all account access is logged in detail. Once an incident has been resolved, the temporary access to this account is revoked.

Typically, you create any supporting tools required in this account on-demand using automation and subsequently remove those supporting tools after an incident is resolved.

Example structure

The following example structure represents the recommended separation of production workloads and resources from non-production through Prod and Test child OUs.

Example account names are shown with qualifiers -test and -prod. The -test qualifier denotes a non-production environment. The -prod qualifier denotes stable, production quality environments for a given capability or workload. A -prod qualifier does not imply that the capability or workload environment is limited to servicing only other production quality capabilities or workloads.

For example, the account represented by the example name log-archive-prod is expected to be the consolidation point for all log data across all accounts. It is simply your stable, production quality form of the log archive capability.

Similarly, use of the -prod qualifier on the other accounts is not intended to constrain the applicability of those accounts to production environments.

Depending on your own cloud resource naming conventions, you may choose to not apply a qualifier to the names of AWS accounts containing your stable, production quality capabilities and workloads.

The following example includes a security-tooling-test account or environment in which you might test and validate new and modified resource configurations before those changes are promoted to your security-tooling-prod account.

For general guidance on separating production and non-production workloads, see Organizing workload-oriented OUs.


          This image shows an example security OU structure with accounts.

Example structure of Security OU