About AWS CloudTrail
AWS CloudTrail Configuration
The course is part of these learning paths
Any information that helps to secure your Cloud infrastructure is of significant use to security engineers and architects, with AWS CloudTrail you have the ability to capture all AWS API calls made by users and/or services.
Whenever an API request is made within your environment AWS CloudTrail can track that request with a host of metadata and record it in a Log which is then sent to AWS S3 for storage allowing your to view historical data of your API calls.
Having this information has a number of uses from a security and day to day operational perspective, but it also allows for additional compliance and when it comes to specific security governance controls. Having an audited trail of requests which can be tracked backed to a user or service, and even the IP address used helps to maintain your required compliance levels.
This course provides a full explanation of the service, looking at what it does, how it does it and with what components and services. It breaks down each of the configurable components allowing you to see exactly how it works and to what degree it can be configured.
It dives into permissions required to run and implement CloudTrail, covering roles and policies, along with an overview of S3 Bucket permissions required for log storage. There are also a number of demonstrations within the course showing first hand how to configure Trails and set up various controls and permissions giving you clear guidance on what to do.
CloudTrail Logs are examined to show you exactly how APIs are recorded and how this sensitive information can be encrypted using KMS and also shared between AWS Accounts.
A key aspect of CloudTrail is its relationship with AWS CloudWatch, where the two services can be used together to create a monitoring solution based on API requests, allowing custom metrics and thresholds to be created. When used in conjunction with SNS, this becomes a powerful monitoring solution.
If you have thoughts or suggestions for this course, please contact Cloud Academy at email@example.com.
Hello and welcome to this lecture where I shall discuss the different features and components of CloudTrail and how they work together to provide a customizable API call-tracking and monitoring solution.
Firstly, let's look under the hood of CloudTrail to see what makes up the core features and components that create the service.
Trails. These are the building blocks of the service. You can create many different trails containing different configurations relating to API requests that you want to capture.
S3. S3 is used by default to store the CloudTrail log files and a dedicated S3 bucket is required during the creation of a new trail.
Logs. Logs are created by AWS CloudTrail and record all events captured. A new log file is created approximately every five minutes and once processed, it is delivered to an S3 bucket as defined by its trail configuration. If no API calls have been made, then no logs will be delivered.
KMS. The use of AWS KMS is an optional element of CloudTrail, but it allows additional encryption to be added to your log files when stored on S3.
SNS. SNS is also an optional component for CloudTrail, but it allows for you to create notifications. For example, when a new log file is delivered to S3, SNS can notify someone or a team via an email. Or it could be used in conjunction with CloudWatch when metric thresholds have been reached.
CloudWatch Logs. Again, this is another optional component. But AWS CloudTrail allows you to deliver its logs to AWS CloudWatch logs as well as S3 for specific monitoring metrics to take place.
Event Selectors. Event selectors allow you to add a level of customization to the type of API requests you want the corresponding trail to capture.
Tags. Tags allow you to assign your own metadata to your trail. For example, you could add a project or department tag indicating which project or department the trail relates to.
Events. For every API request that is captured by CloudTrail it is recorded as an event in a CloudTrail log file.
API Activity Filters. These are search filters that can be applied against your API activity history in the management console for create, modify and delete API calls. These events are held in the management console for seven days, even if the trail itself is stopped or deleted.
Okay, so I've now covered the different components that essentially build CloudTrail. Let me introduce you to the process at a high level of how all of this fits together and in what order. In the coming lectures, I will explain in greater detail each of the configurable elements.
By default, CloudTrail is not enabled within your AWS account, so the very first step is to create a trail. If no trail exists, then CloudTrail does not know what API calls to capture from which region and which services, global or otherwise. During this trail creation, you will need to specify an S3 bucket for your log files to be delivered to. This can be an existing bucket or a new bucket which can be created at this stage. You will then have the option to encrypt your log files with the Key Management Service, KMS, if required. Also if required, you can configure the Simple Notification Service, SNS, to notify you when new log files are delivered. If you want to add another layer of security integrity, then you can enable Log File Validation, which will ensure your logs have not been modified or tampered with since their delivery to S3.
Your trail is now ready to be turned on and created. Once it has been created, you are able to make further configurational changes that are not available during the trail creation itself. Upon selection of your new trail, you will have the option to configure CloudWatch logs, which allows you to deliver your CloudTrail log files to CloudWatch in addition to S3. This allows you to creat CloudWatch monitoring metrics against specific API calls and will receive notification from SNS when custom thresholds are reached. Another optional configurable element is that of CloudTrail Event Selectors. This allows you to specify the types of events, management or data that CloudTrail logs. Finally, at the last element of your newly created trail configuration, there is the ability to add tags just as you would with other resources within AWS. At this point your trail is configured and actively recording API calls as per your configuration. For every API call that matches the requirement of your trail, it will be captured and recorded in a log file as an event. Each API call will be recorded as a new event.
Once you have captured the data, you may need to find a particular event quickly, maybe for security reasons. This can be achieved using API Activity Filters which can be found within the CloudTrail service from the management console. So from a high level perspective, we know how a trail is configured.
But what happens when an API matching a trail is called upon by user or service? Let's take a quick look. A user or service calls upon an API. Next, CloudTrail checks to see if this API call matches any configured trails. If a match is found, CloudTrail recalls the API as an event within its current log file. It also associates other identifiable metadata mentioned earlier. Eventually, the event with the log file will be delivered to S3 and possibly CloudWatch Logs depending on the trail configuration. If it is sent to CloudWatch Logs, the log file will be monitored by any configured metrics. When in S3, the log file will be stored and the default server site encryption, SSE, unless KMS has been configured for increased security measures with the associated trail. If any S3 life cycle rules are applied to the bucket, then over time the log file may be archived to a different storage class or even glacier.
That essentially concludes the elements of CloudTrail and how they work together. Coming up in the following lectures we will dive deeper into these configuration components, providing you with a greater understanding of exactly what can be achieved at a more granular level.
That brings us to the end of this lecture. Coming up next, I will explain and cover the various permissions that need to be in place for CloudTrail to be effective.
About the Author
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data centre and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 60++ courses relating to Cloud, most within the AWS category with a heavy focus on security and compliance
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.