AWS Feed
AWS CloudTrail Best Practices
AWS CloudTrail gives you a history of AWS calls for your account, including API calls made through the AWS Management Console, AWS SDKs, and command line tools. As a result, you can identify:
· Which users and accounts called AWS APIs for services that support CloudTrail.
· The source IP address the calls were made from.
· When the calls occurred.
CloudTrail is enabled on your AWS account when you create it and provides an event history of account activity from the past 90 days. AWS recommends that you create a trail to archive changes and activity in your AWS environment. That way, you can store the API events as logs in a secure, immutable format to be used for later analysis. These logs are stored in an Amazon Simple Storage Service (Amazon S3) bucket that you specify. By delivering ongoing events to S3, you can retain events for more than 90 days. This long-term visibility is crucial for security breach reviews, proactive monitoring, and efforts to meet compliance standards.
In this blog post, I will share best practices for using CloudTrail to enable auditing across your organization.
Configure CloudTrail in all AWS accounts and Regions
To get a complete record of events taken by a user, role, or service in AWS accounts, configure each trail to log events in all AWS Regions. Set up these trails in every AWS account used by your company or organization. This setup ensures every event is logged, regardless of the AWS Region where the event occurred. As a result, you can detect unexpected activity in otherwise unused Regions. Global service events (for example, AWS Identity and Access Management and Amazon Route 53) are also included and logged. If you create a trail that applies to all Regions, any new AWS Region is included automatically. If you have a multi-account setup through AWS Organizations, you can create a trail that logs all events for all AWS accounts in that organization.
Set up separate trails for different use cases
CloudTrail supports use cases such as auditing, security monitoring, and operational troubleshooting. AWS recommends that you set up multiple trails for each use case so that you can provide each team with the knowledge they need. To do this, create trails for different users to manage. The trails can be configured to deliver log files to separate S3 buckets. For example, a security administrator can create a trail that applies to all Regions and encrypt the log files with one AWS Key Management Service (AWS KMS) key, and enable log file validation. A developer at the same company can create a trail that applies to one Region only and configure Amazon CloudWatch alarms to receive notifications of specific API activity.
Turn on data events for trails
Data events provide visibility into the resource operations performed on or in S3 and AWS Lambda. These events are also known as data plane operations. Data events are often high-volume activities, especially if you are storing sensitive data on S3 or have key business operations occurring through Lambda functions. Visibility into any unexpected access to sensitive data lets you take corrective action to protect your data. Because some compliance reports (for example, FedRAMP and PCI-DSS ) require data events to be turned on, AWS recommends that you use AWS Config managed rules or an appropriate Conformance Pack Sample Templates to check that at least one trail is logging S3 data events for all S3 buckets. For more information, see Logging data events for CloudTrail in the AWS CloudTrail User Guide.
Configure CloudTrail logs to be delivered to an S3 bucket in a separate security boundary with limited access (a separate AWS account)
For auditing purposes, when you store log files in a dedicated S3 bucket in a separate administrative domain, you can enforce strict security controls and segregation of duties. Restricting access to this S3 bucket will decrease the chances of unauthorized and unfettered access to the logs. When you have these controls in place, if any AWS account credentials become compromised, the logs won’t be lost because they are stored in a separate domain. For more information about setting up a separate AWS account for this purpose, see Receiving CloudTrail Log Files from Multiple Accounts in the AWS CloudTrail User Guide.
Enable MFA-delete and versioning on the Amazon S3 Bucket storing log files
With multi-factor authentication (MFA) configured on this S3 bucket, you can ensure that additional authentication is required to permanently delete the bucket or an object in the bucket. In addition to MFA, versioning-enabled buckets can help you recover objects from accidental deletion or overwrite. For example, if you delete an object, Amazon S3 inserts a delete marker instead of removing the object permanently. Even though most AWS users and admins do not have any malicious intent, somebody could accidentally delete an S3 bucket that stores critical log files. When you add these safeguards, you can decrease the risk of compromised log files. For more information, see Adding a bucket policy to require MFA and Using versioning in S3 buckets in the Amazon S3 User Guide.
Enable CloudTrail log file integrity validation
CloudTrail log file integrity validation lets you know if a log file has been deleted or changed. You can also use this validation to confirm that no log files were delivered to your account during a given period. These insights are valuable in security and forensic investigations. They provide an additional layer of protection to ensure the integrity of the log files. CloudTrail log file integrity validation uses industry standard algorithms: SHA-256 for hashing and SHA-256 with RSA for digital signing, which makes it computationally unfeasible to modify log files without detection. For more information, see Enabling Validation and Validating Files in the AWS CloudTrail User Guide.
Encrypt CloudTrail log files at rest
By default, the log files delivered by CloudTrail to your bucket are encrypted by Amazon server-side encryption with Amazon S3-managed encryption keys (SSE-S3). To provide a security layer that is directly manageable, you can instead use server-side encryption with AWS KMS-managed keys (SSE-KMS) for your CloudTrail log files.
Use advanced event selectors with data events
When you use data events, advanced event selectors offer more granular control of data event logging. With advanced event selectors, you can include or exclude values on fields such as EventSource
, EventName
, and ResourceARN
. Advanced event selectors also support including or excluding values with pattern matching on partial strings, similar to regular expressions. This provides more control over which CloudTrail data events you want to log and pay for. For example, you can log S3 DeleteObject
APIs to narrow the CloudTrail events you receive to only destructive actions to identify security issues while controlling costs. Keep in mind that when you use CloudTrail for auditing, it is a best practice to record all data events. However, when you use data events for operational monitoring or other use cases, advanced event selectors can be very helpful.
Integrate CloudTrail with Amazon CloudWatch Logs
Amazon CloudWatch helps you collect monitoring and operational data in the form of logs, metrics, and events. When you integrate CloudTrail with CloudWatch Logs, you can monitor and receive alerts for specific events captured by CloudTrail in near real time. For example, you can set up alarms and notifications for anomalous AWS API activity. For more information, see Creating CloudWatch alarms for CloudTrail events: examples in the AWS CloudTrail User Guide.
When you integrate CloudTrail with CloudWatch Logs, you can also visualize data produced by CloudWatch Insights. These insights allow you to extract the data you need, which simplifies the process of querying. For example, you can use CloudWatch Logs to stream the logs to Amazon Elasticsearch Service in near real time, and then access the Kibana endpoint to visualize the data.
Use CloudTrail Insights to monitor anomalous API activity
AWS CloudTrail Insights helps AWS users identify and respond to unusual activity associated with API calls by continuously analyzing CloudTrail management events. If you have CloudTrail Insights enabled and CloudTrail detects unusual activity, Insights events are delivered to the destination S3 bucket for your trail. You can also see the type of insight and the incident time period. Unlike other types of events captured in a trail, Insights events are logged only when CloudTrail detects changes in your account’s API usage that differ significantly from the account’s typical usage patterns. CloudTrail Insights events are also sent to CloudWatch Events, and optionally to an CloudWatch log group, just like other CloudTrail events. This logging gives you automation options for alerting (for example, custom AWS Lambda functions). As a result, you can ensure that your teams stay informed of any unusual API activity.
Use AWS Config rules to meet CloudTrail standards for the CIS AWS Foundations Benchmark controls
AWS Security Hub provides you with a comprehensive view of your security state in AWS and helps you check your environment against security industry standards. It is integrated with CloudTrail, which captures API calls for Security Hub as events. Security Hub supports the CIS AWS Foundations Benchmark standard. You can use AWS Config rules and remediations to make sure CloudTrail is configured according to CIS controls. For example, the S3 bucket with CloudTrail logs cannot be publicly accessible. AWS Config will assess each rule and perform the required remediation to ensure CloudTrail is configured according to these controls. For more information, see the list of rules and remediation steps for the CIS AWS Foundations standard in the AWS Security Hub User Guide.
Get Started!
To get started with AWS CloudTrail today, you can setup your trail in the AWS CloudTrail Management Console or refer to the AWS CloudTrail Documentation.