Microsoft AZ-204: Azure Storage und Blob Storage — Lernleitfaden
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.
Sicherheit, Identität und kontrollierter Datenzugriff
Azure Storage verschlüsselt standardmäßig ruhende Daten (Data at Rest) mit 256-Bit-AES unter Verwendung von Microsoft-verwalteten Schlüsseln. Für eine strengere Kontrolle aktivieren Sie kundenseitig verwaltete Schlüssel (CMK), die in Azure Key Vault oder Managed HSM gespeichert sind, um die Schlüsselrotation und die Trennung von Aufgaben zu steuern. Weisen Sie der verwalteten Identität des Speicherkontos die Berechtigungen zum Umschließen/Entschlüsseln von Schlüsseln (wrap/unwrap) zu. Für hochregulierte Workloads aktivieren Sie die Infrastrukturverschlüsselung, um eine zweite, unabhängige Verschlüsselungsebene anzuwenden. Kombinieren Sie serverseitige Verschlüsselung mit clientseitiger Verschlüsselung, wenn eine durchgängige kryptografische Kontrolle erforderlich ist.
Die Azure AD-Autorisierung integriert die Datenebene mit RBAC für die Dienste Blob und Queue sowie für die Files REST API. Vergeben Sie Rollen mit den geringsten Rechten (Least Privilege), wie z. B. Storage Blob Data Reader oder Storage Blob Data Contributor, an verwaltete Identitäten, Benutzer oder Gruppen. Verwenden Sie im Code DefaultAzureCredential, um OAuth 2.0-Token zu beziehen und das Einbetten von Schlüsseln zu vermeiden. Für den SMB-Zugriff auf Azure Files aktivieren Sie die identitätsbasierte Authentifizierung über Active Directory: Binden Sie das Speicherkonto in ein lokales AD DS (über Azure AD Kerberos für hybride Identitäten) oder in Azure AD DS ein und verwenden Sie NTFS-ACLs und RBAC (z. B. Storage File Data SMB Share Contributor) für die Autorisierung auf Freigabeebene. Stellen Sie SMB 3.x mit Verschlüsselung bei der Übertragung sicher und ziehen Sie Private Endpoints, VPN oder ExpressRoute in Betracht, um Netzwerke zu durchqueren, die Port 445 blockieren.
Shared Access Signatures (SAS) delegieren einen bereichsbezogenen, zeitlich begrenzten Zugriff, ohne Kontoschlüssel preiszugeben. Eine Service-SAS gewährt Zugriff auf einen bestimmten Dienst und eine bestimmte Ressource (z. B. ein einzelnes Blob oder einen Container) mit präzisen Berechtigungen und Start-/Ablaufzeiten. Eine Account-SAS arbeitet auf Kontoebene und erstreckt sich über mehrere Dienste (Blobs, Dateien, Warteschlangen, Tabellen) und Dienst-APIs wie das Auflisten oder Erstellen. Eine User Delegation SAS ist spezifisch für Blob Storage und wird mit einem Benutzerdelegierungsschlüssel signiert, der über Azure AD für einen Prinzipal mit entsprechender RBAC bezogen wird. Sie beseitigt die Abhängigkeit von Schlüsseln und zentralisiert die Zugriffskontrolle in Azure AD. Wenden Sie Einschränkungen an, einschließlich IP-Bereichen, zulässigen Protokollen (nur HTTPS) und kurzen Gültigkeitsdauern. Gespeicherte Zugriffsrichtlinien (Stored Access Policies) zentralisieren SAS-Einschränkungen und ermöglichen den Widerruf durch Aktualisieren oder Löschen der Richtlinie; sie gelten für Service-SAS und Account-SAS. Eine User Delegation SAS verwendet keine gespeicherten Zugriffsrichtlinien; der Widerruf erfolgt durch das Ablaufenlassen des Benutzerdelegierungsschlüssels oder das Entfernen von Azure AD-Rollenzuweisungen. Bevorzugen Sie immer SAS gegenüber Kontoschlüsseln und bevorzugen Sie User Delegation SAS, wenn Ihre Anwendung Azure AD-Token beziehen kann.
← Azure Functions und Serverless Computing · Alle Domänen · Azure Cosmos DB →
Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Bestehe deine Prüfung →