Zero Trust Network Access : quand le VPN ne suffit plus

Le modèle de sécurité traditionnel c’est le “castle-and-moat”. On fait confiance à tout ce qui est à l’intérieur du périmètre réseau. Les VPN ont été conçus dans ce paradigme.

Mais putain, le périmètre il est où maintenant ?

Tes employés travaillent de Starbucks. Tes apps tournent sur AWS, GCP, Azure. Tes développeurs utilisent leur laptop perso. Le périmètre il a disparu. Et le VPN avec.

C’est chiant. C’est pénible. Mais c’est la réalité.

ZTNA résout ce problème. Et il le fait bien.

Lexique

C’est là mes définitions et si elles vous déplaisent, cassez-vous je suis pas là pour discuter lexique.

• ZTNA: Zero Trust Network Access — cadre de sécurité qui applique le principe “ne jamais faire confiance, toujours vérifier” pour l’accès aux applications.
• VPN: Virtual Private Network — tunnel chiffré qui connecte un appareil distant au réseau d’entreprise.
• Zero Trust: modèle de sécurité qui suppose que tout utilisateur ou appareil est potentiellement compromis, nécessitant une vérification continue.
• Least Privilege: principe selon lequel un utilisateur ne doit avoir accès qu’aux ressources nécessaires à sa tâche.
• Micro-segmentation: division du réseau en petits segments avec des politiques de sécurité distinctes.
• SDP: Software-Defined Perimeter — architecture qui masque les ressources aux utilisateurs non autorisés.
• SASE: Secure Access Service Edge — architecture qui combine networking et sécurité en un service cloud.
• IAM: Identity and Access Management — gestion des identités et des accès.
• MFA: Multi-Factor Authentication — authentification multi-facteurs.
• PEP: Policy Enforcement Point — point d’application des décisions d’accès.
• PDP: Policy Decision Point — point de décision d’accès.
• Device Posture: état de sécurité d’un appareil (mises à jour, antivirus, configuration).

Le problème avec les VPN

Le VPN c’est simple. Tu te connectes, tu as accès à tout le réseau. C’est comme donner les clés de tout l’immeuble à quelqu’un qui a juste besoin d’aller aux toilettes.

Les problèmes :

• Accès trop large — Une fois connecté, tu as accès à tout. Si tes credentials sont compromis, l’attaquant a un accès libre pendant des heures.
• Authentification unique — Le VPN vérifie l’identité une seule fois au moment de la connexion. Après, c’est la fête.
• Pas de visibilité — Les VPN offrent peu de visibilité sur ce que font les utilisateurs une fois connectés.
• Performance — Le backhauling du trafic через le data center central crée de la latence. Tu es à Tokyo, ton serveur est à Paris. Tu vas attendre.
• Scalabilité — Chaque nouvel utilisateur, c’est un nouveau concentrateur à dimensionner. C’est coûteux et complexe.

Et voilà.

ZTNA : ne jamais faire confiance, toujours vérifier

ZTNA c’est l’inverse du VPN. Au lieu de faire confiance à tout ce qui est à l’intérieur du périmètre, on fait confiance à personne. Chaque demande d’accès est vérifiée, quel que soit l’origine.

Les trois piliers :

• Ne jamais faire confiance — Chaque demande d’accès est vérifiée.
• Toujours vérifier — L’authentification et l’autorisation sont continues, pas ponctuelles.
• Accès minimal — Les utilisateurs n’ont accès qu’aux applications spécifiques dont ils ont besoin.

C’est tout. Pas de miracle. Pas de magie. Juste du bon sens.

Architecture

Composants clés

Utilisateur/Appareil
    │
    ├── Client ZTNA (agent ou clientless)
    │   ├── Vérification identité (MFA)
    │   ├── Vérification posture appareil
    │   └── Contexte (localisation, comportement)
    │
    ├── Policy Decision Point (PDP)
    │   ├── Policy Engine (PE)
    │   └── Policy Administrator (PA)
    │
    ├── Policy Enforcement Point (PEP)
    │   ├── Contrôle d'accès applicatif
    │   └── Micro-segmentation
    │
    └── Ressource/Application
        ├── Apps cloud (SaaS)
        ├── Apps on-premise
        └── Apps hybrides

Flux de connexion

1. Utilisateur tente d'accéder à une application
2. Client ZTNA intercepte la demande
3. Vérification de l'identité (MFA/SSO)
4. Vérification de la posture de l'appareil
5. PDP évalue le contexte et le risque
6. Si autorisé : PEP établit une connexion sécurisée
7. Connexion directe à l'application (pas de backhaul)
8. Surveillance continue pendant la session
9. Réévaluation si le contexte change

Tu vois la différence avec le VPN ? Ici, on vérifie en continu. Pas juste au login.

Modèles de déploiement

Agent-Based

• Agent installé sur chaque appareil
• Vérification locale de la posture
• Contrôle granulaire par appareil
• Idéal pour environnements gérés

Agentless

• Pas d’installation requise
• Via navigateur ou gateway sécurisé
• Compatible avec tous les appareils
• Idéal pour BYOD et accès externe

Cloud-Based

• Service cloud natif
• Scalabilité élastique
• Pas d’infrastructure on-premise
• Idéal pour environnements multi-cloud

Comment部署 ZTNA

Phase 1 — Évaluation (Semaines 1-2)

• Inventorier les applications et ressources à protéger
• Cartographier les flux d’accès actuels
• Évaluer la maturité IAM existante
• Identifier les cas d’usage prioritaires

Phase 2 — Fondations (Semaines 3-6)

• Renforcer l’IAM (MFA, SSO, RBAC)
• Déployer la vérification de posture appareil
• Définir les politiques d’accès par application
• Implémenter la micro-segmentation de base

Phase 3 — Déploiement ZTNA (Mois 2-4)

• Choisir le modèle de déploiement (agent/agentless/cloud)
• Déployer le PDP et PEP
• Configurer les politiques d’accès granulaires
• Intégrer avec les existants (IdP, SIEM, EDR)

Phase 4 — Optimisation (Mois 4+)

• Activer la vérification continue
• Implémenter l’accès adaptatif (step-up auth)
• Intégrer avec SASE pour la sécurité unifiée
• Monitorer et ajuster les politiques

C’est incrémental. Tu commences petit, tu agrandis. Pas besoin de tout casser pour tout refaire.

ZTNA vs VPN — Le comparatif

Ce que ZTNA fait mieux

• Accès granulaire — Pas d’accès réseau large. Chaque application est protégée individuellement.
• Vérification continue — L’identité et la posture sont vérifiées en continu, pas juste au login.
• Micro-segmentation — Les applications sont isolées, limitant le mouvement latéral.
• Performance — Pas de backhaul. Connexion directe aux applications cloud.
• Scalabilité — Cloud-native, pas de hardware à dimensionner.
• Visibilité — Traçabilité complète de chaque accès.

Ce que VPN fait mieux

• Simplicité — Pour un accès réseau basique, le VPN reste plus simple à déployer.
• Applications legacy — Certaines applications anciennes ne supportent pas l’intégration ZTNA.
• Accès réseau — Pour des besoins de réseau complet (pas juste applicatif), le VPN est encore nécessaire.
• Écosystème mature — Plus de solutions, plus de documentation, plus de retours d’expérience.

Le vrai trade-off

Le choix ZTNA vs VPN, c’est un choix de modèle de sécurité et de maturité architecturale.

• Si tu as un environnement cloud/hybride avec remote work → ZTNA
• Si tu as des applications legacy qui ne supportent pas ZTNA → VPN (temporairement)
• Si tu veux une sécurité granulaire et continue → ZTNA
• Si tu as besoin d’un accès réseau complet → VPN (pour l’instant)
• Si tu veux réduire la surface d’attaque → ZTNA
• Si tu as une équipe petite et des besoins simples → VPN

Les deux ont leur place. Le choix dépend de ton contexte.

Cas d’usage

Remote Work

ZTNA connecte les utilisateurs directement aux applications dont ils ont besoin, où qu’ils soient. Pas de backhaul, pas de latence. La vérification continue确保 que même si un appareil est compromis, les dégâts sont limités.

BYOD

Avec ZTNA, tu peux vérifier la posture de l’appareil sans installer d’agent. L’accès est limité aux applications autorisées, pas au réseau complet.

Accès externe (fournisseurs, contractors)

ZTNA permet d’accorder un accès temporaire et granulaire à des applications spécifiques. L’accès peut être time-bound et device-restricted.

Environnements multi-cloud

ZTNA offre une politique d’accès cohérente quel que soit le fournisseur cloud. Pas besoin de configurations spécifiques par cloud.

Conformité (RGPD, HIPAA, SOC2)

ZTNA fournit une traçabilité complète de chaque accès, facilitant les audits et la conformité. La vérification continue确保 que les politiques sont respectées en permanence.

Risques et mitigations

Prérequis

• IAM mature — MFA, SSO, RBAC déjà en place
• Visibility réseau — Capacité de monitorer les flux
• Support appareil — Gestion des postes (MDM optionnel)
• Cloud — Infrastructure cloud pour le déploiement ZTNA
• Équipe dédiée — Personnes formées à la sécurité zero trust

Si tu n’as pas ces prérequis, commence par les fondations. ZTNA n’est pas un produit que tu installes et c’est fini. C’est une transformation architecturale.

Références

• NIST SP 800-207: Zero Trust Architecture
• NIST SP 1800-35: Implementing a Zero Trust Architecture
• CISA Zero Trust Maturity Model
• Cloudflare Zero Trust
• Zscaler ZTNA
• Palo Alto Prisma Access
• Fortinet Universal ZTNA

Mot de la fin

ZTNA n’est pas un “VPN killer”. C’est une évolution architecturale pour les environnements modernes.

Le meilleur argument pour ZTNA, c’est la réduction de la surface d’attaque. En limitant l’accès aux applications spécifiques et en vérifiant en continu, tu réduis drastiquement le risque de compromission.

Et si tu as un environnement cloud/hybride avec du remote work, ZTNA n’est plus optionnel. C’est une nécessité.

See ya space-cowboy!