Too Much of a Good Thing — Too Much Flexibility in Permission Management is Putting IAM Security at Risk

This blog was originally published by Authomize here.

Written by Gabriel Avner, Authomize.

As cloud services like Salesforce, AWS, and others have grown more robust over time, they have added more options for how IAM security teams can manage their organizations’ access policies.

This increased flexibility has led to a considerable expansion in the number of ways that permissions can be granted and managed. Access can be managed based on identities, attributes, groups, and a long list of other parameters that might fit the needs of one organization or another.

On the face of it, more flexibility is a good thing. No two organizations are exactly alike, and folks appreciate their tools being malleable enough to fit their needs.

But sometimes you really can have too much of a good thing.

Mo’ Options, Mo’ Problems

What has developed is a kind of IAM sprawl that is so flexible as to be a challenge to effective management. This is because for every new access possibility that is created, an IAM security person has to take the time to ensure that the paths not in use are in fact blocked or otherwise being managed.

The result ends up being the creation of more work with diminishing returns, and therefore far less than ideal.

Given this challenging situation, why have the cloud service providers created so many options for managing access? The simplest answer is because their customers have been asking for it.

Every IAM team or department has a good reason why they should be able to manage their access in one fashion or another. There is often a good case to be made why it makes sense to have session policies for one department while another uses identity-based policies. AWS and the rest are trying to be responsive to their customers, but as we can see, it comes at a cost and it may be time to think about a reset in the near future.

For some helpful context on how far the flexibility sprawl has gone, let’s take a look at two of the most complex IAM structures that teams have to contend with.

AWS

A quick skim of the AWS IAM “Policies and Permissions” page shows six different policy types.
They are:

• Identity-based policies
• Resource-based policies
• Permission boundaries
• Organizations SCPs
• Access control lists (ACLs)
• Session policies

Each one of these policy types offer ways to control access to your organization’s resources, providing varying levels of limitations and functionalities.

Some like the Identity and Resource-based policies are pretty straightforward, granting access to specific identities or for a specific asset type like an S3 bucket. But then others are more complicated.

Take the Permissions boundaries for example. Here, the policy defines the maximum permissions that the identity-based policies can grant to an entity, but does not grant those permissions itself. This one falls under AWS’s managed policies that have their own advantages and disadvantages, but in this case, is just a bit confusing.

While there are likely use cases where some of these more complex policy types can help solve specific problems, the probability of someone mishandling them is significantly high –– potentially creating unnecessary risk.

Salesforce

In another case that feels like a tangled ball of yarn, Salesforce provides a number of ways for controlling access within their system.

They include:

• User permissions
• Object permissions
• Custom permissions

Focusing on the user permissions, we have user profiles that can have lots of attributes such as location, or value (high/low) etc). Then there are user permission sets that can have multiple permissions and direct shares associated with them that have to be carefully managed.

Salesforce has quirks that are specific to their platform. A common example is that management will generally automatically “inherit” access to the data that their employees have access to. It makes sense that Salesforce would want to ensure that people higher up the hierarchy can view financial or other customer data that those beneath them can.

The problem is that it requires security teams to enact additional monitoring since these often unused permissions can easily lead to a massive expansion of the threat surface facing those highly privileged accounts.

Adding to the complexity, if you want to access the Apex services for running code, then you have a whole other permission management system that needs to be contended with.

Tips and Best Practices for Keeping Permission Management Simple and Secure

In the face of the overwhelming number of options provided by these services, there are steps that we can take for reducing our level of complexity and chances for costly errors.

1. In AWS, avoid only creating situations where permissions are granted to specific users or groups that then have to be monitored. Instead, use roles that can be assumed by members of groups.
2. Only assume roles using SAML with your IDP service. Don’t allow local accounts that can be unmonitored and cause you to lose visibility.
3. In Salesforce, build profiles and permission sets that represent the organization structure, and base your sharing rules on those profiles and permission sets.

Usability is the Goal

One point that the cloud services companies should consider is that humans do not handle complexity well. Too much choice is frankly just confusing more than it is likely to be helpful. The expansion of options makes it harder to maintain visibility and is leading us down a path where it is increasingly difficult to ensure secure control over access to our assets in these cloud environments.

It is easy to understand why the pressure to constantly improve products and add more functionality is a driving force for these folks with their good intentions.

But hopefully they will get the hint sooner than later that they should focus on usability over piling on more features in the name of increasing flexibility.