Begriff

Least Privilege

Security IAM S1

2 Quellen 0 Lernpfade 3 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Gib einem Handwerker nicht deinen ganzen Schlüsselbund, sondern nur den Schlüssel für den Keller. Gib einer App nicht Admin-Rechte ("God Mode"), wenn sie nur Logfiles schreiben muss. Das Prinzip der geringsten Rechte (Principle of Least Privilege). Jeder User und jedes Programm bekommt nur genau so viele Rechte, wie es unbedingt braucht, um die Arbeit zu tun. Nicht mehr. Warum? Wenn die App gehackt wird, kann der Hacker nur Logfiles schreiben, aber nicht die Datenbank löschen. Der Schaden ("Blast Radius") ist begrenzt.

Merksatz: Ein Sicherheitskonzept, bei dem Benutzer, Prozesse und Systeme nur die minimal notwendigen Zugriffsrechte erhalten, um ihre Aufgaben zu erfüllen.

Linux: Logge dich nie als root ein. Nutze einen normalen User und sudo nur für einzelne Befehle.
Datenbank: Die Web-App bekommt einen DB-User, der nur SELECT, INSERT, UPDATE darf, aber kein DROP TABLE.
AWS: Gib dem Praktikanten keine AdministratorAccess Policy, sondern nur S3ReadOnlyAccess.

1. Just-in-Time (JIT) Privileges

Selbst Admins sollten nicht dauerhaft Admin sein ("Standing Privileges"). Wenn der Admin-Laptop geklaut wird, ist alles weg. Besser: JIT Access. Der Admin beantragt "Ich brauche für 2 Stunden Zugriff auf Prod-DB". Das System genehmigt es (Auto oder Vier-Augen) und gibt ihm temporäre Rechte. Nach 2 Stunden verfallen sie automatisch. Tools: Google Cloud IAP, Teleport, AWS SSO.

2. Capabilities (Linux)

root darf alles. Das ist zu grob. Mit Capabilities zerlegt man Root-Rechte in Scheibchen.

CAP_NET_BIND_SERVICE: Darf Ports < 1024 binden (Webserver).
CAP_SYS_TIME: Darf die Uhrzeit ändern. Eine sichere App läuft als User nobody, hat aber nur CAP_NET_BIND_SERVICE. Selbst wenn sie gehackt wird, kann sie die Uhrzeit nicht ändern.

3. Service Accounts in K8s

In Kubernetes hat jeder Pod automatisch ein Token (default ServiceAccount). Oft hat dieser Account zu viele Rechte. Hacker im Pod können kubectl get secrets machen. Best Practice: automountServiceAccountToken: false setzen, wenn der Pod nicht mit der API reden muss. Wenn doch: Eigene Role erstellen (RBAC), die nur get pods darf, sonst nichts.

1. IAM Access Analyzer (Automated Right-Sizing)

Das Prinzip der minimalen Rechte ist in AWS/GCP manuell katastrophal schwer abzubilden. Du gibst einem Dev FullAccess, weil das Troubleshooting für einen fehlenden API-Call die Entwicklungszeit blockiert. Um nachträglich auf "Least Privilege" zu härten, bedient man sich CloudTrail und IAM Access Analyzern. Diese Machine-Learning Scanner scannen für 90 Tage lückenlos alle Events auf dem JSON-IAM-Policy-Rumpf des Entwicklers. Anschließend werfen sie eine maschinell generierte Policy (Right-Sized Pattern) zurück. Der Scanner erkennt präzise: "Der Entwickler besitzt die Berechtigung für 400 EC2-Actions, nutzte aber nur StartInstance und DescribeInstance". Der Cloud Administrator wendet diese generierte Schrumpf-Policy an, ohne jemals manuell zu auditieren.

2. Privilege Escalation Paths

Ein Hacker sucht nach Systemen, wo Least Privilege dumm umgesetzt wurde. Er sucht Privilege Escalation Lücken. Beispiel im Linux/Kerberos: Ein Apache Webserver-User (www-data) hat eingeschränkte Rechte. Aber er darf einen verdeckten Cronjob triggern, der als User Root den Speicher des Webservers aufräumt (Logrotation). Der Hacker platziert ein manipuliertes Perl-Script im Log-Ordner. Der Root-Cronjob führt es blind via Wildcard aus. Zwar wurde der www-data Account beschränkt, aber durch den fehlerhaften Transition-Pfad wird die Schadsoftware versehentlich im Ring-0 Privilegien-State abgesetzt. Pures Hacking-Gold, weswegen "Least Privilege" immer transitive Ausführsketten (Container-Breakouts) mit einbeziehen muss.

3. Token Vending Machines (TVMs)

Eine App muss in den S3-Speichereimer. Traditionell steckt der Admin dicke AWS-Access-Keys in eine config.ini des Webservers. Wenn der Server kompromittiert wird, stiehlt der Hacker den Masterkey für immer. Enterprise Architektur verzichtet vollständig auf solche Long-Term Credentials. Sie verwenden Token Vending Machines, meist gestützt von AWS STS (Security Token Service) oder HashiCorp Vault. Die App fordert per Zertifikat einen Zugang an. Das System feuert ein flüchtiges SAS-Token (Shared Access Signature) aus. Dieses Token hat Read-Rechte, existiert aber hartcodiert exakt auf Lebenszeit von nur noch "60 Sekunden". Ein Krypto-Diebstahl des Schlüssels ist danach logisch wertlos.

Quick-Check

Was ist "Privilege Escalation"?
Der Angriff, bei dem man mit wenig Rechten anfängt (User) und eine Lücke nutzt, um mehr Rechte zu bekommen (Root). Least Privilege erschwert das, verhindert es aber nicht (Kernel Bugs).
Ist es unbequem?
Ja. Zu wenig Rechte -> "Permission Denied". Entwickler hassen es ("Mach mir einfach Full Access, damit es läuft!"). Sicherheit ist immer ein Trade-Off mit Bequemlichkeit ("Friction").
Wie finde ich die "Least Privileges"?
Schwer. Man fängt oft restriktiv an, schaut in die Audit-Logs ("Access Denied"), und gibt dann genau dieses Recht dazu. Tools wie AWS IAM Access Analyzer helfen dabei ("Dieser User hat S3FullAccess, nutzt aber seit 90 Tagen nur Read. Ich schlage ReadOnly vor.").