Zero Trust Network Access

Architecture Guide
Version 7.0
FORTINET DOCUMENT LIBRARY
https://docs.fortinet.com

FORTINET VIDEO GUIDE

https://video.fortinet.com

FORTINET BLOG
https://blog.fortinet.com

CUSTOMER SERVICE & SUPPORT

https://support.fortinet.com

FORTINET TRAINING & CERTIFICATION PROGRAM

https://www.fortinet.com/training-certification

NSE INSTITUTE
https://training.fortinet.com

FORTIGUARD CENTER
https://www.fortiguard.com

END USER LICENSE AGREEMENT

https://www.fortinet.com/doc/legal/EULA.pdf

FEEDBACK
Email: techdoc@fortinet.com

January 12, 2022

Zero Trust Network Access 7.0 Architecture Guide
01-700-765857-20220112
 TABLE OF CONTENTS

Change Log 4
What is ZTNA architecture? 5
Audience 6
About this guide 7
Technology used 8
Design overview 9
Design concepts and considerations 9
ZTNA access proxy 9
ZTNA secure access 11
ZTNA telemetry, tags, and policy enforcement 12
Summary 12
Design components 12
Design examples 13
Design topology 15
Planning and provisioning 17
Phase one - migration of existing infrastructure 17
Phase two - adding ZTNA controls 17
More information 19

Zero Trust Network Access 7.0 Architecture Guide 3

Fortinet Inc.
Change Log

Date Change Description

2021-12-28 Initial release.

2022-01-12 Updated What is ZTNA architecture? on page 5.

Zero Trust Network Access 7.0 Architecture Guide 4

Fortinet Inc.
What is ZTNA architecture?

With ZTNA access proxy, we form a secure connection without a dial-up VPN, and we can narrow the access surface to
specific applications, which shrinks the attack surface. Following are examples of common use cases for ZTNA:

Use Case Description

Web application access proxy Access to web applications over HTTPS using the ZTNA access
proxy

TCP forward access proxy (TFAP) Access to other applications with ZTNA TCP forward access proxy

ZTNA identity and posture Use ZTNA rules to tag endpoints with identity or posture telemetry

Identity Provider (IdP) integration Integrate different types of IdPs for use with multi-factor
authentication (MFA)

Following is an example architecture of ZTNA:

Zero Trust Network Access 7.0 Architecture Guide 5

Fortinet Inc.
What is ZTNA architecture?

Whether users are located within the corporate network in HQ or located remotely in a coffee shop, in a home, or at a
branch office, they can access internal resources securely by using ZTNA without additional VPN connections. The
FortiGate access proxy verifies device identity, user identity, device health, geolocation, time, and application
permissions before allowing access to provide a consistent user experience inside and outside the corporate network.
This document explores the details of this ZTNA architecture further and dives into each component and design
considerations for your environment.

Audience

Mid-level network and security architects in companies of all sizes and verticals should find this guide helpful.

Zero Trust Network Access 7.0 Architecture Guide 6

Fortinet Inc.
What is ZTNA architecture?

About this guide

This guide is meant to provide high level insight into architectures for different zero trust use cases. It is meant to be used
in conjunction with other technical documentation for each of the components listed in the guide. Where relevant, links to
the administrative guides and other technical reference guides will be listed. See also More information on page 19.

Zero Trust Network Access 7.0 Architecture Guide 7

Fortinet Inc.
Technology used

Zero Trust Network Access (ZTNA) is an access control method that uses client device identification, authentication, and
Zero Trust tags to provide role-based application access. It gives administrators the flexibility to manage network access
for on-net local users and off-net remote users. Access to applications is granted only after verifying the device,
authenticating the user’s identity, authorizing the user, and performing context-based posture checks by using Zero
Trust tags.
The solution is comprised of natively integrated components that include:
l FortiGate Next-Generation Firewall (NGFW)
l FortiClient Endpoint Management Server (EMS)
l FortiClient
Depending on customer complexity and requirements, the following may also be added:
l FortiManager
l FortiAnalyzer
l FortiAuthenticator
l FortiToken
The following ZTNA solutions are discussed in this guide:
l ZTNA access proxy
l HTTPS and TCP access proxy solution and architecture

l Applies to both remote access and internal access

l No persistent connection (such as VPN) is necessary

l ZTNA non-access proxy (also known as ZTNA secure access)

l Remote users continue to access the network by using VPN, but with additional layers of ZTNA device identity

and ZTNA posture checking through rules and tagging

l Local users are provided access through local access policies with ZTNA posture checks

Zero Trust Network Access 7.0 Architecture Guide 8

Fortinet Inc.
Design overview

In this architecture, the goal is to increase security or reduce the burden for the security staff when exposing applications
for access by remote users. The increase in security comes from a seamless integration of device identity, user identity,
and posture checking. This eases the security burden by reducing the number of point products that manage device
certificates, posture checks, and other identity verification technologies.
This section includes the following topics:
l Design concepts and considerations on page 9
l Design examples on page 13
l Design topology on page 15

Design concepts and considerations

When designing your Zero Trust Access solution, consider how this differs from traditional remote access over VPN.
Traditionally, VPN is used to secure data flowing in an otherwise insecure connection. However, the method of access
over VPN often doesn't account for the risk of infected or non-compliant endpoints infecting network devices. Given the
greater risks of allowing remote devices into the network, their access is often limited.
ZTNA tackles some of these issues by securing your traffic over an SSL connection, validating the device identity,
verifying that appropriate endpoint security features are turned on, and authenticating user identity. These measures
help reduce security risk factors to give remote users a level of access similar to what is available when working locally in
the office. This also gives rise to role-based application access, where access is granted based on the user and device
roles, instead of the traffic source.
The ZTNA solution can be categorized into following solutions:
l ZTNA access proxy on page 9
l ZTNA secure access on page 11
The solutions also use ZTNA telemetry, tags, and policy enforcement on page 12.

ZTNA access proxy

ZTNA access proxy allows users to securely access resources through an SSL encrypted access proxy. This simplifies
remote access by eliminating the use of dial-up VPNs. ZTNA rules and tagging offer additional identity and posture
checking.

Zero Trust Network Access 7.0 Architecture Guide 9

Fortinet Inc.
Design overview

With ZTNA access proxy, FortiGate access proxy can proxy HTTP and TCP traffic over secure HTTPS connections with
the client. This enables seamless access from the client to the protected servers, without needing to form IPsec or SSL
VPN tunnels.
The following methods can be used for ZTNA access proxy:
l HTTPS access proxy on page 10
l TCP forwarding access proxy (TFAP) on page 10

HTTPS access proxy

FortiGate HTTPS access proxy works as a reverse proxy for the HTTP server. When a client connects to a web page
hosted by the protected server, the address resolves to the FortiGate’s access proxy VIP. The FortiGate proxies the
connection, and takes steps to authenticate the user. It prompts the user for their certificate on the browser, and verifies
this against the ZTNA endpoint record that is synchronized from FortiClient EMS. If an authentication scheme, such as
SAML authentication, is configured, the client is redirected to a captive portal for sign-on. If this passes, traffic is allowed
based on the ZTNA rules, and the FortiGate returns the web page to the client.

TCP forwarding access proxy (TFAP)

TCP forwarding access proxy works as a special type of HTTPS reverse proxy. Instead of proxying traffic to a web
server, TCP traffic is tunneled between the client and the access proxy over HTTPS and forwarded to the protected
resource. The FortiClient endpoint configures the ZTNA connection by pointing to the proxy gateway, and then
specifying the destination host that it wants to reach. An HTTPS connection is made to the FortiGate’s access proxy VIP,
where the client certificate is verified, and access is granted based on the ZTNA rules. TCP traffic is forwarded from the
FortiGate to the protected resource, and an end-to-end connection is established.

Zero Trust Network Access 7.0 Architecture Guide 10

Fortinet Inc.
 Design overview

ZTNA secure access

ZTNA secure access is also known as non-access proxy, and it uses ZTNA rules and tagging to provide additional
factors of identification for role-based zero trust access and posture checking, typically for local on-net users or for
remote users when VPN is necessary.

With ZTNA secure access, ZTNA rules are used to tag endpoints. Tagging can be used with on-network or off-network
devices to verify many attributes of an endpoint including:
l Active Directory domain membership
l Active Directory group membership
l OS type and version
l Security posture including antivirus and vulnerability status
When an endpoint is tagged based on a ZTNA rule, the telemetry is relayed to FortiClient EMS, and then on to
connected FortiGates in the form of dynamic address lists that can then be applied to policies. Access is denied or
allowed based on the tag and its use in the policy.
Examples of this include only allowing endpoints that belong to Active Directory or dynamically allowing access to certain
VLANs based on the logged in user’s AD group membership. Deny policies can be used with endpoints when they fall
outside of security posture policies, such as deny access to the finance network segment, if an endpoint is tagged with
critical vulnerabilities.

Zero Trust Network Access 7.0 Architecture Guide 11

Fortinet Inc.
 Design overview

ZTNA telemetry, tags, and policy enforcement

When on-net and off-net FortiClient endpoints register to FortiClient EMS, device information, user logon information,
and security posture information are shared over ZTNA telemetry with FortiClient EMS. Clients also make a certificate
signing request to obtain a client certificate from FortiClient EMS that acts as the ZTNA Certificate Authority (CA).
Based on the client information, FortiClient EMS tags clients with Zero Trust rules. The tags and the client certificate
information are synchronized with the FortiGate in real-time. FortiGate uses the client certificate to verify the client
identity, and grants access based on the ZTNA tags applied in the ZTNA rule.

Summary

In summary, while designing your Zero Trust Access solution, consider where you would apply ZTNA access proxy and
where you would apply ZTNA secure access. Both rely on ZTNA tags and rules, but ZTNA access proxy considers
further the identity of connecting devices and secures traffic between the user and the FortiGate access proxy.
Therefore, it is the more appropriate solution for remote access.
When using ZTNA access proxy, it is also important to consider when to apply HTTPS access proxy or TCP forwarding
access proxy. Generally, web applications will fall under the former, and non-web applications, such as RDP, will fall
under the latter. A special SSH access proxy is also available for SSH-based access and integration with SSH servers.
Finally, each type of access proxy also supports load-balancing. When scaling and redundancy are needed, you can
define multiple servers to load-balance traffic between them.

Design components

Consider the requirements of a ZTNA solution, and align that to the existing network and security infrastructure.
Contemplate any changes that may be necessary to prepare for the zero-trust implementation:

ZTNA solution Existing infrastructure

FortiClient 7.0 For deployment, you can use existing software tools (such as SCCM and so on),
native deployment through FortiClient EMS (Windows only), or an accessible,
manual download location for outliers.

FortiClient Endpoint Ensure endpoints with FortiClient can access FortiClient EMS from everywhere.
Management Server (EMS) 7.0 Consider a location in the DMZ with a VIP. Active Directory (AD) integration with
FortiClient EMS may also be necessary for FortiClient deployment and ease of
applying different endpoint profiles to corresponding groups in AD.

FortiOS ZTNA access proxy 7.0 Review FortiGate performance requirements, and ensure existing FortiGates
meet those requirements. Placement of FortiGate(s) allows physical or virtual
access to protect resources from the edge.

FortiOS identity service provider FortiGate will act as an SP. What existing identity providers (IdPs) exist? Do
(SP) appropriate groups exist in the IdP that will align to the identity and role-based
security goals?

Zero Trust Network Access 7.0 Architecture Guide 12

Fortinet Inc.
Design overview

ZTNA solution Existing infrastructure

FortiAuthenticator Identity and If multiple FortiGates are deployed, FortiAuthenticator may be desirable to
Access Management (IAM) consolidate and manage connections to IdPs, including Active Directory, LDAP,
RADIUS, and SAML providers.

FortiToken The ZTNA solution provides for certificate-based authentication in addition to

Multi-factor Authentication (MFA) user-based credentials that are usually integrated with an IdP. In many cases,
another factor of authentication that utilizes one-time passwords (OTP) is
recommended. An existing OTP product can be integrated through SAML, or you
can apply FortiToken to users on FortiAuthenticator. In smaller, single FortiGate
organizations, FortiToken can be managed directly on the FortiGate.

FortiAnalyzer FortiAnalyzer is recommended for gathering logs and generating reports and
analytics for Fortinet devices. FortiAnalyzer should be available from everywhere.
FortiClient ZTNA sends logs directly to FortiAnalyzer.

Design examples

Let’s use an example architecture of a company that has multiple applications hosted internally and in a private, Azure
cloud.
Currently remote users use VPN to gain access to the internal network, and then access the web-based applications by
using a web browser. Non web-based applications are accessed by using remote desktop (RDP) over VPN to jump to
locations that have the client-server applications installed.
The company recently had a malware outbreak that propagated from one point on the network to many endpoints
connected to the internal network – including those connected over VPN. In its investigation, the company found that the
malware originated from an unmanaged, unpatched device that was connected to the network over VPN. The company
has mandated the implementation of a zero-trust architecture. The following success criteria was detailed:
l Block unmanaged devices
l Require multi-factor authentication
l For remote users, limit direct access to the internal network for web applications or remote desktop services
l Allow only identified user groups access to only the specific applications that they need
l Dynamically deny access to devices with critical vulnerabilities both on the internal network and remote-access
network
l Dynamically allow access once the vulnerabilities are remediated
l Reduce the reliance on dial-up VPN
To achieve the above goals, consider the following ZTNA solutions:

Security goals ZTNA solutions

Block unmanaged devices Use FortiClient

No direct access to internal Use ZTNA HTTPS and TCP-forwarding access proxies
networks for web applications or
remote desktop

Zero Trust Network Access 7.0 Architecture Guide 13

Fortinet Inc.
Design overview

Security goals ZTNA solutions

Allow only identified user groups Use ZTNA access proxies and ZTNA secure access posture checking with
access to only the specific integration to existing IdP, FortiAuthenticator, or firewall users and groups
applications that they need

Dynamically deny access to Use ZTNA secure access posture checking

compromised or vulnerable
devices and dynamically allow
devices after remediation

Require multi-factor Use ZTNA access proxies configured with IdP and FortiToken
authentication (MFA)

Reduce the reliance on dial-up Permit only IT and security personnel to use VPN with ZTNA secure access
VPN posture checking and MFA

Zero Trust Network Access 7.0 Architecture Guide 14

Fortinet Inc.
Design overview

Design topology

In the example topology, minor changes to the existing physical infrastructure were necessary. FortiGates replaced
existing firewalls at headquarters (HQ) and a regional office. A FortiGate VM was added to Azure to provide NGFW
protection for the cloud datacenter, and to mirror existing IPsec VPN services.
The internal application servers stayed in place with the same IP scheme in the server VLAN. For remote clients to reach
the application servers, no dial-up VPN is required.
A DMZ was created to host Fortinet services that must always be accessible from the internet.
An internal client VLAN was created for client access, and it requires all endpoints to pass through the FortiGate. The
NGFW feature and ZTNA secure access protects the server VLAN. For internal network users, ZTNA secure access is
used. For remote users, no access is provided directly to the internal network; ZTNA access proxy is used. To gain
access to the server VLAN the following is required:

Zero Trust Network Access 7.0 Architecture Guide 15

Fortinet Inc.
Design overview

ZTNA component Functional description

FortiClient Installs device certificates from the FortiClient EMS CA service

Performs ZTNA checks required by the following ZTNA rules:
l Active Directory domain login

l Active Directory domain group

l Vulnerability status

l MFA challenge and response

l TCP forward-access proxy certificate exchange

Provides dial-up VPN services during the ZTNA migration period

FortiClient EMS Server l Connects FortiClient endpoints to the FortiGate(s) through the fabric
connector
l Acts as a certificate authority (CA) and delivers certificates to FortiClient
endpoints for device authentication
l Centrally manages ZTNA tagging and delivers posture check requirements
to FortiClient
l Passes endpoint certificates and ZTNA tagging information to the FortiGates
for use in ZTNA rules and firewall policies

FortiGate ZTNA access proxy l Provides an HTTPS access-proxy for web applications as well as TCP
forwarding access-proxy for the RDP requirement
l In this design, no access is granted unless an endpoint passes the checks
executed by FortiClient as outlined above

FortiGate ZTNA secure access For internal users, it was decided not to use a full access-proxy, but ZTNA posture
and identity checks are required to gain access to the server VLAN

FortiAuthenticator and Because more than one FortiGate is in the topology, it was decided to implement
FortiToken FortiAuthenticator to:
l Centrally configure and manage connections to IdPs, which is currently

Active Directory
l Centrally manage FortiToken for OTP as part of the MFA requirement

l Act as a SAML IdP and provide a captive portal for authentication and token

challenge

FortiAnalyzer Logging, reporting, and analytics for all the Fortinet devices. In the future, SOC
features will be enabled to help the company manage security events and
incidents as well as automate response and remediation

Zero Trust Network Access 7.0 Architecture Guide 16

Fortinet Inc.
Planning and provisioning

In this design, two FortiGates were deployed to replace legacy firewalls at the headquarters location as well as at a
regional office. At HQ, the legacy firewall remained in place to allow for migration from dial-up VPN to the new ZTNA
architecture. The systems, network, and security engineers were able to migrate end users by using their existing AD
groups. The FortiClient ZTNA agent was deployed by using an existing software delivery tool.
The deployment workflow was handled in the following phases:
1. Migration of existing infrastructure. See Phase one - migration of existing infrastructure on page 17.
2. Addition of ZTNA controls. See Phase two - adding ZTNA controls on page 17.
For more configuration details, see More information on page 19.

Phase one - migration of existing infrastructure

In phase one, the existing infrastructure is migrated. Following is a summary of the deployment steps covered in phase
one:
1. Install the headquarter FortiGate into the local network. Configure connectivity to the MPLS network, and configure
internet routing. Prepare for future cutover by using generally the same configuration as the existing firewall.
2. Implement the regional office FortiGate, and establish connectivity to the existing MPLS network. After testing, cut
over to the regional office.
3. Implement the FortiGate VM on Azure, and establish IPsec VPN to the headquarter FortiGate. Test and cut over.
4. Implement FortiClient EMS, FortiAnalyzer, and FortiAuthenticator in the FortiGate DMZ.
5. Integrate FortiAuthenticator with Active Directory. Install FortiToken, and configure as a SAML IdP.
6. In FortiClient EMS create endpoint profiles, and package FortiClient by using the software configuration tool in
FortiClient EMS. Provide the FortiClient installer package to systems engineers for installation through software
delivery tools.

FortiClient can co-exist with most existing VPN clients. It was decided to test the co-
existence of both agents for a careful migration for the predominantly remote workforce.
After successful deployment and testing, the legacy VPN client was removed.

7. After FortiClient with dial-up VPN and MFA was successfully deployed, the remote workforce was migrated group
by group to the headquarter FortiGate while still using VPN to connect.
8. Once satisfied that the baseline services were operational at headquarters, the regional office, Azure Cloud
datacenter, and dial-up VPN, the legacy firewalls and Azure VPN gateway were retired.

Phase two - adding ZTNA controls

After the successful migration, the company began adding ZTNA controls in phase two. Following is a summary of the
deployment steps covered in phase two:

Zero Trust Network Access 7.0 Architecture Guide 17

Fortinet Inc.
Planning and provisioning

1. Configure the ZTNA tagging rules in FortiClient EMS, and connect the FortiGate to FortiClient EMS by using a fabric
connector.
2. Ensure the FortiClient EMS connection is established and that ZTNA tags are retrieved.
3. On the FortiGate, configure the access proxy ZTNA Server(s).
a. Define the HTTPS access-proxy and the real server (actual application servers) mappings.
b. Define the TCP forwarding access-proxy and real servers (actual RDP servers) mappings.
c. Configure SSO, authentication settings, authentication scheme and policy.
d. Configure ZTNA rules with multi-factor authentication and posture checking.
e. Configure firewall policies to include ZTNA posture checking from the internal client network segment to the
servers network segment by adding ZTNA dynamic IP address lists to each of the policies that control access
to the applications on the server segment.
The company was then able to migrate remote users group by group from dial-up VPN to the new ZTNA solution. Once
end user acceptance testing was complete, the company was able to remove the VPN configuration by using FortiClient
EMS and limit the dial-up VPN access to only IT and security personnel.
For configuration details, see More information on page 19.

Zero Trust Network Access 7.0 Architecture Guide 18

Fortinet Inc.
More information

Feature documentation:

Product document Specific chapter if available

FortiOS 7.0 Admin Guide ZTNA chapter

FortiClient EMS 7.0 Admin Guide Zero Trust Tags

FortiClient 7.0 Admin Guide

FortiAuthenticator 6.4 Admin Guide

FortiAnalyzer 7.0 Admin Guide

Endpoint Posture Check Reference

Solution hub:
l https://docs.fortinet.com/ztna

Zero Trust Network Access 7.0 Architecture Guide 19

Fortinet Inc.
 www.fortinet.com

Copyright© 2022 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare® and FortiGuard®, and certain other marks are registered trademarks of Fortinet, Inc., and other Fortinet names herein
may also be registered and/or common law trademarks of Fortinet. All other product or company names may be trademarks of their respective owners. Performance and other metrics contained herein were
attained in internal lab tests under ideal conditions, and actual performance and other results may vary. Network variables, different network environments and other conditions may affect performance
results. Nothing herein represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written contract,
signed by Fortinet’s General Counsel, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-identified performance metrics and, in such event, only
the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For absolute clarity, any such warranty will be limited to performance in the same ideal
conditions as in Fortinet’s internal lab tests. Fortinet disclaims in full any covenants, representations, and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change,
modify, transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable.