Automate resolution for IAM Access Analyzer cross-account access findings on IAM roles

In this blog post, we show you how to automatically resolve AWS Identity and Access Management (IAM) Access Analyzer findings generated in response to unintended cross-account access for IAM roles. The solution automates the resolution by responding to the Amazon EventBridge event generated by IAM Access Analyzer for each active finding.

You can use identity-based policies and resource-based policies to granularly control access to a specific resource and how you use it across the entire AWS Cloud environment. It is important to ensure that policies you create adhere to your organization’s requirements on data/resource access and security best practices. IAM Access Analyzer is a feature that you can enable to continuously monitor policies for changes, and generate detailed findings related to access from external entities to your AWS resources.

When you enable Access Analyzer, you create an analyzer for your entire organization or your account. The organization or account you choose is known as the zone of trust for the analyzer. The zone of trust determines what type of access is considered trusted by Access Analyzer. Access Analyzer continuously monitors all supported resources to identify policies that grant public or cross-account access from outside the zone of trust, and generates findings. In this post, we will focus on an IAM Access Analyzer finding that is generated when an IAM role is granted access to an external AWS principal that is outside your zone of trust. To resolve the finding, we will show you how to automatically block such unintended access by adding explicit deny statement to the IAM role trust policy.

Prerequisites

To ensure that the solution only prevents unintended cross account access for IAM roles, we highly recommend you to do the following within your AWS environment before deploying the solution described in the blog post:

• Enable Access Analyzer within your AWS Organizations or AWS Account. Access Analyzer generates findings based on current configured policies that are applied to the supported resources. To enable this in your account, you can use an AWS CloudFormation template available in the aws-iam-permissions-guardrails GitHub repository. You can also enable Access Analyzer across your organization by using the scripts for AWS CloudFormation StackSets found in the aws-iam-permissions-guardrails GitHub repository. For more information, see the blog post Enabling AWS IAM Access Analyzer on AWS Control Tower accounts.
• Review the generated findings that are active, and create a baseline for intended cross-account access for IAM roles by creating archive rules and applying the rule on those existing findings.

Note: This solution adds an explicit deny in the IAM role trust policy to block the unintended access, which overrides any existing allow actions. We recommend that you carefully evaluate that this is the resolution action you want to apply.

Solution overview

To demonstrate this solution, we will take a scenario where you are asked to grant access to an external AWS account. In order to grant access, you create an IAM role named Audit_CrossAccountRole on your AWS account 123456789012. You grant permission to assume the role Audit_CrossAccountRole to an AWS principal named Alice in AWS account 999988887777, which is out-side of your AWS Organizations. The following is an example of the trust policy for the IAM role Audit_CrossAccountRole:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::999988887777:user/Alice"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

Assuming the principal arn:aws:iam::999988887777:user/Alice was not archived previously in Access Analyzer, you see an active finding in Access Analyzer as shown in Figure 1.

Figure 1: Sample IAM Access Analyzer finding in AWS Console

Typically, you will review this finding and determine whether this access is intended or not. If the access is unintended, you can block access to the principal 999988887777/Alice by adding an explicit deny to the IAM role trust policy, and then follow up with IAM role owner to find out if there is a reason to allow this cross-account access. If the access is intended, then you can create an archive rule that will archive the finding and suppress such findings in future.

We will walk through the solution to automate this resolution process in the remainder of this blog post.

Solution walkthrough

Access Analyzer sends an event to Amazon EventBridge for every active finding. This solution configures an event rule in EventBridge to match an active finding, and triggers a resolution AWS Lambda function. The Lambda function checks that the resource type in the finding is an IAM role, and then adds a deny statement to the associated IAM role trust policy as a resolution. The Lambda function also sends an email through Amazon Simple Notification Service (Amazon SNS) to the email address configured in the solution. The individual or group who receives the email can then review the automatic resolution and the IAM role. They can then decide either to remove the role for unintended access, or to delete the deny statement from the IAM trust policy and create an archive rule in Access Analyzer to suppress such findings in future.

Figure 2: Automated resolution followed by human review

Figure 2 shows the following steps of the resolution solution.

1. Access Analyzer scans resources and generates findings based on the zone of trust and the archive rules configuration. The following is an example of an Access Analyzer active finding event sent to Amazon EventBridge:

   { 
       "version": "0",
       "id": "22222222-dcba-4444-dcba-333333333333",
       "detail-type": "Access Analyzer Finding",
       "source": "aws.access-analyzer",
       "account": "123456789012",
       "time": "2020-05-13T03:14:33Z",
       "region": "us-east-1",
       "resources": [
           "arn:aws:access-analyzer:us-east-1: 123456789012:analyzer/AccessAnalyzer"
       ],
       "detail": {
           "version": "1.0",
           "id": "a5018210-97c4-46c4-9456-0295898377b6",
           "status": "ACTIVE",
           "resourceType": "AWS::IAM::Role",
           "resource": "arn:aws:iam::123456789012:role/ Audit_CrossAccountRole",
           "createdAt": "2020-05-13T03:14:32Z",
           "analyzedAt": "2020-05-13T03:14:32Z",
           "updatedAt": "2020-05-13T03:14:32Z",
           "accountId": "123456789012",
           "region": "us-east-1",
           "principal": {
               "AWS": "aws:arn:iam::999988887777:user/Alice"
           },
           "action": [
               "sts:AssumeRole"
           ],
           "condition": {},
           "isDeleted": false,
           "isPublic": false
       }
   }
   

2. EventBridge receives an event for the Access Analyzer finding, and triggers the AWS Lambda function based on the event rule configuration. The following is an example of the EventBridge event pattern to match active Access Analyzer findings:

   {
     "source": [
       "aws.access-analyzer"
     ],
     "detail-type": [
       "Access Analyzer Finding"
     ],
     "detail": { 
        "status": [ "ACTIVE" ],
   	"resourceType": [ "AWS::IAM:Role" ] 
    	}
   }
   

3. The Lambda function processes the event when ResourceType is equal to AWS::IAM::Role, as shown in the following example Python code:

   ResourceType = event['detail']['resourceType']
   ResourceType = "".join(ResourceType.split())
   if ResourceType == 'AWS::IAM::Role' :
   

   Then, the Lambda function adds an explicit deny statement in the trust policy of the IAM role where the Sid of the new statement references the Access Analyzer finding ID.

   def disable_iam_access(<resource_name>, <ext_arn>, <finding_id>):
       try:
           ext_arn = ext_arn.strip()
           policy = {
               "Sid": <finding_id>,
               "Effect": "Deny",
               "Principal": {
                   "AWS": <ext_arn>},
               "Action": "sts:AssumeRole"
           }
           response = iam.get_role(RoleName=<resource_name>)
           current_policy = response['Role']['AssumeRolePolicyDocument']
           current_policy = current_policy['Statement'].append(policy)
           new_policy = json.dumps(response['Role']['AssumeRolePolicyDocument'])
           logger.debug(new_policy)
           response = iam.update_assume_role_policy(
               PolicyDocument=new_policy,
               RoleName=<resource_name>)
           logger.info(response)
       except Exception as e:
           logger.error(e)
           logger.error('Unable to update IAM Policy')
   

   As result, the IAM role trust policy looks like the following example:

   {
           "Version": "2012-10-17",
           "Statement": [
               {
                   "Effect": "Allow",
                   "Principal": {
           "AWS": "arn:aws:iam::999988887777:user/Alice"
                   },
                   "Action": "sts:AssumeRole",
               },
               {
                   "Sid": "22222222-dcba-4444-dcba-333333333333",
                   "Effect": "Deny",
                   "Principal": {
           "AWS": "arn:aws:iam::999988887777:user/Alice"
                   },
                   "Action": "sts:AssumeRole"
               }
           ]
       }
   

   Note: After Access Analyzer adds the deny statement, on the next scan, Access Analyzer finds the resource is no longer shared outside of your zone of trust. Access Analyzer changes the status of the finding to Resolved and the finding appears in the Resolved findings table.

4. The Lambda function sends a notification to an SNS topic that sends an email to the configured email address (which should be the business owner or security team) subscribed to the SNS topic. The email notifies them that a specific IAM role has been blocked from the cross-account access. The following is an example of the SNS code for the notification.

   def send_notifications(sns_topic,principal, resource_arn, finding_id):
       sns_client = boto3.client("sns")
       message = "The IAM Role resource {} allows access to the principal {}. Trust policy for the role has been updated to deny the external access. Please review the IAM Role and its trust policy. If this access is intended, update the IAM Role trust policy to remove a statement with SID matching with the finding id {} and mark the finding as archived or create an archive rule. If this access is not intended then delete the IAM Role.". format(
           resource_arn, principal)
       subject = "Access Analyzer finding {} was automatically resolved ".format(finding_id)
       snsResponse = sns_client.publish(
           TopicArn=sns_topic,
           Message=message,
           Subject=subject
       )
   

   Figure 3 shows an example of the email notification.

   

   Figure 3: Sample resolution email generated by the solution

5. The security team or business owner who receives the email reviews the role and does one of the following steps:
   • If you find that the IAM role with cross-account access is intended then:Remove the deny statement added in the trust policy through AWS CLI or AWS Management Console. As mentioned above, the solution adds the Access Analyzer finding ID as Sid for the deny statement. The following command shows removing the deny statement for role_name through AWS CLI using the finding id available in the email notification.

     POLICY_DOCUMENT=`aws iam get-role --role-name '<role_name>' --query "Role.AssumeRolePolicyDocument.{Version: Version, Statement: Statement[?Sid!='<finding_id>']}"`
     aws iam update-assume-role-policy --role-name '<role_name>' --policy-document "$POLICY_DOCUMENT"
     

     Further, you can create an archive rule with criteria such as AWS Account ID, resource type, and principal, to automatically archive new findings that match the criteria.

   • If you find that the IAM role provides unintentional cross-account access then you may delete the IAM role. Also, you should investigate who created the IAM role by checking relevant AWS CloudTrail events like iam:createRole, so that you can plan for preventive actions.

Solution deployment

You can deploy the solution by using either the AWS Management Console or the AWS Cloud Development Kit (AWS CDK).

To deploy the solution by using the AWS Management Console

1. In your AWS account, launch the template by choosing the Launch Stack button, which creates the stack the in us-east-1 Region.
   
2. On the Quick create stack page, for Stack name, enter a unique stack name for this account; for example, iam-accessanalyzer-findings-resolution, as shown in Figure 4.
   

   Figure 4: Deploy the solution using CloudFormation template

3. For NotificationEmail, enter the email address to receive notifications for any resolution actions taken by the solution.
4. Choose Create stack.

Additionally, you can find the latest code on the aws-iam-permissions-guardrails GitHub repository, where you can also contribute to the sample code. The following procedure shows how to deploy the solution by using the AWS Cloud Development Kit (AWS CDK).

To deploy the solution by using the AWS CDK

1. Install the AWS CDK.
2. Deploy the solution to your account using the following commands:

   git clone git@github.com:aws-samples/aws-iam-permissions-guardrails.git
   cd aws-iam-permissions-guardrails/access-analyzer/iam-role-findings-resolution/ 
   cdk bootstrap
   cdk deploy --parameters NotificationEmail=<YOUR_EMAIL_ADDRESS_HERE>
   

After deployment, you must confirm the AWS Amazon SNS email subscription to get the notifications from the solution.

To confirm the email address for notifications

1. Check your email inbox and choose Confirm subscription in the email from Amazon SNS.
2. Amazon SNS opens your web browser and displays a subscription confirmation with your subscription ID.

To test the solution

Create an IAM role with a trust policy with another AWS account as principal that is neither part of archive rule nor within your zone of trust. Also, for this test, do not attach any permission policies to the IAM role. You will receive an email notification after a few minutes, similar to the one shown previously in Figure 3.

As a next step, review the resolution action as described in step 5 in the solution walkthrough section above.

Clean up

If you launched the solution in the AWS Management Console by using the Launch Stack button, you can delete the stack by navigating to CloudFormation console, selecting the specific stack by its name, and then clicking the Delete button.

If you deployed the solution using AWS CDK, you can perform the cleanup using the following CDK command from the local directory where the solution was cloned from GitHub.

cdk destroy

Cost estimate

Deploying the solution alone will not incur any costs, but there is a cost associated with the AWS Lambda execution and Amazon SNS notifications through email, when the findings generated by IAM Access Analyzer match the EventBridge event rule and the notifications are sent. AWS Lambda and Amazon SNS have perpetual free tier and you will be charged only when the usage goes beyond the free tier usage each month.

Summary

In this blog post, we showed you how to automate the resolution of unintended cross-account IAM roles using IAM Access Analyzer. As a resolution, this solution added a deny statement into the IAM role’s trust policy.

You can expand the solution to resolve Access Analyzer findings for Amazon S3 and KMS, by modifying the associated resource policies. You can also include capabilities like automating the rollback of the resolution if the role is intended, or introducing an approval workflow to resolve the finding to suit to your organization’s process requirements. Also, IAM Access Analyzer now enables you to preview and validate public and cross-account access before deploying permissions changes.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the AWS IAM forum.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.