Eenmaal schrijven op containerniveau, veel (WORM)-beleid lezen voor onveranderbare blobgegevens
Een WORM-beleid op containerniveau is een type onveranderbaarheidsbeleid dat kan worden ingesteld op containerniveau. Voor meer informatie over onveranderbare opslag voor Azure Blob Storage raadpleegt u Bedrijfskritieke blobgegevens opslaan met onveranderbare opslag in een schrijfbewerking één keer, veel (WORM)-status lezen
Beschikbaarheid
WORM-beleid (CLW) op containerniveau is beschikbaar voor alle nieuwe en bestaande containers. Dit beleid wordt ondersteund voor accounts voor algemeen gebruik v2, premium blok-blob, algemeen gebruik v1 (verouderd) en blobopslagaccounts (verouderd).
Tip
Microsoft raadt aan om v1-accounts voor algemeen gebruik te upgraden naar v2 voor algemeen gebruik, zodat u kunt profiteren van meer functies. Zie Een opslagaccount upgraden voor meer informatie over het upgraden van een bestaand v1-opslagaccount voor algemeen gebruik.
Deze functie wordt ondersteund voor hiërarchische naamruimteaccounts. Als hiërarchische naamruimte is ingeschakeld, kunt u de naam van een blob niet wijzigen of verplaatsen wanneer de blob de onveranderbare status heeft. Zowel de blobnaam als de mapstructuur bieden essentiële gegevens op containerniveau die niet kunnen worden gewijzigd zodra het onveranderbare beleid is ingesteld.
Er is geen activeringsproces voor deze functie; deze is automatisch beschikbaar voor alle containers. Zie WORM-beleid op containerniveau voor onveranderbaarheid configureren voor meer informatie over het instellen van een beleid voor een nieuwe of bestaande container.
Verwijdering
Een container met een WORM-beleidsset op containerniveau moet leeg zijn voordat de container kan worden verwijderd. Als er een beleid is ingesteld voor een container waarvoor hiërarchische naamruimte is ingeschakeld, moet een map leeg zijn voordat deze kan worden verwijderd.
Scenario's
| Scenario | Verboden bewerkingen | Blobbeveiliging | Containerbeveiliging | Rekeningbeveiliging |
|---|---|---|---|---|
| Een container wordt beveiligd door een actief bewaarbeleid op basis van tijd met containerbereik en/of een juridische bewaring is van kracht | Blob verwijderen, Put Blob1, Blobmetagegevens instellen, Pagina plaatsen, Blob-eigenschappen instellen, Momentopname-blob, Incrementele kopie-blob, Toevoegblok2 | Alle blobs in de container zijn onveranderbaar voor inhoud en metagegevens van gebruikers. | Het verwijderen van containers mislukt als een WORM-beleid op containerniveau van kracht is. | Verwijderen van opslagaccount mislukt als er een container met ten minste één blob aanwezig is. |
| Een container wordt beveiligd door een verlopen bewaarbeleid op basis van tijd met containerbereik en er is geen juridische bewaring van kracht | Put Blob 1, Set Blob Metadata, Put Page, Set Blob Properties, Snapshot Blob, Incremental Copy Blob, Append Block2 | Verwijderingsbewerkingen zijn toegestaan. Overschrijfbewerkingen zijn niet toegestaan. | Het verwijderen van containers mislukt als er ten minste één blob in de container bestaat, ongeacht of het beleid is vergrendeld of ontgrendeld. | Verwijderen van opslagaccount mislukt als er ten minste één container is met een op tijd gebaseerd bewaarbeleid. Ontgrendeld beleid biedt geen verwijderingsbeveiliging. |
1 Azure Storage staat de Put Blob-bewerking toe om een nieuwe blob te maken. Volgende overschrijfbewerkingen op een bestaand blobpad in een onveranderbare container zijn niet toegestaan.
2 De bewerking Toevoegblok is alleen toegestaan voor beleidsregels waarvoor de eigenschap allowProtectedAppendWrites of allowProtectedAppendWritesAll is ingeschakeld.
Beveiligde toevoeg-blobs schrijven toestaan
Toevoeg-blobs bestaan uit blokken gegevens en zijn geoptimaliseerd voor bewerkingen voor het toevoegen van gegevens die zijn vereist voor controle- en logboekregistratiescenario's. Toevoeg-blobs staan standaard alleen het toevoegen van nieuwe blokken toe aan het einde van de blob. Ongeacht onveranderbaarheid, wijziging of verwijdering van bestaande blokken in een toevoeg-blob is fundamenteel niet toegestaan. Zie Over toevoeg-blobs voor meer informatie over toevoeg-blobs.
Met de eigenschapsinstelling allowProtectedAppendWrites kunt u nieuwe blokken schrijven naar een toevoeg-blob terwijl onveranderbaarheidsbeveiliging en naleving behouden blijven. Als deze instelling is ingeschakeld, kunt u rechtstreeks in de container met beleidsbeveiliging een toevoeg-blob maken en vervolgens nieuwe gegevensblokken toevoegen aan het einde van de toevoeg-blob met de bewerking Toevoegblok. Alleen nieuwe blokken kunnen worden toegevoegd; bestaande blokken kunnen niet worden gewijzigd of verwijderd. Het inschakelen van deze instelling heeft geen invloed op het onveranderbaarheidsgedrag van blok-blobs of pagina-blobs.
De eigenschap AllowProtectedAppendWritesAll biedt dezelfde machtigingen als de eigenschap allowProtectedAppendWrites en voegt de mogelijkheid toe om nieuwe blokken naar een blok-blob te schrijven. De Blob Storage-API biedt geen manier voor toepassingen om dit rechtstreeks te doen. Toepassingen kunnen dit echter doen met behulp van toevoeg- en spoelmethoden die beschikbaar zijn in de Data Lake Storage-API. Met deze eigenschap kunnen Microsoft-toepassingen zoals Azure Data Factory ook blokken gegevens toevoegen met behulp van interne API's. Als uw workloads afhankelijk zijn van een van deze hulpprogramma's, kunt u deze eigenschap gebruiken om fouten te voorkomen die kunnen optreden wanneer deze hulpprogramma's proberen gegevens toe te voegen aan blobs.
Toevoeg-blobs blijven onveranderbaar gedurende de effectieve bewaarperiode. Omdat nieuwe gegevens kunnen worden toegevoegd na het maken van de toevoeg-blob, is er een klein verschil in hoe de bewaarperiode wordt bepaald. De effectieve retentie is het verschil tussen de laatste wijzigingstijd van de toevoeg-blob en het door de gebruiker opgegeven bewaarinterval. Wanneer het retentie-interval wordt uitgebreid, gebruikt onveranderbare opslag ook de meest recente waarde van het door de gebruiker opgegeven retentie-interval om de effectieve bewaarperiode te berekenen.
Stel dat een gebruiker een bewaarbeleid op basis van tijd maakt met de eigenschap allowProtectedAppendWrites ingeschakeld en een bewaarperiode van 90 dagen. Een toevoeg-blob, logblob1, wordt vandaag gemaakt in de container, nieuwe logboeken blijven de komende 10 dagen worden toegevoegd aan de toevoeg-blob, zodat de effectieve bewaarperiode voor logblob1 100 dagen vanaf vandaag is (de tijd van de laatste toevoeg + 90 dagen).
Met een retentiebeleid op basis van ontgrendelde tijd kunnen de instellingen voor allowProtectedAppendWrites en AllowProtectedAppendWritesAll op elk gewenst moment worden ingeschakeld en uitgeschakeld. Zodra het bewaarbeleid op basis van tijd is vergrendeld, kunnen de eigenschapsinstellingen allowProtectedAppendWrites en AllowProtectedAppendWritesAll niet worden gewijzigd.
Limieten
Voor een opslagaccount is het maximum aantal containers met een onveranderbaar beleid (retentie op basis van tijd of juridische bewaring) 10.000.
Voor een container is het maximum aantal tags voor juridische bewaring op elk gewenst moment 10.
De minimale lengte van een tag voor juridische bewaring is drie alfanumerieke tekens. De maximale lengte is 23 alfanumerieke tekens.
Voor een container worden maximaal 10 auditlogboeken voor juridische bewaring bewaard voor de duur van het beleid.