Sichern Ihres Azure-Speicherkontos

Azure Storage bietet skalierbaren, langlebigen Cloud-Speicher für Blobs, Dateien, Warteschlangen und Tabellen in einem einzigen Speicherkonto. Da ein Speicherkonto Daten mit sehr unterschiedlichen Sensitivitätsstufen enthalten kann und oft Ziel von Exfiltrations- und Ransomware-Angriffen ist, sollten Sie gezielt Maßnahmen ergreifen, um das Konto, die darin enthaltenen Daten und die darauf zugreifenden Identitäten zu schützen.

Dieser Artikel bietet Sicherheitsempfehlungen, um Ihr Azure Storage-Konto zu schützen. Diese Empfehlungen gelten für alle Datendienste im Konto (Blobs, Dateien, Warteschlangen und Tabellen). Für spezifische Anleitungen für jeden Datendienst siehe die Verwandten Sicherheitsartikel am Ende dieses Artikels.

Die Sicherheitsempfehlungen in diesem Artikel implementieren Zero Trust-Prinzipien: "Explizit überprüfen", "Minimalen Berechtigungszugriff verwenden" und "Verletzung als gegeben ansehen". Umfassende Anleitungen zu Zero Trust finden Sie im Zero Trust Guidance Center.

Dienstspezifische Sicherheit

Azure Storage hat architektonische Merkmale, die beeinflussen, wie Sie es sicher bereitstellen. Entscheidungen, die Sie beim Erstellen eines Kontos treffen – Bereitstellungsmodell, Art, Redundanz und Endpunktkonfiguration – lassen sich später schwer ändern und beeinflussen die Sicherheitslage jeder Workload, die das Konto nutzt.

Speicherkontoarchitektur

  • Verwenden Sie das Azure Resource Manager-Deployment-Modell: Erstellen Sie neue Speicherkonten mit dem Azure Resource Manager-Deployment-Modell. Resource Manager-Konten unterstützen Azure rollenbasierte Zugriffskontrolle (RBAC), verwaltete Identitäten, Microsoft Entra ID-Autorisierung für Daten, Ressourcensperrungen, Tags und Richtlinien – keine davon ist mit dem klassischen Bereitstellungsmodell verfügbar. Migriere alle verbleibenden klassischen Konten. Weitere Informationen finden Sie unter Migrate a classic storage account to Azure Resource Manager.

  • Separate Speicherkonten nach Arbeitslast, Umgebung und Empfindlichkeit: Erstellen Sie separate Konten für Entwicklung, Vorproduktion und Produktion sowie separate Konten für Daten unterschiedlicher Sensitivitätsklassifikationen. Ein Speicherkonto ist eine Shared-Key-Vertrauensgrenze und eine Policy-Grenze – das Kombinieren von Arbeitslasten in einem Konto erhöht den Explosionsradius eines Kompromisses und erschwert die Modellierung des Least-Privileg-Zugriffs.

  • Verwenden Sie pro Region ein Konto für regionale Isolation: Das Platzieren von Konten in der Region, in der ihre verbrauchenden Arbeitslasten laufen, reduziert die Datenübertragung zwischen den Regionen und vereinfacht die Compliance-Grenzen. Für Multiregion-Designs kombinieren Sie regionale Konten mit georedundantem Speicher oder Objektreplikation, anstatt alle Regionen von einem einzigen Konto zu bedienen. Weitere Informationen finden Sie unter Azure Storage-Redundanz.

Angemessene Verwendung von Azure Storage

  • Verwenden Sie keine Azure Storage-Kontoschlüssel als langfristige Anmeldeinformationen für Anwendungen: Speicherkontoschlüssel gewähren die volle Kontrolle über das Konto und können nicht eingeschränkt werden. Anwendungen sollten Microsoft Entra ID mit verwalteten Identitäten oder, wenn Entra ID keine Option ist, kurzlebige Benutzerdelegierungs-Shared Access Signature (SAS)-Token verwenden. Weitere Informationen finden Sie unter Autorisieren des Zugriffs auf Daten in Azure Storage.

  • Verwenden Sie Azure Storage nicht als allgemeiner Geheimnisspeicher: Geheimnisse, Verbindungsstrings und Zertifikate gehören zu Azure Key Vault, das Rotation, Zugriffsrichtlinien, Hardware-Sicherheitsmodul (HSM)-Schutz und Audit-Trails bietet. Weitere Informationen finden Sie in der Übersicht über Azure Key Vault.

Netzwerksicherheit

Speicherkonten sind standardmäßig über das Internet erreichbar. Die Verringerung der Netzwerkangriffsfläche ist die effektivste Änderung, die Sie vornehmen können, um ein Konto vor unbefugtem Zugriff, Datenexfiltration und Aufklärung zu schützen.

  • Deaktiviere den öffentlichen Netzwerkzugriff auf das Speicherkonto: Wenn deine Clients vollständig in Azure sind oder über Private Link erreichbar sind, setze den öffentlichen Netzwerkzugang des Kontos auf Deaktiviert, sodass nur Anfragen über private Endpunkte angenommen werden. Weitere Informationen finden Sie unter Konfigurieren von Firewalls und virtuellen Netzwerken in Azure Storage.

  • Nutze private Endpunkte für den Zugriff aus virtuellen Netzwerken: Ein privater Endpunkt weist dem Speicherkonto eine private IP-Adresse aus deinem virtuellen Netzwerk zu und leitet den Datenverkehr über das Microsoft-Backbone. In Kombination mit deaktiviertem öffentlichem Netzwerkzugang eliminieren private Endpunkte die Internetbelastung. Weitere Informationen finden Sie unter Verwenden privater Endpunkte für Azure Storage.

  • Beschränken Sie den öffentlichen Zugriff mit der Speicherfirewall, wenn private Endpunkte nicht praktikabel sind: Wenn Clients das Konto über öffentliches Netzwerk erreichen müssen, setzen Sie die Standardaktion der Firewall auf Ablehnen und lassen Sie nur die spezifischen IP-Bereiche, virtuelle Netzwerk-Subnetze (über Service-Endpunkte) oder Ressourceninstanzen zu, die Zugriff benötigen. Weitere Informationen finden Sie unter Konfigurieren von Firewalls und virtuellen Netzwerken in Azure Storage.

    • Vertrauenswürdige Microsoft-Dienste zulassen, wenn diese Zugriff auf das Konto benötigen: Firewallregeln nach dem Prinzip „Standardmäßig verweigern“ blockieren Anfragen von anderen Azure-Diensten (z. B. Azure Backup, Log Analytics und Microsoft Defender for Storage) sowie aus dem Azure-Portal und von Diagnosepipelines. Fügen Sie die Ausnahme Azure-Diensten in der Liste der vertrauenswürdigen Dienste den Zugriff auf dieses Speicherkonto erlauben hinzu, damit First-Party-Dienste, auf die Sie angewiesen sind, das Konto erreichen können, ohne es für das öffentliche Internet freizugeben. Weitere Informationen finden Sie unter Grant-Zugriff auf vertrauenswürdige Azure-Dienste.

    • Gewähren Sie allgemein Zugriff auf spezifische Ressourceninstanzen statt auf vertrauenswürdige Dienste: Bevorzugen Sie Ressourceninstanzregeln, die eine benannte Azure-Ressource und deren verwaltete Identität autorisieren, gegenüber der allgemeinen Ausnahme "Allow trusted Microsoft-Dienste". Resource Instance Rules erzeugen eine kleinere Vertrauensfläche. Weitere Informationen finden Sie unter Gewähren des Zugriffs von Azure-Ressourceninstanzen.

  • Verknüpfe Speicherkonten mit einem Netzwerksicherheitsperimeter: Ein Netzwerksicherheitsperimeter definiert logische Grenzen zwischen Plattform und Serviceressourcen und blockiert standardmäßig den Datenverkehr außerhalb des Perimeters, wodurch eine tiefgehende Verteidigung über die Firewall-Regeln pro Konto hinausgeht. Weitere Informationen finden Sie unter Network Security Perimeter für Azure Storage.

  • Setzen Sie eine Mindest-TLS-Version von 1.2 oder höher durch: Konfigurieren Sie die minimale TLS-Version des Speicherkontos so, dass Clients abgelehnt werden, die ältere, veraltete Versionen aushandeln. Weitere Informationen finden Sie unter Konfigurieren der erforderlichen Mindestversion von Transport Layer Security (TLS) für ein Speicherkonto.

  • Sichere Übertragung erfordern (HTTPS): Aktivieren Sie die Secure Transfer required-Eigenschaft , um jede Anfrage über HTTP abzulehnen. Diese Anforderung gilt sowohl für REST-Endpunkte als auch für den Zugriff von SMB auf Azure Files. Weitere Informationen finden Sie unter Sichere Übertragung für ein Speicherkonto erforderlich.

    • Einige Szenarien, wie ältere SMB-Clients oder Altwerkzeuge, erfordern HTTP. In solchen Fällen isolieren Sie diese Clients in einem kontrollierten Netzwerksegment und migrieren Sie sie so schnell wie möglich von HTTP.

  • Einschränken Sie die Replikations- und Kopieroperationen zwischen Tenant-Objekten: Konfigurieren Sie das Speicherkonto so, dass Kopier- und Objektreplikationsoperationen nur von Quellkonten desselben Tenants oder nur von zugelassenen Quellkonten zugelassen werden. Diese Konfiguration verhindert die Datenübertragung über Tenant-Grenzen hinweg durch Nutzer mit Data-Plane-Berechtigungen. Weitere Informationen finden Sie unter Erlaubter Anwendungsbereich für Kopieroperationen und Objektreplikation verhindern über Microsoft Entra-Tenants hinweg.

  • Verwenden Sie VNet-Service-Tags für ausgehende Regeln zu Azure Storage: Wenn Sie ausgehenden Datenverkehr aus einem virtuellen Netzwerk auf Azure Storage beschränken, verwenden Sie den Storage Service-Tag (oder eine regionsspezifische Variante) statt fest kodierter IP-Bereiche. Microsoft hält das Service-Tag aktuell, wenn sich der IP-Adressraum ändert. Weitere Informationen finden Sie in der Übersicht über Azure-Diensttags.

  • Bevorzugen Sie das globale Microsoft-Netzwerk für eingehendes Routing: Konfigurieren Sie die Netzwerkroutingpräferenz des Speicherkontos auf Microsoft-Netzwerkrouting, sodass eingehender Datenverkehr am dem Client nächstgelegenen Point of Presence in das Microsoft-Backbone eintritt und durchgängig im Microsoft-Netzwerk verbleibt. Der Internetdatenverkehr verlässt das Microsoft-Netzwerk an einem früheren Punkt und ist dem Pfad durch das öffentliche Internet stärker ausgesetzt. Weitere Informationen dazu finden Sie unter Konfigurieren der Netzwerkroutingpräferenz für Azure Storage.

Identitäts- und Zugriffsverwaltung

Speicherkonten unterstützen zwei Autorisierungsmodelle: Microsoft Entra ID (identitätsbasiert, prüfbar, widerrufbar) und Shared Key (ein symmetrisches Geheimnis mit vollständigem Kontozugriff). Verlagere Workloads, wo immer möglich, auf Microsoft Entra ID und behandle den geteilten Schlüssel als alten Fallback.

  • Verwenden Sie Microsoft Entra ID, um den Zugriff auf Daten zu autorisieren: Die Microsoft Entra ID-Autorisierung verwendet OAuth 2.0-Token und integriert sich in Conditional Access, verwaltete Identitäten und RBAC-Audit-Trails. Es ist dem Shared Key für den Zugriff auf die Datenebene in jeder Hinsicht überlegen. Weitere Informationen finden Sie unter Autorisieren des Zugriffs auf Daten in Azure Storage.

  • Autorisierung des gemeinsamen Schlüssels nicht zulassen: Stellen Sie die allowSharedKeyAccess Eigenschaft so ein false , dass das Konto jede mit den Kontoschlüsseln unterzeichnete Anfrage ablehnt. Nur Microsoft Entra ID und, wo zutreffend, Benutzerdelegierungs-SAS-Anfragen werden akzeptiert. Weitere Informationen finden Sie unter Verhindern Sie die Autorisierung durch Shared Key für ein Azure Storage-Konto.

  • RBAC-Rollen im kleinsten angemessenen Umfang zuweisen: Die integrierten Storage Data-Plane-Rollen (zum Beispiel Storage Blob Data Reader, Storage Queue Data Contributor) auf Container-, Share-, Warteschlange- oder Tabellenebene zuweisen, wenn möglich, statt auf Konto- oder Abonnementebene. Weitere Informationen finden Sie unter Zugriff auf Blobs autorisieren mit Azure-rollenbasierter Zugriffskontrolle.

    • Fügen Sie ABAC-Bedingungen hinzu, um den Zugriff auf die Datenebene weiter einzuschränken: Azure attributbasierte Zugriffskontrolle (ABAC) erlaubt es, Bedingungen an Rollenzuweisungen anzuhängen – zum Beispiel durch die Einschränkung auf Blobs mit einem bestimmten Indextag oder unter einem bestimmten Pfadpräfix. Für weitere Informationen siehe Zugriff auf Blobs autorisieren mit Azure-Rollenzuweisungen mit ABAC-Bedingungen.

  • Verwenden Sie Benutzerdelegierungs-SAS anstelle von Service- oder Konto-SAS, wenn SAS erforderlich ist: Ein Benutzerdelegierungs-SAS wird mit einer Microsoft Entra-Anmeldekarte statt mit dem Kontoschlüssel signiert, sodass das Widerrufen des Benutzerdelegierungsschlüssels alle von ihm ausgegebenen SAS sofort ungültig macht. Service- und Konto-SAS-Token, die mit Kontoschlüsseln signiert sind, können nicht einzeln widerrufen werden. Weitere Informationen finden Sie unter Gewähren von eingeschränktem Zugriff auf Azure Storage-Ressourcen mithilfe von SAS (Shared Access Signature).

    • Begrenzt jede SAS auf die minimalen Berechtigungen und die kürzeste erforderliche Lebensdauer: Gewähre nur die spezifischen Operationen (zum Beispiel, read aber nicht write) und setze die Laufzeit für Service-SAS, die nicht durch eine gespeicherte Zugriffsrichtlinie gedeckt sind, auf eine Stunde oder weniger fest. Weitere Informationen finden Sie unter Best Practices bei der Verwendung von SAS.

    • Konfigurieren Sie eine SAS-Ablaufrichtlinie auf dem Konto: Setzen Sie eine obere Grenze für die Gültigkeitsdauer der vom Konto ausgegebenen SAS-Token. Verstöße werden protokolliert, damit Sie langlebiges SAS in Ihrem Code finden und beheben können. Weitere Informationen finden Sie unter Erstellen einer Ablaufrichtlinie für Shared Access Signatures.

    • Beschränken Sie SAS-Token auf nur HTTPS: Wenn Sie ein SAS ausgeben müssen, lassen Sie nur HTTPS in der SAS-Signatur zu, um Token-Exposition im Clear zu vermeiden. Weitere Informationen finden Sie unter Gewähren von eingeschränktem Zugriff auf Azure Storage-Ressourcen mithilfe von SAS (Shared Access Signature).

  • Wenn Sie Kontoschlüssel verwenden müssen, schützen und rotieren Sie sie: Speichern Sie Kontoschlüssel in Azure Key Vault, rufen Sie sie zur Laufzeit ab, anstatt sie in der Konfiguration einzubetten, und rotieren Sie sie in einem definierten Rhythmus. Haben Sie ein dokumentiertes Rotationsverfahren, das Ausfallzeiten vermeidet, indem beide Schlüssel während des Rollovers verwendet werden. Weitere Informationen finden Sie unter Verwalten von Speicherkonto-Zugriffsschlüsseln.

  • Speicherrollen mit privilegierten Rechten bedarfsgerecht mit Microsoft Entra Privileged Identity Management (PIM) zuweisen: Für Rollen, die Änderungen auf der Verwaltungsebene für Speicher ermöglichen (z. B. Storage Account Contributor oder Owner), erfordern eine PIM-Aktivierung mit Genehmigung und Mehrfaktorauthentifizierung anstatt dauerhafter Zuweisungen. Weitere Informationen finden Sie unter Was ist Microsoft Entra Privileged Identity Management?.

Datenschutz

Azure Storage verschlüsselt standardmäßig alle ruhenden Daten mit von Microsoft verwalteten Schlüsseln. Die Empfehlungen in diesem Abschnitt erhöhen die Kontrolle der Kunden, schützen vor versehentlichen oder böswilligen Änderungen und verringern die Datenbelastung während Übertragung und Ruhe.

  • Konfigurieren Sie kundenverwaltete Schlüssel (CMK) für die Verschlüsselung in Ruhe: Verwenden Sie einen Schlüssel, den Sie in Azure Key Vault oder Managed HSM verwalten, als Kontoverschlüsselungsschlüssel. CMK ermöglicht es Ihnen, den Verschlüsselungsschlüssel unabhängig von von Microsoft verwalteten Schlüsseln zu rotieren, zu prüfen und zu widerrufen. Sie unterstützt Compliance-Anforderungen, die die Schlüsselkontrolle für Kunden vorschreiben. Weitere Informationen finden Sie unter Vom Kunden verwaltete Schlüssel für die Verschlüsselung von Azure Storage.

  • Infrastrukturverschlüsselung für Defense-in-Depth-Doppelverschlüsselung aktivieren: Die Infrastrukturverschlüsselung legt eine zweite, dienstverwaltete Verschlüsselungsschicht auf die primäre Verschlüsselungsschicht an. Du musst es bei der Kontoerstellung aktivieren. Weitere Informationen finden Sie unter Infrastrukturverschlüsselung für doppelte Datenverschlüsselung aktivieren.

  • Verwenden Sie 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.

  • Aktivieren Sie die Azure Storage-Verschlüsselung für alle Daten bei der Übertragung: Kombinieren Sie Secure transfer required = enabled (siehe Netzwerksicherheit) mit einer TLS-Mindestversion von 1,2 oder höher. Gemeinsam stellen sie sicher, dass das Konto sowohl unverschlüsselte als auch schwach verschlüsselte Verbindungen ablehnt.

  • Verwenden Sie clientseitige Verschlüsselung für die sensibelsten Daten: Für Daten, deren Klartext niemals auf dem Server erscheinen darf, verschlüsseln Sie vor dem Hochladen im Client. Client-seitige Verschlüsselung ist komplementär zur dienstseitigen Verschlüsselung und kann zusammen mit CMK für einen geschichteten Schutz verwendet werden. Für die Unterstützung und Muster für SDKs pro Service siehe Verwandte Sicherheitsartikel.

  • Schützen Sie das Speicherkonto mit einer Ressourcensperre: Wenden Sie eine CanNotDelete- oder ReadOnly-Sperre an, um eine versehentliche oder böswillige Löschung oder Neukonfiguration des Kontos zu verhindern. Sperren gelten für die Kontoressource, nicht für die darin enthaltenen Daten, daher ergänzen sie – nicht ersetzen sie – Soft Delete und Unveränderlichkeit. Weitere Informationen finden Sie unter Anwenden einer Azure Resource Manager-Sperre auf ein Speicherkonto.

Für datendienstspezifische Datenschutzfunktionen (Blob-Unveränderlichkeit und WORM-Richtlinien, Blob-Verschlüsselungsbereiche) siehe den entsprechenden Unterartikel in Verwandte Sicherheitsartikel.

Protokollierung und Überwachung

Speicherkonten sind häufig Ziel von Credential-Diebstahl, Exfiltrationsversuchen und Fehlkonfigurationen. Sie benötigen kontinuierliches Logging und Bedrohungserkennung, um Angriffe schnell zu erkennen und darauf zu reagieren.

  • Aktivieren Sie Microsoft Defender for Storage: Defender for Storage bietet Bedrohungserkennung, Malware-Scans beim Hochladen auf Blobs und Erkennung sensibler Daten. Es kennzeichnet anomale Zugriffsmuster, bekannte bösartige IPs und Tor-Exits sowie ungewöhnliche Authentifizierungsaktivitäten. Aktivieren Sie es auf Abonnement- oder Speicherkontoebene. Weitere Informationen finden Sie unter Überblick über Microsoft Defender for Storage.

    • Aktivieren Sie das Malware-Scannen für Blob-Uploads auf Konten, die nicht vertrauenswürdige Inhalte akzeptieren: Malware-Scanning inspiziert hochgeladene Blobs und markiert oder entfernt schädliche Inhalte, bevor sie an nachgelagerte Nutzer bereitgestellt werden können. Weitere Informationen finden Sie unter Malware Scanning in Defender for Storage.

    • Aktivierung der Bedrohungserkennung sensibler Daten: Die Erkennung sensibler Daten klassifiziert die Daten im Konto und priorisiert Warnungen bei Containern, die sensible Informationen enthalten. Weitere Informationen finden Sie unter Sensitive Data Discovery in Defender for Storage.

  • Senden Sie Diagnoseeinstellungen an einen Log Analytics-Arbeitsbereich: Konfigurieren Sie Diagnoseeinstellungen auf dem Konto und jedem Datendienst (Blobs, Dateien, Warteschlangen, Tabellen), um , StorageWrite, und StorageDelete Logs sowie alle Metriken an Log Analytics zu sendenStorageRead. Bewahren Sie die Protokolle für den Zeitraum, der durch Ihre Compliance-Verpflichtungen erforderlich ist. Weitere Informationen finden Sie unter Überwachen von Azure Storage.

  • Überprüfen Sie, wie jede Anfrage autorisiert wird: Speicherprotokolle vermerken, ob jede Anfrage mit Microsoft Entra ID, Shared Key, SAS oder anonym autorisiert wurde. Abfragen Sie regelmäßig die Protokolle, um unerwartete Autorisierungsmethoden zu erkennen, insbesondere die Nutzung von Shared Key nach der Deaktivierung oder anonymen Zugriff nach der Deaktivierung. Weitere Informationen finden Sie unter Überwachen von Anfragen für Azure Storage.

  • Warnung bei hochsignalartigen Sicherheitsereignissen: Konfigurieren Sie Azure Monitor-Warnungen für Ereignisse wie Schlüsselregeneration, Änderungen der Firewall-Regeln, Änderungen des öffentlichen Netzwerkzugangs, Nutzung von Shared Key auf Konten, in denen sie deaktiviert werden sollten, und Defender für Speicherwarnungen. Weitere Informationen finden Sie unter Protokollwarnungen in Azure Monitor.

  • Weiterleiten Sie Logs an ein zentrales SIEM: Für eine Antwort im Unternehmensmaßstab leiten Sie Speicherlogs von Log Analytics an Microsoft Sentinel oder ein anderes SIEM weiter, sodass Speicherereignisse mit Identität, Netzwerk und Endpunktssignalen korrelieren. Weitere Informationen finden Sie unter Connect Azure Storage to Microsoft Sentinel.

Compliance und Governance

Governance-Kontrollen machen sichere Konfigurationen zum Standard und erkennen Drift automatisch. Für jede Lagerstätte, die größer ist als eine Handvoll Konten, ist die richtlinienbasierte Durchsetzung der einzige nachhaltige Weg, die Basislinie konsistent zu halten.

  • Wenden Sie die Azure Policy an, um die Basisspeichersicherheit durchzusetzen: Weisen Sie eingebaute Richtlinien zu, die unsichere Konfigurationen zur Bereitstellungszeit blockieren, und prüfen Sie bestehende Konten. Hochwertige integrierte Funktionen sind: sichere Übertragung verlangen, mindestens TLS 1.2 verlangen, öffentlichen Netzwerkzugang verweigern, öffentlichen Blob-Zugriff verweigern, Infrastrukturverschlüsselung verlangen und CMK verlangen. Eine vollständige Liste finden Sie unter den integrierten Definitionen von Azure Policy für Azure Storage und Azure Policy Regulatory Compliance Controls for Azure Storage.

  • Nutzen Sie den Microsoft Cloud Security Benchmark (MCSB) als Grundlage: Richten Sie Speicherkontrollen auf MCSB v2-Domänen aus, um eine einheitliche Sicherheitslage über Dienste hinweg zu gewährleisten. Weitere Informationen finden Sie unter Überblick über den Microsoft Cloud Security Benchmark.

  • Tag-Speicherkonten mit Eigentümer, Datenklassifikation und Umgebung: Governance-Richtlinien, Kostenmanagement und Incident-Response hängen alle von konsistenter Markierung ab. Wende Tags über die Azure Policy an, damit sie beim Erstellen nicht weggelassen werden können.

  • Überprüfen Sie Compliance-Angebote, bevor Sie regulierte Daten speichern: Azure Storage verfügt über Zertifizierungen für gängige regulatorische Rahmenwerke (HIPAA, PCI DSS, FedRAMP, ISO 27001 und andere). Bestätigen Sie die Deckung Ihrer Arbeitsbelastung vor dem Einsatz. Weitere Informationen finden Sie unter Azure Storage Compliance-Angebote.

Sicherung und Wiederherstellung

Regionübergreifende Redundanz sowie validierte Failover-Verfahren sorgen für regionale Widerstandsfähigkeit für das Speicherkonto selbst. Für den datendienstspezifischen Löschschutz (vorläufiges Löschen eines Blobs, Blob-Versionierung, Änderungsfeed, Zeitpunktwiederherstellung, vorläufiges Löschen einer Dateifreigabe und Momentaufnahmen) siehe den entsprechenden Unterartikel in Verwandte Sicherheitsartikel.

  • Wählen Sie eine passende Redundanzoption für Ihre Wiederherstellungsanforderungen: Georedundanter Speicher (GRS/RA-GRS/GZRS/RA-GZRS) repliziert Daten in eine gepaarte Region und unterstützt kundeninitiierte Failover für regionale Widerstandsfähigkeit. Zonenredundanter Speicher (ZRS/GZRS) schützt vor Zonenausfällen innerhalb einer Region. Weitere Informationen finden Sie unter Azure Storage-Redundanz.

  • Verlassen Sie sich nicht auf Geo-Redundanz zum Schutz vor Ransomware: Georedundante Replikation spiegelt Daten – und jegliche Beschädigung oder böswillige Löschung – in die gepaarte Region zurück. Kombinieren Sie GRS mit Unveränderlichkeitsrichtlinien, Soft Delete und Versionsmanagement für Ransomware- und Manipulationsschutz. Weitere Informationen finden Sie unter Datenschutzfunktionen in Azure Storage.

  • Üben Sie kundeninitiierte Failover und Failback: Für Konten mit RA-GRS oder RA-GZRS führen Sie eine geplante Failover-Übung durch, um Ihr Wiederherstellungsverfahren zu validieren, bevor Sie es benötigen. Weitere Informationen finden Sie unter Notfallwiederherstellung und Failover des Speicherkontos.

Für Sicherheitsrichtlinien, die spezifisch für jeden Azure Storage-Datendienst sind, siehe:

Nächste Schritte

  • Zuletzt aktualisiert um