Identify and Eliminate Risks on AWS IAM and Secure Data Stores Using Sonrai Dig

By Jeff Moncrief, Director of Sales Engineering at Sonrai Security
By Adam Blackington, Partner Solutions Architect at AWS

With the move to cloud, there has been a paradigm shift in how we protect our most valuable asset—data.

Where it was once the network, identities have become the “new” perimeter. With that, it’s critical to fully understand every possible relationship between the identities and data that exist inside your cloud. The foundation to securing your organization in this new paradigm is truly knowing who, what, and how your data is accessed.

In this post, you’ll learn the importance of building a complete and accurate risk profile, which consists of your identity and data relationships. You’ll also learn how it’s critical to protect the sensitive, private, and confidential data in your Amazon Web Services (AWS) environments.

This is achieved with three fundamental elements:

• Understanding the true permission set for your identities, not just what it is on paper.
• Understanding the true identity performing an action, not just the last one in the chain.
• Understanding which data an identity has access to, if they have accessed it, and what they did.

With this information, you’ll be able to take the appropriate measures to ensure your data is protected by knowing that only identities that need access to a piece of data get it, as well as tracking exactly what the identity is doing.

One of the fundamental principles of security in public cloud is getting to and maintaining a state of least privilege. In this state, all of your identities can only perform actions that are required for their job and nothing more. In many cases, we see identities (both human and non-human) with far too much permission and often with potentially harmful consequences.

Sonrai Dig graphically maps all of your identities and determines their effective permissions, allowing you to get to least privilege across your entire AWS environment. On top of that, Sonrai Dig does this continually to ensure that if something changes, you are notified immediately.

Taking a data-driven approach is fundamental to monitor identity and access management (IAM) permissions, as well as data access to achieve and maintain least privilege. The key is being able to determine the effective permissions completely, including all direct and indirect access paths from both people and non-people identities.

Sonrai Security is an AWS Partner with the Security Competency that delivers an enterprise identity and data governance platform for public cloud. The Sonrai Dig platform is built on a sophisticated graph that identifies and monitors every possible relationship between identities and data in your cloud.

How Have Identities Changed in the Cloud?

In the days of the data center, identities mainly consisted of users, groups, and service accounts.

With AWS, an identity can be a lot more than that; they include users and groups, but AWS roles also allow trusted entities such as AWS IAM users, access keys, applications, or AWS services to acquire temporary credentials to make API calls to the AWS account the role resides in.

This expansive set of identity capabilities enables you to leverage the security, power, and speed of AWS, but comes with an increase in overhead by requiring you to manage and govern your identities, particularly non-people identities.

What Are Effective Permissions?

Effective permissions are what your identities can do and access, not just what you think they can or should. AWS defines effective permissions as “the permissions that are granted by all the policies that affect the user or role.”

An identity’s permissions are constructed not only by the policies attached to them, or the groups they belong to, but are extended to the roles they can assume.

Effective permissions also include, or are restricted by, the combination of resource-based policies, session policies, service policies, organizational policies, and even access through native or third-party secret stores.

When we look at the basic example of an individual, we see the same issues exist (and are often ignored) when the identity is a virtual machine (VM), function, or service.

Effective Permissions with Groups

Let’s assume we have a user, with no directly attached policies. The user was provisioned as part of Group A with Policy A.

At this point, the user’s effective permission is only what Policy A allows the user to do. When the user is added to Group B, with Policy B, the new effective permissions become A+B. Essentially, the original set of permissions are extended to now include those of Policy B also.

Finally, the user is added to a third group with Policy C giving the effective permissions of A+B+C.

Figure 1 – Overlapping IAM permissions boundaries.

Effective Permissions with an AssumeRole

To see how this starts to get complex, let’s assume that with these permissions the user is enabled to assume a role into another AWS account.

Their effective permission is (A+B+C) in the account where their groups exist and whatever permissions they are granted through the assumed role in the production account.

Figure 2 – Cross-account effective permissions example.

What’s the Big Deal with Effective Permissions?

Going back to the example above, on their own each group has their permissions confined to least privilege. For example, the identities belonging to that group can only do what they need to and nothing more.

However, the problem arises as we add more permissions into the mix. Each new group brings a new set of permissions, and the end result could be something a lot more permissive, such as a combination of permissions that would allow escalation to full administrator, or the ability to access sensitive data.

Figure 3 – Toxic unintended permission combinations.

How does this relate to identity and data access risk? If you don’t know what permissions your identities really have, what they are doing in your environment, and what data they can access, then you’re operating under an assumption of being secure, rather than seeing the whole risk profile.

Real-World Examples

Let’s look at some real-world examples of identity and data risk to help put this all into context. Please note the names have been changed.

We’ll use the Sonrai Dig solution to help us identify how the risks arise.

Use Case #1: Identity Risk

In this use case, we’re looking at things from the identity risk perspective.

The organization was exploring the use of Amazon SageMaker to build some custom analytics. As part of setting this up in a dev account, the DevOps team created a role called DataScienceLeads for their data scientists to use.

Through a combination of group, directly attached, and assumed role policies, it achieves the effective permissions:

• sagemaker:CreateNotebookInstance
• sagemaker:CreatePresignedNotebookInstanceUrl
• iam:PassRole

With these permissions, the data scientists have the ability to create a Jupyter notebook and pass it a role. They can also create a pre-signed URL to access this notebook with.

At this point, they use the URL to access their notebook, using permission of the role. Sounds OK, right?

In actuality, this is an identity risk ripe for a privilege escalation. In this example, if one of the data scientist users, or anyone else with the DataScienceLeads role, passes an IAM role that has elevated privileges (full administrator), then the user can end up accessing the notebook running with those elevated permissions.

Figure 4 – Identity privilege self-escalation scenario.

In this use case, what Sonrai has unearthed is an identity risk; one where a malicious user could elevate their privileges and possibly gain full administrator access. This is a classic example of an unintended toxic combination.

Use Case #2: Data Risk

In this use case, we’re looking at things from the data risk perspective.

The company in question used Amazon DynamoDB with a sensitive table called “CustomerRecords.” Since they wanted to limit access to a very select group of people, they monitored this data table (see below).

One day, they found something strange—there was a user who shouldn’t have access. Making matters worse, it appears they have administrator level access.

In this scenario, the Sonrai platform exposed the true “effective permissions” of the SecOpsAdmin user and their subsequent actual permissions on this sensitive DynamoDB table.

Figure 5 – Effective permissions granting access to data.

The AWS user in question, SecOpsAdmin, is a member of the DevOps team. As part of the DevOps team, they belong to the DevOps Group. By looking at their permissions, we can see they have the ability to AssumeRoles into other accounts via built in AWS OrganizationalAccountAccessRole.

Here, the SecOpsAdmin user is able to assume roles into other accounts via the OrganizationalAccountAccessRole.

Figure 6 – Permission chains leading to cross-account access.

On the surface, this looks OK; it’s a DevOps user in the AWS Organizations account with permissions to AssumeRoles into other accounts using a built-in role.

As we dig deeper, however, we can see things are not OK. The OrganizationAccountAccessRole present in all of the company’s AWS accounts has a policy that provides whom or whatever assumes it to have full administrator privileges.

This probably wasn’t the intended permissions for the DevOps role to be able to access accounts with sensitive customer data, but rather something that was inherited based on the Organization configuration.

Below, you can see Sonrai linking and exposing the AdministratorAccess policy attached to the OrganizationAccountAccessRole, which allows full access to the existing account and other accounts.

Figure 7 – Policy granting organization-wide account access.

If we look at SecOpsAdmin’s effective permissions, they have full admin rights into an account that contains sensitive information. With those rights, they can access the “CustomerRecords” data table and do whatever they like.

Sonrai Dig identifies all data across the AWS environments that any identity can access via effective permissions. In this scenario, the SecOpsAdmin user is able to have full control over a DynamoDB environment that contains sensitive customer information.

Figure 8 – Excessive wildcard permissions on a data container.

In this use case, what Sonrai has unearthed is huge data risk. A DevOps user, from another account, can access a very sensitive data table they should not be allowed to. Making matters worse, they have full admin rights and therefore can do whatever they like with the data.

Use Case #3: Access to Critical Data via AssumeRole Chaining

In this example, we are looking at a significant risk to confidential data. It involves multiple AWS roles, a secret store, and cross-account movement.

While this may seem a little far-fetched, it’s actually something that can happen quite easily and is based on a true story.

Here we have an AWS user, Elliot, who is part of the SecOps team at his company and works in the AWS account with the same name. Following what should be least privilege, Elliot is only assigned to a single set of permissions in the 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 AWS Secrets Manager. So far, this is all good, as Elliot’s role is managing his company’s secret store which is in the SecOps account.

Figure 9 – A group membership with an attached policy lets Elliot assume the AllSafeVaultRole.

Well, Elliot can access all of the secrets in AWS Secrets Manager, including key granting access to the AllSafeProd role. This role is used by the cloud team to manage Amazon Simple Storage Service (Amazon S3) buckets in their production account.

Figure 10 – Elliot is able to access the AllSafeProd access key.

As we dig a little deeper, we can see 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.

Figure 11 – Elliot is able to access data in S3 that is tagged as confidential.

Sonrai Dig unearthed a significant data access risk here. On the surface, it appears Elliot only has access to the vault in his company’s SecOps account. By diving deep and mapping the effective permissions, we see that if he were to assume a role he was not intended to use, Elliot would end up having access to confidential information in his company’s production account.

At this point, we now have a clear understanding of a previously unknown problem and can take tangible steps to remediate it.

Use Case #4: Over Privilege Risk with a Non-Human Identity

In this example, we are looking at an identity risk. This risk comes not from a human identity but from a non-human identity; in this case, an AWS Lambda function.

To set the stage, a Lambda function is a piece of code that can be run in your AWS environment. When we create a Lambda function, we have to pass it an AWS role under which it executes. Within this role, permissions are assigned to allow the function to interact with AWS services. As we’ve seen a few times now, this is where trouble comes in.

Overly permissive roles can happen with a Lambda function. This tends to happen when a DevOps team tries to do the right thing and lock down a role to least privilege, but it can be challenging to define all the exact IAM permissions needed and still have your function work properly.

To satisfy another business unit’s needs that is unaware of what the existing least privilege policy is intended for and just focused on “getting the Lambda to just work fast,” they assign another permission that works but offers more access than the function needs. They vow to go back and harden things later.

What we have now is a Lambda function that has two AWS policies attached to its role. The first policy is a nicely locked down custom policy to allow only reads to an S3 bucket with confidential data. The second policy is an S3 bucket which enables the Lambda to do what the business needs, but it allows the Lambda to do anything to any S3 bucket in the environment.

Below is an example of how a Lambda function can have multiple access paths to a data container. One with least privilege permissions and the other with excessive permissions required for the Lambda to function.

Figure 12 – AWS Lambda function with multiple paths to data.

What Sonrai Dig unearthed here is a significant data risk as well. We see a Lambda function that has full admin privileges over S3, and not just the custom privileges to what it was intended for.

Now, we can take the findings to the business and have an informed discussion on what it took to “get it working fast” and why taking the time to fix it is probably needed to protect the business.

Conclusion

Identity and data access relationships can be complex, with tens of thousands of pieces of compute, thousands of roles, and a dizzying array of interdependencies and inheritances across services and accounts.

Sonrai Dig de-risks your cloud by finding these holes, helping you fix them, and preventing those problems from occurring in the first place.

The key to reducing the risk is through Sonrai’s graphing technology that monitors and builds every possible identity and data relationship that exists in your AWS environment.

Each time something changes, the graph is updated. On top of this graph, Sonrai Dig builds a custom analytics for identity and data risk, as well as activity modeling. Through this, you have the most up to date risk profile possible.

Combined, this enables you to make accurate and timely decisions to protect your most valuable assets.

.

.

Sonrai Security – AWS Partner Spotlight

Sonrai Security is an AWS Competency Partner that delivers an enterprise identity and data governance platform for public cloud.

Contact Sonrai Security | Partner Overview | AWS Marketplace

*Already worked with Sonrai Security? Rate the Partner

*To review an AWS Partner, you must be a customer that has worked with them directly on a project.