Cloudflare One

Was macht Cloudflare One?

Bevor Sie Limits, Einstellungen, API-Felder, Kategorie-IDs oder exakte UI-Pfade nennen, rufen Sie aktuelle Informationen aus der Cloudflare One Dokumentation, dem Cloudflare Docs MCP-Server oder dem Cloudflare API-Schema ab.

Workflow

1. Klassifizieren Sie die Anfrage: Architektur, Konfiguration, Fehlerbehebung, Migration oder Überprüfung.
2. Sammeln Sie Kontext: Konto-ID, Benutzer/Standorte/Apps, Identitätsanbieter, SCIM/Gruppen-Sync, Geräteverwaltung, Verkehrspfad, Compliance-Anforderungen und Rollout-Reichweite.
3. Rufen Sie nur die aktuellen Dokumentationen ab, die für die beteiligten Produkte benötigt werden: Access, Gateway, WARP/Device Client, Tunnel/Mesh, Cloudflare WAN, DLP, CASB, Gerätestatus oder Identität.
4. Wenn Kontozugriff verfügbar ist, überprüfen Sie vorhandene Ressourcen, bevor Sie Änderungen vorschlagen oder vornehmen: Access-Apps/Richtlinien/Gruppen/IdPs, Gateway-Regeln/Listen/Kategorien, Geräteprofile/Statusprüfungen, Tunnel/Routen, DNS/Resolver-Einstellungen und Standorte/Sites.
5. Schlagen Sie das Änderungsset mit Voraussetzungen, Validierung und Rollback vor. Für riskante Änderungen stufen Sie diese deaktiviert oder auf eine Pilotgruppe/einen Pilotstandort beschränkt ein, es sei denn, der Benutzer fordert explizit etwas anderes.

Bewertungsaufforderungen

Verwenden Sie diese, um nicht direkt zur Konfiguration zu springen. Fragen Sie nur die für die Aufgabe des Benutzers relevanten Aufforderungen.

Architektur und Ist-Zustand

• Standorte und Benutzer: Büros, Niederlassungen, Rechenzentren, VPCs, Remote-Benutzer, Auftragnehmer, Benutzerzahlen und aktuelles Konnektivitätsmodell.
• Anwendungen und Ziele: SaaS, öffentliche Apps, private Apps, APIs, Infrastrukturziele, Protokolle, Ports, Hostnamen und IP-Bereiche.
• Konnektivität: VPN, MPLS, SD-WAN, direkter Internet-Ausgang, zentralisierter Backhaul, Site-to-Site-Bedarf und private DNS-Architektur.
• Sicherheitsstack: aktuelle SWG, NGFW, VPN/ZTNA, DLP, CASB, E-Mail-Sicherheit, Protokollierung und Compliance-Anforderungen.
• Identität: IdP, SCIM/Gruppen-Sync, Gruppenbenennung, Multi-IdP-Bedarf, Dienstkonten und Auftragnehmer-/Partnerzugriff.
• Rollout: Pilotbenutzer/-Standorte, Reichweite, Rollback-Pfad, Support-Verantwortliche und Erfolgskriterien.

Access und SaaS-Föderation

• App-Form: Web-App, API, SSH/RDP/VNC, Datenbank, SaaS-App, öffentlicher Hostname, private IP oder privater Hostname. Rufen Sie die Dokumentation zum Access-Anwendungstyp ab, bevor Sie eine Auswahl treffen.
• Access-Modell: clientloser Browserzugriff, privates Netzwerk mit Device Client, Peer-to-Peer-Konnektivität, Serviceverbindungen mit Service-Tokens oder gegenseitigem TLS oder SaaS-SSO-Föderation.
• Richtlinienbedarf: Benutzergruppen, Gerätestatus, Sitzungsdauer, mTLS, Service-Tokens und Sichtbarkeit des App Launcher. Rufen Sie die Dokumentation zu Access-Richtlinien ab, bevor Sie Selektoren oder die Auswertungsreihenfolge konfigurieren.
• SaaS-Details: SAML- vs. OIDC-Unterstützung, ACS-/Weiterleitungs-URLs, Entity-IDs/Client-IDs, erforderliche Attribute und Anforderungen an die Mandantensteuerung.

Tunnel und privates Netzwerk

• Standorte und Segmente: Welche Rechenzentren, VPCs, Büros oder Netzsegmente benötigen Konnektivität.
• HA: Entwicklung/Test mit einem einzelnen Connector, Produktion mit mehreren Connectoren oder erweiterte Multi-Tunnel-/Standort-Redundanz.
• Laufzeit: Wo cloudflared oder WARP Connector/Mesh ausgeführt werden: VM, Container, Kubernetes, Bare Metal oder anderes Ziel.
• Ausgang: Ob Connectoren Cloudflare über die erforderlichen ausgehenden Ports/Protokolle erreichen können. Rufen Sie die Tunnel-Konnektivitätsvorprüfungen ab, bevor Sie genaue Endpunkte nennen.
• Erreichbarkeit von Ursprüngen: Ob der Connector jeden privaten Ursprung auflösen und erreichen kann.
• Routing: erforderliche CIDRs/Hostnamen, überlappende IP-Räume, virtuelle Netzwerke, Split Tunnels und Anforderungen an privates DNS/Resolver-Richtlinien.
• Verwaltungsmodell: Bevorzugen Sie für neue Bereitstellungen remote verwaltete/token-basierte Tunnel, es sei denn, es gibt einen eindeutigen Grund für eine lokale Konfiguration.

Gateway, TLS und DLP

• Verkehrskontrollen: DNS-Kategorien, HTTP-URL/Pfad-Inspektion, L4-Ports/Protokolle, Ausgangs-IP-Anforderungen, benutzerdefinierte Listen und Allow/Block-Ausnahmen. Rufen Sie die Dokumentation zu Gateway-Verkehrsrichtlinien für aktuelle Selektoren und die Durchsetzungsreihenfolge ab.
• Identität: Ob Gateway-Richtlinien Benutzer- oder Gruppenselektoren benötigen und ob Benutzer über WARP/IdP-Kontext authentifiziert werden. Überprüfen Sie Gateway-Identitätsselektoren und SCIM-Provisionierung, wenn Gruppen beteiligt sind.
• TLS-Inspektion: Root-CA-Bereitstellungspfad, Anwendungen mit festgelegten Zertifikaten, Compliance-Ausnahmen und FIPS-Anforderungen. Rufen Sie die Dokumentation zur TLS-Entschlüsselung ab, bevor Sie sie aktivieren.
• DLP: sensible Datentypen, zu inspizierende Kanäle, TLS-Inspektionsbereitschaft, DLP-Profile, Anforderungen an die Nutzlastprotokollierung und Toleranz gegenüber Falsch-Positiven. Rufen Sie die DLP Dokumentation ab, bevor Sie Durchsetzungsregeln erstellen.

CASB, Gerätestatus und Risiko

• CASB: SaaS-Anbieter, Administratorzugriffsstufe, Scan-Richtlinie, Organisationsgröße, Remedierungsverantwortlicher und ob Inline-Schutz ebenfalls erforderlich ist. Rufen Sie die Dokumentation zu CASB-Ergebnissen ab, bevor Sie eine Abhilfe empfehlen.
• Gerätestatus: erforderliche Prüfungen, Integrationen mit Drittanbieter-EDR/MDM, Registrierungsregeln, Geräteprofile und Split-Tunnel-Ausrichtung.
• Risikobewertung: relevante Verhaltenssignale, Quellen für Falsch-Positive wie VPNs oder Dienstkonten und ob das Risiko für Untersuchungen oder Durchsetzungsmaßnahmen dient. Rufen Sie die Dokumentation zum Benutzerrisikoscore ab, bevor Sie Risiko in Richtlinien verwenden.

Cloudflare WAN / Standort-Konnektivität

• Standort-Topologie, On-Ramp-Typ, Routen-Eigentümer, Tunnel-Redundanz, statische vs. BGP-verwaltete Routen, Anforderungen an die Netzwerk-Firewall und Geräte-/Profil-Eigentümer. Rufen Sie die Dokumentation zu Cloudflare WAN und Cloudflare Network Firewall ab, bevor Sie Änderungen an der Standortkonnektivität vorschlagen.

Leitplanken

• Access-Kontrollen autorisieren Anwendungen; Gateway-Kontrollen regulieren die Verkehrsinspektion/-filterung. Verwenden Sie beide, wenn die Anforderung identitätsbasierten App-Zugriff und Netzwerk-/Web-Sicherheit umfasst.
• Erstellen Sie bei neuen Access-Bereitstellungen Richtlinien über die wiederverwendbare Richtlinien-API (/access/policies) und hängen Sie sie an Anwendungen an. Senden Sie keine Inline-policies in einer Anwendungs-Erstellungs-/Aktualisierungsanfrage, es sei denn, die aktuelle API-Dokumentation erfordert explizit eine anwendungsspezifische Richtlinie.
• Behandeln Sie eine anwendungsspezifische Richtlinie, die als reusable: false gemeldet wird, als Legacy. Migrieren Sie vorhandene Richtlinien mit dem dokumentierten make_reusable-Endpunkt oder ersetzen Sie sie durch wiederverwendbare Richtlinien; erstellen Sie keine neuen Legacy-Richtlinien. Unterscheiden Sie Legacy-Richtlinien vom veralteten Legacy-Privatnetzwerk-Anwendungstyp.
• Access-Apps für öffentliche Hostnamen können clientlos sein. Apps für private Ziele erfordern WARP/Device Client oder einen anderen Netzwerk-On-Ramp sowie Routen und DNS-Auflösung. Rufen Sie die Dokumentation zur selbst gehosteten privaten App ab, bevor Sie private Ziele konfigurieren.
• Cloudflare Tunnel ist ein Off-Ramp von einem privaten Netzwerk zu Cloudflare. Cloudflare WAN und Mesh sind andere Off-Ramps, die auch On-Ramps sein können.
• Gruppenbasierte Richtlinien hängen von IdP-Gruppenansprüchen oder SCIM ab. Wenn kein Gruppen-Sync vorhanden ist, erfinden Sie keine Gruppenselektoren.
• Private Hostnamen benötigen explizites DNS-Routing/Auflösung; das alleinige Erstellen einer Access-App reicht nicht aus. Verwenden Sie Resolver-Richtlinien und lesen Sie Verbinden eines privaten Hostnamens.
• HTTP-Inspektion und DLP für verschlüsselten Webverkehr erfordern TLS-Inspektion und geplante Do Not Inspect-Ausnahmen.
• Gateway DNS-, Netzwerk-, HTTP- und Egress-Richtlinien haben unterschiedliche Auswertungssemantiken. Rufen Sie die Dokumentation zur Durchsetzungsreihenfolge ab, bevor Sie die Priorität erläutern.
• Beginnen Sie mit breiten Block/Allow/DLP/TLS-Richtlinien, die deaktiviert und auf eine Pilotgruppe mit bestimmten Zielbenutzern oder -gruppen beschränkt sind, es sei denn, der Benutzer genehmigt einen breiteren Rollout.

Identität und Zugriff

• Access-Gruppen sind Cloudflare-Objekte; IdP/SCIM-Gruppen sind Identitätsansprüche. Gateway-Gruppenselektoren verwenden synchronisierte IdP-Gruppen, nicht Access-Gruppen.
• Gruppennamen und SAML/OIDC-Attribute sind groß-/kleinschreibungsabhängig. Überprüfen Sie die genauen Anspruchsnamen und -werte, bevor Sie gruppenbasierte Regeln erstellen.
• SCIM-Änderungen und Gruppenmitgliedschaften können bis zum Abschluss der Synchronisierung und erneuten Authentifizierung veraltet sein. Beheben Sie Fehler anhand der zuletzt authentifizierten Identität des Benutzers, nicht nur des IdP-Status.
• Access-Richtlinien sind standardmäßig auf Verweigerung ausgelegt. Eine private App mit Routen, aber ohne Allow-Richtlinie blockiert trotzdem den Zugriff.
• Access-Richtlinienselektoren können IP-Listen verwenden, nicht Gateway-Domain- oder URL-Listen.
• SaaS-Föderation behandelt die Authentifizierung in der SaaS-App. SaaS-Autorisierung und Mandanteneinschränkungen erfordern normalerweise SaaS-seitige Rollen und/oder Gateway-Mandantenkontrollen.
• Browser Rendering für SSH/VNC/RDP ist eine Access-Funktion. Browser Isolation rendert allgemeine Webinhalte remote. Verwechseln Sie diese nicht.

Bereitstellung des Device Clients

• Der Cloudflare One Device Client ist der On-Ramp für Benutzergeräte. Zwei Komponenten steuern ihn: Registrierungsregeln (wer sich verbinden darf) und Geräteprofile (wie sich der Client nach der Registrierung verhält).

• Die Registrierungsregel ist eine Access-Anwendung vom Typ warp, keine Geräteeinstellung. Sie akzeptiert wiederverwendbare Access-Richtlinien. Suchen Sie bei der Registrierungsfehlerbehebung in Access, nicht in Geräten.

• Verwenden Sie für kopflose oder autonome Geräte (Dienste, Kioske, Linux-Hosts) die Service-Token-Registrierung. Nicht-menschliche Geräte authentifizieren sich als non_identity@[team-domain].cloudflareaccess.com und haben keine Gruppenmitgliedschaft – Geräteprofile, die auf IdP-Gruppen abzielen, werden nicht auf sie angewendet. Zielen Sie explizit auf kopflose Geräte ab, indem Sie die Non-Identity-E-Mail, bestimmte Konventionen zu den Geräten (Betriebssysteminformationen usw.) verwenden oder sie auf das Standardprofil fallen lassen.

• Geräteprofile steuern den Verbindungsmodus, die Split Tunnel-Konfiguration, Benutzerberechtigungen (Deaktivieren, Sperre), automatische Wiederverbindung und das Verhalten bei Captive Portals. Profile werden nach Benutzergruppe oder Geräteattributen in einer Prioritätsreihenfolge abgeglichen – der erste Treffer gewinnt, das Standardprofil fängt den Rest ab.

• Der Split-Tunnel-Modus ist die einflussreichste Client-Einstellung. Wählen Sie den Modus basierend auf dem Bereitstellungsziel:

  Ziel	Modus	Begründung
  Nur VPN-Ersatz (private Apps)	Include	Nur bestimmte private CIDRs und Hostnamen werden durch den Client geroutet. Alles andere geht direkt. Minimale Reichweite.
  Nur SWG (Internetsicherheit)	Exclude	Der gesamte Verkehr durch den Client. Nur ausschließen, was kaputt geht (lokale Drucker, Apps mit festgelegten Zertifikaten).
  VPN-Ersatz + SWG	Exclude	Der gesamte Verkehr durch den Client. Häufigste Unternehmenskonfiguration.
  Koexistenz mit einem anderen VPN	Include	Vermeidet Konflikte mit der Tunnelschnittstelle und DNS-Steuerung des anderen VPN.
  Nur DNS-Filterung	Nur DNS-Modus	Nur DNS-Abfragen gehen an Gateway. Kein Verkehrs-Proxy.

• Include vs. Exclude ist pro Profil, nicht pro Eintrag. Sie können Modi nicht im selben Profil mischen. Ein Wechsel des Modus während der Bereitstellung erfordert eine Neubewertung jedes Eintrags.

• Split-Tunnel-Einträge müssen bidirektional mit Tunnelrouten übereinstimmen. Eine CIDR in der Include-Liste ohne passende Tunnelroute verursacht ein Schwarzes Loch. Eine Tunnelroute ohne passenden Geräteprofil-Eintrag bedeutet, dass der Verkehr niemals in den Tunnel gelangt.

• MDM-Parameter (mdm.xml / verwaltete Einstellungen) überschreiben im Dashboard konfigurierte Profileinstellungen für jede in der Datei angegebene Einstellung. Wenn Dashboard-Änderungen auf verwalteten Geräten keine Wirkung zu zeigen scheinen, überprüfen Sie die MDM-Konfiguration. Rufen Sie die Dokumentation zur MDM-Bereitstellung für plattformspezifische Dateispeicherorte und Parameter ab.

• Wenn ein anderer VPN-Client oder Agent DNS auf dem Gerät steuert, kommt es zu Konflikten mit der DNS-Abfangfunktion des Device Clients. Verwenden Sie in Koexistenzszenarien den Modus „Nur Verkehr“, um Konflikte in der Routing-Tabelle und mit DNS zu vermeiden.

• Die Captive-Portal-Erkennung trennt den Client vorübergehend, wenn ein Portal erkannt wird (Hotel-WLAN, Flughafen). Dies ist eine häufige Quelle von Benutzerfrustration und sollte sorgfältig verwaltet werden.

Privates Netzwerk

• Der Split-Tunnel-Modus ändert die Bedeutung jeder Routenentscheidung: Der Exclude-Modus sendet Datenverkehr an Cloudflare, wenn er aus den Excludes entfernt wird; der Include-Modus sendet Datenverkehr nur, wenn er zu den Includes hinzugefügt wird.
• Virtuelle Netzwerke sollten hauptsächlich verwendet werden, wenn sich IP-Subnetze überschneiden und hostnamebasiertes Routing nicht verwendet wird. Sie können verwendet werden, um andere Aspekte des Benutzer-Konnektivitätsverhaltens zu steuern, es wird jedoch empfohlen, dies über Sicherheitsrichtlinien zu verwalten.
• Ein gesunder Tunnel beweist nur, dass cloudflared Cloudflare erreichen kann. Der Tunnel muss über geeignete …

…

[gekürzt für die Übersetzung]