What is Zero Trust and what are the steps to implement a zero-trust architecture to ensure that your system is flexible, secure, and scalable?
The concept of a zero trust architecture (ZTA) has been around for a while. However, in practice, zero trust implementations have been moving at a pretty slow pace. Maybe that’s not all that strange, given that a comprehensive ZTA is a big task, and the best approach is to start small and expand.
ZTA is gaining more and more momentum, and President Biden’s May 2021 Executive Order, “Improving the Nation’s Cybersecurity,” is driving greater adoption in the federal government and the private sector.
What Is Zero Trust?
The old IT security perimeter was basically a location-based network. Users were either physically within the network or had a VPN connection that authenticated a connection to the network. To a great extent, this was sufficient to access services and data, since they weren’t distributed and hosted in cloud services like they are nowadays. The entry point to the network was where access was controlled, and it defined the perimeter.
The downside of this architecture is that it placed an incredible amount of trust in whoever was accessing the network and the network’s ability to appropriately control access to services and data. Traditional networks put very few controls on lateral movement, meaning that if a hacker gained access to the network, they could most likely move very freely between services and data.
In a zero trust architecture, the new perimeter hinges on identity. With every access attempt to a network, the caller’s identity is verified, regardless of its origin. This is coupled with fine-grained access control rules specifying exactly which services and data the calling party can access. This requires a more sophisticated process for verifying the identity, depending on whether it’s for an actual user or a service. Today, services talk to one another in a microservices architecture, which is equally important to control. For example, a billing service requires access to the inventory service, but probably doesn’t need to access the payroll service.
Identity is Critical
If the requester’s identity is unknown, applying fine-grained access control to systems and data becomes less efficient, and this applies to both users and systems. Therefore, establishing identity is critical in the move towards a ZTA. Essentially, it’s a requirement before any other step takes place.
The Zero Trust Maturity Model outlines two steps for migrating toward a ZTA. The first is “identify actors on the enterprise,” which accounts for verifying the identity of specific users. The second step is to “identify assets owned by the enterprise,” which aims to identify the identity of services and devices.
Naturally, authentication is needed to identify users and determine that they are who they say they are. These days, there are endless options for authentication, and approaches without passwords are gaining momentum. For example, WebAuthn is an excellent option with a robust architecture that is more resistant to phishing attacks than SMS and email authentication options.
Token-Based Architecture
OAuth and OpenID Connect (OIDC) are standards that enable a token-based architecture, a pattern that fits exceptionally well with a ZTA. In fact, you could argue that zero trust architecture is a token-based architecture.
So, how does a token-based architecture work? First, it determines who the user is or what system or service is requesting access. Then, it issues an access token. The token itself will contain different claims, depending on the resource that is being requested as well as contextual information. The claims given in the token can, for example, be determined by a policy engine such as Open Policy Agent (OPA). A policy describes the allowed access and which claims are needed to access certain resources. In the context of the access request, the token service can issue a token with appropriate claims based on that defined policy.
Resources that are being accessed need to verify the identity. In modern architectures, this is typically some type of API. When the request to the API is received, the API validates the access token sent with the request. The system ensures the access token has not expired, validates that the token has the required claims and ensures the token is issued by a valid authorization server (issuer).
At this point, a token-based architecture can also determine the type of user, if it’s a user involved in an access request, and whether they are an internal or external user. This process removes the need for a traditional approach using a VPN. Services and APIs can expose information and in accordance with the ZTA model, directly verify what the user should have access to based on their identity.
Conclusion
The first step in implementing a ZTA is implementing protocols that always validate the requester’s identity regardless of whether a user or another service is requesting. For user authentication, passwordless options are gaining traction, and these will make for safer and more seamless user experiences.
Couple a robust identity layer with a token-based architecture for a flexible and scalable model that allows services and APIs to always validate who is requesting access and what level of access should be allowed.
