„Fiecare program și fiecare utilizator al sistemului ar trebui să opereze folosind cel mai mic set de privilegii necesar pentru a-și îndeplini sarcina.”Jerome Saltzer, Michael Schroeder · The Protection of Information in Computer Systems · 1975 · The Protection of Information in Computer Systems, Proceedings of the IEEE 63(9), 1975 — §I.A.3, principiul (f), least privilege
Orice privilegiu pe care nu-l poți justifica printr-o sarcină e unul de scos.
Un sistem sursă expune un client; depozitul îi expune pe toți, cu istoric. De aceea principiul din 1975 e aici mai concret decât oriunde. Privilegiul minim se aplică pe trei axe: tabele (un rol vede doar schemele de care are nevoie), coloane (mascare dinamică: analistul vede ultimele patru cifre, contabilitatea vede tot) și rânduri (securitate la nivel de rând: un agent de vânzări vede doar regiunea lui, prin aceeași vedere, fără copii ale tabelului). Accesul la seiful de identitate din lecția 18 e un rol separat, acordat separat. Dedesubt, două straturi care nu se negociază: criptare în repaus, cu chei administrate în afara depozitului și rotite, și criptare în tranzit. Deasupra, auditul: fiecare interogare pe tabelele sensibile e înregistrată — cine, când, ce a citit, câte rânduri — păstrată și, mai ales, citită de cineva. Capcanele obișnuite sunt banale și de aceea frecvente: un cont de serviciu pentru instrumentul de BI cu drepturi pe tot depozitul, folosit de toți; secrete lipite în SQL; conturi partajate care fac auditul inutil. Regula lui Saltzer și Schroeder, citită invers: orice privilegiu pe care nu-l poți justifica printr-o sarcină e unul de scos.
Cardul acoperă cele trei axe: tabele, coloane, rânduri. Pasul următor e timpul. Un privilegiu poate fi minim la o oră și excesiv la alta. De aceea accesul larg la depozit ar trebui să fie temporar: ridici drepturile pentru o fereastră scurtă, faci lucrarea, apoi ele expiră singure. Exemplul de zi cu zi: nimeni nu împrumută cheia de la casă toată ziua; o ceri la plată și o predai imediat. La fel, un inginer cere acces de citire la tabelul de salarii doar pentru sesiunea de depanare de marți. Contul permanent larg devine excepția, nu regula. Astfel auditul capătă sens: înregistrarea arată nu doar cine a citit ce, ci și de ce avea dreptul în acel moment. Dar temporaritatea ridică o întrebare nouă: cine are voie să acorde aceste ferestre de acces?
Pasajul 1 s-a oprit la întrebare: cine acorde ferestrele de acces? Răspunsul din 1975 e separarea sarcinilor. Persoana care cere acces nu trebuie să fie cea care îl aprobă, iar cea care aprobă nu trebuie să fie cea care verifică apoi. Într-o firmă mică asta pare exagerat, dar funcționează simplu: dezvoltatorul cere acces, lead-ul echipei aprobă, iar raportul de audit ajunge lunar la securitate. Trei ochi diferiți, nu unul. Exemplul de zi cu zi: la bancă, cel care deschide seiful nu e cel care numără banii. La fel, în depozit, un cont de serviciu nu ar trebui să-și poată extinde singur drepturile. Dacă același om cere, acordă și verifică, privilegiul minim devine doar un formular semnat de el însuși. Dar aprobarea e doar jumătate din mecanism — ce se întâmplă când cineva abuzează totuși de accesul primit?
De ce contează Un singur cont de serviciu supra-privilegiat transformă o breșă într-un instrument de raportare într-o scurgere a întregului istoric al firmei.