So your company is now operating in the cloud. It’s exciting, isn’t it? So many tools at your disposal, so many new ways to get things done, and pure agility. Unfortunately, all of this also introduces many new ways that your organization can be at risk. One of them arises by not fully understanding what your Identities (people or non-people) have access to and can do – their AWS effective permissions. Oftentimes, what you think is fact is actually fiction. Or as they say in the movies; based on real events.
AWS defines effective permissions as “the permissions that are granted by all the policies that affect the user or role.” Simply put, it is the true picture of what your Identity can do and what it can access.
Why is this important?
In AWS, the effective permission for an Identity is oftentimes much broader than what we think it is configured to be. This happens because, in the cloud, an Identity’s permissions are constructed not only by the policies attached to them, or the groups that they belong to but are also extended to the roles that they can assume. These are known as Identity-based policies. But it is much more than that. AWS effective permissions include the combination of resource-based policies, session policies, service policies, organizational policies, and even access to native or third-party secret stores (such as HashiCorp Vault). On top of all of that, the manner in which a policy is implemented can greatly affect an Identity’s effective permissions. Now, what happens if you bring another public cloud into the mix. You might be thinking, “this sounds very complex.” Well it is, and that is why so many organizations today are at risk and don’t even know it. It’s a ticking time bomb in their cloud.
This is great in theory, but let’s look at some examples
To help get our head wrapped around things, let’s look at some examples of how we end up with AWS effective permissions that commonly cause issues. We’ll start with some simple ones and work our way to the more complex.
Let’s start with a rather simple scenario to get a baseline understanding of what an Effective Permission is.
In this scenario, an Identity belongs to multiple Groups. On its own each Group is scoped down to the proper purpose and function. The trouble arises when the permissions from one group, combined with permissions from others, lead to an Effective Permission that is beyond the intended least privilege for the Identity. This usually happens as an organization grows and people change roles and/or gain new responsibilities.
Now let’s take a look at a more complex example. We will build this up step-by-step so that you can see the Effective Permission is at each step and finally what the overall AWS Effective Permission is in totality.
In this example you have an Identity, Elliot, who is part of the SecOps team at his company and belongs to the SecOps Account. In that job he is only assigned to a single AWS Group called AllSafe. The AllSafe Group has two policies, one of which allows Elliot to assume the AllSafeVaultRole. The Role has a Policy attached which gives him access to secrets in his company’s HashiCorp Vault. With these permissions in hand Elliot can do his job of managing his company’s Secret Store which is in the SecOps Account.
That all sounds pretty good right? Well, what happens if the Vault was configured incorrectly and its secrets aren’t as nicely locked down as they were in AWS IAM? In this case it wasn’t and Elliot can access ALL the secrets in the Vault, including the AllSafeProduction Role. This Role is used by the Cloud team to manage S3 buckets in their Production Account. That doesn’t sound good, does it?
No, it is not good at all. As we dig a little deeper we can see below that with the AllSafeProd Role in hand Elliot has full access to all of the Production S3 buckets in his organization. Making matters worse, some of these S3 buckets contain data classified as CONFIDENTIAL.
So, the fiction is that Elliot ONLY has access to the HashiCorp Vault secret store in his Company’s SecOps Account. The fact is that his AWS Effective Permissions show us that he has access to confidential information in his Company’s Production Account.
At that point if you are thinking, “Wow, that was confusing and not good at the same time!!” You are 100% correct. This is exactly why, without knowing what your Identities can access, like Confidential data, and what they can do, such as assume privileged roles, you have a ticking time bomb in your cloud just waiting for someone to take advantage of.
Now that I know what they are, how can I find them in my environment?
That’s a good question and the answer is one you might not like. It’s difficult and requires thorough examination of your Identities. You need to map out each permission path to determine what they can do and/or what they have access to. But it doesn’t end there. Things in the cloud are moving quickly and constantly changing. This also applies to your Identities AWS effective permissions. So once you are done mapping off of that, you then need to keep monitoring things to determine if a change in your environment also changes your AWS effective permissions. If you can do this, then someone needs to take actions to remediate the issue before it becomes a major problem. This could be you, it could be another operational or security team, or even the person that invoked the changes, like a developer.
How do I stay on top of this?
As with many things in the cloud, the problem becomes too complex and things move too quickly to resort to manual efforts. What you need to do is implement the appropriate tooling. This can come in the form of in-house tools that you create to calculate and monitor an Identity’s AWS effective permissions. But this is often a big project and probably outside the scope of what your organization does. It can come in the form of using a combination of cloud-native tools as no one tool does everything. However, these tools are often at different stages of maturation, have no centralized way to tie things together, and are limited only to the cloud that they were built for. This can lead to gaps when one cloud is used and definitely when more than one cloud is used. So, what you really need is a solution that focuses on this and can work across multiple public clouds.
Identity and data access complexity are exploding in your public cloud. Tens of thousands of pieces of compute, thousands of roles, and a dizzying array of interdependencies and inheritances. First-generation security tools miss this as evidenced by so many breaches. Sonrai Dig, our enterprise identity, and data security platform, de-risks your cloud by finding these holes, helping you fix them, and preventing those problems from occurring in the first place.