Amazon AWS Certified SysOps Administrator Associate – Monitoring, Auditing and Performance Part 7

14. [CCP/SAA/DVA] CloudTrail – Hands On

Okay, so let’s learn about cloud trail. So let’s open the Cloud Trail service and we’re going to look at API activity within our account. So let me close these things and let’s go on the left hand side and let’s go to the dashboard. So currently the dashboard shows that we have no trails created and that we haven’t enabled Cloud Trail Insights. And we can look at the event history of everything that happened within my accounts recently.

So if I go to Event History here, get all the information of all the API calls made by some services and when it happened and what was the username and the events were stuff like this. So it’s quite interesting because we can look at read Only events or we can look at write events. So, like, this is read only file? So that means all the right events such as Delete Role, Delete policy, this kind of things. If we look at terminate instances for example, so I’m going to look at events name is Terminate Instances. Okay, so this is a filter. We can see when instances were being deleted in EC Two. And so you can see these two instances right here were deleted by root.

So this is me. One was deleted by the Cloud Nine service. So when I was using cloud nine and one by auto scaling and if we want to drill down into an event, for example, we can look at this event right here. Okay, so an instance was terminated on this date and if I scroll down, I get an information around the event record. So all the information around when it happened, the region happened from the IP, the request parameters, all these kind of things that allow me, if I go back to it, to really understand who initiated it and what and when and how. OK, so this is some really good information and then it also links to the resource being referenced. It says this easy to instance was trying to be deleted. Obviously if I click on this resource name, it’s not going to take me anywhere because this instance was terminated and so it’s not going to find any kind of instances.

But you can see the usefulness of this event right here. Okay, so these are for you can filter by events. As we can see, if there was read Only and you just say true, then you’re going to get all the type of events that just read. For example, describe instances is an event that doesn’t change anything and so you get the idea around how cultural works. As we can see, event history shows you the last 90 days of event management and there is a problem if we want to have more than that, but we’ll see how we can fix this. Okay, so Insights is not enabled and if you create a trail with Insights in it, you’re going to have to pay for it. So I’m not going to do this, but I will show you how we can enable it. And Trails is how you would create a trail to capture more events.

So let’s click on Clear Trail and see how things work. So I’ll call it Demo Trail and as we can see, we could enable this for multiple accounts if we had an organization. So you can manage everything directly from the Cloud Trail service and where do we want to send these logs? So do we want to send everything in a new bucket or an existing bucket? So yes, I can create a new bucket that will be created automatically to have this trail. Do we want this bucket to be encrypted? For sure, why not? I’ll disable this. This is going to be easier log file in Shell, enable it and SNS Notification Delivery I don’t need it. Next, we can also send these logs into Cloud Watch logs so I can enable this and create a new log group which is going to have this name. So that means that in Cloud Watch logs as well as in S Three, I’m going to have all the information around all these events happening within Cloud Trail. Do we want to create a new role for this? Yes, let’s create a new role and it will be created automatically.

So I’ll call it cloud trail role for demo. Okay, next we can tag it and I don’t need it, so I don’t need to tag this trail. Next, we need to choose the type of log events that we want to log into Cloud Watch and S Three and these kind of things. So management events as we’ve seen is all the events that are happening on your AWS resources. So whenever we terminate an instance, whenever we create a new Im role, these kind of things. But Data Events is going to be for events happening on your S buckets and your under functions and insights events if you want to enable Cloud which insights to detect unusual activity errors or user behavior in our account and you have to pay for both of these things if you enable it. I just want to show you the options right now in the console.

So if for management events, what do we want to have? Do we want to have read events, write events? And do you want to exclude Kms events? Because encryption happens a lot and sometimes you just don’t want to see it. So we can click on this and you don’t get any additional charges because management events are free. Next, for Data Events, this is the data sources you need to choose. So we have S Three or Lambda right now in terms of Data events. So if you choose S Three, what do we want to log in terms of data events? So do we want to log all current and future S Three buckets for read and write action? So put object read object, get object, these kind of things.

Or do we want to have individual bucket selection? And what do we want to have for logging for Read and write? So it’s up to you to define as many types of S Three buckets as you want or just all of them. Okay. And then if you want to have Lambda and Sree, you can just add a new Data events type and have Lambda and then choose all functions. And this is going to lug all data events around all these functions.

Or you can just input the function name if you wanted to. So pretty handy. And then for Insights events, it’s just one knob here to enable and then it says, okay, Insights is enabled. And so usage anomalies are going to be logged and you can view them because I don’t want to make you go out of the feature, I’m just going to unselect data events and inside events, but at least you’ve seen the option and you’ve seen the use cases. So I click on next and I will create this trail. Okay, so my trail has now been created. If I click on it, I’m able to see where it’s going to go to. So this is, I believe, my S Three buckets that it is logging to. And this also goes into a Cloud Watch Logs group right here.

So I need to go into services and go to Cloud Watch, and I’m going to find Cloud Watch logs. So let’s open this. And here is Logs, and I go to log groups. And here I can see my Cloud Trail Logs right here that I have. So there’s a log stream that was created as well. And this is where the events would happen. So my SD bucket contains the Cloud Trail and Cloud Trail digest. So if I click on Cloud Trail, this is where the objects would appear as well. So let me close the screen. So what I’m going to do is just wait a little bit for Cloud Trail to start sending some data into S Three and Cloud Watch.

That could take five minutes. And what you can do to have fun is you can, for example, open a service in EC Two. And for example, I’m going to create a key pair just for fun so we can have a look at it. So I’m going to do Funkey Pair and we’ll try to find that event in at least Cloud Watch Logs. So Fund Keeper has been created. Now let me wait a little bit and I will get back to you. Okay, so I’m going to refresh my log events and as we can see, a lot of events have been logged back. Cloud trail already into my Cloud Watch Logs. If I want to filter for the API call name creates Key pair and press Enter. It’s not being found. Let’s go try to found it first into Cloud Trail to see if it appears there. So let’s go to the event history. And I’m going to look by event name. And it’s going to be Create Key Pair, which was logged right here. So we can see this Create Key Pair happening right here.

And it was done. And we can even see the name of the key pair. Oh, this was my old key pair. So this was my dummy key pair. So we need to wait a little bit to get my phone key pair to appear here. So let’s wait, because Cloud Trail can take up to five minutes, up to 15 minutes sometimes to make events appear. So let’s wait a little bit. So let’s refresh our event history. So now we see two key pairs. So perfect. The event was being delivered into Cloud Trail. So that means that if I go to Cloud Watch and search again for my event, yes, I can see four events related to my Creates Key Pair. So if we look at the events, this is when it was created and so on. So this is quite cool. So we can look at all these events related to my Creates Key Pair.

And if I go into my Sree bucket and refresh my objects, as you can see, we get a Cloud Trail directory in S Three for each region that we’re in. So we’re in EU s one. And then we can look by dates. And here we go. We have some files that here I can download and open up. And it will give me JSON files that will look exactly the same as what’s in here and what’s in Cloud Trail. If I click on one of these events, it will look at the same event record. Okay, but the cool thing is that because it is in Amazon S Three, then we can use Athena to query these records. So if I go into Cloud Trail and look into the event history, I can create an Athena table and choose my Cloud Trail logs here. And this is going to create a table in Athena. And this table in Athena that I can open up, I will show you right here is going to allow me to query for historical events in Cloud Trail.

So if I look at this table and then I will click on the three dots and say Preview Table. So let’s run this query. And there’s no output location defined. So let me just scroll up, click on set up a queries of Location. And I need to just select a bucket for this so I can select this one. This looks right. And press select, click on Save. Perfect. So now if I run this query again, this should work. Here we go. And we can see the results where we have the event version, the user identity, and we have a bunch of columns into Athena.

So the event time, the event source, event name, region source, IP address, user agent and so on. And we can start running some queries around these events and analyze our data historically, which I think is really, really cool. So that’s it for this lecture. I hope you liked it. And if you wanted to just clean up after yourself, you could delete this. As for buckets, you could delete this cloud trail log group. And I’m going to do this right now in the trail itself. I can click on it and delete this trail so it stops lugging stuff all around. So that’s it. I hope you liked it, and I will see you in the next lecture.

15. CloudTrail for SysOps

Okay, so here are a few things you need to know for Cloud Trail going into the exam. The first one is that you can have a log file integrity validation. So when you do API calls within AWS, they’re going to be logged back Cloud Trail, and you can have these logs being sent into Amazon s Three, okay, every 1 hour. But you can also create what’s called a digest file. And this is a file that will reference all the log files from the last hour and will contain a hash of each.

And this is going to be stored in the same extra buckets as your log files but within a different folder. And the idea is that this is going to reference all of them, okay? And this will help you determine whether or not a log file was being tampered with. So either modified or deleted after Cloud Trail delivered it. So if the log file hash corresponds to the digest file hash, that you know for sure that the log file has not been modified and you’re good to go. So this is very helpful for compliance purposes. The hash is using the Chat 256 algorithm, okay? And then the idea is that you still want to protect your Svocet using a bucket policy, using Versioning, using MFA, Delete Protection Encryption and Object Lock.

If you wanted to make sure that all these files within your SD buckets from Cloud Trail are kept all along this time, okay? But if you wanted to show from a compliance perspective that these files are not modified with, you would use a digest file from Cloud Trail. Finally, you should protect Cloud Trail using Im if you want to make sure to make sure that Cloud Trail keeps on delivering these lock files into Amazon Sri. You can also integrate Cloud Trail with EventBridge. So Cloud Trail can trigger Event bridge for any kind of API calls made within your AWS accounts.

And then from EventBridge, you can do any kind of integration you want using Lambda, SNS, SQS and so on. So if you wanted to react to any API call, not even something that’s covered by EventBridge, but you know that will appear in Cloud Trail, then you would define an Event bridge integration with Cloud Trail. But Cloud Trail is not real time, okay? The events may be delivered within 15 minutes of an API call, and then the events in log files will also be delivered within history within five minutes. Okay? So this is not a real time automation on top of API calls, but this is for you, a way to get some kind of integration on top of any API calls made within Cloud Trail when it is delivered into EventBridge.

Finally, you can have Organization Trails, so you can set up Cloud Trail at the organization level. So you have a management account and many different member accounts. And so your Cloud Trail@your. org level is going to log events for all API calls for all your member accounts into a target extra bucket that is organization wide, okay? And this is very handy for account management. So all the events will be logged. And this is going to give you for both the management and the member accounts. And the trail name will be the same for every accounts in AWS. And the member accounts cannot remove or modify the organization trail, which is good for compliance. They can only view that it exists. So that’s it for all the additional stuff you need to know on Cartrell. I hope you liked it and I will see you in the next lecture.

• Category: Uncategorized