The AWS CloudTrail setup is one of the most important elements when you start working with the AWS cloud. So how do you set up AWS CloudTrail and what to look for?
On the one hand, it may seem to you that this is obvious. However, I'll tell you that I still often come across with the omission (or rather unconscious) of CloudTrail's correct AWS configuration.
Therefore, in this article we will look more closely at what the AWS CloudTrail service is and why it is so relevant. And it will show you how to configure AWS CloudTrail.
What is AWS CloudTrail?
Let's start from the beginning, what is AWS CloudTrail?
The service is responsible for logging all events on our AWS account. This is what happens when you work with a graphics console (AWS Management Console), aws cli, AWS SDK and API.
I.e., any event like, e.g.:
user user1 logged in to the console,
service X performed the action on service Y,
SecurityGroup has been modified by... ,
In short, everything that happens on your account.
List of logs from the Event history tab
Proper care of AWS CloudTrail logs increases the level of safety and helps meet audit or regulatory requirements.
Therefore, it is important to take care of this part of the setup, so that at any time you will be able to “go back” in time and see what and how happened on your AWS account.
How to enable AWS CloudTrail
Now let's briefly explain two very important elements of the AWS CloudTrail configuration.
For a long time (though I remember times when it wasn't already), for every newly created AWS account, log-collection in CloudTrail is automatically enabled.
Uncle Google hints that in August 2017 AWS announced that CloudTrail is automatically enabled for everyone (see “New — Amazon Web Services Extends CloudTrail to All AWS Customers”).
So if you create an account now and go to CloudTrail in the Event history panel, you will see logs from what's happening in your account (see graphic above).
ATTENTION! Now that second very important element... When you look again at the logs dump above, you will see under the title Event history, a very important sentence:
Event history shows you the last 90 days of management events.
So your logs are there, but after 90 days they're gone. Then what if he comes to check for something that happened, like 180 days ago? How and where can you store these logs for more than 90 days?
To answer these questions, I decided to write this article. I still and quite often encounter a situation where companies do not have a secure configuration and, above all, longer like 90 days of CloudTrail logs storage.
How to safely store logs?
So we go to the merits of this entry, how to safely store AWS CloudTrail logs?
First, even if you only have one AWS account, there's nothing preventing you from saving logs to be available for longer than 90 days. This is about setting up the so-called “Trails” so that logs are saved to the S3 bucket.
I, of course, as usual, strongly encourage you, to create a separate AWS account, to store such logs. Why have more AWS accounts, you'll learn about it from another article of mine, “Isn't one AWS account not enough?”
Today's entry will also focus on the secure storage of logs in a multi-account structure. So let's go to the details.
Storage of logs throughout your organization
If you have several AWS accounts, and you plan to add more in the future, AWS Organizations will help. Thanks to it, you can not only create and manage accounts, but also create a shared configuration for some of the services.
In the organization's settings, there is a section “Trusted access for AWS services” where you can “globally” across the organization include services including AWS CloudTrail.
To deploy the “Trails” configuration so that all accounts automatically send logs to the appropriate S3 bucket, ensure that CloudTrail is enabled in your organization (see above).
Where to save CloudTrail logs?
Login to S3 from multiple AWS accounts.
OK, now we'll take care of setting up a safe place to store logs.
If you have already read my article about the amount of accounts then you know that we will now create a suitable account that will only and exclusively be dedicated to keeping logs from AWS CloudTrail. So I in my organization have a special account, let's talk about id 222222222222 (as in the image above).
Now another important element. Normally, when in your organization management account (say account about id 111111111111), you will create a “Trail” then by default you will get proposals to create a S3 bucket in this account.
However, I want logs to be postponed on a dedicated account (id 222222222222), with very limited access. So, before we configure the organizational trail, then in account 222222222222, we will first create bucket S3, we will impose appropriate permissions on it that will allow you to save logs from the entire organization.
Example policy definition:
“Resource” :"arn:aws:s3። :gov-my-cloudtrail”
“Resource” :"arn:aws:s3። :gov-my-cloudtrail/AWSlogs/1111111111/*”,
“Resource” :"arn:aws:s3። :gov-my-cloudtrail/AWSLogs/o-YOUR-ORGANISATIONS-ID/*”,
An important element in order to make it work, you need to give the opportunity to your organization (by specifying ID in the red spot) to save logs (PutObject operations) to this bucket.
Now it's off the mountain. We go to our management account 1111111111, and then to CloudTrail and from the left we select Trails and create a new trail.
Then we give the name for traila, and now the most important
We mark “Enable for all accounts in my organization”,
We mark “Use existing S3 bucket” and type the name of our bucket on logs e.g. gov-my-cloudtrail.
Setup Trails in AWS CloudTrail.
Other issues like encryption, validation of logs, I recommend, but I leave to you. We're moving on, Next!
Then you still have the ability to determine what other logs besides “Management events” you want to save and that really is everything already.
Now, every account you have as well as create in the future, you will deploy a Trails setup, which will postpone logs to S3 on a dedicated AWS account.
The advantage of this method is also that such an “organizational” traila can not be turned off on any belonging AWS account. You gain confidence that no one will stop saving these logs.
Additional security - Service Control Policy
Since we are already using AWS Organizations, we can further secure logs before deleting, in case someone gets into an account with logs with higher than we would expect permissions.
We can achieve this by additionally imposing Service Control Policy on an account with logs 2222222222 so as to prohibit any modification or deletion of logs.
Of course, this just exemplifies a policy that forbids certain changes both in the configuration and above all the ability to delete logs.
At the time when we impose such a policy on account 2222222222, it will be irrelevant to who and with what privileges logs into the account. It won't be able to delete logs.
As you see the whole process is quite simple and should not take more than 10-15 minutes of your time.
The ground to decide where and how the logs will be stored, I recommend separately the account. However, according to Rule 1 is better than 0, even if you work on one account, put a S3 bucket on it and set up Trails.
Plus you can always export those logs where “out”.
If you have a more account, then as I described in my scenario, create a dedicated account, bucket S3 on it, and set up Trails at the level of the entire organization.
Now you will be sure that at any time it will be possible to check what when and how happened at any time in time. Cheers!