Microsoft AZ-500: Identitäts- und Zugriffsverwaltung — Lernleitfaden

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Teil des Microsoft Azure Security Engineer Associate AZ-500 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Identitäts- und Zugriffsmanagement (IAM) in Microsoft Azure ist auf Microsoft Entra ID (ehemals Azure AD) ausgerichtet. Es regelt, wer auf welche Ressourcen unter welchen Bedingungen und mit welchen Berechtigungen zugreifen kann. Eine effektive IAM-Architektur minimiert dauerhafte Berechtigungen (standing privilege), erzwingt bedingten und risikobasierten Zugriff und führt moderne Authentifizierung für Menschen und Workloads ein, während sie hybride und externe Kollaborationsszenarien unterstützt.

Microsoft Entra Identitätskonstrukte und Geltungsbereiche

Mandanten, Benutzer und Gruppen
- Ein Mandant (Tenant) repräsentiert die Identitätsgrenze und die Vertrauensbasis (Trust Fabric) Ihrer Organisation. Benutzer können Mitglieds- oder Gastkonten (B2B) sein. Verwenden Sie Sicherheitsgruppen für die Autorisierung und Microsoft 365-Gruppen für Kollaborationsfunktionen; bevorzugen Sie dynamische Gruppen, um die manuelle Verwaltung von Mitgliedschaften zu reduzieren.
Verwaltungseinheiten (Administrative Units, AUs)
- AUs ermöglichen es Ihnen, Verzeichnisrollen für eine Teilmenge von Benutzern/Geräten zu delegieren (z. B. kann der regionale Helpdesk nur Benutzer in Europa verwalten). Dies unterstützt das Prinzip der geringsten Rechte (Least Privilege) für Verzeichnisaufgaben.
Verzeichnisrollen und Zuweisungsbereiche für Rollen
- Verzeichnisrollen (z. B. Global Administrator, User Administrator) gelten für Microsoft Entra-Ressourcen. Weisen Sie Verzeichnisrollen nach Möglichkeit auf Ebene einer AU zu, um den „Blast Radius“ (Auswirkungsbereich) einzuschränken. Die Rolle des Global Administrator ist erforderlich, um Privileged Identity Management (PIM) initial zu konfigurieren.
Bereiche der rollenbasierten Zugriffssteuerung in Azure (Azure RBAC)
- Azure RBAC regelt den Zugriff auf Azure-Ressourcen. Weisen Sie Rollen auf der Ebene von Verwaltungsgruppen, Abonnements, Ressourcengruppen oder einzelnen Ressourcen zu. Die Vererbung erfolgt nach unten; wählen Sie immer den kleinstmöglichen praktikablen Bereich, um übermäßige Berechtigungen zu reduzieren.
Operative Überlegungen
- Trennen Sie Verzeichnisrollen (Entra) von Azure RBAC (Ressourcenautorisierung). Verwenden Sie AUs und eng gefasste RBAC-Bereiche, um die administrative Reichweite zu begrenzen, Möglichkeiten für laterale Bewegungen (Lateral Movement) zu reduzieren und Zugriffsüberprüfungen zu vereinfachen.

Zugriffskontrolle mit Azure RBAC und dem Prinzip der geringsten Rechte

Integrierte Rollen und das Prinzip der geringsten Rechte
- Bevorzugen Sie die spezifischste integrierte Rolle, die zur Aufgabe passt. Beispiel: Gewähren Sie reinen Pull-Zugriff auf Container-Images mit AcrPull und Upload-/Push-Zugriff mit AcrPush, anstatt der weitreichenden Rolle Contributor. Gewähren Sie bei Key Vault die administrative Kontrolle über RBAC nur den Tresor-Administratoren, während Sie granulare Zugriffsrichtlinien für spezifische Objektoperationen wie die Zertifikatsverwaltung verwenden.
Vererbung von Rollenzuweisungen
- Weisen Sie Rollen auf dem niedrigstmöglichen Geltungsbereich zu. Zuweisungen auf Verwaltungs- oder Abonnementebene werden nach unten vererbt; vermeiden Sie weitreichende, geerbte Rechte, es sei denn, dies ist beabsichtigt. Wenn Sie konsistentes RBAC über mehrere Abonnements hinweg benötigen, prägen Sie konsistente Rollenzuweisungen durch Azure Blueprints (oder moderne IaC-Alternativen) aus, anstatt manuelle PIM-Zuweisungen vorzunehmen.
Verweigerungszuweisungen (Deny Assignments)
- Verweigerungszuweisungen blockieren explizit Aktionen, unabhängig von Erlaubniszuweisungen, und werden typischerweise von Azure-Diensten wie Azure Policy oder Blueprints erstellt. Verwenden Sie sie, um nicht verhandelbare Leitplanken (Guardrails) durchzusetzen (z. B. das Verhindern von öffentlichen Netzwerkregeln für sensible Ressourcen).
Benutzerdefinierte Rollen
- Wenn integrierte Rollen zu weitreichend sind, definieren Sie benutzerdefinierte Rollen mit nur den erforderlichen Aktionen. Validieren Sie diese durch Tests nach dem Prinzip der geringsten Rechte und durch Zugriffsüberprüfungen.

{
  "Name": "Storage Blob Reader (TagsBlocked)",
  "IsCustom": true,
  "Description": "Read blobs; no tag write",
  "Actions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/read",
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
  ],
  "NotActions": [
    "Microsoft.Resources/tags/write"
  ],
  "AssignableScopes": ["/subscriptions/00000000-0000-0000-0000-000000000000"]
}

Operative Überlegungen
- Eng gefasste RBAC-Bereiche und benutzerdefinierte Rollen reduzieren übermäßige Berechtigungen und die Audit-Oberfläche. Verweigerungszuweisungen kodieren „harte“ Compliance-Vorgaben, die nicht durch versehentlich zu weitreichende „Erlauben“-Zuweisungen umgangen werden können, was die Widerstandsfähigkeit der Sicherheitskonfiguration (Posture Resilience) verbessert.

Privilegierter Zugriff, bedingter Zugriff und Identity Protection

Privileged Identity Management (PIM)
- Berechtigt vs. aktiv: Berechtigte Zuweisungen gewähren keine dauerhaften Berechtigungen; Benutzer müssen diese JIT (Just-in-Time) aktivieren, um aktiv zu werden. Erzwingen Sie bei der Aktivierung Genehmigungen, Begründungen und MFA; legen Sie begrenzte Dauern fest und fordern Sie Ticket-Referenzen für die Nachverfolgbarkeit. Beginnen Sie mit der Erkennung privilegierter Rollen, um die aktuelle Gefährdung (Exposure) zu verstehen. Nutzen Sie regelmäßige Zugriffsüberprüfungen, idealerweise mit Ressourcen- oder Gruppenbesitzern als Prüfern, um den fortbestehenden Bedarf zu validieren.
Bedingter Zugriff (Conditional Access, CA)
- Zuweisungen zielen auf Benutzer/Gruppen, Workload-Identitäten, Cloud-Apps und Aktionen ab. Bedingungen umfassen Anmelderisiko, Geräteplattform/-zustand, Standorte, Client-Apps und Filter für Geräte und Apps. Gewährungssteuerelemente können MFA, konforme oder in Hybrid Azure AD eingebundene Geräte, App-Schutzrichtlinien oder Nutzungsbedingungen erfordern. Sitzungssteuerelemente beschränken die Anmeldehäufigkeit, persistente Sitzungen und von der App erzwungene Einschränkungen (z. B. reiner Web-Zugriff für SharePoint). Verwenden Sie den reinen Berichtsmodus (Report-Only Mode), um die Auswirkungen von Richtlinien vor deren Erzwingung sicher zu validieren. Pflegen Sie Ausschlüsse für Notfallkonten (Break-Glass Accounts) und gestaffelte Rollouts, um Aussperrungen zu verhindern.
Identity Protection
- Benutzerrisiko spiegelt die Wahrscheinlichkeit wider, dass ein Konto kompromittiert ist; Anmelderisiko spiegelt die Wahrscheinlichkeit wider, dass eine bestimmte Sitzung riskant ist. Konfigurieren Sie Richtlinien, um eine sichere Behebung zu erfordern:
  - Benutzer mit geleakten Anmeldeinformationen: als hohes Benutzerrisiko behandeln; Passwortzurücksetzung erzwingen und bis zur Behebung blockieren.
  - Anmeldungen von IPs mit verdächtigen Aktivitäten: mindestens als mittleres Anmelderisiko behandeln; mit MFA abfragen oder für sensible Apps blockieren.
- Integrieren Sie es mit CA, um das Vertrauen in Echtzeit anzupassen. Verfolgen Sie den Risikoverlauf und die Behebungsmaßnahmen, um die Wirksamkeit zu messen.
Operative Überlegungen
- PIM eliminiert dauerhafte Berechtigungen und erzwingt eine starke, auditierbare Aktivierung. CA und Identity Protection wenden das Zero-Trust-Prinzip an – die Überprüfung jedes Zugriffsversuchs basierend auf Benutzer, Gerät, Sitzung und Risiko – und reduzieren so erfolgreichen Diebstahl von Anmeldeinformationen und Token-Replay-Angriffe.

Hybride und Workload-Identitäten

Optionen für hybride Identitäten
- Kennworthash-Synchronisierung (PHS): Synchronisiert Kennworthashes mit Entra ID. Einfach und resilient; erzwingt keine lokalen Anmelderichtlinien zum Zeitpunkt der Authentifizierung.
- Passthrough-Authentifizierung (PTA): Validiert Kennwörter über schlanke Konnektoren gegen lokale DCs; erzwingt lokale Kennwortrichtlinien und Kontobeschränkungen in Echtzeit, ohne AD FS.
- Verbund (z. B. AD FS): Verlagert die Authentifizierung auf einen lokalen STS. Nur verwenden, wenn für komplexe Claims oder Legacy-Szenarien erforderlich; führt zu mehr Servern und operativem Mehraufwand.
- Nahtloses einmaliges Anmelden (Seamless SSO): Meldet Benutzer auf in die Domäne eingebundenen Geräten innerhalb des Unternehmensnetzwerks mit minimalen Eingabeaufforderungen an.
- Operative Entscheidung: Um lokale Kennwortrichtlinien und Kontobeschränkungen durchzusetzen und gleichzeitig die Anzahl der Server zu minimieren, stellen Sie PTA und Seamless SSO bereit und aktivieren Sie zusätzlich PHS für Resilienz/Failover von Szenarien, die nicht von PTA abhängig sind. Ein reiner Verbund erhöht die Komplexität und erfüllt nicht das Ziel, die Serveranzahl zu minimieren.
App-Authentifizierung bei Azure SQL von hybrid eingebundenen Windows-Geräten
- Verwenden Sie die integrierte Active Directory-Authentifizierung, um Eingabeaufforderungen zu minimieren und gegebenenfalls Kerberos/SSO zu nutzen.
Verwaltete Identitäten und Dienstprinzipale
- Verwaltete Identitäten (system- oder benutzerseitig zugewiesen) sind die erste Wahl für in Azure gehostete Workloads, da sie Geheimnisse eliminieren und Anmeldeinformationen automatisch rotieren. Weisen Sie der Identität auf Ressourcenebene RBAC mit den geringsten Rechten zu.
- Dienstprinzipale untermauern App-Registrierungen; verwenden Sie Zertifikatsanmeldeinformationen anstelle von Client-Geheimnissen und legen Sie die kürzestmögliche Lebensdauer fest.
Workload-Identitätsverbund
- Verwenden Sie den OIDC-Verbund, damit externe Workload-Identitäten (z. B. GitHub Actions, Kubernetes) Tokens für Entra-Apps erhalten können, ohne Geheimnisse zu speichern. Definieren Sie die Issuer-, Subject- und Audience-Claims präzise, um einzuschränken, wer Tokens austauschen kann.

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"gh-actions-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:contoso/api:environment:prod",
    "audiences":["api://AzureADTokenExchange"]
  }'

Zugriff von AKS auf ACR
- Verleihen Sie der verwalteten Identität des AKS-Clusters die Berechtigung AcrPull für die Zielregistrierung über den attach-acr-Flow, der die korrekte Bereichszuweisung automatisiert und Fehlzuweisungen vermeidet.

az aks update -n aks-prod -g rg-aks --attach-acr myRegistry

Operative Begründung
- PTA+PHS+Seamless SSO erzwingt lokale Kontrollen in Echtzeit und erhält gleichzeitig die Cloud-Resilienz aufrecht. Verwaltete Identitäten und Verbunde entfernen statische Geheimnisse aus Pipelines und der Laufzeitumgebung und schließen so häufig genutzte Wege für den Diebstahl von Anmeldeinformationen.

Externe Zusammenarbeit, Authentifizierungsmethoden und App-Zugriff

Externe Identitäten und B2B-Zusammenarbeit
- Verwenden Sie B2B-Gastkonten mit mandantenübergreifenden Zugriffseinstellungen, Nutzungsbedingungen und CA, die auf Gäste abzielt. Schränken Sie ein, wer einladen darf, und bevorzugen Sie den Just-in-Time-Zugriff durch Berechtigungsverwaltung.
Berechtigungsverwaltung und Zugriffspakete
- Bündeln Sie Gruppen, Apps und SharePoint-Websites in Zugriffspaketen mit Richtlinien, die definieren, wer anfragen darf (einschließlich externer Benutzer), Genehmigungsworkflows, Zuweisungsdauern und Zugriffsüberprüfungen. Verwenden Sie für die Auswahl der Prüfer „Gruppenbesitzer“, um die geschäftliche Verantwortung bei den Ressourcenverantwortlichen zu belassen.
Authentifizierungsmethoden und kennwortlose Anmeldung
- Standardisieren Sie auf starke Methoden: FIDO2-Sicherheitsschlüssel, Windows Hello for Business und Microsoft Authenticator-Anmeldung per Telefon. Nutzen Sie die kombinierte Registrierung von Sicherheitsinformationen (SSPR + MFA) und erzwingen Sie eine MFA-Registrierungsrichtlinie für alle Benutzer. Aktivieren Sie SSPR bei Bedarf mit On-Premises-Writeback; fordern Sie sichere Methoden und beschränken Sie diese nach Möglichkeit auf vom Unternehmen verwaltete Faktoren. Deaktivieren Sie veraltete/einfache Authentifizierungsprotokolle und blockieren Sie schwache, nur auf SMS basierende MFA, wo das Risiko dies rechtfertigt.
Microsoft Entra-Anwendungsproxy
- Veröffentlichen Sie lokale Webanwendungen ohne eingehende Firewall-Öffnungen. Verwenden Sie Konnektorgruppen für Hochverfügbarkeit (HA), Vorauthentifizierung mit Entra ID und ergänzen Sie CA, Gerätekonformität und Identity Protection für Zero Trust bei Legacy-Anwendungen.
Sicherheit bei der Anwendungsregistrierung
- Fordern Sie Workflows für die Administratoreinwilligung an; schränken Sie ein, wer Apps erstellen darf; klassifizieren Sie Berechtigungen; bevorzugen Sie Anwendungsberechtigungen nur dann, wenn kein Benutzerkontext erforderlich ist, und beschränken Sie den API-Umfang auf das Minimum. Deaktivieren Sie nach Möglichkeit die implizite Genehmigung (Implicit Grant), fordern Sie die Zuweisung für Unternehmensanwendungen und bevorzugen Sie Zertifikate gegenüber Geheimnissen mit automatisierter Rotation.

az ad app update --id <app-id> --required-resource-access @permissions.json
az ad sp update --id <sp-id> --set appRoleAssignmentRequired=true

Operative Begründung
- Zugriffspakete und der Anwendungsproxy bieten einen geregelten, prüfbaren externen Zugriff. Starke, kennwortlose Methoden erhöhen die Phishing-Resistenz. Strenge Kontrollen bei der Anwendungsregistrierung verhindern zu weitreichende Einwilligungen und verringern die Wahrscheinlichkeit eines App-Identitätsdiebstahls.

Praktisches Problemszenario

Adobe Inc. muss einem Drittanbieter temporären administrativen Zugriff auf eine Teilmenge von Azure-Ressourcen gewähren und eine interne Legacy-Webanwendung für den Anbieter veröffentlichen, wobei eine starke Authentifizierung und Zero Standing Privilege durchgesetzt werden müssen.

Zugriffsumfang festlegen und modellieren

Erstellen Sie eine Ressourcengruppe rg-vendor-ops und verschieben Sie nur die erforderlichen Ressourcen dorthin. Weisen Sie die minimal erforderlichen Azure RBAC-Rollen zu (z. B. Contributor für rg-vendor-ops; Reader für eine Diagnose-Ressourcengruppe).
Begründung: Ein enger Geltungsbereich verhindert laterale Bewegungen. Die Rollenvererbung ist auf rg-vendor-ops beschränkt, was den „Blast Radius“ (Schadensradius) eingrenzt.

Identität und Aktivierung mit PIM steuern

Machen Sie die Administratoren des Anbieters für die erforderlichen Rollen berechtigt, nicht permanent; fordern Sie eine Genehmigung, eine Ticket-ID und MFA bei der Aktivierung und begrenzen Sie die Aktivierung auf 4 Stunden. Führen Sie zu Beginn die PIM-Funktion „Privilegierte Rollen ermitteln“ aus, um eine Baseline der bestehenden Zuweisungen zu erstellen.
Begründung: Berechtigte Zuweisungen beseitigen dauerhafte Privilegien (Standing Privilege). Genehmigung und MFA erzwingen einen JIT-Zugriff, der auf Support-Zeitfenster abgestimmt ist und eine prüfbare Kontrolle bietet.

Bedingten Zugriff und Risikorichtlinien erzwingen

Erstellen Sie eine CA-Richtlinie, die auf die Anbietergruppe sowie die Azure-Portal- und ARM-APIs abzielt und MFA, ein konformes/hybrid eingebundenes Gerät erfordert und den Zugriff von riskanten Standorten blockiert. Aktivieren Sie die Richtlinie zuerst im reinen Berichtsmodus (Report-Only) und erzwingen Sie sie dann. Konfigurieren Sie Identity Protection: Blockieren Sie hohes Benutzerrisiko (geleakte Anmeldeinformationen), bis das Kennwort zurückgesetzt wird; fordern Sie MFA für mittleres Anmelderisiko (verdächtige IP) an.
Begründung: CA koppelt den Zugriff in Echtzeit an Gerätevertrauen und Risiko. Der reine Berichtsmodus verhindert Ausfälle während des Rollouts. Risikorichtlinien beheben kompromittierte Sitzungen und Konten automatisch.

Legacy-App mit dem Microsoft Entra-Anwendungsproxy veröffentlichen

Stellen Sie zwei Konnektoren in separaten, für den Anbieter zugänglichen Subnetzen für HA bereit. Konfigurieren Sie die Vorauthentifizierung mit Entra ID, fordern Sie die Zuweisung zur Unternehmensanwendung und wenden Sie dieselbe CA-Richtlinie an. Verwenden Sie Zugriffspakete, um den Benutzern des Anbieters zeitlich begrenzten Zugriff sowohl auf die Unternehmens-App als auch auf die RG-Rollen zu gewähren; legen Sie Gruppenbesitzer als Prüfer fest.
Begründung: Der Anwendungsproxy eliminiert die Gefährdung durch eingehenden Datenverkehr und zentralisiert die Authentifizierung. Die Berechtigungsverwaltung standardisiert das Onboarding/Offboarding und stellt regelmäßige Überprüfungen durch die Ressourcenbesitzer sicher.

Workload- und Anwendungsanmeldeinformationen sichern

Ersetzen Sie alle Client-Geheimnisse durch Zertifikatsanmeldeinformationen für Dienstprinzipale; verwenden Sie für CI/CD den Workload-Identitätsverbund anstelle der Speicherung von Geheimnissen. Fügen Sie für AKS-Workloads, die Images benötigen, die ACR an den Cluster an, um der verwalteten Identität die Berechtigung AcrPull zu erteilen.
Begründung: Das Entfernen statischer Geheimnisse schließt einen häufigen Angriffsvektor; Verbund und verwaltete Identitäten bieten Zugriff mit den geringsten Rechten und automatischer Rotation.

Notfallkonten („Break-Glass“) schützen und überwachen

Schließen Sie zwei Notfallkonten von der CA aus, aber schützen Sie sie mit langen, zufälligen und offline gespeicherten Kennwörtern. Aktivieren Sie vierteljährliche Zugriffsüberprüfungen und exportieren Sie PIM- und CA-Protokolle in einen Log Analytics-Arbeitsbereich mit Warnungen bei anomalen Aktivierungen.
Begründung: Notfallkonten verhindern eine Aussperrung aus dem Mandanten und sind gleichzeitig betriebssicher. Kontinuierliche Überwachung erkennt Missbrauch schnell und stellt die Einhaltung von Compliance-Vorgaben und die Reaktionsfähigkeit bei Vorfällen sicher.

Alle Domänen · Netzwerksicherheitsarchitektur →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →