Zugriffsrichtlinien (RBAC + ABAC)
Die zwei Zugriffskontrollschichten des DuoKey Cockpit — rollenbasierte Administration und attributbasierte (ABAC) Zugriffsrichtlinien, die jede kryptografische Operation zur Laufzeit regeln.
Das Cockpit verfügt über zwei getrennte Zugriffskontrollschichten. Sie beantworten unterschiedliche Fragen und werden an unterschiedlichen Stellen durchgesetzt, weshalb ihre Trennung essenziell ist:
| Schicht | Regelt | Wo sie angewendet wird |
|---|---|---|
| RBAC (Rollen & Berechtigungen) | Wer das Cockpit administrieren darf | Die Management-API — eine App bereitstellen, einen Schlüssel rotieren, eine Richtlinie bearbeiten |
| ABAC-Zugriffsrichtlinien | Wer, von wo und wann eine kryptografische Operation zur Laufzeit ausführen darf | Gebunden an DKE-Dienste, Apps und XKS-Endpunkte; ausgewertet zum Zeitpunkt der Entschlüsselung / des Schlüsselzugriffs |
Eine kurze Führung durch das Erstellen einer Zugriffsrichtlinie und deren Durchsetzung wird hier ergänzt.
RBAC — Administrationsberechtigungen
Administrative Aktionen sind durch feingranulare, hierarchische, rollenbasierte Berechtigungen geschützt, die regeln, wer welche Aktion ausführen darf. Ein Benutzer erhält eine Aktion, wenn er über die passende Berechtigung oder eine übergeordnete, sie implizierende Berechtigung verfügt; Administratoren bestehen alle Prüfungen.
Berechtigungen
Feingranulare Berechtigungen, die sich hierarchisch verschachteln — eine übergeordnete Berechtigung gewährt implizit alles darunter.
Rollen
Jede Rolle bündelt eine Reihe von Berechtigungen und wird Benutzern zugewiesen. Rollen können auf eine Organisationseinheit (OU) beschränkt werden, sodass eine Berechtigung nur innerhalb dieses Zweigs gilt.
OU-Umfang
Eine OU-beschränkte Rollenzuweisung begrenzt die Berechtigungen auf die Ressourcen dieser Organisationseinheit und unterstützt so delegierte Administration.
Rollen, ihre Berechtigungssätze und ihre Organisationseinheiten-Beschränkung werden über die Cockpit-Administrationskonsole erstellt und verwaltet.
ABAC — Zugriffsrichtlinien
Eine Zugriffsrichtlinie ist ein mandantengebundener Datensatz, der immer dann ausgewertet wird, wenn ein geschützter Schlüssel verwendet wird — zum Beispiel eine DKE-Entschlüsselung, eine generische App-Kryptooperation oder eine AWS-XKS-Entschlüsselung. Richtlinien werden von der Policy-Engine der Plattform durchgesetzt und bilden die Autorisierungsschicht oberhalb des jeweiligen Bearer-Tokens, mit dem der Aufrufer authentifiziert wurde.
Aufbau einer Richtlinie
| Attribut | Bedeutung |
|---|---|
| Name | Menschenlesbarer Richtlinienname |
| Beschreibung | Freitext-Beschreibung |
| Aktion | Übergeordnete Richtlinienaktion — Allow, Block oder Bypass |
| App-Typ | Ziel-App-Typ — z. B. DKE365, Oracle TDE, AWS XKS |
| OU-Umfang | Optionaler Organisationseinheiten-Umfang (nicht gesetzt = mandantenweit) |
| Aktiviert | Ob die Richtlinie aktiv ist |
| Regeln + Gruppen | Vier typisierte Regelblöcke — Benutzer, Gerät (IP), Standort und Zeit — plus Identitätsanbieter-Gruppen |
Die fünf Zugriffsdimensionen
Jede Dimension ist eine Liste von Einträgen. Jeder Eintrag trägt einen Match-Modus (Include = Whitelist, Exclude = Blacklist, Require) und, wo zutreffend, einen Match-Operator (any-of, contains).
| 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. Das Cockpit stellt eine Fähigkeitsmatrix bereit, die festlegt, welche der fünf Kategorien jeder App-Typ berücksichtigen kann; die Benutzeroberfläche blendet die nicht anwendbaren Regel-Tabs aus. DKE365 unterstützt alle fünf Dimensionen; mehrere universelle App-Typen unterstützen nur IP / Standort / Zeit.
Eine Richtlinie binden
Eine Richtlinie hat keine Wirkung, bevor sie an eine Ressource gebunden ist. Die Bindung heftet die Richtlinie an das Ziel:
| Ziel | Wie sie gebunden wird |
|---|---|
| DKE-Dienst | An den Dienst angehängt — bei jeder Entschlüsselung durchgesetzt |
| Generische Apps (inkl. Oracle TDE) | An die App angehängt — bei den Kryptooperationen der App durchgesetzt |
| AWS-XKS-Endpunkt | Pro Endpunkt angehängt — im XKS-Entschlüsselungspfad durchgesetzt |
Wie die Durchsetzung funktioniert
Gebundene Richtlinie nachschlagen
Wenn eine geschützte Operation ausgeführt wird, schlägt das Cockpit die an die Ressource gebundene Richtlinie nach. Ist keine angehängt oder die Richtlinie deaktiviert, wird die Operation zugelassen — keine Richtlinie bedeutet, dass die Ressource nicht eingeschränkt ist.
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 unterstützte Dimension wird von der Policy-Engine gegen den Kontext ausgewertet.
Entscheidungsrangfolge anwenden
Entscheidungen werden nach Rangfolge aufgelöst: 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.
Die Standardeinstellung ist Verweigerung. Das Anhängen einer aktivierten, aber leeren Richtlinie blockiert jeglichen Zugriff auf die Ressource, bis mindestens eine Include/Allow-Regel auf den Aufrufer zutrifft. Prüfen Sie eine Richtlinie durchgängig, bevor Sie sie an eine Produktionsressource binden.
Zugriffsrichtlinien-API
Zugriffsrichtlinien werden über die Cockpit-Konsole und ihre Management-API erstellt, aufgelistet, aktualisiert, an Ressourcen gebunden und protokolliert. Dieselbe Schnittstelle stellt die Fähigkeitsmatrix pro App-Typ sowie die für Gruppenregeln verfügbaren Gruppen bereit.
Beispielregeln
Die fünf Dimensionen lassen sich zu Regeln wie den folgenden kombinieren:
- Ein Land blockieren — Operationen aus einem bestimmten ISO-3166-Land verweigern.
- Nur bestimmte Benutzer zulassen — namentlich genannte Benutzer (per E-Mail oder UPN) zulassen und andere ausschließen.
- Nach IP und Zeit einschränken — nur ein bekanntes Subnetz zulassen, und nur innerhalb eines definierten täglichen Zeitfensters (zum Beispiel montags 08:00 bis 18:00 Uhr).
- Nach Identitätsanbieter-Gruppe einschränken — Zugehörigkeit zu einer bestimmten IdP-Gruppe verlangen.
Alles zusammenfügen
Richtlinie erstellen
Erstellen Sie die Richtlinie für den passenden App-Typ mit den gewünschten Regeln — zum Beispiel Operationen nur aus einem bekannten Subnetz (IP-Dimension) während der Geschäftszeiten (Zeit-Dimension) zulassen.
An eine Ressource binden
Hängen Sie sie an das Ziel an — einen DKE-Dienst, eine generische App oder einen AWS-XKS-Endpunkt.
Durchsetzen und protokollieren
Jede Kryptooperation auf dieser Ressource wird gegen die Richtlinie ausgewertet, und jede Entscheidung wird im Zugriffsrichtlinien-Audit-Trail erfasst.
Eine typische gehärtete Richtlinie kombiniert eine IP-Regel (nur die erwarteten Client-Hosts / das erwartete Subnetz) mit einer Zeit-Regel (das zulässige Betriebs- oder Wartungsfenster), wobei das Bearer-Token als Authentifizierung und die Richtlinie als Autorisierung dient. Legen Sie eine Benutzer- oder Gruppen-Regel darüber, wenn die Identität des Aufrufers bekannt ist.