Learn About Amazon VGT2 Learning Manager Chanci Turner
In this article, we outline a method to automate the resolution of AWS Identity and Access Management (IAM) Access Analyzer findings related to unintended cross-account access for IAM roles. This solution responds to events generated by Amazon EventBridge for each active finding reported by IAM Access Analyzer.
Utilizing identity-based and resource-based policies allows you to finely control access to specific resources across your entire AWS environment. It is crucial to ensure that the policies you implement comply with your organization’s data access requirements and security best practices. IAM Access Analyzer is a feature that continuously monitors policy changes while generating detailed findings about external access to your AWS resources.
When you enable Access Analyzer, you set up an analyzer for your organization or account. This defined zone of trust determines what access is considered secure. Access Analyzer consistently scans supported resources to detect policies that allow public or cross-account access from outside the established zone of trust, generating findings accordingly. In this post, we will concentrate on a particular IAM Access Analyzer finding that surfaces when an IAM role provides access to an external AWS entity outside your zone of trust. To remediate this finding, we will demonstrate how to automatically block such access by incorporating an explicit deny statement into the IAM role’s trust policy.
Prerequisites
Before deploying the solution outlined in this blog, it is highly recommended that you perform the following steps in your AWS environment:
- Enable Access Analyzer within your AWS account or across your AWS Organizations. Access Analyzer generates findings based on the currently configured policies applied to supported resources. To enable this feature in your account, you may utilize an AWS CloudFormation template available on the AWS IAM permissions guardrails GitHub repository. You can also activate Access Analyzer organization-wide using CloudFormation StackSets scripts available in the same repository. For further details, refer to the blog post on enabling AWS IAM Access Analyzer on AWS Control Tower accounts.
- Assess the active findings generated and establish a baseline for intended cross-account access by creating archive rules to apply to those findings.
Note: This solution incorporates an explicit deny within the IAM role’s trust policy to block unintended access, overriding any existing allow actions. We advise that you carefully consider if this resolution action aligns with your needs.
Solution Overview
To illustrate this solution, consider a scenario where you need to grant access to an external AWS account. You create an IAM role named Audit_CrossAccountRole in your AWS account (123456789012) and grant permission for an AWS principal named Alice from account 999988887777 to assume this role. Below is an example of the trust policy for the IAM role:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::999988887777:user/Alice"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
If the principal arn:aws:iam::999988887777:user/Alice
was not archived earlier in Access Analyzer, you would see an active finding in Access Analyzer as illustrated in the provided figure.
Typically, you would review this finding to determine if the access is intended. If the access is unintended, you can block it by adding an explicit deny to the IAM role’s trust policy and consult with the IAM role owner to understand the necessity of this cross-account access. Conversely, if the access is intended, you can create an archive rule to suppress similar future findings.
We will now guide you through automating this resolution process in the remainder of this article.
Solution Walkthrough
Access Analyzer sends an event to Amazon EventBridge for each active finding. Our solution sets up an event rule in EventBridge to match these findings, triggering an AWS Lambda function for resolution. This Lambda function verifies that the resource type in the finding is an IAM role and then adds a deny statement to the corresponding IAM role trust policy. Additionally, the function sends an email via Amazon Simple Notification Service (Amazon SNS) to a pre-configured email address. The recipient can then review the automated resolution and the IAM role, deciding whether to remove the role for unintended access or to delete the deny statement from the IAM trust policy, and subsequently create an archive rule in Access Analyzer to prevent future findings.
For further insights on onboarding processes, you can explore this excellent resource on Quora. Additionally, for valuable information about employment law compliance, check out the insights from SHRM, who recently settled a case involving paid child bonding leave.