Microsoft AZ-204: Azure-Authentifizierung, Autorisierung und Sicherheit — Lernleitfaden

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

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

Überblick

Die Authentifizierung und Autorisierung in Azure basieren auf der Microsoft Identity Platform, die Tokens für Identitäten (Benutzer, Apps, Workloads) ausstellt und den Zugriff auf APIs und Ressourcen erzwingt. Anwendungen integrieren sich über OAuth 2.0 und OpenID Connect, beziehen Tokens mit MSAL und fordern Berechtigungen an, die in Azure AD-App-Registrierungen deklariert sind. Workloads, die auf Azure ausgeführt werden, können mithilfe von verwalteten Identitäten vollständig auf Anmeldeinformationen verzichten und sich auf Azure RBAC verlassen, um auf Dienste wie Key Vault, Storage und Microsoft Graph zuzugreifen. Die Geheimnisverwaltung konzentriert sich auf Azure Key Vault, mit einer klaren Trennung zwischen dem Zugriff auf die Datenebene (Data Plane) des Tresors und der Steuerung auf der Verwaltungsebene (Management Plane) sowie mit starken Wiederherstellungsgarantien durch vorläufiges Löschen (Soft Delete) und Bereinigungsschutz (Purge Protection). Für Storage bieten Shared Access Signatures (SAS) eine bereichsbezogene, zeitlich begrenzte Delegierung an Clients, ohne die Kontoschlüssel preiszugeben.

Microsoft Identity Platform, OAuth 2.0, MSAL und App-Registrierungen

Die Microsoft Identity Platform unterstützt mehrere OAuth 2.0-Flows, die für verschiedene Anwendungstypen optimiert sind:

• Authorization Code Flow: Der Standard für Web-Apps, SPAs und native Apps. Öffentliche Clients müssen PKCE verwenden, um den Autorisierungscode zu schützen. Apps leiten Benutzer zum Autorisierungs-Endpunkt weiter, erhalten einen Autorisierungscode an der Umleitungs-URI und lösen diesen dann am Token-Endpunkt gegen ein Zugriffstoken (und optional ein Aktualisierungstoken) ein. Für SPAs ersetzt der Authorization Code Flow mit PKCE den veralteten Implicit Flow und mindert das Risiko des Token-Diebstahls.
• Client Credentials Flow: Wird von Daemons und Server-zu-Server-Diensten ohne Benutzer verwendet. Die Anwendung fordert Tokens mithilfe einer Client-Assertion (Zertifikat) oder eines Client-Geheimnisses an. Hier sind nur Anwendungsberechtigungen (App-Rollen) verfügbar, und die meisten davon erfordern eine Administratorzustimmung. Dieser Flow verwendet den /.default-Scope, um die Menge der statisch konfigurierten Anwendungsberechtigungen anzufordern.
• Device Code Flow: Entwickelt für Geräte oder Umgebungen ohne eingebetteten Browser. Die App erhält einen Benutzercode und eine Verifizierungs-URL von der Identitätsplattform, der Benutzer authentifiziert sich auf einem separaten Gerät, und die App fragt den Token-Endpunkt ab (Polling). Es gelten delegierte Berechtigungen, da sich ein Benutzer anmeldet.
• Implicit Grant Flow: Wurde historisch von SPAs verwendet, um Tokens direkt vom Autorisierungs-Endpunkt zu erhalten. Davon wird heute zugunsten des Authorization Code Flows mit PKCE abgeraten. Wenn er verwendet wird, ist bei der App-Registrierung weiterhin eine Umleitungs-URI erforderlich.

MSAL (Microsoft Authentication Library) bietet einen konsistenten Token-Bezug über verschiedene Sprachen und Plattformen hinweg. Öffentliche Client-Anwendungen (Desktop, Mobile, SPA) verwenden AcquireTokenInteractive und AcquireTokenSilent, um Tokens zu beziehen und zwischenzuspeichern; native Apps verwenden zusätzlich AcquireTokenByDeviceCode für den Device Code Flow und AcquireTokenByAuthorizationCode für das Einlösen des Autorisierungscodes in Kontexten von vertraulichen Clients. Vertrauliche Clients (Web-Apps/APIs/Daemons) beziehen Tokens mit AcquireTokenForClient bei Verwendung von Client Credentials und AcquireTokenOnBehalfOf für OBO-Szenarien, in denen eine API nachgelagerte APIs mit dem delegierten Kontext eines Benutzers aufruft.

Token-Caching ist ein integraler Bestandteil von MSAL: Es speichert Zugriffs- und Aktualisierungstokens, indiziert nach Konto, Client und Scope, und ermöglicht es AcquireTokenSilent, unnötige interaktive Anfragen zu vermeiden. Web-Apps und APIs, die in mehreren Instanzen ausgeführt werden, müssen den Token-Cache mithilfe eines gemeinsam genutzten, verschlüsselten Speichers (z. B. ein verteilter Cache mit korrekter Verschlüsselung im Ruhezustand und während der Übertragung) persistent speichern und schützen. Hooks für die Cache-Serialisierung in MSAL ermöglichen eine sichere Persistenz. Scopes identifizieren die Berechtigungen, die eine App anfordert. Fordern Sie für delegierte Berechtigungen die minimalen, ressourcenspezifischen Scopes an (z. B. https://graph.microsoft.com/User.Read). Fordern Sie für Client Credentials den ressourcenbasierten /.default-Scope an, der auf die statisch der App zugewiesenen Anwendungsberechtigungen abgebildet wird (z. B. scope = https://graph.microsoft.com/.default). Nutzen Sie die inkrementelle Zustimmung (Incremental Consent), um Scopes schrittweise anzufordern und die Reibung für den Benutzer zu reduzieren.

Azure AD-App-Registrierungen definieren die Anwendungsidentität, Anmeldeinformationen, Umleitungs-URIs und Berechtigungen. Delegierte Berechtigungen erfordern einen angemeldeten Benutzer und können oft von den Benutzern selbst für ihre Daten genehmigt werden; Anwendungsberechtigungen werden der App selbst erteilt und erfordern fast immer die Zustimmung eines Administrators, da sie mandantenweit oder sehr breit gelten. Apps, die APIs verfügbar machen, deklarieren Scopes (für delegierte Berechtigungen) und App-Rollen (für Anwendungsberechtigungen) unter „Eine API verfügbar machen“ (Expose an API). Konfigurieren Sie den Zugriff als Single-Tenant oder Multi-Tenant abhängig von den Vertrauensgrenzen und verwenden Sie Zertifikate anstelle von Client-Geheimnissen für stärkere Anmeldeinformationen und eine einfachere Rotation.

Microsoft Graph verwendet die gleiche Token-Ausstellung. Authentifizieren Sie sich mit MSAL, zielen Sie auf die Graph-Ressource und fordern Sie Scopes nach dem Prinzip der geringsten Rechte (Least Privilege) an. Gängige Endpunkte sind:

• GET https://graph.microsoft.com/v1.0/me für das Benutzerprofil mit delegierten Tokens (z. B. User.Read)
• GET https://graph.microsoft.com/v1.0/users und /groups für Verzeichnisobjekte (erfordert entsprechende delegierte oder Anwendungsberechtigungen wie User.Read.All oder Group.Read.All)
• GET https://graph.microsoft.com/v1.0/sites oder /drives für SharePoint/OneDrive-Operationen Wenn Sie Client Credentials verwenden, fordern Sie den /.default-Scope an und stellen Sie sicher, dass eine Administratorzustimmung für die erforderlichen Anwendungsberechtigungen vorliegt. Wählen Sie die richtige Autorität (mandantenspezifisch versus common/organizations), um zu steuern, wo sich Benutzer anmelden können und wo Tokens ausgestellt werden können.

Azure Storage SAS und gespeicherte Zugriffsrichtlinien

Shared Access Signatures (SAS) delegieren einen feingranularen, zeitlich begrenzten Zugriff auf Azure Storage, ohne Kontoschlüssel preiszugeben:

• Benutzerdelegierungs-SAS (nur Blob): Basiert auf Azure AD. Die Anwendung erhält einen Benutzerdelegierungsschlüssel vom Blob-Dienst unter Verwendung von Azure AD-Anmeldeinformationen und erstellt dann SAS-Token für Clients. Dies ist der sicherste Ansatz für benutzerzentrierte Szenarien, da er die Verwendung von Kontoschlüsseln vermeidet und sich an der rollenbasierten Autorisierung orientiert.
• Dienst-SAS: Gilt für eine bestimmte Ressource (Blob, Container, Warteschlangennachricht, Tabellenentität, Datei). Wird mit einem Kontoschlüssel signiert. Unterstützt je nach Dienst Berechtigungen wie Lesen, Schreiben, Hinzufügen, Erstellen, Löschen, Auflisten, Festlegen der Unveränderlichkeit und Tags.
• Konto-SAS: Größter Geltungsbereich über mehrere Dienste (Blob, Queue, Table, File) und Ressourcentypen. Aufgrund des großen Auswirkungsbereichs nur sparsam verwenden.

SAS-Token enthalten Einschränkungen wie Ablaufzeit (se), Startzeit (st), Berechtigungen (sp), IP-Bereiche (sip), erlaubte Protokolle (spr), signierte Ressource (sr) und, wenn an eine gespeicherte Zugriffsrichtlinie gebunden, eine signierte Kennung (si). Folgen Sie dem Prinzip der geringsten Rechte (Least Privilege), indem Sie nur die notwendigen Berechtigungen erteilen, die Ablaufzeiten kurz halten und HTTPS erzwingen (spr=https). Bevorzugen Sie nach Möglichkeit eine Benutzerdelegierungs-SAS; andernfalls verwenden Sie eine Dienst-SAS mit einer gespeicherten Zugriffsrichtlinie zur Widerrufung.

Gespeicherte Zugriffsrichtlinien befinden sich auf Containern, Dateifreigaben, Warteschlangen oder Tabellen und definieren einen wiederverwendbaren Satz von Einschränkungen (Berechtigungen, Start, Ablauf). Beim Erstellen einer SAS wird die Richtlinie über ihre Kennung referenziert. Dies ermöglicht einen zentralen Widerruf oder eine Verschärfung des Geltungsbereichs, ohne alle SAS-Token neu ausstellen zu müssen; das Aktualisieren oder Löschen der Richtlinie wirkt sich sofort auf alle damit verknüpften SAS-Token aus. Rotieren Sie Kontoschlüssel regelmäßig, wenn Dienst- oder Konto-SAS verwendet werden, und überwachen Sie die Nutzung durch Diagnoseeinstellungen und Azure Monitor-Protokolle.

Praktisches Problemszenario

Adobe führt ein mandantenfähiges Medienverarbeitungsportal auf Azure ein. Kunden melden sich mit ihren eigenen Microsoft Entra ID-Mandanten an, laden große Mediendateien direkt in den Blob-Speicher hoch und verfolgen den Verarbeitungsstatus. Die Lösung muss das Speichern von Geheimnissen vermeiden, Berechtigungen zentralisieren und die Wiederherstellbarkeit von Geheimnissen für mindestens 90 Tage sicherstellen.

1. Anwendungen in Microsoft Entra ID registrieren:

   • Erstellen Sie eine SPA für die Portal-Benutzeroberfläche und einen vertraulichen Client für die Backend-API. Legen Sie API-Scopes für den delegierten Zugriff offen und definieren Sie App-Rollen für Hintergrundjobs. Konfigurieren Sie die SPA für die Verwendung des Authorization Code Flow + PKCE mit exakten Weiterleitungs-URIs. Dies richtet jeden Client auf den korrekten OAuth-Flow aus und erzwingt Grenzen für die Zustimmung nach dem Prinzip der geringsten Rechte.

2. MSAL im SPA und Backend implementieren:

   • Die SPA fordert Token für die Backend-API mit AcquireTokenInteractive/AcquireTokenSilent und inkrementeller Zustimmung an. Das Backend verwendet AcquireTokenOnBehalfOf, um Microsoft Graph aufzurufen und das Basisprofil des angemeldeten Benutzers zu lesen. Dies bewahrt den Benutzerkontext durchgängig und minimiert Abfragen durch Token-Caching.

3. Systemseitig zugewiesene verwaltete Identitäten für App Service (API) und Azure Functions (Medienprozessoren) aktivieren:

   • Weisen Sie die Rolle Storage Blob Data Contributor für den Mediencontainer und Key Vault Secrets User für den Vault zu. Verwaltete Identitäten eliminieren die unkontrollierte Verbreitung von Geheimnissen und ermöglichen es der Plattform, Anmeldeinformationen automatisch zu rotieren, während sie gleichzeitig einen sicheren Zugriff auf Storage und Key Vault über Azure RBAC ermöglichen.

4. Azure Key Vault mit RBAC-Datenebene, Soft-Delete und Purge Protection konfigurieren:

   • Speichern Sie Signaturzertifikate für die Backend-Assertion, API-Schlüssel von Drittanbietern und alle Verbindungsgeheimnisse, die nicht durch AAD ersetzt werden können. Erzwingen Sie Purge Protection (Schutz vor endgültigem Löschen) sowie Soft-Delete (vorläufiges Löschen), um die Wiederherstellung für 90 Tage zu garantieren. RBAC vereinfacht die Überwachung und skaliert im Vergleich zu richtlinienbasiertem Zugriff pro Vault über Umgebungen hinweg.

5. Key Vault-Referenzen für die Konfiguration verwenden:

   • Referenzieren Sie Geheimnisse in den App-Einstellungen von App Service und Functions mit @Microsoft.KeyVault(SecretUri=…). Die Plattform löst die Werte mit der verwalteten Identität auf und aktualisiert sie, wodurch Codeänderungen entfallen und verhindert wird, dass Geheimnisse in Klartextkonfigurationen gespeichert werden.

6. Direkte Browser-Uploads mit SAS delegieren:

   • Das Backend stellt Benutzerdelegierungs-SAS-Token für kurzlebigen, reinen Schreibzugriff auf einen bestimmten Blob-Pfad aus, der auf IP und HTTPS beschränkt ist. Erstellen Sie für operative Batch-Tools eine Dienst-SAS, die an eine gespeicherte Zugriffsrichtlinie auf dem Container gebunden ist, sodass Token zentral durch Aktualisieren oder Löschen der Richtlinie widerrufen werden können. Dies ermöglicht Client-Uploads mit hohem Durchsatz, ohne Kontoschlüssel preiszugeben, und unterstützt den Widerruf im Notfall.

7. Microsoft Graph minimal integrieren:

   • Fordern Sie https://graph.microsoft.com/User.Read in der SPA für die Profilanzeige an und verwenden Sie https://graph.microsoft.com/.default im Backend, falls Anwendungsberechtigungen erforderlich sind (mit vorheriger Zustimmung des Administrators). Die Verwendung von /.default stellt sicher, dass das Backend zentral gewährte Anwendungsberechtigungen berücksichtigt und vermeidet, zur Laufzeit zu viele Scopes anzufordern.

Dieses Design verwendet Authorization Code + PKCE zur Absicherung der SPA, OBO zur Beibehaltung des Benutzerkontexts in nachgelagerten Systemen, verwaltete Identitäten und RBAC zur Eliminierung von Geheimnissen, Key Vault mit starken Wiederherstellungsgarantien, Key Vault-Referenzen für eine saubere Konfiguration, Graph mit Scopes nach dem Prinzip der geringsten Rechte und SAS mit gespeicherten Zugriffsrichtlinien für sichere, widerrufbare Client-Uploads.

← Azure-Containerlösungen · Alle Domänen · Azure API Management →

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

Microsoft durchsuchen →