More Cloud Identities, More Problems

4 mins to read

It’s no secret large enterprises are struggling to manage cloud identities. In fact, 84% of organizations faced an identity-related security breach in the past year, according to the 2022 Trends in Securing Digital Identities report. What is making this so hard to get a handle on?

identity proliferation

One thing we know for sure: Identities are proliferating in the cloud. 

Below, we’ll review what is causing this explosion of cloud identities and what challenges are emerging as a result of this new landscape.

Machine Identities

Once upon a time, enterprises were tasked with just managing human digital identities that actually reflected the number of employees they hosted in their organization. Identity and Access Management teams were created to oversee these users and monitor their behavior. We have since come a very long way.

The underpinnings of the cloud are built by digital identities, but not the living breathing kind. Instead, machine identities have taken over the cloud. Machine identities take on many forms including Service Principals in Azure, Virtual Machines, serverless functions like AWS Lambda, roles, compute, connected devices and more. It’s an expansive group. With more and more infrastructure being represented as code and built by developers, machine identities compromise about 43% of cloud identities in the average enterprise, compared to human identities at 16%.

Microservices

Previously, applications were built in monolithic fashions, meaning there were several tightly coupled services packaged together as one. This means as the application grows in size, it becomes hard to scale up and down, experiment, or add new features because you’re adjusting the entire monolithic backend. These days, cloud providers offer a microservices architecture. This structure instead breaks down an application into individual services that communicate via lightweight APIs. This brings a myriad of benefits including the ability to work on each individual service without affecting the entire application.

So previously, in monolithic structures, there would be a single application serving as an identity, whereas with microservices, each individual service can count as an identity. You can imagine how this increases identities exponentially when developers can create new apps or instances any day.

Scale & Scope

In the cloud, machine identities are created to execute action on behalf of humans, or even instead of. These machines ‘do things and create things,’ simply put. They have allowed for things to be done so much faster and far more efficiently, saving organizations time and money, and meeting their needs at scale. Consider an EC2 instance – a virtual machine – helping developers build and host applications. EC2 instances allow applications to be built without investing in hardware upfront, or over-spending as EC2 expands or contracts its compute capabilities depending on the applications needs. All this is to say, machine identities have proven to be immensely useful and because of this they are used in high quantity and frequency.

The cloud moves fast and developers are building new infrastructure every day to keep up with demanding business needs. This means new machine identities every day. And each of these identities often have the permissions needed to make more identities or modify their own privileges. The growth is ever-expansive and never ending. Some enterprises face up to 250,000 machine identities in their environment. This is an overwhelming landscape to manage.

Managing Excessive Permissions & Least Privilege

With all these identities, comes the need for managing the permissions granted to them. This is what traditional IAM teams would do for users on-prem. This sort of manual effort or first-gen IAM tooling does not hold up in the cloud where machine identities are dynamic and at scale. Instead, permission management must be systemic and programmatic. A lot of organizations have looked to Least Privilege policies as a result.

Least Privilege is a framework that enforces identities having the minimum amount of permissions necessary for them to complete their job function. This may seem obvious, but many identities are granted privilege far beyond what’s needed whether intentionally to create ease in future use, or unintentionally.

One way to reach Least Privilege is by looking at excessive permissions. Excessive permissions refer to all the permissions past that threshold of permissions necessary for a job function. Some organizations evaluate this by auditing identity permission use every 30,60 or 90 days. If an identity is not using a permission within that time-frame, it exemplifies it is not necessary and should be detached.

To follow Least Privilege, you don’t want to use managed policies or inline policies, instead you create more individual roles with refined permissions assigned. However, the net-effect of stringent Least Privilege policies is more machine identities. So while there is benefit in reducing the permissions a singular identity has, there are unintended consequences in then needing to create three, five, ten, more roles to accomplish whatever end goal. Instead, now you need a way to better manage the enormous amount of roles (machine identities) in your environment.

The Cloud Identity Proliferation Challenge

As previously mentioned, on-prem, organizations had IAM teams built to manage person identities in their environment. When organizations move to the cloud, a lot of them ‘lift and shift’ these teams, tools, and processes over. However, the issue is these placeholders do not hold up in this new landscape. They are not built to accommodate the scale and proliferation of machine identities nor the dynamic nature of the cloud. 

Another thing to consider is the actual team structures in cloud organizations. Many teams are siloed and there is confusion over who owns what. The team responsible for managing authorization of human identities is not the same team responsible for building machine identities or deploying IaC, and that team is not the same team as the one responsible for securing and managing these machine identities. 

So now that we’ve addressed:

  1. That there is a cloud identity problem: proliferation
  2. What is causing this proliferation, and; 
  3. What cloud factors exacerbate this challenge

In part 2 of this blog we will review how to tackle the real cloud identity problem – managing the permissions associated with all these proliferating identities. Stay tuned.