How Can Digital Enterprises Rationalize Security In Multi-Cloud And On-Prem

Transcript

Security's important to every organization. I think, as a group, most people are getting more comfortable with the idea of security on the cloud. If I were to distill what's different about security on-premises versus security on the cloud when it comes to infrastructure, it's that in the on-premises world, you have this very high-trust world where I have a very clear network perimeter. I can say anything within this defined IP range can talk to anything else in this IP range because I've created a castle and moat model. So, everything can be trusted, and I can manage risk within that environment relatively simply.

As you move to the cloud world, you can no longer assume that just because somebody's making a request of another application that that requester can be trusted. So we move from a perimeter IP-based model for security to an identity-based model for security. Before I give you access to anything in the cloud world, I need to understand your identity, and should this requester have access to this piece of information.

In the cloud world, when an application element boots. For example, when a container boots on Amazon, it's assigned an identity. That identity is the basis for every derivative access request of that element, versus in the on-premises world, the IP address is the basis for that element. So, this shift to identity versus IP addresses is how we think about security in the cloud.

Now, the challenge in a multi-cloud world is that all the different cloud providers have different identity models. For example, on Amazon, they use an IAM model, when this container boots, it's assigned an IAM identity. On Azure, they also use identity because identity is the model, but they use Azure Active Directory as the identity model. On Google, they also use identity, but they have Google IAM model.

Now, these things are, in a sense, incompatible. They all, conceptually, are the same. They have identity as the basis. But they are completely different. So the challenge in the multi-cloud world then is: how do I rationalize an application element on Amazon that might want to make a request of an application element on Azure, both of whom use identity as the basis of security, but those identity models are distinct?

The problem then becomes: how do I broker identity across these different application requirements in a way that might require that to happen 100,000 times a minute? I think that's a peculiar challenge of the cloud. How do I build applications that leverage identity is the basis of security while recognizing that there are different identity models across different platforms?

On the on-premises world, you may use identity for your applications as well, but that'll be active directory or LDAP, which is the traditional model for identity on-premises that we're all familiar with. You end up with this heterogeneity of identity models across clouds that you have to rationalize.

In a sense, this is what I mean by saying you have to establish a foundation. If you want to get good at delivering applications over the longer term, you have to reconcile the fact that number one, identity is the new way of doing security. Number two, different cloud providers and your own on-premises platform have different identity models. Making an investment in a harmonizing layer for how to think about identity-based security across that inevitable fleet is what most of our customers do.