VPN et ZTNA répondent différemment à l'accès distant. Principes du Zero Trust, fin du SSL VPN tunnel dans FortiOS 7.6.3 et démarche de migration.
Le VPN chiffre un tunnel entre un poste distant et le réseau de l'entreprise, puis fait généralement confiance à l'utilisateur une fois connecté. Le Zero Trust Network Access (ZTNA) inverse cette logique : chaque accès à chaque application est vérifié, en continu, selon l'identité, l'état du poste et le contexte. Les deux approches coexistent aujourd'hui, et comprendre leurs différences permet de choisir la bonne architecture pour le télétravail et les prestataires.
Un VPN d'accès distant (souvent appelé « client-to-site » ou « dialup ») établit un tunnel chiffré entre le poste de l'utilisateur et une passerelle, par exemple un pare-feu. Une fois authentifié, l'utilisateur reçoit une adresse du réseau interne et peut joindre les ressources autorisées par les règles de filtrage.
Ce modèle reste simple à comprendre et fonctionne avec presque toutes les applications, y compris les protocoles anciens. Ses faiblesses sont connues :
Le modèle Zero Trust est formalisé par le NIST dans la publication SP 800-207 (Zero Trust Architecture, août 2020). Son principe central : aucune confiance implicite n'est accordée à un utilisateur ou à un équipement du simple fait de sa localisation réseau ou de son appartenance à l'entreprise. L'authentification et l'autorisation sont réalisées avant chaque session vers une ressource, et la protection porte sur les ressources elles-mêmes plutôt que sur des segments de réseau.
Le ZTNA est la déclinaison de ce modèle pour l'accès aux applications. Concrètement :
Un changement important concerne les administrateurs FortiGate. À partir de FortiOS 7.6.3, le mode tunnel SSL VPN n'est plus pris en charge : les configurations correspondantes, y compris les règles de pare-feu associées, ne sont pas reprises lors de la mise à niveau. Fortinet demande de migrer ces accès vers l'IPsec VPN avant de passer en 7.6.3. L'IPsec peut désormais utiliser TCP comme transport (port 443 par défaut), ce qui aide lorsque l'UDP est filtré ou dégradé par un opérateur. Le mode web SSL VPN est conservé, mais renommé « Agentless VPN ». Enfin, un FortiGate configuré comme client SSL VPN n'est plus supporté et doit passer à un client IPsec dialup.
Si votre parc repose encore sur le mode tunnel SSL VPN, il faut donc planifier la migration (profils FortiClient, authentification, règles) avant toute mise à jour de firmware.
Fortinet propose un ZTNA qui s'appuie sur des briques existantes :
Pour les organisations qui préfèrent un service cloud, FortiSASE fournit ces fonctions d'accès sécurisé depuis le cloud, sans passerelle à héberger soi-même.
Dans la pratique, peu d'entreprises passent du VPN au ZTNA en une seule étape. Une démarche progressive donne de meilleurs résultats :
Pour les entités soumises à la loi n° 05-20 relative à la cybersécurité au Maroc, ce travail s'inscrit naturellement dans les exigences de sécurisation des accès aux systèmes d'information, dont l'application est encadrée par le décret n° 2-21-406 et suivie par la DGSSI.
Mettre en œuvre un VPN IPsec et un ZTNA sur FortiGate demande une bonne maîtrise de FortiOS : règles, authentification, certificats, profils de sécurité. La préparation à la certification FortiGate Administrator couvre ces fondamentaux. Pour replacer ces choix dans une architecture de sécurité complète, CompTIA Security+ apporte les bases, et ISC2 CISSP s'adresse aux profils qui conçoivent et pilotent la stratégie d'accès.
Le VPN n'a pas disparu, mais il n'est plus suffisant comme unique réponse à l'accès distant. Le ZTNA réduit la surface d'exposition en donnant accès à des applications précises, après vérification continue de l'utilisateur et du poste. Pour les environnements Fortinet, la fin du mode tunnel SSL VPN est une bonne occasion de revoir l'architecture d'accès dans son ensemble.