Zero Trust is a strategy that basically shifts the focus of security from a perimeter to each individual connection point. In essence, this places the burden of authentication on the device, rather than the network. In a recent Venafi blog, Anastasios Arampatzis shared Why You Can't Achieve Zero Trust Without Machine Identity Management. Today I will build on this idea by sharing a few more examples of where Zero Trust and Machine Identity Management need to come together for both to be successful.
Let’s look at the four Zero Trust principles and then explain how they relate to machine identity management, and dig a little deeper into why they are so important.
Zero Trust changes what in the past has been a “trust but verify” security model to a model whereby default connections are denied. Every time a connection is needed, the identity (person or machine) needs to be authenticated.
While the number of people accessing networks is fairly static, the number of machines making connections on networks is exploding. As new technologies have been adopted, the definition of machines has expanded—from physical machines, such as servers and PCs, to mobile devices, applications, cloud instances, containers, microservices, clusters, APIs, and smart algorithms. Each of these machines needs a machine identity to establish identity and authenticity.
The number of machine identities used by a small enterprise is typically in the thousands. Global 5000 organizations tend to use millions of machine identities. Effectively managing these thousands or millions of machine identities so they can ensure trusted communications absolutely requires a machine identity management strategy and program.
Context is extremely important in a Zero Trust world. As an employee of Venafi, I should be trusted to log in to the Venafi network from my home in Houston. But I probably shouldn’t be trusted if I’m logging in from somewhere in Europe or Asia. Context is equally important when machines are connecting to networks or each other. What's granted for one particular machine identity should not necessarily be granted for all machine identities.
Let’s take Secure Shell (SSH) as an example. SSH is used by IT administrators to create secure connections between machines on unsecured networks. It’s a powerful protocol used widely in corporate networks to provide secure access for users and automated processes, facilitate interactive and automated file transfers, issue remote commands, and manage network infrastructure and other mission-critical system components.
The context of where SSH keys are used for machine identities should matter very much for how SSH machine identities are managed. In connections that have a high-risk context, say connections between build machines or the CI/CD pipeline, we might configure SSH to establish limits on things like port forwarding, source control (only accept SSH connections that come from a named source), passwords and automated keys.
If an application is trying to access data in a database, in a Zero Trust environment that application needs to be validated using certificates and public key infrastructure (PKI) to determine that it is an approved app accessing an approved database. As application architectures get more granular, so does the need to ensure trust between all the components. That has a big impact on machine identity management.
An application architecture from a few years ago might have required just a few TLS certificates to encrypt communications. Maybe one certificate on a load balancer, another one on a web server and two more for the backend application and database servers. Those TLS certificates would have had two- or three-year lifecycles so you wouldn’t have had to think about renewing them that often.
Fast forward to today, where applications are developed with microservices in mesh architectures and are much more compartmentalized. In Zero Trust, these more granular connections all need to be trusted, so the four TLS certificates I needed a few years ago will need to be multiplied to accommodate all the new components. Add on the fact that as of September 2020, TLS certificates have a lifespan of just over one year, means a machine identity management strategy and program is critical for dealing with the increased number of TLS certificates that need to be renewed more frequently.
Zero Trust relies on continuously verifying the trustworthiness of every device, user, and application in an enterprise. Since these devices, users and applications can be highly dynamic, the approach to ensuring their trustworthiness needs to be dynamic as well.
For machines, it means their machine identities need to be created and spun up rapidly, disabled and revoked rapidly, and then reconnected and redesigned. None of these actions can easily be done manually which is yet another reason why machine identity management is critical for Zero Trust.
Machine identity management programs provide organizations with the visibility, intelligence, and automation they need for the thousands or even millions of machine identities used in their organization. The bottom line: Zero Trust programs won’t succeed if they don’t synchronize with an organization’s machine identity management program.
Related Posts
The challenges of identity-based zero trust security
Read More