Das Principle of Least Privilege (PoLP) – Least-Privilege-Prinzip oder Prinzip der minimalen Rechtevergabe – besagt, dass jede Person, jeder Prozess und jedes System genau die minimalen Zugriffsrechte erhalten sollte, die für die Erfüllung ihrer definierten Aufgabe notwendig sind – nicht mehr. Kein Mehr an Rechten aus Bequemlichkeit, Voraussicht für mögliche zukünftige Aufgaben oder weil es einfacher zu konfigurieren ist.
Least Privilege ist ein fundamentales Sicherheitsprinzip, das den Blast Radius – den maximalen Schaden, den ein kompromittiertes Konto oder System anrichten kann – auf ein Minimum begrenzt. Es schützt gleichzeitig vor externen Angreifern, die sich über ein kompromittiertes Konto weitere Zugänge verschaffen wollen, und vor internen Fehlern, bei denen ein Mitarbeiter oder Workflow versehentlich Daten löscht oder ändert, auf die er eigentlich keinen Schreibzugriff haben sollte.
Häufige Verletzungen des Least-Privilege-Prinzips
Verstoß Admin-Accounts für Alltagsaufgaben: Entwickler arbeiten täglich mit Admin-Rechten, weil es bequemer ist. Ein Phishing-Angriff auf diesen Account gibt sofort vollen Systemzugriff.
Verstoß Service-Accounts mit Breitrechten: Workflow-Service-Account hat Admin-Rechte auf das gesamte ERP, obwohl er nur zwei Endpunkte braucht.
Verstoß Gruppenweise Adminrechte: Alle Entwickler im Team haben Admin-Zugang zu Produktionssystemen, auch wenn nur 2 von 8 diesen tatsächlich regelmäßig brauchen.
Korrekt Scoped API-Keys: API-Key für Rechnungsworkflow hat nur Lese- und Schreibrecht auf Kreditorenbuchhaltung – nicht auf Debitoren, Personalstammdaten oder Admin-Funktionen.
Korrekt Just-in-Time Access: Erhöhte Produktionsrechte werden nur auf explizite Anfrage für eine definierte Zeit gewährt und automatisch nach Ablauf entzogen.
Least Privilege für Automatisierungsworkflows umsetzen
Die praktische Umsetzung beginnt mit einer einfachen Frage für jeden Workflow und jeden API-Key: Was ist die minimale Menge an Rechten, die dieser Workflow für seine Aufgabe braucht? Lesen oder schreiben? Welche Tabellen? Welche API-Endpunkte? In welchen Systemen? Die Antwort definiert den Scope. Dann wird genau dieser Scope konfiguriert – nicht mehr. Anfangs fühlt sich das aufwändig an; nach dem zweiten Mal ist es zur Routine geworden.
Praxisbeispiel
Ein Automationsdienstleister wendet Least Privilege konsequent auf alle neuen Workflow-Deployments an. Methode: Vor jedem Deployment wird eine „Minimal-Rechte-Analyse“ durchgeführt. Rechnungsverarbeitungs-Workflow: braucht Lesezugriff auf E-Mail-Postfach (nur Rechnungs-Ordner, nicht Inbox), Schreibzugriff auf ERP-Modul Kreditorenbuchhaltung, Lesezugriff auf Lieferanten-Stammdaten (nur Name, IBAN, Steuernummer). Kein Zugriff auf: Debitoren, HR, Vertrieb, Admin-Konsolen. Ergebnis über alle 34 Workflows: Durchschnittlicher Rechte-Scope reduziert von ursprünglich 100 Prozent Systemzugriff auf 18 Prozent. Bei einem simulierten Angriffsszenario: maximaler Schaden eines kompromittierten Workflows = Zugriff auf 18 Prozent statt 100 Prozent des Systems.
