WORM-Richtlinien (Write Once, Read Many) auf Containerebene für unveränderliche Blob-Daten
Die WORM-Richtlinie (Write Once, Read Many) auf Containerebene ist eine Art von Unveränderlichkeitsrichtlinie, die auf Containerebene 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
WORM-Richtlinien auf Containerebene (CLW) sind für alle neuen und vorhandenen Container verfügbar. Diese Richtlinien werden für Universell V2-, Premium-Blockblob-, Universell V1 (Legacy) und Blob Speicher (Legacy)-Konten unterstützt.
Tipp
Microsoft empfiehlt, für Konten vom Typ „Universell V1“ ein Upgrade auf „Universell V2“ durchzuführen, um von weiteren Features zu profitieren. Informationen zum Upgraden eines vorhandenen Kontos vom Typ „Universell v1“ finden Sie unter Durchführen eines Upgrades auf ein Speicherkonto vom Typ „Allgemein v2“.
Diese Funktion wird bei hierarchischen Namespacekonten unterstützt. Wenn der hierarchische Namespace aktiviert ist, können Sie Blobs nicht umbenennen oder verschieben, wenn sie sich im unveränderlichen Zustand befinden. Sowohl der Blobname als auch die Verzeichnisstruktur liefern wichtige Daten auf Containerebene, die nicht mehr geändert werden können, sobald die unveränderliche Richtlinie in Kraft ist.
Für diese Funktion gibt es keinen Aktivierungsprozess; er ist automatisch für alle Container verfügbar. Weitere Informationen zum Festlegen einer Richtlinie für einen neuen oder vorhandenen Container finden Sie unter Konfigurieren von WORM-Unveränderlichkeitsrichtlinien auf Containerebene.
Löschen
Ein Container mit einem WORM-Richtliniensatz auf Containerebene muss leer sein, bevor der Container gelöscht werden kann. Wenn ein Richtliniensatz für einen Container mit aktiviertem hierarchischen Namespace aktiviert ist, muss ein Verzeichnis leer sein, bevor es gelöscht werden kann.
Szenarien
| Szenario | Unzulässige Vorgänge | Blobschutz | Containerschutz | Kontoschutz |
|---|---|---|---|---|
| Ein Container wird durch eine aktive zeitbasierte Aufbewahrungsrichtlinie mit Geltungsbereich auf Containerebene geschützt, und/oder eine Richtlinie zur Aufbewahrung für juristische Zwecke ist in Kraft | Delete Blob, Put Blob1, Set Blob Metadata, Put Page, Set Blob Properties, Snapshot Blob, Incremental Copy Blob, Append Block2 | Alle Blobs im Container sind für Inhalte und Benutzermetadaten unveränderlich. | Beim Löschen eines Containers tritt ein Fehler auf, wenn eine WORM-Richtlinie auf Containerebene wirksam ist. | Beim Löschen eines Speicherkontos tritt ein Fehler auf, wenn ein Container mit mindestens einem Blob vorhanden ist. |
| Ein Container wird durch eine abgelaufene zeitbasierte Aufbewahrungsrichtlinie mit Geltungsbereich auf Containerebene geschützt, und es ist keine Richtlinie zur Aufbewahrung für juristische Zwecke in Kraft | Put Blob1, Set Blob Metadata, Put Page, Set Blob Properties, Snapshot Blob, Incremental Copy Blob, Append Block2 | Löschvorgänge sind zulässig. Überschreibungsvorgänge sind nicht zulässig. | 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 eines Speicherkontos tritt ein Fehler auf, wenn mindestens ein Container vorhanden ist, der eine gesperrte zeitbasierte Aufbewahrungsrichtlinie aufweist. Entsperrte Richtlinien bieten keinen Schutz vor Löschvorgängen. |
1 Bei Azure Storage ist der Vorgang Put Blob zum Erstellen eines neuen Blobs zulässig. Nachfolgende Überschreibungsvorgänge für einen vorhandenen Blobpfad eines unveränderlichen Containers sind nicht zulässig.
2 Der Vorgang Append Block ist nur für Richtlinien zulässig, bei denen die Eigenschaft allowProtectedAppendWrites oder allowProtectedAppendWritesAll aktiviert wurde.
Zulassen von Schreibvorgängen in geschützten Anfügeblobs
Anfügeblobs bestehen aus Datenblöcken und sind für Vorgänge zum Anfügen von Daten optimiert, die in Überprüfungs- und Protokollierungsszenarien erforderlich sind. Bei Anfügeblobs können neue Blöcke entwurfsbedingt nur am Ende des Blobs hinzugefügt werden. Unabhängig von der Unveränderlichkeit ist das Ändern oder Löschen vorhandener Blöcke in einem Anfügeblob grundsätzlich nicht zulässig. Weitere Informationen zu Anfügeblobs finden Sie unter Informationen zu Anfügeblobs.
Die Eigenschaftseinstellung allowProtectedAppendWrites ermöglicht das Schreiben von neuen Blöcken in ein Anfügeblob unter Aufrechterhaltung von Unveränderlichkeitsschutz und Konformität. Wenn diese Einstellung aktiviert ist, können Sie ein Anfügeblob direkt in dem durch Richtlinien geschützten Container erstellen und über den Vorgang „Append Block“ weitere neue Datenblöcke am Ende des Anfügeblobs hinzufügen. Es können nur neue Blöcke hinzugefügt werden; vorhandene Blöcke können nicht geändert oder gelöscht werden. Das Aktivieren dieser Einstellung wirkt sich nicht auf das Unveränderlichkeitsverhalten von Blockblobs oder Seitenblobs aus.
Die Eigenschaftseinstellung AllowProtectedAppendWritesAll bietet dieselben Berechtigungen wie die Eigenschaft allowProtectedAppendWrites und fügt die Möglichkeit hinzu, neue Blöcke in ein Blockblob zu schreiben. Die Blob Storage-API bietet keine Möglichkeit, dies für Anwendungen direkt zu erledigen. Anwendungen können dies jedoch mithilfe von Anfüge- und Flushmethoden (Leerung) erreichen, die in der Data Lake Storage Gen2-API verfügbar sind. Außerdem ermöglicht diese Eigenschaft Microsoft-Anwendungen wie Azure Data Factory das Anfügen von Datenblöcken mithilfe interner APIs. Sollten Ihre Workloads von einem dieser Tools abhängig sein, können Sie mithilfe dieser Eigenschaft Fehler vermeiden, die angezeigt werden können, wenn die Tools Daten an Blobs anzufügen versuchen.
Anfügeblobs bleiben während des effektiven Aufbewahrungszeitraums im unveränderlichen Zustand. Weil neue Daten auch nach der anfänglichen Erstellung des Anfügeblobs angefügt werden können, gibt es bei der Festlegung des Aufbewahrungszeitraums einen geringfügigen Unterschied. Die Gültigkeit des Aufbewahrungszeitraums entspricht der Differenz zwischen dem Zeitpunkt der letzten Änderung des Blobs und dem vom Benutzer angegebenen Aufbewahrungszeitraum. Entsprechend wird beim Verlängern des Aufbewahrungszeitraums für den unveränderlichen Speicher der letzte Wert des vom Benutzer angegebenen Aufbewahrungszeitraums verwendet, um den effektiven Aufbewahrungszeitraum zu berechnen.
Ein Beispiel: Angenommen, ein Benutzer erstellt eine zeitbasierte Aufbewahrungsrichtlinie mit aktivierter allowProtectedAppendWrites-Eigenschaft und einem Aufbewahrungszeitraum von 90 Tagen. Ein Anfügeblob (logblob1) wird am aktuellen Datum im Container erstellt. Dem Anfügeblob werden während der nächsten 10 Tage weiterhin neue Protokolle hinzugefügt. Der effektive Aufbewahrungszeitraum für logblob1 beträgt also 100 Tage ab dem aktuellen Datum (Zeitpunkt der letzten Anfügung + 90 Tage).
Bei entsperrten zeitbasierten Aufbewahrungsrichtlinien können die Eigenschaftseinstellungen allowProtectedAppendWrites und AllowProtectedAppendWritesAll zu jedem beliebigen Zeitpunkt aktiviert und deaktiviert werden. Sobald die zeitbasierte Aufbewahrungsrichtlinie gesperrt wurde, können die Eigenschaftseinstellungen allowProtectedAppendWrites und allowProtectedAppendWritesAll nicht mehr geändert werden.
Grenzwerte
Ein Speicherkonto kann über maximal 10.000 Container mit einer Unveränderlichkeitsrichtlinie (zeitbasierte Aufbewahrung oder gesetzliche Aufbewahrungspflicht) verfügen.
Ein Container kann zu jeder Zeit über maximal zehn Tags für die gesetzliche Aufbewahrungspflicht verfügen.
Ein Tag für die Aufbewahrung für juristische Zwecke muss mindestens drei alphanumerische Zeichen lang sein. Die Höchstlänge beträgt 23 alphanumerische Zeichen.
Für einen Container werden höchstens zehn Richtlinien-Überwachungsprotokolle für die gesetzliche Aufbewahrungspflicht für die Dauer der Richtlinie aufbewahrt.