Securing AWS CloudTrail

If you manage an Amazon Web Services (AWS) account, you place that account’s security at the top of your priorities. AWS provides many tools to secure, protect, and deliver auditing capabilities. AWS CloudTrail should be a critical piece of your security toolbox. This article will explore CloudTrail and how you can leverage its capabilities to secure your AWS account. We’ll also discuss how you can secure CloudTrail from malicious actors so that you can rely on the data it generates and stores.

What Is AWS CloudTrail?

AWS CloudTrail is a service that tracks and logs user interactions within your AWS account. These interactions include calls to the AWS APIs, actions performed within the AWS Management Console, and calls from the AWS Command Line Interface. Considering the hundreds of services available in an AWS account across a global array of regions, these insights are critical to ensure compliance, audit operations, identify risks, and monitor appropriate use.

The CloudTrail service records each of the above activities in a CloudTrail event. CloudTrail events provide a chronological view of which user or service initiated a request, together with relevant details to allow you to analyze and appropriately respond to any anomalies or unexpected actions, malicious or otherwise.

Next, we’ll discuss how to set up CloudTrail access within your AWS account. Then, we’ll closely examine the process whereby CloudTrail logs events and explain which details those events include. A series of events from a service is known as a trail. We’ll discuss the importance of securing your trails and introduce you to best practices to implement when you enable AWS CloudTrail. We’ll discuss each of the best practices in detail as we go and include a summary at the end so that you have a concise list as a reference.

Configuring Security for CloudTrail

When you create a new AWS account, CloudTrail is automatically enabled. One of the first steps you should take is to create a user group with permission to manage CloudTrail event trails. You can grant permissions to this group by applying AWS-managed IAM policies. There are two managed policies with different levels of access that you can use.

AWSCloudTrail_FullAccess

This managed policy controls the ability of users to view events and manage the CloudTrail configuration. Before applying this policy, take extra care to only grant it to account administrators who have been carefully screened and authorized to edit CloudTrail functionality. This policy allows users to enable, disable, and reconfigure any of the auditing features of CloudTrail.

AWSCloudTrail_ReadOnlyAccess

This managed policy allows those associated with it to view trails and download event history but does not allow the user to modify or disable any of the CloudTrail configurations. It would be best if you were still careful about which users have this access. Still, it’s appropriate for auditors and those tasked with monitoring and analyzing usage within the account.

Suppose you would like additional information about CloudTrail permissions or would like to understand the managed policies in greater depth. In that case, you can reference Granting Permissions for CloudTrail Administration in the AWS documentation for CloudTrail.

Now that we have an authorized user group to manage our CloudTrail configuration, we can configure and view trails on our account.

Managing CloudTrail Capabilities

Let’s start with a tour of the CloudTrail service. Log in to your AWS account and navigate to the CloudTrail home page. Select Event history from the navigation menu on the left side of the screen. By default, CloudTrail maintains a record of all events for the past 90 days. The screenshot below shows me logging into the AWS Console as the root user, creating a CloudTrail, and creating a CloudTrail management group:

You’ll notice multiple events associated with each action I performed. For example, when I created a new trail, there was a call to the CloudTrail.PutEventSelectors API and a call to the S3.PutBucketPublicAccessBlock API. We can view the name of the user who performed the action, a timestamp, and specific details such as the name and type of the resources affected. Clicking on an Event name shows you the entire contents of the event record, which is helpful for additional analysis.

The Event history is useful, but will show you only events in the current region. You can create a CloudTrail that gathers events across all AWS regions and target the trail to include:

• Management events
• Data events, which capture read and write events for services such as:
  • DynamoDB & DynamoDB Streams
  • S3, S3 Outpost, and S3 Access Points
  • Managed Blockchain
• Insights events, such as:
  • API call rate
  • API error rate

In most cases, AWS will charge you for storing the CloudTrail logs in S3; however, CloudTrail Insights events may incur additional charges.

You can create a new CloudTrail by navigating to the CloudTrail Dashboard and selecting the Create trail button. Similar to other creation wizards within AWS, the console takes you through a series of steps to:

1. Define the attributes of your trail, including its name, S3 storage location, and encryption.
2. Identify which types of events the trail should monitor.
3. Review, confirm, and create.

The AWS documentation provides an excellent tutorial that walks through the creation process for a new CloudTrail trail. The tutorial also provides links to documentation that addresses the cost of using CloudTrail and other useful information.

CloudTrail Security Risks and Capabilities

We’ve already discussed the importance of limiting access for viewing and managing CloudTrails to carefully selected and vetted individuals in your organization. You must ensure secure access to manage and view your trails and logs. Let’s discuss additional risks and security precautions that you can take to ensure that both the trails and their event records remain secure.

AWS stores CloudTrail event logs in an S3 bucket that is not publicly accessible. However, some users in your account may still have access to the bucket. An important step when creating a new CloudTrail is to ensure that bucket access is limited to those responsible for viewing and analyzing the logs. AWS recommends creating a centralized S3 bucket for CloudTrail logs and adding the following security restrictions to that bucket:

• Use the principle of least privilege when granting access to the bucket.
• Add lifecycle rules to the bucket to ensure the long-term retention of files within the bucket, including archival to Amazon Glacier for low-cost and long-term storage.
• Add a bucket policy to require MFA validation for any delete actions.

AWS also recommends that you enable server-side encryption on the event logs to safeguard the contents further and restrict access to the appropriate tools and applications. When you create a new trail, you can enable SSE-KMS encryption by checking the box during the first step of the trail creation process. You can learn more about this step and how to use the AWS Key Management System (KMS) in this process in the AWS documentation.

AWS CloudTrail alone is an essential and powerful tool to track and monitor events within your AWS account. One idea you might consider implementing is configuring a trail to monitor changes to the CloudTrail configuration itself. Another helpful idea is to combine the power of CloudTrail with other AWS services, such as AWS Config. AWS Config monitors changes to the configurations of AWS resources within your account. By using AWS CloudTrail and AWS Config together, you will be able to identify who made changes to a configuration, along with a chronological timeline of the implementation of those changes. This process is well-documented in an AWS blog post, “How to use AWS Config and CloudTrail to find who made changes to a resource” (October 2022).

CloudTrail Integration with CloudWatch

When you set up and use a service like CloudTrail, you’ll accurately track and store events across your account. This information is helpful for an investigation, but it’s unlikely that you have someone on your payroll responsible for monitoring and analyzing these events daily. Like other AWS services, you can configure your trail to send logging events to AWS CloudWatch.

You can create CloudWatch alarms that alert you when it detects certain events or an anomaly in the type or number of events. As with CloudTrail, you’ll want to ensure that you properly secure the CloudWatch alarms and the SNS topics used to deliver alert notifications.

CloudTrail Security Best Practices

Throughout this article, we’ve discussed some best practices you can follow to ensure that your CloudTrail access and event logs are appropriately secured. Below is a summary of those best practices:

1. Create user groups that control access to manage, analyze, and view your CloudTrail trails and logs.
2. Create a central S3 bucket to store CloudTrail event logs and use the principle of least privilege to secure that bucket. Also, enable long-term retention of the logs and require MFA validation for the delete action.
3. Monitor CloudTrail events as part of your CloudTrail action plan.
4. Integrate CloudTrail with CloudWatch for automated monitoring and anomaly reporting.
5. Ensure that the CloudWatch alarms and SNS topics used for this are also appropriately secured.
6. Combine CloudTrail with AWS Config to provide a more comprehensive view of how you manage your infrastructure and the resources within your account.