Cloudflare One

Que fait Cloudflare One ?

Avant de citer des limites, des paramètres, des champs d'API, des ID de catégorie ou des chemins d'interface utilisateur exacts, récupérez les informations à jour dans la documentation Cloudflare One, le serveur MCP de la documentation Cloudflare, ou le schéma d'API Cloudflare.

Workflow

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

Prompts d'évaluation

Utilisez-les pour éviter de passer 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, VPC, utilisateurs distants, sous-traitants, nombre d'utilisateurs et modèle de connectivité actuel.
• Applications et destinations : SaaS, applications publiques, applications privées, API, cibles d'infrastructure, protocoles, ports, noms d'hôte et plages IP.
• Connectivité : VPN, MPLS, SD-WAN, accès direct à Internet, backhaul centralisé, besoins site à site et architecture DNS privée.
• Stack de sécurité : SWG actuel, NGFW, VPN/ZTNA, DLP, CASB, sécurité des e-mails, journalisation et exigences de conformité.
• Identité : IdP, synchronisation SCIM/groupes, conventions de nommage des groupes, besoins multi-IdP, comptes de service et accès des sous-traitants/partenaires.
• Déploiement : utilisateurs/sites pilotes, rayon d'impact, chemin de retour arrière, propriétaires du support et critères de succès.

Accès et fédération SaaS

• Type d'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é. Consultez la documentation sur le type d'application Access avant de choisir.
• Modèle d'accès : accès via navigateur sans client, réseau privé avec client d'appareil, connectivité peer to peer, connexions de service avec jetons de service ou TLS mutuel, ou fédération SSO SaaS.
• Besoins en politique : groupes d'utilisateurs, posture de l'appareil, durée de session, mTLS, jetons de service et visibilité du lanceur d'applications. Consultez la documentation sur les politiques Access avant de configurer les sélecteurs ou l'ordre d'évaluation.
• Détails SaaS : prise en charge SAML vs OIDC, URL ACS/redirection, ID d'entité/ID client, attributs requis et exigences de contrôle du locataire.

Tunnel et réseau privé

• Sites et segments : quels centres de données, VPC, bureaux ou segments réseau ont besoin de connectivité.
• HA : connecteur unique dev/test, plusieurs connecteurs de production, ou redondance multi-tunnel/site avancée.
• Environnement d'exécution : où cloudflared ou WARP Connector/Mesh seront exécutés : VM, conteneur, Kubernetes, bare metal ou autre cible.
• Sortie : si les connecteurs peuvent atteindre Cloudflare via les ports/protocoles sortants requis. Consultez les vérifications préalables de connectivité Tunnel avant de nommer les points de terminaison exacts.
• Accessibilité de l'origine : si le connecteur peut résoudre et atteindre chaque origine privée.
• Routage : CIDR/noms d'hôte requis, espaces IP qui se chevauchent, réseaux virtuels, Split Tunnels, et besoins en DNS privé/politique de résolveur.
• Modèle de gestion : privilégiez les tunnels gérés à distance/basés sur des jetons 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 des URL/chemins HTTP, ports/protocoles L4, exigences d'IP de sortie, listes personnalisées et exceptions d'autorisation/blocage. Consultez la documentation sur les politiques de trafic Gateway pour les sélecteurs actuels et l'ordre d'application.
• Identité : si les politiques Gateway ont besoin de sélecteurs d'utilisateurs ou de groupes, et si les utilisateurs seront authentifiés via le contexte WARP/IdP. Vérifiez les sélecteurs d'identité Gateway et le provisionnement SCIM lorsque des groupes sont impliqués.
• Inspection TLS : chemin de déploiement du CA racine, applications avec certificats épinglés, exceptions de conformité et exigences FIPS. Consultez la documentation sur le déchiffrement TLS avant d'activer.
• DLP : types de données sensibles, canaux à inspecter, préparation à l'inspection TLS, profils DLP, exigences de journalisation des charges utiles et tolérance aux faux positifs. Consultez la documentation DLP avant de créer une application.

CASB, posture de l'appareil et risque

• CASB : fournisseurs SaaS, niveau d'accès administrateur, politique d'analyse, taille de l'organisation, responsable de la correction, et si une protection en ligne est également requise. Consultez la documentation sur les résultats CASB avant de recommander une correction.
• Posture de l'appareil : vérifications requises, intégrations EDR/MDM tierces, règles d'inscription, profils d'appareil et alignement du split tunnel.
• Score de risque : signaux de comportement pertinents, sources de faux positifs telles que les VPN ou les comptes de service, et si le risque est destiné à une enquête ou à une application. Consultez la documentation sur le score de risque utilisateur avant d'utiliser le risque dans les politiques.

Cloudflare WAN / Connectivité de site

• Topologie du site, type d'accès, propriété des routes, redondance des tunnels, routes statiques vs gérées par BGP, besoins du pare-feu réseau, et propriété des appareils/profils. Consultez la documentation Cloudflare WAN et Cloudflare Network Firewall avant de proposer des modifications de la connectivité du site.

Garde-fous

• Access contrôle l'autorisation des applications ; Gateway contrôle l'inspection et le filtrage du trafic. Utilisez les deux lorsque l'exigence couvre l'accès aux applications avec identification et la sécurité du réseau/web.
• Pour les nouveaux déploiements Access, créez des politiques via l'API de politique réutilisable (/access/policies) et attachez-les aux applications. N'envoyez pas de politiques en ligne dans une requête de création/mise à jour d'application, sauf si la documentation actuelle de l'API l'exige explicitement pour une politique spécifique à l'application.
• Traitez une politique spécifique à une application signalée comme reusable: false comme héritée. Migrez les politiques existantes avec le point de terminaison make_reusable documenté ou remplacez-les par des politiques réutilisables ; ne créez pas de nouvelles politiques héritées. Distinguez les politiques héritées du type d'application de réseau privé hérité déprécié.
• Les applications Access à nom d'hôte public peuvent être sans client. Les applications de destination privée nécessitent le client WARP/Appareil ou un autre accès réseau plus les itinéraires et la résolution DNS. Consultez la documentation sur l'application privée auto-hébergée avant de configurer des 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 également être des entrées.
• Les politiques basées sur des groupes dépendent des revendications de groupe IdP ou de SCIM. Si la synchronisation de groupe est manquante, n'inventez pas de sélecteurs de groupe.
• Les noms d'hôte privés nécessitent un routage/résolution DNS explicite ; la création d'une application Access seule ne suffit pas. Utilisez les politiques de résolveur et examinez Connecter un nom d'hôte privé
• L'inspection HTTP et la DLP pour le trafic web chiffré nécessitent une inspection TLS et des exceptions "Ne pas inspecter" planifiées.
• Les politiques DNS, Réseau, HTTP et de sortie de Gateway ont une sémantique d'évaluation différente. Consultez la documentation sur l'ordre d'application avant d'expliquer la priorité.
• Commencez par des politiques de blocage/autorisation/DLP/TLS larges, désactivées, 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

• Les groupes Access sont des objets Cloudflare ; les groupes IdP/SCIM sont des revendications d'identité. Les sélecteurs de groupe Gateway utilisent des groupes IdP synchronisés, pas des groupes Access.
• Les noms de groupe et les attributs SAML/OIDC sont sensibles à la casse. Vérifiez les noms de revendication et les valeurs exacts avant de créer des règles basées sur des groupes.
• Les modifications SCIM et l'appartenance à un groupe peuvent être obsolètes jusqu'à ce que la synchronisation et la ré-authentification soient terminées. Dépannez avec la dernière identité authentifiée de l'utilisateur, pas seulement l'état IdP.
• Les politiques Access sont en "refus par défaut". Une application privée avec des itinéraires mais sans politique d'autorisation bloque toujours l'accès.
• Les sélecteurs de politique Access peuvent utiliser des listes IP, pas des listes de domaines ou d'URL 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.
• Le rendu de navigateur pour SSH/VNC/RDP est une capacité Access. L'isolation de navigateur rend le contenu web général à distance. Ne les confondez pas.

Déploiement du client d'appareil

• Le client d'appareil Cloudflare One est le point d'entrée pour les appareils des utilisateurs. Deux composants le contrôlent : les règles d'inscription (qui peut se connecter) et les profils d'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 d'appareil. Elle accepte les politiques Access réutilisables. Cherchez dans Access pour le débogage de l'inscription, pas dans Appareils.
• Pour les appareils sans tête ou autonomes (services, bornes, hôtes Linux), utilisez l'inscription par jeton de service. Les appareils non humains s'authentifient en tant que non_identity@[team-domain].cloudflareaccess.com et n'ont aucune appartenance à un groupe - les profils d'appareil ciblant les groupes IdP ne leur correspondront pas. Ciblez explicitement les appareils sans tête avec l'e-mail non-identité, des conventions spécifiques concernant l'appareil (informations sur le système d'exploitation, etc.), ou laissez-les utiliser le profil par défaut.
• Les profils d'appareil contrôlent le mode de connexion, la configuration du split tunnel, les autorisations utilisateur (désactiver, verrouillage de commutation), la reconnexion automatique et le comportement du portail captif. Les profils sont mis en correspondance par groupe d'utilisateurs ou attributs d'appareil dans un ordre de priorité - la première correspondance l'emporte, le profil par défaut attrape le reste.
• Le mode de split tunnel est le paramètre client le plus impactant. Choisissez le mode en fonction de l'objectif du déploiement :

Objectif	Mode	Justification
Remplacement VPN uniquement (applications privées)	Inclure	Achemine uniquement les CIDR et noms d'hôte privés spécifiés via le client. Tout le reste va directement. Rayon d'impact minimal.
SWG uniquement (sécurité Internet)	Exclure	Tout le trafic via le client. Excluez uniquement ce qui ne fonctionne pas (imprimantes locales, applications avec certificats épinglés).
Remplacement VPN + SWG	Exclure	Tout le trafic via le client. Configuration d'entreprise la plus courante.
Coexistence avec un autre VPN	Inclure	Évite les conflits 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. Aucun proxy de trafic.

• Inclure vs Exclure est par profil, pas par entrée. Vous ne pouvez pas mélanger les modes dans le même profil. Changer de mode en cours de déploiement nécessite de réévaluer chaque entrée.
• Les entrées de split tunnel doivent être alignées bidirectionnellement avec les itinéraires de tunnel. Un CIDR dans la liste d'inclusion sans itinéraire de tunnel correspondant provoque un trou noir. Un itinéraire de tunnel sans entrée de profil d'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 dans le tableau de bord pour tout paramètre spécifié dans le fichier. Si les modifications du tableau de bord semblent sans effet sur les appareils gérés, vérifiez la configuration MDM. Consultez la documentation sur le 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 d'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 du portail captif déconnecte temporairement le client lorsqu'il détecte un portail (WiFi d'hôtel, aéroport). C'est une source courante de friction pour l'utilisateur final et doit être gérée avec soin.

Réseau privé

• Le mode de split tunnel change la signification de chaque décision d'itinéraire : le mode Exclure envoie le trafic à Cloudflare lorsqu'il est retiré des exclusions ; le mode Inclure envoie le trafic uniquement lorsqu'il est ajouté aux inclusions.
• Les réseaux virtuels doivent être utilisés principalement lorsque les sous-réseaux IP se chevauchent et que 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é des utilisateurs, mais il est recommandé de les gérer via des politiques de sécurité.
• Un tunnel sain prouve uniquement que cloudflared peut atteindre Cloudflare. Le tunnel doit avoir un itinéraire approprié...

... (contenu tronqué pour la traduction)