Sécurité des données et cryptage

1) Pourquoi est-ce critique dans iGaming

La plate-forme iGaming fonctionne avec PII, les détails financiers, les sessions de jeu, les signes comportementaux, les signaux anti-fraud et les modèles ML. La fuite ou la substitution de ces données entraîne des amendes, des blocages de marchés, des dommages à la réputation et une régression des métriques (GGR, rétention).

• Confidentialité (accès minimum aux IPI/finances).
• Intégrité (protection contre la substitution et les données « sales »).
• Accessibilité (SLO en lecture/écriture, plans DR).
• Traçabilité (qui a regardé/changé quoi et quand).

2) Modèle de menace (raccourci)

Externe : compromis API/intégrations, MITM, ransomware, fournisseurs (chaîne d'approvisionnement).
Interne : excès de droits, déchargement « ombragé », logs toxiques, erreurs de configuration.
Données et ML : échange d'événements/fich, inversion de modèle, inference de membre.
Compétences : restrictions transfrontalières, exigences locales en matière de stockage et d'élimination.

3) Cryptage en transit (In Transit)

TLS 1. 2+/1. 3 seulement, désactiver les chiffrements faibles ; Préférence pour TLS 1. 3.
mTLS pour S2S (core↔data lake↔catalog↔feature store↔providers).
PFS (ECDHE) - obligatoire.
Certification pinning sur les clients mobiles/de bureau et les intégrations critiques.
Signature API des requêtes aux fournisseurs/PSP (HMAC-SHA-256) et contrôle des temps/répétitions (nonce, clés d'identité).

4) Cryptage stocké (At Rest)

• Cryptage des volumes/objets dans le cloud/K8s (transparent, mais ne protège pas de la lecture « légitime » par le service compromis).

• TDE (Transparent Data Encryption) est une couche de base.
• FLE/Column-level AEAD pour les champs « chauds » (email, téléphone, tokens PAN) : AES-256-GCM ou ChaCha20-Poly1305.
• Row-level clés pour les enregistrements particulièrement sensibles (VIP, paiements).

• Encryption Envelope (KMS-managed DEK, rotation), contrôle d'accès aux clés.
• Signature des manifestes et contrôle de l'intégrité (hash/checksum, arbres Merkle pour les paquets).

5) Choix cryptographique (pratique)

Chiffrement symétrique : AES-GCM/ChaCha20-Poly1305 (AEAD) avec nonce/IV unique ; stocker 'ciphertext + auth tag'.
Hachage : SHA-256/512 pour l'intégrité ; pour les mots de passe - Argon2id (ou bcrypt/scrypt) avec paramétrage et sel.
Signature : Ed25519/ECDSA P-256 pour les artefacts/paquets ; HMAC-SHA-256 pour la signature API.
Principaux arrangements : ECDH (P-256/Curve25519).

6) Gestion des clés (KMS/HSM)

KMS + HSM pour générer/stocker des clés maîtres ; envelope encryption pour DEK.
Rotation : régulière (calendrier) et par événement (incident). Prise en charge de la double lecture pendant la période de migration.
Séparation des tâches (SoD), M-of-N pour « break-glass », journal de toutes les opérations.
Split-key/Shamir pour des secrets particulièrement critiques (comme la signature de pei-out).
Clés géo-scoping : différentes clés pour les régions/marques.

7) Gestion des secrets

Gestionnaire de secrets centralisé (pas dans les variables d'environnement du référentiel).
Les secrets JIT (à courte durée de vie), la rotation automatique et la révocation.
Sidecar/CSI pour la livraison de secrets aux pods de K8s.
Interdiction des logs/trajets secrets ; détecteurs de fuites en CI.

8) Intégrité et confiance dans les données

Signature d'événements/paquets (producteur) et vérification (consumer).
Event-idempotence et clés uniques pour l'anti-replay.
Contrôle des schémas (Schema Registry, compatibilité), Data Contracts en tant que « limites de confiance ».
Stockage WORM pour les journaux critiques et les rapports.

9) Tokenization, masquage et DLP

Tokenization PII/Finance (vault/FPE/DET) - utilisation de tokens dans les logs, les vitrines, les features.
Masquage en UI et déchargement ; révision du PII dans les textes des tiquets/chats (NLP-assainissement).
Politiques DLP : modèles interdits (PAN, IBAN, passeport), unité de déchargement, inspection du courrier/FTP/S3.

10) Accès et audit

RBAC/ABAC : rôle + attributs (pays, marque, environnement) ; les droits les plus faibles.
Accès JIT avec rappel automatique ; une fois tous les N jours, j'ai raison.
mTLS + IP allowlist pour les panneaux d'administration et les points de fin critiques.
Audit-logs immuables (WORM/append-only), corrélation avec SIEM.
Break-glass : rôles/clés individuels, post-mortem obligatoire.

11) Sauvegarde et DR

3-2-1 : 3 copies, 2 supports différents/CSD, 1 hors ligne/isolé (air-gapped).
Cryptage des backaps avec vos propres clés (pas le fournisseur), test de récupération programmé.
RPO/RTO pour les domaines (paiements <X min, événements de jeux <Y min).
Réplication régionale avec crypto-isolation des clés et des réseaux.

12) Vie privée et conformité

Classification des données (Public/Internal/Confidentiel/Restreint).
Minimisation et ligament cible (KYC, AML, RG, rapports).
Politiques de stockage et de suppression : graphiques, Legal Hold, DSAR ; crypto-effacement.
Transfrontalité : Géosonage et cas de stockage local.

13) Observabilité de la sécurité des données

Zero-PII dans les logs (métriques de couverture), alertes lorsque le DLP est déclenché.
Santé clé : rotations, pannes de cryptage, anomalies KMS/HSM.
Integrity SLI : Proportion de paquets/événements signés et vérifiés par signature-checks.
Latency SLO : p95 tokenization/détocalisation, chiffrement/déchiffrement.
Accès SLO : proportion de demandes JIT traitées à l'heure cible.

14) Outils et couches technologiques (catégories)

KMS/HSM : clés maîtres, envelope, signature.
Gestionnaire de secrets : Secrets JIT, rotation.
Terminaison TLS/mTLS-mesh : ingress/service mesh.
DLP/Masking : inspection, assainissement.
Schema Registry/Contrats : compatibilité, interdictions PII.
SIEM/SOAR : corrélation audit-logs, réactions automatiques.
Backup/DR : orchestration backup, test de récupération.

15) Modèles (prêts à l'emploi)

15. 1 Stratégie de chiffrement (fragment)

Algorithmes : AES-256-GCM/ChaCha20-Poly1305 ; Signature du Ed25519 ; hash SHA-256.
Clés : génération en HSM ; rotation de 90 jours ou en cas d'incident ; geo-scoped.
Accès : comptes de service uniquement via mTLS ; Jetons JIT.
Journaux : Mode WORM ; stockage ≥ N mois.
Exceptions : sur décision du CISO/DPO, avec enregistrement de la justification.

15. 2 Passeport de l'ensemble de données à protéger

Domaine/table : payments. transactions

Classe : Restreint (finances)

Chiffrement : FLE (AES-GCM) par champs 'card_token', 'iban', 'payer_id'

Clés : DEK par champ (envelope KMS)

Tokenization : vault tokens pour PAN/phone/email

Accès : ABAC (pays, rôle « Paiements-Ops »), JIT

Journaux : signature de paquet, WORM, rétention 2 ans

15. 3 Checklist de sortie des données

• Le contrat interdit les PII dans les zones « grises », les champs sont marqués « pii/tokenized »
• TLS 1. 3 et mTLS par S2S inclus
• FLE/TDE configurés, clés dans KMS/HSM, rotation active
• Les règles DLP et le masquage des logs sont testés
• Backaps sont cryptés, test de récupération vérifié
• Le SIEM reçoit des logs d'audit ; alertes pour une tentative de désintoxication en dehors de la « zone propre »

16) Feuille de route pour la mise en œuvre

0-30 jours (MVP)

1. Classification des données et carte des flux (PII/Finances/ML).
2. Activer TLS 1. 3/mTLS pour S2S ; l'interdiction des cryptomonnaies faibles.
3. Soulever le KMS/HSM ; convertir les clés en schéma envelope.
4. Activer TDE et FLE pour 3 domaines critiques (Payments/KYC/RG).
5. Masquage des logs et règles DLP de base ; certification Zero-PII.

30-90 jours

1. Tokenisation PII/Finances (vault/FPE) ; Accès JIT et audit de désintoxication.
2. Signature des événements et contrôles d'integrity dans ingestion/ETL.
3. Rotation régulière des clés, split-key pour les paiements VIP.
4. Backaps : 3-2-1, copie hors ligne, mensuelle restore-day.
5. Dashboards SLO (Zero-PII, Integrity, Key-Health, Latinity).

3-6 mois

1. Clés/données géo-scopées par pays ; les politiques transfrontalières.
2. Stockage WORM pour l'audit/rapport ; SOAR-playbooks.
3. Couverture complète avec des tokens analytiques/ML ; interdiction des PII dans les vitrines.
4. Exercice trimestriel : simulation d'incident (ransomware, key leak, data poisoning).
5. Reconfiguration annuelle et audit externe.

17) RACI (exemple)

Politiques et contrôles : CISO/CDO (A), DPO (C), SecOps (R), Domain Owners (C).
Clés/KMS/HSM: Security/Platform (R), CTO (A), Audit (C).
Tokenization/DLP : Data Platform (R), DPO (A), Domaines (C).
Backups/DR : SRE (R), CIO (A).
Surveillance/incidents : SecOps (R), SOAR (R), Legal/PR (C).

18) Métriques et SLO sécurité des données

Zero-PII dans les loges : ≥ 99. 99 % des événements.
Integrity-pass: ≥ 99. 9 % des paquets signés ont été validés avec succès.
Key-hygiene : 100 % des rotations ponctuelles, 0 clés périmées.
Detokenization SLO : p95 ≤ X min, uniquement pour les demandes justifiées.
Backup restore-rate : Succès du test de récupération ≥ 99 %.
Examen de l'accès : Fermé ≥ 95 % des droits excédentaires sur la vérification trimestrielle.
Incident MTR : ≤ le seuil cible pour les types de P1/P2.

19) Anti-modèles

TDE « pour cocher » sans FLE et tokenization des champs sensibles.
Stocker des secrets dans des variables d'environnement/référentiels.
Clés communes/pepper pour tous les domaines/régions.
Logs avec PII/secrets ; décharges de bases sans chiffrement.
Aucune signature/vérification d'intégrité dans les piplines.
« Administrateur unique » sur tous les KMS/HSM ; pas de SoD et de M-of-N.

20) Incident Pleybook (résumé)

1. Détail : SIEM/DLP/audit-journal/plainte.
2. Stabilisation : isolation du segment, rappel des clés/secrets, arrêt des flux problématiques.
3. Évaluation : ce qui a été divulgué/déformé, l'échelle, les juridictions touchées.
4. Communications : Legal/PR/régulateur (si nécessaire), partenaires/joueurs.
5. Mitigations : rotations, rétro-tokenization/cryptage, backfill/contrôles d'intégrité.
6. Post-mortem : causes, leçons, mise à jour des politiques/seuils/tests.

21) Sections connexes

Tokenization des données, Origine et chemin des données, Éthique et confidentialité, ML confidentiel, Federated Learning, Réduction des biais, DSAR/Legal Hold, Observabilité des données.

Résultat

La protection des données robuste est une architecture multi-niveaux + discipline de processus : cryptographie moderne, KMS/HSM rigoureux, tokenization, intégrité signée, logs propres, accès gérables et backups vérifiables. iGaming gagne des plates-formes où les données sont protégées par défaut et les modifications sont transparentes, reproductibles et conformes aux exigences.