Cloudflare Zero Trust : accédez aux applications internes sans VPN

Le VPN d'entreprise n'a pas échoué parce qu'il était mal mis en œuvre. Il a échoué parce qu'il était construit sur un postulat qui n'est plus vrai : il suffit d'être membre du réseau de l'entreprise pour faire confiance à quelqu'un. Lorsqu'un employé se connecte depuis son domicile, le réseau d'un hôtel ou d'un café avec le même VPN que l'équipe du bureau, le périmètre réseau en tant que concept de sécurité n'existe plus. Ce qui reste est une illusion de contrôle entretenue par l’inertie opérationnelle.

Cloudflare Zero Trust part d'un principe différent : l'identité, l'appareil et le contexte de la demande déterminent l'accès, et non l'adresse IP d'origine. La mise en œuvre concrète de celui-ci implique trois composants qui ont des rôles distincts et sont souvent confondus même par ceux qui les ont déjà mis en production.

Accès, Tunnel et WARP : ce que chacun fait

Cloudflare Access est une passerelle d'identité pour les applications. Lorsqu'une requête arrive sur le domaine interne publié via Cloudflare, Access l'intercepte avant que la requête n'atteigne l'origine. L'utilisateur s'authentifie auprès du fournisseur d'identité configuré : Okta, Azure AD, Google Workspace ou tout fournisseur SAML 2.0 et OIDC. Ce n'est qu'après l'authentification et l'évaluation de la politique que le trafic passe à l'origine. L'application ne reçoit jamais de demande non authentifiée.

Cloudflare Tunnel, géré par le démon cloudflared, fonctionne côté serveur. Il crée une connexion sortante chiffrée du serveur vers la périphérie Cloudflare, sans ouvrir les ports de pare-feu entrants. Le flux complet : l'utilisateur s'authentifie via Access → Cloudflare Edge valide → le trafic arrive via le tunnel vers le service interne. Le serveur interne n'a pas besoin d'adresse IP publique, n'a pas besoin de règle d'entrée de groupe de sécurité et n'est pas directement exposé à Internet.

WARP est le client de l'appareil. En mode Zero Trust, il achemine le trafic des appareils via la périphérie Cloudflare via le protocole WireGuard. Cela permet de vérifier la posture (chiffrement du disque, version du système d'exploitation, agent de sécurité installé) et permet aux politiques d'accès d'inclure l'état du périphérique comme condition. Pour les applications Web accessibles via le navigateur, WARP n'est souvent pas nécessaire. Pour les protocoles non HTTP comme SSH et RDP acheminés via le tunnel, c'est obligatoire.

Comment fonctionne le flux d'authentification

La séquence concrète pour un développeur accédant à un service interne : l'utilisateur accède à app.empresa.com. Access détecte qu'il n'y a pas de session valide et redirige vers le fournisseur d'identité. L'utilisateur s'authentifie — avec MFA si la politique l'exige. L’IdP revient à Access avec l’identité et les attributs de groupe confirmés. Access évalue la stratégie : cet utilisateur appartient-il au groupe disposant des autorisations pour cette application ? S'il est approuvé, il émet une session JWT et la demande est transmise à la périphérie, empruntant le tunnel jusqu'au service sur le réseau interne.

Pour les protocoles non HTTP – SSH par exemple – le flux passe par WARP. Le client établit le tunnel WireGuard, la politique de posture est vérifiée et le trafic SSH est acheminé via Cloudflare vers la destination via le tunnel.

Identité et fournisseurs pris en charge

Access prend en charge plusieurs fournisseurs d’identité simultanément dans la même organisation. Une application peut permettre l'authentification via Google Workspace pour les collaborateurs et via GitHub pour les collaborateurs externes. Un autre pourrait nécessiter exclusivement Okta avec MFA obligatoire. Les groupes d'IdP synchronisés (équipes d'ingénierie, équipes spécifiques, départements) alimentent directement les politiques d'accès, sans synchronisation manuelle des listes.

En plus des humains, Access gère l'accès de machine à machine via des jetons de service. Un pipeline CI/CD qui doit atteindre un point de terminaison interne authentifié se voit attribuer un ID client et un secret, qui remplacent le flux SSO humain. Chaque accès, humain ou automatisé, génère un événement d'audit avec identité, horodatage, IP, appareil et décision prise — exportable via Logpush vers SIEM, Splunk ou Datadog.

Ce que Zero Trust ne fait pas

Cloudflare Zero Trust contrôle qui accède à quoi, mais ce n'est pas une solution pour chiffrer les données en transit au sein de l'application : cela reste la responsabilité de l'application elle-même via HTTPS. L'accès ne remplace pas non plus un pare-feu pour le trafic est-ouest entre les services au sein du centre de données ou du VPC. Pour la communication interne entre microservices, mTLS ou service mesh reste le mécanisme approprié.

Un point qui manque dans les premières implémentations : le Tunnel protège le chemin entre le Edge Cloudflare et le serveur d'origine, mais le serveur n'a toujours besoin que de faire confiance aux connexions arrivant via cloudflared. Si le port 443 est ouvert à Internet en dehors du tunnel, l'accès peut être contourné. La bonne pratique consiste à bloquer tout le trafic entrant vers le serveur, à l'exception de celui généré par le démon Tunnel local.

Ce que l'adoption change sur le plan opérationnel

Le changement le plus important n’est pas technique : c’est le modèle mental de celui qui gère l’accès. Avec VPN, l'équipe réseau configure les routes et les tunnels fractionnés ; Avec Zero Trust, l'équipe chargée de l'identité configure les politiques par application. La gestion des accès quitte le niveau réseau et entre dans le niveau identité. Pour les organisations disposant d’équipes réseau et sécurité distinctes, cela implique de négocier les responsabilités.

Le niveau gratuit – jusqu'à 50 utilisateurs avec Access, Tunnel, WARP et Basic Gateway – est suffisant pour la validation de la production. Le plan Team coûte 7 $ par utilisateur et par mois et ajoute des journaux d'audit et une passerelle avec filtrage HTTP. Enterprise ajoute l'isolation du navigateur, la DLP et la sécurité de la messagerie, avec des tarifs négociés. Pour les équipes de plus de 50 utilisateurs qui ont déjà consolidé Okta ou Azure AD, l’effort de déploiement dépasse rarement quatre semaines de travail réel.

Que faut-il évaluer avant de migrer

La décision de passer au Zero Trust n’est pas une question de technologie, mais plutôt de savoir où se situe aujourd’hui le plus grand risque de sécurité. Si votre VPN actuel accorde un accès étendu au réseau après l'authentification, un identifiant compromis expose l'ensemble du réseau interne. Zero Trust limite le rayon d'action : un accès compromis atteint uniquement l'ensemble des applications explicitement autorisées pour cette identité, avec la position de l'appareil comme contrôle supplémentaire.

Commencez par l’application présentant le risque d’exposition le plus élevé et le coût le plus élevé en cas de fuite. Le migrer en premier, avec une politique restreinte aux groupes et une posture obligatoire des appareils, valide le modèle complet en production avec un impact contrôlable. Le modèle testé ici est répliqué pour le reste du portefeuille.