Übersicht zum Datenschutz

In der Azure Storage-Dokumentation bezieht sich Datenschutz auf Strategien zum Schutz des Speicherkontos und der darin enthaltenen Daten vor Löschung oder Änderung oder zur Wiederherstellung von Daten, nachdem sie gelöscht oder geändert wurden. Es ist wichtig, darüber nachzudenken, wie Sie Ihre Daten am besten schützen können, bevor ein Vorfall eintritt, der sie gefährden könnte. Dieser Leitfaden hilft Ihnen im Voraus zu entscheiden, welche Datenschutzfunktionen Ihr Fall benötigt. Azure Storage bietet außerdem Optionen für Notfallwiederherstellung sowie Sicherheit und Netzwerke. All diese Methoden wirken zusammen für einen umfassenden Schutz Ihrer Daten.

Empfehlungen für den grundlegenden Schutz von Daten

Wenn Sie einen grundlegenden Datenschutzschutz für Ihr Speicherkonto und die darin enthaltenen Daten wünschen, ergreifen Sie folgende Schritte:

  1. Konfigurieren Sie eine Azure Resource Manager-Sperre für das Speicherkonto, um das Konto vor Löschung oder Konfigurationsänderungen zu schützen. Weitere Informationen…

  2. Aktivieren Sie das vorläufige Löschen von Containern für das Speicherkonto, um einen gelöschten Container und dessen Inhalt wiederherzustellen. Weitere Informationen...

  3. Aktiviere Blob Soft Delete für das Speicherkonto, um einen gelöschten oder überschriebenen Blob wiederherzustellen. Mehr erfahren...

Der folgende Abschnitt beschreibt diese Optionen und weitere Optionen zum Datenschutz für andere Szenarien ausführlicher. Zum Schutz vor umfassenderen Datenverlustszenarien wie versehentlicher Kontolöschung oder Ransomware sollten Sie zusätzlich zu kontointernen Features Azure Backup aktivieren.

Eine Übersicht über die mit diesen Funktionen verbundenen Kosten finden Sie unter Zusammenfassung der Überlegungen zu Kosten.

Tipp

Nutzen Sie Azure Copilot, um Vorschläge zur Verbesserung der Sicherheitsstrategie Ihres Speicherkontos zu erhalten. Weitere Informationen finden Sie unter Verwalten und Migrieren von Speicherkonten mit Azure Copilot.

Übersicht über Datenschutzoptionen

In der folgenden Tabelle werden die Optionen zusammengefasst, die in Azure Storage für allgemeine Szenarien zum Schutz von Daten verfügbar sind. Wählen Sie die Szenarien aus, die auf Ihre Situation zutreffen, um mehr über die Ihnen zur Verfügung stehenden Optionen zu erfahren. Derzeit sind nicht alle Funktionen für Speicherkonten mit aktiviertem hierarchischem Namespace verfügbar.

Szenario Datenschutzoption Empfehlungen Schutzvorteil Verfügbar für Data Lake Storage
Verhindern Sie, dass ein Speicherkonto gelöscht oder geändert wird. Azure Resource Manager-Sperre
Weitere Informationen...
Sperren Sie alle Ihre Speicherkonten mit einer Azure Resource Manager-Sperre, um eine Löschung des Speicherkontos zu verhindern. Schützt das Speicherkonto vor Löschung oder Konfigurationsänderungen.

Schützt Container oder Blobs im Konto nicht vor dem Löschen oder Überschreiben.
Yes
Stellen Sie einen gelöschten Container innerhalb eines angegebenen Intervalls wieder her. Vorläufiges Löschen von Containern
Mehr erfahren...
Aktivieren Sie Soft Delete für Container für alle Speicherkonten, mit einem Mindestaufbewahrungszeitraum von sieben Tagen.

Aktivieren Sie Blob Soft Delete zum optimalen Schutz von Blobdaten.

Speichern Sie Container, die unterschiedliche Aufbewahrungszeiträume benötigen, in separaten Speicherkonten.
Ein gelöschter Container und dessen Inhalt können innerhalb der Aufbewahrungszeit wiederhergestellt werden.

Nur Operationen auf Containerebene (zum Beispiel Container löschen) können wiederhergestellt werden. Das vorläufige Löschen von Containern ermöglicht es Ihnen nicht, ein einzelnes Blob im Container wiederherzustellen, wenn es gelöscht wurde.
Yes
Stellen Sie ein gelöschtes Blob oder eine Blobversion innerhalb eines bestimmten Intervalls wieder her. Vorläufiges Löschen von Blobs
Mehr erfahren...
Aktivieren Sie Soft Delete für Blobs für alle Speicherkonten mit einer Mindestaufbewahrungsdauer von sieben Tagen.

Aktivieren Sie das vorläufige Löschen von Containern für den optimalen Schutz von Blob-Daten.

Speichern Sie Blobs, die unterschiedliche Aufbewahrungszeiträume benötigen, in separaten Speicherkonten.
Ein gelöschter Blob oder eine Blob-Version kann innerhalb der Aufbewahrungszeit wiederhergestellt werden. Ja
Speichern Sie den Zustand eines Blobs automatisch in einer früheren Version, wenn er überschrieben wird. Blobversionsverwaltung
Mehr erfahren...
Aktiviere die Blob-Versionierung, wenn du automatisch Überschreib- und Metadatenänderungen erfassen und frühere Versionen von Daten aufbewahren möchtest, bis sie explizit gelöscht werden. Um Kosten zu minimieren, verwenden Sie eine Lebenszyklusverwaltungs-Richtlinie oder eine Aufgabe für Speicheraktionen, um alte Versionen automatisch zu löschen.

Aktivieren Sie das vorläufige Löschen eines Blobs, um eine zusätzliche Schutzebene zu erhalten. Weitere Informationen...

Speichern Sie Blobdaten, die keine Versionsverwaltung benötigen, in einem separaten Konto, um die Kosten zu begrenzen.
Bei jedem Blobschreibvorgang wird eine neue Version erstellt. Wenn du einen Blob löschst, wird die aktuelle Version des Blobs zu einer vorherigen Version. Frühere Versionen bleiben bestehen, bis sie ausdrücklich gelöscht werden oder zur aktuellen Version erhoben werden können. Nein
Speichern Sie den Zustand eines Blobs zu einem bestimmten Zeitpunkt manuell. Momentaufnahme eines Blobs
Weitere Informationen...
Empfohlen für gezielte, zeitpunktbezogene Erfassungen oder als Alternative zur Blob-Versionierung bei Konten mit hierarchischem Namensraum, bei denen keine Versionierung verfügbar ist. Ein Blob kann aus einem Snapshot wiederhergestellt werden, wenn der Blob überschrieben wird. Wenn das Blob gelöscht wird, werden auch die Momentaufnahmen gelöscht.

Wenn das vorläufige Löschen eines Blobs aktiviert ist, führen Überschreibungen zur Erstellung von vorläufig gelöschten Momentaufnahmen.
Nein
Verhindern Sie, dass eine Blobversion für einen von Ihnen festgelegten Zeitraum gelöscht wird. Unveränderlichkeitspolitik für eine Blob-Version
Mehr erfahren...
Legen Sie eine Unveränderlichkeitsrichtlinie für eine einzelne Blobversion fest, um unternehmenskritische Dokumente zu schützen, z. B. um rechtliche oder gesetzliche Complianceanforderungen zu erfüllen. Schützt eine Blobversion vor dem Löschen und deren Metadaten vor dem Überschreiben. Bei einem Überschreibvorgang wird eine neue Version erstellt.

Wenn für mindestens einen Container Unveränderlichkeit auf Versionsebene aktiviert ist, ist auch das Speicherkonto vor dem Löschen geschützt. Das Löschen des Containers schlägt fehl, wenn mindestens ein Blob im Container vorhanden ist.
Nein
Verhindern Sie, dass ein Container und seine Blobs für ein von Ihnen festgelegtes Intervall gelöscht oder geändert werden. Unveränderlichkeitsrichtlinie für einen Container
Weitere Informationen...
Legen Sie eine Unveränderlichkeitsrichtlinie für einen Container fest, um unternehmenskritische Dokumente zu schützen, z. B. um rechtliche oder gesetzliche Complianceanforderungen zu erfüllen. Schützt einen Container und seine Blobs vor allen Lösch- und Überschreibvorgängen.

Wenn eine gesetzliche Aufbewahrungspflicht oder eine gesperrte zeitbasierte Aufbewahrungsrichtlinie in Kraft ist, ist das Speicherkonto ebenfalls vor dem Löschen geschützt. Container, für die keine Unveränderlichkeitsrichtlinie festgelegt wurde, sind vor dem Löschen nicht geschützt.
Ja
Stellen Sie einen Satz von Blockblobs zu einem früheren Zeitpunkt wieder her. Point-in-Time-Wiederherstellung
Mehr erfahren…
Wenn Sie die Zeitpunktwiederherstellung verwenden möchten, um zu einem früheren Zustand zurückzukehren, entwerfen Sie Ihre Anwendung so, dass sie anstelle von Containern einzelne Blockblobs löscht. Ein Satz von Blockblobs kann in den Zustand zu einem bestimmten Zeitpunkt in der Vergangenheit zurückversetzt werden.

Nur an Blockblobs vorgenommene Vorgänge werden rückgängig gemacht. Vorgänge, die an Containern, Seitenblobs oder Anfügeblobs durchgeführt wurden, werden nicht rückgängig gemacht.
Nein
Ein Blob kann gelöscht oder überschrieben werden, aber die Daten werden regelmäßig in ein zweites Speicherkonto kopiert. Tresorsicherungen für Azure-Blobs
Erfahren Sie mehr
Aktivieren Sie die Tresorsicherung, damit eine extern gespeicherte Kopie Ihrer Daten in einem Microsoft-Mandanten ohne direkten Zugriff gesichert wird. Bietet selektives Backup wichtiger Container und ermöglicht die Wiederherstellung einzelner Container in einem Speicherkonto, das sich vom Quellspeicherkonto unterscheidet. Ja

AzCopy und Azure Data Factory werden unterstützt.

Objektreplikation wird nicht unterstützt.
Blockblobs asynchron auf ein Zielkonto in einer anderen Region kopieren. Objektreplikation Erfahren Sie mehr... Aktivieren Sie die Objektreplikation, um eine redundante Kopie von Blockblobs in einer anderen Region beizubehalten, damit Ihre Daten verfügbar bleiben, falls die Quellregion nicht mehr verfügbar wird. Speichere Blockblobs, die eine Replikation in allgemeinen v2- oder Premium-Blockblob-Konten erfordern, da die Objektreplikation nur diese Kontotypen unterstützt. Blockblobs, die auf das Quellkonto geschrieben werden, werden gemäß der Replikationsrichtlinie asynchron auf das Zielkonto kopiert. Es werden nur Blockblobs repliziert; Append-Blobs und Page Blobs werden nicht unterstützt, und die Objektreplikation schützt nicht vor einer versehentlichen Löschung eines einzelnen Blobs innerhalb eines Kontos. Yes

Datenschutz nach Ressourcentyp

Die folgende Tabelle fasst die Azure Storage-Optionen zum Schutz von Daten nach den Ressourcen zusammen, die sie schützen.

Datenschutzoption Schützt ein Konto vor der Löschung Schützt einen Container vor der Löschung Schützt ein Objekt vor der Löschung Schützt ein Objekt vor Überschreibungen
Azure Resource Manager-Sperre Ja Nein Nein Nein
Vorläufiges Löschen von Containern Nein Ja Nein Nein
Soft Delete von Blobs Nein Nein Ja Ja
Blob-Versioning6 Nein Nein Ja Ja
Blob snapshot6 Nein No No Ja
Unveränderlichkeitsrichtlinie für eine Blob-Version Yes1 Ja2 Ja Ja3
Unveränderlichkeitsrichtlinie für einen Container Ja4 Ja Ja Ja
Wiederherstellung zu einem Zeitpunkt5 Nein Nein Ja Yes
Tresorsicherungen für Azure-Blobs Nein Yes Ja Yes
Objektreplikation7 Nein Yes Ja Ja
Eigene Roll-your-own-Lösung zum Kopieren von Daten auf ein zweites Konto6 Nein Yes Ja Ja

1 Speicherkontolöschung schlägt fehl, wenn mindestens ein Container mit aktiviertem unveränderlichen Speicher auf Versionsebene vorhanden ist.
2 Die Containerlöschung schlägt fehl, wenn sich mindestens ein Blob im Container befindet, unabhängig davon, ob die Richtlinie gesperrt oder entsperrt ist.
3 Das Überschreiben des Inhalts der aktuellen Version des Blobs erzeugt eine neue Version. Eine Unveränderlichkeitsrichtlinie schützt die Metadaten einer Version vor dem Überschreiben.
4 Während eine rechtliche Sperre oder eine gesperrte zeitbasierte Aufbewahrungsrichtlinie auf Containerebene gilt, ist das Speicherkonto auch vor Löschung geschützt.
5 Derzeit nicht für Data Lake Storage-Workloads unterstützt.
6 AzCopy und Azure Data Factory sind Optionen, die sowohl für Blob Storage als auch für Data Lake Storage Workloads unterstützt werden. Die Objektreplikation wird nur für Blob Storage-Workloads unterstützt.
7 Eine replizierte Kopie wird im Zielkonto gespeichert. Objektreplikation verhindert nicht, dass der Blob im Quellkonto gelöscht wird, und die Replikation ist asynchron, sodass aktuelle Schreibvorgänge möglicherweise noch nicht im Zielkonto vorhanden sind.

Datenwiederherstellungsmaßnahmen basierend auf Ressourcentyp

Sollten Sie Daten wiederherstellen müssen, die überschrieben oder gelöscht wurden, ist Ihre Vorgehensweise davon abhängig, welche Datensicherungsoptionen Sie aktiviert haben und welche Ressource betroffen war. In der folgenden Tabelle werden die Aktionen zur Wiederherstellung von Daten beschrieben.

Gelöschte oder überschriebene Ressource Mögliche Maßnahmen zur Wiederherstellung Anforderungen für die Wiederherstellung
Speicherkonto Versuch der Wiederherstellung des gelöschten Speicherkontos
Mehr erfahren...
Das Speicherkonto wurde ursprünglich mit dem Azure Resource Manager-Bereitstellungsmodell erstellt und wurde innerhalb der letzten 14 Tage gelöscht. Seit dem Löschen des ursprünglichen Speicherkontos wurde kein neues Konto mit demselben Namen erstellt.
Container Wiederherstellung des vorläufig gelöschten Containers und seiner Inhalte
Mehr erfahren…
Das vorläufige Löschen von Containern ist aktiviert, und der Aufbewahrungszeitraum für das vorläufige Löschen von Containern ist noch nicht abgelaufen.
Container und Blobs Wiederherstellung von Daten aus einem zweiten Speicherkonto Alle Container- und Blobvorgänge wurden effektiv auf ein zweites Speicherkonto repliziert.
Blob Wiederherstellung eines vorläufig gelöschten Blobs
Mehr erfahren...
Das vorläufige Löschen von Blobs ist aktiviert, und der Aufbewahrungszeitraum für das vorläufige Löschen ist noch nicht abgelaufen.
Sammlung von Block-Blobs Blockblobs auf den Stand eines früheren Zeitpunkts wiederherstellen1
Mehr erfahren...
Die Point-in-Time-Wiederherstellung ist aktiviert, und der Wiederherstellungspunkt liegt innerhalb des Aufbewahrungszeitraums. Das Speicherkonto wurde nicht kompromittiert oder beschädigt.
Momentaufnahme eines Blobs Wiederherstellung einer vorläufig gelöschten Momentaufnahme1
Mehr erfahren...
Das vorläufige Löschen für Blobs ist aktiviert, Sie haben den Blob überschrieben, wodurch eine vorläufig gelöschte Momentaufnahme erstellt wurde, und das Aufbewahrungsintervall für das vorläufige Löschen ist noch nicht abgelaufen. Oder, Blob Soft Delete wurde aktiviert, du hast einen Snapshot gelöscht und das Aufbewahrungsintervall für das vorläufige Löschen ist noch nicht abgelaufen.
Blob-Version Temporär gelöschte Version1 wiederherstellen
Mehr erfahren...
Das vorläufige Löschen von Blobs ist aktiviert, und der Aufbewahrungszeitraum für das vorläufige Löschen ist noch nicht abgelaufen.

1 Wird derzeit nicht für Data Lake Storage-Workloads unterstützt.

Zusammenfassung der Kostenaspekte

In der folgenden Tabelle werden die Kostenüberlegungen für die verschiedenen in diesem Leitfaden beschriebenen Optionen zum Schutz von Daten zusammengefasst. Für das Aktivieren oder Konfigurieren der folgenden Funktionen fallen keine Kosten an, aber bedenken Sie die Kosten, die ihr Verhalten verursacht.

Datenschutzoption Kostenaspekte
Azure Resource Manager-Sperre für ein Speicherkonto Keine Gebühren für die Konfiguration einer Sperre für ein Speicherkonto
Vorläufiges Löschen von Containern Daten in einem vorläufig gelöschten Container werden zum gleichen Tarif wie aktive Daten abgerechnet, bis der vorläufig gelöschte Container endgültig gelöscht wird.
Vorläufiges Löschen von Blobs Vorläufig gelöschte Blob-Daten werden mit dem gleichen Satz wie aktive Daten berechnet, bis sie dauerhaft gelöscht werden.

Sie werden nicht für die Transaktionen berechnet, die automatisch Snapshots oder Versionen generieren, wenn ein Blob überschrieben oder gelöscht wird, aber Sie werden für Aufrufe der Undelete Blob-Operation zum Schreib-Transaktions-Satz berechnet.

Das Aktivieren von Soft-Delete für häufig überschriebene Daten könnte die Kapazitätsgebühren und die Listenverzögerung erhöhen. Um die Auswirkungen einzuschätzen, empfiehlt Microsoft, mit einer Mindestaufbewahrungsfrist von sieben Tagen zu beginnen. Weitere Informationen finden Sie unter Preisgestaltung und Abrechnung.
Blobversionierung Nachdem du die Blob-Versionierung aktiviert hast, erzeugt jeder Schreibvorgang für ein Blob im Konto eine neue Version, was zu erhöhten Kapazitätskosten führen kann.

Du bezahlst für eine Blob-Version basierend auf einzigartigen Blöcken oder Seiten. Die Kosten steigen also, wenn das Basisblob von einer bestimmten Version abweicht. Die Änderung der Stufe eines Blobs oder einer Blob-Version könnte Auswirkungen auf die Abrechnung haben. Weitere Informationen finden Sie unter Preise und Abrechnung.

Nutzen Sie Lebenszyklusverwaltung oder Speicheraktionen, um ältere Versionen bei Bedarf zu löschen, um Kosten zu senken.
Blob-Snapshots Du bezahlst für Daten in einem Snapshot, basierend auf einzigartigen Blöcken oder Seiten. Die Kosten steigen also, wenn das Basisblob von der Momentaufnahme abweicht. Die Änderung der Stufe eines Blobs oder Snapshots könnte Auswirkungen auf die Abrechnung haben. Weitere Informationen finden Sie unter Preise und Abrechnung.

Nutzen Sie Lifecycle-Management oder Speicheraktionen, um ältere Snapshots bei Bedarf zu löschen und Kosten zu senken.
Richtlinie zur Unveränderlichkeit für eine Blob-Version Das Erstellen, Ändern oder Löschen einer zeitbasierten Aufbewahrungsrichtlinie oder einer rechtlichen Sperre für eine Blobversion führt zu einer Gebühr für Schreibtransaktionen.
Unveränderlichkeitsrichtlinie für einen Container Unveränderliche Daten werden zum gleichen Preis berechnet wie veränderliche Daten. Die Abrechnung bleibt bestehen, solange die Daten veränderbar sind und nicht gelöscht werden.
Point-in-Time-Wiederherstellung Die Aktivierung von Punkt-in-Zeit-Wiederherstellung ermöglicht außerdem Blob-Versionierung, Soft Delete und Change Feed, die jeweils weitere Gebühren verursachen können.

Die Point-in-Time-Wiederherstellung wird Ihnen in Rechnung gestellt, wenn Sie einen Wiederherstellungsvorgang durchführen. Die Kosten für einen Wiederherstellungsvorgang hängen von der Menge der wiederherzustellenden Daten ab. Weitere Informationen finden Sie unter Preise und Abrechnung.
Tresorsicherung Für die Tresorsicherung fallen Sicherungsspeichergebühren oder Instanzgebühren an sowie die quellseitigen Kosten (im Zusammenhang mit der Objektreplikation) für das gesicherte Quellkonto. Siehe Preise.
Objektreplikation Für die Konfiguration der Objektreplikation, einschließlich des Aktivierens von Change Feed und Blob-Versionierung sowie des Hinzufügens von Replikationsrichtlinien, fallen keine Kosten an. Die Objektreplikation erfordert Änderungsfeed und Versionierung, die jeweils weitere Gebühren verursachen können.

Die Pflege replizierter Daten im Zielkonto verursacht Kapazitätskosten, einschließlich der Speicherkosten des Blobs und jeder Blob-Version. Befindet sich das Zielkonto in einer anderen Region als das Quellkonto, entstehen auch Ausgangsgebühren bei der Replikation von Daten.

Objektreplikation verursacht Transaktionskosten: eine Schreib-Transaktionsgebühr für das Quellkonto sowie Lese- und Schreibtransaktionsgebühren für das Zielkonto, einschließlich der Kosten für das Lesen von Änderungsfeed-Datensätzen. Weitere Informationen finden Sie unter Abrechnung.
Daten in ein zweites Speicherkonto kopieren Die Verwaltung von Daten in einem zweiten Speicherkonto verursacht Kapazitäts- und Transaktionskosten. Wenn sich das zweite Speicherkonto in einer anderen Region als das Quellkonto befindet, fallen beim Kopieren von Daten auf dieses zweite Konto zusätzlich Gebühren für ausgehenden Datenverkehr an.

Nächste Schritte