The Challenges of Securing Data Access in the Cloud, Part 3 (of 4)

In this series of posts I have been unraveling the reasons why Identity and Data security in the cloud is so complicated, and why many organizations get it wrong. If you’re joining now, you should read part 1 and part 2 first.

In my last post, we took a closer look at AWS IAM policies with a simple use case of mapping all the resources that a specific IAM user may access. Now that we have the permissions figured out, we move one step forward to understand how to achieve least privilege. Intuitively, this does not appear to be too complex. One should simply monitor the permissions each identity (user or application) actually uses, compare this with the permissions it has, and use the profiling data to right-size roles and permissions. By continually reexamining the environment and removing unused permissions, your environment converges to least privilege over time.

Unfortunately, this is easier said than done. Continuous access profiling and role rightsizing sounds like a straightforward approach, but simple role-based access is not enough to achieve least privilege. Let’s look at an example in the AWS environment to understand where traditional models begin to break down.

In this simple example, an application has assumed a role with excessive privileges (Role), and it is the only application running under this role in your AWS account.

We will assume that Role has permission to access Amazon ElastiCache, RDS, DynamoDB, and S3 services. Now, we introduce another useful AWS IAM tool called AWS Access Advisor. This tool allows us to investigate the list of services accessed by a given role and verify what the role is being used for. Let’s imagine that when we use Access Advisor to inspect the services accessed by Role, we see that Amazon RDS was the only service accessed in the last 90 days.

The simple way to achieve least privilege in this case would be to right-size the permissions and remove unused services from this specific role. 

So far, so good. But is it really good enough? When we dig down into the actual activities performed by the role, leveraging the AWS CloudTrail service, we see that the only RDS resource the role is accessing is a MySQL database.

The next reasonable step would be to limit the permissions to allow access only to MySQL resources (as opposed to all resources that belong to the RDS service type). 

Then the access permissions could be further limited by restricting the access policy to a specific database instance:

Of course, relying solely on the Access Advisor will not allow us to connect the dots between access permissions and individual resources to make this kind of policy decision. This is exactly where Ermetic can help. Anyway, Access Advisor is a good place to start.

As you have just seen, the role is using the AmazonRDSFullAccess policy, granting the specific role full access permission to MySQL resources. However, further analysis of the CloudTrail logs reveals that full access is excessive. Read-only access privileges would suffice for execution of the application.

Therefore, the next reasonable step would be to limit the permissions to read-only access. Unfortunately, Access Advisor does not allow for this level of visibility, and we would either have to manually perform the analysis, or give us a call to see if we can help.

Think this is too complicated?! Come on, we’re just getting started. Let's take a break here and continue in our next chapter...