AWS – AWS CloudTrail

How to Create a web API with ASP.NET Core 3.1

A vital feature of any IT environment is the ability to record a detailed audit log of the changes made, who made the changes, and when they were made. Audits are a requirement of many compliance standards, and are the best practice to ensure that security breaches can be detected and investigated. AWS CloudTrail provides this functionality by allowing you to set up trails that record specific activity within your account.

We’re now going to show you how to set up CloudTrail in your AWS account. Once CloudTrail has been enabled, it will start to record all of the API calls made in your account to the AWS service, and then deliver them to you as log files in an S3 bucket.

When we talk about API calls, we mean things such as the following:

  • Actions performed in the AWS console.
  • Calls made to AWS APIs using the CLI or SDKs.
  • Calls made on your behalf by AWS services. Think CloudFormation or the auto-scaling service.

Each entry in the log will contain useful information, such as the following:

  • The service that was called
  • The action that was requested
  • The parameters that were sent with the request
  • The response that was returned by AWS
  • The identity of the caller (including IP address)
  • The date and time of the request

How to do it…

Follow these steps to set up a new trail with CloudFormation. A trail is a single configuration for logging audit records using CloudTrail. Multiple trails can be configured:

  1. Create a new CloudFormation template file named 05-01-CloudTrail.yml; you’re going to define the following resources:
    • An S3 bucket for our CloudTrail log files to be stored in
    • A policy for our S3 bucket that allows the CloudTrail service to write to our bucket
    • A CloudTrail trail
It’s actually good practice to avoid giving names to your CloudFormation resources. Let CloudFormation name then for you—by doing this, you are guaranteed to avoid naming conflicts. Use output parameters and cross-stack references instead of copying and pasting hardcoded names.
  1. First, define an S3 bucket. We don’t need to give it a name; we’ll add the bucket name to the list of Outputs later:
    Type: AWS::S3::Bucket
  1. Next, you need to define a policy for your bucket. This section is a little wordy, so you may prefer to get this from the code samples instead. This policy essentially allows CloudTrail to do two things to our bucket: s3:GetBucketAcl and s3:PutObject:

    Type: AWS::S3::BucketPolicy
      Bucket: !Ref ExampleTrailBucket
          - Sid: AWSCloudTrailAclCheck20150319
            Effect: Allow
            Action: s3:GetBucketAcl
            Resource: !Join
              - ""
                - "arn:aws:s3:::"
                - !Ref ExampleTrailBucket
          - Sid: AWSCloudTrailWrite20150319
            Effect: Allow
            Action: s3:PutObject
            Resource: !Join
              - ""
                - "arn:aws:s3:::"
                - !Ref ExampleTrailBucket
                - "/AWSLogs/"
                - !Ref AWS::AccountId
                - "/*"
                s3:x-amz-acl: bucket-owner-full-control

  1. Now, you can set up your trail. One thing to note here is that we use DependsOn to make CloudFormation create this trail after it has created the S3 bucket and policy. If you don’t do this, you’ll likely encounter an error when you create the stack because CloudTrail won’t be able to access the bucket. Also, setting IsMultiRegionTrail to true is considered good practice. Add Trail to your template:
    Type: AWS::CloudTrail::Trail
      EnableLogFileValidation: true
      IncludeGlobalServiceEvents: true
      IsLogging: true
      IsMultiRegionTrail: true
      S3BucketName: !Ref ExampleTrailBucket
      - ExampleTrailBucket
      - ExampleBucketPolicy
  1. Finally, you’re going to output the name of the S3 bucket where your CloudTrail logs will be stored:
      Value: !Ref ExampleTrailBucket
      Description: Bucket where CloudTrail logs will be stored
  1. Run your CloudFormation stack using the following command:
 aws cloudformation create-stack \
 --template-body file://05-01-CloudTrail.yml \
 --stack-name example-cloudtrail

How it works…

This template will set up CloudTrail with the following configuration:

  • CloudTrail will be turned on for all regions in your account. This is a sensible place to start because it gives you visibility over where your AWS resources are being created. Even if you are the sole user of your AWS account, it can be handy to know if you are making API calls to other regions by mistake (it’s easy to do). When you create a multi-region trail, new regions will automatically be included when they come online with no additional effort on your part.
  • Global service events will also be logged. Again, this is a sensible default because it includes services that aren’t region-specific. CloudFront and IAM are two examples of AWS services that aren’t region-specific.
  • Log file validation is turned on. With this feature enabled, CloudTrail will deliver a digest file on an hourly basis that you can use to determine if your CloudTrail logs have been tampered with. CloudTrail uses SHA-256 for hashing and signing (RSA). The AWS CLI can be used to perform ad hoc validation of CloudTrail logs. For a quick view of your CloudTrial logs with some basic search and filter functionality, you can head to the AWS web console.

There’s more…

Here are more details about CloudTrail:

  • Server-side encryption is used to encrypt log files in S3. This encryption is transparent to you, but you can opt to encrypt these files with your own Customer Master Key (CMK) if you wish. CMKs are a feature of the Key Management Service (KMS), which is used to encrypt data keys for envelope encryption.
  • API calls are logged by CloudTrail in under 15 minutes.
  • Logs are shipped to your S3 bucket every five minutes.
  • It’s possible to aggregate CloudTrail events across many accounts into a single bucket. This is a pattern often used to log AWS activity into a SecOps, or similar, account for auditing.
  • By default, CloudTrail keeps your API activity for seven days.
  • You can create more than one trail. You might consider creating a trail for your developers that is separate from the trail that is consumed by security. Be aware that trails beyond the first, and trails that record data plane activity, will incur additional costs that could be significant if your account has a large amount of activity.
  • If a CloudFormation stack creates an S3 bucket and that S3 bucket has objects in it, the delete operation will fail if and when you choose to delete the stack. You can manually delete the S3 bucket in the S3 web console if you wish to work around this.

Comments are closed.