Security OU and accounts
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
Depending on your initial requirements, you might not need to establish all of these accounts. Refer to 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. This account contains a centralized storage location for copies of every account’s audit, configuration compliance, and operational logs. It also provides a storage location for any other audit/compliance logs, as well as application/OS logs.
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.
Logs should generally be made directly available for local use by teams working in any account on a shorter-term retention basis. It is common practice to auto-ingest logs from the log archive account into a security information and event management (SIEM) solution.
If you are using AWS Control
Tower
Services in the Log Archive account
With Amazon Security Lake, you can automatically centralize security data from AWS and third-party sources into a data lake that's stored in your Log Archive account. Review Managing access in this account in the following sections to learn how to grant access to the logs from other accounts in your AWS organization.
Logs should generally be made directly available for local use by teams working in any account on a shorter-term retention basis. It is common practice to auto-ingest logs from the log archive account intoa 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 might need to filter operational log data saved to this account. You might 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 protected from being changed or deleted. Data retention policies and legislation that apply to your organization might also apply to the data in your log archive account.
Managing access to this account
We strongly recommend that you only house log data in this account and refrain from also including any workloads in this account, including workloads that act on the log data. By doing so, access to this account can be greatly limited.
Workloads and tools that need to consume the consolidated log data are typically housed in your other accounts and are granted cross-account access through read-only IAM roles to access the log data in a read-only, least privileged manner.
Additionally, to ensure log data is properly protected, we recommend SCPs be applied to the Security OU preventing modification or deletion of files within the centralized logging S3 bucket(s). Additionally, the use of S3 bucket versioning provides visibility into the complete history of all log files.
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. When considering the number of security tooling accounts to use, consider the Design principles for organizing your AWS accounts.
In the context of AWS services, this account is used to provide centralized delegated
admin access to AWS security tooling and consoles, as well as provide view-only access
for investigative purposes into all accounts in the organization. The security tooling
account should be restricted to authorized security and compliance personnel and related
security. This account is an aggregation point (or points for organizations that split the
functionality across multiple accounts) for AWS security services, including AWS Security Hub
Common examples of AWS services
Common examples of security capabilities and AWS services that can be centrally accessed and managed using 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.
-
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 Amazon Macie.
Note
In many cases, it makes the most sense that you specify the same security tooling account for most AWS security services including: Security Hub, GuardDuty, Amazon Macie, AWS Config, Amazon Detective, Amazon Inspector, and IAM Access Analyzer. It also often makes sense to use the same delegated admin account for Firewall Manager. However, we’ve seen cases where firewall management capabilities are assigned to a different security team.
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 might 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
-
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. Refer to 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 view-only access
In support of auditing, exploratory security testing, and investigations, your security team members will need view-only access to accounts in your AWS environment when centrally located logs, AWS security tooling consoles, and other instrumentation are insufficient. View-only access does not allow mutating API calls and is different from read-only access in that does not provide access to any data.
A common approach is to use direct federated access
However, use cases exist where using cross-account roles is preferable, including when using AWS security tooling such as Amazon Detective. In these cases, using a view-only role which is only accessible from the Security tooling account is recommended. For example, in the early stages of investigating a suspected security incident, your security team members first access this account and use a view-only IAM cross account role to access other accounts to review and monitor the state of resources.
If you plan to use a security read-only account, we recommend that you use federated access to access 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.
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 might 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 resources.
For general guidance on separating production and non-production workloads, refer to Organizing workload-oriented OUs.
Example structure of Security OU
