Principle of Least Privilege, Explained

Das Prinzip der minimalen Berechtigung klingt offensichtlich, wenn man es ausspricht: Geben Sie einem Konto, Prozess oder Benutzer nur den Zugriff, den er für seine Aufgabe benötigt, nichts mehr. Die Lücke zwischen dem Aussprechen und dem tatsächlichen Betrieb Ihrer Systeme auf diese Weise ist dort, wo die meisten Sicherheitsverletzungen von einem kleineren Zwischenfall zu einer vollständigen Domänenkompromittierung führen.

Was es wirklich bedeutet

Das Prinzip der minimalen Berechtigung (PoLP) besagt, dass jedes Subjekt in einem System — ein Benutzer, ein Service-Konto, eine Anwendung, ein Container — mit der minimalen Menge an Berechtigungen arbeiten sollte, die zur Erfüllung seiner Funktion erforderlich sind. Nicht die Berechtigungen, die praktisch sind. Nicht die Berechtigungen, die jemand vor drei Jahren gewährt hat und vergessen hat zu widerrufen. Die minimale Menge.

Dies gilt auf jeder Ebene: Dateisystem-Berechtigungen, Datenbankrollen, API-Scopes, Cloud-IAM-Richtlinien, Firewall-Regeln, sudo-Zugriff. Ein Webserver-Prozess, der statische Dateien liest, benötigt keinen Schreibzugriff auf /etc. Ein Reporting-Skript, das nur SELECT-Abfragen ausführt, benötigt keine Datenbankrolle mit DROP TABLE-Rechten. Ein Marketing-Praktikant benötigt keine Domain-Admin-Rechte, weil es einfacher war, als herauszufinden, welche Gruppe richtig ist.

Warum es wichtiger ist, als es klingt

Wenn ein Angreifer ein Konto oder einen Prozess kompromittiert, erbt er alles, was dieses Konto tun kann. Wenn der Laptop eines phished Mitarbeiters nur Zugriff auf die für sein Team relevanten Dateifreigaben hat, ist der Schadensbereich dieses Phishing begrenzt. Wenn dasselbe Konto zufällig Domain-Admin-Rechte hat, weil die IT es einmal so eingerichtet hat und es nie zurückgerollt hat, besitzt der Angreifer jetzt das Netzwerk.

Dies ist die Logik hinter den meisten Forensik-Berichten nach einem Sicherheitsverstoß: Der initiale Zugriff war von geringem Wert, aber die seitliche Bewegung durch über-berechtigte Konten verwandelte ihn in Ransomware in der gesamten Umgebung. Übermäßige Berechtigung verursacht nicht die initiale Kompromittierung, aber sie ist fast immer das, was die Kompromittierung teuer macht.

Wo es in der Praxis auftritt

Cloud IAM. AWS, Azure und GCP haben standardmäßig permissives Verhalten, wenn Sie nicht aufpassen — eine IAM-Richtlinie mit "Action": "*" und "Resource": "*" wird validiert und funktioniert einwandfrei, bis ein durchgesickerter Zugriffsschlüssel einem Angreifer die vollständige Kontokontrolle gibt. Begrenzen Sie Richtlinien stattdessen auf spezifische Aktionen und Ressourcen-ARNs.

Service-Konten. Diese sind häufig die schlimmsten Verursacher, da niemand sie so überprüft wie menschliche Konten. Eine CI/CD-Pipeline, die in einen S3-Bucket bereitgestellt wird, sollte nicht die Anmeldedaten halten, die jeden Bucket im Konto lesen können.

Datenbankrollen. Trennen Sie schreibgeschützte Reporting-Rollen von Anwendungsrollen, die INSERT/UPDATE benötigen, und trennen Sie diese von der DBA-Rolle, die das Schema ändern kann. PostgreSQL und MySQL unterstützen beide granulare GRANT-Anweisungen — verwenden Sie diese, anstatt jeder App-Verbindung das Äquivalent von root zu geben.

Sudo und lokaler Admin. Just-in-time-Erhöhung (Zugriff anfordern, für ein begrenztes Zeitfenster erhalten, ihn automatisch verlieren) schlägt permanente Admin-Rechte jedes Mal. Tools wie sudo mit zeitlich begrenzten Regeln oder PAM-Lösungen in Unternehmensumgebungen existieren genau dafür.

Die Spannung mit