Rollenspiel-Engine

1) Berechtigungsmodelle

RBAC (Role-Based Access Control): Das Subjekt erhält Rollen, die Rollen sind mit Rechten verbunden (permissions). Einfach zu verwalten, gut für typische Aufgaben.
ABAC (Attribute-Based Access Control): Die Entscheidung hängt von den Attributen Subjekt, Ressource, Aktion und Umgebung (Zeit, IP, Region, Risiko) ab. Flexibel und skalierbar auf komplexe Regeln.
RBAC + ABAC Hybrid: Rollen geben die „Basis“ Fähigkeit, Attribute verengen sie (Bedingungen).
(Optional) ReBAC/beziehungsbasiert: Beziehungsgraph (Eigentümer, Teammitglied, Delegierter), nützlich für Dokumenten- und Orgastrukturen.

2) Architektur: PDP/PEP und Threads

PEP (Policy Enforcement Point): Anwendungsort der Lösung (API-Gateway, Backend-Methode, SQL-Layer, UI).
PDP (Policy Decision Point): Ein Dienst/eine Bibliothek, der/die' ALLOW/DENY 'anhand von Richtlinien und Attributen berechnet.
PIP (Policy Information Point): Attributquellen (IdP/Profil, Ressourcenmetadaten, Risikoabfrage, Geo).
PAP (Policy Administration Point): Administrative Schnittstelle/Policy Repository (Versionen, Entwürfe, Veröffentlichung).

Thread: Die Abfrage → PEP bildet den Kontext → PDP zieht die fehlenden Attribute nach oben (über PIP) → berechnet die Lösung → PEP wendet → Audit an (erlauben/verbieten/Felder abschneiden).

3) Datenmodell

• `subject` (user/service) с атрибутами: `tenant_id`, `roles`, `departments`, `risk_level`, `mfa_verified`, `scopes`, `claims`.
• „resource“ mit Typ und Attributen: „type“, „owner _ id“, „tenant _ id“, „classification“ (public/confidential), „region“, „tags“.
• `action`: `read`, `write`, `delete`, `export`, `approve`, `impersonate` и т. п.
• `environment`: `time`, `ip`, `device`, `geo`, `auth_strength`, `business_context` (канал, тариф).

• 'roles (id, tenant_id, name, inherits [])' - Unterstützen Sie Hierarchien und Muster.
• `permissions(id, resource_type, action, constraint?)`.
• `role_permissions(role_id, permission_id)`.
• 'assignments (subject_id, role_id, scope)' - scope: global/projektbezogen/objektbezogen.

• `policy(id, effect=allow|deny, target: {subject, resource, action}, condition: expr, priority, version, status)`.

4) Entscheidungsgrundsätze

Deny-overrides: Explizite Verbote sind prioritärer als Genehmigungen.
Least Privilege (PoLP): Geben Sie den minimal erforderlichen Zugriff, erweitern Sie durch Bedingungen.
Trennung der Pflichten (SoD): Verbot von Rollen-/Aktionskombinationen (z. B. „Zahlung erstellt“ ≠ „aufgerollt“).
Context-aware: Stärkung der Anforderungen bei erhöhtem Risiko (kein MFA, verdächtige IP).
Determinismus: der gleiche Kontext → die gleiche Antwort; Schreiben Sie die Richtlinienversion in das Protokoll.

5) Implementierungsmuster

5. 1 Hybrid RBAC→ABAC (Konditionierung)

yaml
Declarative Policy Example
- id: doc_read_own effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","owner"] }
condition: resource. owner_id == subject. id

- id: doc_read_team effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","viewer"] }
condition: subject. team_id in resource. shared_team_ids

- id: doc_read_confidential_external effect: deny target: { action: read, resource. type: document }
condition: resource. classification == "confidential" and subject. tenant_id!= resource. tenant_id priority: 100 # deny high priority

5. 2 Row/Field-Level Security

Auf DB-Ebene: RLS-Richtlinien (von 'tenant _ id', 'owner _ id').
Auf API-Ebene: Filtern Sie Sammlungen und maskieren Sie Felder, wenn es kein 'allow: read_sensitive_fields'' gibt.

5. 3 „Step-up“ -Lösungen

allow if action == "export" and subject. mfa_verified == true else deny

5. 4 Zeitliche Toleranzen

Zuschüsse mit TTL: 'Zuweisung. expires_at', „Fenster“ des Zugriffs (während der Arbeitszeit der Ressourcenregion).

6) Leistung und Caching

Entscheidungscache nach Schlüssel'(subject_hash, resource_key, Aktion, policy_version) 'mit kurzer TTL.
Edge-Cache der Attribute des Subjekts (claims im Token) + lazy-fetch der Attribute der Ressource.
Inkrementelle Invalidation: Behinderung durch Ereignisse (Rollenwechsel, Richtlinienwechsel, Übersetzung einer Ressource in „vertraulich“).
Batch-Checks: für Listen - mit einem „Filter“ (Policy-Predicate-Pushdown) auswerten, um die PDP nicht zeilenweise zu ziehen.

7) Multi-Leasing (Multi-tenant)

In jeder Tabelle „tenant _ id“; Standardrichtlinien beschränken den Zugriff innerhalb des Leasings.
Lease-Administratoren verwalten nur die Rollen/Rechte ihrer Lease.
Mietenübergreifender Zugang - ausschließlich über explizite Einladungen/Sharing mit expliziter Deny-Override.

8) Richtlinienverwaltung und Lebenszyklus

Versionierung: 'policy. version 'in der PDP-Antwort, im Audit speichern.
Umgebungen: draft → canary (Teile des Verkehrs/Schatten-Modus) → prod.
Testmatrix: Wahrheitstabellen nach Schlüsselrollen/Attributen (Vertragstests).
Change Management: Requests für Richtlinien mit Sicherheits-/Compliance-Reviews.

9) Auditierung und Beobachtbarkeit

Журнал решений: `decision_id`, `subject`, `action`, `resource_ref`, `result`, `matched_policies`, `policy_version`, `attributes_digest`.
Metriken: QPS-PDP, p95-Latenz, Cache-Hit-Rate, Deny-Anteil, Step-up-Frequenz, SoD-Vorfälle.
Traces: span auf PDP-Aufruf; Korrelation mit der API-Anforderung.
Replik: Die Fähigkeit, historische Entscheidungen auf einer neuen Version der Richtlinie (Sicherheitscheck) zu „wiederholen“.

10) Integration mit Authentifizierung und Token

Identität ist von IdP (OIDC/SAML). Token tragen ein Minimum an Attributen: 'sub', 'tenant', 'roles', 'auth _ time', 'amr', 'scopes'.
Für ABAC, ziehen Sie die „schweren“ Zeichen auf der Server-Seite (PIP), um zu vermeiden, dass das Token aufgeblasen wird.
Signierte Resource Token (Capability/Einladungen) - für streng limitierte Delegationen.

11) PDP Pseudocode (vereinfacht)

python def decide(subject, resource, action, env, policies):
matched = []
effect = "deny"
Explicit DENYs with priority for p in sorted (policies, key = lambda x: x.priority, reverse = True):
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
if p. effect == "deny":
return Decision("deny", matched, p. version)
Looking for ALLOW for p in policies:
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
effect = "allow"
break return Decision(effect, matched, max_version(matched, policies))

12) Anti-Muster

„Rolle = Seite“ (Hunderte kleiner Rollen ohne Fachbereichsmodell).
Richtlinien nur im Code ohne Versionen/Überwachung speichern.
Das Fehlen von Deny-Override und SoD → ein erhöhtes Betrugsrisiko.
Starre' user _ id '-Listen in Regeln (anstelle von Attributen/Beziehungen).
Keine Filterung auf Datenebene (RLS), wenn nur in der Benutzeroberfläche ein Filter vorhanden ist.
Synchronisation der Rollen durch manuelle Skripte ohne Ereignisse und Caches-Behinderung.

13) Fälle und Rezepte

13. 1 Feldebene Maskierung:

allow read invoice when subject. roles includes "support"
mask fields ["card_last4", "billing_email"] unless subject. role == "finance"

13. 2 Datenexport nur mit MFA:

allow export if subject. mfa_verified and env. ip in cidr("203. 0. 113. 0/24")

13. 3 SoD:

deny approve_payment if subject. performed_actions includes ("create_payment" within last 24h)

13. 4 Delegierung (eingeschränktes Token):

Der Capability-Token enthält' resource _ id', 'actions = [“ read“]', 'expires _ at', 'aud'. PEP prüft die Unterschrift und die Frist.

14) Testen

Einheitstests eines Politikers: Wahrheitstabellen für die Hauptkombinationen.
Property-based: Generieren Sie zufällige Attribute, um nach „Löchern“ zu suchen.
Golden-Tests: Fixierung einer Reihe von Lösungen für kritische Endpunkte.
Canary/Shadow: Parallele Auswertung alter und neuer Richtlinienversionen mit Protokollierung von Abweichungen.

15) Verwandte Fähigkeiten des Abschnitts „Architektur und Protokolle“

Authentifizierung und Autorisierung (OIDC/OAuth2)

Verwaltung von Einwilligungen

Tokenisierung und Schlüsselverwaltung

Beobachtbarkeit: Protokolle, Metriken, Traces

Geo-Routing und Lokalisierung

Verschlüsselung bei Rest/In Transit

16) Checkliste des Architekten

1. Sind die Themenrollen und ihre Hierarchien definiert?
2. Gibt es ein Hybridmodell: Rollen + Bedingungen auf Attributen?
3. PDP mit deny-overrides, SoD und Step-up umgesetzt?
4. Wo ist PEP? (Gateway, Backend, DB, UI) - überall einheitlich?
5. Lösungscaches und Behinderung nach Ereignissen eingerichtet?
6. Werden Politiker versioniert, getestet, im Prozess ausgerollt?
7. Sind Entscheidungsaudits, Metriken und Traces enthalten?
8. Multiarrangement und RLS/Field-Masking werden unterstützt?
9. Gibt es ein Runbook auf Vorfälle und Regression Politiker?

Schluss

RBAC sorgt für Steuerbarkeit, ABAC für Kontext und Präzision. Durch die Kombination von Rollen mit Attributbedingungen, die gemeinsame Nutzung von PDP/PEP, die Implementierung von Caching, Auditing und Richtlinientests bauen Sie die Autorisierung als Plattformfähigkeit auf: vorhersehbar, überprüfbar und skalierbar für Produkt- und Regulierungsanforderungen.