These two tools built into the IAM Management Console are very useful when conducting security audits, allowing you to test your IAM policies, user-specific access and access to multiple accounts, and even detect alert issues detected.
Regular safety reviews are important
If you have many employees and use IAM users for employee accounts, you should conduct regular security checks to ensure that your policies are kept in check. Because users can have multiple policies linked to their account, it is possible to slip up and accidentally give a user more permissions than they need. Without security checks, the user will continue to have elevated privileges until someone notices it.
The problem is exacerbated with multiple accounts. It is quite common for large companies to use AWS organizations to separate their account into development, testing, staging and production environments. This keeps everything separate and makes it possible for the development environment to have more lax permissions.
Setting up cross-account access is easy; for example, you can give a user in the development environment access to certain resources in the test environment. You want to make sure that the production environment is more locked and does not allow access to external accounts that do not need it. And of course, if you work for another company, you can give them federated access to some of your resources. You want to make sure this is set correctly, otherwise it could be a security issue.
Policy Simulator tests access per account
Policy Simulator is quite simple in concept. You select an account and it assumes the permissions for that account and simulates API requests to test what resources the account has access to.
Go to the IAM Management Console to try it out. Select a user, group or role from the left sidebar and select a service to test.
You can test individual API calls directly by selecting a specific action, but it is much more useful to simply “Select all” and test all possible actions automatically. This can catch errors where, for example, you gave a user write access to a bucket (intended to give them permission to upload), but missed the fact that write permission provides deletion permission as well.
If you click on an action, you will see which IAM policy and rule gives the user access to that resource. You can edit and create new IAM policies directly here, making it an IDE type of IAM. That’s really what IAM Policy Simulator does, but it’s useful enough that it does not have to be super nifty.
Access Analyzer identifies problems with access to multiple accounts
Access Analyzer is a new addition to the IAM suite that can automatically detect problems in your IAM settings, especially when it comes to allowing resources outside your trust. For example, if you have a KMS key in the production environment that someone can access in the development environment, Access Analyzer will detect it and send an alert.
It’s completely free and runs in the background of your AWS account, checking every so often and alerting you to problems. There is no reason not to activate it.
Go to the Access Analyzer tab in the IAM Management Console and click “Create Analyzer.”
It should run automatically when it is created, and if all goes well, you will see nothing else, just an empty list of finds. If it finds something, you will be notified and it will appear in the find list.
From here you can mark whether the find is intended for access or not intended.
If it triggers many false positives, you can set a filter under “Archive Rules.”