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
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
Amazon GuardDuty
We recommend that you enable Amazon 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
Incident Response
Amazon Detective
We recommend that you designate one of your security tooling accounts as the
delegated administrator for Amazon
Detective
Data Protection
Amazon Macie
If you intend to use Amazon Macie
Infrastructure Protection
AWS Firewall Manager
If you intend to use AWS 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
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
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.
Example structure of Security OU
