Remediate an Over-Permissive IAM Policy

Use IAM tools to find and fix excessive S3 policy permissions.

Introduction

30 Second Summary

An app that only needs to read files can become dangerous when its access quietly includes deletion. That hidden permission can sit unnoticed until someone checks each action.

In this project, you will review an over-permissive policy in AWS Identity and Access Management (IAM) for a fictional Amazon S3 reader. You will apply least privilege to prove the reader can list buckets and read objects without deleting them.

What You'll Build

You will rerun one access matrix to watch object deletion change from allowed to implicitly denied while the required reads stay allowed.

By the end of this project, you'll have:

A before-and-after test matrix from the IAM Policy Simulator that makes the unintended s3:DeleteObject permission visible.
A least-privilege policy you can simulate to confirm bucket listing and object reading for nw-security-lab.
An audit evidence pack showing the wildcard warning from IAM Access Analyzer, the corrected simulation, and the CreatePolicy event from AWS CloudTrail.
Secret Mission: Permit uploads only under uploads/ while keeping writes elsewhere and deletion implicitly denied.

Are there any prerequisites?

You need basic IT or networking knowledge. You also need an active AWS account with access to IAM simulation, policy validation, policy management, and CloudTrail Event history.

Before We Start

This first checkpoint frames a fictional Amazon S3 reader-policy review for a workload that lists the nw-security-lab bucket and reads its objects. The policy excludes s3:DeleteObject to protect data from a destructive action outside the workload's requirement.

Verify Your AWS Security Workspace

Your fictional Amazon S3 reader-policy review needs reliable console access. A blocked view would leave a gap in the review evidence.

This preflight checks the AWS Management Console before policy testing begins. You will stop before creating or attaching a policy.

You will confirm access to AWS Identity and Access Management (IAM). You will also confirm that AWS CloudTrail Event history is available.

In this step, get ready to:

Open the IAM Policy Simulator in Custom mode.
Open the IAM JSON Policy editor with its validation pane.
Confirm that CloudTrail Event history loads.

Open the IAM Policy Simulator

Custom mode accepts an identity-based policy before it is attached to an identity. The simulator evaluates authorization without performing the underlying API operation.

Your usual sign-in flow stays inside AWS. This preflight creates no cloud resources.

Sign in to the AWS Management Console using your usual account access method.
Enter IAM in the console search field.
Select AWS Identity and Access Management (IAM) from the search results.
Choose Policy simulator in the navigation pane.
Choose Custom mode.

Custom mode should load a policy editor without AccessDenied. This confirms that your identity can reach the simulator.

Policy Simulator Access Blocked?

A blocked Custom mode view means your identity lacks one or both simulator permissions.

Request iam:GetContextKeysForCustomPolicy for the custom-policy context check.
Request iam:SimulateCustomPolicy for Custom mode simulation.

Ask for targeted help with diagnosing IAM Policy Simulator access.

Check the JSON policy workspace

IAM Access Analyzer policy validation checks policy grammar against AWS best practices. Its pane sorts findings into Security, Errors, Warnings, and Suggestions.

Return to the IAM console tab from earlier.
Choose Policies in the navigation pane.
Choose Create policy.
Select JSON in the Policy editor.
Confirm that the policy validation pane shows Security, Errors, Warnings, and Suggestions.
Leave the JSON editor empty.
Leave the editor open without choosing Create policy.

The JSON editor and validation pane should load without AccessDenied. You have not submitted a policy.

Policy Workspace Access Blocked?

Request only the permissions required for policy validation and policy management.

Request access-analyzer:ValidatePolicy for the policy validation pane.
Request iam:CreatePolicy for the later policy creation task.
Request iam:DeletePolicy for the later cleanup task.
Request iam:ListPolicies for finding customer managed policies.
Request iam:GetPolicy for reviewing policy details.

Ask for targeted help with diagnosing the blocked IAM policy workspace.

Confirm CloudTrail Event history

CloudTrail Event history records recent management events within each AWS Region. It provides an audit view without requiring you to create a trail.

Enter CloudTrail in the AWS Management Console search field.
Select CloudTrail from the search results.
Choose Event history in the navigation pane.
Confirm that recent management events load without AccessDenied.

You should see the Event history table populated with recent management events. This confirms that your identity can look up recorded activity.

Event History Access Blocked?

Event history is regional. A different AWS Region can show a different event list.

Request cloudtrail:LookupEvents if Event history is blocked.

Ask for targeted help with diagnosing CloudTrail Event history access.

Before the final access check, do you expect every required view to load without an access denial?

Return to Custom mode in IAM Policy Simulator.
Confirm that its policy editor loads without AccessDenied.
Return to JSON in the IAM Policy editor.
Confirm that the policy validation pane remains visible.
Return to CloudTrail Event history.
Confirm that recent management events remain visible.

That access hurdle is cleared. Your workspace can now support the review from simulation through audit.

No policy has been created or attached. No policy evidence has been collected yet.

Your AWS security workspace is ready. Next, you will safely simulate a broad policy to expose the destructive access it grants.

Simulate the Over-Permissive Policy

Your access preflight proved that the required AWS security views are available. The reader workload now needs a baseline showing how a wildcard policy behaves.

A wildcard explicit allow can satisfy the read requirement while quietly granting object deletion. In this step, the AWS Identity and Access Management (IAM) Policy Simulator tests that gap against specific Amazon Resource Names (ARNs) without creating a policy.

In this step, get ready to:

Load the intentionally broad policy into Custom mode.
Test bucket listing, object reading, and object deletion against the supplied S3 resources.
Record a three-action test matrix that exposes the destructive permission.

Load the broad policy

Custom mode evaluates an identity-based policy before it is attached to an AWS identity. The broad policy uses wildcards to grant every action against every resource.

Switch back to Policy simulator in IAM.
Confirm that Custom mode is selected.
Load the intentionally broad policy by replacing the editor contents with the JSON below:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "OverPermissiveAccess",
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

What Does This Policy Do?

The Version value selects the 2012-10-17 IAM policy language.
The OverPermissiveAccess statement identifier labels the permission being tested.
The Allow effect creates an explicit grant.
The * values extend that grant to every action and every resource.

Review the policy editor for the version, statement identifier, effect, action, and resource fields.

The editor should now contain one statement named OverPermissiveAccess. Both the action and resource fields should contain *.

The policy exists only inside the current simulation. No customer managed policy has been created or attached.

Policy Does Not Load?

Confirm that the editor contains every brace and quotation mark shown above. A missing character prevents IAM from reading the JSON structure.

Check that Custom mode remains selected before retrying.

Ask for targeted help with diagnosing the policy input.

Build the action test matrix

Amazon S3 evaluates bucket listing against a bucket ARN. Object reads and object deletes target a full object ARN.

Using the matching resource for each action makes the comparison meaningful. The matrix can then expose whether the policy grants destructive access.

Add s3:ListBucket to the simulation.
Set its resource to arn:aws:s3:::nw-security-lab.

You should now see a bucket-listing test associated with arn:aws:s3:::nw-security-lab.

Add s3:GetObject to the simulation.
Set its resource to arn:aws:s3:::nw-security-lab/sample.txt.

You should now see an object-read test associated with arn:aws:s3:::nw-security-lab/sample.txt.

Add s3:DeleteObject to the simulation.
Set its resource to arn:aws:s3:::nw-security-lab/sample.txt.

Your matrix should now contain three action-and-resource tests. The two object actions should use the same sample.txt ARN.

Run the designed failure

A simulation evaluates authorization decisions without sending a real S3 API request. The fictional nw-security-lab bucket does not need to exist.

Why Custom Mode?

Custom mode evaluates an unattached identity-based policy before application. It can simulate resources that do not exist.

This keeps the designed failure safe. No real S3 API request is sent.

Before you run the simulation, do you think the wildcard will distinguish the destructive action from the two required actions?

Run the simulation.

You should see an allowed decision for s3:ListBucket. You should also see an allowed decision for s3:GetObject.

You should see an allowed decision for s3:DeleteObject. This destructive result is the designed failure.

You have captured the exact security gap this review needs to fix. The wildcard grants the reader workload permission to delete the simulated object.

Results Do Not Match?

Confirm that the policy editor still contains * for both Action and Resource.

Check that s3:ListBucket uses the bucket ARN. Check that the two object actions use the full sample.txt ARN.

Ask for help with troubleshooting the unexpected simulation results.

Your baseline now proves that the wildcard policy exceeds the workload's read requirement. Next, you will connect that result to IAM policy validation findings.

Diagnose the Wildcard Risk

Your IAM Policy Simulator baseline has exposed the dangerous symptom. The broad policy allows a destructive Amazon S3 deletion that the fictional reader workload never needs.

IAM Access Analyzer policy validation now explains why the statement is unsafe. You will capture that diagnosis without creating or attaching the policy.

In this step, get ready to:

Place the broad policy in IAM's JSON Policy editor without creating it.
Review the validation categories to find the wildcard warning.
Capture evidence that links the wildcard finding to the allowed deletion result.

Validate the broad policy

An identity-based policy can pass syntax checks while granting far more access than a workload needs. Policy validation also checks IAM grammar against AWS security best practices.

Copy the entire broad policy from the policy input in the Policy simulator Custom mode view from earlier.
Return to the JSON tab in the Policy editor from earlier.
Replace the editor contents with the copied broad policy.

The validation pane should now analyze the same statement that allowed object deletion. The policy remains an unsaved draft.

Keep the broad policy uncreated by leaving Next untouched.

Validation Pane Is Empty?

Confirm that the broad policy appears in the JSON editor.
Confirm that the policy contains an Action value of *.
Confirm that the policy contains a Resource value of *.

Ask for targeted help with diagnosing an empty IAM policy validation pane.

Inspect the wildcard finding

The validation pane separates findings by severity and purpose. Reviewing every category helps you distinguish policy syntax problems from security guidance.

Select the Security tab in the policy validation pane.
Check whether the Security tab lists a finding for the broad statement.
Select the Errors tab.
Check whether the Errors tab reports a policy grammar problem.
Select the Warnings tab.
Expand the general warning about wildcard action and resource use.
Select the Suggestions tab.
Check whether the Suggestions tab provides additional policy-authoring guidance.

The validation results should include a general warning with the check code CREATE_SLR_WITH_STAR_IN_ACTION_AND_RESOURCE. This gives you a concrete diagnosis for the wildcard statement.

Why Does the Wildcard Matter?

An Action value of * grants every supported action. A Resource value of * applies that grant across every resource supported by each action.

The named warning highlights iam:CreateServiceLinkedRole as one consequence. Your test matrix exposes s3:DeleteObject as another consequence.

Cannot Find the Warning?

Confirm that the editor still contains "Action": "*".
Confirm that the same statement still contains "Resource": "*".
Return to the Warnings tab after correcting either value.

Ask for help with finding the wildcard policy warning.

Capture the diagnosis

Audit evidence should connect a policy-authoring finding to an observed access decision. Your evidence will preserve that connection for the remediation step.

Return to the Warnings tab in the policy validation pane.
Expand the wildcard action and resource finding.

The expanded details should identify a general warning. The statement reference should point to OverPermissiveAccess.

The remediation guidance should recommend narrowing the wildcard permissions to the actions and resources the workload requires.

Keep the policy statement visible beside the expanded finding.
Capture the visible policy editor and validation finding with your usual screenshot method.
Save the capture with the evidence name 02-wildcard-validation.

Your evidence now preserves the finding category. It also shows the affected statement and the remediation direction.

Before you compare the two records, do you expect the validation finding to name s3:DeleteObject directly?

Return to the baseline test matrix from the previous step.
Compare the s3:DeleteObject result with the wildcard warning.
Return to the Warnings tab in the policy validation pane.
Confirm that the general warning includes CREATE_SLR_WITH_STAR_IN_ACTION_AND_RESOURCE.
Confirm that the broad policy remains uncreated.

The simulator shows the concrete allowed result for s3:DeleteObject. The validator identifies the wildcard pattern that made excessive access possible.

You have traced the destructive permission back to its wildcard cause. Next, you will replace that broad access with exact read actions and matching S3 resource ARNs.

Enforce Least Privilege and Retest

Your earlier IAM Policy Simulator run exposed the destructive permission. Your validation evidence traced that result to the wildcard statement.

This step applies least privilege to the Amazon S3 reader policy. The same test matrix proves whether the required reads survive while deletion becomes denied.

In this step, get ready to:

Replace the wildcard statement with exact S3 actions and matching resource ARNs.
Rerun the original action test matrix against the same simulated resources.
Confirm that policy validation no longer reports the wildcard action and resource warning.

Define exact Amazon S3 permissions

An identity-based policy grants access through its statements. Separate statements keep each S3 action aligned with the resource format it supports.

Switch back to IAM Policy Simulator in Custom mode from earlier.
Select the broad JSON in the custom policy editor.
Paste this policy over the selected JSON:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListLabBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::nw-security-lab"
    },
    {
      "Sid": "ReadLabObjects",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::nw-security-lab/*"
    }
  ]
}

Why Are There Two Statements?

The ListLabBucket statement grants s3:ListBucket on the bucket ARN.
The ReadLabObjects statement grants s3:GetObject on every object ARN inside the simulated bucket.
No statement grants s3:DeleteObject. The default deny controls that action.

Confirm that Custom mode now shows only the ListLabBucket and ReadLabObjects statements.

Policy JSON Not Accepted?

Check that the policy begins with one opening brace and ends with one closing brace.
Confirm that each statement retains its comma exactly as shown.

Ask for targeted help with diagnosing the least-privilege policy JSON.

✔️ Awesome, I've got everything!

Great. Your simulator policy now matches the least-privilege artifact.

ⓧ I'd like to double check the full code

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListLabBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::nw-security-lab"
    },
    {
      "Sid": "ReadLabObjects",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::nw-security-lab/*"
    }
  ]
}

Rerun the original test matrix

An implicit deny applies when no policy statement allows an action. Reusing the original tests isolates the policy change as the reason for each new result.

Configure one test for s3:ListBucket against arn:aws:s3:::nw-security-lab.
Configure one test for s3:GetObject against arn:aws:s3:::nw-security-lab/sample.txt.
Configure one test for s3:DeleteObject against arn:aws:s3:::nw-security-lab/sample.txt.

Before you rerun the matrix, which action do you think has lost its explicit permission?

Start the simulation.

The rerun shows Allowed for s3:ListBucket. It shows Allowed for s3:GetObject.

The result for s3:DeleteObject is now Implicitly denied. This is the visible proof that the destructive permission is gone.

Update the s3:ListBucket row in your test matrix to Allowed.
Update the s3:GetObject row in your test matrix to Allowed.
Update the s3:DeleteObject row in your test matrix to Implicitly denied.

Deletion Still Allowed?

Confirm that Custom mode contains only the two scoped statements.
Check that no remaining statement contains a wildcard in Action.
Rerun s3:DeleteObject against the full object ARN.

Ask for help with finding why deletion remains allowed.

Validate the remediated policy

IAM Access Analyzer policy validation checks the JSON against policy grammar and AWS security practices. This final check confirms that the remediation removes the earlier wildcard finding without introducing a syntax problem.

Switch back to the IAM JSON Policy editor from earlier.
Replace the broad policy with the least-privilege policy shown above.

Before you review the validation pane, do you expect the wildcard action and resource warning to remain?

Review the Errors tab in the policy validation pane.
Review the Warnings tab for the earlier wildcard finding.

You should see no syntax error. The previous wildcard action and resource warning no longer applies to this policy.

You have closed the risky gap. Required reads still work while object deletion remains denied.

Validation Still Shows a Problem?

Compare the editor JSON with the full least-privilege-policy.json reference above.
Confirm that neither statement contains "Action": "*".
Confirm that neither statement contains "Resource": "*".

Ask for targeted help with understanding the remaining validation finding.

Your remediated policy now passes the simulator and validation checks. Next, you will create the customer managed policy so the approved change produces auditable evidence.

Create, Audit, and Remove the Policy

Your simulation now proves that the policy preserves bucket listing plus object reading. The same evidence shows that object deletion is implicitly denied.

This step turns the validated policy into a temporary customer managed policy in AWS Identity and Access Management (IAM). You will preserve its AWS CloudTrail audit evidence before deleting the temporary resource.

In this step, get ready to:

Create the validated policy without attaching it to an identity.
Trace the policy creation through CloudTrail Event history.
Delete the temporary policy and confirm that it is gone.

Create the approved policy

A customer managed policy becomes a reusable IAM resource. It affects access only after an identity receives an attachment.

You can make this change safely because the policy stays unattached. The creation confirmation becomes your immediate evidence of the approved change.

Switch back to the IAM JSON Policy editor from earlier.
Confirm that the policy validation pane still reports no syntax error.
Compare the editor with least-privilege-policy.json by choosing the tab that matches your confidence:

✔️ Awesome, I've got everything!

Your editor contains the validated bucket-listing statement plus the validated object-reading statement. The policy is ready for creation.

ⓧ I'd like to double check the full code

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListLabBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::nw-security-lab"
    },
    {
      "Sid": "ReadLabObjects",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::nw-security-lab/*"
    }
  ]
}

Why Are the Statements Separate?

The s3:ListBucket action targets the bucket ARN. The s3:GetObject action targets object ARNs beneath that bucket.

Keeping these resources separate preserves the exact access pattern that your test matrix approved.

Choose Next.
Review the Permissions defined in this policy section on Review and create.
Enter NextWorkS3ReadOnlyPolicy in the Policy Name field.
Choose Create policy.

You should see an IAM creation success confirmation for NextWorkS3ReadOnlyPolicy. The policy should have no attached users, groups, or roles.

That is the approved change recorded. Your validated policy now exists as an auditable IAM resource.

Policy Creation Blocked?

Confirm that the JSON editor still reports no syntax error. Check that your signed-in identity has iam:CreatePolicy permission.

Ask for targeted help with diagnosing the policy creation failure.

Trace the creation event

CloudTrail Event history records recent management events for an AWS Region. The IAM creation confirmation remains your immediate proof while the new event becomes visible.

Switch back to CloudTrail Event history from earlier.
Select Event name as the lookup attribute.
Enter CreatePolicy as the full event name.

Before you apply the filter, do you expect the new management event to be visible yet?

Apply the Event name filter.

✔️ I see the CreatePolicy event

The matching event connects your IAM policy creation to the identity that performed it. Record the fields that make this change traceable.

Open the matching CreatePolicy event.
Record eventTime in your audit notes.
Record userIdentity in your audit notes.
Record eventName as CreatePolicy.
Record eventSource as iam.amazonaws.com.

These details show when the change happened. They also identify who requested it through IAM.

ⓧ The event is not visible yet

CloudTrail events can take time to appear. Give the event a few minutes before checking again.

Retain the IAM creation success evidence.
Wait a few minutes.
Refresh Event history.
Check the AWS Region selector for another Region where the IAM event may have been recorded.
Reapply the CreatePolicy event-name filter.
Proceed to cleanup after preserving the immediate IAM evidence.

Event Still Missing?

Confirm that the policy creation succeeded before repeating the search. Make sure the filter contains the full value CreatePolicy.

Ask for help with finding the IAM event in CloudTrail.

Your evidence pack now has immediate IAM creation proof. The CloudTrail record strengthens that evidence when it becomes available.

Delete the temporary policy

Cleanup closes the security review by removing the temporary customer managed policy. Your saved creation evidence remains available for the review.

Deleting the policy looks final. This is the intended cleanup because no workload depends on the unattached resource.

Switch back to IAM Policies from earlier.
Search for NextWorkS3ReadOnlyPolicy.
Select NextWorkS3ReadOnlyPolicy.
Choose Actions.
Choose Delete.
Confirm that you want to delete the policy.
Choose Delete to complete the removal.

Before you search again, do you expect IAM to return the deleted policy?

Search IAM Policies for NextWorkS3ReadOnlyPolicy again.

You should see no result for NextWorkS3ReadOnlyPolicy. This empty result proves that the temporary IAM resource has been removed.

That closes the review loop. You created an approved policy, preserved its audit evidence, and confirmed its cleanup.

Policy Still Appearing?

Refresh the IAM Policies list. Confirm that the search uses the complete name NextWorkS3ReadOnlyPolicy.

Ask for targeted help with removing the remaining customer managed policy.

Secret mission

Allow Uploads to One Prefix Only

Extend your read policy with one upload path under uploads/. Prove that uploads elsewhere and deletion remain implicitly denied.

Clean Up Your Resources

The temporary customer managed policy in AWS Identity and Access Management (IAM) is already deleted. No live AWS resource remains, so this project has no ongoing charges.

Resources you used:

The temporary customer managed policy named NextWorkS3ReadOnlyPolicy, which is already deleted.
The validated least-privilege-policy.json policy file.
The validated secret-mission-policy.json policy file.
The before-and-after test matrix from IAM Policy Simulator.
The 02-wildcard-validation evidence from IAM Access Analyzer policy validation.
The IAM creation success evidence plus the AWS CloudTrail Event history record when available.

Keep everything running

Choose this option if you want to keep your policy-review evidence for future practice. No AWS resource needs to remain active.

Keep least-privilege-policy.json as your validated read-only policy.
Keep secret-mission-policy.json as your prefix-scoped upload example.
Retain the before-and-after test matrix.
Retain the 02-wildcard-validation evidence.
Retain the IAM creation success evidence.
Retain the CloudTrail event details when available.

Your evidence pack remains ready to demonstrate the complete review loop. The temporary IAM policy stays deleted.

Pause - I'll come back to this later

There is no live AWS resource to pause. Preserve your evidence before ending the current console session.

Keep both validated JSON policy files unchanged.
Keep the simulation results with your review evidence.
Keep the policy-validation finding with your review evidence.
Keep the IAM creation evidence with your review evidence.
Keep the CloudTrail event details when available.
End the current AWS Management Console session from the account menu.

The temporary policy remains deleted. Your saved evidence is ready when you return.

Delete - I don't want to use this again

Remove the saved evidence if you no longer need this lab record. The AWS policy itself already has no further delete action.

Return to IAM from earlier.
Choose Policies in the navigation pane.
Search for NextWorkS3ReadOnlyPolicy.

You should see no matching policy. This confirms that the only customer managed AWS resource from the project remains deleted.

Open File Explorer from the Windows taskbar.
Use Windows search to locate least-privilege-policy.json.
Delete the matching least-privilege-policy.json file.
Use Windows search to locate secret-mission-policy.json.
Delete the matching secret-mission-policy.json file.
Use Windows search to locate 02-wildcard-validation.
Delete the matching validation evidence.
Delete the retained test matrix from its saved location.
Delete the retained IAM creation evidence from its saved location.
Delete the retained CloudTrail event details from their saved location.

Windows search should no longer return either JSON policy file or the named validation evidence. IAM should still return no result for NextWorkS3ReadOnlyPolicy.

Nice Work!

You did it! You completed the AWS Identity and Access Management (IAM) review from unsafe simulation to verified cleanup.

You've learned how to:

Build a repeatable action-and-resource test matrix with the IAM Policy Simulator. Expose s3:DeleteObject as allowed by the wildcard policy.
Diagnose the wildcard risk with IAM Access Analyzer policy validation. Replace broad access with a least-privilege policy that uses matching Amazon Resource Names (ARNs) for Amazon S3. Prove required reads stay allowed while deletion becomes implicitly denied.
Capture lifecycle evidence for NextWorkS3ReadOnlyPolicy from creation through deletion. Trace the CreatePolicy management event in AWS CloudTrail. Confirm cleanup with a policy search that returns no result.
Secret Mission: Scope s3:PutObject to arn:aws:s3:::nw-security-lab/uploads/*. Prove uploads under arn:aws:s3:::nw-security-lab/private/new.txt stay implicitly denied. Confirm deletion remains implicitly denied.

Your review instincts have had a full workout. Take the quiz to see what stuck.