Least Privilege ist kein Werkzeug, sondern eine Entwurfsregel. Ihr Nutzen zeigt sich erst im Schadensfall: Ein kompromittiertes Konto hat genau die Reichweite, die ihm vorher zugestanden wurde. Wo Beschäftigte routinemäßig mit administrativen Rechten arbeiten, entspricht die Reichweite eines Phishing-Klicks der des gesamten Systems.
Least Privilege und Need-to-know
Beide Prinzipien werden häufig gleichgesetzt, betreffen aber unterschiedliche Fragen:
- Need-to-know beschränkt, welche Informationen jemand kennen darf: Der Vertriebsmitarbeiter sieht die Kundendaten seiner Region.
- Least Privilege beschränkt, was jemand tun darf: Er darf sie lesen, aber nicht exportieren oder löschen.
Erst zusammen ergeben sie ein tragfähiges Rechtekonzept. Wer nur Need-to-know umsetzt, erhält Nutzer mit vollständigen Änderungsrechten auf einem eingeschränkten Datenausschnitt.
Warum Rechte wachsen
Der Grundzustand jeder gewachsenen Umgebung ist zu viel Berechtigung, und zwar aus nachvollziehbaren Gründen: Rechte werden für ein Projekt vergeben und nicht zurückgenommen; bei Störungen wird großzügig erweitert, um schnell zu helfen; Rollen werden nach dem Vorbild eines bestehenden Kollegen kopiert; Standardinstallationen bringen weitreichende Vorgaben mit. Dieser Effekt, häufig als Privilege Creep bezeichnet, ist kein Einzelfehler, sondern der Normalzustand ohne Gegenprozess.
Umsetzung in Stufen
| Bereich | Zielzustand | Praktischer Einstieg |
|---|---|---|
| Arbeitsplatz | keine lokalen Administratorrechte im Alltagskonto | Ausnahmen erfassen, befristen und begründen |
| Fachanwendungen | Rollen aus Aufgaben abgeleitet, Lese- und Änderungsrechte getrennt | Rollen mit den Fachbereichen neu schneiden statt fortschreiben |
| Administration | getrennte Administrationskonten, Rechte je System statt global | Zahl der globalen Administratoren erheben und begrenzen |
| Dienste und Schnittstellen | technisches Konto je Dienst, minimaler Rechteumfang, benannter Eigentümer | Bestand inventarisieren, Sammelkonten auflösen |
| Notfallzugang | dokumentiert angefordert, zeitlich begrenzt, nachgelagert ausgewertet | Verfahren festlegen, bevor es gebraucht wird |
Die Reihenfolge ist bewusst gewählt: Der Entzug lokaler Administratorrechte und die Begrenzung globaler Administratoren bringen in kurzer Zeit die größte Wirkung, während der Neuschnitt von Fachrollen die eigentliche Projektarbeit ist.
Zeitliche Begrenzung
Die wirksamste Verschärfung des Prinzips ist nicht weniger, sondern kürzer: Rechte werden erst bei Bedarf, für einen definierten Zeitraum und nach Freigabe erteilt und laufen automatisch ab. Für administrative Tätigkeiten reduziert das die Zahl dauerhaft privilegierter Konten erheblich, ohne die Handlungsfähigkeit einzuschränken. Voraussetzung ist ein Verfahren, das schnell genug ist; andernfalls entstehen Umgehungen.
Grenzen
Least Privilege löst keine organisatorischen Probleme. Drei Grenzen sind einzuplanen:
- Verfügbarkeit. Zu enge Rechte ohne funktionierendes Ausnahmeverfahren führen dazu, dass Zugangsdaten geteilt werden. Das Ergebnis ist schlechter als der Ausgangszustand.
- Aufwand. Feingranulare Rechte müssen gepflegt werden. Der Detailgrad sollte sich am Schutzbedarf der Daten orientieren, nicht am technisch Möglichen.
- Altsysteme. Ältere Anwendungen kennen oft nur wenige Rechtestufen. Dort ist die Beschränkung über vorgelagerte Maßnahmen zu erreichen: Netzsegmentierung, Sitzungsprotokollierung, Vier-Augen-Prinzip.
Prüfung im Audit
Auditoren prüfen das Prinzip selten abstrakt. Üblich sind drei Stichproben: die Zahl der Konten mit weitreichenden administrativen Rechten, ein Vergleich der Rechte einer Person mit ihrer aktuellen Stellenbeschreibung und die Frage, wann eine bestimmte Berechtigung zuletzt tatsächlich genutzt wurde. Die dritte Frage ist die unangenehmste, weil sie ohne Auswertung der Protokolle nicht zu beantworten ist.
Wie Rizzqo das Prinzip prüfbar macht
Least Privilege ist als Grundsatz unstrittig und als Nachweis unbequem, weil er für jedes System einzeln geführt werden muss. In Rizzqo erscheint die zugehörige Anforderung aus ISO/IEC 27002 an den Assets, deren Kategorie sie betrifft, und wird dort vom Verantwortlichen des Systems beantwortet, nicht zentral für alle Systeme gemeinsam.
Die Bewertung gewinnt durch die Verknüpfung nach oben. Ein unterstützendes Asset erbt den Schutzbedarf der primären Werte, die es trägt, auch über mehrere Stufen. Der Administrator eines Zwischensystems sieht damit, dass an seiner Rechtevergabe am Ende ein Prozess mit hoher Vertraulichkeitsanforderung hängt, und kann die Angemessenheit der Rechte an diesem Maßstab beurteilen statt am technischen Gefühl.