Majoritatea aplicațiilor web nu sunt compromise printr-un atac spectaculos. Sunt compromise printr-o parolă reutilizată, o cheie de API lăsată în cod, un backup care nu a fost testat niciodată sau un cont de administrator rămas activ după plecarea unui coleg.
În paralel, conformitatea GDPR este tratată de multe companii ca un banner de cookies și o politică de confidențialitate copiată de undeva. Ambele sunt vizibile, niciunul nu protejează datele reale ale clienților.
Securitatea și conformitatea nu sunt același lucru, dar se sprijină reciproc. O aplicație securizată face conformitatea mult mai ușor de demonstrat, iar cerințele GDPR te obligă să pui ordine exact unde aveai oricum risc tehnic. Articolul este un ghid tehnic și operațional, nu consultanță juridică — pentru situația ta specifică, discută cu un specialist în protecția datelor.
Securitatea Nu Este un Feature pe Care Îl Adaugi la Final
O greșeală frecventă este să tratezi securitatea ca pe o etapă de dinaintea lansării: se construiește aplicația, apoi „se securizează". În practică, cele mai costisitoare probleme vin din decizii de arhitectură luate la început, nu din setări uitate la final.
Securitatea reală înseamnă un set de întrebări repetate în fiecare etapă:
- Ce date colectezi și de ce ai nevoie de ele
- Unde ajung datele și cine poate să le vadă
- Ce se întâmplă când cineva greșește sau când un serviciu extern cade
- Cum afli că s-a întâmplat ceva și cât de repede
- Cum revii la o stare corectă după un incident
O aplicație bine construită nu este una care nu poate fi atacată niciodată. Este una în care un incident rămâne limitat, este detectat rapid și poate fi reparat fără să pierzi datele clienților.
Ce Date Personale Ai, de Fapt
Primul pas concret nu este tehnic. Este să scrii ce date personale trec prin aplicația ta. Multe companii descoperă abia atunci că păstrează informații pe care nu le-au folosit niciodată.
| Categorie de date | Exemplu tipic | Risc dacă se scurg | Cât le păstrezi |
|---|---|---|---|
| Identificare | nume, email, telefon | Fraudă, phishing țintit | Cât durează relația comercială |
| Autentificare | parole, token-uri, sesiuni | Preluare completă de cont | Rotire periodică, nu permanent |
| Financiare | facturi, IBAN, istoric plăți | Fraudă, expunere contractuală | Termenul legal de arhivare |
| Comportamentale | loguri, analytics, IP | Profilare, reidentificare | Câteva luni, nu ani |
| Documente încărcate | CV-uri, contracte, acte | Expunere directă de date sensibile | Doar cât cere scopul |
Regula practică este simplă: datele pe care nu le ai nu pot fi furate. Înainte să te întrebi cum protejezi mai bine un câmp, întreabă-te dacă ai nevoie de el.
1. Autentificare și Control al Accesului
Cele mai multe breșe încep de la un cont, nu de la o vulnerabilitate exotică. Un cont de administrator fără al doilea factor este, practic, o singură parolă între atacator și toate datele tale.
Ce trebuie să ai:
- Parole stocate corect: hashing modern (bcrypt, argon2), niciodată text clar
- Autentificare în doi pași obligatorie pentru conturile administrative
- Sesiuni cu expirare și posibilitatea de a invalida sesiunile unui utilizator
- Roluri clare: fiecare utilizator primește minimul de drepturi necesare
- Dezactivare în aceeași zi când cineva pleacă din companie
- Limitarea încercărilor de autentificare, împotriva atacurilor automate
Un audit util pe care îl poți face astăzi: listează toate conturile cu drepturi de administrator din aplicație și din panourile furnizorilor. De obicei sunt mai multe decât își amintește cineva.
2. Protecția Datelor în Tranzit și în Repaus
Datele trebuie protejate în trei locuri: pe drum între utilizator și server, în baza de date și în backup-uri. Multe echipe rezolvă doar primul. Criptarea în repaus contează pentru scenariul în care cineva obține acces la stocare, nu la aplicație — un backup expus, un volum de disc, un export uitat.
Ce trebuie să ai:
- HTTPS peste tot, cu redirect automat și certificate reînnoite automat
- Criptare la nivel de bază de date sau de disc pentru datele sensibile
- Secrete în variabile de mediu sau într-un manager de secrete, niciodată în repository
- Separare între medii: datele reale nu ajung în mediul de testare
- Anonimizare pentru seturile folosite la dezvoltare și demonstrații
Dacă o cheie de API a ajuns vreodată într-un commit, consider-o compromisă și rotește-o. Istoricul repository-ului nu se șterge singur.
3. Consimțământ, Cookies și Formulare
Aici se concentrează cele mai multe neconformități vizibile, pentru că sunt și cele mai ușor de verificat din exterior. Un banner care încarcă scripturi de urmărire înainte ca utilizatorul să apese ceva nu este consimțământ, indiferent cum arată.
Fiecare colectare de date are nevoie de un temei legal și de un scop declarat. Consimțământul este doar unul dintre temeiuri, iar pentru executarea unui contract nici nu este cel potrivit.
Ce trebuie să ai:
- Scripturi de urmărire blocate implicit, până la o acțiune explicită
- Refuz la fel de simplu ca acceptul, fără opțiuni ascunse
- Formulare fără câmpuri inutile: nu cere date pe care nu le folosești
- Politică de confidențialitate care descrie realitatea, inclusiv furnizorii
- Mecanism pentru drepturile utilizatorilor: acces, rectificare, ștergere, portabilitate
- Evidența consimțământului: când a fost dat și pentru ce
Cel mai bun test este să deschizi site-ul în mod incognito și să verifici ce cereri de rețea pleacă înainte de orice click. Rezultatul e adesea surprinzător.
4. Backup, Recuperare și Continuitate
Un backup care nu a fost restaurat niciodată este o presupunere, nu o măsură de siguranță. Două întrebări îți definesc întreaga strategie: câte date îți permiți să pierzi și cât timp îți permiți să stai oprit. Prima determină frecvența, a doua determină viteza de restaurare.
Ce trebuie să ai:
- Backup automat, cu frecvență potrivită volumului de date
- Copii în locație separată de infrastructura principală
- Restaurare testată periodic, pe un mediu izolat
- Retenție definită, ca să nu păstrezi date personale la nesfârșit în arhive
- Backup criptat, pentru că adesea conține exact datele cele mai sensibile
- Procedură scrisă pe care o poate urma și altcineva decât cel care a configurat-o
Testarea restaurării o dată pe trimestru este suficientă pentru majoritatea companiilor și schimbă complet nivelul de încredere.
5. Logging, Audit și Detectarea Incidentelor
Fără loguri, un incident rămâne o poveste. Nu poți spune ce date au fost accesate, de cine și pe ce interval — exact ce ți se cere când trebuie să notifici. În același timp, multe aplicații scriu în loguri chiar datele pe care încearcă să le protejeze.
Ce trebuie să ai:
- Loguri de autentificare: logări reușite, eșuate, schimbări de parolă
- Audit pentru acțiuni sensibile: cine a exportat, șters sau modificat date
- Alerte pentru tipare anormale, nu doar dashboard-uri pe care nu le privește nimeni
- Fără date personale în loguri: nici parole, token-uri sau conținut de documente
- Acces restricționat la loguri, pentru că ele conțin harta activității din aplicație
Un sistem de logging util răspunde la o singură întrebare: dacă un cont ar fi compromis mâine, aș putea reconstitui ce a făcut?
Furnizorii Tăi Sunt Parte din Conformitate
Aplicația ta nu rulează singură. Hosting, email tranzacțional, procesator de plăți, CRM, analytics, suport — fiecare procesează datele clienților tăi în numele tău, iar responsabilitatea rămâne la tine.
Ce trebuie să ai:
- Lista completă a serviciilor care ating date personale
- Acord de prelucrare (DPA) semnat cu fiecare furnizor relevant
- Claritate asupra locației datelor și a transferurilor în afara UE
- Reguli interne pentru cine poate adăuga un instrument nou care primește date
Această listă este și un exercițiu de securitate: fiecare integrare este o cheie în plus care poate fi pierdută.
Ce Faci în Primele 72 de Ore După un Incident
Notificarea unei breșe are un termen scurt, iar improvizația în acel moment costă. O procedură scrisă dinainte face diferența între un răspuns controlat și panică.
- Izolează: oprește accesul compromis, rotește cheile și parolele afectate.
- Documentează: ce s-a întâmplat, când, ce sisteme și ce categorii de date sunt implicate.
- Evaluează impactul asupra persoanelor vizate, nu doar asupra infrastructurii.
- Notifică autoritatea competentă în termenul legal, dacă riscul o impune.
- Informează persoanele afectate atunci când riscul pentru ele este ridicat.
- Repară cauza, nu doar simptomul, și consemnează măsurile luate.
Pregătește din timp lista persoanelor de contact și un canal de comunicare care funcționează chiar dacă sistemul principal este indisponibil.
Greșeli Comune
Problemele de securitate apar rar din lipsă de instrumente. Apar din lipsă de proprietar și de rutină.
- Nimeni nu răspunde de securitate: este responsabilitatea tuturor, deci a nimănui
- Dependențe neactualizate luni sau ani, pentru că „merge oricum"
- Aceleași credențiale folosite în producție și în testare
- Acces permanent acordat pentru o intervenție temporară
- Backup fără test de restaurare, deci fără garanție
- Date de producție copiate pe laptopuri pentru „o verificare rapidă"
Niciuna dintre acestea nu necesită un atacator sofisticat pentru a deveni un incident real.
Un Plan Realist pe 90 de Zile
Nu ai nevoie de un proiect mare pentru a schimba fundamental situația. Ai nevoie de o ordine corectă a pașilor.
Primele 30 de zile: inventariezi datele personale și furnizorii, listezi conturile cu drepturi de administrator, activezi autentificarea în doi pași și verifici ce se încarcă în pagină înainte de consimțământ.
Zilele 31-60: scoți secretele din cod, actualizezi dependențele, configurezi backup automat și faci prima restaurare de test, definești rolurile și retenția datelor.
Zilele 61-90: adaugi logging de audit și alerte, semnezi acordurile de prelucrare lipsă, scrii procedura de răspuns la incident și programezi o revizuire trimestrială.
După aceste trei etape, securitatea devine o rutină întreținută, nu o urgență periodică.
Cum Poate Ajuta ContByte
La ContByte tratăm securitatea ca parte din dezvoltare, nu ca pe un serviciu separat vândut după livrare. Pornim de la datele reale ale aplicației, de la fluxurile existente și de la echipa care o folosește zilnic.
Putem ajuta cu:
- Audit de securitate pentru aplicații web existente
- Implementare de autentificare, roluri și control al accesului
- Arhitectură de date, strategii de criptare și retenție
- Configurare de backup, monitorizare și alerte
- Revizuirea fluxurilor de colectare a datelor și a integrărilor cu terți
- Mentenanță continuă, cu actualizări și verificări periodice
Scopul este ca aplicația să rămână sigură pe termen lung, nu doar să treacă o verificare punctuală.
Concluzie
Securitatea și conformitatea GDPR nu sunt un proiect care se termină. Sunt un set de obiceiuri: știi ce date ai, controlezi cine le accesează, poți reveni după o problemă și poți demonstra ce ai făcut.
Cele mai multe companii nu au nevoie de măsuri complexe, ci de cele de bază, aplicate consecvent. Un inventar de date, autentificare serioasă, secrete gestionate corect și un backup testat rezolvă mai mult decât orice instrument cumpărat în grabă după un incident.