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 antifrod 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 (yadro↔dataleyk↔katalog↔fichestor↔provaydery).
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 для 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 fiches.
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 chèques 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).
Ключи/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.

Total

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.