Drei Rollen sind kein Zugriffsmodell.
Viele Delivery-Plattformen bieten eine kurze Rollenliste — Administrator, Operator, Nur-Lesen — und alles, was nicht hineinpasst, wird Administrator. Das Zertifikatsteam erhält volle Traffic-Rechte, weil Zertifikate unter Traffic liegen. Die Monitoring-Integration erhält ein Administrator-Token, weil es kein kleineres gibt.
Das Ergebnis ist absehbar: Ein Audit fragt, wer eine Änderung hätte vornehmen können, und die ehrliche Antwort lautet: fast die ganze Konsole. Funktionstrennung existiert im Organigramm, nicht im Produkt.
Der zweite Fehler ist die Drift zwischen Oberflächen. Ein Recht, das in der Oberfläche gilt, in der API aber nicht, ist kein Recht, sondern ein Vorschlag.
Unser Ansatz
Die Rolle benennt die Aufgabe. Der Geltungsbereich benennt den Wirkungsradius. Beides gilt auf jeder Oberfläche.
Sechzehn Rollen statt drei
Die Rollen folgen den Linien, entlang derer sich Teams tatsächlich teilen: Traffic, WAF, Netz, GTM, Zertifikate und Monitoring — mit Manager- und Benutzervariante, wo dieser Unterschied zählt, dazu Nur-Lese- und reine Frontend-Rollen für alle, die sehen, aber nicht anfassen sollen.
Geltungsbereich über der Rolle
Die Rolle sagt, welche Art von Objekt ein Benutzer anfassen darf. Der Geltungsbereich sagt, welche: erlaubte Frontend-Adressen, erlaubte Backend-Netze, zugewiesene vServices und zugewiesene vDevices. Zwei Traffic Manager verwalten zwei getrennte Umgebungen auf einer Appliance, ohne die Dienste des anderen zu sehen.
Ein Rechtemodell für Oberfläche, CLI und API
Die interaktive CLI erzwingt dieselbe Rolle wie die Oberfläche — ein Network Manager sieht Netzbefehle und sonst nichts — und der REST-Zugriff wird mit demselben Modell je Bereich und je Feld geregelt. Dauerhafte API-Token sind an die Rolle gebunden.
Jede Oberfläche schreibt in denselben Audit-Trail
Eine Änderung per Klick, per Befehl oder per API-Aufruf landet in einem Audit-Trail mit verlustfreien Vorher-Nachher-Diffs. Die Frage des Prüfers — wer hat das geändert, von wo, und wie sah es vorher aus — hat eine Antwort.
Funktionen
Was das Rollenmodell abdeckt und was darauf aufsetzt.
Sechzehn benannte Administrationsrollen
Der vollständige Satz: Admin (super-admin) · Traffic Manager · Traffic User · Traffic+WAF Manager · Traffic+WAF User · WAF Manager · WAF User · WAF Read-Only · Network Manager · Network User · GTM User · Certificate Manager · Monitor User · Read-Only User · Frontend User · Client. Manager- und Benutzervarianten trennen das Recht zu konfigurieren vom Recht zu betreiben.
Netz-Geltungsbereich — erlaubte Frontend-Adressen und Backend-Netze
Die Reichweite eines Benutzers ist über Adressen begrenzt, nicht nur über Objekttypen. Ein Fehler bleibt damit innerhalb des Segments, für das der Benutzer verantwortlich ist.
Ressourcen-Geltungsbereich — zugewiesene vServices und vDevices
Benutzern werden die konkreten veröffentlichten Dienste und die konkreten vDevices zugewiesen, die ihnen gehören. Alles andere ist für sie nicht schreibgeschützt, sondern unsichtbar.
Zertifikatsrechte: Verwalten und Auswählen getrennt
Das Recht, ein Zertifikat für einen Dienst auszuwählen, und das Recht, die Zertifikatsbibliothek zu verwalten, sind getrennt. Ein Anwendungsteam veröffentlicht auf dem richtigen Zertifikat, ohne den Schlüssel exportieren, ersetzen oder löschen zu können.
Shell-Zugang als Schalter je Benutzer
CLI über SSH und CLI im Browser sind zwei unabhängige Schalter mit jeweils eigener Höchstzahl an Sitzungen. Ein Operator kann die Browserkonsole erhalten, ohne dass irgendwo ein SSH-Konto für ihn existiert.
Kontingente je Benutzer: Bandbreite, CPU und Verbindungen
Eine Rolle kann neben dem Rechteumfang auch eine Ressourcenobergrenze tragen, damit ein Mandantenadministrator die Appliance nicht stellvertretend für alle anderen auslastet.
Feldgenaue API-Autorisierung
Der REST-Zugriff wird je Bereich und je Feld mit demselben Modell wie die Oberfläche geregelt. Eine Rolle, die ein Feld in der Konsole nicht sieht, liest es auch über die API nicht.
Administratoren aus dem Verzeichnis, mit starker Authentifizierung
Administratoren authentifizieren sich gegen lokale Konten, LDAP und Active Directory, RADIUS oder TACACS+ mit Accounting. Zwei-Faktor per SMS- oder E-Mail-Einmalcode, Wiederherstellungstoken und mTLS-Zertifikatsanmeldung aus TR7s interner PKI stehen bereit.
Arbeitsplatzeinstellungen folgen dem Benutzer
Sprache, Design und Kopfzeilenlayout werden je Benutzer gespeichert, sodass die Konsole auf jedem Clusterknoten gleich aussieht.
Betriebliche Tiefe
Die Teile, die entscheiden, ob ein Zugriffsmodell ein Audit übersteht.
Funktionstrennung ausgedrückt statt versprochen
Weil WAF, Traffic, Netz, GTM und Zertifikate eigene Rollenfamilien sind, wird die übliche Anforderung regulierter Branchen — wer die Sicherheitsrichtlinie ändert, ändert nicht den Verkehrsweg — zur Konfiguration statt zur Prozedur, an die sich jemand erinnern muss.
Nur-Lese-Rollen, die wirklich nur lesen
Read-Only User, WAF Read-Only und Monitor User existieren, damit Prüfer, NOC-Personal und Dashboards keine Rolle brauchen, die etwas ändern könnte.
Frontend User und Client für delegierten Zugriff
Frontend User deckt Personen ab, die mit veröffentlichten Diensten arbeiten, ohne die Plattform darunter anzufassen. Client deckt den Cloud-Client-Fall ab, in dem das Konto einem Nutzer des Dienstes gehört, nicht dessen Betreiber.
Brute-Force-Abwehr auf der Managementebene
Passwortkomplexität wird erzwungen, Fehlanmeldungen werden über ablaufende Budgets je IP und je IP-plus-Benutzername gedrosselt, gestützt durch das integrierte CAPTCHA.
Managementdienste einzeln gebunden und eingegrenzt
HTTPS, SSH, FTP und SNMP binden je an eine gewählte Adresse und einen Port und tragen eigene Netzfreigabelisten, ein eigenes Zertifikat und eigene TLS-Mindest- und Höchstversionen. Die Konsole kann TLS 1.3 verlangen, während eine ältere Monitoring-Integration einen anderen Dienst mit TLS 1.2 erreicht.
Zweckgebundene Dateitransferkonten
Der Dateitransfer läuft nicht über ein gemeinsames Konto. Getrennte Konten decken Logexport, Konfigurationssicherung, Offline-Lieferung der IP-Reputationsdaten und Offline-Updatepakete ab, und jedes sieht nur sein eigenes Verzeichnis.
Wann Sie das brauchen
Regulierte Funktionstrennung
Eine Bank braucht getrennte Verantwortliche für WAF-Richtlinie und Traffic — und den Nachweis dafür. WAF Manager und Traffic Manager sind getrennte Rollen mit getrennten Audit-Trails, der Nachweis ist ein Bericht statt eines Gesprächs.
Anwendungsteams, die selbst veröffentlichen
Jedes Team erhält eine Traffic-User-Rolle, eingegrenzt auf die eigenen vServices und Backend-Netze. Veröffentlichen und Betreiben ohne Change Request und ohne Zugriff auf fremde Dienste.
Token für Pipelines und Monitoring
Eine CI/CD-Pipeline erhält ein dauerhaftes API-Token mit enger Rolle, ein Monitoringsystem eines mit Monitor User. Keines trägt Administratorrechte, ein geleaktes Token bleibt ein begrenzter Vorfall.
Ein Zertifikatsteam ohne Traffic-Verantwortung
Certificate Manager verwaltet Schlüsselbibliothek und Erneuerungen; Anwendungsteams wählen daraus. Der private Schlüssel muss nie an das veröffentlichende Team übergeben werden.
Häufige Fragen
Wie viele Administrationsrollen liefert TR7?
Gelten in der CLI dieselben Rechte wie in der Oberfläche?
Können zwei Administratoren auf einer Appliance verschiedene Dienste verwalten, ohne einander zu sehen?
Lässt sich ein API-Token auf weniger als Administrator begrenzen?
Erfordert RBAC eine zusätzliche Lizenz?
Wie authentifizieren sich Administratoren?
Sechzehn Rollen, je Benutzer eingegrenzt, auf jeder Oberfläche durchgesetzt
Gehen wir das Rollenmodell an Ihren eigenen Anforderungen zur Funktionstrennung durch.