AWS’s IAM Policy Simulator and Access Analyzer can help you test the security and access controls of your IAM roles. The IAM Policy Simulator lets you create, edit, and delete policies. You can use this tool to test the effects of different policies on users, groups, resources, and actions. The Access Analyzer helps you identify which users or groups have access to which resources. To use these tools, first sign in to your AWS account. Then go to the IAM Policy Simulator page in the AWS Management Console (https://console.aws.amazon.com/iam/home). On this page, you can create a new policy or edit an existing one. To test a policy, click the Test button next to it. The simulator will run the policy against a user or group that you specify. You can also use the Access Analyzer to see which users or groups have access to which resources in your account. To do this, go to the Access Analyzer page in the AWS Management Console (https://console.aws.amazon.com/iam/home). On this page, you can select a resource type (such as EC2 instances) and then select a region from the list on the left side of the screen. The right side of the screen shows a list of users or groups who have access to that resource type in that region. You can also filter this list by using criteria such as role name or ARN (Amazon Resource Name). ..
These two tools built in to the IAM Management Console are very useful when conducting security reviews, allowing you to test your IAM policies, user specific access, and cross account access, and even sending you warnings issues are detected.
Regular Security Reviews Are Important
If you’ve got a lot of employees, and use IAM users for employee accounts, you should be doing regular security reviews to make sure your policies are kept in check. Because users can have multiple policies attached to their account, it’s possible to slip up and accidentally give a user more permissions than they need. Without security reviews, that user will continue to have elevated permissions until someone notices.
The problem is exacerbated with multiple accounts. It’s pretty common for large companies to use AWS Organizations to separate their account into development, testing, staging, and production environments. This keeps everything separate, and allows for the development environment to have more lax permissions.
Setting up cross account access is easy; for example, you might give a user in the development environment access to certain resources in testing environment. You’ll want to make sure that the production environment is more locked down, and doesn’t allow access to external accounts that don’t need it. And, of course, if you’re working with another company, you might give them federated access to some of your resources. You’ll want to make sure this is set up properly, or else it can become a security issue.
Policy Simulator Tests Per-Account Access
The Policy Simulator is pretty simple in concept. You select an account, and it assumes the permissions of that account and simulates API requests to test which resources that account has access to.
Head over 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 out individual API calls directly by selecting a specific action, but it’s far more useful to simply “Select All” and test every possible action automatically. This can catch errors where, for example, you gave a user write access to a bucket (intending to give them permission to upload), but missed the fact that write permission gives delete permission as well.
If you click on an action, you’ll be shown which IAM Policy and rule gives that user access to that resource. You can edit and create new IAM Policies directly in here, making it an IDE of sorts for IAM. Really, that’s all the IAM Policy Simulator does, but it’s useful enough that it doesn’t need to be super flashy.
Access Analyzer Identifies Problems With Cross-Account Access
The Access Analyzer is a new addition to the IAM suite that can automatically detect problems in your IAM settings, particularly when it comes to allowing resources outside of your circle of trust. If, for example, you have a KMS key in the production environment that can be accessed by someone in the development environment, Access Analyzer will detect that, and send you a warning.
It’s entirely free, and runs in the background of your AWS account, checking every so often and warning you of issues. There’s no reason not to enable it.
Head over to the Access Analyzer tab of the IAM Management Console, and click “Create Analyzer.”
It should run automatically once created, and if everything is good, you won’t see anything else, just an empty list of findings. If it does find something, you’ll be notified and it will appear in the findings list.
From here, you’ll be able to mark if the finding is intended access, or not intended.
If it’s triggering a lot of false positives, you can set up a filter under “Archive Rules.”
