Design considerations
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.
Migrating from SSL VPN to ZTNA
Organizations that have a mature SSL VPN solution in place likely have the following in common:
-
Remote access users and groups are defined on an external server, for example, on a Windows Active Directory.
-
Granular rules are defined to grant distinct user groups access to different resources.
-
For scaling the VPN solution, SSL VPN is offered in tunnel mode to remote users.
-
Remote users have FortiClient installed on their endpoints, and is actively managed by FortiClient EMS.
When the above criteria are met, the basic components and configurations for ZTNA is already in place. Namely, a FortiGate with various user groups defined and FortiClients provisioned and managed by EMS. Administrators can take a phased approach in migrating hosted servers and user groups to ZTNA while incrementally disabling access through SSL VPN.
See the Product prerequisites section for more information on the required and recommended components, and how they form the ZTNA solution.
ZTNA Access Proxy for hosted Web applications
With Web applications hosted on the internal network, ZTNA enables end users to access these applications directly and securely on the browser. Traffic to the destination servers are redirected to the FortiGate access proxy where device identity and posture checking occurs. The FortiGate then grants access and logs the connection.
ZTNA Access Proxy for hosted TCP Applications
ZTNA TCP forwarding access proxy is used for other applications, such as SSH, Remote Desktop Protocol (RDP), and others. The biggest difference in implementation is it requires the FortiClient endpoint to redirect the application request to the ZTNA access proxy using ZTNA mapping rules. These rules can be managed by FortiClient EMS and provisioned to FortiClient Endpoints automatically.
Summary
As discussed in the ZTNA Architecture Guide, when using ZTNA access proxy, it is important to consider when to apply HTTPS access proxy or TCP forwarding access proxy. Generally, web applications will fall under the former. Non-web applications, such as RDP, will fall under the latter, which is most useful for securing remote access. Remember the design goal for Zero Trust Network Access: a device inside the network is trusted no more than a device outside the network. With this in mind, we use ZTNA secure access features to check the posture of devices directly connected to internal network segments and verify the identity of the users accessing the applications locally.
For the purpose of this Deployment guide, we will cover the migration of hosted Web applications to ZTNA only.