Privilegierter Zugriff als Strategie

Stehende Rechte sind das Problem, nicht die Rechte selbst

Im ersten Modul stand die Regel: die kleinste passende Rolle für eine benannte Aufgabe. Sie beantwortet die Frage nach dem Umfang. Dieses Modul beantwortet die zweite Frage — die nach der Dauer. Denn ein Recht, das jemand einmal im Quartal braucht und dauerhaft besitzt, ist 89 Tage lang nur ein Ziel.

Stehendes Privileg — Eine dauerhaft aktive Rechtezuweisung, unabhängig davon, ob sie gerade gebraucht wird. Sie ist der Normalzustand in jedem Tenant, in dem niemand die Dauer als eigene Größe behandelt hat.

Berechtigt statt zugewiesen — und was das nicht ändert

Der Kern der Privileged Identity Management ist eine einfache Unterscheidung. Eine aktive Zuweisung wirkt sofort und dauerhaft. Eine berechtigte Zuweisung wirkt erst, wenn die Person sie ausdrücklich aktiviert — und läuft danach von selbst wieder ab.

Was dabei gern übersehen wird, sagt die Dokumentation ungewöhnlich deutlich: Es gibt keinen Unterschied im Zugriff zwischen einer dauerhaften und einer berechtigten Zuweisung. Der einzige Unterschied ist, dass manche Menschen diesen Zugriff nicht die ganze Zeit brauchen.

Diese Reihenfolge ist wichtig, weil PIM verführerisch ist: Eine Aktivierung fühlt sich nach Kontrolle an, und ein Genehmigungsschritt sieht in einem Bericht gut aus. Beides ändert nichts daran, was die Rolle kann, sobald sie aktiv ist.

Die Begriffe, die in jeder Oberfläche auftauchen

Drei Wortpaare werden ständig durcheinandergebracht, weil sie verschiedene Dinge beschreiben — Art, Zustand und Dauer einer Zuweisung.

Art: berechtigt oder aktiv

Berechtigt heißt, die Person kann die Rolle aktivieren. Aktiv heißt, sie wirkt bereits.

Zustand: zugewiesen oder aktiviert

Aktiviert ist, wer eine berechtigte Zuweisung hat und die nötigen Schritte durchgeführt hat.

Dauer: dauerhaft oder befristet

Beide Arten gibt es in beiden Dauern — auch eine berechtigte Zuweisung kann dauerhaft bestehen oder ein Enddatum tragen.

Aus der Kombination ergeben sich vier Fälle, und der lehrreichste ist dauerhaft berechtigt: Die Person darf die Rolle jederzeit aktivieren, unbefristet. Das ist der übliche Zustand nach einer PIM-Einführung — und er ist deutlich besser als eine dauerhaft aktive Zuweisung, aber eben nicht das Ende der Arbeit.

Der Unterschied zwischen den vier Fällen wird an einer Frage greifbar: Was passiert, wenn drei Monate lang niemand hinsieht? Bei dauerhaft aktiv bleibt die volle Rechtelage bestehen. Bei dauerhaft berechtigt ist niemand privilegiert, solange niemand aktiviert — die Möglichkeit bleibt aber unbegrenzt. Bei befristet berechtigt endet auch die Möglichkeit. Nur der letzte Fall überlebt drei Monate Unaufmerksamkeit ohne Rückstand.

Was bei der Aktivierung verlangt werden kann

Die Aktivierung ist der Moment, in dem sich Bedingungen stellen lassen. Die Dokumentation nennt die verfügbaren Hebel:

• Eine mehrstufige Authentifizierung bei der Aktivierung.
• Eine Begründung, damit später nachvollziehbar ist, wofür aktiviert wurde.
• Eine Genehmigung durch benannte Personen.
• Eine Höchstdauer der Aktivierung — einstellbar von einer bis 24 Stunden.
• Benachrichtigungen, wenn eine privilegierte Rolle aktiviert wird.

Die Höchstdauer ist die unterschätzte Einstellung. Acht Stunden bedeuten, dass eine morgens für einen Handgriff aktivierte Rolle den ganzen Arbeitstag aktiv bleibt — inklusive Mittagspause und dem Zeitraum, in dem das Notebook unbeaufsichtigt ist. Eine Stunde reicht für die meisten Aufgaben und erzwingt eine zweite Aktivierung für den Rest, was genau der Punkt ist.

Verwaltet werden diese Einstellungen mit mindestens der Rolle Privileged Role Administrator; in der Dokumentation heißen sie auch PIM-Richtlinien. Dass sie je Rolle gelten, hat eine praktische Folge für die Einführung: Man kann mit einer einzigen besonders kritischen Rolle streng beginnen — etwa Global Administrator — und die übrigen zunächst milder einstellen, statt den ganzen Bestand auf einmal umzustellen.

Umgekehrt heißt es, dass eine Rolle wie Helpdesk Administrator, die viele Personen tragen, für alle dieselbe Höchstdauer und dieselbe Genehmigungspflicht bekommt. Wer für eine kleine Gruppe strengere Bedingungen braucht, muss den Unterschied über eine andere Rolle oder über den Geltungsbereich abbilden — nicht über die Einstellung.

Die Falle bei der mehrstufigen Authentifizierung

Hier steht ein Satz, der die naheliegendste Einstellung entwertet. Verlangt man bei der Aktivierung eine mehrstufige Authentifizierung, so werden Personen laut Dokumentation möglicherweise nicht dazu aufgefordert, wenn sie sich mit starken Anmeldeinformationen angemeldet oder die Prüfung bereits früher in der Sitzung erbracht haben.

Das heißt: Wer sich morgens mit einem Sicherheitsschlüssel angemeldet hat, aktiviert nachmittags eine privilegierte Rolle unter Umständen ohne jede weitere Interaktion. Die Einstellung ist gesetzt, der Bericht sieht gut aus, und die zusätzliche Bestätigung hat nie stattgefunden.

Die Dokumentation nennt auch den Ausweg. Soll die Prüfung bei der Aktivierung stattfinden, braucht es den Authentifizierungskontext einer Zugriffsregel zusammen mit einer Anmeldestärke — dann verlangt die Aktivierung ein anderes Verfahren als das, mit dem die Person sich angemeldet hat. Wer sich mit Windows Hello for Business anmeldet, muss zur Aktivierung etwa eine kennwortlose Anmeldung mit dem Authenticator durchführen.

Was die betroffene Person dabei sieht, ist übrigens dokumentiert und hilft im Servicedesk: Bei einer Aktivierung mit Authentifizierungskontext erscheint der Hinweis, dass eine Zugriffsrichtlinie aktiv ist und zusätzliche Überprüfung verlangen kann, woraufhin die Person zur erneuten Anmeldung geführt wird. Wer diese Meldung kennt, erkennt sofort, ob der Kontext greift oder ob die Aktivierung still durchgelaufen ist.

Die Regel, die man nicht bauen darf

Beim Einrichten des Authentifizierungskontexts gibt es einen Fehler, der sich logisch erklärt und trotzdem regelmäßig gemacht wird.

Eine Zugriffsregel darf nicht gleichzeitig auf den Authentifizierungskontext und auf die Verzeichnisrolle zielen. Der Grund steht in der Dokumentation: Während der Aktivierung hat die Person die Rolle noch nicht — eine Regel, die auf die Rolle zielt, greift in diesem Moment also gar nicht.

Der Umfang der Regel muss deshalb die Personen erfassen, die für die Rolle berechtigt sind, oder schlicht alle. Wer stattdessen die Rolle als Bedingung setzt, baut eine Regel, die genau dann nicht wirkt, wenn sie wirken soll — und merkt es nicht, weil die Aktivierung ja gelingt.

Wer die Zugriffsregeln verwaltet, entscheidet über die Aktivierung

Aus der Kopplung von PIM an Zugriffsregeln folgt eine Machtverschiebung, die die Dokumentation ausdrücklich benennt.

Sind die Aktivierungsbedingungen über einen Authentifizierungskontext definiert, so bestimmen die Zugriffsregeln, was jemand erfüllen muss. Damit können Sicherheitsprinzipale, die diese Regeln verwalten dürfen — etwa Conditional Access Administrator oder Security Administrator —, die Anforderungen ändern, entfernen oder berechtigte Personen an der Aktivierung hindern.

Die Schlussfolgerung der Dokumentation ist eindeutig: Wer Zugriffsregeln verwalten darf, ist als hoch privilegiert zu betrachten und entsprechend zu schützen. Das ist dieselbe Denkfigur wie bei den rollenfähigen Gruppen aus dem Modul zu Gruppen — dort konnte, wer Mitgliedschaftsregeln ändern durfte, sich indirekt eine Rolle verschaffen.

Praktisch heißt das, dass die Liste der besonders schützenswerten Rollen länger ist als die Liste der offensichtlich mächtigen. Neben Global Administrator und Privileged Role Administrator gehören Conditional Access Administrator und Security Administrator dazu — nicht weil sie selbst auf Daten zugreifen, sondern weil sie die Bedingungen bestimmen, unter denen andere es dürfen.

Nach der Aktivierung endet die Kontrolle

Die letzte und unangenehmste Einschränkung betrifft den Zeitraum nach der Aktivierung. Die Bedingungen des Authentifizierungskontexts gelten für den Aktivierungsvorgang — danach nicht mehr.

Die Dokumentation führt das Beispiel selbst aus: Jemand aktiviert die Rolle von einem konformen Gerät aus, meldet sich anschließend mit demselben Konto von einem nicht konformen Gerät an und nutzt die bereits aktivierte Rolle von dort. Die Aktivierungsbedingung ist erfüllt worden, die Nutzung findet woanders statt.

Der Ausweg sind zwei Regeln statt einer: die erste auf den Authentifizierungskontext für die Aktivierung, die zweite auf die Rolle selbst für die Nutzung danach. Erst zusammen decken sie beide Zeitpunkte ab.

Zuschnitt bleibt die erste Frage

Weil die Aktivierung die Reichweite nicht ändert, bleibt der Rollenzuschnitt aus dem ersten Modul die wichtigere Entscheidung. Zwei Hebel stehen dafür bereit, und beide sind schon bekannt.

• Die kleinste passende Rolle unter über 65 eingebauten statt der Rolle, die immer passt.
• Der Geltungsbereich über eine Verwaltungseinheit oder eine einzelne Ressource statt tenantweit.
• Rollenfähige Gruppen als Träger, damit Zu- und Abgänge die Rechtevergabe nicht berühren.
• Wiederkehrende Überprüfungen der privilegierten Zuweisungen aus dem vorigen Modul.

Zusammen ergibt das eine Reihenfolge: Erst so klein wie möglich zuschneiden, dann den Geltungsbereich setzen, dann die Dauer begrenzen. Wer mit der Dauer anfängt, hat eine unbefristet zu große Rolle in eine befristet zu große verwandelt.

Was PIM im Notfall nicht leisten darf

Aus dem ersten Modul stammt die Empfehlung zweier reiner Cloud-Konten mit dauerhafter Zuweisung der höchsten Rolle. Das ist ein bewusster Widerspruch zu allem, was dieses Modul lehrt — und er ist richtig.

Ein Notfallzugang darf nicht von einer Aktivierung abhängen, denn die Aktivierung ist ein Vorgang, der scheitern kann: Sie braucht eine funktionierende Prüfung, unter Umständen eine Genehmigung durch eine erreichbare Person und eine Zugriffsregel, die nicht gerade der Grund für den Notfall ist.

Durchgerechnet: eine privilegierte Rolle bedarfsgesteuert machen

Der Preis ist Aufwand an einer Stelle, die vorher keinen brauchte: Zwei Zugriffsregeln, ein Authentifizierungskontext und eine Rolleneinstellung müssen zusammenpassen, und ein Fehler in einem der vier Teile führt entweder dazu, dass die Prüfung ausbleibt, oder dazu, dass niemand mehr aktivieren kann. Für den zweiten Fall gibt es die Notfallkonten — deshalb gehören sie in denselben Arbeitsschritt und nicht auf eine spätere Liste.

Die Reihenfolge, die alles zusammenhält

Privileged Identity Management löst ein echtes Problem und wird regelmäßig für die Lösung eines anderen gehalten. Es begrenzt, wie lange jemand etwas kann — nicht, was er kann, nicht, von wo, und nicht, was nach der Aktivierung geschieht. Für diese drei Fragen gibt es andere Werkzeuge, und sie stehen in den vorigen Modulen.