Zugriffsrichtlinien für DKE 365 (RBAC + ABAC)
Das Cockpit-v2-Zugriffskontrollmodell für DKE 365 — RBAC für die Administration und ABAC-Zugriffsrichtlinien, die bei Decrypt durchgesetzt werden.
Cockpit v2 verfügt über zwei getrennte Zugriffskontrollschichten. Für DKE 365 beantworten sie zwei unterschiedliche Fragen:
| Schicht | Regelt | Für DKE bedeutet das |
|---|---|---|
| RBAC (Rollen & Berechtigungen) | Wer das Cockpit administrieren darf | Wer DKE-Dienste bereitstellen / aktivieren / rotieren darf |
| ABAC-Zugriffsrichtlinien | Wer, von wo und wann eine kryptografische Operation zur Laufzeit ausführen darf | Wer DKE-geschützte Inhalte entschlüsseln darf, von welcher IP / welchem Land / welcher Zeit / welcher Gruppe |
Die bestehenden Seiten RBAC und Zero-Trust-Zugriffskontrolle beschreiben die Zugriffskontrolle auf Cockpit v1. Auf Cockpit v2 wird dieselbe Absicht durch die unten beschriebene Policy-Engine umgesetzt, die über die access_policy_id an einen DKE-Dienst gebunden wird.
RBAC — Administrationsberechtigungen
Administrative Aktionen (Bereitstellen, Aktivieren und Rotieren von DKE-Diensten, Verwalten von Zugriffsrichtlinien) unterliegen der rollenbasierten Zugriffskontrolle. Rollen werden Benutzern zugewiesen und können auf eine Organisationseinheit (OU) beschränkt werden; Administratoren bestehen alle Prüfungen.
ABAC — an einen DKE-Dienst gebundene Zugriffsrichtlinien
Eine Zugriffsrichtlinie ist ein mandantengebundener Datensatz, der bei jedem DKE-Decrypt ausgewertet wird. Binden Sie sie an einen Dienst, indem Sie dessen access_policy_id setzen (siehe DKE-Konfiguration).
Die Cockpit-v2-Zugriffskontrollschicht ist eine vollwertige Policy-Engine, keine statische Zulassungsliste. Eine einzelne Richtlinie kombiniert fünf unabhängige Dimensionen (Benutzer, IP, Standort, Zeit, Gruppe), jede mit Whitelist- / Blacklist- / Require-Semantik, unter einer von drei Richtlinienaktionen (Allow / Block / Bypass) mit deterministischer Rangfolge. Sie ist fail-closed, mandantengebunden, optional OU-beschränkt, wird von einer Fähigkeitsmatrix pro App-Typ gesteuert, und jede Entscheidung wird in einem forensischen Audit-Trail protokolliert — alles serverseitig auf dem Decrypt-Pfad durchgesetzt, sodass der Schutz des Labels mit den Daten reist statt mit dem Client.
Aufbau einer Richtlinie
Eine Richtlinie hat einen Namen und eine Beschreibung, eine übergeordnete Aktion (Allow, Block oder Bypass), 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
Jeder Dimensionseintrag trägt einen Match-Modus (Whitelist, Blacklist oder Require) und, wo zutreffend, einen Match-Operator. DKE 365 unterstützt alle fünf Dimensionen.
| 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 |
Wie die Durchsetzung funktioniert (bei Decrypt)
Keine Richtlinie bedeutet keine Einschränkung
Ist keine Richtlinie angehängt (oder sie ist deaktiviert), wird Decrypt zugelassen (keine Richtlinie = nicht eingeschränkt).
Zugriffskontext aufbauen
Cockpit v2 baut einen Zugriffskontext aus dem Aufrufer auf: Benutzer, IP, Land, aktuelle Zeit und Gruppenzugehörigkeit. Das Azure-AD-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. Kann für ein allow in der Produktion kein Sicherheits-Audit-Eintrag geschrieben werden, wird das Decrypt abgelehnt.
Entscheidung protokollieren
Jede Entscheidung wird in einem forensischen Zugriffsrichtlinien-Audit-Log erfasst, das in den Aktivitätsprotokollen angezeigt wird.
Richtlinien werden im Cockpit erstellt und verwaltet, und jede Durchsetzungsentscheidung steht als Audit-Trail zur Verfügung, der in den Aktivitätsprotokollen angezeigt wird.
Beispiel: eine DKE-Decrypt-Richtlinie
Eine typische DKE-Decrypt-Richtlinie erlaubt Decrypt nur für Mitglieder einer bestimmten Identitätsanbieter-Gruppe (zum Beispiel der Zielgruppe des Labels), aus Ihren Unternehmensländern, während der Geschäftszeiten — und blockiert dabei jedes sanktionierte Land vollständig. Sie kombinieren eine Gruppen-Regel mit Standort- und Zeit-Regeln, binden die Richtlinie an den DKE-Dienst (access_policy_id), und jedes Decrypt wird anschließend dagegen ausgewertet, wobei jede Entscheidung im Audit-Trail erfasst wird.
Zugriffsrichtlinien sind die Art, wie DKE 365 Zero-Trust-Entschlüsselung auf Cockpit v2 umsetzt: Authentifizierung ist das Azure-AD-Token, und Autorisierung — wer / wo / wann / welche Gruppe — ist die Zugriffsrichtlinie. Kombinieren Sie eine Gruppen-Regel (nur die Zielgruppe des Labels) mit Standort- und Zeit-Regeln für eine strenge Haltung.