Enterprises are struggling with a swelling number of cloud identities, credentials sprawl and privilege creep. Gartner has sounded the alarm: by 2023, 75% of cloud security failures will result from inadequate management of identities, access and privileges.
It’s time to tame the beast.
The Four Pillars of Entitlement
But first, we need to understand the components of an entitlement that can put security at risk. They can be broken down into: entities, identities, permissions and resources.
An entity is just what it sounds like—a person, machine, service or application that needs access.
Identities can be cloud identity systems, on-premise identity systems, SaaS applications, etc. And they’re not always humans; they could be compute resources needed to complete a business function, like an application or a virtual machine using a service identity.
Identities do not necessarily have to belong to users or applications within your organization. We are seeing a sharp growth in what we call third-party identities belonging to vendors that need access to your public cloud infrastructure in order to provide some operational or business value. These can include security vendors, cost optimization vendors, etc.
These identities become more complicated depending on which public cloud infrastructure you’re using. Each cloud platform manages identities differently, for example Microsoft Azure uses Azure Active Directory.
Meanwhile, many organizations also use on-premises identity systems, which are external to the cloud service provider. In these hybrid environments, users have two (or more) identities, a cloud platform specific identity and a federated identity to access the cloud infrastructure from on-premises identity systems.
Finally, every identity has entitlements or permissions such as the ability to read and write files, granted by policies associated with the cloud platform or custom-written by the organization based on the identity’s roles and access. In addition, entitlements are linked to a specific resource or a group of resources, which could be virtual machines, containers, databases, servers—or secrets such as encryption keys.
Entitlements can also be granted to identities in a number of ways that further complicate their management. These include:
- Grouping: Identities can be clustered together and organized by function, such as business unit, resources they use such as servers, databases, etc. When identities are added to a group they inherit all the permissions assigned to the group by default, whether they need them all or not.
- Chaining: In this scenario an identity may assume additional permissions as it performs its work. Think about how traditional privilege escalation evolves in your system, when an identity is able to start using another, more privileged identity. If the identity the user assumed along the way has more privileges, the user instantly gets those permissions. The same happens in the cloud when an identity linked to an application starts working on behalf of a user.
- Tagging: Identities are often tagged for billing purposes, but the tags can have more than one use: they can be used to assign permissions over each resource and those tags might give different permissions to different users. A virtual machine admin can have a different level of access than a storage admin, for example.
To start connecting the dots between entities, identities, permissions and resources, an organization first needs to understand the permission structure of each cloud provider, whether it’s AWS, Azure, GCP or whomever. Each uses pre-baked permission policies that can lead to privilege creep. These policies tend to be extremely over-provisioned; we see many cases of DevOps or developers assigning administrative-type of policies to applications and resources such as databases, storage and machine IDs.
There are very few applications that really need the ability to read, write and delete all the storage services in your environment. Usually an application would be using a specific storage service to fulfill its business function. Savvy organizations are recognizing this risk and moving to custom-managed policies or policies that allow them to granularly control permissions.
How to Reign in Permissions
Managing permissions starts with visibility. You have to be able to discover all the human and machine identities in the environment. Then you have to be able to map all the permission structures, identities and resources to answer one basic question: Who can access sensitive data in my environment?
Answering that question requires mapping permissions and analyzing the broader security context of your resources, such as their network exposure and who can update their configurations. You have to be able to remove stale access and do it at scale. In most cases, the number of permissions that the environment really requires is around 10% to 20% of the actual number that are provisioned.
This requires determining risk—which users and machines have access to sensitive resources. You have to be able to identify excessive permissions, right-size them and remediate security problems such as lack of multi-factor authentication or failing to rotate access keys. This includes detecting and automatically removing inactive identities.
The biggest barrier to this exercise is the effort involved. It’s impossible to do it manually; we’re talking about hundreds of thousands of users and resources, maybe even millions. Analytics can help you review access policies to provide a clearer picture of the organization’s security posture vis-a-vis identities and their entitlements.
It’s also difficult to address these challenges using tools that come with each cloud platform since they lack the granularity to capture and unravel the complexities of all the privileges attached to identities. They can look at a specific user and understand the permissions attached to that user directly, but they will miss groupings, or chaining of identities inside your organization that can introduce risk. They also miss the broader network context, like the ability to understand if an application is exposed to the internet.
If you are using more than one cloud platform, cloud provider tools will not be able to manage identities and permissions in other cloud infrastructures.
Cloud platform agonistic automation technology is available for managing identities and permissions at scale. By providing visibility into over privileged user and machine accounts it’s possible to tame the wilderness that cloud entitlements have become for many organizations.
ABOUT THE AUTHOR
Arick Goomanovsky, Chief Business Officer of Ermetic