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 firstname.lastname@example.org.
Hello and welcome to this short lecture on permissions. I'm going to talk about permissions that are required to set up and create trails and those required by S3 for CloudTrail login, where we will also take a look at Bucket policies.
As with all resources within AWS, to be able to use a service or feature you need to have the proper permissions and authorization. If you do not have the permissions to create trails on CloudTrail, or to configure it as you need, then you'll need to speak to your AWS administrator or security team. If you are the administrator and you want to grant access to others, then you could create your own IAM policies to cover this access. Or use an existing AWS Managed policy. For more information on IAM policies you can see my previous course Understanding of AWS Authentication, Authorization and Accounting. Or my blog post here on IAM policies. Currently AWS has two Managed policies in IAM, relating to CloudTrail: AWSCloudTrailFullAccess and AWSCloudTrailReadOnlyAccess. These are fairly self explanatory as to the level of access provided here. If someone needs to create or delete trails then they will obviously need the AWSCloudTrailFullAccess policy, associated to the user account.
I just want to quickly point out that if the existing Managed policies don't quite meet your permissions needs then you can simply copy and modify them to meet your specific requirements. For example, if you only wanted particular users to have some of the full access permissions then you can remove any lines within the policy that you wanted to restrict. If we look at the actual policy for AWSCloudTrailFullAccess we can see that this also includes admin level access to SNS and S3, which you may want to restrict depending on how you control and manage these other services within your organization. It's likely you have different teams, managing different services and solutions and so you might need to split up the permissions to allow some to configure S3 and others to configure SNS, Cloud Watch and KMS etc. However upon creation of your trails, it can be useful to have someone responsible to set the configuration for these services during the trail creation, for ease and to ensure it doesn't get overlooked at a later date.
As we know CloudTrail logs are delivered to an S3 Bucket. When creating your trails, there is a step where you need specify which S3 Bucket to send logs to once processed. Here you will have two options. The first option being create a new S3 Bucket. And the second is to use an existing S3 Bucket.
By selecting the first option, CloudTrail applies and configures a Bucket Policy with the relevant permissions, allowing logs to be delivered to the Bucket. As a part of this process, CloudTrail configures the following attributes within the policy. The allowed Statement IDs (SIDs). The folder name where the log files will be saved. The service principal name for the current and future CloudTrail supported regions. The Bucket name. The optional prefix, if one was specified. And the ID of the owning account. This method is the easiest way to allow CloudTrail to write logs to your S3 Bucket.
If, however, you choose to select an existing Bucket, then you need to set up the correct permissions. This is achieved by applying your own Bucket Policy, which must allow CloudTrail to write and install logs within it. Thankfully AWS have provided a JSON template to allow you to do this with relative ease, as you can see from the link.
Once you add this policy to your Bucket, you need to set the variable shown in the red italics with your own settings. The optional prefix allows for better organization, allowing you to create a tiered folder like structure for different trail log files if needed. If this existent Bucket already has a Bucket policy, then take caution as you may need to append or edit your existing policy to account for any new statements.
For users of services requiring read access to the CloudTrail logs, authorization will need to be given for S3 read permissions via the usual methods, such as through IAM or an S3 Bucket Policy or even an S3 access control list. If the logs have been encrypted using the Key Management Service, KMS, additional permissions will be required to read the logs. To read the logs that have been encrypted with KMS, the user or service will also need the decrypt permission associated with the Customer Master Key Policy, as well as existing S3 read permissions. Using KMS on your log files is a great way to add another layer of encryption, over the default encryption applied by CloudTrail, which is SSE-S3, Server-Side Encryption with S3 managed keys. For those unfamiliar with SSE, it's an encryption method used in Amazon S3 to encrypt any object at rest. It's completely managed by AWS along with the encryption keys, which themselves are also automatically encrypted and rotated regularly by S3. SSE-S3 uses the 256 bit advanced encryption standard, AES 256 algorithm, for its encryption.
You can choose to implement SSE-KMS encryption, which is Server-Side Encryption with AWS KMS managed keys during the creation of your Trail. If this is selected you must either select one of two options when defining your key. The first option is for CloudTrail to create a new KMS key for you. Which will be your Customer Master Key, CMK. And CloudTrail will apply the correct policy to that Key. Or secondly you can select an existing Customer Master Key, to which you must then apply your own policy with the correct permissions. Before moving on from this point, it's important to note that if you are using an existing KMS Key, the Key and S3 Bucket must be in the same region. Thankfully in case you forget, you are reminded of this during the configuration process.
Again to save you writing your own policy for own your own chosen Key, you can visit this link. This will allow you to copy the default policy that is applied to a newly created CMK in the first option. Again you simply need to replace the areas as indicated in the example. As I mentioned earlier, if the logs are encrypted with SSE-KMS, then the user will need decrypt permissions which can be found in the following section of this default policy. If you wanted to restrict permissions, you would need to edit the Principal attribute as by default this is left wide open, as indicated by the asterix. For more information on editing policies take a look at Cloud Academies free ebook on AWS security, were I explain the different attributes of an IAM policy.
That now brings us to the end of this lecture. Coming up next, we will talk in greater depth about Trails that we touched on earlier in the previous lecture.
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.