Least Privilege.

Das Prinzip, und warum es in der Praxis immer wieder scheitert

Least Privilege ist leicht zu formulieren und schwer zu leben. Jede Identität, ob eine Person, ein Dienstkonto, ein Automatisierungsskript oder ein API-Schlüssel, sollte genau die Berechtigungen besitzen, die ihre Aufgabe erfordert, und nichts darüber hinaus. Das Versagen ist selten eine bewusste Entscheidung, zu viel zu gewähren. Es ist Anhäufung. Jemand benötigt Administratorrechte für eine einmalige Migration, und die Vergabe wird nie wieder entzogen.

Ein Dienstkonto wird mit weiten Berechtigungsbereichen erstellt, weil deren Einschränkung einen Nachmittag voller Tests erfordern würde, für den niemand Zeit hat. Einem Team wird eine Rolle zugewiesen, die für ein anderes Team entworfen wurde, weil sie die am besten passende verfügbare war. Über Monate hinweg sammeln Identitäten Berechtigungen an, wie ein Schreibtisch Papier ansammelt, und niemand kann erklären, warum eine bestimmte überhaupt da ist.

Diese Anhäufung ist die Angriffsfläche. Wenn ein überberechtigtes Konto Opfer von Phishing wird, durchsickert oder unbemerkt missbraucht wird, ist der Wirkungsradius alles, was dieses Konto erreichen konnte, was in der Regel weit mehr ist als seine tatsächliche Aufgabe. Die Disziplin des Least Privilege liegt nicht in der anfänglichen Vergabe, die der einfache Teil ist. Sie liegt in der fortlaufenden Arbeit, das Nicht-mehr-Benötigte zu entfernen und das Verbleibende rechtfertigen zu können.

Wie Praktiker es tatsächlich umsetzen

Least Privilege ist eine durch Werkzeuge gestützte betriebliche Gewohnheit, keine einmalige Konfiguration. Die Arbeit gruppiert sich um einige wiederkehrende Aktivitäten:

• Rollen- und Berechtigungsdesign: Rollen um Tätigkeitsfunktionen herum aufbauen, sodass die Vergabe von Zugriff eine bewusste Zuordnung ist und nicht eine Kopie dessen, was die vorherige Person hatte.
• Just-in-Time- und Just-Enough-Zugriff: erhöhte Rechte für das Zeitfenster gewähren, in dem sie benötigt werden, und sie danach automatisch entziehen, statt dauerhafte Administratorberechtigungen bestehen zu lassen.
• Zugriffsüberprüfungen: regelmäßig erneut prüfen, wer was besitzt, und einen Verantwortlichen verpflichten zu bestätigen, dass jede Vergabe weiterhin gerechtfertigt ist. Alles, wofür niemand einstehen will, wird widerrufen.
• Funktionstrennung: sensible Aktionen aufteilen, sodass keine einzelne Identität einen Vorgang mit hohem Risiko sowohl initiieren als auch genehmigen kann, was Least Privilege angewendet auf Arbeitsabläufe statt auf Daten bedeutet.
• Maschinenidentitäten: Dienstkonten, Token und Pipeline-Anmeldedaten mit derselben Sorgfalt behandeln wie menschliche Benutzer, denn sie sind oft die am stärksten überberechtigten und die am wenigsten überprüften.

Wo es zwischen Zero Trust, IAM und PAM steht

Least Privilege ist ein Prinzip. Die benachbarten Begriffe sind die Maschinerie, die es umsetzt. Identitäts- und Zugriffsverwaltung (IAM) ist das System, das Identitäten und deren Handlungsmöglichkeiten definiert, sodass Least Privilege die Regel ist, die IAM durchsetzen soll. Privileged Access Management (PAM) ist die strengere Disziplin, die auf die risikoreichsten Konten angewendet wird, wo Least Privilege am wichtigsten ist und wo die Just-in-Time-Erhöhung üblicherweise angesiedelt ist.

Zero Trust ist die umfassendere Architektur, die davon ausgeht, dass keine Identität standardmäßig vertrauenswürdig ist, und jede Anfrage verifiziert; Least Privilege ist einer ihrer Kernmechanismen, denn das Verifizieren einer Anfrage hilft nur, wenn der gewährte Zugriff bereits minimal ist. Man kann das Prinzip ohne die Werkzeuge vertreten, aber in jeder realen Größenordnung verfällt das Prinzip ohne IAM, PAM und regelmäßige Überprüfungen still und leise wieder zur Überprovisionierung.

Der Gedanke zieht sich durch die Standards, selbst dort, wo die genaue Formulierung variiert. ISO/IEC 27001 Annex A behandelt Zugriffskontrolle, privilegierte Zugriffsrechte und die regelmäßige Überprüfung der Zugriffsrechte von Benutzern. Die NIST-Zugriffskontrollfamilie ist um Least Privilege und Funktionstrennung als benannte Prinzipien herum aufgebaut. Die CIS Controls fordern den kontrollierten Einsatz administrativer Berechtigungen und die Kontoverwaltung. Auditoren wollen nicht nur sehen, dass Zugriff einmal korrekt gewährt wurde. Sie erwarten den Nachweis eines fortlaufenden Überprüfungszyklus, und ein dauerhaftes Administratorkonto, das niemand überprüft, wird als Feststellung behandelt, nicht als Bequemlichkeit.