Who can access this public cloud resource?
It’s a simple question. A question you might ask for a number of reasons. Perhaps there has been a security incident related to the resource, and this is part of the investigation. Or the resource contains PII, and a regulatory audit requires you to prove who has access to that PII.
Regardless of the reason, this is a question you will need the answer to from time to time, and despite sounding simple, it is very challenging for most organizations to answer this question.
Unfortunately, there is no simple table that describes who has access to a resource and the policies and permissions that allowed for that access.
Let’s take an AWS S3 bucket as an example.
Many different roles might have policies that allow access to the S3 bucket in question. At the same time, each principal (user or cloud resource) might be assigned to multiple roles, each of which might have access to that S3 bucket. You can also attach a policy directly to the bucket, creating what’s known as a resource-based policy that bypasses the identity-based roles to give a principal direct access to the resource. A principal can also assume a role in AWS, meaning that when a resource is accessed from outside of an AWS account, the accessor receives a session with the permissions that are assigned to the role.
It’s enough to make your head spin!
AWS offers a tool called IAM Access Analyzer. According to Amazon, Access Analyzer “helps you identify the resources in your organization and accounts, such as Amazon S3 buckets or IAM roles, that are shared with an external entity. This lets you identify unintended access to your resources and data, which is a security risk. “
Access Analyzer provides, in the form of a table, a list of external entities that can access the resource in question. This table also describes how the access was granted (bucket policy, access control list, or access point), and the level of access granted.
Unfortunately, this service works only with external access, works for a limited number of AWS services, and the table-based format makes it difficult to visualize exactly who can access the S3 bucket and how they inherited that permission.
Initial deployment is fast and easy - simply onboard your AWS account(s) to Zscaler CIEM via API authorization. From there, start by either searching for the S3 bucket in question, or by filtering on the S3 service to display all S3 resources.
Find your target S3 bucket and select, “Who has access to this object?”
And that’s it! The resulting graph below is an easy to interpret visual that shows exactly who can access the S3 bucket, as well as the role and/or resource policy that resulted in that access.
You can easily investigate the underlying object for every identity, role, policy, resource and more directly from this chart, quickly determining how to remove any unwanted access. You can also review any unused entitlements to give a better sense of whether specific permissions are required or not.
Of course, if you don’t have time for manual investigations, all of this is bubbled up into risk-based policies, and corresponding incidents, that will automatically highlight these types of issues and save you the time investigating (and knowing what to investigate).
Permissions are a rapidly growing public cloud risk area, one that is commonly overlooked by many organizations in their quest to move quickly in the public cloud. We’ve integrated this CIEM functionality into our Workload Posture offering, providing the ability to enforce least privilege principles across your dynamic public cloud environment.
I urge you to reach out to Zscaler to take a closer look at how we can help solve the growing public cloud permissions problem. You can also request a free assessment by going to the end of this page, and clicking “Take an assessment.”