‫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.