Scrittura a livello di contenitore una sola volta, lettura di molti criteri (WORM) per i dati BLOB non modificabili
Un criterio di scrittura a livello di contenitore una sola volta, leggere molti criteri (WORM) è un tipo di criteri di immutabilità che possono essere impostati a livello di contenitore. Per altre informazioni sull'archiviazione non modificabile per Archiviazione BLOB di Azure, vedere Archiviare dati BLOB critici per l'azienda con archiviazione non modificabile in una sola volta, leggere molti stati (WORM)
Disponibilità
I criteri WORM (CLW) a livello di contenitore sono disponibili per tutti i contenitori nuovi ed esistenti. Questi criteri sono supportati per gli account per utilizzo generico v2, BLOB in blocchi Premium, utilizzo generico v1 (legacy) e archiviazione BLOB (legacy).
Suggerimento
Microsoft consiglia di aggiornare gli account per utilizzo generico v1 alla versione 2 per utilizzo generico, in modo da poter sfruttare altre funzionalità. Per informazioni sull'aggiornamento di un account di archiviazione per utilizzo generico v1 esistente, vedere Aggiornare un account di archiviazione.
Questa funzionalità è supportata per gli account dello spazio dei nomi gerarchici. Se lo spazio dei nomi gerarchico è abilitato, non è possibile rinominare o spostare un BLOB quando il BLOB si trova nello stato non modificabile. Sia il nome del BLOB che la struttura di directory forniscono dati essenziali a livello di contenitore che non possono essere modificati dopo che i criteri non modificabili sono stati applicati.
Non esiste alcun processo di abilitazione per questa funzionalità; è disponibile automaticamente per tutti i contenitori. Per altre informazioni su come impostare criteri in un contenitore nuovo o esistente, vedere Configurare i criteri di immutabilità WORM a livello di contenitore.
Eliminazione
Un contenitore con un set di criteri WORM a livello di contenitore deve essere vuoto prima che il contenitore possa essere eliminato. Se è presente un set di criteri in un contenitore con spazio dei nomi gerarchico abilitato, è necessario che una directory sia vuota prima di poterla eliminare.
Scenari
| Scenario | Operazioni non consentite | Protezione BLOB | Protezione dei contenitori | Protezione account |
|---|---|---|---|---|
| Un contenitore è protetto da un criterio di conservazione basato sul tempo attivo con ambito contenitore e/o un blocco valido è attivo | Delete Blob, Put Blob 1, Set BlobMetadata, Put Page, Set Blob Properties, Snapshot Blob, Incremental Copy Blob, Append Block2 | Tutti i BLOB nel contenitore non sono modificabili per il contenuto e i metadati utente. | L'eliminazione del contenitore ha esito negativo se è attivo un criterio WORM a livello di contenitore. | L'eliminazione dell'account di archiviazione non riesce se è presente un contenitore con almeno un BLOB. |
| Un contenitore è protetto da un criterio di conservazione basato sul tempo scaduto con ambito contenitore e non è attivo alcun blocco a fini giudiziari | Put Blob1, Set Blob Metadata, Put Page, Set Blob Properties, Snapshot Blob, Incremental Copy Blob, Append Block2 | Le operazioni di eliminazione sono consentite. Le operazioni di sovrascrittura non sono consentite. | L'eliminazione del contenitore non riesce se nel contenitore è presente almeno un BLOB, indipendentemente dal fatto che i criteri siano bloccati o sbloccati. | L'eliminazione dell'account di archiviazione ha esito negativo se è presente almeno un contenitore con criteri di conservazione basati sul tempo bloccati. I criteri sbloccati non forniscono la protezione dell'eliminazione. |
1 Archiviazione di Azure consente all'operazione Put Blob di creare un nuovo BLOB. Le successive operazioni di sovrascrittura in un percorso BLOB esistente in un contenitore non modificabile non sono consentite.
2 L'operazione Append Block è consentita solo per i criteri con la proprietà allowProtectedAppendWrites o allowProtectedAppendWritesAll abilitata.
Consenti scritture BLOB di accodamento protette
I BLOB di accodamento sono costituiti da blocchi di dati e ottimizzati per le operazioni di accodamento dei dati richieste dagli scenari di controllo e registrazione. Per impostazione predefinita, i BLOB di accodamento consentono solo l'aggiunta di nuovi blocchi alla fine del BLOB. Indipendentemente dall'immutabilità, la modifica o l'eliminazione di blocchi esistenti in un BLOB di accodamento non è consentita. Per altre informazioni sui BLOB di accodamento, vedere Informazioni sui BLOB di accodamento.
L'impostazione della proprietà allowProtectedAppendWrites consente di scrivere nuovi blocchi in un BLOB di accodamento mantenendo al tempo stesso la protezione e la conformità non modificabili. Se questa impostazione è abilitata, è possibile creare un BLOB di accodamento direttamente nel contenitore protetto da criteri e quindi continuare ad aggiungere nuovi blocchi di dati alla fine del BLOB di accodamento con l'operazione Append Block. È possibile aggiungere solo nuovi blocchi; non è possibile modificare o eliminare blocchi esistenti. L'abilitazione di questa impostazione non influisce sul comportamento di immutabilità dei BLOB in blocchi o dei BLOB di pagine.
L'impostazione della proprietà AllowProtectedAppendWritesAll fornisce le stesse autorizzazioni della proprietà allowProtectedAppendWrites e aggiunge la possibilità di scrivere nuovi blocchi in un BLOB in blocchi. L'API di archiviazione BLOB non consente alle applicazioni di eseguire questa operazione direttamente. Tuttavia, le applicazioni possono eseguire questa operazione usando metodi di accodamento e scaricamento disponibili nell'API Data Lake Storage. Questa proprietà consente anche alle applicazioni Microsoft come Azure Data Factory di aggiungere blocchi di dati usando le API interne. Se i carichi di lavoro dipendono da uno di questi strumenti, è possibile usare questa proprietà per evitare errori che possono essere visualizzati quando questi strumenti tentano di aggiungere dati ai BLOB.
I BLOB di accodamento rimangono nello stato non modificabile durante il periodo di conservazione effettivo. Poiché i nuovi dati possono essere aggiunti oltre la creazione iniziale del BLOB di accodamento, esiste una leggera differenza nel modo in cui viene determinato il periodo di conservazione. La conservazione effettiva è la differenza tra l'ora dell'ultima modifica del BLOB di accodamento e l'intervallo di conservazione specificato dall'utente. Analogamente, quando l'intervallo di conservazione viene esteso, l'archiviazione non modificabile usa il valore più recente dell'intervallo di conservazione specificato dall'utente per calcolare il periodo di conservazione effettivo.
Si supponga, ad esempio, che un utente crei un criterio di conservazione basato sul tempo con la proprietà allowProtectedAppendWrites abilitata e un intervallo di conservazione di 90 giorni. Un BLOB di accodamento, logblob1, viene creato nel contenitore oggi, i nuovi log continuano ad essere aggiunti al BLOB di accodamento per i prossimi 10 giorni, in modo che il periodo di conservazione effettivo per logblob1 sia di 100 giorni da oggi (l'ora dell'ultimo accodamento + 90 giorni).
I criteri di conservazione basati sul tempo sbloccati consentono di abilitare e disabilitare le impostazioni delle proprietà allowProtectedAppendWritesAll in qualsiasi momento. Dopo aver bloccato i criteri di conservazione basati sul tempo, le impostazioni della proprietà allowProtectedAppendWrites e AllowProtectedAppendWritesAll non possono essere modificate.
Limiti
Per un account di archiviazione, il numero massimo di contenitori con criteri non modificabili (conservazione basata sul tempo o blocco legale) è 10.000.
Per un contenitore, il numero massimo di tag di blocco valido in qualsiasi momento è 10.
La lunghezza minima di un tag di blocco valido è di tre caratteri alfanumerici. La lunghezza massima è di 23 caratteri alfanumerici.
Per un contenitore, per la durata del criterio vengono conservati un massimo di 10 log di controllo dei criteri di blocco a fini giudiziari.