Amazon AWS Certified SysOps Administrator Associate – Identity
We are nearing the end of this section. But first let’s talk about the kind of security tools we have in IAM. So we can create an IAM credentials report and this is at your account level. And this report will contain all your accounts users and the status of their various credentials. We’ll be actually generating it right now and having a look at it. And the second security tool you can use in IAM is called IAM Access Advisor.
One is at the user level and the Access Advisor is going to show the service permissions granted to a user and when those services were last accessed. And this will be very helpful because we are talking already about the principle of least privilege. And so using this tool, we’re able to see which permissions are not used and reduce the permission a user can get to be in line with that principle of least privilege. So I will see you in the next lecture to show you how to use the security tools.
Let’s generate a credential report. So on the bottom left, I’m going to create a Credential report. And I can click on the load report to just download this report. And this will be a CSV file. Now this CSV, because I’m using a training account, is not fascinating, but as we can see, we have two rows in it. We have my Rot account and my account names defend. We can see when the user was created, if the password was enabled, when the password was last used and last changed, when is the next rotation to be expected? If we do enable password rotation, is MFA active.
So we can see it’s active for my root account, but it is not active for my Stefano accounts. Then access keys, are they generated or not? Yes, they’re created from my Stefano account, but not from my root account. And when they’re last rotated, last used, and so on. You can get more information about other access keys and certificates and so on. So this report is extremely helpful.
If you want to look at some users that haven’t been changing the password or using it or their account, it could be really giving you a great way to find which users that deserve your attention from a security standpoint. Next I want to look at IAM access Advisor. So I’m going to click on my user. My user is Stephan. And the right hand side, it says Access Advisor. So this is going to show me when some services were last used. And the recent activity usually appears within 4 hours.
So if you don’t see all the data, that’s why. So we can see that, for example, identity and access management was last accessed today thanks to this policy right here. And also the Health APIs and notifications were accessed today. Why? Well, this is a little bell right here. Automatically will be accessed to see if there are any notifications for your accounts. And we’ll see what this is. This is the personal health dashboard. Okay? But for the other services, for example, Alexa for business or AOS accounts or Certificates Manager, I haven’t been using them.
And so maybe it makes sense for me to remove these permissions from this user because it seems that this user is not using these services. So this is the whole power of access advice. And as you can see, there are lots of services in AWS, about 23 pages just like this. So this is about 230 services in AWS at the time of recording. So quite a lot to learn. But don’t worry, we’ll get to cover it. And we’ve just seen all the ways we can have security tools on Im. I hope you like this lecture and I will see you in the next lecture.
So now let’s discuss im access analyzer. And this is a service within the Im console that is used to find out which resources are going to be shared externally. So this applies with SD buckets, im 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 to 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 data may be accessible by external sources. And so you define a zone of trust which is going to correspond to your Alist 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 S, three bucket.
We can share it with a specific role, a user, an account, an external client by IP, or a VPC endpoint. But if we define the zone of trust to be our account and only the role the user and the VPC endpoints are within our account, then the accounts and the external client are going to be flagged as a finding. And you can look at it within the console to take action if you think this is a security risk. So in the Im 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 now completed, and as you can see, I have three active findings right now in my account. So one Sq Sq and two Sq Buckets are shared with all principles. 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 sqsq called Demo s Three 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 account. 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 not intended access. And then I go to the SQS console. I fix 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 sqsq.
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, I only have two findings, and here as well, I have two findings related to my Esther buckets being public. And so maybe this is an intended access, in which case I will archive this bucket. And then if I go back to my findings, it will be into the archived column. But 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 this kind of sree public buckets, you can go to Archive rules and you can create your own rule to automatically say which criteria should make a finding irrelevant. Okay, if you wanted to. So that’s it for this lecture. I hope you liked it, and I will see you in the next lecture.
Popular posts
Recent Posts