Crypto Casino
Torrent Gear
Cum funcționează criptarea datelor în sistemele de plată
Sistemele de plată operează cu cele mai sensibile date - PAN (număr card), data expirării, CVV/CVC, jetoane 3-DS, detalii bancare, identificatori portofel. Scurgerea lor este amenzi, rechemarea comerciantului de la bănci/PSP și pierderi financiare directe. Protecția este construită în straturi: criptare într-un canal (TLS), criptare și/sau tokenizare în stocare, gestionare strictă a cheilor și module de încredere hardware (HSM). Mai jos este întreaga „conductă” de securitate în limbaj simplu.
Cărămizi de bază
Criptografie simetrică
Algoritmi: AES-GCM/CTR/CBC (în plăți, standardul de facto este AES-GCM).
Pro: de mare viteză, chei compacte.
Contra: trebuie să conveniți în siguranță asupra unei chei și IV/nonce.
Criptografie asimetrică
Algoritmi: RSA-2048/3072, ECC (P-256/384, Ed25519).
Utilizare: schimb de chei/ambalaj, semnături, PKI, certificate TLS.
Pro: Nu necesită un secret comun în prealabil.
Contra: Mai lent decât criptarea simetrică.
Идея Perfect Forward Secret (SFP)
Cheile de sesiune sunt negociate de ECDHE efemer. Chiar dacă cheia privată a serverului se scurge cândva, sesiunile trecute vor rămâne nedescifrate.
Criptare în tranzit: TLS 1. 2/1. 3
1. Strângere de mână (strângere de mână TLS): clientul și serverul sunt de acord asupra versiunilor/cifrelor, serverul prezintă un certificat (PKI), schimb de chei efemere (ECDHE) → se naște o cheie simetrică de sesiune.
2. Date: transmise în moduri AEAD (AES-GCM/ChaCha20-Poly1305) cu autentificare.
3. Optimizări: TLS 1. 3 runde de tăiere, sprijină reluarea; 0-RTT sunt utilizate cu atenție (numai interogări idempotente).
4. Practica plăților: interzicem SSLv3/TLS1. 0/1. 1, porneşte TLS1. 2/1. 3, capsare OCSP, HSTS, anteturi stricte de securitate.
Criptare „în stocare”: în repaus
Opțiuni
Criptarea volumului complet/bazei de date (TDE): introdusă rapid, protejează împotriva accesului „la rece” la mass-media, dar nu și de scurgeri printr-o aplicație compromisă.
Bitwise/field-level (FLE): câmpurile individuale (PAN, IBAN) sunt criptate. Granular, dar mai dificil de implementat și index.
Păstrarea formatului de criptare (FPE): Util atunci când doriți 16 cifre ca 16 cifre.
Tokenizare: PAN este înlocuit cu un token (șir fără sens); acest PAN este stocat în seiful token sub protecție grea. Atunci când plătiți/returnați, un token este utilizat → comerciantul nu procesează carduri „brute”.
Idee cheie
În stocare, nu este "care algoritm', care este mai important, dar în cazul în care cheile sunt și cine poate detokenize. Prin urmare,...
Managementul cheie: KMS, HSM și plicuri
Ierarhia cheie (criptarea plicului)
Root/KEK (Cheie de criptare a cheilor): clasă înaltă de protecție, stocată și executată în HSM.
DEK (Cheia de criptare a datelor): criptează date/loturi/tabele specifice; ea însăși criptată de KEK.
Rotație: reglementări pentru rotația programată și neprogramată (în cazul unui incident) a KEK/DEK; versiunea cheie este specificată în metadatele textului cifrului.
HSM (Modul de securitate hardware)
Un modul hardware certificat (de exemplu, FIPS 140-2/3) care stochează și efectuează operațiuni cheie în sine.
Nu emite chei private la exterior, acceptă limite/politica de utilizare, audit.
Folosit pentru: generarea de chei, înveliș DEK, 3-DS cheie server, chei EMV, operațiuni PIN, semnarea mesajelor.
KMS
Centralizează politica cheie, versioning, accesează, busteni, și API-uri.
Împreună cu HSM, implementează criptarea plicului și rotația automată.
Standardele cardurilor și specificul industriei
PCI DSS (și logica de minimizare)
Ideea principală: nu stocați CVV, minimizați zona de procesare PAN (domeniul de aplicare).
Acolo unde este posibil - oferiți intrare PAN câmpurilor găzduite/Iframe PSP → comerciantul nu are acces la date brute.
Bușteni, copii de rezervă, halde - aceleași reguli ca și prod: mascare, criptare, retenție.
EMV, PIN и POS
EMV chip/contact-less: criptograme la nivel de card/terminal, protecție împotriva clonării benzii de mag.
Blocuri PIN și ISO 9564: PIN este criptat de la pin pad la procesare, funcționează cu HSM (transferuri de pini, zone cheie).
DUKPT (Cheie unică derivată per tranzacție): Pe POS, fiecare plată este criptată cu o cheie unică derivată din BDK → compromiterea unui mesaj nu îi trage pe alții.
PCI P2PE: sistem de criptare certificat "end-to-end' de la pin pad la furnizorul de decriptare.
3-D Secure (2. x)
Autentificarea titularului cardului → mai puțină fraudă/chargebacks.
Criptografia este utilizată pentru semnăturile mesajelor, ACS/DS/3DS schimbul de chei Server; cheile private sunt de obicei în HSM.
Arhitecturi tipice pentru protecţia datelor
Opțiunea A (comerciant online cu PSP):- Browser → HTTPS → Hosted Fields PSP (PAN nu ajunge la comerciant).
- PSP returnează jetonul de plată.
- Baza de date comercială stochează jetonul + ultimele 4 cifre și BIN (pentru UX și reguli).
- Returnează/repetă - numai token.
- Secretele/cheile - în KMS, cheile private TLS/3-DS - în HSM.
- Aplicație ↔ API - TLS/mTLS.
- Câmpuri sensibile - FLE/FPE sau tokenizare; seiful este izolat.
- Acces la detokenizare - numai pentru roluri de serviciu cu „patru ochi”, operațiuni - prin HSM.
- Pin pad → DUKPT/P2PE prelucrarea →.
- Tastele de pornire a terminalului - prin injectoare securizate/XSM.
- Logare, anti-manipulare de protecție a dispozitivelor.
Rotație, audit și incidente
Rotație cheie: planificată (o dată la fiecare X luni) și prin eveniment (compromis). Rewrap DEK sub noul KEK fără a decripta datele utilizatorilor.
Jurnale imuabile: cine și când a accesat detokenation/chei; semnătura jurnalelor.
Compromis runbook: revocare/rotire imediată, reemiterea certificatelor, blocarea cheilor API, notificarea partenerilor, retrospectivă.
Greșeli comune și cum să le evitați
1. „Criptăm baza de date, deci totul e în regulă”.
Nu, nu este. Aplicația compromisă citește datele în mod deschis. Avem nevoie de tokenizare/FLE și principiul celor mai puține drepturi.
2. Stocare CVV.
Nu poţi. CVV nu este niciodată stocat, chiar criptat (prin PCI DSS).
3. Cheile de lângă date.
Nu poţi. Chei - în KMS/HSM, acces - după rol, privilegii minime, conturi separate.
4. Nu există rotație/versiuni.
Întotdeauna tastele versiunii, stoca „key _ version” în metadate cifrtext.
5. TLS doar pe perimetru.
Criptați în spatele CDN/WAF și în interiorul planului de date (servis→servis, cărți web).
6. Tokenizare „pentru vedere”.
În cazul în care orice serviciu poate detokenize, acest lucru nu este de protecție. Apeluri înguste şi de audit.
7. Backup-uri/încărcări analitice necontabilizate.
Criptarea și mascarea ar trebui să se aplice backup-urilor, instantaneelor, vitrinelor BI, jurnalelor.
Lista de verificare a implementării (pe scurt)
Canal
TLS 1. 2/1. 3, PFS, mTLS pentru cârlige interne și webhook-uri, HSTS, anteturi stricte de securitate.
Depozitare
Tokenizarea PAN, interzicerea stocării CVV.
FLE/FPE pentru câmpurile critice; TDE ca strat de bază.
Taste
KMS + HSM, criptare plic (KEK/DEK), rotație/versiuni, jurnale de neschimbat.
Arhitectură
Câmpuri găzduite/SDK PSP, minimizarea zonei PCI.
Separarea rolurilor/rețelelor, zero încredere, secrete - numai printr-un manager secret.
Operațiuni
Pentest/Red Team pe perimetru și logica de afaceri.
Monitorizarea DLP/CTI a canalelor de scurgere, instruirea personalului.
Runbook на compromis: revocare/rotire/notificare.
Mini-Întrebări frecvente
Este criptarea sau tokenizarea cea mai bună pentru PAN?
În vânzări - tokenizare (minimizează domeniul de aplicare). În seif - criptare cu HSM/KMS.
Am nevoie de un certificat EV pentru un domeniu de plată?
Opţional. Mai important este profilul TLS corect, mTLS, cheile în HSM și disciplina.
Pot folosi 0-RTT în TLS 1? 3 pentru plăţi?
Pentru GET-uri idempotente, da. Pentru POST, este mai bine să dezactivați sau să limitați.
Cum se păstrează „ultimele 4” și BIN?
Separat de PAN; acestea nu sunt date sensibile cu izolare corectă, ci observă mascarea în jurnalele/BI.
Criptarea în sistemele de plată nu este un comutator de comutare, ci un ecosistem: TLS/PFS într-un canal, tokenizare și/sau FLE în stocare, managementul strict al cheilor prin KMS + HSM, standardele industriei (PCI DSS, EMV, 3-DS), rotație și audit. O astfel de arhitectură multi-stratificată face ca scurgerea datelor cardurilor să fie extrem de puțin probabilă, simplifică trecerea auditurilor și, cel mai important, păstrează încrederea băncilor, a partenerilor de plată și a utilizatorilor.