By its very nature, the cloud resides outside of your enterprise’s perimeter. So, it’s not always appropriate to apply the traditional notions of perimeter security to machines that reside in your hybrid cloud environments. In other words, you can no longer automatically trust everything that is within your "castle and moat" because those boundaries no longer exist.
As Cloudflare observes, “This vulnerability in castle-and-moat security systems is exacerbated by the fact that companies no longer have their data in just one place. Today, information is often spread across cloud vendors, which makes it more difficult to have a single security control for an entire network.”
Elastic computing has become the norm. So, in an on-demand environment, such as the cloud, Zero Trust bootstrapping systems require an identity right out of the gate. And in this type of machine-centric world, human nature doesn’t make sense as a checkpoint—we can no longer make gross assumptions on which external systems should be trusted.
In fact, I would argue that trust should be built on-demand based on the security boundary of the relying parties.
What are they doing? Are they crunching numbers? Are they serving up web pages? Or are they enabling some other sort of automated infrastructure?
In this sense, Zero Trust automatically assumes that a given activity is not allowed on a machine unless it falls within the acceptable security parameters for the user and function. So, that’s why I like to think of Zero Trust in terms of on-demand trust governed by machine identities.
So, where do we even begin to build and protect on-demand trust for cloud environments? Enforcing policies for the keys and certificates that are your machine identities will play an essential role in this type of environment. In that way, you can focus your security on each connection, rather than each network or business segment.
Organizations have many different ways of addressing the challenge of Zero Trust in the cloud. For example, one organization might have a single team that operates solely in AWS. So, they're getting certificates only from AWS Certificate Manager. In that way they've already isolated trust for their applications within their environment. They trust only the certificates within their environment. But this scenario only works for them because they don't care about dealing with other teams within the company. Otherwise, they would need a more granular way to enforce Zero Trust with different applications being assigned their own levels of trust.
Another organization might implement Zero Trust for orchestration services that rely on self-signed certificates. And those certificates are only trusted within the environment where they are created. So, for this organization, self-signed certificates define trust by limiting it to a specific CA that issues certificates and keys for that environment.
But these strategies for isolating environments do not play very well in today’s dynamic cloud environments. To make information available to the departments that need to access it, you need to find a way to define on-demand trust. And the only way to make this feasible is to automate machine identity policies that control who can access which machines. And it’s got to be available on demand.
Here’s how that might play out in a cloud instance. You create an instance in AWS, and you give it an upstage key. Then you find the user, say here's your key, go do your thing. Say, upload some code, then publish it. And when that’s completed, you're done. End of transaction. But for that scenario to work, all those extemporaneous steps have to be authenticated in near-real time because all those steps must happen in miliseconds. That also requires a stunning number of machine identities. So, you’ll need exponential scalability for your machine identities in the cloud.
If you're doing on-demand trust, then you've got to be able to dictate access to machines via policy. Having visibility into disparate trust systems is also important because machines come and go in a virtual containerized world and we need to be able revoke trust on demand. Plus, you’ll need to deliver machine identities in a way that automatically scales up or down to meet on-demand trust systems.
Zero Trust access would take into account which servers, along with which policies that determine which certificates would establish trust for how long. In other words, authenticated access would be granted, then retired when it is revoked—whether that’s five days or a couple hours. In the future the lifetimes are going to get much, much, much shorter. So, these things will have to be done quickly.
With a platform for machine identity management, like the one that we offer here at Venafi, you can establish on-demand trust by creating and controlling access at the machine identity level. Plus, you’ll have the visibility into trust across the environment. So, you can enforce Zero Trust in your cloud and on-premises environments and verify that your machine identities are protecting what they should.
How are you handling Zero Trust in the cloud?
(This post has been updated. It was originally posted on June 14, 2019.)