Cloudflare Zero Trust — ZTNA sans VPN pour l'Entreprise

Cloudflare Zero Trust Network Access (ZTNA) élimine le modèle VPN "castle-and-moat" et le remplace par un contrôle d'accès granulaire par application, par utilisateur et par appareil. En 2026, selon le rapport State of Zero Trust de Cloudflare, 72 % des entreprises ayant migré vers ZTNA rapportent une réduction mesurable de leur surface d'attaque — et 94 % des incidents impliquant un VPN compromis auraient été limités si le ZTNA avait été en place, selon le rapport Zero Trust de Cloudflare. Ce guide détaille l'architecture Cloudflare Zero Trust, la configuration des tunnels d'accès, l'intégration IdP (Okta, Azure AD, Google Workspace), les politiques d'accès conditionnel et la supervision des sessions — de zéro à une infrastructure ZTNA opérationnelle en production.

Qu'est-ce que Cloudflare Zero Trust et pourquoi remplacer le VPN en 2026 ?

Cloudflare Zero Trust est une plateforme SASE (Secure Access Service Edge) qui combine accès réseau Zero Trust (ZTNA), passerelle web sécurisée (SWG), courtier de sécurité cloud (CASB) et prévention des pertes de données (DLP) en un seul plan de contrôle. Le composant central pour le remplacement VPN est Cloudflare Access — le module ZTNA qui contrôle l'accès aux applications internes sans tunnel VPN traditionnel.

Le VPN traditionnel a trois problèmes structurels en 2026 : il expose un segment réseau entier dès qu'un utilisateur s'authentifie, il ne vérifie pas l'état de sécurité du device en continu, et il crée un point d'entrée unique dont la compromission donne accès à l'ensemble du réseau interne. Les ransomwares comme REvil et BlackCat ont massivement exploité des VPN SSL pour leur accès initial en 2024-2025 — pas parce que le VPN est mal configuré, mais parce que son architecture expose naturellement plus que nécessaire.

Architecture de Cloudflare Zero Trust : les composants clés

L'architecture Zero Trust Cloudflare repose sur trois composants qui fonctionnent ensemble :

Cloudflare Tunnel (cloudflared) : un daemon léger installé sur votre serveur ou dans votre cluster Kubernetes. Il établit des connexions sortantes persistantes vers le réseau Anycast Cloudflare via le protocole QUIC. Aucun port d'entrée n'est ouvert — le tunnel est toujours initié depuis l'intérieur. Cloudflare expose ensuite l'application via un sous-domaine de votre zone (ex. app-interne.votredomaine.fr).

Cloudflare Access : le proxy d'authentification qui se place devant chaque application exposée. Quand un utilisateur tente d'accéder à app-interne.votredomaine.fr, Access intercepte la requête, vérifie l'identité via l'IdP configuré, contrôle les politiques (rôle, groupe, device posture, géolocalisation) et retourne soit un JWT valide autorisant l'accès, soit une page de refus. L'application d'origine ne voit que des requêtes authentifiées avec les headers d'identité Cloudflare.

WARP Client : le client réseau à installer sur les postes utilisateurs pour accéder aux applications TCP/UDP non-HTTP (SSH, RDP, bases de données). WARP route le trafic vers le réseau Cloudflare et permet d'appliquer les politiques Zero Trust même sur des protocoles non-web. Pour les applications web, aucun client n'est nécessaire.

Installation et configuration de Cloudflare Tunnel

L'installation de cloudflared est la première étape concrète. Sur un serveur Linux (Debian/Ubuntu) :

Téléchargez le binaire depuis le dépôt officiel Cloudflare, installez-le en tant que service systemd, puis authentifiez-le avec votre compte Cloudflare via la commande cloudflared tunnel login. Cette commande ouvre un flux OAuth qui associe le daemon à votre compte. Créez ensuite un tunnel nommé : cloudflared tunnel create mon-tunnel-interne. Cloudflare génère un UUID et un fichier credentials JSON stocké dans ~/.cloudflared/.

Configurez le fichier config.yml pour définir les ingress rules — les règles qui mappent chaque sous-domaine à un service interne :

Exemple de configuration multi-services :

tunnel: <UUID-du-tunnel>
credentials-file: /root/.cloudflared/<UUID>.json

ingress:
  - hostname: gitlab.votredomaine.fr
    service: http://localhost:8080
  - hostname: grafana.votredomaine.fr
    service: http://localhost:3000
  - hostname: ssh-bastion.votredomaine.fr
    service: ssh://localhost:22
  - service: http_status:404

La dernière règle de type http_status:404 est obligatoire — elle traite les requêtes qui ne correspondent à aucun hostname. Démarrez le tunnel avec cloudflared tunnel run mon-tunnel-interne et ajoutez-le à systemd pour le redémarrage automatique.

Retour terrain : Pour un client avec 15 applications internes (GitLab, Grafana, Portainer, plusieurs APIs REST), la migration de VPN SSL vers Cloudflare Tunnel s'est faite en deux semaines. Le point de friction principal n'était pas technique mais organisationnel : convaincre les équipes que "pas de VPN" ne signifiait pas "pas de sécurité". La démo en temps réel des logs d'accès Cloudflare Access — qui montrent précisément qui accède à quoi, depuis quel device, à quelle heure — a été l'argument décisif.

Intégration avec un fournisseur d'identité (IdP)

Cloudflare Access supporte nativement les IdP les plus courants : Okta, Microsoft Azure AD / Entra ID, Google Workspace, GitHub, Ping Identity, OneLogin, et SAML 2.0 générique. L'intégration se configure dans le dashboard Zero Trust → Settings → Authentication.

Pour Azure AD (Microsoft Entra ID), la procédure consiste à créer une application Enterprise dans Azure AD, configurer l'URL de callback Cloudflare (https://[team-name].cloudflareaccess.com/cdn-cgi/access/callback), et renseigner le Client ID, Client Secret et Tenant ID dans Cloudflare. Les groupes Azure AD sont automatiquement synchronisés et disponibles comme conditions dans les politiques d'accès. Pour les organisations qui utilisent déjà des politiques d'accès conditionnel Azure AD, voir notre guide sur Zero Trust M365 pour les stratégies complémentaires.

Pour Okta, la procédure est similaire : créez une application OAuth 2.0 dans Okta avec les scopes openid, email, groups. L'assignation des groupes Okta aux policies Cloudflare Access permet de maintenir la gestion des accès centralisée dans Okta — Cloudflare ne fait que vérifier les assertions.

Comment créer des politiques d'accès conditionnel efficaces ?

Les politiques Cloudflare Access définissent qui peut accéder à quoi sous quelles conditions. Chaque politique est associée à une application (définie par un hostname) et peut inclure plusieurs conditions combinées en logique AND/OR :

• Identité : email, groupe IdP, domain (@votreentreprise.fr), certificat client mTLS
• Device Posture : OS version minimale, antivirus actif, chiffrement disque, certificat device Cloudflare
• Réseau : IP source, pays d'origine (whitelisting géographique)
• Authentification : MFA requis, méthode d'auth (TOTP, WebAuthn, FIDO2)

Exemple de politique réaliste pour une application sensible (interface admin d'une base de données) : groupe Azure AD = "DBA" AND device_posture.disk_encrypted = true AND device_posture.os_version >= "Windows 11 23H2" AND mfa = true. Cette combinaison garantit que seuls les DBA avec un poste à jour, chiffré et MFA actif peuvent accéder à l'admin DB — sans VPN, depuis n'importe quel réseau.

Pour approfondir les architectures Zero Trust multi-couches, consultez notre guide complet sur l'implémentation Zero Trust qui couvre les aspects réseau au-delà de l'accès applicatif.

Device Posture : vérifier l'état de sécurité des postes

Le Device Posture est la dimension la plus puissante et la plus souvent sous-utilisée de Cloudflare Zero Trust. Il permet de conditionner l'accès à l'état réel du device : version OS, présence d'un antivirus, état du chiffrement de disque, absence de rootkits détectés, ou présence d'un certificat device émis par votre CA d'entreprise.

La vérification Device Posture nécessite le client WARP sur le poste utilisateur. WARP collecte les informations de posture en local et les soumet à Cloudflare Access au moment de l'évaluation de la politique. Les vérifications se font à chaque accès (pas seulement à l'authentification initiale) — si l'antivirus est désactivé après connexion, la session est révoquée automatiquement selon la configuration de la politique.

Les intégrations MDM (Intune, Jamf) permettent de synchroniser les attributs de posture depuis votre solution de gestion de parc vers Cloudflare. Pour une organisation Microsoft 365, combiner Intune compliance policies avec les Device Posture checks Cloudflare donne une couverture Zero Trust du poste à l'application sans redondance de configuration.

SSH, RDP et applications TCP sans navigateur

Pour les accès SSH, RDP, ou aux bases de données, Cloudflare Zero Trust propose deux modes :

Browser-rendered SSH/RDP : Cloudflare rend une session SSH ou RDP directement dans le navigateur, sans client additionnel sur le poste utilisateur. L'accès est protégé par les politiques Access. Les sessions sont loggables (screen recording en Enterprise, logs de commandes via SSH Command Logging). C'est idéal pour les accès occasionnels ou les prestataires externes — on leur donne un accès SSH temporaire via navigateur, sans installer de client ni exposer de clé SSH.

WARP + Private Networks : le client WARP route le trafic TCP/UDP vers des plages IP internes définies dans les Private Networks Cloudflare. C'est l'équivalent d'un VPN split-tunnel mais avec évaluation des politiques Zero Trust à chaque flux. Utilisez ce mode pour les accès courants aux bases de données, aux serveurs d'applications et aux services réseau (NFS, SMB) qui ne supportent pas le proxy HTTP.

Supervision et audit des accès Zero Trust

Cloudflare Zero Trust génère des logs détaillés pour chaque événement d'accès : tentative d'authentification, succès, refus (avec la règle de refus), déconnexion, et Device Posture check. Ces logs sont accessibles dans le dashboard (rétention 24h sur le plan gratuit, 30 jours sur les plans payants) et exportables via Logpush vers un SIEM.

Les métriques clés à surveiller : taux de refus par application (une hausse soudaine indique soit une tentative d'accès non autorisée, soit un problème de politique), echecs de Device Posture (indicateur de postes non conformes), et connexions depuis des pays inhabituels. Les alertes Cloudflare Notifications permettent de déclencher un webhook en temps réel sur ces événements.

L'intégration avec un SIEM comme Wazuh (voir notre guide Wazuh SIEM/XDR) permet de corréler les logs d'accès Zero Trust avec les événements endpoint et réseau pour une détection comportementale complète. Une connexion légitime depuis un pays inhabituel est un signal faible — corrélée avec d'autres événements endpoint anormaux, c'est un indicateur de compromission.

Déployer progressivement : du VPN au ZTNA sans rupture

La migration VPN → ZTNA doit être progressive pour éviter les coupures de service. L'approche recommandée en trois phases :

Phase 1 — Coexistence (semaines 1-4) : déployez Cloudflare Tunnel et Access pour les nouvelles applications seulement. Le VPN reste actif. Les utilisateurs ont le choix d'accéder aux nouvelles apps via ZTNA — cela crée une adoption organique et identifie les frictions.

Phase 2 — Migration par application (semaines 5-12) : migrez les applications existantes une par une depuis le VPN vers Access. Commencez par les applications les moins critiques. Pour chaque app migrée, coupez l'accès VPN correspondant — l'exposition réseau diminue progressivement.

Phase 3 — Extinction du VPN (semaine 13+) : une fois toutes les applications migrées, désactivez le serveur VPN. Les dernières résistances viennent généralement des accès TCP non-web — adressez-les avec WARP + Private Networks avant de couper le VPN.

Pour les organisations qui pratiquent déjà la micro-segmentation réseau, notre guide sur IA et Zero Trust explore la segmentation dynamique assistée par ML comme étape suivante naturelle.

Questions fréquentes sur Cloudflare Zero Trust ZTNA

Cloudflare Zero Trust est-il gratuit pour les petites équipes ?

Oui. Le plan Cloudflare Zero Trust gratuit couvre jusqu'à 50 utilisateurs sans limite de temps. Il inclut Cloudflare Access (ZTNA), les tunnels, la Gateway DNS (filtrage DNS), et les Device Posture checks basiques. Les fonctionnalités avancées — SSH Command Logging, DLP, CASB, Gateway HTTP avec inspection TLS — nécessitent les plans payants. Pour une PME de moins de 50 personnes, le plan gratuit est fonctionnellement complet pour remplacer un VPN SSL.

Comment fonctionne l'authentification sans VPN pour les utilisateurs nomades ?

L'utilisateur ouvre son navigateur, accède à app-interne.votredomaine.fr, est redirigé vers la page de login Cloudflare Access, s'authentifie via l'IdP (Azure AD, Okta, Google) avec MFA, et reçoit un cookie JWT valide pour la durée de session configurée. Tout se passe dans le navigateur, depuis n'importe quel réseau. Aucune configuration réseau côté client n'est nécessaire pour les applications web — c'est l'avantage fondamental par rapport au VPN.

Quelles applications ne peuvent pas être migrées vers ZTNA ?

Les applications qui s'appuient sur des protocoles réseau propriétaires non-TCP/UDP (rare mais existant dans les environnements industriels OT), celles qui nécessitent une diffusion multicast, et les services qui ne supportent pas la terminaison SSL intermédiaire (certaines applications legacy avec certificate pinning strict). Pour ces cas, une architecture hybride VPN + ZTNA est justifiée — le ZTNA couvre la majorité des accès, le VPN reste pour les exceptions.

Le ZTNA Cloudflare est-il compatible avec les environnements on-premise sans Internet public ?

Cloudflare Tunnel nécessite que le serveur d'origine puisse établir une connexion sortante vers le réseau Cloudflare (HTTPS/QUIC sortant sur le port 443 ou 7844). Si l'environnement est entièrement air-gapped sans accès Internet, Cloudflare Zero Trust ne s'applique pas. Pour les environnements semi-isolés avec accès Internet restreint, configurez les règles de firewall pour autoriser les connexions sortantes vers les IP Cloudflare publiées.

Comment Cloudflare Zero Trust se compare-t-il à une architecture Zero Trust maison ?

Une architecture Zero Trust maison (nginx + Vault + Consul + Keycloak + openvpn-as) coûte en ingénierie entre 2 et 6 semaines de mise en place, puis une charge de maintenance continue. Cloudflare Zero Trust déploie en 1 à 3 jours et la maintenance est gérée par Cloudflare — mises à jour de sécurité, haute disponibilité, certificats. Le compromis est la dépendance envers un fournisseur tiers et la confiance accordée à Cloudflare pour inspecter les flux d'authentification. Pour les organisations avec des contraintes de souveraineté fortes, consultez notre service RSSI externalisé pour une analyse des compromis souveraineté/opérabilité.

Cloudflare Gateway : filtrage DNS et HTTP sortant

Cloudflare Gateway est le composant de filtrage du trafic sortant de la plateforme Zero Trust. Là où Cloudflare Access contrôle l'accès entrant aux applications internes, Gateway filtre le trafic sortant des utilisateurs vers Internet. Combinés, ils couvrent les deux directions de flux et éliminent la nécessité d'un proxy web d'entreprise (Squid, Zscaler) onéreux à maintenir.

Gateway opère sur deux niveaux : DNS et HTTP. Le filtrage DNS intercepte toutes les requêtes DNS des postes utilisateurs (via WARP) et bloque les domaines malveillants, les domaines de phishing connus, les catégories indésirables (jeux d'argent, contenu adulte, etc.), et les domaines de C2 connus. Ce filtrage se produit avant même que la connexion TCP soit établie — c'est la forme de protection la plus légère en termes de latence et la plus efficace pour les malwares qui utilisent des domaines dynamiques.

Le filtrage HTTP inspecte le trafic HTTPS déchiffré (avec inspection TLS via le certificat root Cloudflare installé sur les postes) pour détecter les uploads de données sensibles, les téléchargements de malwares, et les accès à des applications non autorisées (Shadow IT). Les politiques HTTP peuvent bloquer l'upload vers des services cloud non approuvés, imposer l'authentification SSO pour les applications SaaS, ou appliquer des règles DLP sur les données structurées (numéros de carte, IBAN, données de santé).

Intégration SIEM et corrélation des événements Zero Trust

Une architecture Zero Trust génère des volumes importants de logs d'accès — un utilisateur qui accède à 20 applications génère 20 événements d'authentification par jour, auxquels s'ajoutent les logs Gateway DNS et HTTP. Sans corrélation, ces logs sont des silos d'information peu exploitables. L'intégration SIEM est donc une composante critique du dispositif, pas une option.

Cloudflare Logpush supporte l'envoi vers S3, Azure Blob Storage, Google Cloud Storage, Datadog, Splunk, Sumo Logic et d'autres destinations. Les datasets disponibles incluent : Access Requests, Gateway DNS, Gateway HTTP, Gateway Network, WARP Devices et Audit Logs de configuration. La fréquence d'envoi est configurable entre 30 secondes et 5 minutes selon les contraintes de latence de votre SIEM.

Dans un SIEM comme Wazuh ou Splunk, les corrélations les plus utiles sont : connexion Access réussie depuis un pays inhabituel + événement endpoint anormal (nouvelle clé de registre, exécution de processus suspect) ; échec répété de Device Posture pour un utilisateur donné (indicateur de poste compromis ou non maintenu) ; et accès Gateway DNS à des domaines nouvellement enregistrés (indicateur de C2 potentiel). Ces corrélations requièrent que les timestamps SIEM et Cloudflare soient synchronisés — vérifiez systématiquement le fuseau horaire UTC dans les deux systèmes.

Coûts et ROI du passage à Cloudflare Zero Trust

La question du retour sur investissement est légitime : un VPN SSL grand public (OpenVPN AS, Cisco AnyConnect) coûte entre 5 et 25 € par utilisateur et par mois selon le nombre de licences. Cloudflare Zero Trust est gratuit jusqu'à 50 utilisateurs, puis environ 7 à 10 € par utilisateur et par mois selon les fonctionnalités. Le coût direct est donc comparable.

Le ROI réel vient de la réduction des coûts indirects : infrastructure serveur VPN éliminée (pas de VM à maintenir, pas de certificats à renouveler, pas de mise à jour de sécurité critique urgente comme OpenSSL/Log4Shell), réduction du help desk VPN (les tickets "impossible de se connecter au VPN" représentent 8 à 15 % des tickets help desk dans les organisations avec VPN traditionnel selon Gartner), et réduction de la surface d'attaque qui diminue la probabilité d'un incident de sécurité coûteux.

Le chiffrage le plus parlant pour un RSSI : une breach impliquant un VPN SSL coûte en moyenne 4,2 millions de dollars selon le IBM Cost of a Data Breach Report 2025. Réduire la probabilité de ce vecteur d'attaque par une architecture ZTNA est un argument financier quantifiable qui dépasse largement le coût des licences Cloudflare. Le modèle de maturité Zero Trust CISA fournit un cadre d'évaluation reconnu pour mesurer la progression de votre organisation.

Conclusion

Ce sujet s'inscrit dans un contexte de menaces en constante évolution. La meilleure protection combine veille active, audits réguliers et sécurité by design. Pour approfondir ou évaluer votre exposition, consultez nos experts.