Entra ID Governance: PIM, Access Reviews und Entitlement Management

Warum “Global Admin dauerhaft aktiv” ein Sicherheitsproblem ist

In den meisten KMU-Tenants siehst du im Entra Admin Center unter “Rollen und Administratoren” eine lange Liste von Benutzern mit dauerhaft aktiver Rolle Globaler Administrator. Das ist bequem, aber genau das, was ein Angreifer sich wünscht: Ein einziges kompromittiertes Konto mit permanenten Admin-Rechten reicht, um den gesamten Tenant zu übernehmen. Phishing-Kampagnen zielen gezielt auf Konten, die “immer Admin” sind, weil der Aufwand-Nutzen-Faktor für Angreifer maximal ist.

Microsoft Entra ID Governance löst dieses Problem mit einem Bündel aus fünf Funktionen, die zusammen ein durchgängiges Identity-Governance-Modell ergeben:

• Privileged Identity Management (PIM) - zeitlich begrenzte, genehmigungspflichtige Admin-Aktivierung statt Dauerzugriff
• Access Reviews - periodische Rezertifizierung von Rollen, Gruppen und App-Zugriffen
• Entitlement Management (Access Packages) - Self-Service-Zugriffsanfragen mit Genehmigungs-Workflow und automatischem Ablauf
• Lifecycle Workflows - automatisierte Provisionierung/Deprovisionierung bei Eintritt, Wechsel und Austritt
• Identity Protection - risikobasierte Zugriffsrichtlinien, die verdächtige Anmeldungen und kompromittierte Konten automatisch blockieren

Dieser Artikel geht davon aus, dass du bereits Entra ID Grundlagen kennst und produktiv mit Rollen, Gruppen und Conditional Access arbeitest.

Privileged Identity Management (PIM) im Detail

Das Grundprinzip: eligible statt active

PIM unterscheidet zwei Zuweisungstypen für Rollen (Entra-Rollen, Azure-RBAC-Rollen und PIM für Gruppen):

• Active (aktiv): Die Rolle wirkt sofort, dauerhaft oder zeitlich befristet - wie eine klassische Rollenzuweisung.
• Eligible (berechtigt): Der Benutzer kann die Rolle aktivieren, hat sie aber im Ruhezustand nicht. Erst durch eine explizite Aktivierung (mit MFA, Begründung, ggf. Genehmigung) wird die Rolle für eine begrenzte Zeit aktiv.

Der Kerngedanke: Niemand braucht Globaler Administrator 24/7. Ein Helpdesk-Mitarbeiter, der einmal pro Woche ein Passwort zurücksetzen muss, aktiviert die Rolle Password Administrator für 1-2 Stunden und sie fällt danach automatisch wieder auf “eligible” zurück.

Rollen konfigurieren

Im Entra Admin Center unter Identity Governance > Privileged Identity Management > Microsoft Entra roles legst du für jede Rolle eine eigene Aktivierungsrichtlinie fest:

Aktivierung in der Praxis

Ein berechtigter Benutzer aktiviert seine Rolle im Entra-Portal unter My roles oder per PowerShell:

# Microsoft Graph PowerShell SDK verbinden
Connect-MgGraph -Scopes "RoleAssignmentSchedule.ReadWrite.Directory","RoleEligibilitySchedule.ReadWrite.Directory"

# Eigene UPN und Rollen-ID ermitteln
$principalId = (Get-MgUser -UserId "s.weber@contoso.ch").Id
$roleDefinitionId = (Get-MgRoleManagementDirectoryRoleDefinition -Filter "DisplayName eq 'User Administrator'").Id

# Aktivierung anfordern (Self-Activation)
$params = @{
    Action           = "SelfActivate"
    PrincipalId      = $principalId
    RoleDefinitionId = $roleDefinitionId
    DirectoryScopeId = "/"
    Justification    = "Passwort-Reset fuer Ticket #4821"
    ScheduleInfo     = @{
        StartDateTime = Get-Date
        Expiration    = @{
            Type     = "AfterDuration"
            Duration = "PT4H"
        }
    }
}

New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter $params

Für Genehmiger, die eine Aktivierungsanfrage bearbeiten:

# Offene Genehmigungsanfragen abrufen
Get-MgRoleManagementDirectoryRoleAssignmentScheduleRequest `
  -Filter "status eq 'PendingApproval'"

# Anfrage genehmigen (ueber die Approvals-API)
$approvalId = "<id-aus-obiger-abfrage>"
Invoke-MgGraphRequest -Method POST `
  -Uri "https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignmentApprovals/$approvalId/steps/1/approve" `
  -Body (@{ justification = "Genehmigt, Ticket geprueft" } | ConvertTo-Json)

PIM für Gruppen

Seit einiger Zeit lässt sich PIM nicht nur auf Entra-/Azure-Rollen anwenden, sondern auch auf Microsoft 365- und Security-Gruppen selbst (“PIM for Groups”). Das ist besonders praktisch, wenn eine Gruppe Zugriff auf eine kritische Applikation oder ein SharePoint-Standort mit Owner-Rechten steuert - Mitglieder werden dann nur zeitlich begrenzt Mitglied statt dauerhaft.

# PIM-faehige Gruppe abrufen und eligible Mitgliedschaft anfordern
$groupId = "3f1e2a4b-5678-4c9d-a012-abcdef123456"
$params = @{
    AccessId      = "member"
    PrincipalId   = $principalId
    GroupId       = $groupId
    Action        = "AdminAssign"
    Justification = "Projektzugriff Q3, befristet"
    ScheduleInfo  = @{
        StartDateTime = Get-Date
        Expiration    = @{ Type = "AfterDuration"; Duration = "P30D" }
    }
}
New-MgIdentityGovernancePrivilegedAccessGroupEligibilityScheduleRequest -BodyParameter $params

Access Reviews: Rezertifizierung statt “einmal vergeben, für immer da”

Das grösste Sicherheitsrisiko in gewachsenen Tenants ist nicht die initiale Rechtevergabe, sondern das Nicht-Entziehen von Rechten, die nicht mehr gebraucht werden. Ein Mitarbeiter wechselt die Abteilung, die alte Gruppenmitgliedschaft bleibt bestehen. Ein externer Berater bekommt Gastzugriff für ein Projekt, das Projekt endet, der Zugriff bleibt.

Access Reviews automatisieren die periodische Überprüfung:

• Gruppenmitgliedschaften (M365- und Security-Gruppen, auch dynamische Gruppen als Referenz)
• Zuweisungen zu Enterprise Applications
• PIM-Rollenzuweisungen (eligible und active, für Entra-Rollen und Azure-Ressourcen-Rollen)
• Zugriffspakete in Entitlement Management
• Gastbenutzer-Zugriff tenant-weit

Eine Review anlegen

Im Entra Admin Center unter Identity Governance > Access Reviews > New access review:

1. Umfang wählen: Gruppe, Anwendung oder PIM-Rolle
2. Reviewer festlegen: Gruppenbesitzer, Manager der Benutzer, bestimmte Personen oder Self-Review (“Bestätige deinen eigenen Zugriff”)
3. Wiederholung: einmalig oder periodisch (monatlich, quartalsweise, halbjährlich, jährlich)
4. Verhalten bei Nicht-Reaktion: Zugriff automatisch entziehen oder behalten
5. Auto-Apply der Ergebnisse aktivieren, damit kein manueller Klick zur Umsetzung nötig ist

# Access Review per Graph PowerShell anlegen (vereinfachtes Beispiel)
$params = @{
    DisplayName = "Quartalsreview Vertrieb-Gruppe"
    DescriptionForAdmins = "Rezertifizierung Mitgliedschaft Vertrieb-SharePoint"
    Scope = @{
        "@odata.type" = "#microsoft.graph.accessReviewQueryScope"
        Query = "/groups/8a1c2b3d-4e5f-6789-abcd-ef0123456789/transitiveMembers"
        QueryType = "MicrosoftGraph"
    }
    Reviewers = @(
        @{ Query = "/groups/8a1c2b3d-4e5f-6789-abcd-ef0123456789/owners"; QueryType = "MicrosoftGraph" }
    )
    Settings = @{
        RecurrenceType = "quarterly"
        AutoApplyDecisionsEnabled = $true
        DefaultDecisionEnabled = $true
        DefaultDecision = "Deny"
        InstanceDurationInDays = 14
    }
}
New-MgIdentityGovernanceAccessReviewDefinition -BodyParameter $params

Review-Frequenz nach Risikoklasse

Entitlement Management: Self-Service statt Ticket-Pingpong

Ohne Entitlement Management läuft Zugriffsvergabe im KMU meist so: Mitarbeiter schreibt Mail an IT, IT prüft (oder auch nicht), IT vergibt Zugriff manuell, niemand entzieht ihn wieder. Entitlement Management strukturiert diesen Prozess über Access Packages (Zugriffspakete).

Aufbau eines Zugriffspakets

Ein Access Package bündelt eine oder mehrere Ressourcen (Gruppen, Teams, Enterprise Apps, SharePoint-Sites) zu einer beantragbaren Einheit, zum Beispiel “Onboarding Projektteam Nord” mit Zugriff auf eine Teams-Gruppe, eine SharePoint-Bibliothek und eine CRM-Applikationsrolle.

Schritt-für-Schritt-Ablauf:

1. Catalog anlegen (Container für zusammengehörige Ressourcen und Pakete, z.B. “Vertrieb”)
2. Ressourcen zum Catalog hinzufügen (Gruppen, Apps, SharePoint-Sites)
3. Access Package erstellen und Ressourcenrollen zuweisen (z.B. “Mitglied” der Gruppe, “Leser” der SharePoint-Site)
4. Policy definieren: Wer darf anfragen? (alle Mitarbeiter, nur bestimmte Abteilung, auch externe Partner via Connected Organizations)
5. Genehmigungsworkflow konfigurieren (ein- oder mehrstufig, mit Eskalation bei Timeout)
6. Ablaufdatum/Expiration festlegen: fixes Datum, Anzahl Tage nach Zuweisung, oder an Access Review gekoppelt

# Access Package Catalog anlegen
$catalog = New-MgEntitlementManagementCatalog -BodyParameter @{
    DisplayName = "Vertrieb-Ressourcen"
    Description = "Gruppen und Apps fuer Vertriebsteam"
    IsExternallyVisible = $false
}

# Access Package im Catalog erstellen
$package = New-MgEntitlementManagementAccessPackage -BodyParameter @{
    DisplayName = "Onboarding Vertrieb Aussendienst"
    Description = "CRM-Zugriff, Teams, SharePoint fuer neue Aussendienstmitarbeiter"
    CatalogId   = $catalog.Id
}

Vergleich: PIM vs. Entitlement Management vs. Access Reviews

Diese drei Bausteine werden oft verwechselt, lösen aber unterschiedliche Probleme:

Lifecycle Workflows: Automatisierung entlang des Mitarbeiterlebenszyklus

Lifecycle Workflows automatisieren die klassischen HR-getriggerten Prozesse, die sonst manuell und fehleranfällig ablaufen: Eintritt, interne Versetzung, Austritt. Die Workflows reagieren auf Attribute im Entra-Benutzerobjekt (typischerweise synchronisiert aus einem HR-System via Entra ID Governance HR-Connectoren oder direkt gepflegt).

Vier vorgefertigte Workflow-Kategorien stehen als Templates bereit:

• Pre-hire: Konto vor dem ersten Arbeitstag anlegen, Lizenzen zuweisen, Willkommensmail versenden
• Post-hire / New hire: Zugriffspakete zuweisen, Gruppen ergänzen, Manager benachrichtigen
• Pre-offboarding: X Tage vor Austrittsdatum Zugriffe einschränken, Manager-Zugriff auf OneDrive vorbereiten
• Post-offboarding: Konto deaktivieren, aus allen Gruppen entfernen, Lizenzen entziehen, Konto nach Aufbewahrungsfrist löschen

# Beispiel: On-demand Ausführung eines Offboarding-Workflows für einen Benutzer
Connect-MgGraph -Scopes "LifecycleWorkflows.ReadWrite.All"

$workflowId = "b1c2d3e4-f5a6-7890-bcde-f01234567890"
$userId = (Get-MgUser -UserId "m.muster@contoso.ch").Id

$params = @{
    Subjects = @(
        @{ Id = $userId }
    )
}
Invoke-MgActivateIdentityGovernanceLifecycleWorkflow -WorkflowId $workflowId -BodyParameter $params

Typische Trigger-Bedingung für einen Austritts-Workflow (in der Workflow-Definition als Kondition hinterlegt):

trigger:
  type: timeBased
  timeBasedAttribute: employeeLeaveDateTime
  offsetInDays: -1     # einen Tag vor Austrittsdatum ausloesen
executionConditions:
  scope:
    rule: "department eq 'Vertrieb'"
tasks:
  - name: "Alle Gruppenmitgliedschaften entfernen"
    taskDefinitionId: "1953a66c-751c-45e5-8bfe-01462c70da3c"
  - name: "Benutzerkonto deaktivieren"
    taskDefinitionId: "1dfdfcc7-52fa-4c2e-9d61-c8f9e9b5a3af"
  - name: "Manager per Mail benachrichtigen"
    taskDefinitionId: "aab41899-9972-422a-9d97-6dd0f9dde217"

Für den Vergleich zu klassischem, manuellem Onboarding/Offboarding lohnt sich ein Blick auf IT-Onboarding und -Offboarding als Ergänzung - Lifecycle Workflows automatisiert genau die Schritte, die dort als Checkliste beschrieben sind.

Identity Protection: Risikobasierte Zugriffsrichtlinien

Identity Protection wertet Signale aus Milliarden von Anmeldungen im Microsoft-Ökosystem aus (Threat Intelligence, ungewöhnliche Reisemuster, Leaked Credentials, Anomalie-Erkennung) und berechnet daraus zwei Risikowerte:

• Sign-in Risk: Wie wahrscheinlich ist es, dass diese konkrete Anmeldung nicht vom rechtmässigen Kontoinhaber stammt? (z.B. Anmeldung aus anonymisiertem IP-Bereich, unmögliche Reisegeschwindigkeit zwischen zwei Anmeldungen)
• User Risk: Wie wahrscheinlich ist es, dass das Konto insgesamt kompromittiert ist? (z.B. Zugangsdaten in einem bekannten Leak aufgetaucht, wiederholt riskante Anmeldungen)

Risikobasierte Conditional-Access-Richtlinie einrichten

Praxisbeispiel für ein KMU: Bei erkanntem Sign-in-Risiko “Medium” oder höher wird MFA zusätzlich erzwungen, bei User-Risiko “High” wird ein Passwort-Reset erzwungen und die Sitzung beendet.

Ablauf im Entra Admin Center unter Protection > Conditional Access > Policies > New policy:

1. Zuweisung: alle Benutzer, Ausnahme für Notfall-Zugangskonten (Break-Glass)
2. Bedingungen > User risk: Stufe “High” auswählen
3. Bedingungen > Sign-in risk: Stufe “Medium and above” auswählen
4. Zugriffssteuerung: “Require password change” (bei User Risk) bzw. “Require multifactor authentication” (bei Sign-in Risk)
5. Sitzungssteuerung: “Sign-in frequency” auf jede Anmeldung setzen für maximale Wirksamkeit
6. Erst im Report-only-Modus 1-2 Wochen laufen lassen, Auswirkungen im Log auswerten, dann auf “On” umstellen

// Sign-ins mit erhoehtem Risiko der letzten 7 Tage auswerten (Log Analytics / Sentinel)
SigninLogs
| where TimeGenerated > ago(7d)
| where RiskLevelDuringSignIn in ("medium", "high")
| project TimeGenerated, UserPrincipalName, RiskLevelDuringSignIn, RiskState,
          IPAddress, Location, AppDisplayName, ConditionalAccessStatus
| order by TimeGenerated desc

Entscheidungsbaum: Wo fange ich an?

Für ein KMU, das bei null startet, empfiehlt sich diese Reihenfolge statt alles gleichzeitig einzuführen:

1. Break-Glass-Konten einrichten und dokumentieren (falls noch nicht vorhanden) - Voraussetzung für alles Weitere
2. PIM für Tier-0-Rollen aktivieren (Global Admin, Privileged Role Administrator) - grösster Sicherheitsgewinn pro Aufwand
3. Identity Protection Risk-based Conditional Access im Report-only-Modus testen, dann aktivieren
4. PIM auf weitere administrative Rollen ausrollen (Helpdesk Admin, User Admin, Exchange Admin, …)
5. Access Reviews für PIM-Rollen einrichten (quartalsweise/monatlich je nach Kritikalität)
6. Entitlement Management für die ersten 2-3 Anwendungsfälle einführen (z.B. Projektzugriff, externe Partner)
7. Access Reviews auf Gruppen und Apps ausweiten
8. Lifecycle Workflows einführen, sobald verlässliche HR-Datenquelle steht

Weiterlernen

• Was ist Privileged Identity Management? – Microsoft Learn
• Was sind Access Reviews? – Microsoft Learn
• Was ist Entitlement Management? – Microsoft Learn
• Was sind Lifecycle Workflows? – Microsoft Learn
• Risikobasierte Zugriffsrichtlinien – Microsoft Entra ID Protection
• Grundlagen der Microsoft Entra ID Governance Lizenzierung

Videos

YouTube