Schützen Sie Ihren Azure Blob Storage

Azure Blob Storage speichert riesige Mengen unstrukturierter Objektdaten in Containern. Es ist oft Ziel von Exfiltrationen, Ransomware und öffentlichen Expositionsfällen. Dieser Artikel bietet Sicherheitsempfehlungen, die speziell für Blob-Container, Blobs und hierarchische Namensräume von Azure Data Lake Storage sind.

Note

Dieser Artikel behandelt Sicherheitspraktiken speziell für Azure Blob Storage. Für Sicherheitsratschläge auf Kontoebene siehe Secure your Azure Storage account.

Netzwerksicherheit

  • Front-benutzerdefinierte Domains, statische Websites und alle öffentlich bereitgestellten Blob-Inhalte mit Azure Front Door: TLS bei Azure Front Door mit einem verwalteten Zertifikat beenden, WAF aktivieren und den öffentlichen Netzwerkzugang des Speicherkontos einschränken, sodass nur Front Door den Ursprung erreichen kann. Die eigene benutzerdefinierte Domain-Funktion von Azure Storage unterstützt keine verwalteten TLS-Zertifikate, und Front Door fügt WAF-Schutz, Rate-Limiting und Logging hinzu, die dem anonymen Containerzugriff fehlen. Weitere Informationen finden Sie unter Use Azure Front Door with Azure Storage blobs.

  • Deaktivieren Sie den statischen Website-Endpunkt, wenn er nicht verwendet wird: Der $web-Container bleibt öffentlich lesbar, solange die Funktion für statische Websites aktiviert ist, selbst wenn allowBlobPublicAccess auf false festgelegt ist. Deaktivieren Sie die statische Website-Funktion bei Konten, die sie nicht benötigen. Weitere Informationen finden Sie unter Hosten von statischen Websites in Azure Storage.

Identitäts- und Zugriffsverwaltung

Anonymer öffentlicher Zugang

  • Deaktivieren Sie anonymen öffentlichen Lesezugriff im Speicherkonto: Setzen Sie die allowBlobPublicAccess Eigenschaft so, false dass kein Container im Konto öffentlich sein kann, unabhängig von der Konfiguration auf Containerebene. Weitere Informationen finden Sie unter Übersicht: Korrigieren des anonymen öffentlichen Lesezugriffs für Blob-Daten.

  • Überprüfen und beheben Sie bestehende anonyme Zugriffe: Verwenden Sie die Leitlinien in Remediate anonymous read access to blob data , um Container zu finden, die öffentlichen Zugriff erlauben, und diese in privaten Zugriff oder explizites SAS-basiertes Sharing umzuwandeln.

SAS und ABAC auf Blob-Ebene

  • Verwenden Sie für den Blobzugriff bevorzugt eine Benutzerdelegierungs-SAS anstelle einer Dienst-SAS: Eine Benutzerdelegierungs-Shared Access Signature (SAS) wird mit Microsoft Entra-Anmeldeinformationen signiert. Der Widerruf des Benutzerdelegierungsschlüssels macht sofort alle darauf basierenden SAS ungültig und bietet eine Möglichkeit zum Widerruf, die bei Dienst- und Konto-SAS nicht vorhanden ist. Weitere Informationen finden Sie unter Erstellen einer SAS für die Benutzerdelegierung.

  • Scope-Service-SAS mit gespeicherten Zugriffsrichtlinien zur Rückgängigmachbarkeit: Wenn Sie ein Service-SAS verwenden müssen, verknüpfen Sie es mit einer gespeicherten Zugriffsrichtlinie für den Container. Du kannst die Richtlinie anschließend ändern oder löschen, um alle SAS, die auf sie verweisen, ungültig zu machen. Ohne eine Richtlinie kann ein Service-SAS nur durch das Rotieren der Kontoschlüssel widerrufen werden, was Auswirkungen auf alle anderen SAS im Konto hat. Weitere Informationen finden Sie unter Definieren einer gespeicherten Zugriffsrichtlinie.

  • Verwenden Sie Blob-Index-Tags, um den Zugriff über ABAC zu bedingen: Kombinieren Sie Blob-Index-Tags mit attributbasierten Zugriffskontrollbedingungen (ABAC), um nur Blobs mit spezifischen Tag-Werten Lesezugriff zu gewähren – zum Beispiel . Classification=Public Dieser Ansatz ermöglicht es einer einzigen Rollenzuweisung, viele Anrufer zu bedienen, ohne Zugriff auf sensible, getaggte Daten zu gewähren. Weitere Informationen finden Sie unter Zugriff auf Blobs mithilfe von ABAC-Bedingungen autorisieren.

Datenschutz

  • Verwenden Sie Blob-Verschlüsselungsscopes, um die Verschlüsselung für bestimmte Container oder Blobs zu isolieren: Verschlüsselungsscopes ermöglichen es, verschiedene Schlüssel oder Schlüsselrotationsrichtlinien auf Container- oder Blob-Ebene innerhalb eines einzigen Kontos anzuwenden. Diese Funktion ist nützlich für Multitenant-Workloads, die ein Konto teilen, aber eine Schlüsselkontrolle pro Tenant benötigen. Weitere Informationen finden Sie unter Verschlüsselungsumfange für Blob Storage.

  • Verwenden Sie clientseitige Verschlüsselung für Blob-Daten, die niemals im Klartext auf dem Server erscheinen dürfen: Verschlüsseln Sie Blob-Inhalte im Client vor dem Upload. Das SDK integriert sich mit Azure Key Vault oder Managed HSM für die Schlüsselverwaltung. Kombinieren Sie dies mit serverseitigem CMK für mehrschichtigen Schutz. Weitere Informationen finden Sie unter Client-seitige Verschlüsselung für Blobs.

Unveränderlichkeit und WORM

  • Konfigurieren Sie zeitbasierte Aufbewahrungsrichtlinien für regulierte Daten: Wenden Sie eine zeitbasierte Aufbewahrung auf Container- oder Versionsebene an, um Änderungen oder Löschungen von Blobs für einen festen Zeitraum zu verhindern. Versionsebene Unveränderlichkeit bietet eine feinere Kontrolle und man kann sie bei einzelnen Versionen aktivieren oder erweitern. Weitere Informationen finden Sie unter Speichern unternehmenskritischer Blobdaten mit unveränderlichem Speicher.

  • Verwenden Sie rechtliche Sperren für unbegrenzte Aufbewahrung, die durch rechtliche oder ermittlerische Bedürfnisse getrieben wird: Rechtliche Sperren verhindern die Löschung, bis ein autorisierter Benutzer die Sperre ausdrücklich aufhebt, ohne feste Dauer. Weitere Informationen finden Sie unter Speichern unternehmenskritischer Blobdaten mit unveränderlichem Speicher.

  • Sperren Sie Aufbewahrungsrichtlinien, um sie nicht veränderbar zu machen: Benutzer mit entsprechenden Berechtigungen können eine entsperrte Aufbewahrungsrichtlinie verkürzen oder löschen. Das Sperren der Richtlinie macht die Aufbewahrungsfrist zu einer unumkehrbaren Verpflichtung. Sperren Sie erst, nachdem Sie die Laufzeit der Richtlinie überprüft haben. Weitere Informationen finden Sie unter Konfigurieren von Unveränderlichkeitsrichtlinien für Container.

Objektreplikation und Kopieroperationen

  • Beschränke die Objekt-Replikation auf Quellkonten, die du kontrollierst: Konfiguriere die erlaubte Quellkontoliste des Zielkontos so, dass nur bekannte, vertrauenswürdige Quellkonten Daten pushen können. Weitere Informationen finden Sie unter Konfigurieren der Objektreplikation.

  • Verhindern von Cross-Tenant-Objekt-Replikation: Replikationsrichtlinien verbieten, deren Quell- und Zielkonten in verschiedenen Microsoft Entra-Tenants liegen. Diese Einschränkung verhindert, dass ein autorisierter Benutzer die Replikation auf einen externen Tenant konfiguriert. Weitere Informationen finden Sie unter Verhindern der Microsoft Entra-Mandanten übergreifenden Objekt-Replikation.

  • Einschränken Sie den erlaubten Umfang für Kopieroperationen: Konfigurieren Sie das Konto so, dass Kopieroperationen nur von Quellkonten im selben Tenant oder im selben Abonnement zugelassen werden. Diese Konfiguration blockiert einen gemeinsamen Exfiltrationspfad – das Kopieren von einem privaten Konto in ein von Angreifern kontrolliertes Konto. Weitere Informationen finden Sie unter Zulässiger Umfang für Kopieroperationen.

Sicherung und Wiederherstellung

  • Aktivieren Sie Blob-Versionierung, um vorherige Versionen beim Schreiben und Löschen zu erhalten: Wenn Sie die Versionierung aktivieren, erzeugt jede Schreib- oder Löschoperation eine neue Version und behält den vorherigen Zustand. Sie können Versionen adressieren und wiederherstellen. Weitere Informationen finden Sie unter Blobversionsverwaltung (Vorschau).

  • Aktivieren Sie Soft Delete für Blobs und Container: Soft Delete behält gelöschte Blobs und Container für eine festgelegte Aufbewahrungsfrist, sodass Sie sie in dieser Zeit wiederherstellen können. Richte Container-Level und Blob-Level Soft Delete separat ein und aktiviere beide. Weitere Informationen finden Sie unter Soft Delete für Blobs und Soft Delete für Container.

  • Aktivieren Sie die Point-in-Time-Wiederherstellung für Blockblob-Konten: Die Point-in-Time-Wiederherstellung arbeitet mit Versionsmanagement und Soft Delete, um einen Bereich von Blockblobs auf einen bestimmten vergangenen Zeitstempel zurückzusetzen. Diese Funktion ist hilfreich für die Wiederherstellung von Ransomware. Die Zeitpunktwiederherstellung setzt voraus, dass Sie die Versionierung, das vorläufige Löschen von Blobs und den Änderungsfeed aktivieren. Weitere Informationen finden Sie unter Zeitpunktwiederherstellung – Blockblobs.

  • Aktivieren Sie den Änderungsfeed für Audit und Forensik: Der Änderungsfeed ist ein geordnetes, unveränderliches Protokoll jeder Änderung an Blobs im Konto. Es ermöglicht nicht nur eine zeitpunktgenaue Wiederherstellung, sondern bietet auch ein dauerhaftes Audit-Protokoll für Untersuchungen. Weitere Informationen finden Sie unter Change feed support in Azure Blob Storage.

Azure Data Lake-Speicher

Data Lake Storage fügt Blob Storage einen hierarchischen Namensraum und POSIX-ähnliche Zugriffskontrolllisten (ACLs) hinzu. ACLs und RBAC arbeiten zusammen – gewähren groben Zugriff über RBAC und verfeinern innerhalb des Dateisystems mit ACLs.

  • Verwenden Sie RBAC für grobkörnigen Zugriff und ACLs für feinkörnigen Zugriff: Weisen Sie integrierte Blob-RBAC-Rollen auf Container- oder Kontoebene zu, um breiten Zugriff zu gewähren. Dann verwenden Sie ACLs auf Verzeichnissen und Dateien, um den Zugriff innerhalb des Containers einzuschränken. Verwenden Sie keine ACLs allein für Berechtigungen, die ein Benutzer über einen gesamten Container hinweg benötigt. RBAC ist effizienter zu bewerten und zu prüfen. Weitere Informationen finden Sie unter Access Control Model in Azure Data Lake Storage.

  • Verwenden Sie Standard-ACLs auf Verzeichnisse, um Berechtigungen für neue Kind-Objekte zu erben: Standard-ACLs gelten für Dateien und Verzeichnisse, die nach der Einstellung der ACL erstellt werden. Setze sie auf Verzeichnisebene, um das Verwalten von ACLs bei einzelnen Dateien zu vermeiden. Weitere Informationen finden Sie unter Access Control Lists in Azure Data Lake Storage.

  • Aktivieren Sie den hierarchischen Namensraum bei der Kontoerstellung: Sie können den hierarchischen Namensraum auf einem bestehenden Konto nicht aktivieren, ohne Migration durchzuführen. Wenn Sie wissen, dass eine Arbeitslast Data Lake Storage-Semantik verwendet, aktivieren Sie sie im Voraus, anstatt später zu migrieren. Weitere Informationen finden Sie unter Azure Data Lake Storage hierarchical namespace.

Protokollierung und Überwachung

  • Warnung bei anonymen Zugriffstreffern, nachdem Sie anonymen Zugriff deaktiviert haben: Wenn Sie allowBlobPublicAccess auf falsesetzen, filtern Sie Speicherprotokolle auf AuthenticationType == "Anonymous" und warnen Sie bei Treffern. Diese Treffer deuten entweder auf einen falsch konfigurierten Client oder einen Probing-Versuch hin. Weitere Informationen finden Sie unter Überwachen von Azure Storage.

  • Aktivieren Sie Defender for Storage, und reagieren Sie auf Bewertungen der Malwareüberprüfung: Wenn Sie die Malwareüberprüfung aktivieren, konfigurieren Sie eine automatisierte Reaktion (Bloblöschung, Quarantänekennzeichnung oder Unterdrückung nachgelagerter Workflows) für MalwareScanningResult Bewertungen, damit als schädlich identifizierte Blobs nicht für Nutzer bereitgestellt werden können. Weitere Informationen finden Sie unter Reagieren auf Malwareüberprüfungsergebnisse in Defender for Storage.

  • Blob-Index-Tag-Mutationen auf Klassifikationsdrift verfolgen: Wenn du Blob-Index-Tags verwendest, um ABAC-Zugriffsbedingungen zu steuern, beeinflussen Änderungen an diesen Tags direkt, wer den Blob lesen kann. Protokollieren Sie SetBlobTags-Vorgänge für sensible Container und warnen Sie bei diesen. Weitere Informationen finden Sie unter Verwalten und Finden von Daten in Azure Blob Storage mit Blobindextags.

Nächste Schritte

  • Zuletzt aktualisiert um