RBAC: Rollen und Berechtigungen verwalten

1) Ziele und Grundsätze der RBAC

Das Ziel: den Zugang überschaubar, überprüfbar und im Umfang minimal zu machen, um Geld/PII und Compliance (DSGVO/AML/PCI/ISO) zu schützen.
Grundsätze: Least Privilege· Need-to-Know· Separation of Duties (SoD)· Zero Trust· Revocability (schneller Rückruf)· Auditability (Nachweisbarkeit).

2) Taxonomie der Rechte und Rollen

• Daten: 'READ', 'WRITE', 'EXPORT', 'DELETE', 'MASKED _ READ' (Standard für PII).
• Операции: `APPROVE_WITHDRAWAL`, `CHANGE_FRM_RULE`, `KYC_DECISION`, `SANCTIONS_OVERRIDE`.
• Админ: `ROLE_UPDATE`, `USER_PROVISION`, `SECRET_ROTATE`, `BREAK_GLASS`.
• Integrationen: „API _ CALL:“, „WEBHOOK _ SIGN“, „SERVICE _ CONFIG _ UPDATE“.

• Core (сквозные): `employee_basic`, `viewer_internal`, `auditor_privacy`.
• Доменные: `support_agent`, `vip_manager`, `payments_ops`, `aml_officer`, `kyc_operator`, `fraud_analyst`, `rg_specialist`, `bi_analyst`.
• System/solche: 'devops _ admin', 'dba _ admin', 'service _ account _', 'read _ only _ prod'.
• Privilegiert (über PAM/JIT): 'break _ glass _ admin', 'prod _ db _ jit _ editor'.

3) Rollengestaltung (Rollentechnik)

1. Ressourcenbestand: Systeme/Tabellen/Endpunkte, Datenklassen (Public/Internal/Confidential/Restricted/Highly Restricted).
2. User Stories nach Funktion: Wer macht was und warum (purpose).
3. Aufgabenmapping → Berechtigungen: Mindestsatz für jede Funktion.
4. Gruppierung in einer Rolle: eine Rolle = eine Verantwortungsdomäne; Vermeiden Sie „Superrollen“.
5. SoD-Test: Überprüfung auf Inkompatibilitäten (z. B. "payments _ ops' ≠" fraud _ rule _ admin ").
6. Pilot und Messung: Wir geben eine vorübergehend begrenzte Gruppe aus, wir sammeln einen Prüfpfad.
7. Versionierung: Jeder Rollenwechsel erfolgt über CAB mit changelog.

4) Interaktion zwischen RBAC ↔ ABAC ↔ SoD

RBAC antwortet „wer kann im Prinzip“, ABAC „unter welchen Bedingungen“ (Medium, Geo, Device/MDM, Time, KYC Level, 'Purpose').
SoD verbietet gefährliche Rollenkombinationen und verlangt 4-Augen für kritische Aktionen.
Praxis: Standardmäßig geben Rollen MASKED_READ zu PII; Der nicht maskierte Zugriff erfordert das Attribut 'purpose' + JIT und eine positive ABAC-Policy-Lösung.

5) Multi-Leasing und Geo-Kontext

Tenant-Scope: Rollen sind an Miete/Marke/Gerichtsbarkeit gebunden ('role: payments _ ops @ EEA').
Geo-Keys: separate Verschlüsselungsschlüssel und Zugriffssegmente pro Region (EC/UK/...).
Granularität: Filterung nach der Spalte' region _ code'(RLS) und nach der Gerichtsbarkeit des Spielers.

6) Row/Column-Level Sicherheit und Maskierung

• RLS (Strings): Zugriff nur auf Datensätze Ihres Landes/Ihrer Marke/Ihres Teams.
• CLS (Spalten): sensible Felder sind maskiert zugänglich; unmaskiert - nur mit dem Privileg 'pii _ unmask' + 'purpose'.

sql
CREATE POLICY rls_tx
ON dwh. transactions
USING (region_code = current_setting('app. region'));

SELECT
CASE WHEN has_priv('pii_unmask') THEN email ELSE mask_email(email) END AS email_view
FROM dwh. users;

7) JIT, break-glass и PAM в RBAC

JIT: temporäre privilegierte Rolle (15-120 min) unter dem Ticket; automatische Rücknahme; vollständiges Audit.
Break-glass: Notfallzugang mit MFA + zweiter Bestätigung und Sitzungsaufzeichnung; Post-Revue mit Security + DPO.
PAM: Secret Storage, Session Proxy, Passwort-/Schlüsselrotation.

8) Rollenlebenszyklus (SOP)

SOP-1: Erstellen/Ändern einer Rolle

1. Anfrage des Domaininhabers → Aufgabenliste → Mupping Permissions → SoD-Check → Pilot → CAB → Release + Dokumentation.

SOP-2: Antrag und Erteilung des Zugangs

1. Antrag (IDM/ITSM) mit „Zweck“ und Frist → Auto-Check-SoD/Gerichtsbarkeit → Zustimmung des Dateneigentümers + Sicherheit (für Restricted +) → Ausstellung (oft JIT) → Eintragung in das Register.

SOP-3: Rückruf/Offboarding

Auslöser: Kündigung, Rollenwechsel, Inaktivität> 30/60 Tage, JIT abgelaufen.
Automatischer Rückruf und Logbuch.

SOP-4: Re-Zertifizierung

Vierteljährlich bestätigen die Eigentümer, dass die Benutzerrollen noch benötigt werden; Das System entfernt „hängende“ Rechte.

9) Beispiel Rollenmatrix (Ausschnitt)

10) Werkzeuge und Umsetzung (Muster)

Rollenkatalog als Code: YAML/JSON im Repository + CI-Validatoren, changelog.
Zentrale IdP/SSO: SCIM-Vorführung, Gruppenzüge „group → role“.
Policy decision point: Policy Engine (ABAC) mit Kontextattributen.
Secrets/KMS: Schlüsselisolierung per Medium/Region/Tenant.
Data Gateway: Eine einzelne Maskierungs-/Audit-Schicht für DWH/BI/Exporte.
SIEM/SOAR: Korrelation 'ROLE _ UPDATE '/' READ _ PII '/' EXPORT _ DATA', Auto-Tickets.

11) Auditierung und Protokollierung

Обязательные события: `ROLE_ASSIGN`, `ROLE_REVOKE`, `ROLE_UPDATE`, `BREAK_GLASS`, `JIT_GRANT`, `READ_PII`, `EXPORT_DATA`, `PAYMENT_APPROVE`, `KYC_DECISION`.
Anforderungen: WORM-Kopie, Hash-Ketten, Paketsignatur, 'purpose '/' ticket _ id' in jedem Event, Zeitsynchronisation.

12) Metriken und KPIs/KRIs

Coverage:% der Systeme unter RBAC ≥ 95%.
SoD violations: = 0; Versuche, inkompatible Rollen zuzuweisen - Auto-Block.
JIT-Rate: ≥ 80% der Erhöhungen gehen als JIT.
Offboarding TTR: Widerruf der Rechte ≤ 15 Min.
Masked reads ratio: ≥ 95% der PII-Zugriffe sind maskiert.
Recertification: 100% der Rollen werden vierteljährlich bestätigt.
Exporte signiert: 100% der Exporte mit Signatur/Logbuch.

13) RACI (vergrößert)

14) Checklisten

Vor dem Erstellen einer Rolle

• User-stories und 'purpose' beschrieben
• Liste der Ressourcen und Datenklassen
• Mindestberechtigungen Mupping
• SoD-Validierung/Konflikte
• Masking Policy und RLS/CLS
• Re-Zertifizierungsplan und Eigentümer

Vor der Freigabe des Zugriffs

• Feste' purpose' und Frist
• SoD/Jurisdiktionen/MDM/MFA erfüllt
• Standard-Maskierung, JIT beim Boosten
• Logbuch und Revisionsdatum enthalten

15) Häufige Fehler und Anti-Muster

„Superrollen“ mit breiten Rechten statt kleiner Domains.
Direkter Zugang zur PII ohne Maskierung und 'Purpose'.
Keine SoD/vierte Augen für 'PAYMENT _ APPROVE '/' KYC _ APPROVE'.
Verlängerung der vorübergehenden Rechte „für immer“.
Kopieren von Prod-Daten in dev/stage.
Undurchsichtige Exporte ohne Signatur und Protokoll.

16) Fahrplan für die Umsetzung

Woche 1-2: Ressourcenbestand/Datenklassifizierung; Entwurfsrollenmatrix; SoD-Tabelle.
Woche 3-4: RBAC als Code (Repository), IdP-Gruppen/SCIM, ABAC-Engine (Basisattribute: Medium/Geo/MDM/Zeit), JIT/PAM, Maskierungsschicht für DWH/BI.
Monat 2: Re-Zertifizierung, Offboarding-Automatisierung, SOAR-Alerts für RBAC/SoD/ABAC-Verstöße, Exportprotokolle/WORM.
Monat 3 +: Erweiterung der Attribute (Geräterisiko, KYC-Ebene), Bias-Audits der Zugriffe, Kostenoptimierung und regelmäßige Tabletop-Übungen.

TL; DR

Starke RBAC = Small Domain Roles + Attributed Conditions (ABAC) + SoD und JIT/PAM + Masking und RLS/CLS + Hard Audit und Re-Zertifizierung. Dies reduziert das Risiko von Lecks/Missbrauch, beschleunigt die Prüfung und hält die Plattform innerhalb der Grenzen der Datenschutz- und Compliance-Anforderungen.