GH GambleHub

Kontrolle des Datenzugriffs

1) Warum ist es iGaming

Risiko und Regulierung: PII/Finanzen, grenzübergreifend, RG/AML-Anforderungen.
Geschwindigkeit und Vertrauen: Sicherer Self-Service für Analytics und ML ohne manuelle „Hände“.
Audit und Verantwortung: „Wer hat was gesehen und warum“, die Nachweisbarkeit des Grundsatzes der Mindestrechte.

2) Grundprinzipien

1. Least Privilege - nur das Richtige und für den richtigen Zeitraum.
2. Segregation of Duties (SoD) - Entwickler ≠ der den Zugang genehmigt; Analytiker ≠ Eigentümer der Daten.
3. Just-in-Time (JIT) - temporäre, automatisch widerrufbare Rechte.
4. Defense in Depth - mehrstufiger Schutz: Netzwerk → Service → Tabelle → Spalte → Zeile → Zelle.
5. Policy-as-Code - Zugriffe und Masken im Code/Repository, Revue passieren durch PR.
6. Provenance-aware - Lösungen basieren auf Katalog, Linie, Klassifizierung und Verträgen.

3) Klassifizierung der Daten

Die Klassen: Public / Internal / Confidential / Restricted (die PII/Finanzen).
Kennzeichnungen in den Diagrammen und im Verzeichnis: „pii“, „financial“, „tokenized“, „masking“, „rle“ (row-level), „cle“ (column-level), „geo = EU/TR/...“, „tenant“.

Mindestvorschriften:
  • Eingeschränkt: Token/Masken überall; Entgiftung nur im „Reinraum“ auf Antrag.
  • Vertraulich: Zugriff mit Standardmasken; Masken abnehmen - durch Begründung und JIT.
  • Intern/Öffentlich: nach Domain-Rollen, ohne PII.

4) Berechtigungsmodelle

RBAC (Bazir-Rolle.) : Schnellstart, Rollenkataloge ("Marketing-Analyst", "Risk-Ops').
ABAC (Attribut-Baser.) : Land, Marke, Medium (prod/stage), Projekt, Verarbeitungszweck, Zeit, Risikoebene.
ReBAC (für Beziehungen): „set owner“, „domain steward“, „revuer“.
Hybrid: RBAC als Rahmen, ABAC präzisiert die Grenzen.

5) Granularität des Zugangs

Netzwerk/Ingress: mTLS, allow-list, private Links.
Service/Cluster: IAM-Rollen, Servicekonto mit einem Minimum an Privilegien.
Speicher: Verzeichnisse/Diagramme/Tabellen (GRANT), Row-Level Security (RLS), Column-Level Security (CLS).
Maskierung/Tokenisierung: Dynamische Masken in SQL/BI; Token statt PII.
Fichester/ML: Zugang nur zu Aggregaten/erlaubten Fics; Merkmalsrichtlinie (allow/deny).
Dateien/Objekte: vorsignierte Links mit TTL, Verschlüsselung und Download-Richtlinien.

6) Muster für Schlüsseldomänen

KYC/AML: CLS (nur Token sichtbar), RLS nach Betreiberland; detokenization - DPO/Legal von JIT.
Zahlungen: Restricted, FLE + Token, Zugriff auf Risiko/Zahlungen-Ops über JIT; prüfbare Entladungen.
Spielevents: Intern/Vertraulich, RLS nach Marke/Region/Tenant, CLS für user_id.
Responsible Gaming: Zugriff des RG-Teams auf die Aggregate; Einzelfälle - auf Anfrage.
BI/ML: „goldene“ Vitrinen ohne PII; ML - Liste der erlaubten Begriffe, Protokoll der Ausreden für kontrovers.

7) Zugangsverfahren

7. 1 Antrag → Vereinbarung → Rückstellungen

Antragsformular: Zweck, Umfang, Laufzeit, Rolle, ABAC-Attribute, Besitzer des Sets.
Auto-Check: Datenklasse, SoD, Training bestanden? Interessenkonflikt?
RACI: Owner (R), Steward (C), DPO/Sec (A/C), IT/IAM (R).

7. 2 JIT и break-glass

JIT: 15 min/2 Stunden/1 Tag mit Auto-Rückruf; Verlängerung durch neuen Antrag.
Break-glass: für Vorfälle; separate Rollen/Schlüssel, verstärkte Prüfung, Post-Mortem erforderlich.

7. 3 Regelmäßige Reviews

Vierteljährliche Zugriffsprüfung: Domaininhaber bestätigen Rollen/Attribute.
Automatische Deaktivierung von „vergessenen“ Zugriffen (No-Use 30/60 Tage).

8) Technische Mechanismen

Katalog & Verträge: Quelle der Wahrheit über Besitzer, Klassen, Masken.
Policy Engine: OPA/Äquivalent für ABAC/Row/Column-Policy.
Data Masking: dynamische Masken in DWH/BI; Format-Safe-Masken für Telefone/E-Mail.
Tokenization: vault/FPE; Entgiftung nur im „Reinraum“.
Secrets & PAM: Secret Manager, JIT-Sitzungen, Bildschirmaufzeichnung für Admin-Zugriffe.
Audit & SIEM: Unveränderliche Protokolle (WORM), Korrelation von Zugriffsereignissen mit Sitzungen und Uploads.
Geo/Tenant-Isolatoren: physikalische/logische Trennung (Schemata, Verzeichnisse, Cluster, Verschlüsselungsschlüssel).

9) Consent & DSAR

Die Zugriffe berücksichtigen die Zustimmung des Spielers (Marketing = aus → Marketing-Attribute ausblenden).
DSAR-Buttons: per Token suchen/hochladen/löschen; das Protokoll der gesamten Operation; Legal Hold wird berücksichtigt.

10) Überwachung und SLO

Access SLO: p95 Ausgabezeit des JIT-Zugangs (z.B. ≤ 30 min).
Zero-PII in logs: 100% der Ereignisse ohne PII.
Anomalierate: Alerts bei einem SELECT-Burst oder atypischen JOIN zu Restricted.
Review Coverage: ≥ 95% der Rollen sind pünktlich.
Maske Hit-Rate: Anteil der Anfragen, bei denen die Maske/der Token ausgelöst wurde.
Detokenization MTTR: durchschnittliche Bearbeitungszeit eines gültigen Antrags.

11) Vorlagen

11. 1 Zugriffsrichtlinie (Ausschnitt)

Das Prinzip: least privilege + SoD + JIT.
Rollen: Rollenkatalog mit Aufgabenbeschreibung/Vitrinen.
ABAC-Attribute: 'country', 'brand', 'env', 'purpose', 'retention'.
Masken/Token: Standardmäßig auf Confidential/Restricted aktiv.
Revue: vierteljährlich; Auto-Rückruf von „vergessenen“ Zugriffen.
Verstöße: Lockdown, Ermittlungen, Training.

11. 2 Antragsformular

Wer: Name/Team/Manager.
Was: Satz/Tabelle/Schaukasten/fichi.
Warum: Ziel, erwartetes Ergebnis/Metriken.
Wie lange: Laufzeit/Zeitplan.
Datenklasse: (wird aus dem Verzeichnis automatisch vervollständigt).
Signaturen: Owner/Steward, DPO oder Sec (falls eingeschränkt).

11. 3 Rollenkatalog (Beispiel)

Marketing-Analyst: Interne/vertrauliche Marketing-Schaufenster; ohne Entgiftung; RLS nach Marke.
Risiko-Ops: Eingeschränkte Zahlungen mit Masken; JIT für die Entgiftung; nur über „weiße“ Vorlagen exportieren.
RG-Team: RG-Aggregate, Zugang zu Fällen auf Anfrage.
DS/ML: Fichester (allow-list fich), Sandbox ohne PII.

12) Fahrplan für die Umsetzung

0-30 Tage (MVP)

1. Klassifizierung von Daten und Labels in Schemata.
2. Rollenkatalog + grundlegende ABAC-Attribute (Land/Marke/env).
3. Standardmaskierung/Tokenisierung für Confidential/Restricted.
4. JIT-Prozess und Audit-Protokoll; break-glass Vorschriften.
5. RLS/CLS für Zahlungen, KYC, Spielereignisse; Verbot „SELECT“ für Restricted.

30-90 Tage

1. Policy-as-Code im CI (Abfrage-Linter, Blöcke bei Verstößen).
2. Integration mit Consent/DSAR; Zugriffs-SLO-Berichte.
3. Vierteljährliche Access Review; Auto-Deaktivierung.
4. PAM für Admin-Zugriffe; Aufzeichnung der Sitzungen; Zeitbox.

3-6 Monate

1. Geo/Tenant-Isolation, separate Verschlüsselungsschlüssel nach Jurisdiktionen.
2. Automatische Rollenempfehlungen basierend auf tatsächlichen Abfragen (usage-based).
3. Verhaltensanalyse des Zugangs (Anti-Anoma-Lii), SOAR-Playbooks.
4. Prozesszertifizierung und externes Audit.

13) Anti-Muster

Ein „Superuser“ für alle - ohne SoD und JIT.
Datenaufbereitung über Dateien/Screenshots außerhalb der kontrollierten Kanäle.
RLS/CLS nur „auf Papier“ - Masken aus in BI.
Keine Revue-Rechte und Auto-Recall; „ewige“ Zugänge.
Das Verzeichnis/die Verträge werden nicht aktualisiert - die Zugriffsregeln sind veraltet.
Entgiftung in Anwendungen „zur Bequemlichkeit“ ohne Audit.

14) RACI (Beispiel)

Richtlinien/Architektur: CDO/CISO (A), DPO (C), SecOps (R), Data Platform (R).
Vergabe von Zugriffen: IAM/IT (R), Owners (A/R), Stewards (C), Manager (I).
Audit/Revue: Owners (R), DPO/Sec (A), Internal Audit (C).
Vorfälle: SecOps (R), Legal/PR (C), Domains (R).

15) Verwandte Abschnitte

Datenmanagement, Daten Tokenisierung, Datensicherheit und Verschlüsselung, Datenherkunft und Pfad, Ethik/DSAR, Vertrauliche ML, Federated Learning.

Summe

Die Zugriffskontrolle ist ein System aus Richtlinien, Attributen und Automatisierung, das Teams die richtigen Daten genau in der richtigen Menge und Zeit zur Verfügung stellt und eine vollständige Traceability hinterlässt. Bei iGaming ist dies die Grundlage für das Vertrauen in Metriken, die Störfallresistenz und die Geschwindigkeit der Entscheidungsfindung.

Contact

Kontakt aufnehmen

Kontaktieren Sie uns bei Fragen oder Support.Wir helfen Ihnen jederzeit gerne!

Telegram
@Gamble_GC
Integration starten

Email ist erforderlich. Telegram oder WhatsApp – optional.

Ihr Name optional
Email optional
Betreff optional
Nachricht optional
Telegram optional
@
Wenn Sie Telegram angeben – antworten wir zusätzlich dort.
WhatsApp optional
Format: +Ländercode und Nummer (z. B. +49XXXXXXXXX).

Mit dem Klicken des Buttons stimmen Sie der Datenverarbeitung zu.