Ce problemă rezolvă
Într-un sistem care ține documentele unei organizații, întrebarea nu este dacă datele sunt protejate în general, ci cine anume poate vedea un anumit document, într-un anumit moment, și ce urmă lasă accesul acela. Regulamentul (UE) 2016/679 cere exact acest nivel de precizie: temei pentru prelucrare, minimizarea datelor, limitarea accesului la ce este necesar și capacitatea de a demonstra toate acestea la control.
Majoritatea incidentelor din aplicațiile de business nu vin din criptografie spartă, ci din autorizare greșită. Un identificator ghicit în adresa paginii, un rol care moștenește mai mult decât ar trebui, o interogare care uită să filtreze pe organizație — toate duc la același rezultat: cineva vede un document care nu îi aparține.
Cum este construită protecția în VOGO eBS ECM
Autorizarea pornește de la refuz. Orice cerere care nu se potrivește explicit cu o regulă de acces este respinsă; nu există comportament implicit permisiv pe care cineva să uite să îl restrângă. Regula se aplică pe server, la fiecare cerere, nu în interfață — o cerere trimisă direct, fără să treacă prin ecran, urmează același drum.
Datele fiecărei organizații sunt izolate la nivel de tenant. Separarea nu este o condiție adăugată la sfârșitul unei interogări, ci face parte din modul în care se construiește accesul la date, astfel încât o interogare scrisă greșit să nu poată, prin omisiune, să scoată date din alt tenant.
Protecția anti-IDOR — insecure direct object reference — înseamnă că identificatorul unui obiect nu este, prin el însuși, o cheie de acces. Faptul că un utilizator cunoaște sau ghicește numărul unui document nu îi dă dreptul să îl deschidă; dreptul se verifică separat, pe obiectul concret.
- drepturi separate pentru consultare, creare, modificare și anulare, configurabile pe fiecare componentă;
- verificarea accesului pe server, la fiecare cerere, independent de ce afișează interfața;
- izolarea datelor pe tenant, parte din construcția accesului, nu condiție adăugată ulterior;
- jurnal de audit pentru operațiunile asupra documentelor și înregistrărilor.
Ce câștigă organizația
Un operator de date care primește o solicitare de acces, o rectificare sau o cerere de ștergere trebuie să răspundă în termen și să poată arăta ce a făcut. Un sistem în care accesul este verificat consecvent și în care operațiunile lasă urmă transformă aceste solicitări din proiect de investigație în interogare.
La fel funcționează și la control. Întrebarea „cine a avut acces la acest dosar și când" primește răspuns din jurnal, nu din reconstituire. Iar separarea clară între roluri reduce discuția despre responsabilitate: se vede cine putea să facă ce.
Întrebări frecvente
Platforma este conformă cu GDPR?
Conformitatea aparține operatorului de date, nu unui produs software. Platforma oferă mecanismele pe care operatorul se sprijină: autorizare deny-by-default, izolare pe tenant, drepturi pe rol și jurnal de audit. Configurarea concretă, temeiurile de prelucrare și politicile de retenție rămân decizii ale organizației.
Ce înseamnă deny-by-default în practică?
Înseamnă că o cerere fără o regulă de acces care să o permită explicit este respinsă. Consecința practică: un drept uitat nu devine un drept acordat din greșeală.
Cum se verifică izolarea între organizații?
Separarea pe tenant face parte din modul în care se construiește accesul la date, nu dintr-o condiție adăugată la fiecare interogare. Vă putem arăta mecanismul într-o demonstrație tehnică.
Se poate integra cu politicile interne de securitate existente?
Da. Drepturile se definesc pe roluri, iar rolurile se pot alinia la structura organizatorică și la politicile deja aprobate. Integrarea cu un director de identități se discută separat, în funcție de infrastructura dumneavoastră.
Discutăm despre GDPR & INFOSEC
Vă putem arăta componenta în funcțiune pe datele dumneavoastră, vă putem trimite o ofertă pentru dimensiunea organizației sau vă putem răspunde punctual la întrebări tehnice.