-: So now let's discuss IAM Access Analyzer,
and this is a service within the IAM console that is used
to find out which resources
are going to be shared externally.
So S3 buckets, IAM Roles, KMS Keys,
Lambda Functions and Layers, SQS Queues
and Secrets Manager Secrets.
So, the idea is that some of these obviously
can have resource policies attached with them
or they can be shared with other accounts.
But sometimes you forget about sharing these items
and it can be a security risk for your company
because some of the app may be accessible
by external sources.
And so you define a zone of trust,
which is going to correspond to your alias accounts
or your entire alias organization,
and then anything outside your zone of trust that has access
to the resources said above
are going to be reported as findings.
So for example, we have an S3 buckets,
we can share it with a specific role, a user, an account,
an external client by IP or VPC endpoint.
But if we define the zone of trust to be our accounts
and only the role of the user and the VPC endpoints
are within our accounts,
then the accounts and the external clients
are going to be flagged as a finding.
And you can look at it within the consultant to take action
if you think this is a security risk.
So in the IAM console, on the left hand side,
you have access analyzer and here you can create
your first analyzer.
So you name it, console analyzer.
This is free by the way to enable.
The zone of trust
is going to be the current account right now.
And the findings are going to be reported
outside of your zone of trust.
You can add tags to the analyzer but we don't need to.
And then I'm going to create the analyzer.
This is going to create a service linked role
which is going to allow the analyzer
to interact with resources on our behalf.
So my scan has not completed and as you can see,
I have three active findings right now in my accounts.
So one SQS queue and two S3 buckets are shared
with all principals.
So this one is shared through a bucket policy
and this one doesn't say how, and this is write access
and this is read access.
So it's very interesting.
For example, let's consider this SQS queue
called a demo S3 notification.
So we can click here to have a link
directly into the resource and then go here
and then go to access policy.
And as you can see, I allow anyone to send a message
and anyone could be anyone from an external accounts.
So this is not good, right?
So what I should do then is have a look at this
and make sure that this is either the intended access
of my queue so I can archive it or a not intended access.
And then I go to the SQS console, I fixed this policy,
and then I rescan. So I'm going to edit this.
And I don't like this policy,
so I'm going to just remove this policy overall,
because I don't want to allow anyone
to send a message into my SQS queue.
I will click on save and now I will do a rescan.
And now the status is resolved
because the access is no longer allowed.
So if I go back to my findings now only have two findings.
And here as well, I have two findings
related to my S3 buckets being public.
And so maybe this is an intended access
in which case I will archive this buckets.
And then If I go back to my findings,
it will be into the archived column.
We see we have the other one from the resolve column
and we can still look at the active ones.
And then finally, if you wanted to always archive
these kind of S3 public buckets,
you can go into archive rules
and you can create your own rule
to automatically say which criteria
should make a finding irrelevance. Okay.
If you want it to.
So that's it for this lecture. I hope you liked it.
And I will see you in the next lecture.