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 easy accessibility to steerage that may make it easier to to fine-tune your IAM insurance policies. Each of those new options construct on the Customized Coverage Checks and the Unused Entry evaluation that have 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 make it easier to to detect insurance policies that grant entry to particular, vital AWS assets, or that grant any kind of public entry. Each of the checks are designed for use forward of deployment, presumably as a part of your CI/CD pipeline, and can make it easier to 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 which you can share together with your builders in order that they’ll revoke permissions that grant entry that’s not truly 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 objects or to interchange them with extra restrictive ones.

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

Test No Public Entry – This test operates on a useful resource coverage, and checks to see if the coverage grants public entry to a specified useful resource kind. For instance, you may test a coverage to see if it permits public entry to an S3 bucket by specifying the AWS::S3::Bucket useful resource kind. Legitimate useful resource varieties embody DynamoDB tables and streams, EFS file methods, OpenSearch domains, Kinesis streams and stream customers, KMS keys, Lambda capabilities, S3 buckets and entry factors, S3 Specific listing buckets, S3 Outposts buckets and entry factors, Glacier, Secrets and techniques Supervisor secrets and techniques, SNS subjects and queues, and IAM coverage paperwork that assume roles. The listing of legitimate useful resource varieties will develop over time and will be discovered within the CheckNoPublicAccess documentation,

Let’s say that I’ve a coverage which by accident grants public entry to an Amazon Easy Queue Service (Amazon SQS) queue. Right here’s how I test 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 consequence:

{
    "consequence": "FAIL",
    "message": "The useful resource coverage grants public entry for the given useful resource kind.",
    "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 check out once more, and this time the test passes:

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

Test Entry Not Granted – This test operates on a single useful resource coverage or identification coverage at a time. It additionally accepts an listing of actions and assets, each within the type which are acceptable as a part of an IAM coverage. The test sees if the coverage grants unintended entry to any of the assets within the listing by the use of the listed actions. For instance, this test could possibly be used to guarantee that a coverage doesn’t enable a vital 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 test fails:

{
    "consequence": "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 check out once more, and this time the test passes, indicating that the coverage doesn’t grant entry to the listed assets:

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

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

A few of these are leftovers from instances once I was given early entry to a service in order that I might use after which weblog about it; others are as a result of my common ineptness as a cloud admin! Both manner, I would like 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 comply with the steps and delete the entry key or I can click on Archive to take away the discovering from the listing of energetic findings and add it to the listing of archived ones. I can even create an archive rule that may do the identical for related findings sooner or later. Comparable suggestions are supplied for unused IAM customers, IAM roles, and passwords.

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

The advice is to interchange 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 comply with the steps or I can archive the discovering.

The findings and the suggestions are additionally obtainable 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 whole 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 should utilize these instructions (or the equal API calls) to combine the suggestions into your individual instruments and methods.

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

— Jeff;