The traditional approach to security has focused on establishing the perimeter system. The protective measures were aimed at preventing unauthorized users from gaining access to the corporate network. This way, it was mostly about protecting internal resources and networks from external intrusions. However, this approach meant that the system would be vulnerable in a different way. The perimeter security naturally doesn’t help prevent attacks where an external intruder poses as an internal user. If an intruder can break through the perimeter, they can quickly move laterally within the network to gain further access to corporate resources.

Nowadays, with more resources moving to the cloud and employees working remotely more than ever before, the perimeter doesn’t really exist anymore. This is where Zero-Trust Architecture comes into play.

What is Zero-Trust?

Zero-Trust Architecture (ZTA) is not a single architecture in and of itself. First, it is a philosophy that assumes that there are attackers both within and outside of the network. Therefore, no users or machines should be automatically trusted. Second, ZTA is a set of guidelines for designing systems and operations to tighten security to protect enterprise assets.

The main principle of ZTA is “trust no one.” This means that no entity should have access to any resources until they are authenticated and have proven who they are and what access privileges they have. This principle is applied to all resources and communications, whether internal or external, and access policies are well defined. ZTA puts an emphasis on applications and services to always verify the entity that is requesting access to a given resource.

Is this user allowed to access this record from the given location? Does this microservice have permission to access another microservice to retrieve data?

These types of access decisions are typically handled well by attribute or policy-based access control systems such as Rego, XACML, or other policy languages or products that support them. Policies are modeled and controlled by a Policy Decision Point (PDP) and enforced by a Policy Enforcement Point (PEP). The actual implementation of the PEP differs; it could be an API gateway, for example. The authentication aspect is at the core of this — as it is difficult to determine access if the requesting entity is unknown, regardless if that’s a user, system, or device.

Who Needs Zero-Trust?

The short answer is everyone.

The long answer is that Zero-Trust is essential for anyone whose operations presuppose working across the cloud or on-premise with different users or systems accessing the network or different services. ZTA is critical not only for remote work but ensuring that companies have an opportunity to grow: both internally and externally — with established access privileges.

ZTA is typically a bigger priority for organizations dealing with large volumes of critical data. For example, healthcare, financial organizations, and government agencies are segments that typically deal with some level of Personal Identifiable Information (PII). Thus, they should be looking at ZTA if they are not already.

Modernization and digital transformation efforts typically drive the use of APIs. With this, the adoption of APIs is steadily growing and should further drive the adoption of ZTA. APIs are used as an entry point to data and are accessed by users, systems, and devices. Therefore, it will be essential to implement a robust mechanism to verify who has access to a given API in a given context.

How Can API-Based Platforms Take a Zero-Trust Approach?

APIs are both internal and external facing. Following a ZTA approach, they should be treated the same. Trust no one; verify always. In modern environments, APIs are the entry points to all data and will be a critical component to control access to. The historical approach of controlling access to APIs using API keys will not suffice in a ZTA. As we’ve discussed previously, API keys can easily be stolen or shared, and verifying the identity of the caller that is presenting an API key will be impossible.

A modern token-based architecture built on top of OAuth and OpenID Connect fits exceptionally well into an API-based platform. It will also be able to handle all of the requirements for a solid ZTA. There are flows to authenticate both users and systems. After successful verification, tokens can be issued containing claims used to control access further and allow a least privilege approach.

As mentioned previously, an API gateway can sit in front of the APIs and provide valuable protections, including access token validation. There are patterns here, such as the Phantom Token Approach and the Split Token Approach that can be used depending on the overall architecture and use case. Both are intended to discourage the use of PII by the application calling the API. Instead, the API gateway can resolve this information and pass it on to the API as needed. This will further emphasize a ZTA approach.

Whether an API gateway is used or not, the control here lies within the software. This can span multiple architectures and cater to organizations that utilize a multi-cloud approach with services running on-premise.

How Should Zero-Trust be Implemented?

There are four main building blocks for implementing ZTA:

1. An inventory of systems to detect anomalies,
2. Authentication and authorization processing,
3. Network monitoring, and
4. Threat containment and mitigation.

With all these crucial processes, one stands out as it carries out the main requirement for ZTA — determining who the user is. A system must check whether the user is internal or external, what part of the organization they belong to, what service is requesting information from another service, or even what third-party service is requesting access to an internal corporate service.

Here are the key technologies and standards which help implement Zero-Trust and ensure authentication and authorization goes smoothly:

1. Token-Based Architecture

A Token-Based Architecture is precisely the kind of robust authentication service needed to get started implementing a ZTA. The reason is that the token-based approach to authentication can handle all the different types of use cases spanning from users accessing resources to services communicating with other services. It is scalable and highly flexible and is the method to use when it comes to API security and access control of microservices.

A token-based architecture has several aspects of the important process of verification already built in. This could be in the form of introspecting an access token or decoding and validating a JWT. In addition to a simple verification checking if the token is still valid, there’s the notion of Scopes and Claims that can be leveraged to further control what access is granted.

2. Multi-Factor Authentication (MFA)

With authenticating every access request to a resource, internal or external, the authentication component becomes key in the ZTA. There needs to be lots of flexibility in the type of authentication performed to handle both users and services. All resources are also not equal, so there will be scenarios where some kind of step-up authentication is required for more critical resources where Multi-Factor Authentication (MFA) is probably preferred.

3. Single Sign-on

Users will move around from service to service and access different resources, and with that, Single Sign-On (SSO) will play an important role to streamline the user experience. Of course, not all services will allow SSO, nor should they. This should be controlled and configurable depending on the service and data that is being accessed as well as other contextual input.

4. Customizable Authentication Methods and Alert System

In the process of authentication, you also must consider the level of confidence in the authentication. This is where additional inputs such as time of day, geo-location, risk score, etc., come into play to augment the authentication method to calculate the confidence of the given authentication. For example, if the score indicates an unacceptable level of risk, maybe there needs to be alerting/reporting, and additional factors invoked to raise the confidence level of the user’s identity.

Conclusion

With authentication happening with every request for access to a resource, authentication becomes critical in implementing a ZTA. A token-based architecture maps exceptionally well to handle this for both users, services, and devices.

Organizations should move towards gradually implementing a ZTA to protect their resources. First, start with critical resources and determine the requirements for strong authentication, including MFA and SSO approaches to strengthen security and make the transition smooth for end users. Strong confidence in authentication can allow you to move further to leveraging an API gateway to protect APIs using a token-based architecture. Here, fine-grained authorization using a centralized policy and attributes can help determine who should have access to what data.