Segmentierung von Privilegien

1) Warum Segmentierung notwendig ist

Die Segmentierung von Privilegien ist der Schlüssel zur Verringerung des „Blast Radius“ von Fehlern und Insidermissbrauch. Es ermöglicht Ihnen, genau zu begrenzen, wer und wo welche Aktionen mit welchen Daten durchführen kann, während die Geschwindigkeit der Operationen und die Einhaltung der Anforderungen der Aufsichtsbehörden beibehalten werden.

• weniger Vorfälle aufgrund von „überflüssigen Rechten“;
• Beschleunigung der Untersuchungen: der Zugang ist transparent und erklärbar;
• Einhaltung der SoD/Compliance, nachweisbares Audit;
• sichere Experimente und schnelle Releases ohne Risiko für den Prod-Core.

2) Grundsätze

Zero Trust: Jede Aktion wird kontextbezogen geprüft; Es gibt keine „vertrauenswürdigen Zonen“.
Least Privilege: Mindestrechte für eine Mindestlaufzeit (idealerweise JIT).
Kontext über Rolle: Rechte hängen nicht nur von der Rolle ab, sondern auch von den Attributen (Tenant, Region, Umgebung, Risiko).
Segregation of Duties (SoD): Trennung von Initiierung, Genehmigung, Ausführung und Audit.
Policy-as-Code: Richtlinien im Code mit Versionierung, Tests und Reviews.

3) Zugangsreifemodell

1. RBAC (Rollen): Start - feste Rollen (Support, Risiko, Zahlungen, Handel, Ops, SRE, Compliance).
2. ABAC (Attribute): Attribute hinzufügen: Tenant, Region, Gerichtsbarkeit, Produkt, Kanal, Umgebung (prod/stage/dev), Zeit, Risikoklasse Betrieb, KRI-Signale.
3. PBAC (policy-based): zentralisierte „Wer/Was/Wo/Wann/Warum“ -Richtlinien + Bedingungen (z.B. „In der Produktion - nur per JIT und mit Ticket“).

4) Segmentierungsbereiche (Achse für Achse)

4. 1 Tenant/Kunde

Zugang und Betrieb sind auf eine bestimmte Marke/Betreiber/Affiliate beschränkt.
Cross-Tenant-Aktionen sind verboten, außer bei streng definierten PII-freien Aggregationen.

4. 2 Region/Gerichtsbarkeit

Die Politik berücksichtigt die lokalen Lizenz- und KYC/AML-Regeln.
Transaktionen mit Spielerdaten sind auf die geografische Speicherung und Verarbeitung beschränkt.

4. 3 Umgebung (dev/stage/prod)

Prod isoliert: separate Credits, Netzwerke, Bastion/PAM, „read-only default“.
Zugang zu prod nur JIT, mit Ticket und Änderungsfenstern.

4. 4 Datenklasse

PII/Finanzen/Gaming Telemetrie/Techlogs - verschiedene Ebenen des Zugangs und der Maskierung.
Der PII-Export erfolgt nur über zugelassene verschlüsselte Workflows und TTL.

4. 5 Kritikalität der Operationen

Klassen P1/P2/P3: Veröffentlichung von Koeffizienten, manuelle Verrechnungen, Schlussfolgerungen, Wechsel des PSP-Routings - erfordern eine duale Steuerung.
Risikoarme Operationen können durch die Politik automatisch ausgelöst werden.

5) Berechtigungsstufen (tiers)

Viewer: Nur lesende Aggregate und maskierte Daten.
Operator: Runbook-Routinen ausführen, ohne die Konfigurationen zu ändern.
Contributor: Konfiguration in nicht kritischen Domänen ändern.
Approver: Genehmigung von Anträgen und High-Risk-Operationen (nicht mit der Ausführung kombiniert - SoD).
Admin (JIT): Kurzfristiger Boost für seltene Aufgaben unter Dual Control und Session Record.

6) SoD und inkompatible Rollen

• Initiieren Sie Schlussfolgerungen ≠ genehmigen Sie ≠ führen Sie sie endgültig durch.
• Erstellen Sie eine Bonuskampagne ≠ aktivieren Sie sie im Angebot ≠ ändern Sie die Limits.
• Entwickeln Sie Fitu ≠ Appruvit Release ≠ Roll-out in prod.
• PII-Upload anfordern ≠ genehmigen ≠ entschlüsseln.

Für jedes Paar gibt es eine formalisierte Verbots- und Ausschlusspolitik mit Revisionsdatum.

7) JIT-Zugang und PAM

Elevation auf Anfrage: Ziel/Ticket/Termin angegeben; nach Ablauf - Auto-Rückruf.
Dual Control: P1/P2 Aktionen - zwei Appruver aus verschiedenen Funktionen.
Sitzungskontrolle: Aufzeichnung kritischer Sitzungen, Anomaliealerts, Verbot von Copypasta bei der Arbeit mit PII.
Break-glass: Notfallzugang mit engen Grenzen und obligatorischem Post-Audit.

8) Servicekonten und APIs

Minimale Zusammenschlüsse; Trennung nach Aufgaben/Microservices; kurzlebige Token/Zertifikate.
Rotation von Geheimnissen, Verbot von geteilten Geheimnissen; Verbot von „god-scope“.
Limits für Rate/Quotas, Idempotency-Schlüssel, Webhook-Signatur (HMAC).

9) Segmentierung auf Infrastrukturebene

Netzwerke: Segmentisolierung (per-domain/per-tenant), Standard-egress-Verbot, mTLS.
Kubernetes/Cloud: Nijmspaces/Projekte per-Umgebung und Domain, Gatekeeper/OPA zum Verbot von gefährlichen Mustern.
DB/Caches: Access Broker (DB Proxy/IAM), standardmäßig nur lesen, DDL-Verbot in der Produktion außerhalb des Fensters.
Speicher: verschiedene Schlüssel/Buckets pro Datenklasse mit TTL- und WORM-Richtlinien für die Prüfung.

10) Richtlinien als Code (PaC)

Richtlinien in Repositories (Rego/YAML), PR-Revue, Auto-Tests (unit/e2e), Diff-Audit.
Dynamischer Kontext: Tageszeit, Standort, KRI-Level, Risikobewertung der Operation.
Erklärbarkeit der Entscheidung allow/deny und Verweis auf die Politik im Audit.

11) Protokolle und Audits

Vollständigkeit: Wer/Was/Wo/Wann/Warum, Vor-/Nachwerte, Ticket-ID.
Unverträglichkeit: zentrale Sammlung, WORM/immutable, Signatur von Datensätzen.
Konnektivität: Kette aus Admin-Konsole → API → DB → externen Anbietern.
Audit SLA: Reaktionsgeschwindigkeit auf Anfragen der Steuerung/des Reglers.

12) Dashboards und Metriken (KPI/KRI)

Zugriffs-KPIs: JIT-Anteil vs. persistente Rechte, durchschnittliche Privilegiendauer,% der abgedeckten SoDs, Bearbeitungszeit der Anträge, Abdeckung der Rezertifizierungen.
KRI Missbrauch: Ausbrüche von sensiblen Operationen, Massenentladungen, atypische Standorte/Stunden, Sequenzen von „zayavka→deystviye→otkat“.
Exec-Dashboard: Status-Track von Hochrisiko-Rollen, Break-Glass-Events, Trends.

13) Politische Beispiele (Skizzen)

Prod-операции: `allow if role in {Operator, Admin} AND env=prod AND jit=true AND ticket!=null AND sod_ok AND time in ChangeWindow`.
Экспорт PII: `allow if data_class=PII AND purpose in ApprovedPurposes AND ttl<=7d AND encryption=ON AND approvers>=2`.
PSP-роутинг: `allow if action=UpdateRouting AND dual_control AND risk_assessment_passed AND rollback_plan_attached`.

14) Umsetzungsfahrplan (8-12 Wochen)

Ned. 1-2: Betriebs-/Rollen-/Dateninventar, SoD-Matrix, Datenklassifizierung und Segmentierungsdomänen.
Ned. 3-4: RBAC-Basis, Rollenkatalog, JIT für Prod-Konsolen, Start PaC (OPA/Gatekeeper).
Ned. 5-6: ABAC: Attribute Tenant/Region/Umgebung/Datenklasse; Trennung von Neimspaces/Projekten.
Ned. 7-8: PAM (JIT-Elevation, Session Recording, Break-Glass), DDL-Verbot und DB-Broker, PII-Exportrichtlinien.
Ned. 9-10: PBAC für risikoreiche Operationen (Schlussfolgerungen, Boni, PSP), Dual-Control, KRI-Alerts.
Ned. 11-12: vierteljährliche Rezertifizierung, Abdeckung von 100% hochriskanten PaC-Operationen, Berichterstattung und Schulung.

15) Artefakte

Role Catalog: Rollen, Mindestprivilegien, Besitzer.
Matrix-SoD: inkompatible Rollen/Operationen, Ausnahmen, Override-Prozess.
Policy Pack: Eine Reihe von PaC-Richtlinien mit Tests und Deny/Allow-Beispielen.
Access Request Form: Zweck, Laufzeit, Objekt (Tenant/Region/Umgebung), Risikobewertung, Appruver.
Sensitive Ops Register: Liste der P1/P2 Aktionen, Fenster, Dual-Control-Kriterien.
Audit Playbook: Sammeln und Bereitstellen von Protokollen, SLA-Antwort, Rollen.

16) Antipatterns

Permanente Admin-Rechte und allgemeine Regeln.
Tenantenübergreifende Zugänge „zur Bequemlichkeit“.
Keine Isolierung prod/stage/dev.
Policies auf Papier ohne Enforce in Code/Konsolen.
PII-Export nach manueller Vereinbarung ohne Verschlüsselung und TTL.
Fehlende Rezertifizierungen und „hängende“ Rechte.

17) Das Ergebnis

Bei der Privilegiensegmentierung geht es nicht nur um die „richtigen Rollen“. Dies ist eine mehrdimensionale Isolation (Tenant, Region, Umgebung, Daten, Kritikalität) + dynamischer Kontext (ABAC/PBAC) + Prozesse (SoD, JIT, Rezertifizierung) + technischer Zwang (PaC, PAM, Netzwerke/DB). Eine solche Schaltung reduziert das Risiko von Fehlern und Missbrauch drastisch, beschleunigt sichere Änderungen und macht die Plattform resistent gegen Skalen- und Regulierungsanforderungen.