Identity and access management (IAM) involves the technologies, policies, and processes that govern access to resources. It answers the question: Who gets access to what and when? Effective IAM is crucial for the security and proper functioning of your IT infrastructure.
The complexity of managing your environments across multiple clouds, accounts, and on-premise data centers makes maintaining centralized visibility and control challenging. This increases the risk of misconfigurations and security issues. For example:
Unauthorized access, as seen in the Sumo Logic data breach of 2023, can result in data breaches or malicious actions.
Overly permissive permissions can unintentionally expose sensitive information.
Poor IAM practices can enable insider threats, increasing the risk of data leaks, theft, fraud, or sabotage.
Excessive permissions can lead to accidental data deletions that disrupt operations and cause data loss.
In regulated industries, IAM misconfigurations can violate laws like GDPR and HIPAA, requiring strict access controls and auditing.
To address these challenges for environments that use AWS Cloud, AWS provides a service called IAM Access Analyzer. This service assists in the proactive identification of potential security risks related to IAM configurations. IAM Access Analyzer helps reduce the complexity of managing and auditing permissions across your organization’s AWS resources.
In this guide, you’ll learn how to install and harness the benefits of using AWS IAM Access Analyzer.
What Is AWS IAM Access Analyzer?
AWS IAM Access Analyzer is a feature that has been included with AWS IAM since 2019. On a basic level, IAM Access Analyzer uses automated reasoning, which AWS calls provable security, to analyze all public and cross-account paths to your resources. It then provides a comprehensive analysis of those paths on a dashboard.
This comprehensive analysis report contains “findings,” which are items the analyzer detected within your AWS landscape that represent potential security issues or noncompliant access configurations, such as permissions granted but not being actively used. Findings are categorized based on the type and severity of the issue (security warnings, errors, general warnings, or suggestions).
IAM Access Analyzer works with twelve AWS services and fifteen resource types within these services. The following table shows the resources that it works with for each service:
IAM Access Analyzer Enabled Services | Resources |
IAM | Roles |
Amazon Simple Storage Service (Amazon S3) | Buckets and directory buckets |
AWS Lambda | Functions and layers |
AWS Key Management Service (AWS KMS) | Keys |
Amazon Simple Queue Service (Amazon SQS) | Queues |
Amazon Elastic Block Store (Amazon EBS) | Volume snapshots |
Amazon Elastic Container Registry (Amazon ECR) | Repositories |
Amazon Relational Database Service (Amazon RDS) | DB snapshots and DB cluster snapshots |
AWS Secrets Manager | Secrets |
Amazon Simple Notification Service (Amazon SNS) | Topics |
Amazon Elastic File System (Amazon EFS) | File systems |
Amazon DynamoDB | Streams and tables |
Features and Use Cases
As of this writing, IAM Access Analyzer provides four capabilities to help you manage your access:
These four capabilities have specific actions that support the overall objective of that tool. For example, the refine access tool provides an analyzer that helps you identify and review any unused access in your AWS organization and accounts.
Let’s look at some features and use cases:
- Identify resources in your organization and accounts that are shared with an external entity: The external access analyzer identifies resources (such as Amazon S3 buckets and AWS KMS keys) shared with entities outside your AWS organization or account, ensuring sensitive resources are not inadvertently shared with unauthorized users.
- Identify unused access in your organization and accounts: This feature identifies active IAM roles and policies with unused permissions and shows unused roles, passwords, and access keys, thereby allowing you to revoke them to maintain the principle of least privilege. (Unsecured access analysis costs $0.20 per IAM role or user analyzed per month.)
- Validate IAM policies against policy grammar and AWS best practices: This feature ensures IAM policies comply with AWS’s policy grammar and best practices and identifies overly permissive policies, syntax errors, and deviations from standards.
- Validate IAM policies against your specified security standards: IAM Access Analyzer validates IAM policies against custom security standards. It uses automated reasoning to check specific IAM actions and compare policies to reference policies. (Custom policy checks cost $0.0020 per API call.)
- Generate IAM policies based on access activity in your AWS CloudTrail logs: By analyzing AWS CloudTrail logs, IAM Access Analyzer generates policies that grant only the permissions necessary for the observed activities, thus ensuring tight alignment with actual usage patterns.
Getting Started with AWS IAM Access Analyzer
Now that you know what IAM Access Analyzer is, the services it works with, and its features and use cases, let’s look at how you can get started using this tool to improve your access control.
To follow this section, you’ll need to have access to an AWS account and sufficient permissions to use IAM Access Analyzer. For example, you’ll need an “Administrator” role that has full access to everything or a role that has been granted the IAMAccessAnalyzerFullAccess AWS managed policy.
In this section, you’ll learn how to create and use an external access analyzer, an unused access analyzer, and IAM Access Analyzer for S3. You’ll also learn how to generate an IAM policy based on AWS CloudTrail.
Creating an External Access Analyzer
An external access analyzer identifies resources shared with external entities to ensure sensitive data is not exposed to unauthorized users. This enhances security by allowing you to review, manage, and control external access to reduce the risk of data breaches and unauthorized access.
To enable an external access analyzer using the AWS Management Console, log in to your AWS account and go to the IAM console:
Click the Access Analyzer option in the left-hand navigation pane to open IAM Access Analyzer:
Click Create analyzer, then select the type of findings you want the analyzer to provide:
Here, choose External access analysis to scan the resources within your account for external access. In the Analyzer details section, confirm the region for which you want to enable IAM Access Analyzer. This example uses the region “US East (N. Virginia).” Then, give the analyzer a name; the example uses `ExternalAccess-ConsoleAnalyzer-ConductorOneDemo`. You also have the option to create tags, but these are optional and not part of the example in this tutorial.
If your AWS account is part of an organization, the Analyzer details section will show an option to select either your current AWS account or current organization as the zone of trust for the analyzer. Since this AWS account is standalone (not part of an organization), the option is not shown.
When you’re satisfied with the current settings, click the Create analyzer button to create the external access analyzer. You’ll get a confirmation that the external access analyzer was created successfully:
Creating an Unused Access Analyzer
An unused access analyzer helps you identify and remove unnecessary permissions to ensure adherence to the principle of least privilege. This reduces the attack surface, minimizes potential security risks, and improves compliance with security best practices.
The steps to create an unused access analyzer are similar to those for creating an external access analyzer. From the IAM console, choose the Access Analyzer option in the left-hand navigation pane. You should see your already-created external access analyzer listed.
Click Create unused access analyzer:
As you can see in the Analysis > Findings type section, Unused access analysis is selected:
In the Analyzer details section, put in `UnusedAccess-ConsoleAnalyzer-ConductorOneDemo` as the name. In the Tracking period field, enter “5” as the number of days for which to generate findings. This value can be set to anything between 1 and 180 days. For this tutorial, the unused access analyzer will generate findings for permissions unused in your AWS account for 5 or more days since its last scan (today); anything not used in 5 days should be flagged.
Scroll down the page, then click the Create analyzer button to create the analyzer:
You will get the following confirmation message:
Using the Analyzers
You’ve now successfully set up both analyzers. Depending on how vast the resources are in your AWS account, it may take a few minutes before you start seeing any findings in the respective dashboards.
Analyzing S3 Buckets
IAM Access Analyzer for S3 can show you the S3 buckets that are configured to allow access to anyone on the internet or other AWS accounts, including AWS accounts outside of your organization. When used, IAM Access Analyzer for S3 will show you findings that detail the source and level of shared or public access.
IAM Access Analyzer for S3 requires an account-level analyzer. It will generate and update findings as a result of an S3 bucket or access control list (ACL) change within thirty minutes of the change.
To use IAM Access Analyzer for S3, first log in to your AWS account, then type “s3” in the search bar on the home page and click S3 to go to the S3 console:
Click IAM Access Analyzer for S3 in the left-hand navigation pane:
IAM Access Analyzer for S3 will show findings for buckets in the region, which in this case is North Virginia:
As you can see from the results, there are three buckets with public access and one bucket with access from other AWS accounts. The status of these findings is “Active,” meaning that they have not been reviewed. The other status option is “Archived,” which means that the finding has been reviewed and confirmed as intended.
Select a finding to apply an action to it. For example, in the screenshot below, the second finding has been selected:
The Archive and Block all public access options become enabled:
If public access was not intended, you would click Block all public access. For this example, click Archive, as the bucket is intended to be public.
You will then get a dialog where you have to type in “confirm” to verify that you want to archive findings for a bucket with public access:
Click Confirm. You’ll get a notification that the bucket was successfully archived, and its status will change from “Active” to “Archived.”
If you change the region to one where there is no IAM Access Analyzer enabled, for example US East (Ohio), you would get a message saying IAM Access Analyzer is not enabled in that region:
Identifying Resources Shared with an External Entity
To use IAM Access Analyzer to identify resources shared with an external entity, go back to the IAM console and select Access Analyzer > External access in the left-hand navigation menu. This will open up a screen of external access findings. This example shows eight findings, but your number of findings will vary:
On this screen, you’ll see the finding ID (allocated automatically by AWS), the resource that has external access, and the “external principal” (the entity type that has the access). In the list of findings, you can see the following external principals that have access to the specified resources: “All Principals,” “IAM User,” “Federated User,” and “AWS Account.” You can also view the time when each finding was last updated, as well as its status. As mentioned earlier, “Active” means the finding has not yet been reviewed.
You can either archive or resolve an external access finding. You’ll resolve the finding for the purposes of this tutorial, but if you wanted to archive it, you would select it and then select Archive from the Actions dropdown menu:
Instead of archiving the finding, click the finding ID for the finding you want to resolve. This will open the finding details page:
This page has a button to archive the finding as well as a link to the relevant console you need to open in order to resolve the finding. In this case, the link goes to the IAM console. If this finding were related to S3, the link would open the S3 console.
Click the Go to IAM console button to open the IAM console to the role specified in the finding:
Select the Trust relationships tab to configure access:
To remove external access, click the Edit trust policy button. The trust policy will look something like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::414351767826:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "bd78f305-1649-4ffc-a325-2dfc27b01eef"
}
}
}
]
}
Change the `Effect` value to `Deny`:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": {
"AWS": "arn:aws:iam::414351767826:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "bd78f305-1649-4ffc-a325-2dfc27b01eef"
}
}
}
]
}
Next, click the Update policy button:
You’ll get a confirmation that the trust policy has been updated:
Go back to the finding details page:
The status is still “Active,” so to refresh it, click Rescan. The status will then be “Resolved”:
If you go back to the external access findings screen, you’ll see that you now only have seven findings because you just resolved one:
As before, your actual number may be different from this, but it will be one less than the number of external access findings that you started with.
Identifying Unused Access in Your Organization
To identify unused access in your organization, go to the IAM console and select Access Analyzer > Unused access in the left-hand navigation menu to view the unused access findings:
This example account currently has 58 unused access findings. As before, the number in your account may vary. Each finding has an automatically generated finding ID and a finding type indicating permissions, roles, and access keys that were unused during the usage window (which you set to 5 days earlier in the tutorial).
Click any finding to open the finding details page:
The finding status is “Active,” and the “Last used” field shows that the role `rds-monitoring-role` was never used and thus can be removed. The finding details page contains a link to open the role in the IAM console, so click it:
Click Delete to remove the role:
You need to confirm the deletion by typing in the name of the role. After you click Delete, you’ll get a confirmation that the role was deleted:
Note that the status still shows the finding as “Active,” but there is no rescan option, so you’ll need to refresh the page to view the changed status:
The status will change to “Resolved” when the unused access analyzer runs again:
If you go back to the unused access findings screen, you’ll see that the number of active findings has been reduced to reflect the one you just removed:
If you change the status filter from “Active” to “Resolved,” you’ll get a list of all the resolved findings:
Generating IAM Policies Based on AWS CloudTrail Logs
You can generate IAM policies using CloudTrail activity for a user or a role. The CloudTrail logs contain entries of all the services and levels of access used by the user or role, and IAM Access Analyzer will generate an IAM policy that allows the same access.
To use this feature, you need to have a CloudTrail trail active to log events for IAM Access Analyzer to use to generate the policy. The maximum number of active days for CloudTrail logs is ninety days.
To create a CloudTrail trail, follow the instructions here. This tutorial uses a CloudTrail trail called `ConductorOne-Demo` that has been logging the events of the “Administrator” user:
Once you have an active trail, go to your IAM console and click Users in the left-hand navigation menu:
If you have a lot of users, you can filter the name of the user that you want to create access for. In this instance, there are only three users, so there’s no need to filter. Select the user, which is “Administrator” in this example, to open the user’s details:
Click the Generate policy button to generate a new policy based on the access activity for this user:
This will open a page where you have to configure details that will be used to generate the policy:
Specify the time period for review, the region where the trail is, and the name of the trail (`ConductorOne-Demo`). You also need to select the region where the analyzer should focus the assessment. For this demonstration, all regions are selected.
When you’re done, click the Generate policy button. This will start the policy generation process, which takes a few minutes. The status will be “In progress” during this time.
When policy generation is complete, you’ll get a confirmation message, and the status will update:
You can click the View generated policy button to review the generated policy:
The policy is based on the “Administrator” user’s actions over the period specified. You can then proceed with the prompts to customize and save it as a managed policy in IAM.
Pitfalls of Using AWS IAM Access Analyzer
While AWS IAM Access Analyzer is a valuable tool for identifying potential security risks and ensuring compliance with access policies in AWS environments, it is not without its challenges and limitations. The following are some of the pitfalls to be aware of when using IAM Access Analyzer.
Cumbersome for Large Environments
Managing a large number of resources with IAM Access Analyzer can be overwhelming, especially in large-scale environments with numerous AWS accounts. For instance, a large enterprise with thousands of S3 buckets and IAM roles may find it challenging to review and remediate all findings promptly, leading to potential delays in addressing security issues.
Region-Specific Analysis
IAM Access Analyzer operates on a region-specific basis, meaning it must be enabled and managed separately in each AWS region where resources are deployed. Since you enabled it in the N. Virginia region, only resources within that region could be analyzed. This can complicate monitoring and management across multiple regions, as there is additional effort required to configure and maintain multiple analyzers in multiple regions. There’s also the risk of incomplete monitoring if some regions are overlooked or not configured.
False Positives
IAM Access Analyzer can sometimes generate false positives and identify potential risks that aren’t actually security issues. For example, when IAM Access Analyzer can’t fully determine whether a policy statement grants external access to an external entity, it will default to declaring a false positive finding. This may result in wasted effort if time and resources are spent investigating and addressing nonissues.
Integration Challenges
Organizations may have other existing security and compliance workflows, and integrating those workflows with IAM Access Analyzer can be challenging. For example, an organization using a comprehensive security information and event management (SIEM) system may face challenges in importing and correlating IAM Access Analyzer findings with other security events. To resolve this, custom development and additional tools might be required to bridge the gap.
Best Practices to Get the Most Out of AWS IAM Access Analyzer
For most systems and applications, following best practices gives you a solid foundation from which to build and get the most out of that system, and AWS IAM Access Analyzer is no different. These best practices involve focusing on key security areas, taking proactive measures, educating and upskilling your team, and continuously optimizing your processes.
Focus
You should start by defining your security state, which includes understanding the desired access levels for your resources as well as identifying which resources are sensitive and who needs access. You should also leverage IAM Access Analyzer’s filtering capabilities to focus on specific issues. Earlier, you saw how to filter using the status. This is more or less how filtering works, and you can filter using a specific finding type, IAM resource, and so on.
The image below shows an example of filtering findings by unused password:
Proactive Measures
Regular policy validation can help ensure that your IAM policies enforce the principle of least privilege and align with both AWS best practices and your internal security standards. You should go beyond reactive findings and help prevent security gaps before they arise. You can do this by using the “Check for new access” feature on IAM Access Analyzer policy validation. This will let you know if your new policy or policy edit has introduced new access.
Continuous monitoring will allow you to stay updated on new findings and changes in your environment, enabling timely detection and remediation of potential security threats. Once an analyzer is created, it will run continuously, but it’s up to your security team to constantly and periodically review the findings.
Action and Education
You need to educate your team about the importance of access control and the specifics of the findings generated by IAM Access Analyzer to promote a culture of security awareness. A comprehensive security strategy involves both action and education. Education ensures that your team understands the importance of access control and how to respond to security findings, while taking action involves implementing this knowledge to address the findings effectively. Education will promote a culture of security awareness where team members are knowledgeable about potential risks and the significance of maintaining strict access controls.
Once a finding is generated by IAM Access Analyzer, you should address it as soon as possible, with priority given to the highly sensitive ones to mitigate the critical risks first. Taking action and promptly mitigating critical risks reduces the chances of security breaches.
Finally, you should also have robust team onboarding and offboarding policies and procedures to ensure no user has unauthorized access once they have left the organization. For instance, during onboarding, ensure that new team members receive the appropriate access levels aligned with their roles and educate them on security best practices and the use of IAM tools. Offboarding, on the other hand, should involve a systematic process to immediately revoke access to all AWS tools once the employee leaves the organization. For example, use automated workflows that trigger access revocation procedures (such as disabling user accounts and removing IAM roles and permissions) as part of the offboarding checklist. This will prevent any unauthorized access post-departure.
Conclusion
In this guide, you learned about AWS IAM Access Analyzer and how to install it. You also reviewed some of the pitfalls of using IAM Access Analyzer and best practices to maintain robust access control within your AWS environment (whether it’s just one account or an organization with multiple accounts).
To further reinforce security and access control in your AWS environment, consider using ConductorOne. ConductorOne offers access reviews, access controls, integrations, and extensibility features that allow you to integrate with any environment. It also has solutions for compliance automation, zero standing privileges, and infrastructure access controls that allow you to protect your most sensitive cloud and on-prem infrastructure. Specifically, ConductorOne helps reinforce access control in AWS by automating the periodic review and certification of IAM roles and permissions, ensuring that only authorized users maintain access over time. Additionally, it provides detailed audit trails and reporting capabilities that enable you to track and document all access changes and compliance actions for regulatory requirements.