30. September 2026 · IT-Sicherheit · Zero Trust · Compliance · Schwachstellenmanagement

Least Privilege steht im Etikett, nicht auf dem Host

Konten gelten als minimal berechtigt, der Host erlaubt oft weit mehr. Wie Sie echte Rechte prüfen und warum es eine Negativprobe braucht.

„Least Privilege“ – das Prinzip der geringsten Berechtigung – gehört zu den wenigen Sicherheitsgrundsätzen, gegen die niemand etwas einwendet. Entsprechend oft steht es geschrieben: in Berechtigungskonzepten, Rollenbeschreibungen, Anträgen und Betriebshandbüchern. Nur entscheidet keines dieser Dokumente darüber, was ein Konto tatsächlich darf. Das entscheidet die Konfiguration des Systems, auf dem das Konto arbeitet. Dieser Beitrag beschreibt, warum beides auseinanderlaufen kann, wie Sie den tatsächlichen Stand erheben und was vor einer Korrektur bedacht sein will.

Was die Standards verlangen

Die Anforderung selbst ist in den gängigen Rahmenwerken inhaltlich gleich gefasst. NIST beschreibt sie in SP 800-53 als Kontrolle AC-6: Erlaubt werden nur die Zugriffe, die für die zugewiesenen Aufgaben notwendig sind – ausdrücklich auch für Prozesse, die im Auftrag von Benutzern handeln. Automatisierung und Dienstkonten sind damit nicht ausgenommen, sondern mitgemeint. Die Erweiterungen der Kontrolle werden konkreter: Privilegierte Konten sind auf festgelegte Personen oder Rollen zu beschränken (AC-6(5)), zugewiesene Rechte regelmäßig auf ihre Notwendigkeit zu prüfen und gegebenenfalls zu entziehen (AC-6(7)), und die Ausführung privilegierter Funktionen ist zu protokollieren (AC-6(9)).

Das BSI verlangt im IT-Grundschutz-Baustein ORP.4 dasselbe Prinzip: Kennungen und Berechtigungen dürfen nur aufgrund des tatsächlichen Bedarfs vergeben werden (ORP.4.A2). Bemerkenswert ist die Anforderung ORP.4.A3. Sie verlangt nicht nur, dass Kennungen und Rechteprofile dokumentiert werden, sondern dass diese Dokumentation „regelmäßig daraufhin überprüft werden“ muss, „ob sie den tatsächlichen Stand der Rechtevergabe widerspiegelt“.

Damit ist die Prüfrichtung vorgegeben: vom System zur Dokumentation, nicht umgekehrt. Eine Dokumentation, die niemand gegen die Wirklichkeit abgleicht, beschreibt eine Absicht.

Das Muster: Dokumentation sagt X, effektive Rechte sagen Y

Die Abweichung ist selten das Ergebnis von Nachlässigkeit. Sie entsteht, weil Berechtigungen an mehreren Stellen gleichzeitig wirken – und weil ein Name oder eine Beschreibung leichter zu lesen ist als eine effektive Berechtigung. Zwei Lehrbuchbeispiele machen das greifbar.

Angenommen, ein Dienstkonto für die Datensicherung ist im Berechtigungskonzept als „nur lesend“ beschrieben. Im Verzeichnisdienst ist es Mitglied einer Gruppe, die ihrerseits Mitglied einer administrativen Gruppe ist. Jede einzelne Mitgliedschaft wirkt plausibel. In der Summe darf das Konto weit mehr als lesen – und wer nur die direkte Gruppenmitgliedschaft betrachtet, sieht es nicht.

Angenommen, eine Rolle in einer Plattform trägt den Namen „Betrachter“, enthält aber neben Leserechten auch die Berechtigung, Rollenzuweisungen zu ändern. Der Name ist korrekt gewählt, die Rolle nicht. Wer die Rolle zuweist und sich auf den Namen verlässt, vergibt faktisch die Möglichkeit, sich selbst weitere Rechte zu geben.

In beiden Fällen gilt derselbe Grundsatz: Durchgesetzt ist eine Einschränkung nur dort, wo das Zielsystem sie prüft. Was im Konzept, im Namen oder in einem aufrufenden Werkzeug steht, ist eine Beschreibung, keine Kontrolle.

Das System fragen, nicht die Dokumentation

Die tatsächlichen Rechte lassen sich in aller Regel direkt beim System erfragen:

  • Unter Linux mit sudo: sudo -n -l listet laut Handbuch die Rechte des aufrufenden Benutzers auf dem aktuellen Host. Die Option -n verhindert jede Passwortabfrage – ist eine Eingabe nötig, bricht sudo mit einer Fehlermeldung ab, statt zu warten. Das macht den Aufruf für automatisierte Prüfungen geeignet. Mit einem angehängten Befehl beantwortet sudo gezielt, ob genau dieser Aufruf erlaubt wäre, ohne ihn auszuführen.
  • In Verzeichnisdiensten: die effektiven Berechtigungen eines Kontos auf einem Objekt, einschließlich verschachtelter Gruppen und vererbter Rechte – nicht die Liste der Gruppen, in denen es Mitglied sein sollte.
  • In Cloud- und Plattformdiensten: die ausgewertete Richtlinie für eine konkrete Aktion, nicht die Rollenbezeichnung.

Ohne Negativprobe beweist die Prüfung nichts

Eine Prüfung, die nur den erlaubten Fall bestätigt, hat eine eingebaute Schwäche. Die Frage „Darf das Konto, was es darf?“ wird auch von einem Konto mit Vollzugriff mit Ja beantwortet. Das Ergebnis unterscheidet also nicht zwischen einem sauber eingeschränkten und einem uneingeschränkten Konto.

Aussagekräftig ist erst die Gegenprobe: eine Anfrage, die abgewiesen werden muss. Angenommen, ein Konto soll ausschließlich einen bestimmten Dienst neu starten dürfen. Dann gehören zur Prüfung Fragen wie: Darf es die Berechtigungskonfiguration bearbeiten? Konten anlegen? Eine beliebige Shell mit erhöhten Rechten starten? Mit sudo -n -l <befehl> lassen sich solche Fragen stellen, ohne etwas auszuführen; in Verzeichnisdiensten und Plattformen leisten die Auswertungen der effektiven Berechtigungen dasselbe. Ein Nein auf sudo -n -l /bin/sh schließt eine Root-Shell allerdings nicht aus: Erlaubte Programme mit Shell-Escape – etwa find, vim oder less – oder Platzhalter in den erlaubten Argumenten öffnen denselben Weg. Kommt bei einer dieser Fragen ein Ja, ist die Beschreibung falsch – ganz gleich, was die Positivprüfung ergeben hat.

Zwei Details machen die Negativprobe belastbar. Erstens: Werten Sie die Antwort aus, nicht nur das Ausbleiben eines Ja. Ein Aufruf, der wegen eines Netzwerkfehlers oder einer unerwarteten Passwortabfrage gar nicht zustande kam, sieht sonst aus wie eine Ablehnung. Zweitens: Die Negativprobe gehört in die regelmäßige Überprüfung nach AC-6(7) und ORP.4.A3, nicht nur in die Abnahme. Berechtigungen ändern sich durch Konfigurationsmanagement, Updates und Notfalleingriffe.

Vor dem Einschränken den Reparaturweg sichern

Wer eine zu weit gefasste Berechtigung findet, will sie schließen. Dabei gilt ein Grundsatz, der in Planungen leicht fehlt: Eine Einschränkung darf nicht den einzigen Weg zu ihrer eigenen Korrektur entfernen. Ist das eingeschränkte Konto zugleich das einzige, das die Berechtigungskonfiguration ändern darf, lässt sich ein Fehler in der neuen Regel anschließend nur noch über Konsolenzugang, Wiederherstellung oder Neuaufbau beheben.

Die Konsequenz ist eine Reihenfolge, keine Lockerung. Bevor ein Recht entzogen wird, ist zu klären, welcher Weg es zurückgeben könnte und ob dieser Weg die Einschränkung übersteht. Eine zweite, unabhängige Administrationsidentität mit eigenem Zugang sollte existieren und erprobt sein, bevor die erste eingeschränkt wird. Das BSI formuliert in ORP.4.A20 einen verwandten Gedanken für die Notfallvorsorge: Vorkehrungen zu treffen, um arbeitsfähig zu bleiben, wenn das Berechtigungsmanagement selbst nicht zur Verfügung steht.

Weitreichende Automatisierungskonten sind Tier 0

Konten, über die ausgerollt, konfiguriert oder automatisiert wird, gelten oft als Betriebswerkzeug. Sobald sie weitreichende administrative Rechte auf vielen Systemen besitzen, sind sie mehr als das: Wer sie kontrolliert, kontrolliert die Systeme.

Microsoft beschreibt im Enterprise Access Model, dass die frühere Tier-0-Ebene zur „Control Plane“ erweitert wurde, und verlangt, die Hierarchie durchzusetzen, sodass tiefere Ebenen keine höheren kontrollieren können. Dazu gehört ausdrücklich, fortlaufend nach Konfigurationsschwächen zu suchen, die eine unbeabsichtigte Rechteausweitung ermöglichen. Für Kennungen mit weitreichenden Berechtigungen empfiehlt das BSI Mehr-Faktor-Authentisierung (ORP.4.A10).

Was Sie prüfen sollten

  • Effektive Rechte erheben – für jedes Dienst- und Automatisierungskonto, auf dem System.
  • Zu jeder Positivprüfung eine Negativprobe festlegen, die abgelehnt werden muss.
  • Einschränkungen dort verankern, wo sie durchgesetzt werden.
  • Vor jeder Einschränkung den Reparaturweg herstellen und erproben.
  • Weitreichende Automatisierungskonten wie Tier 0 behandeln: Mehr-Faktor-Schutz, Protokollierung, benannte Verantwortung.

Wie sector7 unterstützt

Wir unterstützen Sie bei Rollen- und Rechtekonzepten, bei der Verwaltung privilegierter Konten, bei Multifaktor-Authentifizierung und bei der Härtung von Betriebssystemen – einschließlich Richtlinien, Dokumentation und Audits. Mehr dazu unter Cyber Security.

Quellen

Sprechen wir über Ihre Situation.

Gespräch vereinbaren+49 212 240915 0