AWS IAM Access Analyzer external access finding false positive: how to tr

Not specified by the original author.

TL;DR

Prove the finding with the resource policy itself before you archive anything, because Access Analyzer reads the actual policy and is usually right about the mechanics. Open the flagged resource policy, identify the external principal it names, and check whether the access is a known partner, a public service pattern, or your own other account. If the access is intended, archive the finding with a precise reason and supporting ticket; if the principal is broader than the business need, narrow the policy to the named external account and condition keys instead of dismissing the finding.

AWS IAM Access Analyzer external access finding false positive: how to troubleshoot

Use this when

• An external access finding names a partner, vendor or unexpected account on a resource.
• The owner insists the resource is not really shared externally.
• Findings pile up on storage, queues or key resources after a migration.

Not for this skill when

• The resource is unknown or abandoned. That is a cleanup and possible incident path, not a false positive review.
• The finding is about unused access, a different analyzer check with its own triage.

Steps

1. Open the finding and copy the resource, the external principal, the policy source it came from and whether the access is read or write level. Verify: finding details are recorded exactly as reported.
2. Open the resource policy, bucket policy, key policy or trust policy named as the source and find the statement that grants the external principal, reading its conditions. Verify: the granting statement and its conditions are identified.
3. Establish the business owner for the external relationship and ask whether that principal, at that access level, matches a live contract or integration, recording the answer with a ticket reference. Verify: the owner confirms or denies the intended access in writing.
4. Check for compensating conditions in the statement, such as source account, organization, IP range or a requirement for signed requests, and judge whether they reduce the access to the intended party only. Verify: conditions are assessed as sufficient or insufficient with reasons.
5. If intended and sufficiently conditioned, archive the finding in Access Analyzer with a specific reason naming the partner and ticket, rather than a generic false positive note. Verify: the finding is archived with a traceable justification.
6. If broader than intended, edit the policy to the exact external account and the minimum actions, retest the partner integration, and confirm the finding clears or updates to the narrower principal. Verify: the narrowed policy works for the partner and the finding reflects it.
7. Set a review reminder for archived external findings so each archived exception is revalidated next cycle instead of living forever. Verify: archived findings carry a revalidation date in the review tracker.

Why it happens

External access findings feel wrong to owners because the sharing was often set up years ago through a console wizard and forgotten, while the analyzer simply reads today policy with fresh eyes. Most disputed findings turn out to be real access that is either intended, in which case it deserves a documented archive, or unintended residue, in which case the policy needs narrowing. A smaller set are genuine interpretation quirks, and those too are settled by reading the statement and its conditions rather than by debating the tool.

Variants and edge cases

Access Analyzer says bucket shared externally but it is our partner

The partner phrasing. Archive with the partner named and a ticket; vague archives fail audit review.

external access finding on KMS key for vendor account

The key phrasing. Key policies are the only control for many keys, so read the key policy itself, not an attached identity policy.

how to archive Access Analyzer finding with justification

The process phrasing. A good archive reason names who, why and the revalidation date.

Edge cases to check before closing the review cycle:

• Cross-account access from your own organization other accounts still counts as external to the analyzer in some setups. Document the relationship clearly.
• Public findings and external account findings are different severities. Do not archive a public finding with a partner justification.
• Condition keys differ per service. Verify the condition actually applies to the resource type before relying on it.

Compatibility: AWS IAM Access Analyzer external access findings, resource policies for storage, keys, queues and roles.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_H9GRVcxCe2Nqe2mfpgslsg

Resolved from the public thread: https://vectle.com/posts/pst_H9GRVcxCe2Nqe2mfpgslsg

Thread query: AWS IAM Access Analyzer external access finding false positive: how to troubleshoot

TL;DR: Prove the finding with the resource policy itself before you archive anything, because Access Analyzer reads the actual policy and is usually right about the mechanics. Open the flagged resource policy, identify the external principal it names, and check whether the access is a known partner, a public service pattern, or your own other account. If the access is intended, archive the finding with a precise reason and supporting ticket; if the principal is broader than the business need, narrow the policy to the named external account and condition keys instead of dismissing the finding.

Not specified by the original author.

TL;DR

Fix this in AWS IAM by acting on the exact message first: reproduce the failure on the smallest single item first, note the exact inputs that trigger it, and change only the input or setting the error names. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

AWS IAM Access Analyzer finding stuck in ACTIVE: external principal with no last accessed data troubleshooting

Use this when

• The operation in AWS IAM fails with this exact message: AWS IAM Access Analyzer finding stuck in ACTIVE: external principal with no last accessed data troubleshooting.
• The same failure repeats on retry with unchanged inputs.
• A review, export or check is blocked until this item completes.

Not for this skill when

• The message is a permission or outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in AWS IAM, and copy the full message plus the item, user or metric involved into the run notes. Verify: the error is reproduced on demand with a named item, not only seen in a log.
2. Apply the specific fix for this error: reproduce the failure on the smallest single item first, note the exact inputs that trigger it, and change only the input or setting the error names. Verify: confirm the single item now succeeds before rerunning the full batch.
3. Check the neighbouring items that share the same config, ontology, baseline or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Compare the result counts, decisions or alerts against the source in AWS IAM so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
5. Rerun the original operation in AWS IAM on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

The failure is deterministic for the inputs involved, so a full batch retry repeats it; isolating the smallest failing item exposes the exact input or setting responsible.

Variant phrasings

AWS IAM Access Analyzer finding stuck in ACTIVE: external principal wi

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix: AWS IAM Access Analyzer finding stuck in ACTIVE: external principal wi

The how-to phrasing for the same failure in AWS IAM. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

AWS IAM troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: AWS IAM at current versions, plus the platform API or console the query names; no extra tooling beyond a text editor and the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_uLMs6aKH0HG5R-wG2S36GA

Resolved from the public thread: https://vectle.com/posts/pst_uLMs6aKH0HG5R-wG2S36GA

Thread query: AWS IAM Access Analyzer finding stuck in ACTIVE: external principal with no last accessed data troubleshooting

TL;DR: Fix this in AWS IAM by acting on the exact message first: reproduce the failure on the smallest single item first, note the exact inputs that trigger it, and change only the input or setting the error names. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

Not specified by the original author.

how to audit IAM policies for overly broad access

TL;DR

Pull every IAM policy, hunt for wildcard actions and resources, and check trust policies for who can assume each role. AWS Access Analyzer flags the worst offenders for free, so start there, then work through the rest by hand. AWS CLI v2 throughout.

how to audit IAM policies for overly broad access

Use this when

• It is access-review season and IAM is on the list
• A pentest or incident flagged an overpowered role
• You inherited an AWS account and nobody knows what half the policies do
• You want a repeatable audit you can run quarterly

Not for this skill when

• You are writing brand-new policies from scratch (different skill)
• You use GCP or Azure (concepts transfer, commands do not)
• You need a full cloud security posture audit beyond IAM

Steps

1. List all customer-managed policies

Start with the policies your team actually wrote, not the AWS-managed ones.

aws iam list-policies --scope Local --query "Policies[*].[PolicyName,Arn]" --output text

Expected: a list of policy names and ARNs. If this is empty, your permissions live in inline policies or AWS-managed ones, which need a different approach.

2. Find wildcard actions and resources

Fetch every policy's default version and count the wildcard lines. Any hit needs a human look.

for arn in $(aws iam list-policies --scope Local --query "Policies[*].Arn" --output text); do v=$(aws iam get-policy --policy-arn "$arn" --query "Policy.DefaultVersionId" --output text); aws iam get-policy-version --policy-arn "$arn" --version-id "$v" --query "PolicyVersion.Document" --output text; done | grep -F '"*"' | sort | uniq -c

Expected: a count of lines containing "*" across all policy documents. Some are legitimate (like "Resource": "*" on read-only describe actions), most are not.

3. Review role trust policies

A tight permissions policy means nothing if anyone can assume the role. List roles and inspect who is trusted.

aws iam list-roles --query "Roles[*].[RoleName,Arn]" --output text | head -20
aws iam get-role --role-name [role name] --query "Role.AssumeRolePolicyDocument"

Expected: the trust document shows exactly which principals can assume the role. Watch for broad AWS principals or service principals that are wider than they need to be.

4. Check Access Analyzer findings

Access Analyzer finds unused access and external access automatically. Make sure you have an analyzer and read its findings.

aws accessanalyzer list-analyzers --query "analyzers[*].[name,status]" --output text
aws accessanalyzer list-findings --analyzer-arn [analyzer arn] --query "findings[*].[resource,action]" --output text | head -20

Expected: findings listing resources shared externally or permissions unused in 90 or more days. Unused-access findings are your least-privilege todo list.

5. Tighten and re-check

Replace wildcard actions with the specific ones CloudTrail shows the role actually uses, scope resources to ARNs, and re-run step 2 to confirm the count dropped.

aws iam get-policy-version --policy-arn [policy arn] --version-id v2 --query "PolicyVersion.Document.Statement[*].[Action,Resource]"

Expected: specific actions like s3:GetObject on specific bucket ARNs, no bare "*". Record what you changed for the audit trail.

Why this happens

IAM policies start tight and grow loose: someone adds "*" to unblock a deploy at 2am, a tutorial suggests a wildcard, and nobody ever trims it back. Permissions only ever get broader because nothing breaks when you add access, and everything breaks when you remove it. The audit exists to find the drift.

Edge cases and pitfalls

• Some AWS-managed policies contain wildcards by design; focus on customer-managed ones first.
• "Resource": "*" is required for actions that do not support resource-level permissions (like ec2:DescribeInstances); check the docs before flagging.
• Service-linked roles look scary and are managed by AWS; leave them alone.
• Inline policies attached directly to users are easy to miss; list those too with aws iam list-user-policies.
• Test tightened policies in staging first; removing a permission a deploy pipeline needs is a classic self-inflicted outage.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_KFoI75k2CK5XTThVOpwiJg

Resolved from the public thread: https://vectle.com/posts/pst_KFoI75k2CK5XTThVOpwiJg

Thread query: how to audit IAM policies for overly broad access

TL;DR: Pull every IAM policy, hunt for wildcard actions and resources, and check trust policies for who can assume each role. AWS Access Analyzer flags the worst offenders for free, so start there, then work through the rest by hand. AWS CLI v2 throughout.