Cloudflare Zero Trust — ZTNA sans VPN pour l'Entreprise

L'abandon du VPN périmétrique au profit du Zero Trust Network Access (ZTNA) est l'une des transformations les plus profondes de la sécurité réseau d'entreprise depuis deux décennies. Le modèle VPN traditionnel reposait sur une hypothèse devenue obsolète : une fois à l'intérieur du périmètre réseau, un utilisateur est implicitement de confiance. Les attaques par ransomware, le mouvement latéral après compromission d'un poste, et la généralisation du travail hybride ont rendu ce modèle dangereux. Cloudflare Zero Trust (anciennement Cloudflare for Teams) implémente le principe Zero Trust — "ne jamais faire confiance, toujours vérifier" — en évaluant chaque demande d'accès individuellement selon l'identité de l'utilisateur, la santé du terminal, le contexte de la connexion et les politiques d'accès granulaires définies par l'administrateur. La plateforme repose sur quatre composants complémentaires : Cloudflare Access (ZTNA), Cloudflare Gateway (DNS filtering et HTTP inspection), le client WARP (agent réseau) et Browser Isolation (accès sans agent). Ce guide complet détaille l'architecture, le déploiement et la configuration opérationnelle de chaque composant, de l'intégration des fournisseurs d'identité jusqu'à la journalisation pour la conformité NIS 2 et DORA, avec des exemples concrets applicables à une infrastructure d'entreprise française.

Zero Trust vs VPN traditionnel — pourquoi abandonner le périmètre

Le VPN SSL/IPSec crée un tunnel chiffré qui connecte le poste de travail à un concentrateur réseau d'entreprise, donnant à l'utilisateur un accès à l'ensemble du réseau interne. C'est précisément ce qui le rend dangereux : en cas de compromission du poste ou des identifiants VPN, l'attaquant hérite du même accès réseau que l'utilisateur légitime.

La réalité des incidents de sécurité le confirme : 80% des ransomwares exploitent un mouvement latéral après un accès initial, souvent obtenu via des identifiants VPN compromis (phishing, credential stuffing, vulnérabilité de l'équipement VPN lui-même). Les CVE critiques sur Pulse Secure, Citrix ADC, Fortinet SSL-VPN et SonicWall ont exposé des milliers d'organisations entre 2020 et 2025.

Le Zero Trust inverse cette logique : aucun utilisateur, aucun terminal, aucune requête n'est implicitement de confiance, qu'ils soient dans le réseau d'entreprise ou en dehors. Chaque accès est conditionné à la vérification de l'identité (IdP + MFA), à la santé du terminal (antivirus à jour, chiffrement disque, certificat de conformité), et aux politiques d'accès granulaires (qui peut accéder à quoi, depuis quel contexte, à quelle heure).

Les avantages concrets du ZTNA sur le VPN : suppression de la surface d'attaque réseau (les applications internes ne sont plus exposées sur Internet), élimination du mouvement latéral (chaque application est cloisonnée), meilleure expérience utilisateur (pas de VPN à lancer manuellement, accès direct aux applications), et traçabilité exhaustive de chaque connexion. Pour une évaluation de votre infrastructure actuelle avant migration, consultez notre service d'audit d'infrastructure.

Architecture Cloudflare Zero Trust — Access, Gateway, WARP, Browser Isolation

La plateforme Cloudflare Zero Trust repose sur quatre composants interdépendants qui couvrent l'ensemble des cas d'usage d'accès sécurisé.

Cloudflare Access est le composant ZTNA. Il sécurise les applications internes en les exposant via le réseau Cloudflare avec une vérification d'identité à chaque accès. Chaque application protégée par Access devient accessible via une URL publique (ex : app.example.com) mais nécessite une authentification validée avant d'autoriser la connexion au serveur d'origine. Le tunnel vers le serveur d'origine est établi via cloudflared, un daemon léger qui maintient une connexion sortante chiffrée vers le réseau Cloudflare — sans port entrant à ouvrir sur votre pare-feu.

Cloudflare Gateway est le composant de sécurité du trafic sortant. Il filtre les requêtes DNS (blocage de domaines malveillants, phishing, logiciels malveillants), inspecte le trafic HTTP/HTTPS (DLP, prévention des fuites de données, blocage de catégories), et protège les utilisateurs où qu'ils soient, y compris hors du réseau d'entreprise.

WARP Client est l'agent réseau léger installé sur les postes de travail. Il route le trafic des utilisateurs via le réseau Cloudflare, permettant à Gateway d'inspecter et de filtrer le trafic sortant, et à Access de disposer d'informations sur la santé du terminal. WARP remplace fonctionnellement un client VPN, mais sans concentrateur central ni backhauling du trafic vers un datacenter d'entreprise.

Browser Isolation permet d'accéder aux applications web dans un navigateur rendu dans le cloud Cloudflare, sans qu'aucun code de l'application ne s'exécute localement. C'est la solution pour les contractants, les utilisateurs BYOD ou les accès à des applications non fiables sans installer d'agent sur le terminal.

Cloudflare Access — sécuriser les applications internes

La configuration d'une application dans Cloudflare Access nécessite trois éléments : le déploiement du daemon cloudflared sur le serveur d'origine, la création d'un tunnel Cloudflare, et la définition des politiques d'accès.

Installez cloudflared sur le serveur hébergeant l'application : curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -o cloudflared && chmod +x cloudflared. Authentifiez-le avec votre compte Cloudflare : cloudflared tunnel login. Créez un tunnel nommé : cloudflared tunnel create mon-app. Configurez le fichier config.yml avec l'URL interne de l'application et le nom du tunnel. Démarrez le tunnel comme service systemd : cloudflared service install.

Les politiques Access définissent qui peut accéder à l'application. Chaque politique est composée de règles Include/Exclude/Require. Exemple de politique stricte : Include — Email appartient à votre domaine (@entreprise.fr). Require — Authentification MFA validée. Require — Terminal avec Device Posture conforme (antivirus actif, OS à jour). Exclude — Membres du groupe "Contractors" (pour les prestataires, une politique séparée avec Browser Isolation).

Les groupes Access permettent de mutualiser les règles. Créez un groupe "Admins-IT" avec les adresses e-mail de votre équipe IT, et un groupe "Utilisateurs-Internes" avec le domaine e-mail de l'entreprise. Assignez ces groupes aux politiques des applications correspondantes.

Access supporte également la protection des applications SSH et RDP via le navigateur (Browser-based SSH/RDP) : les connexions SSH ou RDP passent par le tunnel Cloudflare et sont accessibles depuis un navigateur web sans client SSH/RDP local, avec authentification SSO préalable. Cela élimine l'exposition des ports 22 et 3389 sur Internet. Ces configurations s'articulent avec les pratiques d'administration sécurisée décrites dans notre article sur Entra ID et Azure AD.

Intégration Identity Provider — Okta, Entra ID, Google Workspace

Cloudflare Access s'intègre nativement avec les principaux fournisseurs d'identité (IdP) via SAML 2.0 et OIDC. Cette intégration permet d'utiliser votre IdP d'entreprise existant comme source d'authentification unique pour toutes les applications protégées par Access.

L'intégration avec Microsoft Entra ID (Azure AD) se fait via OIDC ou SAML. Dans Entra ID, créez une nouvelle application "Enterprise Application" de type "Non-gallery", configurez l'URL de réponse (ACS URL fournie par Cloudflare Access), et définissez les attributs SAML mappant les groupes Entra ID vers les politiques Access. Cloudflare Access récupère automatiquement les groupes de l'utilisateur pour les utiliser dans les politiques d'accès. Consultez notre guide complet sur la sécurisation d'Entra ID pour la configuration détaillée de l'IdP.

L'intégration avec Okta utilise OIDC. Dans Okta, créez une application OIDC "Web Application", configurez les redirect URIs Cloudflare, et exportez les scopes (openid, email, groups). Dans Cloudflare Access, ajoutez Okta comme IdP avec le Client ID, Client Secret et le domaine Okta. Les groupes Okta sont disponibles comme conditions dans les politiques Access.

Pour Google Workspace, l'intégration OAuth 2.0/OIDC permet d'utiliser les comptes Google d'entreprise comme authentification. Créez un projet Google Cloud, configurez les credentials OAuth, et renseignez le Client ID/Secret dans Cloudflare Access. Les domaines Google Workspace (G Suite) peuvent être utilisés comme condition d'accès.

Le MFA conditionnel permet d'exiger une double authentification uniquement pour les applications sensibles ou selon le contexte (accès depuis un pays inhabituel, depuis un terminal non reconnu). Cloudflare Access évalue le niveau d'authentification fourni par l'IdP (via le claim AMR - Authentication Methods References) et peut exiger un MFA supplémentaire si le contexte l'exige.

Cloudflare Gateway — DNS filtering, HTTP inspection et DLP

Cloudflare Gateway protège les utilisateurs contre les menaces provenant d'Internet en filtrant le trafic à deux niveaux : DNS et HTTP/HTTPS.

Le DNS filtering redirige les résolveurs DNS des postes de travail vers Cloudflare Gateway (via le client WARP ou une configuration DNS manuelle). Chaque requête DNS est évaluée contre des listes de blocage par catégorie : malware, phishing, botnets, cryptomining, sites pour adultes, réseaux sociaux, etc. Le blocage DNS est ultra-rapide (avant même l'établissement de la connexion TCP) et économique en ressources. Pour les entreprises soumises à NIS 2, le blocage DNS des domaines de commande-et-contrôle (C2) connus est une mesure de détection d'incidents pertinente.

L'HTTP inspection nécessite l'installation d'un certificat racine Cloudflare sur les postes (pour le HTTPS). Elle permet d'inspecter le contenu des requêtes web et d'appliquer des règles DLP (Data Loss Prevention). Exemple : détecter et bloquer l'envoi de numéros de carte bancaire, de numéros de sécurité sociale ou de données IBAN vers des domaines non autorisés.

Les politiques Gateway peuvent autoriser ou bloquer selon l'URL, la catégorie, le type de fichier, l'application identifiée (Shadow IT detection), ou les résultats d'inspection DLP. La détection du Shadow IT est particulièrement précieuse : Gateway identifie automatiquement l'utilisation de services cloud non approuvés (Dropbox personnel, WeTransfer, ChatGPT via navigateur) et permet de les bloquer ou de les ajouter à la liste des services approuvés après évaluation de risque.

Les règles Gateway s'intègrent avec la conformité DORA pour les entités financières, notamment les exigences de maîtrise des risques liés aux tiers numériques et de gestion des flux de données sensibles.

WARP Client — déploiement MDM, GPO et Jamf

Le client WARP est disponible pour Windows, macOS, Linux, iOS et Android. Son déploiement en entreprise s'effectue via les outils MDM existants avec une configuration pré-établie pour éviter toute interaction utilisateur.

Pour le déploiement via Microsoft Intune (MDM Windows) : téléchargez le paquet MSI WARP depuis le tableau de bord Cloudflare Zero Trust. Créez une application Intune de type "Line-of-business app" avec le MSI. Configurez les paramètres WARP via un profil de configuration Intune avec la clé de registre HKLM\\SOFTWARE\\Cloudflare\\CloudflareWARP, incluant votre Team Name (identifiant de votre organisation Cloudflare Zero Trust). Assignez l'application et le profil à vos groupes de machines.

Pour le déploiement via GPO (Group Policy Objects) dans un environnement Active Directory : distribuez le MSI WARP via une GPO d'installation logicielle. Créez un fichier ADMX (template WARP) pour configurer les paramètres via les préférences GPO. Le paramètre clé est organization (votre Team Name Cloudflare) qui force l'inscription automatique du client dans votre tenant Zero Trust.

Pour Jamf (macOS/iOS) : téléchargez le paquet PKG WARP. Créez un package Jamf avec les scripts de pré/post-installation. Déployez le fichier de configuration MDM (com.cloudflare.warp.plist) avec votre Team Name et les paramètres de politique. Assignez aux groupes de machines via une stratégie Jamf.

La Device Posture évalue en continu la conformité du terminal : version OS, état de l'antivirus, chiffrement BitLocker/FileVault, présence d'un certificat client, version du client WARP. Ces attributs de posture sont disponibles comme conditions dans les politiques Access pour conditionner l'accès aux applications selon la santé du terminal. Les organisations NIS 2 peuvent ainsi s'assurer que seuls les postes conformes accèdent aux systèmes critiques. Notre page NIS 2 détaille les exigences applicables.

Browser Isolation — accès sécurisé sans agent

Cloudflare Browser Isolation exécute le navigateur dans le cloud Cloudflare et ne transmet au terminal de l'utilisateur qu'un flux vidéo interactif de la page rendue. Aucun code JavaScript, aucun plugin, aucun contenu actif de la page distante ne s'exécute localement. C'est la protection maximale pour les accès à des applications non fiables ou pour des utilisateurs dont le terminal n'est pas géré par l'entreprise.

Les cas d'usage principaux de Browser Isolation en entreprise : accès des contractants et prestataires sans installation d'agent sur leur poste personnel (BYOD). Navigation sécurisée vers des sites potentiellement malveillants (URLs reçues par e-mail, recherches sur des domaines suspects) sans risque d'exécution de code malveillant localement. Accès à des applications legacy nécessitant Internet Explorer ou des plugins obsolètes sans exposer les postes gérés. Protection des utilisateurs VIP (dirigeants, DSI, RSSI) qui sont des cibles prioritaires pour le phishing et les attaques ciblées.

Browser Isolation s'intègre avec les politiques Gateway : lorsqu'une règle Gateway détecte un accès à une catégorie de site risquée (malware potentiel, hameçonnage non confirmé), elle peut rediriger la navigation en mode Isolated Browser plutôt que de bloquer complètement. L'utilisateur continue de naviguer mais dans un environnement sécurisé.

La configuration d'accès aux applications internes via Browser Isolation (Remote Browser Isolation + Access) permet aux contractants sans client WARP installé d'accéder aux applications internes depuis leur navigateur personnel, avec une isolation complète entre l'application d'entreprise et le terminal du prestataire. C'est une alternative sécurisée au VPN pour les tiers non gérés, particulièrement pertinente pour la conformité DORA qui impose la maîtrise des accès des prestataires tiers.

Journalisation et conformité NIS 2 et DORA

La traçabilité exhaustive des accès est l'un des principaux avantages du Zero Trust sur le VPN. Cloudflare Zero Trust génère des logs détaillés pour chaque connexion, chaque requête DNS et chaque flux HTTP inspecté par Gateway.

Les logs Access enregistrent : horodatage, identité de l'utilisateur (e-mail, IdP), application accédée, résultat de l'évaluation des politiques (Allow/Deny), pays, IP source, appareil utilisé (Device ID), score de posture du terminal. Ces logs sont accessibles depuis l'onglet "Logs → Access" dans le tableau de bord Zero Trust, avec une rétention de 30 jours sur les plans standard.

Les logs Gateway enregistrent chaque requête DNS filtrée et chaque flux HTTP inspecté : URL complète, catégorie détectée, action appliquée (Allow/Block/Isolate), identité de l'utilisateur (si authentifié via WARP). Ces logs permettent de reconstituer précisément l'activité réseau d'un utilisateur en cas d'incident.

Pour la conformité NIS 2, les logs Zero Trust constituent des preuves d'audit conformes aux exigences de traçabilité des accès aux systèmes d'information. La politique d'accès conditionnel documentée (qui a accès à quoi, selon quelles conditions) répond aux exigences de gestion des accès à privilèges. Notre page NIS 2 détaille l'articulation entre Zero Trust et les mesures de sécurité imposées.

Pour la conformité DORA (secteur financier), les logs d'accès Zero Trust permettent de démontrer la maîtrise des accès des tiers (prestataires IT, éditeurs logiciels) aux systèmes d'information critiques, une exigence explicite de DORA Article 28. L'export des logs vers un SIEM via Logpush permet une conservation longue durée conformément aux obligations réglementaires. La page conformité DORA précise les délais de rétention applicables.

Cloudflare Logpush exporte les logs Zero Trust en temps réel vers votre SIEM (Splunk, Elastic, Datadog, Microsoft Sentinel) ou vers un stockage objet (S3, Azure Blob, GCS). Configurez Logpush depuis "Settings → Logpush" dans le tableau de bord Zero Trust. Pour l'intégration avec Microsoft Sentinel, Cloudflare propose un connecteur natif disponible dans la marketplace Azure. Notre article sur la gestion des vulnérabilités aborde l'intégration des logs Zero Trust dans un processus de détection et réponse aux incidents structuré.

FAQ — Cloudflare Zero Trust

Cloudflare Zero Trust peut-il remplacer complètement notre VPN existant ?

Pour la grande majorité des cas d'usage d'entreprise (accès aux applications internes web, SSH, RDP, partages de fichiers via applications web), Cloudflare Zero Trust est un remplacement complet du VPN. Cependant, certains cas d'usage réseaux persistants nécessitent une réflexion supplémentaire : les applications client-lourd qui communiquent directement avec des serveurs internes par IP ou protocole propriétaire (ERP legacy, imprimantes réseau, caméras IP) peuvent nécessiter Cloudflare Tunnel avec le routage réseau (Private Networks via WARP), qui permet à WARP d'agir comme un VPN split-tunnel pour ces cas spécifiques. La migration est donc généralement progressive : commencez par les applications web et SSH/RDP, puis migrez les cas d'usage réseaux persistants avec Private Networks. Un inventaire complet des usages réseau est indispensable avant la migration.

Quelle est la différence entre Cloudflare Access et Cloudflare Gateway ?

Cloudflare Access protège l'accès entrant vers vos applications : il vérifie l'identité de l'utilisateur avant de lui permettre d'accéder à une application interne. C'est la composante ZTNA (Zero Trust Network Access) de la plateforme, qui remplace le VPN pour l'accès aux ressources internes. Cloudflare Gateway, à l'inverse, protège le trafic sortant depuis les postes de travail vers Internet : il filtre les requêtes DNS, inspecte le trafic HTTP pour bloquer les sites malveillants, et prévient les fuites de données (DLP). Access et Gateway sont complémentaires : Access sécurise ce qui entre dans votre infrastructure, Gateway sécurise ce qui sort de vos postes. La plupart des déploiements Zero Trust utilisent les deux simultanément pour une protection complète.

Comment migrer de Cisco AnyConnect ou Pulse Secure vers Cloudflare WARP ?

La migration d'un VPN existant vers Cloudflare WARP doit être planifiée par phases pour éviter toute interruption de service. Phase 1 : inventoriez toutes les ressources auxquelles les utilisateurs accèdent via VPN (applications web internes, partages de fichiers, serveurs, imprimantes). Phase 2 : déployez cloudflared sur les serveurs des applications web internes et créez les tunnels Cloudflare Access — sans toucher au VPN existant. Phase 3 : déployez le client WARP en parallèle du client VPN sur un groupe pilote. Testez l'accès aux applications via Access. Phase 4 : formez les utilisateurs et migrez-les par vagues vers WARP uniquement. Phase 5 : désactivez le VPN une fois que 100% des cas d'usage sont couverts par Access + WARP. Prévoyez 3 à 6 mois pour une migration complète dans une organisation de 500 utilisateurs.

Cloudflare Zero Trust est-il adapté aux petites entreprises et PME ?

Cloudflare propose un plan Zero Trust gratuit incluant jusqu'à 50 utilisateurs, avec les fonctionnalités Access (ZTNA), Gateway (DNS filtering basique), WARP et Browser Isolation limité. Pour une PME de moins de 50 utilisateurs, ce plan gratuit offre un niveau de sécurité Zero Trust nettement supérieur à un VPN traditionnel, sans coût supplémentaire. Pour les PME entre 50 et 500 utilisateurs, le plan Teams (6$/utilisateur/mois) débloque le Gateway HTTP inspection, le DLP, le Bot Management avancé et des logs étendus. Le plan Enterprise ajoute les SLA contractuels, le support 24/7, Logpush temps réel et les fonctionnalités de conformité avancées. Même pour une PME, l'investissement Zero Trust est généralement inférieur au coût total d'un concentrateur VPN (hardware, licences, maintenance, support) avec un niveau de sécurité supérieur.

Comment le mode Browser Isolation protège-t-il contre le phishing ciblé ?

Browser Isolation neutralise les attaques de phishing ciblé (spear phishing) de plusieurs façons. Premièrement, lorsqu'un utilisateur clique sur un lien suspect reçu par e-mail, Gateway peut rediriger automatiquement la navigation vers un Isolated Browser si le domaine est inconnu ou classé comme risqué — l'utilisateur voit le site, mais aucun code malveillant ne s'exécute localement. Deuxièmement, en mode isolé, les keyloggers et les injecteurs de code malveillant ne peuvent pas capturer les frappes clavier locales (les entrées clavier sont transmises chiffrées vers le navigateur distant). Troisièmement, même si le site de phishing tente de voler des cookies de session, les cookies sont isolés dans le navigateur distant et ne sont jamais présents sur le terminal local. Cette protection est particulièrement précieuse pour les dirigeants et les utilisateurs à hauts privilèges qui sont des cibles prioritaires des groupes APT. Combinez Browser Isolation avec une politique de vérification des liens par e-mail (Email Security) pour une protection anti-phishing multicouche.