IAM Entry Analyzer Replace: Extending customized coverage checks & guided revocation

We’re making IAM Entry Analyzer much more highly effective, extending customized coverage checks and including quick access to steerage that can assist you to fine-tune your IAM insurance policies. Each of those new options construct on the Customized Coverage Checks and the Unused Entry evaluation that had been launched at re:Invent 2023. Right here’s what we’re launching:

New Customized Coverage Checks – Utilizing the ability of automated reasoning, the brand new checks assist you to detect insurance policies that grant entry to particular, crucial AWS assets, or that grant any sort of public entry. Each of the checks are designed for use forward of deployment, probably as a part of your CI/CD pipeline, and can assist you proactively detect updates that don’t conform to your group’s safety practices and insurance policies.

Guided Revocation – IAM Entry Analyzer now provides you steerage that you would be able to share along with your builders in order that they’ll revoke permissions that grant entry that isn’t really wanted. This contains unused roles, roles with unused permissions, unused entry keys for IAM customers, and unused passwords for IAM customers. The steerage contains the steps wanted to both take away the additional gadgets or to exchange them with extra restrictive ones.

New Customized Coverage Checks
The brand new coverage checks could be invoked from the command line or by calling an API perform. The checks look at a coverage doc that’s provided as a part of the request and return a PASS or FAIL worth. In each instances, PASS signifies that the coverage doc correctly disallows the given entry, and FAIL signifies that the coverage would possibly enable some or the entire permissions. Listed here are the brand new checks:

Test No Public Entry – This verify operates on a useful resource coverage, and checks to see if the coverage grants public entry to a specified useful resource sort. For instance, you possibly can verify a coverage to see if it permits public entry to an S3 bucket by specifying the AWS::S3::Bucket useful resource sort. Legitimate useful resource sorts embrace DynamoDB tables and streams, EFS file techniques, OpenSearch domains, Kinesis streams and stream customers, KMS keys, Lambda features, S3 buckets and entry factors, S3 Categorical listing buckets, S3 Outposts buckets and entry factors, Glacier, Secrets and techniques Supervisor secrets and techniques, SNS matters and queues, and IAM coverage paperwork that assume roles. The record of legitimate useful resource sorts will broaden over time and could be discovered within the CheckNoPublicAccess documentation,

Let’s say that I’ve a coverage which unintentionally grants public entry to an Amazon Easy Queue Service (Amazon SQS) queue. Right here’s how I verify it:

$ aws accessanalyzer check-no-public-access --policy-document file://useful resource.json 
  --resource-type AWS::SQS::Queue --output json

And right here is the end result:

{
    "end result": "FAIL",
    "message": "The useful resource coverage grants public entry for the given useful resource sort.",
    "causes": [
        {
            "description": "Public access granted in the following statement with sid: SqsResourcePolicy.",
            "statementIndex": 0,
            "statementId": "SqsResourcePolicy"
        }
    ]
}

I edit the coverage to take away the entry grant and take a look at once more, and this time the verify passes:

{
    "end result": "PASS",
    "message": "The useful resource coverage doesn't grant public entry for the given useful resource sort."
}

Test Entry Not Granted – This verify operates on a single useful resource coverage or id coverage at a time. It additionally accepts an record of actions and assets, each within the kind which might be acceptable as a part of an IAM coverage. The verify sees if the coverage grants unintended entry to any of the assets within the record by the use of the listed actions. For instance, this verify could possibly be used to make it possible for a coverage doesn’t enable a crucial CloudTrail path to be deleted:

$ aws accessanalyzer check-access-not-granted --policy-document file://ct.json 
  --access assets="arn:aws:cloudtrail:us-east-1:123456789012:path/MySensitiveTrail" 
  --policy-type IDENTITY_POLICY --output json

IAM Entry Analyzer signifies that the verify fails:

{
    "end result": "FAIL",
    "message": "The coverage doc grants entry to carry out a number of of the listed actions or assets.",
    "causes": [
        {
            "description": "One or more of the listed actions or resources in the statement with index: 0.",
            "statementIndex": 0
        }
    ]
}

I repair the coverage and take a look at once more, and this time the verify passes, indicating that the coverage doesn’t grant entry to the listed assets:

{
    "end result": "PASS",
    "message": "The coverage doc doesn't grant entry to carry out the listed actions or assets."
}

Guided Revocation
In my earlier publish I confirmed you ways IAM Entry Analyzer discovers and lists IAM gadgets that grant entry which isn’t really wanted. With right this moment’s launch, you now get steerage that can assist you (or your developer staff) to resolve these findings. Listed here are the newest findings from my AWS account:

A few of these are leftovers from instances after I was given early entry to a service in order that I may use after which weblog about it; others are attributable to my basic ineptness as a cloud admin! Both means, I want to wash these up. Let’s begin with the second, Unused entry key. I click on on the merchandise and may see the brand new Suggestions part on the backside:

I can observe the steps and delete the entry key or I can click on Archive to take away the discovering from the record of lively findings and add it to the record of archived ones. I also can create an archive rule that can do the identical for comparable findings sooner or later. Related suggestions are offered for unused IAM customers, IAM roles, and passwords.

Now let’s check out a discovering of Unused permissions:

The advice is to exchange the prevailing coverage with a brand new one. I can preview the brand new coverage side-by-side with the prevailing one:

As within the first instance I can observe the steps or I can archive the discovering.

The findings and the suggestions are additionally accessible from the command line. I generate the advice by specifying an analyzer and a discovering from it:

$ aws accessanalyzer generate-finding-recommendation 
  --analyzer-arn arn:aws:access-analyzer-beta:us-west-2:123456789012:analyzer/MyAnalyzer 
  --id 67110f3e-05a1-4562-b6c2-4b009e67c38e

Then I retrieve the advice. On this instance, I’m filtering the output to solely present the steps because the total JSON output is pretty wealthy:

$ aws accessanalyzer get-finding-recommendation 
  --analyzer-arn arn:aws:access-analyzer-beta:us-west-2:123456789012:analyzer/MyAnalyzer 
  --id 67110f3e-05a1-4562-b6c2-4b009e67c38e --output json | 
  jq .recommendedSteps[].unusedPermissionsRecommendedStep.recommendedAction
"CREATE_POLICY"
"DETACH_POLICY"

You need to use these instructions (or the equal API calls) to combine the suggestions into your individual instruments and techniques.

Obtainable Now
The brand new checks and the decision steps can be found now and you can begin utilizing them right this moment in all public AWS areas!

— Jeff;