We consistently hear that organizations are looking at ZTNA to address one or more of these issues. The most common reason people are looking at ZTNA is to support work from anywhere (WFA) initiatives. As organizations emerge from pandemic shut downs, they are looking for way to provide safe access to employees who want to work in the office some days a week and some days in the home. They rolled out VPN access when they pushed everyone out of the office and now they are looking for a better solution for the long term.
Some organizations are looking to ZTNA to help them reduce their risk profile, using the additional checks and segmentation to reduce the attack surface.
Other organizations are concerned about their cloud journey as they shift applications to the cloud and how to maintain control over who has access to those applications. ZTNA can help with that, too.
With respect to the cloud journey, with ZTNA, the IT department maintains granular access control to applications so applications can be moved to the cloud or even between clouds and users will be none the wise. The users will have no idea where the application is hosted as they will only be connecting to the ZTNA enforcement point (which they don’t even know where that is located), and the connection is then passed on to the application (once all the checks have been successfully passed).
The result of these changes is that we have shifted from a network architecture where we work in one place and our applications are in the local data center; one where we can check people at the door and when they connect to the network and then trust them with unfettered access. We’ve shifted from a concentric model to a mesh architecture where we have users working in many locations as we are providing applications in many places. So it makes no sense for us to use the same trust models in this new architecture. We need to shift to an explicit trust model, where we verify a user and device prior to granting access to a resource. That’s the basics of zero trust.
I heard someone describe the idea of zero trust as “treating the inside like the outside”. I think that is a good way to picture the result of deploying zero trust capabilities in that all connections, even internal ones, are evaluated as if they are coming from a remote user.
To use Fortinet’s ZTNA capabilities, organizations need two elements: something running FortiOS, most likely a FortiGate, and our ZTNA agent which is part of FortiClient. ZTNA was introduced in our FOS 7.0 code, which was released in the Spring of 2021 so the FortiGates and FortiClient do need to be on 7.0 or later firmware. If your customer already has FortiGate and FortiClient - no license required for ZTNA.
While and authentication solution required for ZTNA, it is not required to be a Fortinet solution. We do have an excellent solution in our FortiAuthenticator and FortiToken products, or our new FortiTrust Identity services, but Fortinet’s ZTNA will also work with any of the many 3rd party ID providers such as Azure AD, Okta, Ping, etc.
In addition to the fact that our ZTNA agent is part of FortiClient – we should also note that VPN is part of FortiClient. The benefit here is that it allows you to roll out ZTNA to your customers at the pace (migrate to ZTNA one application at a time) that is right for them – and there are no significant architectural changes from their existing Fortinet VPN to Fortinet ZTNA. FortiGate is acting as either the ZTNA enforcement or the VPN concentrator = simplified
Many ask: Will VPNs go away completely?
Over time, application access will shift to ZTNA we expect that 80% of users will be using ZTNA
However, there will be instances when a VPN will still be needed. There could be situation when a user needs to access a network resource - thus they will need a VPN
ZTNA operates above the network – at the application layer – so, there’s no need for ZTNA to grant access to a segment of the network.
And FortiClient is intelligent enough that it knows when to send traffic to ZNTA process and other to VPN – your customers could have both tunnels going and being routed at the same time.
By delivering our ZTNA as part of our firewall, we gain many advantages to the cloud-only solutions on the market. The most important benefit is that by putting the ZTNA in firewall enables it to go wherever a firewall can be deployed. So you can have ZTNA coverage for remote workers as we as those in dense, campus settings, accessing on-prem applications. This really is Universal ZTNA.
Second, because this is a firewall, the traffic going through ZTNA can have the full security stack applied to it.
And because this is a FortiGate firewall, you also have the benefit of license-free SD-WAN and the application awareness for better user experiences.
I also noted that our ZTNA agent is part of FortiClient, our VPN agent. This merged VPN and ZTNA agent makes it easy to transition from a VPN-based remote access to ZTNA application access. Applications can be moved over the ZTNA control one-at-a-time, in a very controlled fashion, ensuring that users get the access they need even as the security is improved.
And finally, these ZTNA capabilities are free. They are included with FortiGate OS and with FortiClient. Existing users simply need to turn them on and new users have no extra licenses to purchase.
So we see that ZTNA is how the access to applications is evolving. It is more than just a replacement for remote access via VPN, it is bringing the principles of zero trust to application access- ongoing verification of users and devices partnered with granted granular access, just enough access to do the job.
And in a rare case, ZTNA is improving the security of the organization while also improving the user experience. With much of the security checks being done in background and with a consistent experience, it’s a win-win for users and security champions.
Thank you for your time
The result of these changes is that we have shifted from a network architecture where we work in one place and our applications are in the local data center; one where we can check people at the door and when they connect to the network and then trust them with unfettered access. We’ve shifted from a concentric model to a mesh architecture where we have users working in many locations as we are providing applications in many places. So it makes no sense for us to use the same trust models in this new architecture. We need to shift to an explicit trust model, where we verify a user and device prior to granting access to a resource. That’s the basics of zero trust.
I heard someone describe the idea of zero trust as “treating the inside like the outside”. I think that is a good way to picture the result of deploying zero trust capabilities in that all connections, even internal ones, are evaluated as if they are coming from a remote user.
The result of these changes is that we have shifted from a network architecture where we work in one place and our applications are in the local data center; one where we can check people at the door and when they connect to the network and then trust them with unfettered access. We’ve shifted from a concentric model to a mesh architecture where we have users working in many locations as we are providing applications in many places. So it makes no sense for us to use the same trust models in this new architecture. We need to shift to an explicit trust model, where we verify a user and device prior to granting access to a resource. That’s the basics of zero trust.
I heard someone describe the idea of zero trust as “treating the inside like the outside”. I think that is a good way to picture the result of deploying zero trust capabilities in that all connections, even internal ones, are evaluated as if they are coming from a remote user.
Starting point is an existing SD-WAN / SD-Branch setup
NOTE, a single location NGFW can also be converted into an SDWAN Hub (so it’s supported)
Add ZTNA for the most secure private app access, and reduce attack surface / chance of ransomware
Enable SASE to secure remote user traffic, plus interconnect with any private apps not yet enable for ZTNA.
As per the animation:
Unified management plane handles endpoint on-boarding plus single / global posture database and unified policy
Single policy and posture installed everywhere
All components inter-connect natively (such as SASE and SDWAN)
