ZTNA auto-hébergé ou cloud
« ZTNA cloud » et « ZTNA auto-hébergé » semblent être deux catégories simples. En pratique, plusieurs architectures existent entre les deux. La question la plus utile est :
Qui exploite le plan de contrôle, où circule le trafic applicatif et quelles fonctions restent opérationnelles lorsque des services externes sont indisponibles ?
Ce guide compare les principaux modèles sans supposer qu'un modèle est toujours supérieur.
Quatre modèles d'exploitation courants
1. ZTNA cloud
Le fournisseur exploite gestion, politiques et accès sous forme de plateforme cloud. Cela peut réduire le travail d'infrastructure du client et fournir disponibilité et couverture géographique gérées par le fournisseur.
2. Plan de contrôle fournisseur + connecteurs client
Le fournisseur exploite la coordination et les politiques centrales tandis que le client déploie connecteurs, passerelles ou service edges près des applications privées. Selon le produit, le trafic peut passer par les composants client, les edges du fournisseur, des chemins directs ou une combinaison.
3. ZTNA auto-hébergé
Le client ou un MSP exploite l'infrastructure de contrôle et d'application. Il gagne en contrôle du déploiement mais assume davantage de maintenance, sauvegardes, disponibilité et supervision.
4. ZTNA autonome / déconnecté
La plateforme peut fonctionner sans service de contrôle obligatoire du fournisseur. C'est le modèle pertinent pour les environnements durablement isolés, fortement restreints ou totalement air-gapped.
Exploitation du plan de contrôle
Le plan de contrôle gère généralement configuration, identités, ressources, politiques, autorisation et workflows administratifs. Dans un service cloud, il est exploité par le fournisseur ; dans un système auto-hébergé, par le client ou le MSP. Aucun n'est automatiquement plus sûr : les frontières de confiance et responsabilités diffèrent.
Demandez qui peut administrer, où est stockée la configuration, quels services externes sont requis, ce qui reste disponible sans Internet et qui est responsable de quoi.
Plan de données
L'emplacement du plan de contrôle ne dit pas nécessairement où passe le trafic applicatif. Un produit géré dans le cloud peut garder le trafic directement entre composants client ; un autre peut le faire passer par des service edges fournisseur. Un système auto-hébergé peut proxyfier ou router via l'infrastructure du client. Évaluez séparément coordination des politiques et chemin réel des données.
Dépendance Internet
Un service connecté peut offrir une excellente disponibilité tout en dépendant du cloud fournisseur pour gestion, nouvelles autorisations, coordination d'authentification ou autres fonctions. Cela peut être souhaitable en entreprise. Un environnement déconnecté exige une autre réponse.
« Fonctionne pendant une panne temporaire » n'est pas équivalent à « peut fonctionner durablement air-gapped ».
Identité et authentification
Le ZTNA cloud s'intègre souvent aux fournisseurs d'identité cloud. Les produits auto-hébergés peuvent prendre en charge identités externes, locales ou les deux. Un modèle air-gapped doit utiliser les méthodes d'identité et d'authentification disponibles dans l'environnement isolé. La même contrainte s'applique à la MFA : un service push cloud ne peut pas terminer une transaction sans connectivité.
Mises à jour et licences
Dans le cloud, le cycle de vie logiciel relève en grande partie du fournisseur. L'auto-hébergement nécessite un modèle de mise à jour : dépôts, service géré ou paquets manuels. Les environnements déconnectés ont besoin d'un processus hors ligne contrôlé pour les mises à jour et licences lorsqu'elles dépendraient autrement d'une connexion externe.
Disponibilité et reprise après sinistre
Les services cloud fournissent généralement une redondance gérée par le fournisseur. L'auto-hébergement transfère davantage de responsabilité à l'opérateur. Les produits peuvent utiliser clustering, actif/passif, composants distribués ou sauvegarde/restauration — ces modèles ne sont pas équivalents. Il faut demander l'architecture exacte plutôt que se contenter des termes « haute disponibilité » ou « résilience ».
Responsabilités opérationnelles
| Domaine | Cloud | Auto-hébergé / client ou MSP |
|---|---|---|
| Infrastructure du plan de contrôle | Fournisseur | Client ou MSP |
| Correctifs plateforme | Principalement fournisseur | Client/MSP selon le processus fournisseur |
| Mise à l'échelle | Principalement fournisseur | Client/MSP |
| Sauvegardes | Principalement fournisseur | Client/MSP |
| Disponibilité de la supervision | Fournisseur + intégration client | Client/MSP |
| Dépendance Internet | Selon le produit, souvent importante | Selon le produit, parfois évitable |
| Aptitude à l'air gap | Selon le produit | Possible si l'architecture le permet |
Davantage de contrôle signifie aussi davantage de responsabilité.
Conformité et contrôle des données
Certaines organisations préfèrent le cloud pour sa standardisation et sa portée mondiale. D'autres doivent garder l'infrastructure dans des frontières définies pour des réseaux isolés, politiques internes, environnements réglementés, contrats ou contraintes de localisation/dépendance. Le bon choix dépend des exigences réelles.
Où se situe ZTXGate
ZTXGate s'exécute dans une infrastructure exploitée par le client ou un MSP. Son fonctionnement principal ne requiert pas de plan de contrôle cloud CoreZT obligatoire.
ZTXGate autonome : peut rester totalement air-gapped ; licences et mises à jour sont manuelles ; ZTXBAS intégré peut fonctionner dans l'environnement déconnecté lorsqu'il est sous licence.
ZTXGate avec ZTXHub optionnel : ZTXGate reste exploité par le client/MSP ; ZTXHub appartient à CoreZT et est exploité par CoreZT ; il centralise les mises à jour et licences et reste optionnel pour l'accès principal.
Résilience : ZTXGate ne fournit pas actuellement de clustering HA conventionnel. Des sauvegardes périodiques peuvent être restaurées dans un nouveau déploiement. Il s'agit d'un modèle DR sauvegarde/restauration, pas d'un basculement automatique.
Découvrir le ZTNA auto-hébergé · Pas de plan de contrôle cloud obligatoire
Questions à poser à tout fournisseur ZTNA
- Qui exploite le plan de contrôle ?
- Où circule le trafic ?
- Quels composants côté client sont requis ?
- Que se passe-t-il si le cloud fournisseur est indisponible ?
- Le système peut-il fonctionner durablement déconnecté ?
- Quelles fonctions d'identité/posture dépendent de services externes ?
- Comment les mises à jour sont-elles livrées ?
- Comment les licences fonctionnent-elles hors ligne ?
- Quel est le véritable modèle de disponibilité ?
- Qui gère sauvegardes et reprise après sinistre ?
- Quelles fonctions exigent un logiciel endpoint ?
- Quelles responsabilités restent au client ou au MSP ?
Ces réponses révèlent généralement plus que l'étiquette « ZTNA ».