Chris ScheelsApril 22, 2021
ZTNA Guide, Part 2: ZTNA Architecture: Exploring Your Zero Trust Architecture Options
This blog is part 2 of our 4-part guide to Zero Trust Network Access (ZTNA). Part 1 provides a ZTNA definition and general conceptual overview. This part describes the different ZTNA architecture approaches. Part 3 explains what you should look for in a ZTNA solution and part 4 reviews the top considerations you should keep in mind during ZTNA implementation.
There are multiple ZTNA architecture approaches: client-based vs. browser-based, self-hosted vs. as-a-service. All zero trust architecture approaches offer benefits over traditional access solutions. Still the differences in their architectural makeup are worth considering when determining the right ZTNA solution for your organization’s current and future requirements.
Client-based ZTNA solutions require the installation of an agent on each device that will be accessing network resources. The agent enforces security policies and provides the user with a single sign-on experience when authenticating to multiple applications.
Browser-based ZTNA solutions do not require agents to be installed on devices, but instead rely on a browser plugin to enforce security policies and provide a single sign-on experience.
Self-hosted ZTNA solutions are typically deployed on-premises and managed by the organization’s IT staff.
As-a-service ZTNA solutions are hosted in the cloud and managed by the service provider.
Continue reading to learn more about each of these unique solutions.
Exploring Different ZTNA Architecture Approaches
ZTNA Architecture, Option 1A: Client-based
This architecture is similar to the Cloud Security Alliance (CSA) Software-Defined Perimeter architecture. In this setup, a client is installed on a server or user’s device and the endpoint initiates the connection process.
Pro of Client-Based ZTNA Architecture
This approach's advantage is the ability to apply Zero Trust for all private resources, including custom or legacy applications and enhance device posture checks as criteria for trusted access.
Con of Client-Based ZTNA Architecture
There can be situations where access from an unmanaged device is required to connect and a client can’t be installed. For example, this can occur when setting up third-party or contractor access.
ZTNA Architecture, Option 1B: Browser-based
This architecture is similar to the Google BeyondCorp vision, which is essentially a “clientless” or browser-based approach. In this instance, the user connects to the web application via a common internet browser.
Pro Browser-Based Zero Trust Architecture
A browser-based ZTNA architecture provides frictionless web application access, a viable option for unmanaged devices in which a client's installation isn’t allowed or possible. It is best to use this approach for smaller, less complex, web-only applications or a one-off use case.
Con Browser-Based Zero Trust Architecture
This type of ZTNA architecture only supports web applications and web protocols, which have significant limitations. Therefore, browser-based is not a viable solution for a full Zero Trust deployment, which requires integration with non-web-based applications.
ZTNA Architecture, Option 2A: Self-hosted Deployment
This ZTNA architecture gives organizations complete control of their deployment without any ongoing management from the ZTNA provider. This includes infrastructure instantiation, management and monitoring, software upgrades and security patches, as well as the configuration of policies, integrations and user onboarding.
Pro Self-Hosted Deployment ZTNA Architecture
Less vendor-dependent, which typically translates to lower cost and greater control across the data plane without introducing a vendor cloud solution.
Con Self-Hosted Deployment Zero Trust Architecture
Requires internal resources for initial setup and ongoing management to ensure up-to-date software versions across the entire enterprise.
ZTNA Architecture, Option 2B: As-a-Service Deployment
Deploying ZTNA as-a-service is a simplified way for achieving Zero Trust and can be very appealing for SMB and mid-market businesses. This approach leverages the vendor for hosting and managing the ZTNA controller and gateway, assuming responsibility for infrastructure instantiation, management, monitoring and applying upgrades and security patches.
Pro As-a-Service Deployment Zero Trust Architecture
Less internal resources are required to set up and maintain the ZTNA architecture, as well as comfort in knowing software is the most up-to-date.
Con As-a-Service Deployment ZTNA Architecture
As-a-service solutions require a premium for vendor hosting and often data passing through a vendor cloud can impact data control or compliance requirements.
Taking A Hybrid Approach
There are select few ZTNA providers that offer a hybrid model, which allows an enterprise to blend the advantages of all architectural approaches, depending on the use case. For example, this might include selecting browser-based access for third-party access to a web-based application and using the client for critical and legacy applications. Or, leveraging as-a-service deployment for a resource-constrained region while self-hosting where your internal staff can handle the ongoing management.
Picking the Right ZTNA Architecture
Before starting your Zero Trust journey, you must consider how you want to set up your ZTNA instance. As described above, setup will impact what components of the network can or can't be secured. The long-term strategy with Zero Trust is to protect the entire enterprise ... any user, any device, any resource, in any location. Therefore, we recommend a solution that allows for flexibility with as many deployment options as possible as you ramp up your Zero Trust implementation.
There are a few different ways to architect your ZTNA. The first is through an on-premises solution, which gives you more control over how traffic flows through your network and what data is stored where. However, this option requires more upkeep from an IT perspective and can be expensive to scale.
Another option is to use a cloud-based solution, which can be more cost-effective and easier to scale. With a cloud solution, traffic is routed through the ZTNA provider's infrastructure before reaching your internal network. This means you'll have less control over how traffic flows and where data is stored, but it can be a good option if you're just getting started with Zero Trust.
The third option is a hybrid solution, which combines on-premises and cloud-based components. This can give you the best of both worlds: the control of an on-premises solution with the flexibility and scalability of a cloud solution.
No matter which architecture you choose, make sure it's one that will allow you to easily add new users, devices, and resources as you expand your Zero Trust implementation.
Want to explore how ZTNA architectures play into your ZTNA vendor selection?
When it comes to ZTNA there are a few different ways that vendors approach the architecture. Some vendors take a more traditional network security approach, while others focus on cloud-based security models
It's important to understand the different ZTNA architectures when you're evaluating ZTNA vendors, as it will impact the way the security solution is deployed and managed.
Read the complete guide to ZTNA eBook to learn more about selecting the right ZTNA architecture for your organization.
Ready to learn more about the Appgate SDP ZTNA architecture?