10.2 Auditing External & Unused Access with IAM Access Analyzer

10.2 Auditing External & Unused Access with IAM Access Analyzer

Establishing and maintaining the principle of least privilege in enterprise AWS environments is an ongoing operational challenge. As multi-account environments scale, resource-based policies, role trust configurations, and cross-account delegations proliferate across thousands of workloads. Traditional security auditing mechanisms rely on pattern matching, regex scraping, or static linters. However, static linters frequently fail when evaluating complex JSON policies containing nested conditions, NotPrincipal elements, or multi-statement evaluation rules, resulting in dangerous false negatives or overwhelming alert fatigue from false positives.

AWS IAM Access Analyzer addresses this challenge by applying automated reasoning—a field of computer science that uses mathematical logic to prove security properties. Access Analyzer delivers three foundational security capabilities: continuous auditing of external access beyond designated trust boundaries, automated discovery of unused identities, stale credentials, and dormant permissions, and automated least-privilege policy generation derived directly from historical AWS CloudTrail activity.

---

Mathematical Foundations: Automated Reasoning vs. Heuristic Pattern Matching

Traditional cloud security posture management (CSPM) tools inspect policies using heuristic pattern matching. For example, a basic scanner searches for "Principal": "*" to flag an Amazon S3 bucket as publicly readable. However, modern enterprise policies frequently combine wildcard principals with strict condition keys:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAccessRestrictedToCorporateOrg",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::corp-internal-documents/*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalOrgID": "o-enterprise123"
        },
        "Bool": {
          "aws:SecureTransport": "true"
        }
      }
    }
  ]
}

A superficial pattern matcher flags this bucket as "publicly accessible" because of the * principal, creating a false positive. Conversely, a policy with dozens of overlapping allow and deny statements might inadvertently open access to external accounts through an omitted condition—a flaw that static scanners frequently miss.

IAM Access Analyzer avoids heuristics entirely. It converts IAM policies, resource policies, permission boundaries, and condition keys into formal mathematical logic formulas using Satisfiability Modulo Theories (SMT) solvers. The automated reasoning engine mathematically proves whether a viable logical path exists for an unauthorized principal outside the defined zone of trust to access a resource. This mathematical certainty guarantees comprehensive coverage without false alarms.

---

External Access Analyzers: Zones of Trust & Supported Resources

An external access analyzer identifies resources within your AWS environment that have been shared with an entity outside your designated Zone of Trust.

Defining the Zone of Trust

The zone of trust defines the perimeter within which access is considered legitimate and expected:

• Account-Level Analyzer: The zone of trust is restricted to the single AWS account where the analyzer is deployed. Access granted to any external AWS account, anonymous public user, or unauthenticated caller generates a finding.
• Organization-Level Analyzer: The zone of trust encompasses the entire AWS Organization. Deployed via the AWS Organizations Management Account or a designated Delegated Administrator account, this analyzer monitors all member accounts. Sharing resources between member accounts inside the organization does not generate findings; findings trigger only when access is granted to an entity outside the organization.

Monitored Resource Types

External access analyzers evaluate resource-based policies for 15 resource types: S3 general purpose and directory buckets, IAM roles, KMS keys, Lambda functions and layers, SQS queues, Secrets Manager secrets, SNS topics, EBS volume snapshots, RDS DB snapshots and DB cluster snapshots, ECR repositories, EFS file systems, and DynamoDB tables and streams. The most frequently tested are:

Internal Access Analyzers

Internal access analyzers (added in 2025) answer the opposite question: which IAM users and roles inside your organization or account can reach selected critical resources. They combine identity policies, resource policies, SCPs, RCPs, and permissions boundaries, and support S3 buckets and directory buckets, RDS DB snapshots and cluster snapshots, and DynamoDB tables and streams. Use them to find, for example, every role in the organization that can read a payroll bucket.

Loading diagram...

Findings Lifecycle and Archive Rules

When Access Analyzer detects external access, it generates a structured finding containing the affected resource ARN, the external principal, permitted actions, and matching condition keys. Findings follow a formal lifecycle:

• Active: The resource policy currently allows access to an external entity outside the zone of trust.
• Resolved: Access Analyzer automatically resolves the finding when the resource policy is modified to revoke the external access, or when the resource is deleted.
• Archived: The access has been evaluated and confirmed as intentional by a security administrator.

To prevent operational alert fatigue from known, approved external integrations (e.g., an external auditing firm assuming a read-only role or a public S3 bucket hosting static website assets), administrators configure Archive Rules:

• Archive rules specify criteria based on resource ARNs, principal ARNs, or condition keys.
• Incoming findings matching the archive rule criteria are automatically marked as Archived without alerting analysts.
• Existing active findings can be retroactively archived when an archive rule is created.
• Findings are published to Amazon EventBridge (detail-type: "Access Analyzer Finding"), enabling automated integration with AWS Security Hub, PagerDuty, or Jira ticketing pipelines.

---

Unused Access Analyzers: Continuous Auditing of Dormant Privileges

While external access analyzers secure perimeter boundaries, enterprise environments face an equally dangerous internal threat: dormant identities and excessive unused permissions. Over time, employees change roles, infrastructure testing roles are abandoned, and developers retain broad wildcard permissions that are never exercised in production.

An Unused Access Analyzer continuously evaluates IAM identities across an organization or individual account against an Unused Access Tracking Period (configurable from 1 to 365 days, with a standard default of 90 days).

Four Types of Unused Access Findings

1. Unused Roles: IAM roles with no access activity during the tracking period. Dormant roles should be reviewed and deleted so attackers can't use them for lateral movement.
2. Unused Access Keys: IAM user access keys that have not signed a request during the tracking period.
3. Unused Passwords: IAM user console passwords that have not been used to sign in during the tracking period.
4. Unused Permissions (Service & Action Level): Continuously compares the permissions granted in attached identity policies against actual API calls recorded in CloudTrail. If an IAM role has AmazonS3FullAccess but has only executed s3:GetObject over the past 90 days, Access Analyzer generates a finding listing all unused services (e.g., s3:DeleteBucket, s3:PutBucketPolicy) as unused.

Auditing Mechanism Comparison

---

Automated Policy Generation from CloudTrail Logs

Achieving true least privilege by manually authoring IAM policies is notoriously difficult. Developers frequently default to broad managed policies (PowerUserAccess, AmazonEC2FullAccess) because determining the exact set of dozens of micro-actions required by an application is time-consuming.

IAM Access Analyzer solves this through CloudTrail-Based Automated Policy Generation:

Loading diagram...

Step-by-Step Policy Generation Workflow

1. Run Workload in Staging: Deploy the application in a staging or integration test environment with broader permissions, and execute end-to-end regression suites and business workflows for a representative period (e.g., 30 to 60 days).
2. Initiate Generation (StartPolicyGeneration): Through the IAM console or CLI, start a policy generation task targeting the specific IAM role. Specify the CloudTrail trail that captures management and data events, along with the date range.
3. Automated Log Analysis: Access Analyzer queries the CloudTrail logs stored in Amazon S3, identifying every unique API action executed by the target principal ARN and extracting the associated resource ARNs.
4. Review Generated Policy (GetGeneratedPolicy): Access Analyzer outputs a syntactically valid JSON policy containing only the actions observed in the logs. For actions where CloudTrail cannot deterministically identify the exact resource ARN, the generated policy provides clearly marked placeholders (e.g., ${ResourceArn}) prompting the engineer to specify the exact ARN.
5. Attachment & Deprecation: The generated least-privilege policy is attached as a customer managed policy, and the legacy broad policy is detached.

---

Specialty Exam Pitfalls & Architectural Traps

1. Assuming Organization Analyzers Detect Intra-Organization Cross-Account Access: An organization-level analyzer considers all member accounts within the AWS Organization to be inside the zone of trust. If an S3 bucket in the Production Account allows access to an IAM role in the Development Account, an organization analyzer will not generate a finding! To detect cross-account sharing between internal accounts, you must deploy Account-Level Analyzers.
2. Know the Coverage Limits: External access analyzers cover 15 resource types (including DynamoDB tables and streams, SNS topics, ECR repositories, EFS file systems, and EBS/RDS snapshots), but not every resource policy: API Gateway resource policies and Amazon OpenSearch Service domain policies, for example, are not analyzed. Unused access analyzers cover only IAM users and roles.
3. S3 Block Public Access Is Considered: Access Analyzer accounts for S3 Block Public Access. When Block Public Access blocks a public bucket policy, no public finding remains (a cross-account access point finding may replace it). Bucket-level settings are re-evaluated whenever a policy changes, but account-level settings only every 6 hours, so findings can lag an account-level change.
4. Archive Rules Do Not Modify Resource Policies: Creating an archive rule merely suppresses the finding in the Access Analyzer console and prevents future EventBridge notifications. It does not alter, restrict, or revoke the underlying resource-based policy.