Speichern Sie geschäftskritische Blobdaten mit unveränderlichem Speicher in einem WORM-Status (Write Once, Read Many).
Unveränderlicher Speicher für Azure Blob Storage ermöglicht es Benutzern, unternehmenskritische Daten im WORM-Zustand (Write Once, Read Many) zu speichern. Im WORM-Zustand können Daten für ein vom Benutzer angegebenes Intervall weder geändert noch gelöscht werden. Durch Konfigurieren von Unveränderlichkeitsrichtlinien für Blobdaten können Sie Ihre Daten vor Überschreibungen und Löschungen schützen.
Unveränderlicher Speicher für Azure Blob Storage unterstützt zwei Arten von Unveränderlichkeitsrichtlinien:
Zeitbasierte Aufbewahrungsrichtlinien: Mit einer zeitbasierten Aufbewahrungsrichtlinie können Benutzer Richtlinien zum Speichern von Daten für ein angegebenes Intervall festlegen. Wenn eine zeitbasierte Aufbewahrungsrichtlinie festgelegt wird, können Objekte erstellt und gelesen, aber nicht geändert oder gelöscht werden. Nach Ablauf des Aufbewahrungszeitraums können Objekte gelöscht, aber nicht überschrieben werden.
Richtlinien zur Aufbewahrung für juristische Zwecke: Ist die Aufbewahrung für juristische Zwecke festgelegt, werden unveränderliche Daten so lange gespeichert, bis die Richtlinie explizit gelöscht wird. Wenn eine Richtlinie zur Aufbewahrung für juristische Zwecke definiert ist, können Objekte erstellt und gelesen, aber nicht geändert oder gelöscht werden.
Diese Richtlinien können gleichzeitig festgelegt werden. Eine Benutzerin oder ein Benutzer kann z. B. sowohl eine zeitbasierte Aufbewahrungsrichtlinie als auch eine gesetzliche Aufbewahrungspflicht auf derselben Ebene und zur selben Zeit festgelegt haben. Damit ein Schreibvorgang erfolgreich durchgeführt werden kann, muss entweder die Versionierung aktiviert sein oder die Daten müssen weder einer gesetzliche Aufbewahrungspflicht noch einer zeitlichen Aufbewahrungsrichtlinie unterliegen. Damit eine Löschung erfolgreich ist, dürfen die Daten außerdem nicht einer gesetzliche Aufbewahrungspflicht oder zeitlichen Aufbewahrungsrichtlinie unterliegen.
Das folgende Diagramm zeigt, wie zeitbasierte Aufbewahrungsrichtlinien und gesetzliche Aufbewahrungspflichten Schreib-und Löschvorgänge verhindern, solange sie in Kraft sind.
Es gibt zwei Funktionen unter dem Oberbegriff der unveränderlichen Speicherung: WORM auf Containerebene und WORM auf Versionsebene. WORM auf Containerebene erlaubt es, Richtlinien nur auf Containerebene festzulegen, während WORM auf Versionsebene erlaubt, Richtlinien auf Konto-, Container- oder Versionsebene festzulegen.
Informationen zu unveränderlichem Speicher für Blobs
Unveränderlicher Speicher unterstützt Organisationen aus dem Gesundheitswesen, Finanzwesen und verwandten Branchen – insbesondere Broker-Dealer-Organisationen – dabei, Daten sicher zu speichern. Darüber hinaus kann unveränderlicher Speicher in allen Szenarien verwendet werden, in denen kritische Daten vor Änderung oder Löschung geschützt werden sollen.
Beispiele für typische Anwendungen:
Einhaltung gesetzlicher Bestimmungen: Unveränderlicher Speicher für Azure-Blobspeicher unterstützt Organisationen dabei, SEC 17a-4(f), CFTC 1.31(d), FINRA und andere Bestimmungen einzuhalten.
Sichere Dokumentaufbewahrung: Mit unveränderlichem Speicher für Blobs wird sichergestellt, dass Daten selbst dann nicht von Benutzern geändert oder gelöscht werden können, wenn diese über Administratorrechte für ein Konto verfügen.
Aufbewahrung für juristische Zwecke: Mit unveränderlichem Speicher für Blobs können Benutzer vertrauliche Informationen, die für Rechtsstreitigkeiten oder die geschäftliche Nutzung wichtig sind, für den gewünschten Zeitraum in einem manipulationsgeschützten Zustand speichern, bis die Aufbewahrungspflicht nicht mehr gilt. Dieses Feature ist nicht allein auf rechtliche Anwendungsfälle beschränkt, sondern kann auch als ereignisbasierter Aufbewahrungsvorgang oder Unternehmenssperre angesehen werden, wenn Daten basierend auf Ereignisauslösern oder Unternehmensrichtlinien geschützt werden müssen.
Compliance
Microsoft hat Cohasset Associates, ein führendes, auf Datensatzverwaltung und Information Governance spezialisiertes Unternehmen für unabhängige Bewertungen, damit beauftragt, unveränderlichen Speicher für Blobs und dessen Konformität mit den spezifischen Anforderungen der Finanzdienstleistungsbranche zu bewerten. Cohasset hat bestätigt, dass die Verwendung von unveränderlichem Speicher für Blobs im WORM-Zustand die relevanten Speicheranforderungen der CFTC-Regel 1.31(c)-(d), der FINRA-Regel 4511 und der SEC-Regel 17a-4(f) erfüllt. Microsoft hat die Einhaltung dieser Regeln angestrebt, da sie die weltweit striktesten Richtlinien zur Aufbewahrung von Datensätzen für Finanzinstitute darstellen.
Der Cohasset-Bericht ist im Microsoft Service Trust Center verfügbar. Ausführliche Informationen zu den Compliancezertifizierungen von Microsoft finden Sie im Azure Trust Center. Wenden Sie sich an den Azure-Support, um einen Nachweis der WORM-Unveränderlichkeitskonformität von Microsoft anzufordern.
Zeitbasierte Aufbewahrungsrichtlinien
Über eine zeitbasierte Aufbewahrungsrichtlinie werden Blobdaten im WORM-Format für einen festgelegten Zeitraum gespeichert. Wenn eine zeitbasierte Aufbewahrungsrichtlinie festgelegt wurde, können Clients Blobs erstellen und lesen, sie aber nicht ändern oder löschen. Nach Ablauf des Aufbewahrungszeitraums können Blobs gelöscht, jedoch nicht überschrieben werden.
Bereich
Eine zeitbasierte Aufbewahrungsrichtlinie kann in den folgenden Bereichen konfiguriert werden:
- WORM-Richtlinie auf Versionsebene: Eine zeitbasierte Aufbewahrungsrichtlinie kann auf Konto-, Container- oder Versionsebene konfiguriert werden. Wenn sie auf Konto- oder Containerebene konfiguriert ist, wird sie an alle Blobs in dem jeweiligen Konto oder Container vererbt. Wenn ein Container für juristische Zwecke aufbewahrt werden muss, kann WORM auf Versionsebene nicht für denselben Container erstellt werden. Dies liegt daran, dass die Versionen aufgrund der Aufbewahrung für juristische Zwecke nicht generiert werden können.
- WORM-Richtlinie auf Containerebene: eine zeitbasierte Aufbewahrungsrichtlinie, die auf Containerebene konfiguriert wird und für alle Objekte im entsprechenden Container gilt. Einzelne Blobs können nicht mit ihren eigenen Unveränderlichkeitsrichtlinien konfiguriert werden.
Aufbewahrungszeitraum für eine zeitbasierte Richtlinie
Der kürzeste Aufbewahrungszeitraum für eine zeitbasierte Aufbewahrungsrichtlinie liegt bei einem Tag und der längste bei 146.000 Tagen (400 Jahre). Wenn Sie eine zeitbasierte Aufbewahrungsrichtlinie konfigurieren, bleiben die betroffenen Objekte während des effektiven Aufbewahrungszeitraums im unveränderlichen Zustand. Die Gültigkeit des Aufbewahrungszeitraums für Objekte entspricht der Differenz zwischen der Erstellungszeit des Blobs und dem vom Benutzer angegebenen Aufbewahrungszeitraum. Da der Aufbewahrungszeitraum einer Richtlinie verlängert werden kann, wird für den unveränderlichen Speicher der letzte Wert des vom Benutzer angegebenen Aufbewahrungszeitraums verwendet, um den effektiven Aufbewahrungszeitraum zu berechnen.
Ein Beispiel: Angenommen, der Benutzer erstellt eine zeitbasierte Aufbewahrungsrichtlinie mit einem Aufbewahrungszeitraum von fünf Jahren. Ein in diesem Container vorhandenes Blob (testblob1) wurde vor einem Jahr erstellt. Der effektive Aufbewahrungszeitraum für testblob1 beträgt also vier Jahre. Wenn ein neues Blob (testblob2) in den Container hochgeladen wird, beträgt der effektive Aufbewahrungszeitraum für testblob2 fünf Jahre ab dem Zeitpunkt seiner Erstellung.
Gesperrte und entsperrte Richtlinien
Wenn Sie erstmals eine zeitbasierte Aufbewahrungsrichtlinie konfigurieren, wird die Richtlinie zu Testzwecken entsperrt. Nach Abschluss der Tests können Sie die Richtlinie sperren, damit sie mit SEC 17a-4(f) und anderen gesetzlichen Bestimmungen vollständig konform ist.
Gesperrte und entsperrte Richtlinien schützen vor Lösch- und Überschreibvorgängen. Sie können eine entsperrte Richtlinie jedoch ändern, indem Sie den Aufbewahrungszeitraum verkürzen oder verlängern. Außerdem können Sie eine entsperrte Richtlinie löschen. Sie können eine gesperrte zeitbasierte Aufbewahrungsrichtlinie nicht löschen. Sie können den Aufbewahrungszeitraum verlängern, ihn aber nicht verkürzen. Maximal fünf Verlängerungen des effektiven Aufbewahrungszeitraums sind während der Lebensdauer einer gesperrten Richtlinie zulässig, die auf Containerebene definiert ist. Bei einer Richtlinie, die für eine Blobversion konfiguriert wurde, ist die Anzahl der Verlängerungen des effektiven Zeitraums nicht begrenzt.
Wichtig
Eine zeitbasierte Aufbewahrungsrichtlinie muss gesperrt sein, damit das Blob zur Erzielung von Konformität mit SEC 17a-4(f) und anderen gesetzlichen Bestimmungen in einem konformen unveränderlichen Zustand ist (Schreib- und Löschschutz). Microsoft empfiehlt, die Richtlinie in einem angemessenen Zeitraum zu sperren (in der Regel weniger als 24 Stunden). Der Zustand „Entsperrt“ bietet zwar Unveränderlichkeitsschutz, allerdings wird die Verwendung des Zustands „Entsperrt“ nicht für andere Zwecke als für kurzfristige Tests empfohlen.
Überwachungsprotokollierung für Aufbewahrungsrichtlinien
Jeder Container mit aktivierter zeitbasierter Aufbewahrungsrichtlinie umfasst ein Richtlinienüberwachungsprotokoll. Das Überwachungsprotokoll enthält bis zu sieben zeitbasierte Aufbewahrungsbefehle für gesperrte zeitbasierte Aufbewahrungsrichtlinien. Die Protokollierung beginnt in der Regel, nachdem Sie die Richtlinie gesperrt haben. Protokolleinträge enthalten Benutzer-ID, Befehlstyp, Zeitstempel und Aufbewahrungszeitraum. Das Überwachungsprotokoll wird für die Lebensdauer der Richtlinie gemäß den Richtlinien der Verordnung SEC 17a-4(f) aufbewahrt.
Das Azure-Aktivitätsprotokoll ist ein umfassenderes Protokoll mit allen Verwaltungsdienstaktivitäten. Azure-Ressourcenprotokolle enthalten Informationen zu Datenvorgängen. Der Benutzer ist für die dauerhafte Speicherung dieser Protokolle verantwortlich, die aus gesetzlichen oder anderen Gründen ggf. erforderlich ist.
Änderungen an zeitbasierten Aufbewahrungsrichtlinien auf Versionsebene werden nicht überwacht.
Gesetzliche Aufbewahrungspflichten
Eine Aufbewahrung für juristische Zwecke ist eine vorübergehende Unveränderlichkeitsrichtlinie, die für juristische Untersuchungszwecke oder allgemeine Schutzrichtlinien angewendet werden kann. Eine Aufbewahrung für juristische Zwecke speichert Blobdaten in einem WORM-Format (Write-Once, Read-Many), bis die gesetzliche Aufbewahrungspflicht explizit gelöscht werden. Wenn ein Zeitraum für die Aufbewahrung für juristische Zwecke festgelegt wird, können Blobs erstellt und gelesen, aber nicht geändert oder gelöscht werden. Verwenden Sie eine Aufbewahrung für juristische Zwecke, wenn der Zeitraum, in dem die Daten in einem WORM-Zustand aufbewahrt werden müssen, unbekannt ist.
Bereich
Eine Aufbewahrung für juristische Zwecke kann in einem der folgenden Bereiche konfiguriert werden:
WORM-Richtlinie auf Versionsebene: Eine gesetzliche Aufbewahrungspflicht kann auf der Ebene einer einzelnen Blobversion konfiguriert werden, um sensible Daten präzise zu verwalten.
WORM-Richtlinie auf Containerebene: Eine gesetzliche Aufbewahrungspflicht, die auf Containerebene konfiguriert ist, gilt für alle Blobs in diesem Container. Einzelne Blobs können nicht mit ihren eigenen Unveränderlichkeitsrichtlinien konfiguriert werden.
Tags
Eine Aufbewahrungsrichtlinie für juristische Zwecke auf Containerebene muss mindestens einem benutzerdefinierten alphanumerischen Tag zugeordnet werden, das als Bezeichnerzeichenfolge dient. Ein Tag kann beispielsweise eine Fall-ID oder einen Ereignisnamen enthalten.
Überwachungsprotokollierung
Jeder Container mit einer Aufbewahrungsrichtlinie für juristische Zwecke stellt ein Richtlinienüberwachungsprotokoll bereit. Das Protokoll enthält Benutzer-ID, Befehlstyp, Zeitstempel und die Tags für die Aufbewahrungsrichtlinie für juristische Zwecke. Das Überwachungsprotokoll wird für die Lebensdauer der Richtlinie gemäß den Richtlinien der Verordnung SEC 17a-4(f) aufbewahrt.
Das Azure-Aktivitätsprotokoll ist ein umfassenderes Protokoll mit allen Verwaltungsdienstaktivitäten. Azure-Ressourcenprotokolle enthalten Informationen zu Datenvorgängen. Der Benutzer ist für die dauerhafte Speicherung dieser Protokolle verantwortlich, die aus gesetzlichen oder anderen Gründen ggf. erforderlich ist.
Änderungen an gesetzliche Aufbewahrungspflichten auf Versionsebene werden nicht geprüft.
Funktionsoptionen des unveränderlichen Speichers
Die folgende Tabelle zeigt eine Aufschlüsselung der Unterschiede zwischen WORM auf Containerebene und WORM auf Versionsebene:
| Kategorie | WORM auf Containerebene | WORM auf Versionsebene |
|---|---|---|
| Granularitätsebene der Richtlinie | Richtlinien können nur auf Containerebene konfiguriert werden. Jedes Objekt, das in den Container hochgeladen wird, erbt den Unveränderlichkeitsrichtliniensatz. | Richtlinien können auf Konto-, Container- oder Bobebene konfiguriert werden. Wenn eine Richtlinie auf Kontoebene festgelegt ist, erben alle Blobs, die in dieses Konto hochgeladen werden, die Richtlinie. Die gleiche Logik gilt für Container. Wenn eine Richtlinie auf mehreren Ebenen festgelegt ist, ist die Reihenfolge der Rangfolge immer Blob -> Container -> Konto. |
| Verfügbare Richtlinientypen | Zwei verschiedene Arten von Richtlinien können auf Containerebene festgelegt werden: zeitbasierte Aufbewahrungsrichtlinien und gesetzliche Aufbewahrungspflichten. | Auf Konto- und Containerebene können nur zeitbasierte Aufbewahrungsrichtlinien festgelegt werden. Auf Blobebene können sowohl zeitbasierte Aufbewahrungsrichtlinien als auch gesetzliche Aufbewahrungspflichten festgelegt werden. |
| Featureabhängigkeiten | Für dieses Feature sind keine anderen Features vorgesehen oder erforderlich. | Die Versionsverwaltung ist eine Voraussetzung für die Verwendung dieses Features. |
| Aktivierung für vorhandene Konten/Container | Dieses Feature kann jederzeit für vorhandene Container aktiviert werden. | Je nach Granularitätsgrad ist dieses Feature möglicherweise nicht für alle vorhandenen Konten/Container aktiviert. |
| Löschen von Konten/Containern | Sobald eine zeitbasierte Aufbewahrungsrichtlinie für einen Container festgelegt wurde, können Container nur noch gelöscht werden, wenn sie leer sind. | Sobald WORM auf Versionsebene auf Konto- oder Containerebene aktiviert ist, können sie nur noch gelöscht werden, wenn sie leer sind. |
| Unterstützung für Azure Data Lake Storage (Speicherkonten, für die ein hierarchischer Namespace aktiviert wurde) | WORM-Richtlinien auf Containerebene werden für Konten, die über einen hierarchischen Namespace verfügen, unterstützt. | WORM-Richtlinien auf Versionsebene werden für Konten, die über einen hierarchischen Namespace verfügen, noch nicht unterstützt. |
Weitere Informationen zu WORM auf Containerebene finden Sie unter WORM-Richtlinien auf Containerebene. Weitere Informationen zu WORM auf Versionsebene finden Sie unter WORM-Richtlinien auf Versionsebene.
WORM auf Containerebene vs auf Versionsebene
Die folgende Tabelle hilft Ihnen bei der Entscheidung, welche Art von WORM-Richtlinie Sie verwenden sollten.
| Kriterien | WORM-Verwendung auf Containerebene | WORM-Verwendung auf Versionsebene |
|---|---|---|
| Organisation von Daten | Sie möchten Richtlinien für bestimmte Datensätze festlegen, die nach Containern kategorisiert werden können. Alle Daten in diesem Container müssen für die gleiche Zeitspanne in einem WORM-Zustand gehalten werden. | Sie können Objekte nicht nach Aufbewahrungszeiträumen gruppieren. Alle Blobs müssen mit einer individuellen Aufbewahrungsfrist gespeichert werden, die auf den Szenarien des jeweiligen Blobs basiert, oder die Benutzerin oder der Benutzer hat einen gemischten Workload, so dass einige Datengruppen in Containern zusammengefasst werden können, andere Blobs jedoch nicht. Sie können auch Richtlinien auf Containerebene und Richtlinien auf Blobebene innerhalb desselben Kontos festlegen. |
| Menge der Daten, die eine Unveränderlichkeitsrichtlinie erfordern | Sie müssen keine Richtlinien für mehr als 10.000 Container pro Konto festlegen. | Sie möchten Richtlinien für alle Daten oder große Datenmengen festlegen, die nach Konto abgegrenzt werden können. Sie wissen bereits, dass Sie, wenn Sie WORM auf Containerebene verwenden, den Grenzwert von 10.000 Containern überschreiten müssen. |
| Interesse an der Aktivierung der Versionsverwaltung | Sie möchten die Versionsverwaltung entweder aus Kostengründen nicht aktivieren oder weil die Workload zahlreiche zusätzliche Versionen erzeugen würde, mit denen Sie umgehen müssten. | Sie möchten entweder die Versionsverwaltung nutzen oder es macht Ihnen nichts aus, sie zu nutzen. Sie wissen, dass Sie, wenn Sie die Versionsverwaltung nicht aktivieren, Änderungen oder Überschreibungen an unveränderlichen Blobs nicht als separate Versionen aufbewahren können. |
| Speicherort (Blob Storage im Vergleich zu Data Lake Storage) | Ihre Workload ist vollständig auf Azure Data Lake Storage ausgerichtet. Sie haben kein unmittelbares Interesse oder planen nicht, zu einem Konto zu wechseln, bei dem die Funktion für hierarchische Namespaces nicht aktiviert ist. | Ihre Workload befindet sich entweder in Blob Storage in einem Konto, für das das Feature für hierarchische Namespaces nicht aktiviert ist, und kann jetzt WORM auf Versionsebene verwenden, oder Sie sind bereit zu warten, bis die Versionsverwaltung für Konten verfügbar ist, für die ein hierarchischer Namespace aktiviert ist (Azure Data Lake Storage). |
Zugriffsebenen
Alle Blobzugriffsebenen unterstützen unveränderlichen Speicher. Sie können die Zugriffsebene eines Blobs mit dem Vorgang „Set Blob Tier“ ändern. Weitere Informationen finden Sie unter Zugriffsebenen für Blobdaten.
Redundanzkonfigurationen
Alle Redundanzkonfigurationen unterstützen unveränderlichen Speicher. Weitere Informationen zu Redundanzkonfigurationen finden Sie unter Azure Storage-Redundanz.
Empfohlene Blobtypen
Microsoft empfiehlt, Unveränderlichkeitsrichtlinien hauptsächlich für Blockblobs und Anfügeblobs zu konfigurieren. Unveränderlichkeitsrichtlinien sollten nicht für Seitenblobs konfiguriert werden, in denen eine virtuelle Festplatte für eine aktive VM gespeichert wird. Der Grund dafür ist, dass Schreibvorgänge auf diese Festplatte blockiert werden, oder dass bei aktivierter Versionsverwaltung jeder Schreibvorgang als eine neue Version gespeichert wird. Microsoft empfiehlt, die Dokumentation gründlich durchzugehen und Ihre Szenarios zu testen, bevor Sie zeitbasierte Richtlinien sperren.
Unveränderlicher Speicher bei vorläufigen Löschvorgängen für Blobs
Wenn das vorläufige Löschen von Blobs für ein Speicherkonto konfiguriert ist, gilt diese Konfiguration unabhängig davon, ob eine Richtlinie zur Aufbewahrung für juristische Zwecke oder eine zeitbasierte Aufbewahrungsrichtlinie in Kraft ist, für alle Blobs innerhalb des Kontos. Microsoft empfiehlt, das vorläufige Löschen als zusätzliche Schutzmaßnahme zu aktivieren, bevor Unveränderlichkeitsrichtlinien angewendet werden.
Wenn Sie das vorläufige Löschen aktivieren und dann eine Unveränderlichkeitsrichtlinie konfigurieren, werden alle Blobs, die bereits vorläufig gelöscht wurden, dauerhaft gelöscht, sobald die Aufbewahrungsrichtlinie für vorläufiges Löschen abgelaufen ist. Vorläufig gelöschte Blobs können während des Aufbewahrungszeitraums für vorläufiges Löschen wiederhergestellt werden. Ein Blob oder eine Version, die noch nicht vorläufig gelöscht wurde, wird durch die Unveränderlichkeitsrichtlinie geschützt und kann erst vorläufig gelöscht werden, wenn die zeitbasierte Aufbewahrungsrichtlinie abgelaufen ist oder die gesetzliche Aufbewahrungspflicht entfernt wird.
Verwenden des Blobbestands zum Nachverfolgen von Unveränderlichkeitsrichtlinien
Der Azure Storage-Blobbestand bietet eine Übersicht über die Container in Ihren Speicherkonten sowie die Blobs, Momentaufnahmen und Blobversionen innerhalb dieser Container. Sie können den Bericht zum Blobbestand nutzen, um sich über die Attribute von Blobs und Containern zu informieren. Diese Informationen umfassen u. a. die Angabe dazu, ob für eine Ressource eine Unveränderlichkeitsrichtlinie konfiguriert ist.
Wenn Sie den Blobbestand aktivieren, generiert Azure Storage täglich einen Bestandsbericht. Der Bericht enthält eine Übersicht über Ihre Daten, die Sie auch für Geschäfts- und Complianceanforderungen nutzen können.
Weitere Informationen zum Blobbestand finden Sie unter Azure Storage-Blobbestand.
Hinweis
Sie können keine Bestandsrichtlinie in einem Konto konfigurieren, wenn die Unterstützung für die Unveränderlichkeit auf Versionsebene für dieses Konto aktiviert ist oder die Unterstützung für die Unveränderlichkeit auf Versionsebene für den Zielcontainer aktiviert ist, der in der Bestandsrichtlinie definiert ist.
Konfigurieren von Richtlinien im großen Stil
Sie können eine Speicheraufgabe verwenden, um eine Unveränderlichkeitsrichtlinie basierend auf einer Reihe von Ihnen definierter Bedingungen im großen Stil für mehrere Speicherkonten zu konfigurieren. Eine Speicheraufgabe ist eine Ressource, die in Azure Speichervorgänge verfügbar ist. Dies ist ein serverloses Framework, mit dem Sie allgemeine Datenvorgänge für Millionen von Objekten über mehrere Speicherkonten hinweg ausführen können. Weitere Informationen finden Sie unter Was sind Azure Speichervorgänge?.
Preiskalkulation
Für die Verwendung von unveränderlichem Speicher fällt keine zusätzliche Kapazitätsgebühr an. Unveränderliche Daten werden auf die gleiche Weise abgerechnet wie änderbare Daten. Wenn Sie WORM auf Versionsebene verwenden, könnte die Rechnung höher ausfallen, da Sie die Versionsverwaltung aktiviert haben und die Speicherung zusätzlicher Versionen mit Kosten verbunden ist. Weitere Informationen finden Sie in den Preisrichtlinien für die Versionsverwaltung. Ausführliche Informationen zu Preisen von Azure Blob Storage finden Sie auf der Seite mit den Preisen für Azure Storage.
Beim Erstellen, Ändern oder Löschen einer zeitbasierten Aufbewahrungsrichtlinie oder einer Richtlinie zur Aufbewahrung für juristische Zwecke für eine Blobversion fällt eine Gebühr für Schreibtransaktionen an.
Wenn Sie Ihre Rechnung nicht begleichen und Ihr Konto über eine aktive zeitbasierte Aufbewahrungsrichtlinie verfügt, werden die normalen Datenaufbewahrungsrichtlinien gemäß den Bestimmungen Ihres Vertrags mit Microsoft angewendet. Weitere Informationen finden Sie unter Datenverwaltung bei Microsoft.
Featureunterstützung
Dieses Feature ist nicht mit der Zeitpunktwiederherstellung und der Nachverfolgung des letzten Zugriffs kompatibel. Dieses Feature ist mit dem vom Kunden verwalteten, ungeplanten Failover kompatibel. Alle Änderungen, die nach der letzten Synchronisierung an der unveränderlichen Richtlinie vorgenommen werden (z. B. das Sperren oder Erweitern einer zeitbasierten Aufbewahrungsrichtlinie) werden jedoch nicht mit der sekundären Region synchronisiert. Nach Abschluss des Failovers können Sie die Änderungen an der sekundären Region wiederholen, um sicherzustellen, dass diese gemäß Ihrer Unveränderlichkeitsanforderungen auf dem neuesten Stand ist. Unveränderlichkeitsrichtlinien werden in Konten, für die das NFS 3.0-Protokoll (Network File System, Netzwerkdateisystem) oder SFTP (SSH File Transfer Protocol, SSH-Dateiübertragungsprotokoll) aktiviert ist, nicht unterstützt.
Einige Workloads, z. B. SQL Server-Sicherung über URLs, erstellen ein Blob und fügen es dann hinzu. Wenn für einen Container eine aktive zeitbasierte Aufbewahrungsrichtlinie oder eine gesetzliche Aufbewahrungspflicht gilt, wird dieses Muster nicht erfolgreich ausgeführt. Weitere Informationen finden Sie unter „Erlauben des geschützten Anhängens von Blob-Schreibvorgängen“.
Weitere Informationen finden Sie unter Unterstützung der Blob Storage-Features in Azure Storage-Konten.