Cloudflare One

Avant de citer des limites, des paramètres, des champs API, des identifiants de catégorie ou des chemins exacts dans l'interface, récupérez les informations actuelles sur la documentation Cloudflare One, le serveur MCP de documentation Cloudflare ou le schéma API Cloudflare.

Workflow

1. Classifiez la demande : architecture, configuration, dépannage, migration ou examen.
2. Rassemblez le contexte : ID de compte, utilisateurs/sites/applications, fournisseur d'identité, synchronisation SCIM/groupes, gestion des appareils, chemin du trafic, contraintes de conformité et rayon de souffle du déploiement.
3. Récupérez uniquement la documentation actuelle nécessaire pour les produits impliqués : Access, Gateway, WARP/client appareil, Tunnel/Mesh, Cloudflare WAN, DLP, CASB, device posture ou identité.
4. Si l'accès au compte est disponible, inspectez les ressources existantes avant de proposer ou d'effectuer des modifications : applications Access/politiques/groupes/IdPs, règles Gateway/listes/catégories, profils appareil/vérifications posture, tunnels/routes, paramètres DNS/résolveur et sites/emplacements.
5. Proposez l'ensemble des changements avec les prérequis, la validation et la procédure de restauration. Pour les changements risqués, testez en mode désactivé ou limité à un groupe pilote/site, sauf si l'utilisateur demande explicitement le contraire.

Invites d'évaluation

Utilisez-les pour éviter de sauter directement à la configuration. Posez uniquement les questions pertinentes pour la tâche de l'utilisateur.

Architecture et état actuel

• Sites et utilisateurs : bureaux, succursales, centres de données, VPCs, utilisateurs distants, sous-traitants, nombre d'utilisateurs et modèle de connectivité actuel.
• Applications et destinations : SaaS, applications publiques, applications privées, APIs, cibles d'infrastructure, protocoles, ports, noms d'hôte et plages IP.
• Connectivité : VPN, MPLS, SD-WAN, sortie Internet directe, backhaul centralisé, besoins site-à-site et architecture DNS privée.
• Stack de sécurité : SWG, NGFW, VPN/ZTNA, DLP, CASB, sécurité e-mail, journalisation et exigences de conformité actuels.
• Identité : IdP, synchronisation SCIM/groupes, nommage des groupes, besoins multi-IdP, comptes de service et accès des sous-traitants/partenaires.
• Déploiement : utilisateurs/sites pilotes, rayon de souffle, chemin de restauration, propriétaires du support et critères de succès.

Access et fédération SaaS

• Forme de l'application : application web, API, SSH/RDP/VNC, base de données, application SaaS, nom d'hôte public, IP privée ou nom d'hôte privé. Récupérez la documentation du type d'application Access avant de choisir.
• Modèle d'accès : accès navigateur sans client, réseau privé avec client appareil, connectivité pair-à-pair, connexions de service avec jetons de service ou TLS mutuel, ou fédération SSO SaaS.
• Besoins de politique : groupes d'utilisateurs, device posture, durée de session, mTLS, jetons de service et visibilité du lanceur d'applications. Récupérez la documentation de la politique Access avant de configurer les sélecteurs ou l'ordre d'évaluation.
• Détails SaaS : support SAML vs OIDC, URLs ACS/redirection, Entity IDs/client IDs, attributs requis et exigences de contrôle des locataires.

Tunnel et réseau privé

• Sites et segments : quels centres de données, VPCs, bureaux ou segments réseau ont besoin de connectivité.
• HA : connecteur unique pour dev/test, connecteurs multiples en production ou redondance avancée multi-tunnel/multi-site.
• Runtime : où cloudflared ou WARP Connector/Mesh s'exécuteront : VM, conteneur, Kubernetes, bare metal ou autre cible.
• Sortie : si les connecteurs peuvent atteindre Cloudflare sur les ports/protocoles de sortie requis. Récupérez les vérifications préalables de connectivité Tunnel avant de nommer les points d'extrémité exacts.
• Accessibilité de l'origine : si le connecteur peut résoudre et atteindre chaque origine privée.
• Routage : CIDRs/noms d'hôte requis, espaces d'adressage qui se chevauchent, réseaux virtuels, Split Tunnels et besoins de DNS privé/politique résolveur.
• Modèle de gestion : préférez les tunnels gérés à distance/basés sur jeton pour les nouveaux déploiements, sauf s'il existe une raison claire pour une configuration locale.

Gateway, TLS et DLP

• Contrôles de trafic : catégories DNS, inspection HTTP URL/chemin, ports/protocoles L4, exigences d'IP de sortie, listes personnalisées et exceptions allow/block. Récupérez la documentation de la politique de trafic Gateway pour les sélecteurs actuels et l'ordre d'application.
• Identité : si les politiques Gateway ont besoin de sélecteurs d'utilisateur ou de groupe, et si les utilisateurs seront authentifiés via le contexte WARP/IdP. Vérifiez les sélecteurs d'identité Gateway et la configuration SCIM quand les groupes sont impliqués.
• Inspection TLS : chemin de déploiement de l'autorité de certification racine, applications avec certificat épinglé, exceptions de conformité et exigences FIPS. Récupérez la documentation du déchiffrement TLS avant d'activer.
• DLP : types de données sensibles, canaux à inspecter, préparation à l'inspection TLS, profils DLP, exigences de journalisation de payload et tolérance aux faux positifs. Récupérez la documentation DLP avant de créer une application.

CASB, Device Posture et risque

• CASB : fournisseurs SaaS, niveau d'accès administrateur, politique de scan, taille de l'organisation, propriétaire de la correction et si une protection inline est également requise. Récupérez la documentation des conclusions CASB avant de recommander une correction.
• Device posture : vérifications requises, intégrations EDR/MDM tiers, règles d'inscription, profils appareil et alignement split tunnel.
• Scoring de risque : signaux de comportement pertinents, sources de faux positifs tels que les VPNs ou les comptes de service, et si le risque est pour l'investigation ou l'application. Récupérez la documentation du score de risque utilisateur avant d'utiliser le risque dans les politiques.

Cloudflare WAN / Connectivité de site

• Topologie du site, type de point d'entrée, propriété des routes, redondance des tunnels, routes gérées statiquement vs BGP, besoins de pare-feu réseau et propriété des appliances/profils. Récupérez la documentation de Cloudflare WAN et du Pare-feu réseau Cloudflare avant de proposer des changements de connectivité de site.

Garde-fous

• Les contrôles d'accès gèrent l'autorisation des applications ; Gateway gère l'inspection/filtrage du trafic. Utilisez les deux quand la exigence couvre l'accès aux applications conscient de l'identité et la sécurité réseau/web.
• Les applications Access avec nom d'hôte public peuvent être sans client. Les applications de destination privée nécessitent WARP/client appareil ou un autre point d'entrée réseau plus des routes et une résolution DNS. Récupérez la documentation de l'application privée auto-hébergée avant de configurer les destinations privées.
• Cloudflare Tunnel est une sortie d'un réseau privé vers Cloudflare. Cloudflare WAN et Mesh sont d'autres sorties qui peuvent aussi être des points d'entrée.
• Les politiques basées sur les groupes dépendent des réclamations de groupe IdP ou SCIM. Si la synchronisation de groupe est manquante, n'inventez pas de sélecteurs de groupe.
• Les noms d'hôte privés ont besoin d'un routage/résolution DNS explicite ; créer une application Access seule n'est pas suffisant. Utilisez les politiques résolveur et consultez Connecter un nom d'hôte privé
• L'inspection HTTP et DLP pour le trafic web chiffré nécessitent l'inspection TLS et des exceptions planifiées Do Not Inspect.
• Les politiques Gateway DNS, Network, HTTP et Egress ont une sémantique d'évaluation différente. Récupérez la documentation de l'ordre d'application avant d'expliquer la précédence.
• Commencez par des politiques large block/allow/DLP/TLS désactivées et limitées à un pilote avec des utilisateurs ou groupes cibles spécifiques, sauf si l'utilisateur approuve un déploiement plus large.

Identité et accès

• Access Groups sont des objets Cloudflare ; les groupes IdP/SCIM sont des réclamations d'identité. Les sélecteurs de groupe Gateway utilisent les groupes IdP synchronisés, pas les Access Groups.
• Les noms de groupe et les attributs SAML/OIDC sont sensibles à la casse. Vérifiez les noms et valeurs de réclamation exacts avant de créer des règles basées sur les groupes.
• Les changements SCIM et l'adhésion au groupe peuvent être obsolètes jusqu'à ce que la synchronisation et la réauthentification se terminent. Dépannez avec la dernière identité authentifiée de l'utilisateur, pas seulement l'état IdP.
• Les politiques Access sont deny-by-default. Une application privée avec des routes mais sans politique Allow bloque quand même l'accès.
• Les sélecteurs de politique Access peuvent utiliser des listes d'IP, pas des listes de domaines ou d'URLs Gateway.
• La fédération SaaS gère l'authentification dans l'application SaaS. L'autorisation SaaS et les restrictions de locataire nécessitent généralement des rôles côté SaaS et/ou des contrôles de locataire Gateway.
• Browser Rendering pour SSH/VNC/RDP est une capacité Access. Browser Isolation affiche le contenu web général à distance. Ne les confondez pas.

Déploiement du client appareil

• Le client Cloudflare One est le point d'entrée pour les appareils utilisateur. Deux composants le contrôlent : règles d'inscription (qui peut se connecter) et profils appareil (comment le client se comporte après l'inscription).

• La règle d'inscription est une application Access de type warp, pas un paramètre appareil. Elle accepte des politiques Access réutilisables. Cherchez dans Access pour déboguer l'inscription, pas dans Devices.

• Pour les appareils sans interface ou autonomes (services, kiosques, hôtes Linux), utilisez l'inscription par jeton de service. Les appareils non-humains s'authentifient sous non_identity@[team-domain].cloudflareaccess.com et n'ont pas d'adhésion à un groupe - les profils appareil ciblant les groupes IdP ne leur correspondront pas. Ciblez explicitement les appareils sans interface avec l'e-mail non-identité, des conventions spécifiques sur les appareils (informations OS, etc.) ou laissez-les tomber sur le profil par défaut.

• Les profils appareil contrôlent le mode de connexion, la configuration du split tunnel, les permissions utilisateur (désactiver, verrouillage du commutateur), reconnexion automatique et comportement du portail captif. Les profils sont appariés par groupe d'utilisateur ou attributs appareil par ordre de précédence - le premier correspondant gagne, le profil par défaut rattrape le reste.

• Le mode split tunnel est le paramètre client le plus impactant. Choisissez le mode selon l'objectif du déploiement :

  Objectif	Mode	Justification
  Remplacement VPN uniquement (applications privées)	Include	Acheminez uniquement les CIDRs et noms d'hôte privés spécifiés via le client. Tout le reste va directement. Rayon de souffle minimal.
  SWG uniquement (sécurité Internet)	Exclude	Tout le trafic via le client. Excluez seulement ce qui casse (imprimantes locales, applications avec certificat épinglé).
  Remplacement VPN + SWG	Exclude	Tout le trafic via le client. Configuration d'entreprise la plus courante.
  Coexistence avec un autre VPN	Include	Évite le conflit avec l'interface tunnel et le contrôle DNS de l'autre VPN.
  Filtrage DNS uniquement	Mode DNS uniquement	Seules les requêtes DNS vont à Gateway. Pas de proxying de trafic.

• Include vs exclude est par-profil, pas par-entrée. Vous ne pouvez pas mélanger les modes dans le même profil. Changer les modes en milieu de déploiement nécessite de réévaluer chaque entrée.

• Les entrées split tunnel doivent s'aligner avec les routes de tunnel de manière bidirectionnelle. Un CIDR dans la liste include sans route tunnel correspondante crée un trou noir. Une route tunnel sans entrée de profil appareil correspondante signifie que le trafic n'entre jamais dans le tunnel.

• Les paramètres MDM (mdm.xml / préférences gérées) remplacent les paramètres de profil configurés au tableau de bord pour tout paramètre spécifié dans le fichier. Si les modifications du tableau de bord semblent n'avoir aucun effet sur les appareils gérés, vérifiez la configuration MDM. Récupérez la documentation du déploiement MDM pour les emplacements de fichiers et paramètres spécifiques à la plateforme.

• Si un autre client VPN ou agent contrôle le DNS sur l'appareil, l'interception DNS du client appareil entrera en conflit. Dans les scénarios de coexistence, utilisez le mode « trafic uniquement » pour éviter les conflits de table de routage et DNS.

• La détection de portail captif déconnecte temporairement le client quand il détecte un portail (WiFi hôtel, aéroport). C'est une source courante de friction pour les utilisateurs finaux et doit être gérée avec soin.

Réseau privé

• Le changement de mode split tunnel change le sens de chaque décision de routage : le mode Exclude envoie le trafic à Cloudflare quand supprimé des exclusions ; le mode Include envoie le trafic uniquement quand ajouté aux inclusions.
• Les réseaux virtuels doivent être utilisés principalement quand les sous-réseaux IP se chevauchent et le routage basé sur le nom d'hôte n'est pas utilisé. Il peut être utilisé pour contrôler d'autres comportements de connectivité utilisateur, mais il est recommandé de gérer via les politiques de sécurité.
• Un tunnel sain prouve seulement que cloudflared peut atteindre Cloudflare. Le tunnel doit avoir des routes d'application publiées, routes réseau ou routes de nom d'hôte appropriées pour que la connectivité fonctionne.
• Cloudflare Tunnel et Cloudflare Mesh peuvent tous deux être utilisés pour faciliter la connectivité aux réseaux internes. Cloudflare WAN peut aussi, mais c'est limité aux abonnements Enterprise. Récupérez choisir un point d'entrée quand vous délibérez entre les types de Tunnel.
• Exécutez plusieurs connecteurs cloudflared pour la HA en production, de préférence sur des hôtes séparés. Les tunnels gérés à distance basés sur jeton sont l'option par défaut pour les nouveaux déploiements.

Gateway, TLS et DLP

• dns.domains correspond à un domaine et ses sous-domaines ; dns.fqdn ne correspond qu'à la correspondance exacte.
• Les sélecteurs de pré-résolution DNS et les sélecteurs de post-résolution ne se comportent pas comme une seule liste stricte de précédence. Récupérez la documentation d'évaluation actuelle avant de changer l'ordre des règles.
• Les règles HTTP Do Not Inspect s'exécutent avant les comportements HTTP Allow/Block/Isolate. Une règle de blocage plus tardive ne remplacera pas un contournement d'inspection antérieur.
• Les applications avec certificat épinglé ont besoin des exceptions Do Not Inspect avant l'inspection TLS large. Déployez l'autorité de certification racine Cloudflare sur les appareils gérés avant d'activer l'inspection.
• Les profils DLP sont des définitions de détection uniquement. Ils ne font rien tant qu'ils ne sont pas référencés par les politiques HTTP Gateway ou les paramètres de scan CASB. Les règles avec inspection de corps peuvent être évaluées plusieurs fois en une seule passe.
• Commencez DLP avec la journalisation de payload si approprié, ajustez les faux positifs, puis bloquez.
• Les politiques Gateway Network sont des contrôles L4 stricts. La correspondance L4 consciente de l'identité nécessite le contexte d'appareil authentifié.

CASB, risque et opérations

• CASB API est hors-bande et périodique. Il ne fournit pas d'application inline en temps réel, bien que certaines intégrations supportent la « correction » ; utilisez les contrôles d'application granulaires Gateway pour la capacité CASB inline pour les applications supportées. Récupérez les contrôles d'application granulaires quand vous créez des politiques de sécurité pour des actions spécifiques dans des applications SaaS spécifiques.
• Les conclusions CASB sont liées à des ressources et instances spécifiques. Analysez les ressources affectées avant de recommander une correction.
• Utilisez les directives de correction du tableau de bord actuel pour les correctifs CASB. La plupart des corrections se produisent dans la console admin SaaS, pas Cloudflare.
• Les grandes intégrations SaaS peuvent prendre 24-48 heures pour les scans initiaux. La réautorisation peut redémarrer l'état du scan ; vérifiez la santé des credentials avant de vous reconnecter.
• Les scores de risque utilisateur sont basés sur le comportement et asynchrones. Les conclusions CASB n'impliquent pas automatiquement un risque utilisateur élevé.

Infrastructure Access

• Zero Trust Infrastructure Access (ZTIA) est l'offre conçue à cet effet pour l'accès SSH via le client appareil. Elle fournit des capacités non disponibles via les applications auto-hébergées : journalisation des touches, contrôle de la manière dont les utilisateurs s'authentifient sur la machine cible, certificats éphémères qui remplacent les clés SSH statiques par des certificats éphémères liés à l'identité Access, et gestion d'accès privilégié léger. Utilisez les applications Infrastructure Access pour SSH quand le client appareil est déployé.
• Browser Rendering fournit SSH, RDP et VNC sans client via le navigateur sans exiger le client appareil. RDP sans client inclut l'enregistrement de session et les contrôles de transfert de fichiers. Utilisez l'accès sans client quand un client appareil ne peut pas être installé (sous-traitants, accès partenaire, appareils non gérés) - généralement pas comme l'option par défaut pour les utilisateurs gérés avec le client installé.
• Audit SSH est une action de politique Gateway Network qui journalise les commandes SSH sans bloquer. Elle nécessite que la session soit proxifiée via Cloudflare.
• Les certificats éphémères nécessitent la configuration de l'autorité de certification sur l'hôte cible et sshd configuré pour faire confiance à la clé publique de l'autorité de certification Cloudflare. Récupérez la documentation de configuration des certificats éphémères avant de configurer.
• Pour l'accès kubectl et base de données derrière les réseaux privés, utilisez le client appareil avec le routage de destination privée. Il n'existe pas actuellement d'équivalent Infrastructure Access ou rendu navigateur pour les protocoles TCP arbitraires.

Logs, analytiques et DEX

• Les journaux d'activité Gateway enregistrent les décisions de politique DNS, HTTP et Network. Filtrez par nom de règle, identité d'utilisateur, destination, action et plage de temps. Ce sont l'outil de dépannage principal pour « pourquoi cela a-t-il été bloqué/autorisé. »
• Les journaux d'audit Access enregistrent les décisions d'authentification par application - qui s'est authentifié, quelle politique correspond et détails de session. Utilisez pour vérifier le comportement de la politique et enquêter sur les défaillances d'accès.
• La découverte Shadow IT utilise les journaux HTTP Gateway pour mettre en évidence les applications SaaS non gérées. Nécessite l'inspection TLS pour la visibilité HTTPS.
• DEX (Digital Experience Monitoring) fournit les diagnostiques de connectivité au niveau de la flotte et par appareil. Utilisez les tests DEX (HTTP, traceroute) pour surveiller proactivement l'accessibilité vers les origines critiques et les applications internes. L'état de la flotte montre la santé du client appareil, le mode de connexion et l'état de connectivité dans la population inscrite.
• Logpush exporte les journaux Gateway, Access, Network et DEX vers un SIEM ou stockage externe. Configurez avant le lancement si le client demande une rétention de journal centralisée ou la création de rapports de conformité.
• Lors du dépannage, travaillez à partir des journaux vers la configuration : identifiez l'entrée de journal montrant la défaillance (blocage Gateway, accès refusé, erreur tunnel, manque de résolution DNS), puis tracez en arrière jusqu'à la règle, route ou politique responsable.

Cloudflare WAN / Connectivité de site

• Cloudflare WAN est la connectivité, pas un service de sécurité. Appliquez l'inspection et la politique avec Gateway et le Pare-feu réseau si nécessaire.
• Les expressions du pare-feu WAN ne sont pas le même langage que les expressions wirefilter de Gateway. Récupérez la syntaxe actuelle avant de modifier.
• Les PSKs IPsec générés et certains secrets OAuth/client sont retournés une seule fois. Stockez-les immédiatement.

Résultats par défaut

• Conceptions : hypothèses actuelles, architecture cible, responsabilités des produits, phases de déploiement, validation et décisions ouvertes.
• Travail de configuration : prérequis, ressources exactes à inspecter/créer/modifier, cas de test et restauration.
• Dépannage : chemin du trafic, point de défaillance probable, preuves à collecter et test suivant.

Invites de validation

• Access : testez les flux autorisés, non autorisés, posture-échouant, jeton de service et multi-IdP le cas échéant ; inspectez les journaux et la précédence des politiques.
• Accès réseau privé : vérifiez la recherche de route, la santé du tunnel, l'accessibilité de l'origine, le comportement split tunnel, la résolution DNS et l'accès de bout en bout à partir d'un appareil test client appareil.
• Gateway : vérifiez le type de règle, l'action, l'expression du trafic, la précédence/phase d'évaluation, les listes référencées et les paramètres Gateway avant d'activer largement.
• TLS/DLP : testez les exceptions Do Not Inspect et la confiance de l'autorité de certification racine avant d'activer l'inspection ; testez DLP avec des exemples connus et surveillez les faux positifs avant de bloquer.
• CASB/risque : confirmez la santé de l'intégration, l'expiration des credentials, la découverte des ressources, le calendrier de scan, les instances de conclusions et la latence du signal de score de risque avant de déclarer la correction complète.
• Cloudflare WAN : vérifiez la santé du tunnel, la priorité/propriété des routes, le flux du trafic, la syntaxe de l'expression du pare-feu et la télémétrie du connecteur/appliance le cas échéant.

Sécurité des API

• Utilisez les noms d'outil MCP pleinement qualifiés quand les outils MCP sont disponibles.
• Ne devinez jamais les identifiants de catégorie, identifiants d'application, champs wirefilter ou corps de requête API. Récupérez le schéma/documentation actuel et les objets de compte existants.
• N'activez pas les politiques de production large sans approbation explicite.