Un ERP nu e o aplicație oarecare. În aceeași bază de date stau comenzi, facturi și prețuri de negociere lângă CNP-uri, adrese de domiciliu, salarii și fișe de personal. E multi-utilizator, cu roluri care nu trebuie să vadă unele lucrurile celorlalți, și trebuie să poată răspunde, peste un an, la întrebarea „cine a modificat acest câmp și când?". Asta nu mai e doar o cerință de securitate — e GDPR (Art. 5, 25, 30) și e ISO 27001 în același timp.
Vestea bună: tehnologiile care fac un ERP conform nu sunt exotice. Sunt mature, disponibile și — important — se montează cel mai bine la început, nu la sfârșit. Mai jos sunt cele pe care le folosim noi, fiecare legată de principiul GDPR pe care îl servește. Nu pentru că „așa se face", ci pentru că fără ele un ERP multi-tenant pur și simplu nu poate fi apărat la un audit serios.
Criptare în tranzit și la repaus — confidențialitate
Punctul de plecare, fără excepții. Tot traficul merge pe TLS 1.3, cu HSTS
activat (Strict-Transport-Security) ca browserul să refuze din start orice
downgrade la HTTP. Fără HSTS, un atacator pe rețea poate forța o primă conexiune
necriptată; cu el, fereastra aceea dispare.
La repaus, baza de date și fișierele stau criptate (AES-256 la nivel de volum și de storage). Practic, dacă cineva ar pune mâna pe un backup sau pe un disc, ar obține zgomot, nu CNP-uri.
- Principiu GDPR: confidențialitate (Art. 5(1)(f)) și măsuri tehnice adecvate (Art. 32).
- De ce un ERP în special: datele personale și cele comerciale circulă constant între client, server și storage. Un canal necriptat le expune pe toate deodată.
Row-Level Security în Postgres — fiecare vede doar ce e al lui
Aici se câștigă sau se pierde un ERP multi-tenant. Tentația comodă e să filtrezi
datele în aplicație: WHERE org_id = :currentOrg. Funcționează — până când un
endpoint uită filtrul, un dezvoltator scrie un query nou în grabă, sau un bug de
autorizare lasă o organizație să vadă rândurile alteia.
Noi mutăm regula acolo unde nu poate fi ocolită: în baza de date, prin Row-Level Security (RLS). Activăm RLS pe tabele și definim politici care leagă fiecare rând de organizația și de utilizatorul care au dreptul să-l vadă. De acolo, chiar dacă aplicația greșește, Postgres returnează zero rânduri. Securitatea nu mai depinde de disciplina fiecărui query.
- Principiu GDPR: integritate și confidențialitate; minimizarea accesului.
- De ce un ERP în special: e prin definiție multi-tenant și multi-rol. Izolarea între clienți nu poate fi o convenție — trebuie să fie o lege a sistemului.
Opinia noastră, fără menajamente: dacă izolarea între tenanți trăiește exclusiv în codul aplicației, ai o vulnerabilitate, nu o arhitectură. RLS costă câteva zile de proiectare la început și te scutește de un incident raportabil mai târziu.
Jurnal de audit — cine, ce, când, imuabil
Întrebarea „cine a modificat prețul de pe comanda asta acum trei luni?" trebuie să aibă răspuns. Fără jurnal, răspunsul e o ridicare din umeri — inacceptabil într-un sistem care ține date personale.
Logăm fiecare operație sensibilă: actor, acțiune, entitate atinsă, valori înainte/după și timestamp. Jurnalul e imuabil — append-only, fără UPDATE sau DELETE din aplicație — cu o retenție definită (90 de zile), după care intrările expiră controlat. Nu ținem totul la nesfârșit; păstrarea peste necesar e ea însăși un risc GDPR.
- Principiu GDPR: responsabilitate (Art. 5(2)) și evidența activităților de prelucrare (Art. 30).
- De ce un ERP în special: e sistemul de referință pentru bani și pentru oameni. La un audit ISO 27001 sau la o solicitare a unei persoane vizate, jurnalul e diferența între „demonstrăm" și „credem că".
Un jurnal care poate fi editat de cei pe care îi monitorizează nu e jurnal, e decor. Imuabilitatea nu e un moft — e tot rostul lui.
Acces după principiul privilegiului minim + MFA (TOTP)
Cel mai sigur acces e cel pe care nu-l acorzi. Pornim de la least privilege: fiecare rol primește exact permisiunile de care are nevoie, nimic în plus. Un operator de depozit nu vede salarii; un contabil nu modifică rețete de producție.
Peste asta adăugăm autentificare cu doi factori prin TOTP (aplicații tip Authenticator), obligatorie sau opțională în funcție de senzitivitatea rolului. O parolă furată nu mai e suficientă pentru a intra.
- Principiu GDPR: minimizarea accesului, măsuri tehnice și organizatorice (Art. 32).
- De ce un ERP în special: concentrează multe categorii de date într-un singur loc. Cu cât mai puține persoane ajung la cele sensibile și cu cât mai greu se intră pe un cont, cu atât suprafața de atac e mai mică.
URL-uri semnate, cu viață scurtă, pentru documente
Documentele — contracte, fișe, scanuri — nu stau pe linkuri publice „care merg dacă le știi". Asta e exact tiparul prin care se scurg date: un URL ajuns într-un e-mail sau într-un istoric de browser rămâne valabil la nesfârșit.
Folosim URL-uri semnate, cu expirare scurtă (5 minute). Sistemul generează linkul la cerere, doar pentru cine are dreptul, iar peste cinci minute linkul e mort. Dacă scapă undeva, nu mai descarcă nimic.
- Principiu GDPR: minimizarea datelor pusă în practică — acces exact cât trebuie, cât timp trebuie.
- De ce un ERP în special: atașamentele conțin frecvent cele mai sensibile date (acte de identitate, contracte). Un link permanent e o scurgere care așteaptă să se întâmple.
Pseudonimizare, minimizare și retenție definită — privacy by design
Ultimul strat e și cel mai greu de adăugat ulterior, pentru că ține de modelul de date. Întrebările pe care le punem din faza de proiectare:
- Avem nevoie de câmpul ăsta? Dacă nu, nu-l colectăm. Datele necolectate nu pot fi pierdute.
- Putem pseudonimiza? Acolo unde e posibil, separăm identitatea de date prin referințe (ID-uri opace), ca rapoartele și analizele să nu lucreze direct pe identificatori reali.
- Cât timp ținem datele? Fiecare categorie are o retenție definită, cu ștergere sau anonimizare automată la expirare.
Asta e esența Art. 5 și Art. 25 — privacy by design și by default. Setarea implicită protejează, nu expune.
Compliance-by-design: GDPR și ISO devin o proprietate, nu o cursă
Niciuna dintre aceste tehnologii nu e revoluționară luată separat. Puterea lor stă în faptul că sunt montate din arhitectură, nu lipite peste un sistem gata făcut. Când RLS, jurnalul imuabil, accesul minim, URL-urile semnate și retenția definită sunt deja în fundație, GDPR și ISO 27001 nu mai sunt un proiect de criză înainte de audit — sunt pur și simplu cum funcționează sistemul.
Diferența practică e enormă. Conformitatea adăugată la sfârșit înseamnă luni de remediere, query-uri rescrise și proceduri care contrazic codul. Conformitatea construită de la început înseamnă că auditorul verifică ce există deja și pleacă.
Takeaway practic: când evaluați un ERP — făcut intern sau cumpărat — puneți cinci întrebări concrete. Traficul e pe TLS cu HSTS? Izolarea între clienți e la nivel de bază de date (RLS) sau doar în aplicație? Există jurnal imuabil cu retenție definită? Accesul e least-privilege cu MFA? Documentele merg pe linkuri semnate, cu expirare? Dacă răspunsul la oricare e „nu" sau „o rezolvăm noi în proceduri", aveți o problemă de arhitectură, nu una de hârtii — și e mult mai ieftin s-o rezolvați acum decât după prima solicitare a unei persoane vizate.
