Why we need identity-based / identity-first security for cloud infrastructure

When organizations adopt cloud infrastructure, new security concerns emerge. It doesn’t matter if it’s one public cloud environment, multi-cloud, or hybrid cloud. Trying to manage access using static IP addresses is complex and risky.

Before we can understand the need for identity-based security, we need to understand the patterns of security that came before.

»What is IP-based security?

IP-based security is a method of controlling access to resources based on a device’s unique internet protocol (IP) address. In an IP-based model, systems determine whether to allow or to deny access based on network location. Devices with an address within an organization’s internal IP range are considered “trusted.” Those outside of that range are “untrusted” and may be blocked or subjected to limited access using firewall rules, security policies, or VPNs.

»The problem with IP-based security

In private, on-premises infrastructure, change happens at a relatively slow pace. A virtual machine might live for months, or even years, after being provisioned. The IP address of the server is fixed and then used as a unit of control in traditional privileged access management (PAM) systems and firewall rules for workload identification and more.

But in the cloud, this doesn’t work for several reasons:

• Cloud infrastructure is not static. New VMs are spun up and down as needed, lasting for only days, hours, or sometimes even minutes instead of months or years.

• Sheer scale. Instead of a few machines with a lot of cores, cloud infrastructure uses many more machines with smaller footprints.

• Changing IP addresses. Communication between cloud environments requires IP addresses to be translated and rewritten as traffic flows through VPNs, NAT gateways, and other middleware.

The ephemeral nature of cloud infrastructure makes IP addresses poor units of management because they are always changing.

Another critical factor is that the cloud renders the concept of the traditional network perimeter moot. Adopting cloud infrastructure means organizations no longer can assume everything inside the network perimeter is secure. This legacy pattern is called a “castle-and-moat” structure, where perimeter-based, network-centric security devices are used to keep nefarious traffic away from computing resources.

But IP addresses can be spoofed, shared, or dynamically reassigned. And they provide little guarantee about who (or what) is actually accessing a resource. As a result, identity — not network boundary — is now the new perimeter.

»What is identity-based security? Identity-first security?

Identity-first or identity-based security is a method of controlling access to resources by focusing on who (or what) is trying to access a resource rather than network location. In an identity-first model, access decisions are made using authenticated identity attributes. These may include:

• User credentials

• Device posture

• Role or group membership

• Behavioral context

Instead of trusting a network segment, every request is checked and verified for legitimacy before access is granted.

»Why identity-first security is a requirement in the cloud

There are many reasons identity-first security models should be used when adopting cloud infrastructure. These include:

»Trust is never assumed

IP-based security operates on the premise that being inside the network perimeter equals trust. Identity-first security assumes nothing (this is where the concept of zero trust security comes from). Trust must be earned with verified credentials and continuous validation.

»Support for dynamic environments

There is no fixed perimeter in the cloud. Users, apps, and data live across multiple environments. VMs are constructed and deconstructed as needed. Since cloud IP ranges are shared and dynamic, IP-based controls fail. Identity-first security is based on identity attributes; therefore IP address changes have no effect on access decisions.

»Enables simpler network topologies

Identity-first models allow for less complex networks. Instead of defining rules that allow devices to talk to other devices (such as a web server communicating with a database server) based on a static IP address, identity-first models allow for service identities. By focusing on service identities (that do have a static address), the underlying devices can come and go, addresses can change or be reassigned, and traffic is unaffected. Rules are enforced at the service level, where identity information is available, and network topologies are much simpler.

»Enhanced security against modern threats

IP-based security can be easily bypassed through tactics like IP spoofing or VPN tunneling. If attackers can compromise an internal machine (a device inside the trusted network), they can use that machine to access sensitive data or to cause harm to systems and networks. Identity-first security mitigates these risks by enforcing authentication factors and behavioral analytics even if the entity has made it onto the network.

»Supports least-privilege access

Identity-based security also makes role-defined (identity-defined) access controls easier to implement and manage, so that administrators can narrow the scope of access for identities and only give them access to what they need — not blanket access to large portions of sensitive networks.

»Auditability and compliance

Identity-based systems provide detailed logs of who accessed what, when, and how. IP-based systems often lack this visibility because they focus on devices, not users.

»Faster incident response and forensics

If a breach occurs, identity-first telemetry can pinpoint which account or credential was used. This enables faster containment and remediation. IP-based logs often show only where an attack came from, not who executed it.

»Future-proof and scalable

Identity-based security integrates with emerging technologies like passwordless authentication, adaptive risk scoring, and AI-driven access control. This helps organizations stay resilient against evolving threats. 

»Learn more 

Identity-first security delivers a modern defense model that aligns with zero trust principles, supports dynamic cloud infrastructure, and scales across all environments.

• Learn about what the next generation of cloud security has in store by checking out this deep-dive security guide.

Watch HashiCorp co-founder Armon Dadgar talk more about why we need identity-based security:

• 
  Armon DadgarCo-founder & CTO

»Transcript

The way we think about this is: What changes as we go from a static, private cloud-centric infrastructure into either private + public or multiple public cloud environments, or even a single public cloud environment?

What it really comes down to is a change in the dynamism of this infrastructure. In a private infrastructure, it tends to be much more static. We provision a VM, it lives for months to years, and we use an IP address as the unit of our security control. An IP address is what we’re using with our traditional privilege access management (PAM) systems. It’s what we’re using with our firewalls. It’s the unit that identifies what workload is on that machine.

As we make this transition into this more dynamic cloud environment, there are a few challenges. One, our infrastructure’s much more ephemeral, so we don’t have machines living from months to years. We might have things living for hours and days. So one part of this challenge is—how do we have a unit that we’re managing that is less subject to change?

The other aspect of it is, there’s a lot more scale. We have a much larger infrastructure. So instead of having fewer machines with a lot of cores, we might have many, many more machines that are smaller in individual footprint. And then as we talk about multiple environments, IP is getting translated between them. So our IPs might be flowing through firewalls. They might be flowing through VPNs and nets and other middleware that’s translating the IP address.

So, where before we could use the IP as a unit of identity and manage around that, now our problem is: IPs are coming and going all the time as we’re scaling up, scaling down, and we have this ephemeral infrastructure. Plus, those IPs are flowing through systems that are translating it. So the IP’s being rewritten. And so it becomes this really bad unit of management. We’re trying to hang our hat on a thing that’s a moving target.

So instead, what is a static target? How do we think about identity? Instead of saying IP1 can talk to IP2, how do we, instead, express that as the web server can talk to the database? Where the web server is an identity and the database is an identity, and these things are static. It doesn’t matter which IP address is associated with the web server as long as we know it’s a web server. It doesn’t matter if we have one, ten, or fifty web servers, as long as all of them are identified as a web server.

What this lets us do is have this higher-level rule that says, “web server is allowed to talk to the database,” and now these things can come and go. And we’re not rewriting firewall rules or trying to figure out how to constantly update a bunch of our infrastructure. We have a relatively static set of rules, assigned to a static set of identities, and then our infrastructure underneath that can still continue to be dynamic.

This simplifies a lot of it, and particularly has impacted how we think about network topology. Oftentimes what we have to do is design our network topologies such that traffic is flowing through middleware in a very controlled way. And this lets us impose firewalls in different places and act as checkpoints where we’re filtering IPs — versus if we try and do that in a dynamic way, it becomes a very complicated topology.

Instead, by focusing on service identity, we can have much simpler topologies and push that enforcement up to the service level, where identity information is available to us.

Updated from the original video and transcript published in 2018.