Principle of Least Privilege, Uitgelegd

Least privilege klinkt vanzelfsprekend zodra je het hardop zegt: geef een account, proces of gebruiker alleen de toegang die nodig is om zijn werk te doen, niets meer. Het gat tussen dat zeggen en je systemen werkelijk op die manier runnen is waar de meeste inbreuken van een klein incident in een volledige domeincompromittering veranderen.

Wat het werkelijk betekent

Het principe van least privilege (PoLP) zegt dat elk subject in een systeem — een gebruiker, een service account, een applicatie, een container — met de minimale set van permissies moet werken die nodig zijn om zijn functie te vervullen. Niet de permissies die handig zijn. Niet de permissies die iemand drie jaar geleden toebedeeld heeft en is vergeten in te trekken. Het minimum.

Dit geldt op elke laag: bestandssysteem permissies, databaserollen, API scopes, cloud IAM policies, firewall regels, sudo-toegang. Een webserverproces dat statische bestanden leest hoeft geen schrijftoegang tot /etc. Een rapportscript dat alleen SELECT queries uitvoert heeft geen databaserol met DROP TABLE rechten nodig. Een stagiair in marketing hoeft geen domeinadmin omdat het makkelijker was dan de juiste groep uitzoeken.

Waarom het meer uitmaakt dan het klinkt

Wanneer een aanvaller een account of proces compromitteert, erven zij alles wat die account kan doen. Als de laptop van een gephisht personeelslid alleen toegang tot de bestanden die relevant zijn voor hun team heeft, is het bereik van die phishing beperkt. Als diezelfde account toevallig domeinadmin rechten heeft omdat IT dit eens ingesteld heeft voor troubleshooting en het nooit teruggedraaid heeft, bezit de aanvaller nu het netwerk.

Dit is de logica achter de meeste post-breach forensische rapporten: initiële toegang was weinig waardevol, maar lateral movement via overtoestane accounts heeft het in ransomware over de hele omgeving veranderd. Overtollige privilege veroorzaakt niet de initiële inbreuk, maar het is haast altijd wat de inbreuk kostbaar maakt.

Waar het in de praktijk voorkomt

Cloud IAM. AWS, Azure en GCP hebben standaard permissief gedrag als je niet voorzichtig bent — een IAM policy met "Action": "*" en "Resource": "*" zal validatie doorstaan en prima werken, totdat een gelekt access key een aanvaller volledige accountcontrole geeft. Beperk policies tot specifieke acties en resource ARNs in plaats van wildcards te gebruiken.

Service accounts. Dit zijn vaak de ergste overtreders omdat niemand ze op dezelfde manier controleert als menselijke accounts. Een CI/CD pipeline die naar één S3 bucket deployt hoeft geen credentials te hebben die elke bucket in de account kunnen lezen.

Databaserollen. Scheid read-only rapportagrollen van applicatierollen die INSERT/UPDATE nodig hebben, en scheid deze van de DBA rol die schema kan wijzigen. PostgreSQL en MySQL ondersteunen beide granulaire GRANT statements — gebruik ze in plaats van elke app-connectie gelijk te stellen aan root.

Sudo en lokale admin. Just-in-time elevation (vraag toegang, krijg het voor een beperkt venster, verlies het automatisch) is altijd beter dan vaste admin rechten. Tools als sudo met tijdgebonden regels, of PAM oplossingen in enterprise omgevingen, bestaan specifiek hiervoor.

De spanning met