WORM-Richtlinien (Write Once, Read Many) auf Versionsebene für unveränderliche Blob-Daten

Eine WORM-Richtlinie (Write Once, Read Many) auf Versionsebene ist eine Art von Unveränderbarkeitsrichtlinie, die auf Konto-, Container- oder Versionsebene festgelegt werden kann. Weitere Informationen über unveränderlichen Speicher für Azure Blob Storage finden Sie unter Speichern geschäftskritischer Blob-Daten mit unveränderlichem Speicher in einem WORM-Status (Write Once, Read Many).

Verfügbarkeit

Richtlinien zur Unveränderbarkeit auf Versionsebene (VLW) werden auf Kontoebene für neue Konten und auf Container- und Blobebene für neue und bestehende Konten/Container unterstützt. Diese Richtlinien werden sowohl für Universal v2 als auch für Premium-Blockblob-Konten unterstützt. Diese Funktion wird bei hierarchischen Namespacekonten nicht unterstützt.

Versionsabhängigkeit

Für Aufbewahrungsrichtlinien auf Versionsebene muss die Blobversionsverwaltung für das Speicherkonto aktiviert werden. Informationen zum Aktivieren der Blobversionsverwaltung finden Sie unter Aktivieren und Verwalten der Blobversionsverwaltung (Vorschau). Beachten Sie, dass die Aktivierung der Versionsverwaltung sich auf die Abrechnung auswirken kann. Weitere Informationen finden Sie im Abschnitt Preise und Abrechnung für die Blobversionsverwaltung.

Wenn Sie nach der Aktivierung der Versionsverwaltung erstmalig ein Blob hochladen, wird diese Version des Blob zur aktuellen Version. Bei jeder Überschreibung des Blobs wird eine neue Version erstellt, mit der der vorherige Zustand des Blobs gespeichert wird. Wenn Sie die aktuelle Version eines Blobs löschen, wird sie zu einer vorherigen Version und beibehalten, bis sie explizit gelöscht wird. Eine vorherige Blobversion beinhaltet die zeitbasierte Aufbewahrungsrichtlinie, die zu dem Zeitpunkt gültig war, zu dem die aktuelle Version zu einer vorherigen Version wurde.

Wenn eine Standardrichtlinie für das Speicherkonto oder den Container gültig ist und dann durch eine Überschreibung eine vorherige Version erstellt wird, erbt die neue aktuelle Version die Standardrichtlinie für das Konto oder den Container.

Für jede Version kann nur eine zeitbasierte Aufbewahrungsrichtlinie konfiguriert werden. Für eine Version kann auch eine gesetzliche Aufbewahrungspflicht konfiguriert werden.

Informationen zum Konfigurieren von zeitbasierten Aufbewahrungsrichtlinien auf Versionsebene finden Sie unter Konfigurieren von Unveränderlichkeitsrichtlinien für Blobversionen.

Aktivieren und Richtlinieneinstellung

Die Verwendung unveränderlicher Richtlinien mit WORM auf Versionsebene ist ein zweistufiger Prozess. Aktivieren Sie zuerst die Unveränderlichkeit auf Versionsebene. Anschließend können Sie Richtlinien für die Unveränderlichkeit auf Versionsebene festlegen.

Um eine Richtlinie auf der Ebene des Speicherkontos festzulegen, müssen Sie zunächst WORM auf Versionsebene für das Speicherkonto aktivieren. Sie können dies nur bei der Kontoerstellung tun. Es gibt keine Möglichkeit, WORM auf Versionsniveau für bereits bestehende Konten zu aktivieren.

Abbildung zum Festlegen einer Richtlinie für unveränderliche Speicherung auf Versionsniveau auf Kontoebene.

Um eine Richtlinie auf Containerebene festzulegen, müssen Sie zunächst WORM auf Versionsebene entweder für das Konto ODER für den Container aktivieren.

Wenn Sie WORM auf Versionsebene für einen Container aktivieren möchten, empfiehlt Microsoft, dass Sie es bei der Erstellung des Containers aktivieren. Sie können jedoch einen nicht auf Versionsebene aktivierten WORM-Container in einen auf Versionsebene aktivierten WORM-Container migrieren. Wenn Sie sich dafür entscheiden, einen Container nicht zu migrieren, können Sie immer noch eine WORM-Richtlinie auf Containerebene für diesen Container festlegen, aber die Option, Richtlinien auf Blobebene festzulegen, ist für diesen Container nicht verfügbar.

Abbildung zum Festlegung einer Richtlinie für die unveränderliche Speicherung auf Versionsebene auf Containerebene.

Um eine Richtlinie auf Blobebene festzulegen, müssen Sie WORM auf Versionsebene entweder für das Konto oder den Container aktivieren. Es gibt keine Möglichkeit, WORM auf Versionsebene auf Blobebene zu aktivieren; es muss vererbt werden.

Abbildung zur Festlegung einer Richtlinie für die unveränderliche Speicherung auf Versionsebene auf Blobebene.

Migration

Für vorhandene Container kann die Unveränderlichkeit auf Versionsebene aktiviert werden, jedoch muss zuvor eine Migration durchgeführt werden. Dieser Vorgang kann eine Weile dauern. Einmal aktiviert, kann die WORM-Unterstützung für diesen Container nicht mehr entfernt werden. Sie können 10 Container gleichzeitig pro Speicherkonto migrieren. Weitere Informationen zum Migrieren eines Containers zur Unterstützung der Unveränderlichkeit auf Versionsebene finden Sie unter Migrieren eines vorhandenen Containers zur Unterstützung der Unveränderlichkeit auf Versionsebene.

Konfigurieren einer Richtlinie für die aktuelle Version

Nachdem Sie die Unterstützung der Unveränderlichkeit auf Versionsebene für ein Speicherkonto oder einen Container aktiviert haben, haben Sie die Möglichkeit, eine zeitbasierte Standardaufbewahrungsrichtlinie für das Konto oder den Container zu konfigurieren. Wenn Sie eine zeitbasierte Standardaufbewahrungsrichtlinie für das Konto oder den Container konfigurieren und dann ein Blob hochladen, erbt das Blob diese Standardrichtlinie. Außerdem können Sie die Standardrichtlinie für jedes Blob überschreiben, indem Sie eine benutzerdefinierte Richtlinie für das entsprechende Blob konfigurieren.

Wenn die zeitbasierte Standardaufbewahrungsrichtlinie für das Konto oder den Container entsperrt ist, beinhaltet auch die aktuelle Version eines Blobs, das die Standardrichtlinie erbt, eine entsperrte Richtlinie. Nach dem Hochladen eines einzelnen Blobs können Sie den Aufbewahrungszeitraum für die Richtlinie für die aktuelle Version des Blobs verkürzen oder verlängern oder die aktuelle Version löschen. Außerdem können Sie die Richtlinie für die aktuelle Version sperren, selbst wenn die Standardrichtlinie für das Konto den Container entsperrt bleibt.

Wenn die zeitbasierte Standardaufbewahrungsrichtlinie für das Konto oder den Container gesperrt ist, enthält auch die aktuelle Version eines Blobs, das diese Richtlinie erbt, eine gesperrte Richtlinie. Wenn Sie jedoch die Standardrichtlinie beim Hochladen eines Blobs überschreiben und nur eine Richtlinie für das Blob festlegen, bleibt die Richtlinie des Blobs entsperrt, bis Sie sie explizit sperren. Wenn die Richtlinie für die aktuelle Version gesperrt ist, können Sie den Aufbewahrungszeitraum verlängern, aber weder die Richtlinie löschen noch den Aufbewahrungszeitrum verkürzen.

Wenn für das Speicherkonto oder den Container keine Standardrichtlinie konfiguriert wurde, können Sie ein Blob entweder mit einer benutzerdefinierten Richtlinie oder ohne Richtlinie hochladen.

Wenn die Standardrichtlinie für ein Speicherkonto oder einen Container geändert wird, bleiben Richtlinien für Objekte innerhalb des Containers unverändert, auch wenn die Richtlinien von der Standardrichtlinie geerbt wurden.

In der Tabelle unten sind die verschiedenen verfügbaren Optionen zum Festlegen einer zeitbasierten Aufbewahrungsrichtlinie für ein Blob beim Hochladen aufgeführt:

Standardrichtlinienstatus für Konto oder Container Hochladen eines Blobs mit der Standardrichtlinie Hochladen eines Blobs mit einer benutzerdefinierten Richtlinie Hochladen eines Blobs ohne Richtlinie
Standardrichtlinie für Konto oder Container (entsperrt) Blob wird mit entsperrter Standardrichtlinie hochgeladen Blob wird mit entsperrter benutzerdefinierter Richtlinie hochgeladen Blob wird ohne Richtlinie hochgeladen
Standardrichtlinie für Konto oder Container (gesperrt) Blob wird mit gesperrter Standardrichtlinie hochgeladen Blob wird mit entsperrter benutzerdefinierter Richtlinie hochgeladen Blob wird ohne Richtlinie hochgeladen
Keine Standardrichtlinie für ein Konto oder einen Container Blob wird mit entsperrter benutzerdefinierter Richtlinie hochgeladen Blob wird ohne Richtlinie hochgeladen

Konfigurieren einer Richtlinie für eine vorherige Version

Bei aktivierter Versionsverwaltung wird mit einem Schreib- oder Löschvorgang für ein Blob eine neue vorherige Version des Blobs erstellt, mit der auch der Zustand des Blobs vor dem Vorgang gespeichert wird. Standardmäßig beinhaltet eine vorherige Version die zeitbasierte Aufbewahrungsrichtlinie, die gegebenenfalls für die aktuelle Version zu dem Zeitpunkt gültig war, zu dem die aktuelle Version zu einer vorherigen Version wurde. Die neue aktuelle Version erbt die Richtlinie für den Container, wenn es eine gibt.

Wenn die von einer vorherigen Version geerbte Richtlinie entsperrt ist, kann der Aufbewahrungszeitraum verkürzt oder verlängert oder die Richtlinie gelöscht werden. Die Richtlinie für eine vorherige Version kann für diese Version auch gesperrt werden, selbst wenn die Richtlinie für die aktuelle Version entsperrt ist.

Wenn die von einer vorherigen Version geerbte Richtlinie gesperrt ist, kann der Aufbewahrungszeitraum verlängert werden. Die Richtlinie kann weder gelöscht noch kann der Aufbewahrungszeitraum verkürzt werden. Wenn für die aktuelle Version keine Richtlinie konfiguriert wurde, erbt die vorherige Version keine Richtlinie.

Sie können eine benutzerdefinierte Richtlinie für die Version konfigurieren. Wenn die Richtlinie für eine aktuelle Version geändert wird, bleiben die Richtlinien für vorhandene vorherige Versionen unverändert, auch wenn die Richtlinie von einer aktuellen Version geerbt wurde.

Löschen

Sobald ein Konto oder ein Container für eine unveränderliche Richtlinie aktiviert ist, kann es/er nicht mehr gelöscht werden, bis es/er leer ist. Wichtig ist, dass es keine Rolle spielt, ob eine unveränderliche Richtlinie für ein WORM-Konto oder einen Container auf Versionsebene festgelegt wurde, sondern ob sie für eine Richtlinie aktiviert ist. Sobald dies der Fall ist, muss das Konto oder der Container leer sein, um gelöscht zu werden.

Abbildung der Reihenfolge der Vorgänge beim Löschen eines Kontos mit einer Unveränderbarkeitsrichtlinie auf Versionsebene.

Szenarien

Szenario Unzulässige Vorgänge Blobschutz Containerschutz Kontoschutz
Eine Blobversion wird durch eine aktive Aufbewahrungsrichtlinie und/oder eine Richtlinie zur Aufbewahrung für juristische Zwecke geschützt Delete Blob, Set Blob Metadata, und Put Page Die Blobversion kann nicht gelöscht werden. Benutzermetadaten können nicht geschrieben werden.
Beim Überschreiben eines Blobs mit Put Blob, Put Block List oder Copy Blob wird eine neue Version erstellt1.
Beim Löschen des Containers tritt ein Fehler auf, wenn mindestens ein Blob im Container vorhanden ist (unabhängig davon, ob die Richtlinie gesperrt ist oder nicht). Beim Löschen des Speicherkontos tritt ein Fehler auf, wenn mindestens ein Container mit aktiviertem unveränderlichen Speicher auf Versionsebene vorhanden ist oder wenn unveränderlicher Speicher für das Konto aktiviert ist.
Eine Blobversion wird durch eine abgelaufene Aufbewahrungsrichtlinie geschützt, und es ist keine Richtlinie zur Aufbewahrung für juristische Zwecke in Kraft Set Blob Metadata und Put Page Eine Blobversion wird durch eine abgelaufene Aufbewahrungsrichtlinie geschützt, und es ist keine Richtlinie zur Aufbewahrung für juristische Zwecke in Kraft Die Blobversion kann gelöscht werden.
Beim Überschreiben eines Blobs mit Put Blob, Put Block List oder Copy Blob wird eine neue Version erstellt1.
Beim Löschen eines Speicherkontos tritt ein Fehler auf, wenn mindestens ein Container vorhanden ist, der eine Blobversion mit einer gesperrten zeitbasierten Aufbewahrungsrichtlinie aufweist.
Entsperrte Richtlinien bieten keinen Schutz vor Löschvorgängen.

1 Blobversionen sind für Inhalte immer unveränderlich. Wenn die Versionsverwaltung für das Speicherkonto aktiviert ist, wird durch einen Schreibvorgang in einen Blockblob eine neue Version erstellt. Die einzige Ausnahme ist der Vorgang Put Block.

Grenzwerte

In einem Konto können maximal 10.000 Container mit eindeutigen zeitbasierten Aufbewahrungsrichtlinien eingerichtet werden. Sie können jedoch eine Richtlinie auf Kontoebene festlegen, die von mehr als 10.000 Containern geerbt wird.

Nächste Schritte