Security OU – Log Archive account - AWS Prescriptive Guidance

Security OU – Log Archive account

Survey

We would love to hear from you. Please provide feedback on the AWS PRA by taking a short survey.

The Log Archive account is where you centralize infrastructure, service, and application log types. For more information about this account, see the AWS Security Reference Architecture (AWS SRA). With a dedicated account for logs, you can apply consistent alerting across all log types and to confirm that incident responders can access an aggregate of these logs from one place. You can set up security controls and data retention policies all from one place as well, which can simplify the privacy operational overhead. The following diagram illustrates the AWS security and privacy services that are configured in the Log Archive account.

AWS services deployed in the Log Archive account in the Security organizational unit.

Centralized log storage

Log files (such as AWS CloudTrail logs) might contain information that could be considered personal data. Some organizations choose to use an organization trail in order to aggregate CloudTrail logs across AWS Regions and across accounts into one central location, for visibility purposes. For more information, see AWS CloudTrail in this guide. When implementing centralization of CloudTrail logs, the logs are typically stored in an Amazon Simple Storage Service (Amazon S3) bucket in a single Region.

Depending on your organization's definition of personal data, your contractual obligations to your customers, and applicable regional privacy regulations, you might need to consider cross-border data transfers when it comes to log aggregation. Determine if the personal data within the various log types falls under these restrictions. For example, CloudTrail logs might contain your organization's employee data, but they might not contain your customers' personal data. If your organization needs to adhere to restricted data transfer requirements, the following options can help support:

  • If your organization is providing services in the AWS Cloud to data subjects in multiple countries, you might choose to aggregate all logs in the country that has the most stringent data residency requirements. For example, if you're operating in Germany and it has the most stringent requirements, you might aggregate data in an S3 bucket in the eu-central-1 AWS Region so that data collected in Germany doesn't leave the borders of Germany. For this option, you can configure a single organization trail in CloudTrail that aggregates logs from across all accounts and AWS Regions into the target Region.

  • Redact the personal data that needs to stay in the AWS Region before the data is copied and aggregated to another region. For example, you can mask the personal data in the application's host Region before you transfer the logs to a different Region. For more information about masking personal data, see the Amazon Data Firehose section of this guide.

  • If you have stringent data sovereignty concerns, you can maintain a separate multi-account landing zone in the AWS Region that enforces these requirements. This way, you can simplify the landing zone configuration in the Region for centralized logging. It also provides additional infrastructure segregation benefits and helps keep log local to their own Region. Work with your legal counsel to determine which personal data is in scope and which Region-to-Region transfers are allowed. For more information, see Strategizing for global expansion in this guide.

Through service logs, application logs, and operating system (OS) logs, you can use Amazon CloudWatch to monitor AWS services or resources in their corresponding account and Region by default. Many choose to centralize these logs and metrics from multiple accounts and Regions into a single account. By default, these logs persist in their corresponding account and Region where they originate. For centralization, you can use subscription filters and Amazon S3 export tasks to share data into a centralized location. It might be important to include the proper filters and export tasks when aggregating logs from a workload that has cross-border data transfer requirements. If the access logs of a workload contain personal data, you might need to make sure that these are transferred to or retained in specific accounts and Regions.

Amazon Security Lake

As recommended in the AWS SRA, you might want to use the Log Archive account as the delegated administrator account for Amazon Security Lake. When you do this, Security Lake collects supported logs in dedicated Amazon S3 buckets in the same account as other SRA-recommended security logs.

From a privacy perspective, it is important for your incident responders to have access to logs from your AWS environments, SaaS providers, on premises, cloud sources, and third-party sources. This helps them more quickly block and remediate unauthorized access to personal data. The same considerations for log storage most likely apply to log residency and Regional movement within Amazon Security Lake. This is because Security Lake collects security logs and events from the AWS Regions in which you've enabled the service. To comply with data residency requirements, consider your configuration of rollup Regions. A rollup Region is a Region where Security Lake consolidates data from one or more contributing Regions, which you select. Your organization might need to align on your Regional compliance requirements for data residency before you can configure Security Lake and rollup Regions.