This post was originally published here by Edward Smith.
AWS Identity and Access Management (IAM) is a powerful service that helps you control access to AWS resources by enabling you to specify who and what is authenticated (signed in) and authorized (has permissions) to use those resources. Since IAM represents the “keys to the kingdom” for your AWS environment, it’s important to audit the service to find loose permissions and access to untrusted accounts–including cross-account roles and service roles.
What are cross-account roles and service roles?
AWS cross-account IAM roles allow customers to grant access to resources in their account to a partner or other third parties while enabling the customers to maintain their security posture. Cross-account roles allow the customer to delegate access without the need to distribute key material, and without the burden on the third party to safely handle key material after receipt.
A service role is a role that an AWS service assumes to perform actions in your account on your behalf. When you set up most AWS services, you must define a role for the service to assume. This service role must include all the permissions required for the service to access the AWS resources that it needs.
What’s the risk in misconfigured cross account roles and service roles?
Because cross-account and service roles grant permission to either an entire account or service, the wrong permission tied to a role can cause significant downstream effects.
Due to the ability to create cross-account roles which trust one account to assume the role in another account, an AWS account can be exposed to attack from other AWS accounts, including those belonging to business partners or worse. For example, let’s say you’re a healthcare provider that needs to exchange information with payment providers via an AWS integration. You provide them with a cross-account role, but with too loose of permissions. If one of your payment providers gets compromised, and the attacker discovers the cross-account role, they could use it to break into your AWS environment.
Since service roles trust an entire AWS service, if a service is compromised there is potential to cause more damage with broad permissions, but less damage with more restricted permissions. Sometimes service roles are created and forgotten. For example, someone adds role for a particular application or other purpose for a short period of time, but the role is not disabled after its no longer needed. Another example would be an insider threat leaving a back door. In this case it wouldn’t matter if that person’s IAM account was turned off or not because they could still gain access through the service account and cause damage.
It’s important for security practitioners to continuously audit these roles, identify new ones, and make sure the trusts are approved. Because this can become an enormous time-consuming task, security teams often can’t even scratch the surface without centralized exposure detection and automated remediation across many AWS accounts.
How does CloudPassage help?
In addition to our existing IAM policies, which mostly focus on users and keys, Halo Cloud Secure now continuously audits service roles and cross-account roles across any number of AWS accounts to find loose permissions and access to untrusted accounts.
Photo:Project Times
