Qu’est-ce que le ZTNA, au juste ?

Le Zero Trust Network Access (ZTNA) est un terme qui, en 2025, n’est plus un simple buzzword. Il rejoint désormais les concepts établis comme le SD‑WAN, l’authentification multi-facteurs (MFA) ou l’IoT.

Il n’existe pas de consensus clair dans l’industrie réseau et sécurité sur la définition exacte du ZTNA. Toutefois, si vous interrogez la plupart des fournisseurs, vous obtiendrez généralement trois principes, exprimés différemment :

• Le client n’est pas considéré comme fiable par défaut et n’a donc accès à rien initialement — c’est le principe du Zero Trust ;
• Les connexions sont établies par application : le client demande l’accès à une ressource spécifique, et non à un sous‑réseau complet ;
• Le client est contrôlé avant et pendant la connexion pour vérifier qu’il est toujours autorisé à accéder à la ressource — c’est le client posturing.

Après cette mise en contexte, voyons comment Fortinet gère les connexions ZTNA en mode transfert TCP.

L’environnement

Nous disposons de :

• Un client externe, appelé FortiClient, qui souhaite accéder à une ressource ;
• Un FortiGate jouant le rôle de proxy d’accès ZTNA : ztnaproxy.ad.labdomain.com ;
• Un serveur FortiClient EMS : ems.ad.labdomain.com, qu’il soit auto-hébergé ou en SaaS ;
• Un serveur LAN : win-server.ad.labdomain.com, accessible via ZTNA, ainsi qu’un serveur win-ad.ad.labdomain.com, utilisé uniquement pour la démonstration.

Versions utilisées : FortiOS 7.4.9, FortiClient 7.4.5, FortiClient EMS 7.4.5.

Commençons par le client, là où tout débute.

Comment FortiClient gère le ZTNA

FortiClient reçoit sa configuration ZTNA depuis EMS. La première étape consiste à déterminer si la ressource demandée correspond à une destination ZTNA. FortiClient vérifie si ce que l’utilisateur tente d’atteindre figure dans sa liste de destinations ZTNA. Si oui, il poursuit le processus.

Qui effectue la résolution DNS des FQDN ZTNA ?

C’est FortiClient lui‑même. C’est le processus FortiTCS (Tunnel Control Service) qui gère :

• la configuration ZTNA reçue d’EMS,
• l’enregistrement des paramètres,
• l’attribution d’adresses IP factices pour la résolution DNS,
• l’exécution d’un proxy DNS local.

Lors d’une mise à jour ZTNA, on observe la liste des destinations ZTNA. FortiClient intercepte donc les requêtes DNS vers les FQDN ZTNA et renvoie une IP factice, même si la connexion n’est pas destinée à ZTNA. Pour les destinations ZTNA définies en IP, rien de particulier : la connexion est simplement transmise.

Rôle de FortiTCS

FortiTCS établit une connexion sécurisée vers le FortiGate (proxy ZTNA / TFAP / ZTNA gateway) et y transfère le trafic pertinent. Lorsqu’un FQDN ZTNA est contacté, FortiTCS génère une requête HTTP GET vers le FortiGate :

GET /tcp?address=win-server.ad.labdomain.com&port=3389&tls=0 HTTP/1.1

Cette requête indique :

• la ressource demandée,
• le port,
• si un chiffrement supplémentaire est demandé.

Le FortiGate doit ensuite résoudre lui‑même le FQDN, car l’IP fournie par FortiClient est factice.

Comment FortiGate gère le ZTNA

Le FortiGate agit comme un proxy : il reçoit la connexion FortiClient et se connecte au serveur réel à sa place. Le traitement ZTNA est assuré par le processus WAD (Web Application Daemon).

Étapes principales côté FortiGate

1. Vérification du certificat client FortiClient envoie le certificat utilisateur fourni par EMS. Le FortiGate vérifie ce certificat via la CA ZTNA d’EMS.
2. Réception de la requête HTTP ZTNA Le FortiGate lit la requête GET envoyée par FortiTCS.
3. Résolution DNS du FQDN cible Le FortiGate résout le FQDN réel (ex. 192.168.1.241).
4. Correspondance avec une politique proxy Le FortiGate identifie la proxy-policy ZTNA correspondante (ex. policy ID 123).
5. Établissement de la connexion vers le serveur réel Le FortiGate se connecte au serveur cible, en appliquant un SNAT par défaut (IP de l’interface de sortie). Un IP pool peut remplacer ce comportement.
6. Création du tunnel de transfert TCP Le FortiGate renvoie un 101 Switching Protocols et établit le tunnel.

ZTNA et UDP

Depuis FortiOS 7.6.0 et FortiClient 7.4.1, ZTNA supporte également l’UDP. FortiClient encapsule alors l’UDP dans TCP, établit une connexion QUIC, puis transfère le trafic comme pour TCP.

EMS est‑il obligatoire ?

Oui, EMS est indispensable pour :

• distribuer les certificats utilisateurs,
• fournir la configuration ZTNA,
• permettre à FortiClient d’être en mode ZTNA complet.

Sans EMS, pas de destinations ZTNA configurables, donc pas de ZTNA TCP forwarding. Ce serveur FortiClient-EMS peut être :

• Hébergé sur votre infrastructure (on premise) ;
• Hébergé dans le cloud Fortinet (EMS Cloud);
• Embarqué dans la solution FortiSASE.