Majoritatea echipelor tratează GDPR ca pe un exercițiu juridic: o politică de confidențialitate, un banner de cookie-uri, un DPA semnat uitat într-un sertar. Această abordare eșuează prima dată când o cerere de ștergere trebuie să ajungă într-un depozit de date sau prima dată când auditorul unui client enterprise întreabă unde anume se află un backup. Regulamentul impune cerințe concrete privind modul în care datele circulă prin sistemele dumneavoastră — ce intră într-un pipeline, cât timp persistă, cine le poate citi și dacă puteți dovedi toate acestea.
Acest ghid introductiv traduce principalele obligații în decizii de arhitectură. Este scris pentru factorii de decizie tehnici din companiile B2B care vehiculează date cu caracter personal la scară mare — înregistrări CRM, evenimente ale utilizatorilor, istorice de tranzacții — și care doresc pipeline-uri care trec un audit, nu politici care doar îl promit.
Patru obligații care țin de arhitectură
Cea mai mare parte a textului GDPR nu îi privește pe ingineri. Patru obligații însă îi privesc, deoarece constrâng direct schemele și topologia.
- Propagarea temeiului legal. Fiecare înregistrare de date cu caracter personal a fost colectată în baza unui temei legal specific — consimțământ, contract, interes legitim. Acest temei trebuie să însoțească datele sau să poată fi determinat pe baza lor, astfel încât sistemele din aval să poată acționa atunci când se schimbă. Dacă consimțământul este retras în CRM, depozitul de date și fiecare tabel derivat trebuie să afle acest lucru.
- Minimizarea datelor. Un pipeline ar trebui să transporte câmpurile pe care le impune scopul prelucrării și să le elimine pe celelalte încă de la preluare. Copierea integrală a înregistrărilor sursă pentru că stocarea este ieftină vă multiplică suprafața de conformitate cu fiecare tabel.
- Limite de păstrare. Fiecare set de date are nevoie de o perioadă de păstrare definită și de o sarcină automată care o aplică. Păstrarea gestionată prin scripturi ad-hoc, sau deloc, este una dintre cele mai frecvente constatări de audit.
- Dreptul la ștergere. Atunci când o persoană vizată o solicită, trebuie să îi ștergeți datele cu caracter personal din fiecare sistem de stocare care le conține, în termen de o lună. Aceasta este o problemă de sisteme distribuite și, dintre cele patru, cea mai greu de implementat retroactiv.
Rezidența datelor în UE: fixați regiunile, apoi verificați marginile
Toate cele trei mari platforme cloud operează regiuni în UE — printre care Frankfurt, Paris, Amsterdam și Dublin — iar fixarea stocării principale într-una dintre ele este simplă. Riscul se află la margini: replicarea backupurilor între regiuni, copiile pentru recuperare în caz de dezastru, serviciile SaaS de agregare a jurnalelor sau de urmărire a erorilor găzduite în Statele Unite, instrumentele de suport care exportă date de producție. O garanție de rezidență a datelor este la fel de solidă ca cea mai puțin atentă componentă.
Orice transfer în afara SEE necesită un mecanism juridic valabil — o decizie privind caracterul adecvat sau clauze contractuale standard însoțite de o evaluare a impactului transferului. Pentru majoritatea platformelor B2B, cea mai simplă poziție care poate fi susținută este păstrarea datelor cu caracter personal în regiuni din UE de la un capăt la altul: stocările principale, replicile, backupurile și stiva de observabilitate. Astfel dispare o întreagă categorie de întrebări din fiecare evaluare de securitate pe care clienții dumneavoastră o vor efectua asupra dumneavoastră.
Criptare: practică standard, aplicată complet
Criptarea în tranzit înseamnă TLS 1.2 sau o versiune superioară pe fiecare segment, inclusiv traficul dintre servicii din propria rețea — traficul intern este cel la care lipsește cel mai des. Criptarea în repaus este implicită pentru stocarea cloud administrată, dar setările implicite folosesc chei gestionate de furnizor. Cheile gestionate de client prin KMS-ul platformei cloud vă oferă rotirea cheilor, separarea pe medii și posibilitatea de a revoca accesul, iar acestea sunt ceea ce chestionarele de securitate ale companiilor mari solicită tot mai des.
Pentru câmpurile cu sensibilitate ridicată, adăugați criptare la nivel de câmp în stratul aplicației. Aceasta permite și crypto-shredding: distrugeți cheia asociată unei persoane vizate, iar datele acesteia devin ilizibile în toate copiile protejate de acea cheie — inclusiv în backup-urile și arhivele pe care practic nu le puteți rescrie. Pentru stocările de tip append-only sau imuabile, acesta este adesea singurul mecanism de ștergere viabil.
Subîmputerniciți și DPA-uri: stratul contractual de sub pipeline
Orice terț care prelucrează date cu caracter personal în numele dumneavoastră este o persoană împuternicită de operator sau un subprocesator și are nevoie de un acord de prelucrare a datelor în temeiul articolului 28. Într-un pipeline tipic, această listă este mai lungă decât se așteaptă echipele: furnizorul de cloud, serviciul administrat de ETL sau streaming, furnizorul depozitului de date, instrumentele de monitorizare și de urmărire a erorilor — stack trace-urile și liniile de log conțin date cu caracter personal mai des decât s-ar crede — și orice API de îmbogățire a datelor.
Păstrați un registru actualizat al subprocesatorilor, care asociază fiecare furnizor cu componenta de pipeline pe care o deservește, categoriile de date pe care le vede și regiunea în care rulează. Includeți semnarea DPA-ului în definiția „gata” (definition of done) pentru adăugarea oricărui instrument în pipeline. Clienții enterprise din Franța, Germania și Țările de Jos vor solicita acest registru în procesul de achiziție; să-l puteți prezenta într-o zi, nu într-o lună, este un semnal de credibilitate.
Model: zone de pseudonimizare
Împărțiți pipeline-ul în două zone. O zonă identificată conține identificatorii direcți — nume, adrese de e-mail, numere de telefon — într-un număr mic de sisteme de stocare cu acces strict controlat. O zonă pseudonimizată, în care au loc analiza, raportarea și învățarea automată, conține tokenuri stabile în locul identificatorilor, cu un seif (vault) care asociază tokenurile cu identitățile pentru puținele fluxuri de lucru care au nevoie de acest lucru.
Beneficiul este reducerea razei de impact: cea mai mare parte a infrastructurii și a accesului echipei dumneavoastră nu atinge niciodată un identificator direct, iar o breșă în zona analitică dezvăluie mult mai puțin. Să fim exacți în privința limitelor — datele pseudonimizate sunt în continuare date cu caracter personal în sensul GDPR, așadar modelul reduce riscul și sfera auditului; nu exceptează nimic de la aplicarea regulamentului.
Model: propagarea ștergerii și pistele de audit
Tratați ștergerea ca pe un eveniment, nu ca pe un script. O cerere de ștergere intră printr-un singur punct, este validată și publicată ca eveniment de ștergere pe magistrala internă de mesaje. Fiecare sistem care stochează date cu caracter personal — baze de date operaționale, depozitul de date, indexuri de căutare, cache-uri, aplicații SaaS din aval prin API — este abonat, execută propria ștergere și raportează finalizarea. Un coordonator urmărește distribuirea și închide cererea doar după ce fiecare consumator a confirmat, ceea ce vă oferă un răspuns solid la întrebarea: de unde știți că datele au fost șterse peste tot?
Backupurile au nevoie de o politică explicită și documentată: fie ștergerea este reaplicată automat la restaurarea unui backup, fie perioada de păstrare a backupurilor este suficient de scurtă încât expirarea să rezolve problema. Pe lângă ștergere, mențineți un jurnal de audit de tip append-only al activităților de prelucrare — modificări ale consimțământului, confirmări de ștergere, rulări ale politicilor de păstrare, accesări ale zonei cu date identificabile. Principiul responsabilității de la articolul 5 alineatul (2) înseamnă să puteți demonstra conformitatea, iar acest jurnal este demonstrația.
De unde să începeți
Începeți cu o hartă a datelor: ce sisteme conțin date cu caracter personal, ce câmpuri, în baza cărui temei, pentru cât timp. Apoi parcurgeți straturile în ordinea impactului — mai întâi rezidența și nivelul de bază al criptării, apoi automatizarea perioadelor de păstrare, apoi propagarea ștergerii, iar zonele de pseudonimizare acolo unde sensibilitatea datelor o justifică. Adaptarea ulterioară se măsoară în luni pe un stack B2B tipic; integrarea acestor proprietăți într-un pipeline nou costă doar o fracțiune din acest efort.
Proiectăm și operăm pipeline-uri de date conforme cu GDPR ca parte a serviciului nostru de Infrastructură cloud și procesarea datelor, cu rezidența datelor în UE și acordurile DPA gestionate standard. Dacă doriți o a doua opinie asupra arhitecturii dumneavoastră actuale, și noi am începe tot cu un audit.