5 mins to read
2022 One major risk when operating in the cloud is not fully understanding what your identities (person and non-person) have access to and privilege to do – in other words, their AWS effective permissions. The term can be used generally, but for the purpose of this blog we’ll focus on what they look like in AWS. In the cloud, it is easy to hold onto a false sense of security because ‘just being in the cloud means you’re secure’ – yet that couldn’t be further from the case. Let’s explore.
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. Effective permissions are an identity’s end-to-end abilities.
The power of AWS effective permissions
In AWS, the effective permissions of an identity is oftentimes much broader than what it appears to be. Broader meaning often an identity can do more, see more and access more than your organization thinks it has configured. 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 also influenced by the roles that they can assume. These are known as identity-based policies. But still there is more. 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 were to bring an additional public cloud into the mix? If you are thinking, “that sounds complicated,” then you’re right. This is why so many organizations today are at risk and don’t even realize it. Your identity management can be a ticking time bomb in your cloud.
OK, can we have some examples?
To help get our head wrapped around things, let’s look at some effective permissions that commonly cause issues. We’ll start with some simple ones and work our way up to the more complex scenarios.
Let’s start with a rather simple scenario to get a baseline understanding of what an AWS effective permission is.
In this scenario, an identity belongs to multiple groups. On its own, each group is scoped down to the proper purpose, function and least privilege. 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 scales up and people change roles or gain new responsibilities. This is understood as a toxic combination.
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 result of the identity’s permissions at each step and finally what the overall effect 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.
So far 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 actually 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 reach, Elliot can assume 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. This should make the hairs on the back of your neck raise.
As we mentioned earlier, it is easy to think one thing, when in fact, the reality is quite different. Here, Elliot appears to only have access to the HashiCorp Vault secret store in his company’s SecOps account. The truth is that his effective permissions culminate in his access to confidential information in his company’s production account.
This is where thinking “wow, that was confusing but doesn’t sound good at the same time” is 100% valid. This very common scenario is exactly why, without knowing what your identities can access, like confidential data, and what they can do, such as assume privileged roles, you can find yourself with configurations bad actors are just waiting to take advantage of.
How can I understand the totality of permissions 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 and this truth also applies to your identities’ effective permissions. Once you are done inventorying identities and mapping out all their permissions, you then need to keep monitoring things to determine if a change occurs. Continuous monitoring is the only way someone can take action 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 at scale 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 that is likely too big of a project and potentially outside your wheelhouse.
The other option is using a combination of cloud-native tools, as no one tool does everything. However, these tools are often at different stages of maturation, have siloed information, and are limited to only 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, we’ll cut to the chase – what you really need is a solution that focuses on this and can work across multiple public clouds.
Identity and data access complexities are exploding in your public cloud. Tens of thousands of pieces of compute, thousands of roles, and a dizzying array of interdependencies and inheritances make up your organization. First-generation security tools miss these security concerns, as exemplified by so many breaches. Sonrai Dig, our enterprise identity and data security platform, de-risks your cloud by finding the holes hidden to the human eye, helping you fix them, and preventing those problems from occurring in the first place.
Explore a demo today or learn about our Identity solution.
Read the latest news and insights
06.23.2020
Understand and better manage your organizations sensitive...
01.27.2020
On January 13, 2020 at an enterprise company headquartered...
01.21.2020
Learn the most common types of AWS IAM policy mistakes...
