Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Un criterio WORM ("scrivi una volta, leggi più volte") a livello di contenitore è un tipo di policy di immutabilità che può essere configurata a livello di container. 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 stato 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 gerarchico. Se lo spazio dei nomi gerarchico è abilitato, non è possibile rinominare o spostare un BLOB quando il BLOB si trova in stato non modificabile. Sia il nome del BLOB sia la struttura delle directory forniscono dati essenziali a livello di contenitore che non possono essere modificati una volta applicato il criterio di immutabilità.
Non è necessario 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 di poter essere eliminato. Se un set di criteri è abilitato in un contenitore con spazio dei nomi gerarchico, è necessario che una directory sia vuota prima di poterla eliminare.
È possibile eliminare un contenitore con criteri WORM a livello di contenitore solo usando operazioni del piano di controllo. Tutte queste richieste vengono inviate all'URL di Azure Resource Manager. Ad esempio, il comando di PowerShell Remove-AzRmStorageContainer usa un'operazione del piano di controllo per eliminare un contenitore. Al contrario, il comando Remove-AzStorageContainer tenta di usare un'operazione del piano dati, che non avrà esito positivo. Analogamente, il comando CLI di Azure az storage container-rm delete utilizza un'operazione di controllo, mentre az storage container delete si basa su un'operazione del piano dati. È anche possibile eliminare un contenitore tramite il portale di Azure, perché esegue l'attività usando un'operazione del piano di controllo.
Scenari
| Sceneggiatura | Operazioni non consentite | Protezione BLOB | Protezione dei contenitori | Protezione dell'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 Blob1, Set Blob Metadata, 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 un criterio WORM a livello di contenitore è attivo. | L'eliminazione dell'account di archiviazione non riesce se è presente un contenitore con almeno un BLOB. |
| Un contenitore è protetto da un criterio di conservazione scaduto basato su tempo 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 ha esito negativo se nel contenitore esiste 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 su tempo bloccati. I criteri sbloccati non forniscono la protezione dall'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 criteri con la proprietà allowProtectedAppendWrites o allowProtectedAppendWritesAll abilitate.
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à dell'immutabilità. 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 solo aggiungere 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 direttamente questa operazione. 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 API interne. Se i carichi di lavoro dipendono da uno di questi strumenti, è possibile usare questa proprietà per evitare errori che potrebbero apparire 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é è possibile aggiungere nuovi dati dopo la creazione iniziale di un BLOB di accodamento, vi è 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 su tempo con la proprietà allowProtectedAppendWrites abilitata e un intervallo di conservazione di 90 giorni. Un BLOB di accodamento, logblob1, viene creato nel container oggi; nei successivi 10 giorni vengono aggiunti nuovi log allo stesso blob, pertanto il periodo di conservazione effettivo per logblob1 sarà di 100 giorni a partire da oggi (cioè dalla data dell’ultima operazione di aggiunta + 90 giorni).
I criteri di conservazione basati su tempo sbloccati consentono di abilitare e disabilitare le impostazioni delle proprietà allowProtectedAppendWrites e 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, viene mantenuto un massimo di 10 log di controllo della policy di blocco legale per l’intera durata della policy.