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.
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:
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:
You can read more about how Teleport extends BeyondCorp and the Federal Zero Trust Architecture strategy here.
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.
There are a number of good use cases for ZTNA. Here are a few examples:
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 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.
ZTNA is not without its own challenges or risks. Here are a few to take into consideration:
When adopting a ZTNA solution, there are a few considerations you should take into account.
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.
Teleport is an excellent, do-it-all example of Zero Trust access. At the core of Teleport is the Teleport cluster consisting of:
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.
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.
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.
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.
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.
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.
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.
“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.
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.
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.
Protect your infrastructure with essential security & compliance capabilities with Teleport Team