Resourced referenced:

AWS Whitepaper: https://d0.awsstatic.com/whitepapers/compliance/AWS_Security_at_Scale_Logging_in_AWS_Whitepaper.pdf

Transcript:

Hello and welcome to this lecture. In this lecture, I will explain the basic fundamentals of AWS CloudTrail to give you an overview of the service before we look deeper at the inner workings revealing how the different elements work together.

So what is CloudTrail and what does it do? CloudTrail is a service that has a primary function to record and track all AWS API requests made. These API calls can be programmatic requests initiated from a user using an SDK, the AWS command line interface, from within the AWS management console or even from a request made by another AWS service.

For example, when auto scaling automatically sends an API request to launch or terminate an instance. These API requests are all recorded by CloudTrail.

When an API request is initiated, AWS CloudTrail captures the request as an event and records this event within a log file which is then stored on S3. Each API call represents a new event within the log file. CloudTrail also records and associates other identifying metadata with all the events. For example, the identity of the caller, the time stamp of when the request was initiated and the source IP address. In a later lecture entitled Insight Into CloudTrail Logs I will look at these log files deeper, where I will provide an example of a log file showing the different attributes recorded.

For greater management, new log files are typically created every five minutes which are then delivered and stored within an S3 bucket that is defined by you during your CloudTrail configuration. This allows you to easily go back and review the history of all API requests made. There is also an option to have these logs delivered to a CloudWatch Logs log file as well. Having this association with CloudWatch enables custom metrics to be configured to monitor specific API requests. Thresholds can be set against these metrics and when crossed, the simple notification service SNS can be triggered to notify your security teams to investigate. That, at a very high level, is the overall function of the AWS CloudTrail service.

Now let's take a look at the CloudTrail architecture to understand where it can be implemented from an AWS region standpoint and which services can be supported. AWS CloudTrail is a global service with support for all regions. Support for the latest region EU-London was added in mid-December 2016. In addition to this worldwide coverage, CloudTrail also provides support for over 60 AWS services and features across a wide range of service categories. As you can imagine, with this extensive coverage CloudTrail can capture a vast amount of data if you have a multi-region, multi-service infrastructure environment deployed.

So armed with this information, what can you do with it? How can you use this data to help you manage and support your AWS infrastructure? Well, there are a number of ways you can use the data captured by CloudTrail to help you enhance your AWS environment. Firstly, and as mentioned earlier, it can be used very effectively as a security analysis tool. CloudTrail events provide very specific information about where an API call originated from and who or what initiated the request. As a result, if malicious activity was detected via irregular trends or restricted API call thresholds with the use of CloudWatch then a number of security controls can be quickly implemented to prevent the user from causing additional damage.

Another common use for CloudTrail is to help resolve and manage day-to-day operational issues and problems. Using built-in filtering mechanisms, it's possible to quickly find who, what, and when a particular API was used which could've potentially caused an outage or service interruption. This enables quicker root cause identification resulting in a speedy resolution. Appropriate actions could then be taken to ensure the incident does not reoccur in your environment.

As API calls to add, modify, or delete resources are captured, CloudTrail can be an effective method of tracking changes to resources within your environment. There is another AWS service that is specifically designed to order and track changes to resources which is called AWS Config which CloudTrail interacts with. However, CloudTrail can be used to capture the actual API request and all associated data which made the change. And if you are not using AWS Config, then this at least provides some base level of monitoring and tracking.

From a governance and security legislation perspective, many certifications require the ability to recall and provide evidence of log files relating to specific changes to resources. CloudTrail provides all of this by default through the use of capturing events and writing them to a log file which is then stored on S3. AWS has a great white paper on achieving compliance using CloudTrail entitled Logging in AWS How AWS CloudTrail can help you achieve compliance by logging API calls and changes to resources. The following URL will take you to that white paper. If you need to be able to capture and track API requests within your AWS account for any of these reasons mentioned or perhaps for other reasons you may have of your own, then CloudTrail can do this for you and deliver the output as a log file into an S3 bucket of your choice.

That brings us to the end of this lecture. Next, we look at how CloudTrail is formulated and how the various components and elements work together.