Principiul Celui Mai Mic Privilegiu, Explicat

Principiul celui mai mic privilegiu pare evident odată ce îl spui cu voce tare: acordă unui cont, proces sau utilizator doar accesul de care are nevoie pentru a-și face treaba, nimic mai mult. Diferența dintre a spune asta și a rula sistemele în realitate în acest fel este ceea ce transformă de obicei o breșă minoră într-o compromitere completă a domeniului.

Ce înseamnă cu adevărat

Principiul celui mai mic privilegiu (PoLP) spune că fiecare subiect dintr-un sistem — un utilizator, un cont de serviciu, o aplicație, un container — ar trebui să funcționeze cu setul minim de permisiuni necesar pentru a-și completa funcția. Nu permisiunile care sunt convenabile. Nu permisiunile pe care cineva le-a acordat acum trei ani și a uitat să le revoce. Minimul.

Aceasta se aplică la fiecare nivel: permisiuni de sistem de fișiere, roluri bază de date, dimensiuni API, politici cloud IAM, reguli firewall, acces sudo. Un proces server web care citește fișiere statice nu are nevoie de acces de scriere la /etc. Un script de rapoarte care rulează doar interogări SELECT nu are nevoie de un rol bază de date cu drepturi DROP TABLE. Un stagiar din marketing nu are nevoie de drepturi de admin de domeniu pentru că a fost mai ușor decât să afle grupul corect.

De ce contează mai mult decât sună

Când un atacator compromite un cont sau un proces, moștenește tot ceea ce poate face acel cont. Dacă laptopul unui angajat phishing are acces doar la partajările de fișiere relevante pentru echipa lor, raza de acțiune a phishing-ului este conținută. Dacă același cont se întâmplă să aibă drepturi de admin de domeniu pentru că IT l-a setat o dată așa pentru troubleshooting și nu l-a readus niciodată, atacatorul acum posedă rețeaua.

Aceasta este logica din spatele celor mai multe rapoarte forense post-breșă: accesul inițial era de valoare scăzută, dar mișcarea laterală prin conturi prea permisive l-a transformat în ransomware în întregul mediu. Privilegiul excesiv nu cauzează compromiterea inițială, dar este aproape întotdeauna ceea ce face compromiterea scumpă.

Unde apare în practică

Cloud IAM. AWS, Azure și GCP implicit au comportament permisiv dacă nu ești atent — o politică IAM cu "Action": "*" și "Resource": "*" va trece validarea și va funcționa bine, până când o cheie de acces scurgă îi dă unui atacator control complet al contului. Limitează politicile la acțiuni și ARN-uri de resurse specifice în loc să apelezi la wildcard-uri.

Conturi de serviciu. Acestea sunt frecvent cei mai rău ofensatori pentru că nimeni nu le revizuiește cum revizuiesc conturi umane. Un pipeline CI/CD care se implementează pe un bucket S3 nu ar trebui să dețină credențiale care pot citi fiecare bucket din cont.

Roluri bază de date. Separă rolurile de raportare doar citire de rolurile aplicației care au nevoie de INSERT/UPDATE și separă-le de rolul DBA care poate modifica schema. PostgreSQL și MySQL ambele suportă declarații GRANT granulare — folosește-le în loc să dai fiecărei conexiuni aplicație echivalentul root.

Sudo și admin local. Elevarea just-in-time (cere acces, primește-l pentru o fereastră limitată, pierde-l automat) bate drepturile de admin permanente de fiecare dată. Instrumente ca sudo cu reguli cu limită de timp sau soluții PAM în medii enterprise există specific pentru asta.

Tensiunea cu