Why should we use identity-based or "identity-first" security as we adopt cloud infrastructure?
Identity is one of the most important aspects of security. Learn why old, IP-based identity models don't work in a dynamic cloud infrastructure.
- 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.
