Der privilegierte Zugriff auf Anwendungen, Ressourcen und Verwaltungsportale ist ein heikles Thema in vielen Unternehmen. Die erforderlichen Konzepte zur "guten" Administration sind bekannt, erweisen sich in der Umsetzung hinsichtlich der Balance von Risikominimierung und Bedienfreundlichkeit zuweilen aber als schwierig. Wer erweiterte Berechtigungen sein Eigen nennen darf, sollte nicht mit dem zugehörigen Account ebenfalls E-Mails lesen oder im Netz surfen. Wer viele Privilegien besitzt, sollte sie nicht alle auf ein Konto konzentrieren, um im Fall einer Kompromittierung den "Blast Radius" gering zu halten. Einige Unternehmen trennen Admin-Konten auch anhand der Nutzung – Cloud-Admins müssen andere privilegierte Accounts nutzen als On-Premises-Admins.

Die Schutzkonzepte hinter diesen Szenarien sind bekannt: "Just in Time" (JIT) bedeutet, dass der eigentlich privilegierte Account nur durch aktives Freischalten der Privilegien zu einem Admin-Account wird. Das kann entweder durch den Besitzer manuell erfolgen oder lässt sich durch einen Prozess zusätzlich schützen – nämlich wenn ein Vier-Augen-Prinzip die Freigabe durch einen Kollegen erfordert und der Besitzer Multifaktor-Authentifizierung (MFA) ausführt oder den Account nur von einem bestimmten Computer, eine Admin-Workstation, also eine "Privileged Admin Workstation" (PAW) oder "Secure Admin Workstation" (SAW), nutzt. Die Freischaltung ist dann zeitgebunden, sodass der Admin die Privilegien manuell zurückgibt oder sie automatisch entfallen.

Mit "Just Enough Administration" (JEA) erhält ein Account nie alle zugewiesenen Rechte gleichzeitig, sondern muss sie getrennt voneinander freischalten. Ein gleichzeitiges Freischalten der Privilegien wäre zwar möglich, kommt aber selten vor, wenn die wichtigen Rechte systemspezifisch oder tätigkeitsspezifisch aufgeteilt sind. So kann im Fall einer Account-Kompromittierung zwar ein Satz von Privilegien abhandenkommen, für die anderen, potenziell verfügbaren Berechtigungen müsste der Angreifer aber eine separate, erneute Freischaltung durchführen, die dann durch das Vier-Augen-Prinzip, MFA oder zumindest im System hinterlegt und auditiert wird.

Privileged Identity Management (PIM) ist Teil der Premium-Lizenzen von Microsoft [1], weshalb Sie alle privilegierten Admins, die mit dem System in Berührung kommen und arbeiten, eine Lizenz zuweisen müssen. Bei limitierter Lizenzanzahl können Sie zumindest mit den bedeutendsten Rollen beginnen: den Global Admins und Rollen, die die M365-Dienste steuern. PIM geht aber über M365 hinaus und lässt die Verwaltung von Azure durch privilegierte Admins ebenfalls zu, wie auch die Administration von Privilegien, die in Apps außerhalb der Microsoft Cloud vorhanden sind.

Wenn verbundene Apps Privilegien anhand von Gruppenmitgliedschaften oder Rollendefinitionen via Claims nutzen, oder sie Admins per Provisionierung in die App synchronisieren, können Sie die Admin-Zugriffe in PIM verwalten. Das macht PIM für viele Cloudszenarien interessant: Der Fokus muss nicht auf der Microsoft-Cloud liegen, sondern auf AWS oder SaaS-Angeboten, die auch die Google-Cloud oder Alibaba umfassen. Damit PIM aber Privilegien regeln kann, muss Azure AD der Identity Provider für diese Apps sein.

Weisen Sie Ihren Kollegen Rollen in Azure AD zu, konfigurieren Sie die Rollenmitgliedschaft meist für "permanente" Nutzung. Damit PIM JIT und JEA ermöglichen kann, wandeln Sie die permanenten Rollenzuweisungen in "berechtigte" um. Das befähigt Kollegen im Besitz des Accounts, eine Freischaltung zu starten. Sie sehen im Azure-AD-Portal, wer gerade "Global Admin" ist. Als solcher oder "Privileged Role Admin" in Azure AD navigieren Sie zu "Azure Active Directory / Identity Governance / Privileged Identity Management" und wählen "Azure AD Roles" und "Roles". So gelangen Sie zur Rollenübersicht.

Klicken Sie nun auf "Global Administrators" für die Übersicht der Rolleninhaber. Sie sehen drei Tabs: "Eligible-", "Permanent-" und "Expired"-Assignments. Für JIT und JEA sollten Sie möglichst viele Accounts von "Permanent" nach "Eligible" überführen. Für jedes Konto, das als "Permanent" gelistet ist, sehen Sie am Ende der Detailzeile die Aktionen "Remove" und "Update". Remove erntfernt den Account aus der Rolle. Über "Update" öffnen Sie ein Detailmenü, in dem Sie den "Assignment Type" von "Active" nach "Eligible" ("berechtigt", weitere Privilegien zu aktivieren) umstellen und, falls gewünscht, die Rollenzugehörigkeit auch generell zeitlich begrenzen können. Dazu entfernen Sie den Haken aus "Permanently eligible" und tragen das Enddatum ein. Das ist dann äußerst hilfreich, wenn Sie in regelmäßigen Abständen eigene Mitarbeiter oder externe Kollegen hinsichtlich ihrer Berechtigungen überprüfen und eine Neubeantragung der Privilegien anstreben. Mit "Save" machen Sie aus den permanenten Admins berechtigte Admins, die dann in PIM eine Freischaltung beantragen müssen.

Gerade besonders kritische Rollen wie "Global Admins" sollten Sie per PIM verwalten und überwachen. Wenn sämtliche Global Admins – bis auf einen Notfallaccount, dessen Anmeldeinformationen Sie in einem Safe aufbewahren – nur noch "berechtigte" Admins sind, senken Sie das Risiko ungewollter Änderungen signifikant. Das Gleiche gilt für weitere privilegierte Rollen.

Nicht alle Rollen- und Gruppenmitgliedschaften, die privilegierte Aktionen erlauben, sind demselben Risiko ausgesetzt. Einige Rollen bedürfen eines größeren Schutzes vor Risiken als andere, weshalb für den Prozess der Freischaltung sowie die Länge der Freischaltung feinere Einstellungen nötig sind. Wenn Sie sich die Rollenzuweisungen in PIM ansehen, können Sie im Hauptmenü den "Settings"-Knopf für die Detailkonfiguration der Rolle auswählen. Alternativ finden Sie "Settings" im linken Menü in "Privileged Identity Management / Azure AD Roles", das Sie zu einer Rollenübersicht führt, in der Sie auch einsehen können, ob bereits Detailkonfigurationen für eine Rolle vorgenommen wurden oder ob die Voreinstellungen überhaupt noch vorhanden sind.

Die Einstellungen sind sortiert nach "Aktivierung", "Zuweisung" und "Benachrichtigungseinstellungen", wobei Sie die Benachrichtigungen separat für Änderungen, Zuweisungen oder Rückgaben von Privilegien konfigurieren können. Per "Edit" führt Sie PIM durch einen Assistenten, der die drei Kategorien konfiguriert. Zunächst definieren Sie, wie die Freischaltung – oder Aktivierung – aussehen soll: einmal aktiviert, lässt sich die Rolle zwischen 30 Minuten und 24 Stunden nutzen. Natürlich können Admins die Privilegien über das PIM-Portal selbst zurückgeben – vergessen Admins das, verfallen die Privilegien nach Ablauf der Zeit automatisch. Sollten Sie MFA erzwingen wollen, können Sie das ebenfalls definieren. Auch Einstellungen für "business justi­fication" und "ticket information" lassen sich erzwingen: Um nachzuverfolgen, an welchem Ticket oder Change Request die Kollegen arbeiten, wenn sie die Rolle nutzen, speichert PIM die Information im Audit-Log – oder Sie greifen die Daten per API ab. Abschließend bestimmen Sie, ob Genehmigungen von Kollegen oder Vorgesetzten vorgesehen sind oder ob sich die Rolle durch Mitarbeiter selbst aktivieren lässt.

In "Assignment" setzen Sie fest, ob sich Rollen für immer "permanent" oder "berechtigt" zuweisen lassen oder ob Sie die Zuweisungen periodisch erneuern wollen und damit zeitlich beschränken. Die Maximaleinstellung ist ein Jahr. Zudem können Sie MFA für permanent zugewiesene Admins erzwingen, und falls Kollegen anderen doch permanente Rechte zuweisen, nach der "business justification" fragen.

Mitarbeiter, die eine privilegierte Rolle nutzen und aktivieren möchten, können dies über das Azure-AD-Portal erledigen: Sie navigieren zu "portal.azure.com" und nach erfolgreicher Authentifizierung zu "Azure AD Privileged Identity Management". In der Übersichtsseite geht es direkt über den "Active"-Knopf an die richtige Stelle, alternativ im linken Menü "My Roles". Das Portal zeigt die Liste aller Assignments an – berechtigte wie auch aktive permanente Rollen. In "eligible assignments" starten Sie über "Activate" den Prozess, der Sie zunächst nach Ticketsystem, Ticketnummer und einer Begründung fragt, danach die Genehmigung durch einen Vorgesetzten oder Kollegen anstößt und – nach Genehmigung – MFA für die Aktivierung einfordert; das Ganze hängt natürlich von den rollenspezifischen Einstellungen ab.

Für Subscriptions und Management Groups in Azure können Sie den Zugang zu Rollen wie "Contributor" oder "Automation Operator" in PIM verwalten lassen. Bevor sich die Rolle dann in Azure nutzen lässt, muss eine Aktivierung erfolgen. Gerade bei kritischer Infrastruktur, die auf VMs läuft, oder bei Projekten, die Sie Kunden zur Verfügung stellen, kann das ein Risiko durch Änderungen einschränken. Bevor es losgeht, müssen Sie die Management Group oder Subscrip-tion in PIM integrieren – hierzu müssen Sie Admin jener Azure-Ressource sein und gleichzeitig mit demselben Account, Global Admin oder Privileged Role Admin (PRA) sein, um das Onboarding in beiden Welten, Azure und PIM, vollständig abzuschließen. Andernfalls scheitert das "Discovery". Unter "Azure resources" sehen Sie den Schalter "Discover resources", wonach PIM mit Ihrem gerade angemeldeten Admin-Konto auf die Suche in Azure geht und Subscriptions sowie MGs findet. Aus der Liste der gefundenen Ressourcen wählen Sie die Subscriptions und MGs aus, die Sie mit PIM schützen wollen, und klicken auf "Manage resources", was Sie anschließend bestätigen. Sie sollten die Subscription jetzt in PIM unter "Azure resources" sehen können.

Per Klick darauf gewinnen Sie wieder den Überblick über die verfügbaren Rollen samt deren voreingestellten Berechtigungen und erhalten die Möglichkeit, neue Mitglieder zu Rollen hinzuzufügen – wieder "berechtigt" oder "permanent" – sowie rollenspezifische Einstellungen zur Aktivierung und Benachrichtigungen vorzunehmen. Die Detaileinstellungen unter "Settings" speichert PIM dabei pro Ressource für Azure, sodass Sie jede Subscription oder Management Group mit eigenen Einstellungen versehen können, damit "Contributors" in einer Subscription etwas strenger aktiviert werden müssen als in einer Test-Subscription.

Um PIM auch für andere privilegierte Rollen in anderen Anwendungen fit zu machen, können Sie das Konzept "Privileged Access Groups" nutzen. So wie PIM die Aktivierung von Rollenmitgliedschaften schützen und mit MFA und einem Vier-Augen-Prinzip versehen kann, erreichen Sie das Gleiche mit Gruppenmitgliedschaften: Bevor ein Mitarbeiter Mitglied einer "privileged access group" werden kann, muss die PIM-Aktivierung klappen. Die Gruppe, deren Mitgliedschaft Sie mit PIM steuern, nutzen Sie dann in der Zielanwendung für privilegierten Zugriff. Die Gruppe mit der durch PIM gesteuerten Gruppenmitgliedschaft übergeben Sie in einer von zwei Arten an die Anwendung: entweder durch Identity Provisioning nach dem SCIM-Standard oder per Claims im SAML- oder OpenIDConnect-Token. In unserem Beispiel konfigurieren wir das für eine AAD-Gruppe "APPS_SALESFORCE_ADMINS", die einige "berechtigte", aber keine permanenten Mitglieder haben soll. Sobald jemand Mitglied der Gruppe wird, erhält der Benutzer automatisch "System Administrator"-Berechtigungen in einer Salesforce-Instanz, die per SSO an das AAD angebunden ist.

In der PIM-Übersicht wählen Sie im linken Menü "Privileged access groups" und anschließend "Discover groups" mit dem Lupensymbol. Über die Suche finden Sie die Gruppe, die Admin-Berechtigungen in der SaaS-Anwendung steuert: "APPS_ SALESFORCE_ADMINS". Per "Manage groups"-Knopf führen Sie das Einbinden der Gruppe in PIM aus. Danach können Sie sowohl Gruppenmitgliedschaften als auch Besitzverhältnisse in PIM für permanente und berechtigte Mitarbeiter steuern. Besitzt die Gruppe bereits einen Owner und Mitglieder, werden diese übernommen und als aktive, permanente Mitglieder oder Besitzer geführt. Klicken Sie nun auf "Member", wonach Sie die Oberfläche zur Konfiguration für "Eligible" und "Active"-Zuweisungen sehen. Alle Salesforce-Admins, die nur noch über Aktivierung zum Admin werden dürfen, müssen Sie in "Eligible assignments" hinzufügen. Verfügen einige der Benutzer schon über eine aktive Mitgliedschaft, finden Sie diese in "Active assignments" und können sie in der rechten Spalte über die "Update"-Funktion ändern, indem Sie den "Assignment type" von "Active" auf "Eligible" umstellen.

Haben Sie die SaaS-Anwendung schon für die Gruppennutzung konfiguriert, sind Sie hiermit fertig. Konfigurieren Sie die App gerade neu, müssen Sie die Gruppe "APPS_SALESFORCE_ADMINS" nun noch hinzufügen: Wechseln Sie zu "Enterprise Applications" und suchen Sie die Salesforce-App. In der App gehen Sie zu "Users and groups" und fügen mit "+ Add user/group" ein neues Assignment hinzu. In "Users and groups" wählen Sie die PIM-aktivierte Gruppe aus, in "Select a role" definieren Sie, welche Rolle die aktivierten Mitglieder der Gruppe erhalten sollen. Azure AD sollte alle definierten Rolle aus Salesforce anzeigen und Sie auswählen lassen. Nach "Assign" ist die PIM-verwaltete Gruppe nun mit der privilegierten Rolle der SaaS-App verknüpft. Azure AD fügt nun, wenn SSO zur App stattfindet, die Gruppenmitgliedschaft nach Aktivierung in PIM hinzu. Falls die App die automatische Provisionierung von Gruppen unterstützt, wird nach der PIM-Aktivierung die geänderte Mitgliedschaft automatisch übertragen.

Gibt es Änderungen in der Konfiguration von PIM oder werden Rollen aktiviert oder wieder zurückgegeben, finden sich die Details dazu im Auditlog. Das Log ist für Admins lesbar. Wenn Sie für Audit- und Compliance-Zwecke die Daten auswerten müssen, lässt sich das Log exportieren [2]. Sie können die Daten filtern und in CSV exportieren oder über die Exportmöglichkeiten ihrem SIEM-Tool oder Logging-Infrastruktur zur Verfügung stellen. Ohne Export sind die Einträge nur 30 Tage gültig – sollten Sie Aktivierungen und Rollennutzung länger verfolgen wollen, müssen Sie die Daten wegspeichern.

Wünschen Sie eine fokussierte Ansicht der Ereignisse, navigieren Sie in PIM nach "Azure AD roles" oder "Azure Roles / My Audit". Möchten Sie zusätzliche Alerts neben dem normalen Auditing konfigurieren, können Sie sich über verwaiste Accounts in privilegierten Rollen, Zuweisungen von Rollen außerhalb von PIM und weitere kritische Events informieren lassen [3].

In der gleichen Lizenz, mit der Sie PIM nutzen, sind weitere Funktionen für Berechtigungs- und Zugangsverwaltung enthalten. Eines der Feature ist "Access Reviews", mit dem Sie neben Mitgliedschaft in Gruppen oder Zuweisung von Anwendungen auch privilegierte Rollenzuweisungen von Reviewern überprüfen lassen können. Selbst wenn Sie einigen Kollegen "Global Administrator" oder "Exchange Service Administrator" als berechtigte Rollen zugewiesen haben, können Sie diese regelmäßig durch Abteilungsleiter, die IT-Security oder die Benutzer selbst bestätigen lassen.

Der Reviewer lässt sich dann etwa halbjährlich dazu auffordern, zu überprüfen, ob die Inhaber der privilegierten Rollen diese auch weiterhin zugewiesen haben sollen. Nur wenn das Review positiv ausfällt, dürfen Sie die Rolle behalten. Andernfalls kann Access Reviews die Rollenzuweisung automatisch entfernen. Das komplementiert den automatischen Ablauf einer Rolle in PIM – selbst wenn der automatische Ablauf nach zwei Jahren konfiguriert ist, ist der Rolleninhaber im Drei- oder Sechsmonatstakt überprüfbar.

PIM in Azure AD liefert JIT- und JEA-Funktionen für die Microsoft-Cloud. Wer Anwendungen mit SSO in Azure AD integriert, kann diesen Anwendungen privilegierte Berechtigungen über Rollen und Gruppenmitgliedschaften zur Verfügung stellen. Auch in SaaS-Anwendungen und Clouds außerhalb von Azure gibt es privilegierte Rollen, deren Risiko verwaltet werden muss.