Implementing Zero Trust Network Access in Cloud-Native Environments

What is Zero Trust Network Access?

Zero Trust Network Access (ZTNA) is a security solution that provides secure remote access to corporate resources based strictly on identity and context. Identity verification for every person and device is required continuously regardless of network location or whether they have previously accessed a resource or not. No one is trusted from inside the network or outside, which is a tighter ship than the traditional approach of one being universally trusted as long as they are inside the network.

ZTNA is one component of SASE (secure access service edge) which is a framework that Gartner in its 2019 “The Future of Network Security is in the Cloud” report describes as an “emerging offering combining comprehensive WAN capabilities with comprehensive network security functions (such as SWG, CASB, FWaaS and ZTNA) to support the dynamic secure access needs of digital enterprises.” ZTNA is an element of the larger ZTA (Zero Trust access) philosophy and an important topic in cybersecurity.

ZTNA, specifically, applies zero-trust principles to a secure remote access architecture and is alternatively described as a software-defined perimeter (SDP) over and against a network-defined perimeter. The identity and context focus serve to create a logical boundary around the applications and infrastructure within.

Given the pandemic a few years back and the resulting normalization of remote working conditions and remote users, the concept of Zero Trust Network Access gained popularity, answering the call for better remote security and a superior alternative to traditional virtual private networks.

Components needed to implement ZTNA

To implement ZTNA, you’ll need a system consisting of an identity-aware proxy allowing only trusted devices and verified identities to access resources within. Let’s look at more detail into four specific components:

• Internet-facing access proxy. ZTNA, given the fact that it trusts no device or user, can sit in the public internet and not require network guardrails around it policing who can and can’t get in.
• Continual verified identities. Instead of basing access on whether one is inside or outside the network (VPN), ZTNA removes trust by verifying identity continuously throughout a user’s session. Access control is “always on”.
• Device identity. Devices also receive an identity and must be declared “trusted” to access resources.
• SSO and user database. Most ZTNA solutions will incorporate an SSO provider, like Okta, for identity management and to manage its users.
  

How does ZTNA work?

In a zero-trust model, emphasis is placed on who you are, not so much where you are. For example, employees used to be physically located in an office to access resources, but when traveling they would use a VPN. Identity is a major component over and against traditional solutions that focus on network or perimeter-based security.

Zero-trust, as the name implies, trusts no person or device. The proxy is public facing and may or may not lie behind a perimeter, but allows no access outside of presenting a verified identity or device.

Using our ZTNA components listed above, let’s look at how Zero-Trust Network Access works using Teleport as an example.

First, we have the internet-facing, identity-aware access proxy, or broker, on the public web. The ZTNA approach extends the network out publicly and essentially serves to hide the applications and resources from it. Users and devices could attempt to authenticate with the proxy, but being untrusted by default, cannot authenticate until a valid identity has been verified.

Once verified, the proxy continues to verify the identity or trusted device upon every computing resource access attempt. Access is given on a one-to-one basis, preventing lateral movement. The proxy can integrate with an SSO provider to maintain a database of users and enforce identity management and single-sign-on access.

Modern Zero Trust security tooling will also include, as seen in the Teleport diagram above:

• Modern authentication implementations like WebAuthn and passwordless
• Real-time auditing and logging capabilities to record all actions that pass through the proxy
• Role-based access controls to provide granular access to resources for each user and device.

You can read more about how Teleport extends BeyondCorp and the Federal Zero Trust Architecture strategy here.

What’s the difference between VPN and ZTNA?

A big question that comes up around the topic of Zero-Trust Network Access is how it compares to VPNs, which have been around for a long time and are still used by many companies. The differences can be quite significant and present an unmistakable line in the sand between modern and more legacy security approaches. Let’s look at a few:

Security. VPNs grant unrestricted horizontal access within the network. Once you are inside the VPN, you can move about freely. The downside here is that attackers, once they make their way into the network, can pivot unhindered. ZTNAs, on the other hand, trust no one regardless of whether they are inside or outside the network, and continue to do so even after initial verification. Identity-based authentication, overall, is more secure than traditional password-based, IP-enforced VPN architecture.

Cost. VPNs can be costly, difficult to manage and scale, and can create a suboptimal and inefficient experience for those working remotely, like developers and system administrators. Often these solutions are piecemealed together, with many moving parts, and disliked by those who have to use them on a daily basis.

Granularity. VPNs utilize network access and perimeter security to keep bad actors out, but stop there. A ZTNA service can eliminate this broad access by combining granularity via RBAC or ABAC to limit what each person or device is allowed to access after being verified.

Location. VPNs often require on-premises resources to complete the architecture, which, again, can add to costs and complexity. ZTNA provides a cloud-native architecture and is deployed in the cloud allowing easy access from any location.

Flexibility. When your proxy is on the public web, this makes it easy for a company to allow for BYOD (bring your own device) enforcement for its employees as the focus is on protecting resources and not so much network segments. VPNs often require providing and maintaining company computers and extended resources for each employee.

What are some ZTNA use cases?

There are a number of good use cases for ZTNA. Here are a few examples:

• Opening up applications to contractors, collaborators, suppliers, etc. without requiring a DMZ or VPN. Everyone enters the same way.
• Hiding internal applications, systems and private applications from the public network with a virtual, software-defined perimeter
• Authenticating users on BYOD devices as ZTNA hosts cloud-based assets publicly with the proper verifications.
• Leveraging the  safety of end-to-end encryption and security even on network carriers that aren’t overly trusted.
• Secure, identity-based access to particular resources from any device or location on the public web
• Auditing and logging actions from a central location (proxy)
• IoT security for devices at the edge.

What are the outcomes of ZTNA?

Advantages of ZTNA

User experience and productivity: It’s proven time and again that great user experience creates better productivity. If a team of engineers can avoid the hassles and wasted time that often accompany VPN access in exchange for the quick and controlled resource access that Zero Trust architecture allows, they are not only happier, but they can also spend more time actually doing the work they are tasked with.

Control and visibility: There is more control and visibility in a ZTNA model. Given that all traffic runs through the proxy, auditing and logging can be centralized and precise. Fine-grained RBAC control can further define who has access to what resources.

Modernization: Companies can get rid of legacy remote access solutions, like VPNs, in exchange for a complete software-based access solution.

Fast deployment: A ZTNA solution can be deployed quickly compared to a VPN, which with networks, firewalls, security, can take months to stand up. In addition, scaling consists of adding a new user or trusted device and in some cases a license.

Multicloud access: As companies continue to shift infrastructure into the cloud, ZTNA can mitigate the hassle of “vendor lock-in” and consolidate access to multicloud applications and systems.

Security benefits of ZTNA

Security is a major benefit of ZTNA and pairs well with its approach to modern cloud infrastructure access. Here are a few benefits:

Identity-based: The ZTNA model bases authentication on identity and trust as opposed to a traditional and outdated password or shared secret. Using modern secure enclaves, Windows Hello, or FaceId to authenticate helps to prove, biometrically, a user or device’s identity for Device Trust

Hidden infrastructure: In a Zero-Trust Network, your systems and applications are hidden from the public without having to connect any of them to a corporate network. This, then, frees up your network while keeping your applications invisible to the public.

Control and granularity: A centralized proxy, or trust broker, makes management of users, devices, and resources easy and maintainable. Attribute-based access controls or role-based access controls within the proxy provide even further granularity and definition as users move laterally to access resources within the principle of least privilege.

App segmentation: With ZTNA segmentation can be created around applications instead of networks. Secure boundaries can be put up around individual applications or groups of applications and managed via policies.

Challenges and risks of ZTNA?

ZTNA is not without its own challenges or risks. Here are a few to take into consideration:

• The trust broker, or proxy, can serve as a single point of failure as it handles all the operations of the network. In addition, performance factors like latency can come as a result of the broker being the single operation.
• ZTNA can also be complex to those new to the model. Accounting for the identity verification, trust, and authorization of resources via access policies and mappings can be complex to implement. Adopting enterprise Zero Trust security solutions like Teleport can make the transition and adoption much easier.
• Lack of education on moving past VPNs, perimeter security, and even failure to adopt modern authentication practices introduced by the FIDO Alliance can be challenging to ZTNA adoption.
• Cost. Increasing security steps, adding multi-factor authentication and continuous verification can sometimes be expensive to implement and build out for organizations. Again, choosing a well-established Zero Trust solution out there can save you time and money in your transition.

Considerations when evaluating ZTNA solutions

When adopting a ZTNA solution, there are a few considerations you should take into account.

• Vendor specialization: Often security, IAM, and network management have been marketed separately and vendors will have a specialty on which one they mostly cater to. This results in having to choose multiple solutions to get the full ZTA solution. It’s important to consider this and try to choose a solution that will cover all bases for your specific implementation.
• SSO and identity providers. Does the solution integrate with your existing identity provider?
• Cost and setup: How much work is it to get this solution up and running? How much does it cost? Does it meet all of your requirements?
• Logistics: Does the solution support your operating systems? Do agents need to be installed for it to work?

How is ZTNA different from Zero Trust Application Access (ZTAA)?

When it comes to ZTNA vs ZTAA, the key difference between the two is found in the third letter, respectively, Network vs. Application.

According to Gartner, a ZTNA “creates an identity and context-based, logical access boundary around an application or set of applications.” It’s focused on the identity-aware “network” as a whole and the remote access of it.

ZTAA is concerned with the protection of the applications themselves, not with the network that it’s in, but the applications within it, notably web-based apps.

• However, these days ZTAA is often used assumingly within discussions of ZTNA and the differentiation is not as emphasized. Regardless, ZTAA takes place within a ZTNA setup and applies Zero Trust security to the applications themselves.
  

Implementing Zero Trust Network Access with Teleport

Teleport is an excellent, do-it-all example of Zero Trust access. At the core of Teleport is the Teleport cluster consisting of:

1. A proxy service: This identity-aware, public-facing proxy provides secure access to resources in your infrastructure, from the public web, without the need for a VPN.
2. An auth service: The authentication service manages local users and configuration resources. It issues short-lived certificates to clients and maintains an audit log.
3. Teleport agents: The agents run in the same network and speak the language of the protocols it supports including servers, Kubernetes, databases, Windows desktops, and web apps.

A user can authenticate to the cluster using an identity provider of their choice (OIDC, SAML, GitHub SSO) or local WebAuthN methods, both focusing on passwordless technology and not outdated secrets. Once the identity is verified the user can access the resources that their Teleport role allows them to access and nothing more. Short-lived certificates are granted upon initial access in addition to resource access discouraging the use of any long-lived secrets. For an example, see our blog post on how Teleport applies the principles of Zero Trust to SSH access.

A database of devices can also be maintained and trust required for devices to access the network, and just-in-time access requests can be used to grant temporary privileged access to particular resources or roles.

Finally, the Teleport proxy will maintain an audit log of all sessions and actions passing through the proxy which can then be injected into external logging and monitoring facilities out there. Session recording is also a feature that will allow you to play back any kubectl or ssh sessions taking place through the proxy.

If you’d like to try out Teleport for 14 days, go and sign up for Teleport Team and we’ll get it running for you in a matter of minutes.

Zero Trust Network Access FAQs

Why is ZTNA important?

ZTNA is important because of the continued adoption of cloud-native architecture and growth of remote workers. End-users need a secure and efficient way to access the resources and systems to do work. Exchanging the outdated password-based authentication practices and complex perimeter policing with true user identity, security, and ease of access that ZTNA provides is just the natural progression and modernization of legacy systems and cybersecurity best practices.

What’s the difference between ZTNA and VPN in cloud-native and remote companies?

VPNs fail in providing granularity in access. The perimeter-based security works to keep bad actors out, but if breached, fails to stop lateral access. VPNs are also costly to manage, have a much more complex setup and maintenance requirement, aren’t easily scalable and can become difficult to scale as the number of users and applications grow. For more comparisons, check out our blog post on the subject.

What is the difference between service-initiated ZTNA vs endpoint-initiated ZTNA?

These are the two main types of ZTNA setups. Endpoint-initiated ZTNA gets its name based on an agent being installed on the end-user’s device(s). Service-initiated ZTNA, on the other hand, does not require the installation of an agent on the user’s device, and can be more appealing to BYOD-based organizations.

How is ZTNA different from ZTA and ZTAA?

ZTNA is the most widely used form of ZTA (Zero Trust Access) and provides user access to networks only after proper authentication and verification. ZTAA takes ZTNA a step further past the network itself and applies specifically to protecting applications in that devices and users must show proper authentication and verification to access applications themselves.

What is a Software-Defined Perimeter (SDP) in the context of ZTNA?

A software-defined perimeter is another term synonymous with ZTNA and is the alternative to a network-defined perimeter. An SDP creates a logical or virtual perimeter based on identity and serves to cloak applications and systems from the perimeter outside of it.

Does Zero Trust use MFA?

MFA is an important concept in Zero Trust access as it adds on a layer of security in order to access the proxy and the resources within it. It can also be required on each new session or connection for further security or to meet more rigid compliance standards.

What does “just in time and just enough” authentication and access control mean in ZTNA?

“Just in time and just enough” is similar to the principle of least privilege. It’s best practice to give a user “just enough” privilege to do their day-to-day work, and to give it “just in time,” not long-lived access to resources. With Teleport we always grant short-lived certificates that expire after a period of time.

Why is continuous authorization with device trust important in ZTA?

First of all, Device Trust is verified through device challenges via a private key in your secure enclave and this gives your device an identity that can be verified continuously. Also, managing a list of trusted devices can help you quickly offboard employees or restrict a device on the fly (and ultimately a user) if needed.

What is Least Privileged Access in ZTA?

Least privileged access, or principle of least privilege as it’s also known, is giving the least amount of access to a user or group of users so that they can perform their daily tasks, and nothing more. Further privileged access requests would be given on a temporary and as-needed basis only and not permanently.