Zugriffsrichtlinien (RBAC + ABAC)
Die zwei Zugriffskontrollschichten von Cockpit v2 — rollenbasierte Administration und ABAC-Zugriffsrichtlinien, die Schlüssel, Oracle-TDE-Apps und DKE-Dienste schützen.
Cockpit v2 verfügt über zwei getrennte Zugriffskontrollschichten. Ihre Trennung ist wichtig:
| Schicht | Regelt | Wo sie angewendet wird |
|---|---|---|
| RBAC (Rollen & Berechtigungen) | Wer das Cockpit administrieren darf | Die Management-API (z. B. eine Oracle-TDE-App bereitstellen, einen DKE-Schlüssel rotieren) |
| ABAC-Zugriffsrichtlinien | Wer, von wo und wann eine kryptografische Operation zur Laufzeit ausführen darf | Gebunden an Schlüssel, Apps (inkl. Oracle TDE) und DKE-Dienste; ausgewertet zum Zeitpunkt der Entschlüsselung / des Schlüsselzugriffs |
Ein kurzes Demo-Video zum Erstellen einer Zugriffsrichtlinie und deren Durchsetzung wird hier ergänzt.
RBAC — Administrationsberechtigungen
Administrative Aktionen (Verwalten von Schlüsseln, Apps, DKE-Diensten und Zugriffsrichtlinien) unterliegen der rollenbasierten Zugriffskontrolle. Rollen werden Benutzern zugewiesen; jede Rolle gewährt eine Reihe von Berechtigungen und kann auf eine Organisationseinheit (OU) beschränkt werden. Administratoren bestehen alle Prüfungen.
ABAC — Zugriffsrichtlinien
Eine Zugriffsrichtlinie ist ein mandantengebundener Datensatz, der immer dann ausgewertet wird, wenn ein geschützter Schlüssel verwendet wird (zum Beispiel ein DKE-Decrypt oder eine Oracle-TDE-Masterschlüssel-Operation). Sie spiegelt das Zugriffsrichtlinienmodell des bisherigen Cockpit wider, neu implementiert auf einer Policy-Engine.
Aufbau einer Richtlinie
Eine Richtlinie hat einen Namen und eine Beschreibung, eine übergeordnete Aktion (Allow, Block oder Bypass), einen Ziel-App-Typ (zum Beispiel DKE 365, Oracle TDE oder eine universelle App), einen optionalen Organisationseinheiten-Umfang (andernfalls mandantenweit), ein Aktiviert-Flag sowie Regelblöcke für jede der fünf unten beschriebenen Zugriffsdimensionen.
Die fünf Zugriffsdimensionen
Jede Dimension ist eine Liste von Einträgen; jeder Eintrag trägt einen Match-Modus (Whitelist, Blacklist oder Require) und, wo zutreffend, einen Match-Operator.
| Dimension | Prüft gegen |
|---|---|
| Benutzer | UPN / Anzeigename / E-Mail (regex-fähig) |
| IP | Exakte Adresse, CIDR-Bereich oder Start-Ende-Bereich (IPv4/IPv6) |
| Standort | ISO-3166-Ländercodes |
| Zeit | Wochentag + Minute-des-Tages-Bereich |
| Gruppe | Zugehörigkeit zu einer Identitätsanbieter-Gruppe |
Nicht jeder App-Typ unterstützt jede Dimension. Cockpit v2 stellt eine Fähigkeitsmatrix bereit, die festlegt, welche der fünf Kategorien jeder App-Typ berücksichtigen kann, und die Benutzeroberfläche blendet die nicht anwendbaren Regel-Tabs aus. DKE 365 unterstützt alle fünf; mehrere universelle App-Typen unterstützen nur IP / Standort / Zeit.
Eine Richtlinie binden
| Ziel | Wie sie gebunden wird |
|---|---|
| DKE-Dienst | access_policy_id am Dienst — bei jeder Entschlüsselung durchgesetzt |
| Generische Apps (inkl. Oracle TDE) | access_policy_id an der App — bei den Kryptooperationen der App durchgesetzt |
| AWS XKS | Eine access_policy_id pro Endpunkt, durchgesetzt im XKS-Entschlüsselungspfad |
Wie die Durchsetzung funktioniert
Gebundene Richtlinie nachschlagen
Wenn eine geschützte Operation ausgeführt wird, schlägt das Cockpit die gebundene Richtlinie nach. Ist keine angehängt oder die Richtlinie deaktiviert, wird die Operation zugelassen (keine Richtlinie = nicht eingeschränkt).
Zugriffskontext aufbauen
Das Cockpit baut einen Zugriffskontext aus der Identität und dem Transport des Aufrufers auf: Benutzer (aus dem JWT), IP, Land, aktuelle Zeit und Gruppenzugehörigkeit. Das JWT ist maßgeblich; weitergeleitete / CDN-Header (Client-IP, Land) werden nur als Fallback und Gegenprüfung verwendet, und nur, wenn sie von Quelladressen in der konfigurierten Liste vertrauenswürdiger Proxy-CIDRs stammen.
Jede Dimension auswerten
Jede Dimension wird von der Policy-Engine ausgewertet.
Entscheidungsrangfolge anwenden
Entscheidungsrangfolge: Bypass > Block > Allow > Standard-Verweigerung.
Fail-closed
Eine aktivierte Richtlinie ohne Regeln verweigert (sie lässt nicht stillschweigend zu). Kann für eine allow-Entscheidung in der Produktion kein Sicherheits-Audit-Eintrag geschrieben werden, wird die Operation verweigert.
Entscheidung protokollieren
Jede Entscheidung wird in einem forensischen Zugriffsrichtlinien-Audit-Log erfasst, das in den Aktivitätsprotokollen angezeigt wird.
Richtlinien verwalten
Richtlinien werden im Cockpit erstellt und verwaltet, das außerdem die Fähigkeitsmatrix pro App-Typ, die für Gruppenregeln verfügbaren Gruppen und den Durchsetzungs-Audit-Trail anzeigt.
Beispielregeln
Zugriffsrichtlinien kombinieren die fünf Dimensionen mit einfacher Whitelist- / Blacklist- / Require-Semantik. Typische Regeln umfassen: jedes sanktionierte Land blockieren und gleichzeitig Ihre Unternehmensländer zulassen (Standort); nur namentlich genannte Benutzer zulassen oder ein Muster ausschließen (Benutzer); auf einen IP-Bereich und die Geschäftszeiten beschränken (IP + Zeit); oder die Zugehörigkeit zu einer bestimmten Identitätsanbieter-Gruppe verlangen.
Eine Zugriffsrichtlinie auf eine Oracle-TDE-App anwenden
Die Richtlinie erstellen
Erstellen Sie eine Zugriffsrichtlinie für den Oracle-TDE-App-Typ mit den gewünschten Regeln — zum Beispiel Masterschlüssel-Operationen nur aus dem Datenbank-Subnetz zulassen (IP-Dimension) während der Geschäftszeiten (Zeit-Dimension).
An die App binden
Binden Sie sie an die Oracle-TDE-App, indem Sie die access_policy_id der App setzen.
Durchsetzen und protokollieren
Jede Masterschlüssel-Verwaltungsoperation auf dieser App wird dann gegen die Richtlinie ausgewertet, und jede Entscheidung wird im Zugriffsrichtlinien-Audit-Trail erfasst.
Eine typische Oracle-TDE-Richtlinie kombiniert eine IP-Regel (nur die Datenbank-Hosts / das Subnetz) mit einer Zeit-Regel (Wartungsfenster für die Schlüsselrotation), wobei das access_guid-Bearer-Token als Authentifizierung und die Richtlinie als Autorisierung dient.