Il existe une confusion récurrente parmi les équipes qui adoptent Cloudflare Zero Trust : traiter Access et Tunnel comme des parties interchangeables d'un même système, alors qu'en pratique, ce sont des produits avec des responsabilités complètement différentes. Un ingénieur qui configure le tunnel et suppose que l'authentification est résolue publie un service privé sans aucune porte d'identité. Comprendre ce que fait chaque élément – et quand cela vaut la peine d’utiliser l’un sans l’autre – est ce qui différencie une implémentation bien architecturée d’une faille attendant d’être exploitée.
Que fait Cloudflare Access
L'accès est un proxy d'identité. Il se trouve devant un nom d'hôte — app.empresa.com, par exemple — et intercepte chaque requête avant qu'elle n'atteigne l'origine. Lorsque l'utilisateur ne dispose pas d'une session valide, Access redirige vers le fournisseur d'identité configuré. Après une authentification réussie, Access évalue la stratégie associée à cette application : l'utilisateur appartient-il au groupe autorisé ? L’authentification a-t-elle utilisé MFA ? L'appareil est-il conforme ? Si toutes les conditions sont remplies, Access émet une session JWT et la demande est envoyée à l'origine.
La source peut être n'importe quoi : un serveur avec une adresse IP publique, un service interne, un tunnel. L'accès ne se soucie pas de savoir où se trouve la source ; il se soucie de quiconque essaie d'y arriver. Cette distinction est importante car elle signifie qu'Access fonctionne devant des applications qui disposent déjà d'une IP publique, sans avoir besoin d'un Tunnel. Si vous disposez d'une application avec une adresse IP publique qui nécessite un contrôle d'accès basé sur l'identité d'entreprise, Access résout ce problème sans déplacer l'application ni installer cloudflared.
Ce que fait Cloudflare Tunnel
Tunnel résout un problème différent : comment rendre un serveur privé accessible via Internet sans ouvrir de passerelles dans le pare-feu. Le démon cloudflared, installé sur le serveur ou dans un conteneur sur le même réseau, établit une connexion sortante chiffrée vers le Edge Cloudflare. À partir de là, Cloudflare agit comme intermédiaire : le trafic entrant atteint la périphérie et emprunte le tunnel déjà établi jusqu'au service interne.
Le résultat est que le serveur interne n'a pas d'IP publique, n'a pas de port 80 ou 443 ouvert sur Internet et n'a pas besoin de règle d'entrée dans le groupe de sécurité ou le pare-feu. Le seul trafic qui entre est celui qui provient du processus cloudflared lui-même exécuté localement. Un serveur complètement isolé de tout accès externe direct est désormais accessible aux utilisateurs autorisés via Cloudflare Edge.
cloudflared peut être configuré en tant que service systemd, conteneur Docker ou déploiement Kubernetes. La configuration moderne utilise le tableau de bord Cloudflare pour gérer le tunnel – pas de fichier YAML local, avec une configuration propagée via l'API. Un seul processus cloudflared peut exposer plusieurs services sur différents noms d'hôtes : app1.empresa.com va au port 3000 localement, app2.empresa.com va au port 4000, db-admin.empresa.com va à pgAdmin sur le port 5050.
Quand utiliser Tunnel sans accès
Le tunneling sans accès est un scénario valide et courant : vous souhaitez acheminer le trafic d'une application publique via Cloudflare Edge pour la protection DDoS et CDN, sans authentification supplémentaire. Le service est accessible au public, mais le trafic atteint le serveur uniquement via Cloudflare, sans exposition directe de l'adresse IP d'origine. Cloudflare protège contre les attaques volumétriques et le serveur est masqué.
Autre usage : développement local partagé. Un développeur souhaite montrer un prototype exécuté localement à une personne extérieure au réseau. cloudflared tunnel --url localhost:3000 crée une URL temporaire accessible au public sans configuration DNS ni pare-feu. Pas d'accès, pas d'authentification — mais utile pour le cas spécifique.
Le risque est de supposer que Tunnel implique une protection. Cela ne veut pas dire. Le tunnel est la connectivité. Sans accès au premier plan, toute requête qui atteint le nom d'hôte configuré dans Cloudflare atteint votre service interne.
Quand utiliser Access sans Tunnel
L'accès sans Tunnel a du sens lorsque la source dispose déjà d'une IP publique : un serveur sur EC2 avec une IP élastique, une application sur un PaaS, un point de terminaison d'API avec une adresse publique. Access agit comme un proxy d'identité devant cette adresse publique, sans avoir besoin de cloudflared.
Le détail opérationnel critique dans ce scénario : l'origine doit accepter le trafic uniquement en provenance de la périphérie Cloudflare. Si le serveur continue d'accepter les demandes de n'importe quelle adresse IP, l'accès peut être contourné en accédant simplement directement à l'adresse IP. La bonne pratique consiste à configurer le serveur pour qu'il accepte uniquement le trafic provenant des plages IP de Cloudflare, ou à utiliser un en-tête authentifié qu'Access injecte et que l'application vérifie.
La combinaison qui offre véritablement Zero Trust
La combinaison des deux est ce qui implémente le modèle Zero Trust complet : le Tunnel rend le serveur privé accessible via Cloudflare ; L'accès nécessite une authentification et une évaluation des politiques avant d'autoriser toute demande à emprunter le tunnel. Le serveur interne n'est jamais directement exposé à Internet et ne reçoit jamais de demandes non authentifiées.
Le flux : l'utilisateur accède au nom d'hôte → L'accès vérifie la session, redirige vers l'IdP si nécessaire → après l'authentification et la vérification de la politique, Access transmet la demande au bord → le bord descend dans le tunnel → cloudflared la transmet au processus local. Le serveur interne ne voit que le trafic déjà autorisé par Access.
Pour l'accès de machine à machine — pipelines CI/CD, agents de surveillance, intégrations — L'accès émet des jetons de service : un identifiant client et un secret qui remplacent le flux SSO humain. Le service automatisé inclut ces jetons dans l’en-tête de la demande et Access les reconnaît comme une identité de service approuvé, en appliquant la stratégie associée. Chaque accès via un jeton de service génère également un événement d'audit.
La vision de ceux qui architectent le système
Un point qui a été oublié lors de la phase de conception : Tunnel n'a aucun coût de sortie chez Cloudflare. Le trafic passant par cloudflared n'est pas facturé pour la bande passante sur le forfait Team. Cela a de réelles implications en termes de coûts par rapport aux alternatives qui facturent par Go transféré – et influence la décision d'utiliser Cloudflare Tunnel par rapport à des solutions de tunneling similaires.
La décision architecturale centrale lors de l’adoption des deux composants est la suivante : où sont les politiques d’accès ? Access vous permet de créer des politiques granulaires par application : un groupe a accès au panneau d'administration, un autre a un accès en lecture seule à la surveillance, les collaborateurs externes accèdent uniquement au portail de documentation. Cette granularité n’existe pas dans les VPN traditionnels. Le coût du maintien de cette granularité est la gestion continue des politiques à mesure que les équipes changent et que les applications évoluent. L'automatisation de cela via Terraform ou l'API de Cloudflare est l'étape qui transforme la gestion des accès d'une tâche manuelle en un processus contrôlé.
A lire aussi
-Cloudflare Zero Trust : accédez aux applications internes sans VPN