Cloudflare Organizations löst das Problem des Zugriffsmanagements (RBAC) in einer Multi-Account-Umgebung. Dies ist wichtig für SRE und Architekten, wo Tausende von Benutzern und verstreute Konten eine Fragilität im Management schaffen.
Das Problem tritt nicht sofort auf — bis die Anzahl der Konten schneller wächst, als sie verwaltet werden können. In Unternehmensszenarien segmentieren Teams Ressourcen über separate Cloudflare-Konten, um das Prinzip der minimalen Berechtigungen (least privilege) einzuhalten. Dies verringert das Risiko von übermäßigem Zugriff, schafft jedoch einen Nebeneffekt: die Kontrolle wird fragmentiert. Administratoren sind gezwungen, manuell in jedem Konto präsent zu sein, und ihre Berechtigungen können geändert oder entfernt werden. Bei Tausenden von Konten und Benutzern verwandelt sich dies in ein instabiles System, in dem RBAC formal vorhanden ist, aber operationell kompliziert wird.
Die Lösung besteht darin, eine Abstraktionsebene über den Konten hinzuzufügen. Cloudflare Organizations führt eine organisatorische Schicht ein, die mehrere Konten in eine einzige Struktur integriert. Die Schlüsselidee besteht darin, das Management von Benutzern, Richtlinien und Analytik zu zentralisieren, ohne die Zugriffsgrenzen innerhalb einzelner Konten zu verletzen. Dies ist ein Kompromiss: Einerseits bleibt die Isolation der Teams erhalten, andererseits entsteht ein Kontrollpunkt für Administratoren. Eine wichtige Einschränkung: Das System erhöht die Berechtigungen nicht automatisch. Jede Hinzufügung eines Kontos erfordert die Beteiligung eines Superadministrators, was das Risiko unkontrollierten Zugriffs verringert.
Architektonisch basiert Organizations auf einem Tenant-System, das zuvor für das Partner-Ökosystem verwendet wurde. Dies bot ein fertiges Modell für Multi-Tenancy und ermöglichte es, sich auf die Konsolidierung der Autorisierung zu konzentrieren. Im Rahmen dieser Arbeit wurde das System der Zugriffsprüfungen überarbeitet: veraltete Pfade wurden entfernt und die Logik über domain-scoped roles vereinheitlicht. Die Änderungen sind umfangreich — es wurden etwa 133.000 Zeilen Code hinzugefügt und 32.000 Zeilen Legacy-Code entfernt. Dies ist nicht nur ein Refactoring, sondern eine Angleichung des Zugriffsmodells, was für die zukünftige Erweiterung von Rollen auf Organisationsebene und Konten wichtig ist.
Ein besonderer Schwerpunkt liegt auf der Leistung. Die Zugriffsprüfungen bei Listenoperationen (z. B. /accounts oder /zones) haben sich historisch bei einer großen Anzahl von Ressourcen verschlechtert. Nach den Änderungen wurde eine Leistungsverbesserung von 27 % festgestellt. Dies ist eine direkte Folge der Vereinfachung des Autorisierungsmodells und der Beseitigung überflüssiger Prüfungen. Für Highload-Szenarien ist dies entscheidend: Die Latenz im Control-Plane beginnt, die Benutzererfahrung der Administratoren und die Automatisierung zu beeinflussen.
Die neue Rolle des Org Super Administrators wird zum zentralen Kontrollpunkt. Sie erfordert keine Mitgliedschaft in den Tochterkonten, hat jedoch vollen Zugriff darauf. Dies beseitigt die Notwendigkeit, Administratoren manuell in jedes Konto hinzuzufügen. Gleichzeitig werden solche Benutzer nicht im UI des spezifischen Kontos angezeigt, was die lokale Sauberkeit des Managements bewahrt. Dies ist ein interessanter Kompromiss zwischen Transparenz und zentralisiertem Kontroll.
Aus betrieblicher Sicht wurde eine aggregierte Analytikschicht hinzugefügt. Administratoren können den HTTP-Verkehr über alle Konten und Zonen in einem Dashboard sehen. Derzeit ist dies auf HTTP-Analytik beschränkt, aber die Architektur sieht eine Erweiterung vor. Dies ist ein wichtiger Schritt in Richtung einer einheitlichen Beobachtbarkeit auf Organisationsebene, obwohl es derzeit noch kein vollständiges Beobachtungssystem ist.
Eine weitere Schicht sind zentralisierte Richtlinien. Organizations ermöglicht es, Richtlinien (z. B. WAF) zwischen Konten zu teilen. Dies verändert das Modell des Sicherheitsmanagements: Jetzt kann das Sicherheitsteam Regeln einmal aktualisieren und sie auf die gesamte Organisation anwenden. Dabei bleiben die Änderungsrechte beim Team des ursprünglichen Kontos. Dies verringert die Duplizierung von Konfigurationen und das Risiko der Desynchronisation, erfordert jedoch eine sorgfältige Verwaltung der Quelle der Wahrheit.
Der Implementierungsprozess wurde absichtlich als Self-Service gestaltet. Cloudflare erstellt Organisationen nicht automatisch. Dies verhindert eine implizite Erhöhung der Berechtigungen. Die Erstellung einer Organisation und das Hinzufügen von Konten erfordert eine ausdrückliche Zustimmung zwischen den Administratoren. Dieser Ansatz erhöht die operationale Belastung zu Beginn, macht jedoch das Zugriffsmodell vorhersehbar.
Zusammenfassend handelt es sich um eine evolutionäre Verbesserung von RBAC in einer Multi-Account-Architektur. Organizations ersetzt nicht das bestehende Modell, sondern fügt eine Koordinationsschicht hinzu. Der Hauptgewinn besteht in der Verringerung der Fragilität des Managements und der Verbesserung der Leistung der Zugriffsprüfungen. Die Einschränkungen sind ebenfalls offensichtlich: Das System erfordert Disziplin im Management von Rollen und deckt derzeit nicht alle Szenarien der Analytik und Richtlinien ab. Aber das Fundament ist gelegt — und es ist eindeutig auf eine zukünftige Erweiterung ausgelegt.