ZTNA sur site pour les applications privées

Le ZTNA sur site consiste en un déploiement de l’architecture « zero trust network access » dans lequel le point d’application des politiques pour les applications privées fonctionne sur une infrastructure située au sein des centres de données et des succursales de l’organisation. Les utilisateurs et les systèmes sont authentifiés et autorisés pour chaque application, comme dans tout système ZTNA, mais le trafic entre les utilisateurs sur site et les applications sur site n’a pas besoin de transiter par le cloud d’un fournisseur ni d’en revenir.

Cet article fait partie du guide consacré à la sécurité du cloud hybride.

Comment fonctionne le ZTNA ?

ZTNA vérifie l'identité, l'appareil et le contexte de chaque utilisateur, puis le connecte à une seule application plutôt qu'à un réseau.

L'architecture « zero trust » du NIST, la norme SP 800-207, sépare le point de décision relatif à la politique (qui détermine si un sujet est autorisé à accéder à une ressource) du point d'application de la politique (qui établit, surveille et met fin à la connexion). Les produits ZTNA mettent en œuvre ce modèle pour les applications privées :

1. Un utilisateur ou un système demande à accéder à une application.
2. La requête parvient à un point de traitement, généralement une passerelle, un intermédiaire ou un proxy.
3. La politique évalue l'identité, le groupe, l'état de sécurité de l'appareil, l'emplacement, le risque et l'application spécifique demandée.
4. Si cela est autorisé, le point d'application relie l'utilisateur à cette application uniquement. Le reste du réseau reste invisible.
5. La session fait l'objet d'une surveillance et peut être interrompue si les conditions changent.

Le guide pratique SP 1800-35 du NIST , intitulé « Mise en œuvre d'une architecture Zero Trust » et publié en juin 2025, présente 19 exemples de mise en œuvre réalisés avec 24 fournisseurs dans des environnements sur site et dans le cloud ; il constitue une référence utile pour comprendre comment ces composants s'articulent concrètement.

ZTNA hébergé dans le cloud ou sur site

La différence réside dans l'endroit où s'effectue le contrôle : dans le cloud du fournisseur pour chaque session, ou sur les passerelles du client lui-même pour les sessions locales.

Dans un modèle classique de courtage cloud, une machine virtuelle de connexion légère s’exécute à côté de l’application et ouvre un tunnel sortant vers la passerelle du fournisseur ; aucun port entrant du pare-feu n’est donc nécessaire. Skyhigh Private Access fonctionne de cette manière pour l’accès à distance : le trafic client est géré au point de présence SSE et acheminé via des tunnels TLS vers des connecteurs déployés dans le même centre de données, cloud privé ou cloud public que l’application.

Le ZTNA sur site ajoute une voie d'application locale afin que les utilisateurs et les systèmes situés au sein du réseau bénéficient du même contrôle par application sans avoir à quitter le bâtiment.

Pourquoi l'application de la loi au niveau local est-elle importante ?

La mise en œuvre locale évite les boucles de retour, permet d'accéder au trafic interne et à celui des agents IA, et continue de fonctionner en cas de panne du cloud.

Le « hairpinning ». Le fait d'acheminer le trafic d'un utilisateur de bureau vers un courtier cloud, puis de le renvoyer vers un serveur situé au bout du couloir, augmente la latence et la dépendance vis-à-vis d'Internet, sans apporter aucun avantage en matière de sécurité.

Trafic interne. Une grande partie du trafic que le modèle « zero trust » est censé régir ne franchit jamais la périphérie d’Internet : sessions d’administration, appels entre applications, accès des ingénieurs aux systèmes OT. Une mise en œuvre exclusivement dans le cloud ne permet pas de le détecter.

Agents IA et comptes de service. Les agents autonomes et les comptes de service peuvent disposer d’un accès au niveau utilisateur et transférer des données entre les systèmes internes à la vitesse de l’ordinateur. Skyhigh soutient que le contrôle de ces flux doit s’effectuer au sein même du réseau d’où provient le trafic (Skyhigh Security).

Continuité. En cas de défaillance du cloud du fournisseur ou de la connexion Internet, les sessions locales se poursuivent conformément à la politique appliquée localement. Veuillez vérifier auprès de votre fournisseur la durée maximale de déconnexion prise en charge ainsi que le comportement des contrôles de conformité et d'identité.

Souveraineté. Le trafic des applications locales peut rester au sein de l'infrastructure du client. Identifiez où les décisions relatives aux politiques, les vérifications d'identité et les métadonnées de session sont traitées et stockées. Lorsqu'une session Skyhigh nécessite une protection des données appliquée dans le cloud, le contenu concerné est transféré vers le cloud Skyhigh afin d'y être inspecté conformément à la même politique.

Contrôles d'identité

Le ZTNA sur site doit appliquer les mêmes exigences strictes en matière d'identité que l'accès à distance :

• Authentification via le fournisseur d'identité de l'entreprise avec une authentification multifactorielle (MFA) résistante au phishing
• État du terminal : statut de gestion, version du système d'exploitation, chiffrement du disque, protection des terminaux
• Groupe et rôle, associés à des droits spécifiques à chaque application
• Contexte : lieu, heure, score de risque issu de l'analyse comportementale
• Charge de travail et identité de l'agent pour les accès non humains
• Évaluation continue, avec interruption de la séance en cas de changement de posture ou de risque

Une lacune courante consiste à exempter les utilisateurs sur site des contrôles de conformité des appareils. Le simple fait d'être connecté au réseau local de l'entreprise ne constitue pas une conformité.

Emplacement des connecteurs et des passerelles

Placez les passerelles à proximité des applications qu'elles protègent, au sein de groupes redondants, en mettant en place une segmentation autour d'elles.

• Placez les passerelles à proximité des applications qu'elles protègent, sur le même segment ou sur un segment adjacent, de sorte que l'application protégée ne soit accessible que par l'intermédiaire de la passerelle.
• Déployez-les par groupes pour optimiser la capacité et la disponibilité, et associez les applications à des groupes plutôt qu'à des passerelles individuelles.
• Limitez la connectivité aux communications sortantes uniquement pour les chemins gérés par le cloud, afin que les applications ne soient pas exposées aux connexions entrantes.
• Utilisez la segmentation du réseau gérée par le client pour empêcher une passerelle compromise d'accéder à des systèmes non concernés.
• Prévoyez la configuration des succursales. Déterminez si chaque succursale disposera d'une passerelle locale ou si elle sera reliée à une passerelle régionale.

Chemins d'accès locaux

Une architecture ZTNA hybride nécessite trois voies d'accès distinctes, toutes régies par une seule politique :

1. D'un utilisateur sur site à une application sur site : passerelle locale, sans aller-retour via le cloud.
2. De l'utilisateur distant à l'application sur site : du courtier cloud au connecteur local ou à la passerelle.
3. De l'utilisateur sur site à l'application hébergée dans le cloud : passerelle locale ou intermédiaire cloud vers un connecteur dans l'environnement cloud.

Ces trois éléments doivent utiliser une seule et même définition de politique, afin que les droits d'un utilisateur ne varient pas en fonction de son emplacement.

Un exemple d'architecture « zero trust » pour le cloud hybride

Une architecture hybride « zero trust » combine l'application des règles au niveau local et dans le cloud au sein d'une même couche d'identité et de politiques, comme le montre cet exemple.

Prenons l'exemple d'une entreprise de services financiers disposant d'un centre de données au siège, de 40 agences, d'un environnement IaaS et d'un personnel travaillant à distance.

• Identité : un fournisseur d'identité avec authentification multifactorielle (MFA) ; état de sécurité des appareils issu de la gestion des terminaux.
• Siège social : les passerelles ZTNA locales font office de passerelles d'accès aux interfaces d'administration du système bancaire central et aux outils internes. Le personnel sur place se connecte directement via la passerelle locale.
• Agences : les passerelles des agences contrôlent l'accès aux systèmes des agences et redirigent les requêtes vers les passerelles du siège pour les applications centrales.
• IaaS : les connecteurs situés dans l'environnement cloud servent d'interface aux charges de travail ; les utilisateurs, qu'ils soient à distance ou sur site, y accèdent via le courtier approprié.
• Personnel à distance : les points de présence dans le cloud permettent d'accéder à la fois aux applications des centres de données et aux applications IaaS.
• Agents IA : les identités de service des assistants IA internes bénéficient de droits spécifiques à chaque application, qui sont appliqués localement.
• Politique : un ensemble unique de règles régit l'ensemble des chemins d'accès, géré à partir d'une seule console.

En cas de défaillance de la connexion Internet, le personnel du siège et des agences continue de travailler avec les applications locales, et l'application des règles se poursuit au niveau local pendant la durée prévue pour le fonctionnement hors ligne.

Exigences de déploiement à évaluer

Évaluez les solutions ZTNA sur site au regard de ces exigences avant de présélectionner les fournisseurs.

• Exécution locale pour les utilisateurs sur site sans « hairpinning » vers le cloud
• Mêmes règles et mêmes droits pour les chemins d'accès locaux et distants
• Application des règles de configuration des appareils pour les utilisateurs sur site
• Prise en charge des identités non humaines et des agents d'intelligence artificielle
• Protocoles pris en charge : Web, SSH, RDP, bases de données et TCP/UDP traditionnels
• Haute disponibilité et groupes de connecteurs
• Comportement défini lorsque le cloud du fournisseur ou le fournisseur d'identité est inaccessible
• Enregistrement de l'emplacement et intégration SIEM
• Intégration avec la passerelle Web et le système DLP afin d'assurer la protection des données lors des sessions d'applications privées

Logiciel d'architecture « zero trust » pour le cloud hybride

Le ZTNA est l'un des composants d'une architecture hybride « zero trust ».

Cette solution s'intègre aux fournisseurs d'identité, aux outils de gestion des terminaux, aux passerelles Web, aux CASB, aux solutions DLP et à la segmentation. Évaluez le ZTNA comme un élément de la plateforme qui assurera le respect du reste de votre politique, et non comme un simple substitut autonome au VPN. Consultez l'article « Solutions de sécurité pour le cloud hybride : comment comparer les fournisseurs ».

Comment Skyhigh met en œuvre le ZTNA sur site

Skyhigh propose une solution ZTNA sur site via des passerelles locales au sein du réseau maillé SSE hybride, parallèlement à l'Private Access, gérée via le cloud.

Dans Skyhigh Hybrid SSE Mesh, le ZTNA local fonctionne sur les passerelles sur site et en succursale de l’organisation, au sein d’une infrastructure dont celle-ci est propriétaire et qu’elle modifie sous son propre contrôle, plutôt que sur un nœud local exploité par un fournisseur, étendant ainsi l’application du modèle « zero trust » aux utilisateurs internes, aux ressources et aux agents d’IA. Skyhigh Private Access continue de gérer l’accès à distance via les points de présence Skyhigh, et ces deux solutions sont gérées à partir d’une seule console et d’un seul moteur de politiques, aux côtés des solutions SWG, CASB et DLP.

Sources

1. NIST. SP 800-207 : Architecture « Zero Trust » (août 2020). https://csrc.nist.gov/pubs/sp/800/207/final
2. NIST NCCoE. SP 1800-35 : Mise en œuvre d'une architecture « Zero Trust » (juin 2025). https://csrc.nist.gov/pubs/sp/1800/35/final
3. CISA. Modèle de maturité « Zero Trust », version 2.0. https://www.cisa.gov/zero-trust-maturity-model
4. Skyhigh Security. « Comment fonctionne Skyhigh Private Access ». https://success.skyhighsecurity.com/docs/how-skyhigh-private-access-works
5. Skyhigh Security. « Moderniser votre infrastructure Symantec Edge Secure Web Gateway , grâce à Skyhigh Hybrid SSE Mesh » (15 juillet 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html