Using AWS IAM Access Analyzer to Find and Resolve Issues

In our lab walkthrough series, we go through selected lab exercises on our INE Platform. Subscribe or sign up for a 7-day, risk-free trial with INE and access this lab and a robust library covering the latest in Cyber Security, Networking, Cloud, and Data Science!

Purpose: Access Analyzer helps you identify the resources in your organization and accounts that are shared with an external entity. It validates IAM policies against policy grammar and best practices. And also generates IAM policies based on access activity in your AWS CloudTrail logs. Here, we'll learn how to create an Access Analyzer and utilize it to get rid of permissions that are overly permissive and could be used maliciously by an attacker.

Technical difficulty:

What does it do and how does it work?

It assists you in identifying the resources in your organization and accounts that are shared with an external entity, such as Amazon S3 buckets or IAM roles (AWS accounts, root users, IAM users and roles, federated users, AWS services, anonymous users, and other entities that you can use to create filters are examples of external entities). This allows you to detect unauthorized access to your resources and data, which poses a security risk. Access Analyzer identifies resources shared with external principals by analyzing the resource-based policies in your AWS environment using logic-based reasoning.

Access Analyzer examines the resource-based policies applied to AWS resources in the Region where Access Analyzer is enabled. Access Analyzer does not examine access logs to determine whether a resource within your zone of trust was accessed by an external entity. It generates a finding when a resource-based policy allows access to a resource, even if the resource was not accessed by the external entity.

When making its determination, Access Analyzer also does not consider the state of any external accounts. That is, even if it indicates that account 0011223344 has access to your S3 bucket, it has no knowledge of the account's users, roles, service control policies (SCP), or other relevant configurations. Access Analyzer does not consider who owns the other account. It's also for security; even if the account isn't owned by the Access Analyzer customer, it's important to know that an external entity could gain access to their resources, even if there are no principals in the account who can access them right now.

Access Analyzer analyzes the following resource types:

Amazon Simple Storage Service buckets
AWS Identity and Access Management roles
AWS Key Management Service keys
AWS Lambda functions and layers
Amazon Simple Queue Service queues
AWS Secrets Manager secrets

Now Let’s Discuss the Findings:

Access Analyzer generates a finding for each instance of a resource shared outside of your account. The findings include details about the access and the external principal who granted it. When you create an analyzer, you choose an organization or AWS account to analyze. Any principal in the organization or account that you choose for the analyzer is considered trusted.

Access Analyzer generates a finding for each instance of a resource-based policy that grants access to a resource within your zone of trust to a principal that is not within your zone of trust. Any sharing that is within the zone of trust is considered safe, so Access Analyzer does not generate a finding.

Now that we have covered all the key terms for the lab, let's carry out the experiment.

Lab Scenario

We have set up the below scenario in our INE labs for our students to practice. The screenshots have been taken from our online lab environment.

Lab Link: Access Analyzer

Objective

Create an Analyzer using the Access Analyzer and find issues (overly permissive permissions) and resolve those issues.

Solution

Step 1: Click the lab link button to get access credentials. Login to the AWS account with these credentials.

Step 2: Search for “IAM” and navigate to the IAM dashboard.

Step 3: Click on “Access analyzer” from the access reports.

Step 4: Click on “Create analyzer”.

Step 5: Set everything as default and click on “Create analyzer”.

After the successful creation of an access analyzer, it identifies resources shared with external principals by using logic-based reasoning to analyze the resource-based policies in your AWS environment and list them as findings in the active findings table.

Step 6: Click on “Finding ID” of the resource “Secret”. This will list details about the finding.

This finding informs that the resource has been shared with an external AWS account having an id 002763723555.

This page also includes information about the access and the external principal granted to it.

NOTE: Secrets Manager enables you to replace hard coded credentials in your code, including passwords, with an API call to Secrets Manager to retrieve the secret programmatically. This helps ensure the secret can't be compromised by someone examining your code, because the secret no longer exists in the code.

Step 7: Right click on the resource arn and open the link in the new tab. This will make it easier to switch back to the analyzer dashboard.

Step 8: Navigate to the “Resource permissions” and check out the resource policy.

In this resource-based policy, the IAM element Effect specifies whether the statement results in allow or an explicit deny. The IAM Action element defines the actions that are performed with the secret. The IAM Resource element is the secret that the policy is attached to. The IAM Principal element specifies the user with access to perform actions with the secret.

This policy grants full access to the secret for the two AWS accounts. Remove the external AWS account arn and keep the one which has an arn of this account.

Click on “Edit permissions”.

Remove the external AWS account arn from principal.

Click on “Save”.

Now, the access to the secret is only allowed for the current account. Now switch back to the tab which has an access analyzer dashboard.

Step 9: On the finding page, Click on the “Rescan” button to run a scan again in this particular resource.

If the resource is no longer shared outside of your zone of trust, the status of the finding is changed to Resolved. The finding is no longer displayed in the Active findings table, and instead is displayed in the Resolved findings table. Now, the access is removed, the status changed to Resolved.

Step 10: Click on “Finding ID” of the resource “S3 Bucket” which has a name that starts with “lab-zone”.

NOTE: S3 bucket is an object storage service that offers scalability, data availability, security, and performance. S3 is used to store and protect any amount of data for a range of use cases, such as data lakes, websites, mobile applications, backup and restore, archive, enterprise applications, IoT devices, and big data analytics.

Step 11: Right click on the resource arn and open the link in the new tab. This will navigate to the S3 dashboard.

Step 12: Click on Permissions.

Notice the permissions overview section. The access of this bucket is public.

A bucket policy is a resource-based policy that you can use to grant access permissions to your bucket and the objects in it. Only the bucket owner can associate a policy with a bucket. The permissions attached to the bucket apply to all of the objects in the bucket that are owned by the bucket owner.

The following policy grants the Read, Write, List permission to any public anonymous users.

Step 13: Click on “Edit” under block public access.

Step 14: Block all public access by checking the box and click on “Save changes”.

Step 15: Enter “confirm” and save the settings.

All public access to the bucket is blocked.

Switch to the tab which has an access analyzer dashboard.

Step 16: On the finding page, Click on the “Rescan” button to run a scan again in this particular resource.

The access is removed, the status changed to Resolved.

Step 17: Click on “Finding ID” of the resource “S3 Bucket” which has a name that starts with “lab-bucket-ip”.

Step 18: Right click on the resource arn and open the link in the new tab. This will navigate to the S3 dashboard.

Step 19: Click on “Permissions”.

Step 20: Scroll down to the Block public access section and click on the “Edit” button.

Step 21: Block all public access by checking the box and click on Save changes.

Enter “confirm” and save the settings.

All the public access has been blocked.

The following policy denies permissions to any user to perform Amazon S3 Read, Write, List operations on objects in the specified S3 bucket unless the request originates from the IP address specified in the condition. This access will work even when you block all the public access to the bucket.

Step 22: Click on “Edit” under bucket policy.

Change the Effect in the policy to “Deny”. This denies permissions to user having the specified IP address to perform Amazon S3 Read, Write, List operations.

Click on “Save changes”.

Switch to the tab which has an access analyzer dashboard.

Step 23: On the finding page, Click on the “Rescan” button to run a scan again in this particular resource.

The access is removed, the status changed to Resolved.

Step 24: Click on “Finding ID” of the resource “IAM Role” with the name “ad_role”.

NOTE: An IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it.

Step 25: Right click on the resource arn and open the link in the new tab. This will navigate to the IAM dashboard.

A trust policy is a document in which you define the principals that you trust to assume the role. A role trust policy is a required resource-based policy that is attached to a role in IAM. The principals that you can specify in the trust policy include users, roles, accounts, and services. This is an overly permissive trust policy.

Step 26: Click on “Trust relationships”.

Step 27: Click on “Edit trust policy”.

Step 28: Change the Effect to “Deny”.

This trust policy allows full access to the AWS account and this can be assumed by anyone.

Step 29: Update policy by clicking “Update policy”.

Switch to the tab which has an access analyzer dashboard.

Step 30: On the finding page, Click on the “Rescan” button to run a scan again in this particular resource.

The access is removed, the status changed to Resolved.

Step 31: Navigate back to the analyzer dashboard. Click on “Finding ID” of the resource “KMS Key”.

Check the access level granted.

NOTE: AWS Key Management Service (AWS KMS) is an encryption and key management service scaled for the cloud. AWS KMS keys and functionality are used by other AWS services, and you can use them to protect data in your own applications that use AWS.

Step 32: Right click on the resource arn and open the link in the new tab. This will navigate to the KMS dashboard.

AWS Key Management Service (KMS) gives you centralized control over the cryptographic keys used to protect your data. The service is integrated with other AWS services making it easy to encrypt data you store in these services and control access to the keys that decrypt it.

This key policy statement allows all actions (kms:*) to two AWS accounts on the KMS key. Remove the external AWS account from the key policy.

The principal in this key policy statement is the account principal, which is represented by an ARN in this format: arn:aws:iam::account-id:root. The account principal represents the AWS account and its administrators.

Step 33: Remove the external AWS account from the principal and click on “Save changes”.

Switch to the tab which has an access analyzer dashboard.

Step 34: On the finding page, Click on the “Rescan” button to run a scan again in this particular resource.

The access is removed, the status changed to Resolved.

Step 35: Navigate back to the analyzer dashboard. Select all the findings with the name “TheOracle” and archive the findings.

These findings are generated from an IAM role which was created intentionally for this lab and has no security threats. So archive the findings.

Step 36: Click on “Archive” under the actions.

When you archive a finding, it is removed from Active findings and the status changes to Archived.

Click on “Archived” and navigate to archived findings.

This will list all the archived findings.

Click on “Resolved” and navigate to resolved findings.

This will list all the resolved findings.

References:

AWS Access Analyzer (https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)

Conclusion

We saw how to create an Analyzer using the Access Analyzer, find permissions that are overly permissive in nature, and get rid of those permissions.

To perform these tasks hands-on in our lab, subscribe or sign up for a 7-day, risk-free trial with INE to access this lab and a robust library covering the latest in Cyber Security, Networking, Cloud, and Data Science!