Contrôle de l'accès aux données

1) Pourquoi est-ce iGaming

Risque et réglementation : IPI/finances, transfrontalières, exigences RG/AML.
Rapidité et confiance : Analyse libre-service sécurisée et ML sans « distributions » manuelles.
Audit et responsabilité : « qui a vu et pourquoi », la probabilité du principe des droits minimums.

2) Principes de base

1. Least Privilège n'est que le bon et pour la bonne durée.
2. Segregation of Duties (SoD) est un développeur qui approuve ≠ accès ; analyste ≠ propriétaire des données.
3. Just-in-Time (JIT) - droits temporaires, révocables automatiquement.
4. Defense in Depth - Protection hiérarchisée : réseau → service → table → colonne → ligne → cellule.
5. Policy-as-Code - accès et masques dans le code/référentiel, ronfler via PR.
6. Provenance-aware - les solutions reposent sur le catalogue, la règle, la classification et les contrats.

3) Classification des données

Classes : Public/Internal/Confidentiel/Restreint (PII/Finance).
Étiquettes dans les schémas et le catalogue : « pii », « financial », « tokenized », « masking », « rle » (row-level), « cle » (column-level), « geo = EU/TR/... », « tenant ».

• Restreint : jetons/masques partout ; désintoxication uniquement dans la « zone propre » de la demande.
• Confidentiel : accès avec les masques par défaut ; retrait des masques - par la justification et le JIT.
• Internal/Public : par rôle de domaine, sans PII.

4) Modèles d'autorisation

RBAC (rôle-bazir.) : Démarrage rapide, catalogues de rôles (« Marketing-Analyst », « Risk-Ops »).
ABAC (attribut basir.) : pays, marque, environnement (prod/stage), projet, finalité du traitement, temps, niveau de risque.
ReBAC (par relation) : « propriétaire du recrutement », « steward du domaine », « revuer ».
Hybride : RBAC comme cadre, ABAC précise les limites.

5) Granularité d'accès

Réseau/ingress : mTLS, allow-list, liens privés.
Service/cluster : Rôle IAM, compte service avec un minimum de privilèges.
Référentiels : Répertoires/schémas/tables (GRANT), Row-Level Security (RLS), Column-Level Security (CLS).
Masquage/Tokenization : masques dynamiques en SQL/BI ; jetons au lieu de PII.
Fichestor/ML : accès uniquement aux unités/fiches autorisées ; politique des signes (allow/deny).
Fichiers/objets : liens pré-signés avec TTL, cryptage et politique de téléchargement.

6) Modèles pour les domaines clés

KYC/AML : CLS (seuls les tokens sont visibles), RLS par pays d'opérateur ; désintoxication - DPO/Legal par JIT.
Paiements : Restreints, jetons FLE +, accès Risk/Payments-Ops via JIT ; déchargement vérifiable.
Événements de jeu : Internal/Confidentiel, RLS par marque/région/tenant, CLS pour user_id.
Jeu responsable : accès de l'équipe RG aux agrégats ; cas individuels - sur demande.
BI/ML : vitrines « dorées » sans PII ; ML est la liste des fiches autorisées, le journal des excuses pour les polémiques.

7) Procédures d'accès

7. 1 Demande → accord → provisions

Formulaire de demande : objectif, portée, durée, rôle, attributs ABAC, titulaire du recrutement.
Essai automatique : classe de données, SoD, formation terminée ? conflit d'intérêts ?
RACI: Owner (R), Steward (C), DPO/Sec (A/C), IT/IAM (R).

7. 2 JIT и break-glass

JIT : 15 min/2 heures/1 jour avec auto-rappel ; renouvellement - pour une nouvelle demande.
Break-glass : pour les incidents ; rôles/clés séparés, audit renforcé, post mortem obligatoire.

7. 3 Revues régulières

Revue trimestrielle d'accès : les propriétaires de domaine confirment les rôles/attributs.
Auto-désactivation des accès « oubliés » (no-use 30/60 jours).

8) Mécanismes techniques

Catalogue & Contrats : source de vérité sur les propriétaires, les classes, les masques.
Moteur de politique : ORA/équivalent pour ABAC/Row/Column-policy.
Data Masking : masques dynamiques en DWH/BI ; Format de masque de coffre-fort pour les téléphones/email.
Tokenization: vault/FPE; désintoxication uniquement dans la « zone propre ».
Secrets & PAM : gestionnaire secret, sessions JIT, enregistrement des écrans pour les accès admin.
Audit & SIEM : logs immuables (WORM), corrélation des événements d'accès avec les sessions et les téléchargements.
Geo/tenant-isolants : Fi/division logique (schémas, répertoires, clusters, clés de chiffrement).

9) Consent & DSAR

Les accès tiennent compte du consentement du joueur (marketing = off → masquer les attributs marketing).
Boutons DSAR : rechercher/décharger/supprimer par token ; le journal de toute l'opération ; Legal Hold est pris en compte.

10) Surveillance et SLO

Access SLO : p95 du temps de la distribution du JIT-accès (par ex., ≤ 30 mines).
Zero-PII in logs : 100 % des événements sans PII.
Taux d'anomalie : alertes en cas d'éclatement de SELECT ou de JOIN atypique à restreint.
Review Coverage : ≥ 95 % des rôles sont revus à temps.
Mask Hit-Rate : proportion des requêtes où le masque/jeton a fonctionné.
Detokenization MTR : temps moyen de traitement de la demande validée.

11) Modèles

11. 1 Politique d'accès (fragment)

Principe : least privilège + SoD + JIT.
Rôles : répertoire des rôles avec description des tâches/vitrines.
Attributs ABAC : 'country', 'brand', 'bou', 'purpose', 'retentation'.
Masques/tokens : sont actifs par défaut sur Confidentiel/Restreint.
Revue : trimestrielle ; auto-révocation des accès « oubliés ».
Violations : blocage, enquête, formation.

11. 2 Formulaire de demande

Qui : Nom/équipe/gestionnaire.
Quoi : kit/table/vitrine/fichi.
Pourquoi : objectif, résultat attendu/métrique.
Combien de temps : délai/horaire.
Classe de données : (auto-rempli à partir du catalogue).
Signatures : Owner/Steward, DPO ou Sec (si restreinte).

11. 3 Répertoire des rôles (exemple)

Analyste marketing : Vitrines de marketing interne/confidentiel ; sans désintoxication ; RLS par marque.
Risk-Ops : Paiements restreints avec des masques ; JIT pour la désintoxication ; Exporter uniquement via des modèles « blancs ».
RG-Team : unités RG, accès aux mallettes sur demande.
DS/ML : fichestor (allow-list fich), sandbox sans PII.

12) Feuille de route pour la mise en œuvre

0-30 jours (MVP)

1. Classification des données et des étiquettes dans les schémas.
2. Répertoire des rôles + attributs ABAC de base (pays/marque/bou).
3. Masquage/Tokenization par défaut pour Confidentiel/Restreint.
4. Processus JIT et journal d'audit ; règlement break-glass.
5. RLS/CLS pour les paiements, KYC, événements de jeu ; l'interdiction de 'SELECT' pour Restricted.

30-90 jours

1. Policy-as-Code dans CI (linter de requête, blocs en cas de violation).
2. Intégration avec Consent/DSAR ; rapports sur l'accès SLO.
3. Examen trimestriel de l'accès ; auto-désactivation.
4. PAM pour les accès admin ; enregistrement des sessions ; La boxe temporelle.

3-6 mois

1. Géo/tenant-isolation, clés de cryptage séparées par juridiction.
2. Auto-recommandations de rôles basées sur des requêtes réelles (utilisation-basée).
3. Analyse comportementale de l'accès (anti-anome), SOAR-playbooks.
4. Certification des processus et audit externe.

13) Anti-modèles

« Superutilisateur » pour tout le monde - sans SoD et JIT.
Déchirez les données à travers des fichiers/captures d'écran en dehors des canaux surveillés.
RLS/CLS uniquement « sur papier » - les masques sont éteints en BI.
Pas de droits et de révocation automatique ; les accès « éternels ».
Le catalogue/les contrats ne sont pas mis à jour - les règles d'accès sont obsolètes.
Désintoxication dans les applications « pour la commodité » sans audit.

14) RACI (exemple)

Politiques/architecture : CDO/CISO (A), DPO (C), SecOps (R), Data Platform (R).
Délivrance d'accès : IAM/IT (R), Owners (A/R), Stewards (C), Gestionnaires (I).
Audit/revues : Owners (R), DPO/Sec (A), Audit interne (C).
Incidents : SecOps (R), Legal/PR (C), Domaines (R).

15) Sections connexes

Gestion des données, Tokenization des données, Sécurité des données et cryptage, Origine et chemin des données, Éthique/DSAR, Confidentiel ML, Federated Learning.

Résultat

Le contrôle d'accès est un système de politiques, d'attributs et d'automatisation qui donne aux équipes les données dont elles ont besoin exactement dans la quantité et le temps nécessaires, tout en laissant une traçabilité complète. Dans iGaming, c'est la base de la confiance dans les métriques, la résistance aux incidents et la rapidité de la prise de décision.