Securitatea și criptarea datelor

1) De ce este critic în iGaming

Platforma iGaming funcționează cu PII, detalii financiare, sesiuni de joc, trăsături comportamentale, semnale antifraudă și modele ML. Scurgerea sau substituirea acestor date duce la amenzi, blocaje ale pieței, deteriorarea reputației și regresia metricii (RGG, retenție).

• Confidențialitate (acces minim la PII/finanțe).
• Integritate (protecție împotriva falsificării și a datelor murdare).
• Disponibilitate (citire/scriere SLO, planuri DR).
• Trasabilitatea (cine a urmărit/schimbat ce și când).

2) Model de amenințare (scurtat)

Extern: compromis API/integrare, MITM, ransomware, furnizori (lanț de aprovizionare).
Intern: drepturi redundante, încărcări „umbre”, jurnale toxice, erori de configurare.
Date și ML: înlocuirea/caracteristica evenimentului, inversarea modelului, inferența membrilor.
Jurisdicții: restricții transfrontaliere, cerințe locale de depozitare și eliminare.

3) Criptare în tranzit

TLS 1. 2+/1. 3 numai, dezactivați suitele de cifruri slabe; preferință TLS 1. 3.
mTLS pentru S2S (yadro↔dataleyk↔katalog↔fichestor↔provaydery).
SFP (ECDHE) - necesar.
Certificat de fixare pe clienții mobile/desktop și integrări critice.
Semnarea API a cererilor către furnizori/PSP (HMAC-SHA-256) și controlul timpului/repetiției (nonce, chei de idempotență).

4) În repaus

• Criptarea volumelor/obiectelor într- the/K8s cloud (transparent, dar nu protejează împotriva citirii „legitime” de către un serviciu compromis).

• TDE (criptare transparentă a datelor) - strat de bază.
• FLE/Column-level AEAD pentru câmpuri fierbinți (e-mail, telefon, jetoane PAN): AES-256-GCM sau ChaCha20-Poly1305.
• Chei de nivel rând pentru înregistrări deosebit de sensibile (VIP, plăți).

• Criptarea plicurilor (DEK gestionat de KMS, rotație), controlul accesului la cheie.
• Semnarea manifestă și controlul integrității (hash/checksum, arbori Merkle pentru pachete).

5) Alegeri criptografice (practică)

Criptare simetrică: AES-GCM/ChaCha20-Poly1305 (AEAD) cu nonce/IV unic; store 'cifertext + auth tag'.
Hashing: SHA-256/512 pentru integritate; pentru parole - Argon2id (sau bcrypt/scrypt) cu parametrizare și sare.
Semnătură: Ed25519/ECDSA P-256 pentru artefacte/pachete; HMAC-SHA-256 pentru semnătura API.
Aranjamente cheie: ECDH (P-256/Curve25519).

6) Managementul cheilor (KMS/HSM)

KMS + HSM pentru generarea/stocarea cheilor principale; criptare plic для DEK.
Rotație: regulat (calendar) și după eveniment (incident). Suport cu citire dublă pentru perioada de migrare.
Separarea taxelor (SoD), M-of-N pentru „spargerea sticlei”, înregistrarea tuturor operațiunilor.
Split-key/Shamir pentru secrete deosebit de critice (de exemplu, semnătura plăților).
Geo-scoping chei: chei diferite pentru regiuni/branduri.

7) Managementul secret

Managerul de secrete centralizate (nu în variabilele de mediu depozit).
Secretele JIT (de scurtă durată), auto-rotație și rechemare.
Sidecar/CSI pentru furnizarea de secrete pentru inimile K8s.
Interzicerea jurnalelor/traseelor cu secrete; detectoare de scurgeri în CI.

8) Integritatea și încrederea datelor

Semnarea evenimentelor/pachetelor (de către producător) și verificarea (de către consumator).
Idempotența evenimentului și cheile unice pentru anti-reluare.
Controlul schemei (registrul schemei, compatibilitate), contractele de date ca „limite de încredere”.
Stocare WORM pentru jurnale critice și raportare.

9) Tokenizare, mascare și DLP

Tokenizarea PII/finance (vault/FPE/DET) - utilizarea tokenurilor în jurnale, storefronturi, caracteristici.
Mascarea în UI și încărcări; Ediție PII în texte de bilet/chat (salubritate NLP).
Politici DLP: șabloane interzise (PAN, IBAN, pașaport), bloc de descărcare, inspection/FTP/S3 prin poștă.

10) Acces și audit

RBAC/ABAC: atribute de rol + (țară, marcă, mediu); cele mai puține drepturi.
JIT accesează cu auto-rechemare; o dată la fiecare N zile - o revizuire a drepturilor.
mTLS + IP allowlist pentru panouri admin și puncte finale critice.
Jurnale de audit imuabile (WORM/append-only), corelație cu SIEM.
Spargerea sticlei: roluri/chei individuale, post-mortem obligatoriu.

11) Backup și DR

3-2-1: 3 copii, 2 medii diferite/CDS, 1 offline/izolat (aer-gapped).
Criptarea backup-uri cu propriile chei (nu furnizorul), test de recuperare programat.
RPO/RTO pentru domenii (plăți <X min., evenimente de joc <Y min.).
Replicarea regională cu izolarea cripto-cheie și rețea.

12) Confidențialitate și conformitate

Clasificarea datelor (public/intern/confidențial/restricționat).
Minimizarea și legătura țintă (KYC, AML, RG, raportare).
Politici de păstrare și dispunere: grafice, Legal Hold, DSAR; cripto-ştergere.
Transfrontalier: geo-zonare și cazuri de depozitare locale.

13) Observabilitatea siguranței datelor

Zero-PII în jurnale (metrici de acoperire), alerte atunci când DLP este declanșat.
Sănătate cheie: rotații, eșecuri cifrate, anomalii KMS/HSM.
Integritate SLI - Procentul de pachete/evenimente semnate și verificări de semnătură verificate.
Latență SLO: p95 tokenizare/detokenizare, criptare/decriptare.
SLO de acces: proporția de cereri JIT procesate la momentul țintă.

14) Unelte și straturi de proces (categorii)

KMS/HSM: chei principale, plic, semnătură.
Secrets Manager: Secretele JIT, rotație.
Terminarea TLS/mTLS-mesh: intrare/plasă de serviciu.
DLP/Mascare: inspecție, salubritate.
Schema Registry/Contracte: Compatibilitate, interdicții PII.
SIEM/SOAR: corelarea jurnalelor de audit, reacții automate.
Backup/DR: orchestrarea backup-urilor, testul de recuperare.

15) Șabloane (gata de utilizare)

15. 1 Politica de criptare (fragment)

Algoritmi: AES-256-GCM/ChaCha20-Poly1305; semnătura Ed25519; SHA-256 hash.
Chei: generare în HSM; rotație 90 zile sau pe incident; geo-scoped.
Acces: numai conturi de servicii prin mTLS; Jetoane JIT.
Jurnale: modul WORM; depozitare ≥ N luni.
Excepții: prin decizia CISO/DPO, cu înregistrare de justificare.

15. 2 Pașaportul setului de date protejate

Domeniu/tabel: plăți. tranzacții

Clasa: Restricționat (Finanțe)

Criptare: FLE (AES-GCM) prin campuri 'card _ token', 'iban', 'payer _ id'

Chei: DEK pe câmp (plic KMS)

Tokenizare: jetoane seif pentru PAN/telefon/e-mail

Acces: ABAC (țară, rol "Payments-Ops'), JIT

Busteni: semnatura pachet, WORM, retentie 2 ani

15. 3 Lista de verificare a eliberării datelor

• Contractul interzice PII în zonele gri, câmpurile marcate 'pi/tokenized'
• TLS 1. 3 și mTLS pe S2S activat
• FLE/TDE configurat, chei în KMS/HSM, rotație activă
• Regulile DLP și testele de mascare a jurnalului
• Backup criptat, test de recuperare testat
• SIEM primește jurnale de audit; alerte pentru încercarea de detokenizare în afara „zonei curate”

16) Foaia de parcurs privind implementarea

0-30 zile (MVP)

1. Clasificarea datelor și harta fluxului (PII/Financials/ML).
2. Activează TLS 1. 3/mTLS pentru S2S; interzicerea calculatoarelor cu cifru slab.
3. Ridicați KMS/HSM; transfera cheile la schema de plic.
4. Activați TDE și FLE pentru 3 domenii critice (Plăți/KYC/RG).
5. Mascarea jurnalului și regulile DLP de bază; Calificare zero-PII.

30-90 zile

1. Tokenizarea PII/Finance (seif/FPE); JIT accesează și audituri de detokenation.
2. Semnarea evenimentului și verificări de integritate în ingestie/ETL.
3. Rotație obișnuită a cheilor, split-key pentru plăți VIP.
4. Copii de rezervă: 3-2-1, copie offline, zi de restaurare lunară.
5. Tablouri de bord SLO (Zero-PII, Integritate, Key-Health, Latency).

3-6 luni

1. Chei/date geometrizate în funcție de jurisdicție; politicile transfrontaliere.
2. Stocarea WORM pentru audit/raportare; Playbooks SOAR.
3. Acoperire completă cu jetoane de analiză/ML; Interdicția PII în cazurile de afișare.
4. Exerciții trimestriale: simulări de incidente (ransomware, scurgeri de chei, otrăviri de date).
5. Recertificarea anuală și auditul extern.

17) RACI (exemplu)

Politici și controale: CISO/CDO (A), DPO (C), SecOps (R), Proprietarii de domenii (C).
Ключи/KMS/HSM: Securitate/Platformă (R), CTO (A), Audit (C).
Tokenization/DLP: Data Platform (R), DPO (A), Domenii (C).
Copii de rezervă/DR: SRE (R), CIO (A).
Monitorizare/Incidente: SecOps (R), SOAR (R), Legal/PR (C).

18) Măsurători și SLO-uri de securitate a datelor

Zero-PII în jurnale: ≥ 99. 99% din evenimente.
Integritate-pass: ≥ 99. 9% din pachetele semnate au fost verificate cu succes.
Igiena cheilor: 100% rotații la timp, 0 chei expirate.
Detokenization SLO: p95 ≤ X min., numai la cerere cu justificare.
Rata de restaurare de rezervă: testul de succes restabilește ≥ 99%.
Revizuirea accesului: închis ≥ 95% din drepturile de audit trimestriale excedentare.
Incident MTTR - ≤ pragul țintă pentru P1/P2 tipuri.

19) Anti-modele

TDE „pentru spectacol” fără FLE și tokenizarea câmpurilor sensibile.
Stocarea secretelor în variabile/depozite de mediu.
Chei/piper partajate pentru toate domeniile/regiunile.
Jurnale cu PII/secrete; fără criptare.
Nu există semnături/verificări de integritate în conducte.
„Single admin” pentru toate KMS/HSM; fără SoD și M-of-N.

20) Playbook Incident (Scurt)

1. Detectie: SIEM/DLP/audit-log/reclamatie.
2. Stabilizare: izolare segment, revocare cheie/secret, oprirea fluxurilor de probleme.
3. Evaluare: ceea ce a curs/distorsionat, scară, jurisdicții, afectate.
4. Comunicații: Legal/PR/regulator (acolo unde este necesar), parteneri/jucători.
5. Atenuări: rotații, tokenizare/criptare retro, controale de rambursare/integritate.
6. Post-mortem: motive, lecții, actualizarea politicilor/pragurilor/testelor.

21) Secțiuni conexe

Tokenizarea datelor, originea și calea datelor, etica și confidențialitatea, confidențialitatea ML, învățarea federalizată, reducerea prejudecăților, DSAR/Legal Hold, observabilitatea datelor.

Rezultat

Protecția fiabilă a datelor este o arhitectură pe mai multe niveluri + disciplină de proces: criptografie modernă, KMS/HSM strictă, tokenizare, integritate semnată, jurnale curate, accesări gestionate și backup-uri verificabile. În iGaming, platformele câștigă în cazul în care datele sunt protejate în mod implicit, iar modificările sunt transparente, reproductibile și conforme.