Now let's talk about user activity tracking
with AWS CloudTrail.
With AWS CloudTrail, we have the ability to record
all of the calls made to the AWS API.
So when our team is using their credentials,
whether it be long term credentials or temporary
credentials, the fact that some set of credentials
were used to at least attempt to create or delete
or otherwise modify Amazon resources,
then that API call is recorded.
And the result of that is also recorded,
whether or not it was a success or was a failure
due to some kind of an error or invalid credentials.
And so again, CloudTrail records all of the calls
made to AWS APIs. And we can configure CloudTrail
to deliver those log files to an S3 bucket,
or we could also have AWS CloudTrail deliver log events
to CloudWatch logs in near real-time.
And so these log files and the data includes the identity
of some kind of a key,
marking the identity of those credentials,
the source IP, and a number of
request and response details.
Now of course if you're using the API
to get some kind of sensitive data into AWS,
then the data itself will not be recorded.
CloudTrail is not recording sensitive information.
Even for the identity, usually these credentials have a,
two components to them. There's a key
and then there's a secret. And the secret is not recorded,
but the key is because the key is meant to be public.
And like I said, the actual data is not recorded.
And so, another thing that's not recorded,
several things, would be, like the operating system logs.
Right, so if you're running Ubuntu or Windows or RedHat
on EC2, anything happening inside that operating system,
that is not recorded by CloudTrail.
Database queries are also not recorded.
These are just a couple of examples of things
that are not recorded.
Right, so hold that thought. We're gonna talk more
about that here in just a moment.
So let's take a look at this diagram.
And again, we have the AWS API.
And we, from wherever we are.
We could be making calls to the API from on-premises,
from our laptop at home, or even from within AWS.
But either way, these calls are coming into the API.
And perhaps some of those calls
are coming from the CLI tools.
Perhaps some of those calls are being generated
from the SDKs, and perhaps some of those
are coming in through the API from the AWS web console.
Doesn't really matter where they come from.
The fact is, is that the CLI tools, the SDKs,
and the web console all make use of the API.
There is no tool that we have access to, as a customer,
that can, in any way, skirt the API.
Everything that we do goes through it.
And so, you'll also notice here that in this diagram
we're making use of two different regions.
And so, we have the ability to turn CloudTrail on
region by region. Or we could turn CloudTrail on
for all regions at once.
And so, a typical pattern is that
when we turn CloudTrail on, it's generally easier
to deal with logs in one place.
And so here, what we're seeing
is that the CloudTrail
is essentially running within each region.
But each CloudTrail service for that region
is sending its data to the same S3 bucket.
So now we have one place that we can go to,
to retrieve those CloudTrail log files.
And so again, could be that we have other services
within Amazon. We could have, for example,
Jenkins running on EC2.
And Jenkins is responsible for communicating
with the Amazon API in order to upload artifacts to S3.
That call would also be captured.
So again, anything that uses the API will be captured.
But if we notice here in this diagram,
we have EC2 instances running.
Of course the API was used to launch those instances.
The API would be used to terminate those instances.
But once those instances are running,
there is then an operating system.
If we shell into that operating system,
if we gain some kind of remote access,
now we're in a completely different realm of authentication.
We're within the realm of the operating system.
It has it's own set of credentials.
And so, anything that we do in there is completely,
CloudTrail is completely blind to.
So if we need those, if we need that kind of access logging,
we would have to collect that with CloudWatch logs.
And the same is true for our databases.
Right, if we have some type of relational database
running in RDS, again the AWS API would be used
to create the database.
But then once we have that database and we want to
connect to it and start running queries,
the database itself has it's own realm of authentication.
We connect to that and we use database level credentials.
And anything happening within the database engine.
Any alters to tables, any schema changes,
any SQL queries that are run,
CloudTrail is blind to that activity as well.
So again for anyone who really needs
to satisfy change management or compliance,
AWS CloudTrail is a key service
that allows you to record all of the calls,
including the credentials that were used as they are made,
to the AWS API.