How to choose a Zero Trust architecture: SDP or Reverse-Proxy?
Published 02/15/2021
This blog was originally published on Wandera.com
Written by Alex Wells at Wandera
Zero Trust Network Access (ZTNA) is the next generation access solution that is set to be a key part of IT administrators toolkits, displacing longstanding Virtual Private Networks (VPN). There are numerous factors and features that need to be considered when choosing the right ZTNA architecture for your organization. In this guide we breakdown the differences between the two prominent architectures, Software Defined Perimeter (SDP) and reverse-proxy, and how to successfully evaluate them.
The need for a Zero Trust architecture
For many years, VPN has been the primary mechanism for connecting remote workers to business applications, but why are organizations choosing to migrate now? Simply put, the architecture of VPN is unable to provide the security necessary to protect against modern cyber threats and trends. According to IDC, VPN was being used in 68% of major incidents involving remote access tools, making risk mitigation a significant motivating factor for many businesses.
Gartner, Forrester, and many other analysts have identified ZTNA as the technology that will replace VPN because it not only provides comprehensive security, it also promises productivity and operational benefits to the business.
By 2023, 60% of enterprises will phase out most of their remote access virtual private networks (VPNs) in favor of ZTNA – Gartner
31% of organizations are currently considering ZTNA, 19% are in the adoption phase – TeleGeography
Understanding the use cases behind the move to ZTNA is essential so organizations can build their own evaluation criteria. There are numerous use cases for ZTNA, including application access, conditional access, unmanaged and BYO device enablement and much more. These use cases drive the requirements that should be considered when choosing a ZTNA architecture for your organization.
The principles of Zero Trust Network Access
First established by the Jericho Forum the key tenets of Zero Trust can be summarized as five principles:
- Trust no one – Before access is granted all users and devices must prove their trustworthiness. This so critical to enterprises that Gartner predicts that by 2023, 60% of them will phase out most of their remote access virtual private networks in favor of ZTNA.
- Verify identity claims – The identity and authentication of an end-user is a cornerstone of Zero Trust security. It is so important that, according to Centrify, 73% of businesses have given staff extra training on how to remain cyber-safe when working remotely, with specific training around verifying passwords and log-in credentials.
- Give those you know what they need – The permissions of every user start from zero, and are only granted when necessary. Also known as least-privilege access, this gives users access to the tools they need and prevents them from connecting to those they don’t. An IDC survey found that 40% of cyber breaches actually originate with authorized users accessing unauthorized systems.
- Do not ignore the device – Device-awareness is required to ensure that anonymous, vulnerable or compromised devices do not get access to corporate resources. IDC discovered that 70% of successful breaches originate on the endpoint.
- Play zone defense – Logically isolate every application and require authentication and security checks before access is granted to each. These micro-tunnels are essential for preventing lateral movement, which VMWare found was utilized in nearly 60% of attacks.
Understanding Zero Trust architecture
There are various subtypes for each architecture and every implementation is slightly different, for the case of simplicity we will consider the broad high-level architectures for both SDP and reverse proxy.
Software-Defined Perimeter (SDP)
The Software-Defined Perimeter, also known as Endpoint-Initiated ZTNA in Gartner’s market guide, is based on the Cloud Security Alliance’s architecture. In this design, an application is installed on authorized end-user devices, which shares information about the device and its security context to a ZTNA Controller. This security context would include details about the device, the user’s identity, and other information which can indicate whether trust should be extended. If all of the supplied information matches up against the organization’s policy, the user will be granted access to the requested application.
High-level SDP architecture
The ZTNA Controller denies access to any application until authentication is complete, before then the Gateway does not permit any traffic to flow. Because the Gateway drops all traffic sent by unauthenticated users and devices it effectively makes the application invisible.
Reverse-proxy
The reverse-proxy architecture also referred to as application-initiated ZTNA in the Gartner market guide. Despite the similar-looking diagram, this architecture, which is based on the BeyondCorp model, operates very differently from SDP, and critically no endpoint agent is required.
High-level reverse-proxy architecture
This model requires a connector to be installed on the same network as the application, which establishes an outbound connection to a ZTNA Proxy. Users must then authenticate with the ZTNA Proxy, which verifies credentials against the organization’s identity management system. Once authenticated, traffic is allowed to flow between the device and application via the proxy.
Comparing SDP and reverse-proxy Zero Trust Network Access architectures
Although both architectures have similar features there are some key differences:
- | SDP | Reverse-Proxy |
---|---|---|
Security | The fourth principle of Zero Trust is including information about the security state of the device, this is important contextual information that must be incorporated into the decision to grant access or not. | Clientless reverse-proxy implementation means that there is no end-user app to install, making BYOD and unmanaged device deployments simpler, but it means foregoing essential information about the security of the device - increasing the chance of a breach due to malware siphoning data access by the endpoint or infecting corporate servers. |
Support | SDP has native compatibility with any protocol that simplifies the deployment and enablement of APIs and SaaS services. With support for both browser and software applications, SDP supports for the current and future tools that enterprises may choose to deploy. | A limitation of the routing and protocol compatibility makes reverse-proxy only suitable for certain browser-based or web applications. Being only compatible HTTP and HTTPS restricts the use cases that can be easily supported. To support ZTNA applications with real-time functionality will require additional development to support the additional latency introduced by traffic processing. |
Configuration | Software-defined services can simplify the complex ZTNA and corporate infrastructure requirements, reducing the amount of time teams must spend configuring new applications for remote access. | A feature of some legacy reverse-proxy solutions is that an on-premise connector is required, increasing the deployment time of the ZTNA solution. Additionally, proxy-based solutions require additional time and effort to configure as they can easily break applications if not set up correctly. |
Maintenance | SDP can be fully hosted in the cloud, moving all maintenance, upgrade and patching responsibility to the provider. This gives IT teams more time to focus on other projects. | Regardless of whether on-premise connectors are hardware or software-based it will require ongoing maintenance. Delays patching the connector could allow security vulnerabilities that are discovered to go unremediated. |
Latency | Fully software-defined services can have extremely versatile routing, meaning that traffic does not need to be directed along certain predefined paths, reducing the latency for the end-user. | Although connectors can be hosted anywhere having centralized proxy infrastructure that traffic must travel through adds length to the distance that packets must travel, potentially even creating traffic hairpins. |
Networking | With the freedom to choose and customize the networking protocols used, next-gen encryption and tunneling options which support real-time apps such as Microsoft 365 streaming over wireless connections can be used. | Being web traffic based means that TLS is used by default. This severely limits streaming and real-time apps as TLS-meltdown can easily render the service unusable. |
Showing 1 to 6 of 6 entries
Evaluating different types of Zero Trust architecture
There are a number of important differences between the high-level architectures, however, the assessment of individual solutions should not cause vendors to be dismissed without evaluation. Not all services are built equally and the benefits and weaknesses of each option may have been worked around by development teams.
For example, although SDP vendors have the options of utilizing more modern, advanced networking and encryption techniques they may have opted for more familiar protocols. Many developers use common standards like OpenVPN or IPsec which have numerous issues, such as introducing latency and draining mobile device’s batteries. These offer little to no benefits over TLS limited reverse-proxy solutions. Care must be made to select vendors using the latest technologies.
Additionally, some enterprises may be tempted to use reverse-proxy services because they do not use a device manager or have a significant BYOD user base. In theory, this makes sense because SDP requires a client to be installed, however some developers have worked around this limitation. Easy enrollment techniques and privacy-preserving technologies can make deploying a client a simple process for end-users.
Thorough vetting of architectures is time-consuming however it can be crucial for identifying the optional access solution for an enterprise. ZTNA solutions will be at the heart of the next generation of digital transformation, so selecting the right one is essential.
Summary
Software-defined perimeters and reverse-proxy architecture are the two most common models vendors are basing their ZTNA solutions around. At first glance, they may appear to have little to differentiate them however as this guide has highlighted there is disparity in how they work and what they do.
Overall, SDP solutions appear to provide better security, more flexible networking and broader application support. However, reviews of each solution should be properly conducted as the actual implementation of each architecture by vendors can have a significant effect on the features and performance of the service.
Related Articles:
How Cloud-Native Architectures Reshape Security: SOC2 and Secrets Management
Published: 11/22/2024
The Lost Art of Visibility, in the World of Clouds
Published: 11/20/2024
Group-Based Permissions and IGA Shortcomings in the Cloud
Published: 11/18/2024