AWS Security – Risk of Unmanaged Exteral Resource Shares

Allowing AWS Principals to share resources externally using AWS Resource Access Manager comes with certain risks. One primary concern is the potential exposure of sensitive data to unauthorized parties. External sharing increases the attack surface, making it crucial to carefully manage permissions and access controls.

Misconfigurations or inadequate access policies may lead to unintended data leaks or unauthorized access. It’s essential implement strict security measures, regularly audit permissions and follow the principle of least privilege to minimize potential risks associated with external sharing in AWS RAM.

So, How can we fix this?

We can make use of service control policies to deny creation of resource share and update the resource shares to make the publicly shared to external principles.

Lets see them with examples:

First, Lets create a resource share and try if we can share it externally with an AWS account unknown to us. In this example, I am creating an resource share using an customer managed prefix list.

Create resource share with Prefix List share

Next, Configure resource sharing. Here I am sharing the resource to a complete unknown account.

Configuring external share

After clicking next, you will see the screen with following details.

Final screen after completing the resource share

Now, As we see a complete different account now has access the resource and we do not have any control. The solution? Service control policy

Lets fix this.

We will create a service control policy that will deny resource share when configured with external share ( outside of AWS Organization or zone of trust )

Policy creation in AWS Organization

I am using the native policy generator to create the service control policy.

Policy creation using Policy Generator

Now, Lets attach this Service control policy to our Target OU.

Attach SCP to Target OU

In enterprise setup, before applying to a Global Target, Always test the policy in a staging environment. In this case, I am testing on my Security OU especially made for security engineering as playground.

Now lets try create a resource share and see if we can share it with external principle.

Explicit deny error during share

As we can see, the resource share was unsuccessful with an message saying an explicit deny caused the resource share to be shared externally.

CloudTrail Event

Similarly, Incase users already created resource share without external access, they can’t alter it to allow external principles since the policy explicitly denies it.

It is essential that we spread awareness of these risks while enabling cloud users to be productive.

Note: Even if you allow external sharing, one need to attach the principal account Id to make the resource share available to other accounts. I really wonder if AWS has any feature requests to catch this external sharing with IAM Access Analyzer in the future.