Cloudflare Zero Trust : Guide Complet Tunnel, Access et Gateway

Face a l'explosion du travail hybride, a la multiplication des surfaces d'attaque et a l'obsolescence programmee des architectures perimetriques traditionnelles, le modele Zero Trust s'est impose comme le nouveau paradigme de la cybersecurite d'entreprise. Parmi les acteurs qui ont democratise cette approche, Cloudflare occupe une place singuliere : en s'appuyant sur son reseau mondial de plus de 300 points de presence, la plateforme Cloudflare One propose une suite integree — Cloudflare Tunnel, Access, Gateway, WARP, Browser Isolation, DLP et CASB — capable de remplacer integralement un VPN d'entreprise tout en offrant une granularite de controle sans precedent. Dans cet article de reference, nous decortiquons chaque brique de l'ecosysteme Cloudflare Zero Trust, depuis les fondements theoriques du modele ZTNA jusqu'au deploiement concret avec fichiers de configuration, politiques d'acces et scripts Terraform. Que vous soyez RSSI, architecte cloud ou ingenieur DevOps, vous trouverez ici un guide exhaustif pour concevoir, deployer et exploiter une architecture Zero Trust Network Access basee sur Cloudflare, avec des retours d'experience, des cas d'usage reels et une analyse critique des limites de la solution.

Pourquoi le VPN est mort : l'avenement du Zero Trust

Pendant plus de vingt ans, le VPN (Virtual Private Network) a constitue la pierre angulaire de l'acces distant aux ressources d'entreprise. Le principe etait simple : etablir un tunnel chiffre entre le poste de l'utilisateur et le reseau interne, puis accorder un acces large — souvent trop large — a l'ensemble des ressources situees derriere le pare-feu. Ce modele, herite de l'ere ou les serveurs physiques residaient dans un datacenter unique et ou les employes travaillaient exclusivement depuis le bureau, reposait sur une hypothese fondamentale : tout ce qui se trouve a l'interieur du perimetre est digne de confiance.

Cette hypothese s'est averee catastrophique. Les violations de donnees les plus devastatrices de la derniere decennie — SolarWinds, Colonial Pipeline, Uber 2022 — ont toutes exploite le meme schema : un attaquant obtient un acces initial (phishing, credential stuffing, compromission d'un fournisseur), puis se deplace lateralement a l'interieur du reseau en profitant de la confiance implicite accordee par l'architecture perimetrique. Une fois le VPN franchi, l'attaquant dispose des memes privileges qu'un employe legitime, voire davantage s'il escalade ses droits.

Le modele Zero Trust, formalise par John Kindervag chez Forrester en 2010 puis codifie par le NIST dans sa publication speciale SP 800-207, repose sur un axiome radicalement different : ne jamais faire confiance, toujours verifier. Chaque requete d'acces — qu'elle provienne de l'interieur ou de l'exterieur du reseau — doit etre authentifiee, autorisee et chiffree avant d'etre accordee. Il n'existe plus de zone de confiance implicite.

Les piliers du Zero Trust selon le NIST et la CISA sont les suivants :

• Verification continue de l'identite : chaque utilisateur et chaque appareil doivent prouver leur identite a chaque requete, pas seulement lors de la connexion initiale.
• Principe du moindre privilege : l'acces est accorde uniquement aux ressources strictement necessaires, pour la duree strictement necessaire.
• Microsegmentation : le reseau est decoupe en segments granulaires, empechant le mouvement lateral meme en cas de compromission d'un segment.
• Posture de l'appareil : l'etat de securite du terminal (OS a jour, antivirus actif, chiffrement du disque) est evalue en temps reel avant d'autoriser l'acces.
• Chiffrement de bout en bout : toutes les communications sont chiffrees, y compris celles qui transitent a l'interieur du reseau d'entreprise.
• Journalisation et analyse continue : chaque acces est enregistre et analyse pour detecter les comportements anormaux.

Le VPN, par conception, viole pratiquement tous ces principes. Il accorde un acces reseau large apres une authentification unique, ne verifie generalement pas la posture de l'appareil en continu, et ne segmente pas les acces par application. Pire, il concentre le trafic vers un point unique (le concentrateur VPN), creant un goulot d'etranglement en termes de performance et un point de defaillance unique en termes de disponibilite. Avec l'adoption massive du cloud (SaaS, IaaS, PaaS), une part croissante du trafic n'a meme plus besoin de transiter par le datacenter d'entreprise — le VPN force un detour inutile qui degrade l'experience utilisateur.

C'est dans ce contexte que des solutions de Zero Trust Network Access (ZTNA) ont emerge. Contrairement au VPN qui connecte l'utilisateur a un reseau, le ZTNA connecte l'utilisateur a une application specifique, apres verification de son identite, de la posture de son appareil et du contexte de la requete. Cloudflare, avec sa plateforme Cloudflare One, a pris une longueur d'avance en proposant une solution ZTNA complete, integree a son reseau mondial Anycast, offrant a la fois securite, performance et simplicite de deploiement.

Cloudflare One : architecture globale

Cloudflare One est la plateforme SASE (Secure Access Service Edge) de Cloudflare qui regroupe l'ensemble des services de securite et de connectivite reseau sous une interface unifiee. Contrairement aux solutions SASE traditionnelles qui resultent souvent de l'assemblage heteroclite de produits acquis par rachat, Cloudflare One a ete concu nativement sur le reseau mondial Anycast de Cloudflare — un reseau qui compte plus de 310 datacenters dans plus de 120 pays, a moins de 50 millisecondes de 95% de la population connectee a Internet.

Cette architecture distribuee confere a Cloudflare One un avantage structurel : chaque point de presence execute l'integralite de la pile de services (DNS, proxy HTTP, inspection TLS, filtrage, isolation de navigateur), eliminant le besoin de router le trafic vers un datacenter central. Le resultat est une latence minimale et une resilience maximale.

Les composants de Cloudflare One

La plateforme se decompose en sept briques fonctionnelles majeures, chacune adressant un aspect specifique de la securite Zero Trust :

Cloudflare Access est le composant d'authentification et d'autorisation. Il agit comme un reverse proxy d'identite devant vos applications internes (web, SSH, RDP, API). Chaque requete entrante est interceptee par Access qui verifie l'identite de l'utilisateur (via un fournisseur d'identite comme Okta, Azure AD, Google Workspace ou GitHub), evalue la posture de son appareil, applique les regles contextuelles (geolocalisation, horaire, groupe) et ne transmet la requete a l'application que si toutes les conditions sont remplies. Access remplace efficacement le VPN pour l'acces aux applications internes.

Cloudflare Gateway est le composant de filtrage DNS et HTTP. Il agit comme un Secure Web Gateway (SWG) en inspectant les requetes DNS et HTTP/HTTPS sortantes des utilisateurs pour bloquer les domaines malveillants, filtrer les categories de contenu indesirable, prevenir l'exfiltration de donnees et appliquer les politiques d'utilisation acceptable d'Internet. Gateway combine resolution DNS securisee (DNS over HTTPS), inspection TLS, antivirus en ligne et prevention de la perte de donnees (DLP).

Cloudflare Tunnel (anciennement Argo Tunnel) est le composant de connectivite. Il permet d'exposer des services internes (serveurs web, applications, API, bases de donnees) sur le reseau Cloudflare sans ouvrir de port entrant sur le pare-feu. Un daemon leger (cloudflared) installe sur le serveur d'origine etablit des connexions sortantes persistantes vers le reseau Cloudflare, qui se charge ensuite de router le trafic entrant vers ces tunnels. C'est la brique fondamentale qui elimine la surface d'attaque liee aux ports ouverts.

Cloudflare WARP est le client endpoint. Installe sur les postes de travail et les appareils mobiles, il cree un tunnel WireGuard vers le point de presence Cloudflare le plus proche, acheminant l'ensemble (ou une partie) du trafic reseau a travers la pile de securite Cloudflare. WARP collecte egalement les informations de posture de l'appareil (version de l'OS, etat du chiffrement disque, presence d'un antivirus) qui sont utilisees par Access pour les decisions d'autorisation.

Browser Isolation (isolation de navigateur) est le composant d'isolation. Il execute les pages web dans un conteneur distant sur le reseau Cloudflare et ne transmet a l'utilisateur que le rendu visuel (via un protocole propriataire de dessin vectoriel). Le code JavaScript malveillant, les exploits de navigateur et les telechargements non autorises sont neutralises car ils s'executent dans un environnement ephemere isole du poste de l'utilisateur. L'experience utilisateur est quasi transparente grace a la proximite des points de presence Cloudflare.

Data Loss Prevention (DLP) est le composant de protection des donnees. Il inspecte le trafic HTTP sortant (et certains flux SaaS via l'integration CASB) a la recherche de donnees sensibles : numeros de carte bancaire, numeros de securite sociale, donnees medicales, code source, secrets d'API. Les detections peuvent declencher des alertes, des blocages ou des actions de remediation automatisees. Le DLP de Cloudflare utilise a la fois des patterns regex predefinies et des algorithmes de machine learning pour la classification contextuelle.

CASB (Cloud Access Security Broker) est le composant de securite SaaS. Il s'integre via API aux applications SaaS utilisees par l'entreprise (Google Workspace, Microsoft 365, Salesforce, Slack, GitHub) pour detecter les erreurs de configuration, les partages excessifs de fichiers, les applications OAuth tierces a risque et les violations de politique. Le CASB fonctionne en mode out-of-band (sans intercepter le trafic en temps reel), ce qui permet une visibilite complete sans impact sur les performances.

L'approche plateforme vs. assemblage de solutions

L'un des defis majeurs du deploiement Zero Trust reside dans la proliferation des outils. Une entreprise typique qui souhaite implementer une architecture Zero Trust complete pourrait avoir besoin d'un fournisseur d'identite (Okta), d'un SWG (Zscaler), d'un ZTNA (Palo Alto Prisma), d'un CASB (Netskope), d'un DLP (Symantec), d'un service DNS securise (Cisco Umbrella) et d'un outil d'isolation de navigateur (Menlo Security). L'integration, la gestion et le depannage de cette pile heteroclite representent un cout operationnel considerable.

Cloudflare One adopte l'approche inverse : une plateforme unique, avec une console d'administration unique (le dashboard Zero Trust dans Cloudflare), des politiques coherentes qui s'appliquent transversalement a tous les composants, et un plan de donnees unifie sur le reseau Anycast. Cette integration native permet des synergies impossibles avec une pile heterogene : par exemple, une regle Gateway peut automatiquement declencher l'isolation de navigateur pour les sites a risque moyen, tout en transmettant les metadonnees de la session a Access pour enrichir les decisions d'autorisation.

Cloudflare Tunnel : exposer des services sans port ouvert

Cloudflare Tunnel est probablement le composant le plus revolutionnaire de l'ecosysteme Cloudflare One. Son principe est simple mais puissant : au lieu d'ouvrir des ports entrants sur votre pare-feu pour exposer des services internes, vous installez un daemon leger (cloudflared) sur votre serveur d'origine. Ce daemon etablit des connexions sortantes persistantes vers le reseau Cloudflare via le protocole QUIC (ou HTTP/2 en fallback). Le trafic entrant destine a votre service est route par Cloudflare a travers ces tunnels, sans que votre serveur n'ait besoin d'etre directement accessible depuis Internet.

Pourquoi Cloudflare Tunnel change la donne

Dans une architecture traditionnelle, exposer un service web necessitait d'ouvrir les ports 80 et 443 sur le pare-feu, de configurer un certificat TLS, de mettre en place un WAF, et de gerer la protection DDoS. Chaque port ouvert representait une surface d'attaque supplementaire. Les scans massifs (Shodan, Censys) detectaient ces services en quelques heures, et les tentatives d'exploitation automatisees commencaient immediatement.

Avec Cloudflare Tunnel, votre serveur n'a aucun port entrant ouvert. Il n'est meme pas necessaire qu'il ait une adresse IP publique. Le daemon cloudflared initie des connexions sortantes (port 7844 UDP pour QUIC, ou 443 TCP en fallback) vers les points de presence Cloudflare les plus proches. Ces connexions sont multiplexees et maintenues en permanence. Lorsqu'un utilisateur accede a votre domaine, Cloudflare route la requete a travers le tunnel jusqu'au serveur d'origine.

Les avantages de cette approche sont multiples :

• Zero surface d'attaque reseau : aucun port entrant ouvert, aucune adresse IP publique exposee. Votre serveur est invisible aux scans.
• TLS automatique : Cloudflare gere le certificat TLS face a l'utilisateur. La connexion entre Cloudflare et votre serveur est egalement chiffree via le tunnel QUIC.
• Protection DDoS native : le trafic transite par le reseau Cloudflare avant d'atteindre votre serveur, beneficiant automatiquement de la protection DDoS de Cloudflare.
• WAF et Rate Limiting : vous pouvez appliquer les regles WAF et de rate limiting de Cloudflare en amont du tunnel.
• Resilience : cloudflared etablit par defaut quatre connexions vers deux datacenters Cloudflare differents, assurant la haute disponibilite.
• Simplification operationnelle : plus besoin de gerer les regles de pare-feu entrantes, les certificats Let's Encrypt, les configurations NAT ou les IP statiques.

Architecture technique de Cloudflare Tunnel

Le daemon cloudflared est un binaire Go open source (code source disponible sur la documentation officielle Cloudflare One) qui s'execute sur la machine d'origine. Lors de la creation d'un tunnel, Cloudflare genere un jeton d'authentification (tunnel token) qui permet a cloudflared de s'authentifier aupres du reseau Cloudflare. Ce jeton est lie a un compte Cloudflare specifique et a un tunnel nomme.

Au demarrage, cloudflared etablit quatre connexions QUIC (ou HTTP/2) vers deux datacenters Cloudflare geographiquement proches. Ces connexions sont maintenues par des heartbeats et sont automatiquement retablies en cas de coupure. Le protocole QUIC offre un avantage significatif par rapport a HTTP/2 : il permet le multiplexage de flux sans head-of-line blocking, reduit la latence de reconnexion et gere nativement les changements d'IP (utile pour les clients mobiles).

Lorsqu'une requete arrive sur le reseau Cloudflare pour un domaine associe a un tunnel, la logique de routage identifie le tunnel correspondant (via un enregistrement DNS CNAME pointant vers <tunnel-id>.cfargotunnel.com) et transmet la requete a l'une des connexions actives du tunnel. Le daemon cloudflared recoit la requete et la transmet au service local configure dans les regles d'ingress.

Installation et configuration de cloudflared

L'installation de cloudflared est straightforward sur la plupart des systemes d'exploitation. Voici la procedure pour les distributions Linux basees sur Debian/Ubuntu :

# Ajout du depot Cloudflare
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/cloudflared.list

# Installation
sudo apt update && sudo apt install cloudflared

# Verification
cloudflared --version

Pour macOS via Homebrew :

brew install cloudflare/cloudflare/cloudflared

Pour Windows, un installeur MSI est disponible sur la page de releases GitHub de cloudflared. Sur Docker, l'image officielle cloudflare/cloudflared est disponible sur Docker Hub et peut etre utilisee directement dans un docker-compose.

Creation d'un tunnel nomme

Les tunnels nommes (named tunnels) sont la methode recommandee pour creer et gerer des tunnels. Ils offrent une configuration persistante, un identifiant stable et la possibilite de gerer les regles d'ingress via un fichier de configuration.

# Authentification aupres de Cloudflare
cloudflared tunnel login
# Ouvre un navigateur pour l'authentification OAuth
# Genere ~/.cloudflared/cert.pem

# Creation du tunnel
cloudflared tunnel create mon-tunnel-prod
# Output: Created tunnel mon-tunnel-prod with id a1b2c3d4-e5f6-...

# Le fichier de credentials est genere dans
# ~/.cloudflared/a1b2c3d4-e5f6-....json

# Creation du DNS CNAME
cloudflared tunnel route dns mon-tunnel-prod app.exemple.fr
# Cree un enregistrement CNAME: app.exemple.fr -> a1b2c3d4-e5f6-....cfargotunnel.com

Configuration des regles d'ingress

Le fichier de configuration de cloudflared definit les regles d'ingress qui mappent les requetes entrantes (basees sur le hostname et le chemin) vers les services locaux. Voici un exemple complet :

# ~/.cloudflared/config.yml
tunnel: a1b2c3d4-e5f6-7890-abcd-ef1234567890
credentials-file: /home/deploy/.cloudflared/a1b2c3d4-e5f6-7890-abcd-ef1234567890.json

# Parametres de transport
protocol: quic
# Nombre de connexions par datacenter (defaut: 4 au total, 2 par DC)
edge-ip-version: auto

# Metriques Prometheus
metrics: 127.0.0.1:2000

# Regles d'ingress (evaluees dans l'ordre, premiere correspondance gagne)
ingress:
  # Application web principale
  - hostname: app.exemple.fr
    service: http://localhost:8080
    originRequest:
      connectTimeout: 10s
      noTLSVerify: false
      httpHostHeader: app.exemple.fr

  # API interne
  - hostname: api.exemple.fr
    service: http://localhost:3000
    originRequest:
      connectTimeout: 30s
      # Headers personnalises transmis a l'origine
      httpHostHeader: api.interne

  # Acces SSH via navigateur (Cloudflare Access for Infrastructure)
  - hostname: ssh.exemple.fr
    service: ssh://localhost:22

  # Acces RDP
  - hostname: rdp.exemple.fr
    service: rdp://localhost:3389

  # Serveur Grafana interne
  - hostname: grafana.exemple.fr
    service: http://localhost:3001
    originRequest:
      # Basepath rewriting si necessaire
      noTLSVerify: true

  # TCP generique (base de donnees)
  - hostname: db.exemple.fr
    service: tcp://localhost:5432

  # Catch-all obligatoire (derniere regle)
  - service: http_status:404

Chaque regle d'ingress specifie un hostname (correspondant a un enregistrement DNS CNAME vers le tunnel) et un service local. Le bloc originRequest permet de configurer finement le comportement de la connexion entre cloudflared et le service local : timeouts, headers, verification TLS, keep-alive, etc.

Lancement et gestion du tunnel

# Lancement manuel (mode debug)
cloudflared tunnel run mon-tunnel-prod

# Installation en tant que service systemd
sudo cloudflared service install
# Cree /etc/systemd/system/cloudflared.service

# Verification du statut
cloudflared tunnel info mon-tunnel-prod

# Liste des tunnels actifs
cloudflared tunnel list

Deploiement avec Docker Compose

Pour les environnements containerises, cloudflared s'integre nativement dans un stack Docker Compose. Voici un exemple complet :

# docker-compose.yml
version: "3.8"

services:
  app:
    image: mon-app:latest
    ports:
      - "127.0.0.1:8080:8080"
    networks:
      - interne

  cloudflared:
    image: cloudflare/cloudflared:latest
    command: tunnel --no-autoupdate run --token ${TUNNEL_TOKEN}
    environment:
      - TUNNEL_TOKEN=${TUNNEL_TOKEN}
    restart: unless-stopped
    networks:
      - interne
    depends_on:
      - app

networks:
  interne:
    driver: bridge

L'utilisation d'un token (genere via le dashboard Cloudflare Zero Trust) permet de deployer le tunnel sans avoir besoin du fichier de credentials JSON sur la machine, simplifiant considerablement la gestion des secrets dans les environnements CI/CD.

Configuration Terraform pour Cloudflare Tunnel

Pour les equipes qui pratiquent l'Infrastructure as Code, le provider Terraform Cloudflare permet de gerer l'ensemble de la configuration des tunnels de maniere declarative. Voici un exemple complet :

# providers.tf
terraform {
  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 4.0"
    }
  }
}

provider "cloudflare" {
  api_token = var.cloudflare_api_token
}

# variables.tf
variable "cloudflare_api_token" {
  type      = string
  sensitive = true
}

variable "cloudflare_account_id" {
  type = string
}

variable "cloudflare_zone_id" {
  type = string
}

variable "domain" {
  type    = string
  default = "exemple.fr"
}

# tunnel.tf
resource "random_password" "tunnel_secret" {
  length  = 64
  special = false
}

resource "cloudflare_tunnel" "main" {
  account_id = var.cloudflare_account_id
  name       = "prod-tunnel"
  secret     = base64encode(random_password.tunnel_secret.result)
}

# Configuration du tunnel (ingress rules)
resource "cloudflare_tunnel_config" "main" {
  account_id = var.cloudflare_account_id
  tunnel_id  = cloudflare_tunnel.main.id

  config {
    ingress_rule {
      hostname = "app.${var.domain}"
      service  = "http://localhost:8080"
      origin_request {
        connect_timeout = "10s"
        no_tls_verify   = false
      }
    }

    ingress_rule {
      hostname = "api.${var.domain}"
      service  = "http://localhost:3000"
      origin_request {
        connect_timeout = "30s"
      }
    }

    ingress_rule {
      hostname = "ssh.${var.domain}"
      service  = "ssh://localhost:22"
    }

    # Catch-all (obligatoire)
    ingress_rule {
      service = "http_status:404"
    }
  }
}

# Enregistrements DNS CNAME
resource "cloudflare_record" "app" {
  zone_id = var.cloudflare_zone_id
  name    = "app"
  value   = "${cloudflare_tunnel.main.id}.cfargotunnel.com"
  type    = "CNAME"
  proxied = true
}

resource "cloudflare_record" "api" {
  zone_id = var.cloudflare_zone_id
  name    = "api"
  value   = "${cloudflare_tunnel.main.id}.cfargotunnel.com"
  type    = "CNAME"
  proxied = true
}

resource "cloudflare_record" "ssh" {
  zone_id = var.cloudflare_zone_id
  name    = "ssh"
  value   = "${cloudflare_tunnel.main.id}.cfargotunnel.com"
  type    = "CNAME"
  proxied = true
}

# Output du token pour le deploiement
output "tunnel_token" {
  value     = cloudflare_tunnel.main.tunnel_token
  sensitive = true
}

Cette approche IaC presente plusieurs avantages : versionnement de la configuration dans Git, revues de code avant deploiement, reproducibilite des environnements, et possibilite d'integrer la creation du tunnel dans un pipeline CI/CD qui provisionne egalement l'infrastructure serveur.

Cloudflare Access : authentification contextuelle

Cloudflare Access est le composant d'authentification et d'autorisation de Cloudflare One. Il agit comme un reverse proxy d'identite situe sur le reseau edge de Cloudflare, devant vos applications internes. Chaque requete est interceptee, l'identite de l'utilisateur est verifiee, et l'acces n'est accorde que si l'ensemble des conditions definies dans la politique d'acces sont satisfaites.

Access se distingue des solutions d'authentification traditionnelles par sa position dans l'architecture : il s'execute sur le edge Cloudflare, avant meme que la requete n'atteigne votre serveur d'origine. Cela signifie que les requetes non autorisees sont rejetees au niveau du reseau Cloudflare, sans jamais consommer de ressources sur votre infrastructure. C'est un avantage considerable en termes de securite (zero exposition de l'application aux acteurs non authentifies) et de performance (reduction de la charge sur le serveur d'origine).

Integration avec les fournisseurs d'identite (IdP)

Access supporte une large gamme de fournisseurs d'identite via les protocoles standards OpenID Connect (OIDC) et SAML 2.0. Les integrations natives incluent :

• Okta : integration OIDC avec support des groupes, MFA et device trust
• Azure Active Directory (Entra ID) : integration OIDC avec support des groupes Azure AD, acces conditionnel et device compliance
• Google Workspace : integration OIDC avec support des groupes Google et des unites organisationnelles
• GitHub : authentification via OAuth avec support des organisations et des equipes
• OneLogin, PingIdentity, JumpCloud : integration SAML/OIDC standard
• Fournisseur OIDC generique : tout IdP compatible OIDC peut etre integre
• Fournisseur SAML generique : tout IdP compatible SAML 2.0 peut etre integre
• One-Time PIN (OTP) : pour les utilisateurs externes qui n'ont pas de compte dans votre IdP, Access peut envoyer un code a usage unique par email

Plusieurs fournisseurs d'identite peuvent etre configures simultanement, permettant aux utilisateurs de choisir leur methode d'authentification sur la page de login Access. C'est particulierement utile pour les organisations qui doivent accueillir a la fois des employes (authentification via Azure AD interne) et des partenaires externes (authentification via OTP ou un IdP federe).

Politiques d'acces : la granularite Zero Trust

Les politiques Access sont le coeur du mecanisme d'autorisation. Elles definissent qui peut acceder a quelle application, dans quelles conditions. Chaque application protegee par Access possede un ensemble ordonne de politiques, evaluees de haut en bas. Les types de decisions possibles sont :

• Allow : autorise l'acces si toutes les conditions de la regle sont remplies
• Block : refuse explicitement l'acces
• Bypass : desactive Access pour certains chemins (utile pour les health checks)
• Service Auth : autorise l'acces via un service token (machine-to-machine)

Les conditions disponibles pour construire les politiques sont extremement riches :

• Identite : adresse email, domaine email, groupe IdP, claim OIDC/SAML specifique
• Geolocalisation : pays d'origine de la requete (basee sur l'IP GeoIP)
• Reseau : plage d'adresses IP source (CIDR)
• Posture de l'appareil : presence du client WARP, version OS minimale, chiffrement disque actif, logiciel antivirus/EDR actif, numero de serie de l'appareil, certificat client mTLS
• Methode d'authentification : MFA specifique utilisee (TOTP, WebAuthn, push), IdP specifique
• Temporalite : duree de la session, re-authentification periodique

Service Tokens et authentification machine-to-machine

Toutes les requetes vers des applications protegees par Access ne proviennent pas necessairement d'un utilisateur humain. Les pipelines CI/CD, les scripts de monitoring, les webhooks et les communications inter-services necessitent egalement un acces authentifie. Pour ces cas d'usage, Access propose les Service Tokens.

Un Service Token est une paire Client ID / Client Secret generee dans le dashboard Cloudflare. Les requetes machine-to-machine incluent ces credentials dans les headers HTTP :

# Requete avec Service Token
curl -H "CF-Access-Client-Id: <client-id>" \
     -H "CF-Access-Client-Secret: <client-secret>" \
     https://api.exemple.fr/health

# Exemple dans un pipeline GitLab CI
deploy:
  stage: deploy
  script:
    - curl -X POST
        -H "CF-Access-Client-Id: ${CF_ACCESS_CLIENT_ID}"
        -H "CF-Access-Client-Secret: ${CF_ACCESS_CLIENT_SECRET}"
        -H "Content-Type: application/json"
        -d '{"version": "'${CI_COMMIT_SHA}'"}'
        https://api.exemple.fr/deploy

Les Service Tokens peuvent avoir une date d'expiration et etre revoques individuellement. Il est fortement recommande de creer un Service Token par consommateur (un token par pipeline, un token par script de monitoring) plutot qu'un token partage, afin de faciliter la tracabilite et la revocation en cas de compromission.

mTLS (Mutual TLS) : authentification par certificat client

Pour les scenarios qui exigent un niveau d'assurance cryptographique encore plus eleve, Access supporte l'authentification par certificat client (mTLS). Dans ce mode, le client doit presenter un certificat TLS valide signe par une autorite de certification (CA) de confiance configuree dans Access. Cette approche est particulierement adaptee aux communications IoT, aux API financieres et aux acces depuis des terminaux manages par l'entreprise.

Cloudflare permet de generer une CA privee directement dans le dashboard, ou d'importer votre propre CA. Les certificats clients peuvent etre distribues via MDM (Mobile Device Management) aux appareils d'entreprise, fournissant une couche d'authentification supplementaire independante de l'identite utilisateur.

# Configuration Terraform d'une politique Access avec mTLS
resource "cloudflare_access_policy" "api_mtls" {
  application_id = cloudflare_access_application.api.id
  zone_id        = var.cloudflare_zone_id
  name           = "API mTLS authentication"
  precedence     = 1
  decision       = "non_identity"

  include {
    certificate = true
  }
}

# Association du certificat CA
resource "cloudflare_access_mutual_tls_certificate" "ca" {
  zone_id              = var.cloudflare_zone_id
  name                 = "Corporate CA"
  certificate          = file("${path.module}/certs/corporate-ca.pem")
  associated_hostnames = ["api.exemple.fr"]
}

JWT et propagation d'identite

Apres authentification reussie, Access genere un JSON Web Token (JWT) signe qu'il transmet a l'application d'origine via le header Cf-Access-Jwt-Assertion et un cookie CF_Authorization. Ce JWT contient les claims d'identite de l'utilisateur (email, groupes, IdP utilise) et peut etre verifie par l'application d'origine a l'aide de la cle publique de signature disponible a l'endpoint https://<team-domain>.cloudflareaccess.com/cdn-cgi/access/certs.

Cette propagation d'identite est cruciale : elle permet a l'application d'origine de connaitre l'identite de l'utilisateur authentifie sans avoir besoin d'implementer sa propre logique d'authentification. L'application peut utiliser les claims du JWT pour les decisions d'autorisation applicative (RBAC), l'audit trail et la personnalisation de l'interface.

# Verification du JWT Access en Python (Flask)
import jwt
import requests
from functools import wraps
from flask import request, abort

TEAM_DOMAIN = "mon-equipe.cloudflareaccess.com"
CERTS_URL = f"https://{TEAM_DOMAIN}/cdn-cgi/access/certs"
AUDIENCE = "32eafc7c8a77e1c69e34a8e344293..."  # Application Audience (AUD) Tag

def get_public_keys():
    """Recupere les cles publiques de signature Access."""
    resp = requests.get(CERTS_URL)
    jwk_set = resp.json()
    return [jwt.algorithms.RSAAlgorithm.from_jwk(key) for key in jwk_set["keys"]]

def verify_access_token(f):
    """Decorateur pour verifier le JWT Access."""
    @wraps(f)
    def decorated(*args, **kwargs):
        token = request.cookies.get("CF_Authorization") or \
                request.headers.get("Cf-Access-Jwt-Assertion")
        if not token:
            abort(403, "Token Access manquant")

        keys = get_public_keys()
        for key in keys:
            try:
                payload = jwt.decode(
                    token,
                    key=key,
                    audience=AUDIENCE,
                    algorithms=["RS256"]
                )
                request.access_identity = payload
                return f(*args, **kwargs)
            except jwt.InvalidTokenError:
                continue

        abort(403, "Token Access invalide")
    return decorated

@app.route("/api/data")
@verify_access_token
def get_data():
    email = request.access_identity.get("email")
    groups = request.access_identity.get("custom", {}).get("groups", [])
    # Logique d'autorisation applicative basee sur les claims
    return {"user": email, "groups": groups}

Cloudflare Gateway : DNS et HTTP filtering

Cloudflare Gateway est le composant Secure Web Gateway (SWG) de Cloudflare One. Il inspecte et filtre le trafic DNS et HTTP/HTTPS sortant des utilisateurs, offrant une protection contre les menaces (malware, phishing, command & control), un controle de l'utilisation d'Internet (filtrage de categories) et une prevention de la perte de donnees (DLP). Gateway fonctionne a deux niveaux complementaires : le filtrage DNS et le filtrage HTTP.

Filtrage DNS : la premiere ligne de defense

Le filtrage DNS est le mecanisme le plus simple et le plus leger a deployer. En configurant les appareils pour utiliser les resolvers DNS de Cloudflare Gateway (soit via le client WARP, soit en configurant manuellement les serveurs DNS), chaque requete de resolution de nom est evaluee contre les politiques definies dans le dashboard.

Le filtrage DNS presente plusieurs avantages :

• Deploiement immediat : il suffit de changer les serveurs DNS pour que la protection soit active
• Couverture universelle : tout appareil qui fait des requetes DNS est protege, y compris les appareils IoT qui ne peuvent pas executer le client WARP
• Faible latence : le filtrage s'effectue lors de la resolution DNS, sans intercepter le trafic HTTP
• Pas de certificat : contrairement au filtrage HTTP/TLS, le filtrage DNS ne necessite pas l'installation d'un certificat racine sur les appareils

Les politiques DNS de Gateway permettent de :

• Bloquer les domaines malveillants (bases sur les feeds de threat intelligence Cloudflare, mis a jour en temps reel)
• Bloquer les categories de contenu (adulte, jeux d'argent, reseaux sociaux, etc. — plus de 100 categories disponibles)
• Bloquer les domaines recemment enregistres (souvent utilises pour le phishing)
• Bloquer les domaines utilisant des algorithmes de generation de noms (DGA), typiques des botnets
• Autoriser explicitement des domaines (whitelist)
• Rediriger les requetes vers des resolvers personnalises (split DNS pour les domaines internes)

Pour les reseaux d'entreprise, Gateway propose des configurations DNS over HTTPS (DoH) avec un endpoint dedie par organisation, garantissant que les requetes DNS sont chiffrees et ne peuvent pas etre interceptees ou modifiees en transit :

# Endpoint DoH dedie a votre organisation
https://<team-id>.cloudflare-gateway.com/dns-query

# Configuration sur un routeur (exemple pfSense)
# DNS over HTTPS upstream: https://<team-id>.cloudflare-gateway.com/dns-query

# Configuration systemd-resolved (Linux)
# /etc/systemd/resolved.conf
[Resolve]
DNS=172.16.0.2
DNSOverTLS=yes
Domains=~.

# Configuration via WARP client (recommande)
# Le client WARP configure automatiquement le DNS Gateway

Filtrage HTTP/HTTPS : inspection approfondie

Le filtrage HTTP va plus loin que le filtrage DNS en inspectant le contenu des requetes HTTP et HTTPS. Pour le trafic HTTPS, Gateway effectue une inspection TLS (TLS interception) en utilisant un certificat racine Cloudflare installe sur les appareils de l'utilisateur. Ce mecanisme, souvent appele "break and inspect", permet d'analyser le contenu chiffre des requetes.

Le filtrage HTTP permet des politiques beaucoup plus granulaires que le filtrage DNS :

• Filtrage par URL complete : bloquer un chemin specifique sur un domaine autorise (ex: bloquer github.com/*/releases mais autoriser le reste de GitHub)
• Filtrage par type MIME : bloquer le telechargement de certains types de fichiers (executables, archives, scripts)
• Filtrage par header HTTP : inspecter les headers de requete et de reponse
• Antivirus en ligne : les fichiers telecharges sont scannes par le moteur antivirus de Cloudflare avant d'etre transmis a l'utilisateur
• DLP en ligne : le contenu des requetes et des reponses est inspecte a la recherche de donnees sensibles (numeros de carte, PII, code source)
• Tenant control : restreindre l'acces aux tenants d'applications SaaS autorises (ex: autoriser uniquement le tenant Google Workspace de l'entreprise, bloquer les comptes personnels)

Split Tunnels et Do Not Inspect

Tous les flux de trafic n'ont pas vocation a etre inspectes par Gateway. Les applications de visioconference (Teams, Zoom) generent un volume important de trafic temps reel qui beneficie peu de l'inspection et qui pourrait souffrir de la latence supplementaire. De meme, certaines applications financieres ou medicales utilisent le certificate pinning, incompatible avec l'inspection TLS.

Gateway propose deux mecanismes de contournement :

Split Tunnel : configure au niveau du client WARP, il determine quel trafic est route vers le reseau Cloudflare et quel trafic emprunte la connexion Internet directe. Deux modes sont disponibles :

• Exclude mode (defaut) : tout le trafic passe par Cloudflare, sauf les destinations explicitement exclues. C'est le mode le plus securise.
• Include mode : seul le trafic destine aux IP/domaines explicitement listes passe par Cloudflare. Le reste du trafic emprunte Internet directement. Ce mode est utilise quand on souhaite proteger uniquement l'acces aux ressources internes sans filtrer le trafic Internet general.

Do Not Inspect : configure dans les politiques HTTP de Gateway, il permet de bypasser l'inspection TLS pour certains domaines tout en maintenant le routage via Cloudflare. Le trafic vers ces domaines est toujours soumis aux politiques DNS mais pas a l'inspection HTTP/TLS.

# Exemple de configuration Split Tunnel (Exclude mode) via API
# Exclure le trafic Teams/Zoom du tunnel
curl -X PUT \
  "https://api.cloudflare.com/client/v4/accounts/{account_id}/devices/policy/exclude" \
  -H "Authorization: Bearer {api_token}" \
  -H "Content-Type: application/json" \
  -d '[
    {"address": "13.107.64.0/18", "description": "Microsoft Teams"},
    {"address": "52.112.0.0/14", "description": "Microsoft Teams Media"},
    {"host": "*.zoom.us", "description": "Zoom"},
    {"address": "170.114.0.0/16", "description": "Zoom Media"}
  ]'

Logpush : exportation des logs vers votre SIEM

Gateway genere des logs detailles pour chaque requete DNS et HTTP filtree. Ces logs incluent l'identite de l'utilisateur, l'appareil source, le domaine/URL demande, la politique appliquee, l'action executee et les metadonnees de la requete. Cloudflare Logpush permet d'exporter ces logs en temps reel vers des destinations externes :

• Amazon S3 / R2
• Google Cloud Storage
• Azure Blob Storage
• Splunk
• Datadog
• Sumo Logic
• New Relic
• Endpoint HTTP generique (webhook)

L'integration SIEM est essentielle pour les equipes SOC qui ont besoin de correler les evenements Gateway avec d'autres sources de telemetrie (EDR, firewall, IDS) pour la detection des menaces avancees et la reponse aux incidents.

WARP Client : device posture et enrollment

Le client WARP est l'agent endpoint de Cloudflare One. Disponible sur Windows, macOS, Linux, iOS et Android, il remplit trois fonctions essentielles : l'etablissement du tunnel WireGuard vers le reseau Cloudflare, la collecte des informations de posture de l'appareil, et l'application des politiques split tunnel.

Architecture technique du client WARP

WARP utilise le protocole WireGuard (ou plus precisement, une implementation proprietaire de WireGuard optimisee par Cloudflare, appelee BoringTun) pour etablir un tunnel chiffre vers le point de presence Cloudflare le plus proche. Ce tunnel est maintenu en permanence et se reconnecte automatiquement en cas de changement de reseau (passage du WiFi au cellulaire, changement de point d'acces).

Le client WARP fonctionne en trois modes :

• WARP mode : tout le trafic de l'appareil (DNS et HTTP/TCP/UDP) est route via le tunnel WireGuard vers Cloudflare. C'est le mode le plus securise, equivalent a un "always-on VPN" mais sans les inconvenients du VPN traditionnel.
• Gateway with WARP : identique au mode WARP mais avec l'application des politiques Gateway (filtrage DNS et HTTP). C'est le mode recommande pour les deploiements d'entreprise.
• Gateway with DoH : seules les requetes DNS sont routees vers Cloudflare Gateway (via DNS over HTTPS). Le trafic HTTP/TCP emprunte Internet directement. Ce mode offre une protection DNS sans l'overhead du tunnel complet, adapte aux appareils a faible puissance ou aux scenarios ou l'inspection HTTP n'est pas souhaitee.

Enrollment des appareils

L'enrollment est le processus par lequel un appareil est enregistre aupres de votre organisation Cloudflare Zero Trust. Plusieurs methodes d'enrollment sont supportees :

Enrollment manuel : l'utilisateur installe le client WARP, entre le nom de l'equipe (team name) de l'organisation, et s'authentifie via l'IdP configure. C'est la methode la plus simple pour les petits deploiements ou les appareils BYOD.

Enrollment via MDM : pour les deploiements a grande echelle, le client WARP peut etre pre-configure et deploye silencieusement via un systeme de Mobile Device Management (Intune, Jamf, Workspace ONE, etc.). Un fichier de configuration XML/plist specifie le team name, les parametres de connexion et le mode d'enrollment.

# Exemple de profil MDM pour macOS (Jamf)
# com.cloudflare.warp.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>organization</key>
  <string>mon-equipe</string>
  <key>auth_client_id</key>
  <string>abc123.access</string>
  <key>auth_client_secret</key>
  <string>def456secret</string>
  <key>gateway_unique_id</key>
  <string>team-id-unique</string>
  <key>service_mode</key>
  <string>warp</string>
  <key>auto_connect</key>
  <integer>0</integer>
  <key>switch_locked</key>
  <true/>
</dict>
</plist>

Enrollment par numero de serie : pour un controle encore plus strict, vous pouvez restreindre l'enrollment aux appareils dont le numero de serie est pre-enregistre dans Cloudflare. Seuls les appareils d'entreprise autorises pourront rejoindre l'organisation, empechant les appareils personnels non geres de se connecter.

Device Posture : evaluation continue de la securite des appareils

Le client WARP collecte en permanence des informations sur l'etat de securite de l'appareil. Ces informations, appelees "device posture signals", sont evaluees par les politiques Access et Gateway pour prendre des decisions d'autorisation contextuelles. Les signaux de posture disponibles incluent :

• Version du systeme d'exploitation : exiger une version minimale de Windows, macOS, iOS ou Android (ex: Windows 11 22H2 minimum)
• Chiffrement du disque : verifier que FileVault (macOS), BitLocker (Windows) ou LUKS (Linux) est actif
• Pare-feu actif : verifier que le pare-feu systeme est active
• Verrouillage d'ecran : verifier qu'un code ou mot de passe est configure
• Integrations EDR/EPP : verifier la presence et le statut de solutions de securite tierces :
  • CrowdStrike Falcon (score ZTA, derniere analyse)
  • SentinelOne (agent actif, score de risque)
  • Microsoft Defender for Endpoint
  • Tanium
  • Carbon Black
  • Uptycs
• Certificat client : verifier la presence d'un certificat specifique dans le keystore de l'appareil
• Domain join : verifier que l'appareil est joint au domaine Active Directory de l'entreprise
• Numero de serie : verifier que le numero de serie de l'appareil figure dans une liste autorisee

Ces signaux de posture sont remontes en temps reel au plan de controle Cloudflare et peuvent etre utilises comme conditions dans les politiques Access. Par exemple, une politique peut exiger : "L'utilisateur doit appartenir au groupe 'Engineering' ET l'appareil doit avoir CrowdStrike actif avec un score ZTA superieur a 70 ET le disque doit etre chiffre ET la version de macOS doit etre >= 14.0".

# Configuration Terraform d'une regle de posture d'appareil
resource "cloudflare_device_posture_rule" "os_version" {
  account_id  = var.cloudflare_account_id
  name        = "macOS minimum version"
  type        = "os_version"
  description = "Require macOS 14.0 or later"

  input {
    version    = "14.0.0"
    operator   = ">="
    os_distro_name = "mac"
  }
}

resource "cloudflare_device_posture_rule" "disk_encryption" {
  account_id  = var.cloudflare_account_id
  name        = "Disk encryption required"
  type        = "disk_encryption"
  description = "FileVault must be enabled"

  input {
    require_all = true
  }
}

resource "cloudflare_device_posture_rule" "crowdstrike" {
  account_id  = var.cloudflare_account_id
  name        = "CrowdStrike ZTA score"
  type        = "crowdstrike_s2s"
  description = "CrowdStrike ZTA score must be >= 70"

  input {
    version_operator = ">="
    count_operator   = ">="
    score_operator   = ">="
    overall          = "70"
  }
}

# Utilisation dans une politique Access
resource "cloudflare_access_policy" "engineering_app" {
  application_id = cloudflare_access_application.internal_app.id
  zone_id        = var.cloudflare_zone_id
  name           = "Engineering team with device posture"
  precedence     = 1
  decision       = "allow"

  include {
    group = [cloudflare_access_group.engineering.id]
  }

  require {
    device_posture = [
      cloudflare_device_posture_rule.os_version.id,
      cloudflare_device_posture_rule.disk_encryption.id,
      cloudflare_device_posture_rule.crowdstrike.id,
    ]
  }
}

Deploiement step-by-step complet

Cette section presente un guide de deploiement complet, de A a Z, pour mettre en place une architecture Cloudflare Zero Trust couvrant l'acces aux applications internes, le filtrage DNS/HTTP et la gestion des appareils. Ce guide suppose que vous disposez d'un compte Cloudflare avec un domaine configure et d'un fournisseur d'identite (nous utiliserons Azure AD dans cet exemple).

Etape 1 : Configuration initiale de Cloudflare Zero Trust

Commencez par acceder au dashboard Cloudflare Zero Trust (one.dash.cloudflare.com). Lors de la premiere connexion, vous devez definir un nom d'equipe (team name) qui servira d'identifiant pour votre organisation. Ce team name sera utilise dans les URLs d'authentification (https://<team-name>.cloudflareaccess.com) et dans la configuration du client WARP.

# Verification de la configuration via API
curl -s "https://api.cloudflare.com/client/v4/accounts/{account_id}/access/organizations" \
  -H "Authorization: Bearer {api_token}" | jq '.result'

# Reponse attendue :
{
  "name": "Mon Organisation",
  "auth_domain": "mon-equipe.cloudflareaccess.com",
  "login_design": { ... },
  "is_ui_read_only": false
}

Etape 2 : Integration du fournisseur d'identite

Configurez l'integration avec votre fournisseur d'identite. Pour Azure AD :

1. Dans le portail Azure, creez une inscription d'application (App Registration) pour Cloudflare Access
2. Configurez les URI de redirection : https://mon-equipe.cloudflareaccess.com/cdn-cgi/access/callback
3. Activez les permissions openid, profile, email, offline_access et User.Read
4. Pour le support des groupes, ajoutez la permission Directory.Read.All (type Application)
5. Generez un client secret
6. Dans le dashboard Cloudflare Zero Trust, ajoutez Azure AD comme IdP en renseignant le Client ID, le Client Secret et le Directory (Tenant) ID

# Test de l'integration IdP via API
curl -s "https://api.cloudflare.com/client/v4/accounts/{account_id}/access/identity_providers" \
  -H "Authorization: Bearer {api_token}" | jq '.result[] | {name, type, id}'

Etape 3 : Installation et configuration de Cloudflare Tunnel

Installez cloudflared sur le serveur qui heberge vos applications internes :

# Installation sur Ubuntu/Debian
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee \
  /usr/share/keyrings/cloudflare-main.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] \
  https://pkg.cloudflare.com/cloudflared $(lsb_release -cs) main" | \
  sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt update && sudo apt install -y cloudflared

# Creation du tunnel via le dashboard (recommande)
# Dashboard > Zero Trust > Networks > Tunnels > Create a tunnel
# Copiez le token genere

# OU creation via CLI
cloudflared tunnel login
cloudflared tunnel create prod-tunnel
cloudflared tunnel route dns prod-tunnel app.mondomaine.fr
cloudflared tunnel route dns prod-tunnel api.mondomaine.fr

# Configuration
cat > /etc/cloudflared/config.yml <<EOF
tunnel: <tunnel-id>
credentials-file: /etc/cloudflared/<tunnel-id>.json
protocol: quic
metrics: 127.0.0.1:2000

ingress:
  - hostname: app.mondomaine.fr
    service: http://localhost:8080
  - hostname: api.mondomaine.fr
    service: http://localhost:3000
  - hostname: ssh.mondomaine.fr
    service: ssh://localhost:22
  - service: http_status:404
EOF

# Installation du service systemd
sudo cloudflared service install
sudo systemctl enable cloudflared
sudo systemctl start cloudflared

# Verification
sudo systemctl status cloudflared
cloudflared tunnel info prod-tunnel

Etape 4 : Creation des applications et politiques Access

Creez une application Access pour chaque service expose via le tunnel :

# Via Terraform (recommande pour l'IaC)
resource "cloudflare_access_application" "app_interne" {
  zone_id                   = var.cloudflare_zone_id
  name                      = "Application Interne"
  domain                    = "app.mondomaine.fr"
  type                      = "self_hosted"
  session_duration          = "8h"
  auto_redirect_to_identity = true
  http_only_cookie_attribute = true
  same_site_cookie_attribute = "lax"

  # Logo personnalise (optionnel)
  logo_url = "https://app.mondomaine.fr/logo.png"
}

# Politique: Engineering team
resource "cloudflare_access_policy" "engineering" {
  application_id = cloudflare_access_application.app_interne.id
  zone_id        = var.cloudflare_zone_id
  name           = "Engineering Team"
  precedence     = 1
  decision       = "allow"

  include {
    group = ["engineering@mondomaine.fr"]
  }

  require {
    geo = ["FR", "DE", "BE"]
  }
}

# Politique: Service token pour CI/CD
resource "cloudflare_access_policy" "cicd" {
  application_id = cloudflare_access_application.app_interne.id
  zone_id        = var.cloudflare_zone_id
  name           = "CI/CD Pipeline"
  precedence     = 2
  decision       = "service_auth"

  include {
    service_token = [cloudflare_access_service_token.cicd.id]
  }
}

resource "cloudflare_access_service_token" "cicd" {
  account_id = var.cloudflare_account_id
  name       = "GitLab CI Pipeline"
  min_days_for_renewal = 30
}

# Application SSH avec rendu navigateur
resource "cloudflare_access_application" "ssh" {
  zone_id          = var.cloudflare_zone_id
  name             = "SSH Access"
  domain           = "ssh.mondomaine.fr"
  type             = "ssh"
  session_duration = "1h"
}

Etape 5 : Configuration des politiques Gateway

Definissez les politiques de filtrage DNS et HTTP :

# Politique DNS : bloquer les menaces
resource "cloudflare_teams_rule" "block_malware_dns" {
  account_id  = var.cloudflare_account_id
  name        = "Block malware domains"
  description = "Block domains categorized as malware, phishing, or C2"
  precedence  = 1
  action      = "block"
  enabled     = true

  traffic = "any(dns.security_category[*] in {80 83 176 178})"

  rule_settings {
    block_page_enabled  = true
    block_page_reason   = "Ce domaine a ete bloque car il est associe a des activites malveillantes."
  }
}

# Politique DNS : bloquer les categories non-professionnelles
resource "cloudflare_teams_rule" "block_categories_dns" {
  account_id  = var.cloudflare_account_id
  name        = "Block non-business categories"
  description = "Block adult, gambling, and social media during work hours"
  precedence  = 2
  action      = "block"
  enabled     = true

  traffic = "any(dns.content_category[*] in {4 5 6 24})"

  rule_settings {
    block_page_enabled  = true
    block_page_reason   = "L'acces a cette categorie de sites est restreint par la politique de l'entreprise."
  }
}

# Politique HTTP : bloquer le telechargement d'executables
resource "cloudflare_teams_rule" "block_exe_download" {
  account_id  = var.cloudflare_account_id
  name        = "Block executable downloads"
  description = "Block download of executable files from untrusted sources"
  precedence  = 10
  action      = "block"
  enabled     = true

  traffic = "http.response.content_type[*] in {\"application/x-msdownload\" \"application/x-executable\"} and not any(http.request.host[*] in {\"update.microsoft.com\" \"dl.google.com\"})"

  rule_settings {
    block_page_enabled  = true
    block_page_reason   = "Le telechargement de fichiers executables est bloque."
  }
}

# Politique HTTP : DLP - bloquer l'envoi de numeros de carte bancaire
resource "cloudflare_teams_rule" "dlp_credit_card" {
  account_id  = var.cloudflare_account_id
  name        = "DLP - Block credit card exfiltration"
  description = "Block HTTP requests containing credit card numbers"
  precedence  = 20
  action      = "block"
  enabled     = true

  traffic = "any(http.request.body contains_credit_card_numbers)"

  rule_settings {
    block_page_enabled  = true
    block_page_reason   = "L'envoi de numeros de carte bancaire est bloque."
  }
}

Etape 6 : Deploiement du client WARP

Deployer le client WARP sur les appareils de l'entreprise :

# Windows - deploiement silencieux via GPO ou Intune
# Telechargement de l'installeur MSI depuis https://developers.cloudflare.com/cloudflare-one/connections/connect-devices/warp/download-warp/

# Installation silencieuse
msiexec /i Cloudflare_WARP_Release-x64.msi /quiet ORGANIZATION="mon-equipe" ONBOARDING="false" SERVICE_MODE="warp"

# macOS - deploiement via Jamf
# Utiliser le package PKG officiel + profil de configuration plist

# Linux - installation et configuration
curl -fsSL https://pkg.cloudflare.com/cloudflare-warp-ascii.gpg | sudo tee \
  /usr/share/keyrings/cloudflare-warp-ascii.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/cloudflare-warp-ascii.gpg] \
  https://pkg.cloudflare.com/cloudflare-warp $(lsb_release -cs) main" | \
  sudo tee /etc/apt/sources.list.d/cloudflare-warp.list
sudo apt update && sudo apt install -y cloudflare-warp

# Enregistrement
warp-cli teams-enroll mon-equipe
# Ouvre le navigateur pour l'authentification

# Verification
warp-cli status
warp-cli teams-enroll-status

Etape 7 : Validation et tests

Apres le deploiement, validez chaque composant :

# Test du tunnel
curl -I https://app.mondomaine.fr
# Doit retourner 302 vers la page d'authentification Access

# Test Access (apres authentification)
# Verifier le JWT dans les headers
curl -s -H "Cookie: CF_Authorization=<jwt>" https://app.mondomaine.fr/api/whoami

# Test Gateway DNS
dig @172.64.36.1 malware-test.cloudflare-dns.com
# Doit retourner 0.0.0.0 (bloque)

# Test Gateway HTTP
curl -v https://malware.testcategory.com
# Doit afficher la page de blocage

# Test SSH via navigateur
# Acceder a https://ssh.mondomaine.fr dans le navigateur
# Doit afficher le terminal SSH apres authentification Access

# Verification de la posture
warp-cli device-posture
# Affiche les checks de posture evalues

Cas d'usage concrets

Au-dela de la theorie, examinons des scenarios reels ou Cloudflare Zero Trust apporte une valeur tangible par rapport aux architectures traditionnelles.

Cas 1 : Acces SSH/RDP sans VPN pour les equipes DevOps

Scenario : une equipe de 50 developpeurs et SRE doit acceder quotidiennement a des serveurs Linux (SSH) et Windows (RDP) situes dans un datacenter on-premise et dans AWS. Actuellement, ils utilisent un VPN Cisco AnyConnect qui genere des plaintes constantes : deconnexions, latence, conflits de routage avec les reseaux domestiques.

Solution avec Cloudflare Zero Trust :

1. Installer cloudflared sur chaque serveur cible (ou sur un bastion unique qui proxyfie les connexions)
2. Configurer des regles d'ingress pour chaque service SSH/RDP
3. Creer des applications Access avec des politiques granulaires par equipe et par serveur
4. Les developpeurs accedent a SSH directement depuis leur navigateur (terminal web rendu par Cloudflare) ou via cloudflared access ssh pour un acces natif avec leur client SSH prefere

# Acces SSH natif via cloudflared (cote client)
# Configuration ~/.ssh/config
Host ssh.mondomaine.fr
  ProxyCommand cloudflared access ssh --hostname %h

# Utilisation
ssh user@ssh.mondomaine.fr
# cloudflared intercepte la connexion, ouvre le navigateur pour
# l'authentification Access, puis tunnel le SSH a travers Cloudflare

# Pour RDP, utilisation du tunnel TCP
cloudflared access tcp --hostname rdp.mondomaine.fr --url localhost:3390
# Puis connexion RDP vers localhost:3390

Les avantages par rapport au VPN sont immediats : connexion instantanee sans client VPN, authentification contextuelle a chaque session, audit trail complet de chaque commande SSH (avec session recording optionnel), et zero configuration reseau sur le poste client. Les developpeurs travaillent depuis chez eux, depuis un cafe ou depuis un espace de coworking avec exactement la meme experience.

Cas 2 : SaaS prive pour les equipes distribuees

Scenario : une scale-up de 200 personnes heberge plusieurs applications internes (wiki Confluence, outil de ticketing, dashboard BI, admin e-commerce) sur des serveurs derriere un pare-feu. L'equipe, repartie sur 5 pays, utilisait un VPN qui saturait regulierement le concentrateur central.

Solution : chaque application interne est exposee via un Cloudflare Tunnel dedie, avec une application Access configuree individuellement. Les politiques sont definies par equipe et par application :

• Le wiki Confluence est accessible a tous les employes authentifies via Azure AD
• Le dashboard BI est restreint aux equipes Finance et Direction, avec MFA WebAuthn obligatoire
• L'admin e-commerce est restreint a l'equipe Operations, uniquement depuis des appareils avec CrowdStrike actif
• Le ticketing est accessible a tous les employes plus les prestataires externes via OTP email

Resultat : chaque application a ses propres politiques d'acces, la latence est reduite de 60% en moyenne (le trafic ne fait plus le detour par le concentrateur VPN central), et les prestataires externes n'ont plus besoin d'un acces VPN complet pour consulter le ticketing.

Cas 3 : Securisation d'une infrastructure DevOps multi-cloud

Scenario : une entreprise utilise AWS, GCP et un datacenter on-premise. Les outils DevOps (Jenkins, ArgoCD, Grafana, Vault, Kibana) sont repartis sur ces trois environnements. Les equipes utilisent actuellement un mesh VPN (WireGuard self-hosted) difficile a maintenir et sans controle d'acces granulaire.

Solution : deployer un daemon cloudflared dans chaque environnement (un EC2 dans AWS, un GCE dans GCP, un serveur dans le datacenter) avec des tunnels dedies. Chaque outil est expose via un sous-domaine Access avec des politiques specifiques :

# Ingress rules pour l'environnement AWS
ingress:
  - hostname: jenkins.devops.exemple.fr
    service: http://jenkins-internal:8080
  - hostname: argocd.devops.exemple.fr
    service: https://argocd-server:443
    originRequest:
      noTLSVerify: true  # ArgoCD self-signed cert
  - hostname: grafana.devops.exemple.fr
    service: http://grafana:3000
  - service: http_status:404

# Ingress rules pour l'environnement GCP
ingress:
  - hostname: vault.devops.exemple.fr
    service: https://vault:8200
  - hostname: kibana.devops.exemple.fr
    service: http://kibana:5601
  - service: http_status:404

L'avantage majeur est la centralisation des politiques d'acces dans une console unique, independamment de l'emplacement physique des services. Un SRE qui accede a Grafana dans AWS et Kibana dans GCP a la meme experience d'authentification, les memes politiques de posture, et tous les acces sont traces dans le meme journal d'audit.

Cas 4 : Securisation d'appareils IoT et OT

Scenario : une entreprise industrielle possede des equipements IoT (capteurs, automates, cameras) qui communiquent avec un serveur central via MQTT et HTTP. Ces equipements ne peuvent pas executer le client WARP et utilisent actuellement des VPN IPsec site-to-site pour la connectivite.

Solution hybride :

• Les serveurs centraux sont exposes via Cloudflare Tunnel (cloudflared installe sur le serveur)
• Les appareils IoT dans chaque site communiquent avec un cloudflared local installe sur une gateway (Raspberry Pi, edge server) qui proxyfie les connexions TCP
• L'authentification est geree par mTLS (chaque appareil IoT possede un certificat client)
• Les politiques Access verifient le certificat client et l'adresse IP source

Cette approche elimine les VPN site-to-site tout en maintenant la connectivite IoT, avec un controle d'acces granulaire impossible a realiser avec un VPN traditionnel. Chaque flux est identifie et autorise individuellement, empechant un appareil IoT compromis de pivoter vers d'autres services.

Securite avancee : Browser Isolation, Shadow IT, DLP

Au-dela des briques fondamentales (Tunnel, Access, Gateway, WARP), Cloudflare One propose des fonctionnalites de securite avancees qui adressent des menaces sophistiquees et des exigences de conformite strictes. Comme nous l'avons explore dans notre article sur la securisation d'Active Directory, la protection des identites et des acces est un pilier fondamental de toute strategie de cybersecurite moderne.

Browser Isolation : neutraliser les menaces web

L'isolation de navigateur est l'une des techniques les plus efficaces pour neutraliser les menaces vehiculees par le web (phishing, drive-by download, exploitation de vulnerabilites navigateur, watering hole). Le principe : au lieu d'executer le code des pages web sur le poste de l'utilisateur, les pages sont rendues dans un conteneur distant isole, et seul le rendu visuel est transmis a l'utilisateur.

L'implementation de Cloudflare se distingue par son approche de "Network Vector Rendering" (NVR) : plutot que de transmettre un flux video (comme le font les solutions VDI traditionnelles, gourmandes en bande passante), Cloudflare transmet un ensemble de commandes de dessin vectoriel (similaire a un flux de commandes Canvas). Le resultat est une experience utilisateur quasi indistinguable de la navigation native, avec une consommation de bande passante moderee.

Les scenarios d'utilisation de Browser Isolation incluent :

• Isolation automatique des sites a risque : les politiques Gateway peuvent automatiquement rediriger vers l'isolation les sites classes comme "risque moyen" (sites non categorises, domaines recemment enregistres). Les sites a haut risque sont bloques, les sites de confiance sont autorises directement, et les sites intermediaires sont isoles.
• Protection contre le phishing cible : les emails contenant des liens sont renvoyes vers des sessions d'isolation, empechant l'execution de code malveillant meme si l'utilisateur clique sur le lien.
• Acces controle aux donnees sensibles : en combinant Access et Browser Isolation, vous pouvez autoriser la consultation de donnees sensibles (dashboards financiers, dossiers patients) tout en empechant le copier-coller, l'impression et le telechargement. L'utilisateur voit les donnees mais ne peut pas les exfiltrer.
• Protection des appareils non geres (BYOD) : pour les utilisateurs qui accedent depuis des appareils personnels, l'isolation garantit que les donnees d'entreprise ne sont jamais stockees localement sur l'appareil.

# Politique Gateway : isoler les sites non categorises
resource "cloudflare_teams_rule" "isolate_uncategorized" {
  account_id  = var.cloudflare_account_id
  name        = "Isolate uncategorized sites"
  description = "Route uncategorized websites through Browser Isolation"
  precedence  = 5
  action      = "isolate"
  enabled     = true

  traffic = "not any(http.request.host[*] in $trusted_domains) and http.request.host not in $corporate_domains"

  rule_settings {
    # Controles de l'isolation
    disable_copy_paste  = false  # Autoriser copier-coller
    disable_printing    = true   # Interdire impression
    disable_download    = true   # Interdire telechargement
    disable_upload      = true   # Interdire upload
    disable_keyboard    = false  # Autoriser saisie clavier
  }
}

Shadow IT Discovery : visibilite sur les applications SaaS non autorisees

Le Shadow IT — l'utilisation d'applications et de services cloud non approuves par l'equipe IT — est un probleme croissant dans les organisations modernes. Les employes adoptent spontanement des outils de productivite, de partage de fichiers ou de communication sans validation securitaire, creant des risques de fuite de donnees et de non-conformite.

Cloudflare Gateway, en inspectant le trafic DNS et HTTP de tous les utilisateurs, offre une visibilite complete sur les applications SaaS utilisees dans l'organisation. Le dashboard "Shadow IT" dans Cloudflare Zero Trust affiche :

• La liste de toutes les applications SaaS detectees, classees par categorie
• Le nombre d'utilisateurs par application
• Le volume de trafic par application
• Le score de risque de chaque application (base sur les pratiques de securite du fournisseur, la conformite, les conditions d'utilisation)
• Le statut d'approbation (approuve, non approuve, en cours de revue)

Cette visibilite permet aux equipes securite de prendre des decisions eclairees : approuver les applications utiles et securisees, bloquer les applications a risque, et migrer les utilisateurs d'alternatives non approuvees vers les outils sanctionnes. Les decisions de conformite peuvent etre enrichies par les analyses detaillees que nous decrivons dans notre guide de conformite RGPD.

Data Loss Prevention (DLP) : empecher l'exfiltration de donnees

Le composant DLP de Cloudflare One inspecte le trafic HTTP en temps reel a la recherche de donnees sensibles. Contrairement aux solutions DLP traditionnelles qui necessitent un agent lourd sur chaque poste, le DLP Cloudflare fonctionne au niveau du proxy HTTP Gateway, offrant une couverture immediate pour tous les appareils routes via WARP.

Les types de donnees detectables incluent :

• Numeros de carte bancaire : detection par regex + algorithme de Luhn pour eliminer les faux positifs
• Numeros de securite sociale : patterns francais (NIR), americains (SSN), britanniques (NIN), etc.
• Donnees medicales : detection contextuelle de termes medicaux associes a des identifiants patients
• Secrets d'API et credentials : detection de patterns typiques (AWS keys, tokens GitHub, passwords dans URLs)
• Code source : detection de snippets de code dans les requetes sortantes (protection contre l'exfiltration de propriete intellectuelle)
• Profils DLP personnalises : regex personnalisees pour les formats de donnees specifiques a votre organisation

Les actions disponibles lors d'une detection DLP sont :

• Log : enregistrer l'evenement sans bloquer la requete (mode monitoring)
• Block : bloquer la requete et afficher une page d'erreur a l'utilisateur
• Allow with warning : autoriser la requete mais notifier l'utilisateur et l'equipe securite

L'integration avec le CASB Cloudflare permet egalement d'appliquer des regles DLP aux donnees au repos dans les applications SaaS (fichiers partages publiquement dans Google Drive contenant des donnees sensibles, par exemple).

Pricing et plans : Free, Teams, Enterprise

Cloudflare Zero Trust adopte un modele de tarification progressif avec un tier gratuit particulierement genereux — une approche coherente avec la strategie historique de Cloudflare consistant a democratiser l'acces aux outils de securite. Comprendre les differences entre les plans est essentiel pour dimensionner correctement votre deploiement et maitriser les couts.

Plan Free (jusqu'a 50 utilisateurs)

Le plan gratuit de Cloudflare Zero Trust est l'un des plus genereux du marche. Il inclut :

• Cloudflare Access : jusqu'a 50 utilisateurs, nombre illimite d'applications protegees, integration IdP, politiques d'acces completes
• Cloudflare Tunnel : nombre illimite de tunnels, trafic illimite
• Cloudflare Gateway : filtrage DNS pour jusqu'a 50 utilisateurs, resolution DNS illimitee
• Client WARP : deploiement sur jusqu'a 50 appareils
• Logs : retention de 24 heures dans le dashboard

Ce plan est ideal pour les startups, les petites equipes et les projets personnels. Il permet de deployer une architecture Zero Trust complete sans aucun cout, ce qui est remarquable comparee aux solutions concurrentes (Zscaler, Palo Alto Prisma Access) dont les plans d'entree commencent generalement a plusieurs milliers d'euros par an.

Plan Zero Trust (Teams) — anciennement "Teams Standard"

Le plan payant de base est facture par utilisateur et par mois. Il ajoute au plan gratuit :

• Nombre illimite d'utilisateurs
• Filtrage HTTP (inspection TLS) en plus du filtrage DNS
• Antivirus en ligne
• Session recording pour SSH
• Device posture checks avances
• Logpush (export des logs vers SIEM externe)
• Support prioritaire
• Retention des logs etendue (30 jours)
• DLP basique (patterns predefinis)

Le cout est generalement de l'ordre de 7 dollars par utilisateur et par mois, mais les tarifs exacts varient et Cloudflare propose des remises pour les engagements annuels. Ce plan convient aux PME et aux equipes de taille moyenne (50 a 500 utilisateurs) qui ont besoin d'une protection complete sans les fonctionnalites enterprise.

Plan Enterprise

Le plan Enterprise est un contrat negocie sur mesure qui ajoute :

• Browser Isolation (incluant les controles DLP dans l'isolation)
• CASB API complet (integration avec les applications SaaS)
• DLP avance (patterns personnalises, exact data match, OCR)
• Shadow IT discovery avance
• Digital Experience Monitoring (DEM) — mesure de la qualite de l'experience utilisateur
• SLA garanti (99.99% uptime)
• Support dedie (TAM — Technical Account Manager)
• Logpush avec retention illimitee
• Integrations SIEM avancees
• Conformite (SOC2, ISO 27001, FedRAMP — selon les regions)

Le pricing Enterprise est generalement de l'ordre de 10 a 15 dollars par utilisateur et par mois, avec des variations significatives selon le volume, la duree d'engagement et les options selectionnees. La negociation directe avec l'equipe commerciale Cloudflare est necessaire pour obtenir un devis precis.

Comparaison avec les concurrents

Pour contextualiser ces tarifs, voici une comparaison approximative avec les principales solutions concurrentes :

• Zscaler ZPA + ZIA : 15-25 $/utilisateur/mois (pas de plan gratuit, minimum 100 utilisateurs generalement)
• Palo Alto Prisma Access : 20-35 $/utilisateur/mois (pas de plan gratuit)
• Netskope : 15-30 $/utilisateur/mois (pas de plan gratuit)
• Microsoft Entra Private Access : inclus dans certains plans Microsoft 365 E5, ou 6-12 $/utilisateur/mois en standalone

Cloudflare se positionne comme l'option la plus accessible, avec un plan gratuit imbattable et des tarifs competitifs en entreprise. Le principal avantage de Cloudflare reside dans l'integration native avec son reseau CDN/DDoS, eliminant le besoin de solutions separees pour la protection web. En revanche, les solutions Zscaler et Palo Alto offrent generalement des fonctionnalites DLP et CASB plus matures, et une presence plus etablie dans les grandes entreprises soumises a des exigences de conformite strictes.

Limites et inconvenients de Cloudflare Zero Trust

Aucune solution n'est exempte de limites, et l'honnetete intellectuelle commande d'examiner les faiblesses de Cloudflare Zero Trust avec la meme rigueur que ses forces. Voici les principales limites a considerer avant un deploiement.

Vendor lock-in et dependance a un fournisseur unique

En adoptant Cloudflare One comme plateforme SASE unique, vous creez une dependance significative a Cloudflare. Votre DNS, votre proxy, votre authentification d'acces, votre filtrage et votre connectivite reseau reposent sur un seul fournisseur. Si Cloudflare subit une panne majeure (ce qui est arrive, notamment l'incident de juin 2022 qui a impacte 19 datacenters), l'ensemble de votre infrastructure d'acces est affecte. Si Cloudflare decide de modifier ses tarifs, ses conditions de service ou de deprecier des fonctionnalites, vous avez peu de levier de negociation.

Mitigation : maintenez un plan de repli documentaire (configuration VPN de secours, DNS secondaire), exportez regulierement vos configurations Terraform, et evaluez periodiquement les alternatives du marche.

Latence et performance

Bien que le reseau Anycast de Cloudflare offre generalement une latence faible, l'ajout d'un proxy intermediaire entre l'utilisateur et les ressources ajoute inevitablement un overhead. Pour la majorite des applications web, cet overhead est negligeable (quelques millisecondes). Cependant, pour les applications sensibles a la latence (trading financier, jeux en temps reel, VoIP), le detour via Cloudflare peut etre problematique, notamment si le point de presence le plus proche est eloigne de l'utilisateur ou du serveur d'origine.

L'inspection TLS (break and inspect) de Gateway ajoute egalement un overhead de traitement. Pour chaque connexion HTTPS, le proxy doit dechiffrer, inspecter et rechiffrer le trafic. Sur des flux volumineux ou des applications a forte concurrence, cet overhead peut etre perceptible.

Mitigation : utilisez les split tunnels pour exclure les flux sensibles a la latence, configurez les regles "Do Not Inspect" pour les applications qui n'ont pas besoin d'inspection HTTP, et monitorez les metriques de latence via le Digital Experience Monitoring (plan Enterprise).

Conformite et souverainete des donnees (EU)

Pour les entreprises soumises au RGPD ou a des reglementations sectorielles strictes (sante, finance, defense), la question de la souverainete des donnees est critique. Le trafic qui transite par Cloudflare est traite sur le point de presence le plus proche, ce qui peut etre un datacenter situe hors de l'UE. Meme si Cloudflare est certifie ISO 27001, SOC 2 Type II et dispose de clauses contractuelles standard pour les transferts de donnees, certaines reglementations sectorielles exigent que les donnees ne quittent jamais le territoire europeen.

Cloudflare propose une option "Regional Services" qui permet de restreindre le traitement des donnees a une region geographique specifique (Europe, par exemple). Cependant, cette option est uniquement disponible sur le plan Enterprise et peut impacter les performances pour les utilisateurs situes en dehors de la region configuree.

Pour les organisations soumises a des exigences de souverainete tres strictes (OIV, operateurs de services essentiels), l'utilisation d'un fournisseur americain pour la couche de securite reseau peut etre un facteur eliminatoire, independamment des garanties techniques et contractuelles offertes.

Complexite de la configuration avancee

Si le deploiement basique de Cloudflare Zero Trust est remarquablement simple, la configuration avancee peut devenir complexe. La gestion fine des split tunnels, des exclusions TLS, des integrations IdP multiples, des regles de posture d'appareil et des politiques DLP necessite une expertise significative. La documentation Cloudflare, bien que complete, est parfois fragmentee et peut manquer d'exemples concrets pour les scenarios avances.

Les interactions entre les differentes couches de politiques (Gateway DNS, Gateway HTTP, Access, device posture) peuvent creer des comportements inattendus si les regles ne sont pas soigneusement ordonnees et testees. Un blocage DNS peut prevenir l'acces a un site qui est autorise par la politique HTTP, ou inversement.

Limitations techniques specifiques

• Protocoles non-HTTP : si Cloudflare Tunnel supporte le TCP et l'UDP generiques, l'inspection et le filtrage avances de Gateway sont principalement concus pour le trafic HTTP/HTTPS et DNS. Les protocoles applicatifs non-HTTP (SMTP, FTP, bases de donnees) transitent par le tunnel sans inspection approfondie.
• Applications avec certificate pinning : les applications qui implementent le certificate pinning (certaines applications bancaires, applications mobiles natives) sont incompatibles avec l'inspection TLS de Gateway. Elles doivent etre ajoutees aux listes "Do Not Inspect".
• Client WARP sur Linux : le client WARP pour Linux a historiquement ete en retard en termes de fonctionnalites par rapport aux clients Windows et macOS. Certaines fonctionnalites de device posture ne sont pas disponibles ou ont un support limite sur Linux.
• Limites de l'API et du dashboard : le dashboard Cloudflare Zero Trust peut devenir lent et difficile a naviguer pour les organisations qui gerent des centaines d'applications et de politiques. L'API, bien que fonctionnelle, manque parfois de documentation pour les cas d'edge.

Le modele d'inspection TLS pose question

L'inspection TLS (break and inspect) est un sujet de debat dans la communaute securite. En dechiffrant le trafic HTTPS, Cloudflare a acces au contenu en clair de toutes les communications des utilisateurs. Meme si Cloudflare s'engage contractuellement a ne pas exploiter ces donnees, le simple fait qu'un tiers ait la capacite technique d'acceder au contenu des communications est problematique pour certaines organisations, notamment celles qui manipulent des donnees classifiees ou soumises au secret professionnel (avocats, medecins).

De plus, l'installation d'un certificat racine Cloudflare sur les appareils des utilisateurs cree un point de confiance supplementaire : si la cle privee de ce certificat etait compromise (bien que stockee en HSM chez Cloudflare), un attaquant pourrait dechiffrer l'ensemble du trafic HTTPS des utilisateurs concernes. C'est un risque theorique mais qui merite consideration dans une analyse de risques complete.

FAQ : Cloudflare Zero Trust

Cloudflare Zero Trust est-il vraiment gratuit pour les petites equipes ?

Oui, le plan Free de Cloudflare Zero Trust est veritablement gratuit pour jusqu'a 50 utilisateurs, sans limitation dans le temps et sans carte bancaire requise. Ce plan inclut Cloudflare Access (nombre illimite d'applications protegees), Cloudflare Tunnel (nombre illimite de tunnels avec trafic illimite), le filtrage DNS de Gateway, et le client WARP pour jusqu'a 50 appareils. Les limitations principales du plan gratuit concernent l'absence de filtrage HTTP (inspection TLS), l'absence de DLP, l'absence de Browser Isolation, et une retention des logs limitee a 24 heures. Pour une startup ou une petite equipe de developpeurs, ce plan gratuit offre une couverture de securite Zero Trust remarquablement complete. A titre de comparaison, les concurrents directs (Zscaler, Palo Alto Prisma Access) n'offrent aucun plan gratuit et ciblent principalement les entreprises de plus de 100 utilisateurs.

Cloudflare Tunnel peut-il remplacer completement un VPN d'entreprise ?

Dans la majorite des cas, oui. Cloudflare Tunnel combine avec Access peut remplacer un VPN pour l'acces aux applications web internes, aux services SSH et RDP, aux API et meme aux bases de donnees (via le tunnel TCP). L'experience utilisateur est generalement superieure a celle d'un VPN : connexion instantanee, pas de client VPN lourd a installer (pour les applications web), authentification contextuelle, et acces granulaire par application plutot qu'un acces reseau large. Cependant, il existe des scenarios ou un VPN reste necessaire : l'acces a des protocoles reseau de bas niveau (ICMP, multicast), certaines applications legacy qui necessitent un acces reseau complet (ex: partages de fichiers SMB sans passerelle web), ou les environnements air-gapped qui ne peuvent pas etablir de connexion sortante vers Internet. Pour ces cas d'edge, une approche hybride (Cloudflare Tunnel pour la majorite des acces + VPN residuel pour les cas specifiques) est recommandee.

Comment Cloudflare Zero Trust gere-t-il la haute disponibilite ?

La haute disponibilite est assuree a plusieurs niveaux. Au niveau du reseau, Cloudflare exploite plus de 310 points de presence interconnectes par un reseau Anycast : si un datacenter tombe en panne, le trafic est automatiquement reroute vers le datacenter suivant le plus proche, sans intervention manuelle et sans interruption perceptible par l'utilisateur. Au niveau des tunnels, chaque daemon cloudflared etablit par defaut quatre connexions vers deux datacenters differents. Si un datacenter ou une connexion echoue, les trois connexions restantes prennent le relai. Pour une haute disponibilite cote serveur d'origine, vous pouvez deployer plusieurs instances de cloudflared pour le meme tunnel sur des serveurs differents (en utilisant le meme tunnel token), et Cloudflare repartira le trafic entre les instances actives. Au niveau de l'authentification, Access met en cache les sessions des utilisateurs (JWT), donc une panne temporaire de l'IdP n'interrompt pas les sessions en cours (seules les nouvelles authentifications echouent).

L'inspection TLS de Gateway est-elle compatible avec toutes les applications ?

Non, l'inspection TLS (break and inspect) n'est pas compatible avec toutes les applications. Les applications qui implementent le certificate pinning (verification que le certificat presente correspond a un certificat predefini) rejetteront la connexion car le certificat presente par le proxy Gateway ne correspond pas au certificat attendu. C'est courant pour les applications bancaires, certaines applications mobiles natives, et les clients de messagerie. De meme, les applications qui utilisent des protocoles TLS non-standard ou des extensions TLS rares peuvent rencontrer des problemes de compatibilite. Cloudflare fournit une liste maintenue de domaines a exclure automatiquement de l'inspection TLS ("Do Not Inspect" defaults), et vous pouvez ajouter vos propres exclusions. En pratique, environ 5 a 10% des domaines necessitent une exclusion de l'inspection TLS, principalement des services financiers, des applications gouvernementales et des applications mobiles natives.

Peut-on utiliser Cloudflare Zero Trust avec plusieurs fournisseurs d'identite simultanement ?

Oui, Cloudflare Access supporte la configuration simultanee de plusieurs fournisseurs d'identite (IdP). Lors de l'acces a une application protegee, l'utilisateur voit une page de connexion qui liste tous les IdP configures et peut choisir celui qu'il souhaite utiliser. C'est une fonctionnalite essentielle pour les organisations qui doivent accueillir differentes populations d'utilisateurs : les employes internes s'authentifient via Azure AD ou Okta de l'entreprise, les prestataires externes utilisent leur propre IdP federe ou un OTP par email, et les partenaires commerciaux utilisent un IdP specifique negocie dans le cadre du partenariat. Les politiques Access peuvent specifier quel IdP est requis pour chaque application ou chaque regle, permettant par exemple d'exiger Azure AD pour les applications sensibles et d'accepter l'OTP pour les applications a faible risque. Il est egalement possible de configurer des IdP differents par application, limitant les options d'authentification a celles pertinentes pour chaque contexte.

Comment monitorer la sante et les performances de Cloudflare Tunnel en production ?

Le monitoring de Cloudflare Tunnel peut se faire a plusieurs niveaux. Le dashboard Cloudflare Zero Trust affiche l'etat de chaque tunnel (actif, degrade, inactif), le nombre de connexions actives et les metriques de trafic. Le daemon cloudflared expose des metriques Prometheus sur un endpoint local (configurable via le parametre metrics dans config.yml, par defaut localhost:2000/metrics). Ces metriques incluent le nombre de requetes traitees, les latences, les erreurs et l'etat des connexions vers les datacenters Cloudflare. Vous pouvez les collecter avec Prometheus et les visualiser dans Grafana. En complement, Cloudflare Logpush permet d'exporter les logs d'acces en temps reel vers votre SIEM pour une analyse centralisee. Pour les alertes, vous pouvez configurer des notifications Cloudflare (via le dashboard ou l'API) pour etre prevenu en cas de tunnel down, de degradation de performance ou de changement d'etat. Enfin, le Digital Experience Monitoring (DEM), disponible sur le plan Enterprise, offre une vision de bout en bout de l'experience utilisateur, mesurant la latence a chaque etape du parcours (client WARP, reseau Cloudflare, tunnel, serveur d'origine).

Cloudflare Zero Trust est-il conforme au RGPD et adapte aux entreprises europeennes ?

Cloudflare est conforme au RGPD et fournit les mecanismes contractuels requis pour les transferts de donnees (clauses contractuelles standard, Data Processing Agreement). Pour les entreprises qui exigent que les donnees restent en Europe, l'option "Regional Services" (plan Enterprise) permet de restreindre le traitement des donnees aux datacenters europeens de Cloudflare. Cependant, il est important de noter que Cloudflare est une entreprise americaine soumise au CLOUD Act, ce qui theoriquement permet aux autorites americaines de demander l'acces aux donnees stockees par Cloudflare, meme si elles sont localisees en Europe. Cette question juridique, qui est au coeur du debat Schrems II, n'est pas specifique a Cloudflare — elle s'applique a tous les fournisseurs cloud americains (AWS, Azure, GCP). Pour les organisations qui ont des exigences de souverainete tres strictes (OIV francais, institutions financieres reglementees, sante), il est recommande de mener une analyse d'impact sur la protection des donnees (DPIA) specifique a l'utilisation de Cloudflare et de consulter votre DPO. Des alternatives europeennes existent pour certaines briques (mais pas avec le meme niveau d'integration et de performance globale).

Quelle est la difference entre Cloudflare WARP (grand public) et Cloudflare WARP (Zero Trust) ?

Cloudflare propose deux versions du client WARP qui partagent le meme logiciel mais fonctionnent dans des modes differents. WARP (grand public), disponible gratuitement sous le nom "1.1.1.1" sur les stores d'applications, est un VPN personnel qui chiffre le trafic DNS et HTTP de l'utilisateur vers le reseau Cloudflare, offrant une protection de la vie privee et un DNS securise. Il n'y a pas de dashboard d'administration, pas de politiques de filtrage et pas de controle d'acces — c'est un outil de protection individuelle. WARP (Zero Trust), aussi appele "WARP for Teams", utilise le meme client mais en mode "Gateway with WARP". Lorsqu'un appareil est enregistre (enrolled) aupres d'une organisation Cloudflare Zero Trust, le trafic est route vers le tenant Zero Trust de l'organisation, soumis aux politiques Gateway, et les informations de posture de l'appareil sont collectees. L'administrateur controle la configuration via le dashboard Zero Trust, peut forcer le mode always-on, bloquer la desinscription et appliquer des split tunnels specifiques. Les deux modes ne peuvent pas coexister sur le meme appareil — un appareil est soit en mode personnel, soit en mode organisationnel.

Conclusion

Le modele Zero Trust n'est plus une option — c'est une necessite dictee par l'evolution des menaces, la dissolution du perimetre reseau et la generalisation du travail distribue. Cloudflare, en s'appuyant sur son infrastructure reseau mondiale, a reussi le pari de democratiser ce modele avec Cloudflare One, une plateforme SASE qui combine Cloudflare Tunnel pour la connectivite sans port ouvert, Access pour l'authentification contextuelle, Gateway pour le filtrage DNS et HTTP, WARP pour la securite endpoint, et des briques avancees (Browser Isolation, DLP, CASB) pour les organisations aux exigences les plus elevees.

La force de Cloudflare Zero Trust reside dans trois piliers : l'accessibilite (plan gratuit pour 50 utilisateurs, documentation exhaustive, deploiement rapide), la performance (reseau Anycast de 310+ PoPs, latence minimale, protocole QUIC), et l'integration native (une plateforme unique, une console unique, des politiques coherentes transversales). Pour la majorite des PME et des equipes techniques, Cloudflare Zero Trust represente le meilleur rapport fonctionnalites/cout/complexite du marche.

Cependant, les organisations doivent evaluer lucidement les limites : le vendor lock-in inherent a l'adoption d'une plateforme unique, les questions de souverainete des donnees pour les entreprises europeennes soumises a des reglementations strictes, la maturite encore perfectible de certaines briques (DLP, CASB) par rapport aux leaders specialises, et la complexite potentielle des configurations avancees. L'approche de securite en profondeur que nous preconisons dans notre article sur la defense en profondeur reste pertinente : Cloudflare Zero Trust doit etre un composant d'une strategie de securite plus large, pas une solution unique et isolee.

Le passage au Zero Trust est un voyage, pas une destination. Commencez par identifier vos applications les plus critiques, deployer un premier tunnel, configurer les premieres politiques Access, puis etendez progressivement la couverture en ajoutant le filtrage Gateway, le client WARP et les regles de posture. A chaque etape, mesurez l'impact sur la securite et sur l'experience utilisateur. La beaute de l'approche Cloudflare est qu'elle permet ce deploiement progressif sans bouleverser l'existant — chaque brique ajoute une couche de securite supplementaire sans casser ce qui fonctionne deja. Et pour ceux qui souhaitent approfondir les fondamentaux de la securite reseau, notre guide des fondamentaux de la securite reseau offre un complement ideal a cet article.