Archiviare i dati BLOB critici per l'azienda con archiviazione non modificabile in una sola volta, leggere molti stati (WORM)
L'archiviazione non modificabile per Archiviazione BLOB di Azure consente agli utenti di archiviare i dati business-critical in uno stato WORM (Write Once, Read Many). Nello stato WORM, i dati non possono essere modificati o eliminati per un intervallo specificato dall'utente. Configurando criteri di immutabilità per i dati BLOB, è possibile proteggere i dati da tentativi di sovrascrittura ed eliminazione.
L'archiviazione non modificabile per Archiviazione BLOB di Azure supporta due tipi di criteri di immutabilità:
Criteri di conservazione basati sul tempo: con criteri di conservazione basati sul tempo, gli utenti possono impostare criteri per archiviare i dati per un intervallo specificato. Quando vengono impostati criteri di conservazione basati sul tempo, gli oggetti possono essere creati e letti, ma non modificati o eliminati. Al termine del periodo di conservazione, gli oggetti possono essere eliminati ma non sovrascritti.
Criteri di blocco a fini giudiziari: un blocco a fini giudiziari archivia dati non modificabili fino a quando non viene cancellata in modo esplicito il blocco a fini giudiziari. Quando viene impostato un blocco a fini giudiziari, gli oggetti possono essere creati e letti, ma non modificati o eliminati.
Questi criteri possono essere impostati contemporaneamente all'uno all'altro. Ad esempio, un utente può avere criteri di conservazione basati sul tempo e un blocco legale impostato allo stesso livello e contemporaneamente. Affinché una scrittura abbia esito positivo, è necessario che il controllo delle versioni sia abilitato o che non siano presenti criteri di conservazione legali o basati sul tempo sui dati. Affinché un'eliminazione abbia esito positivo, non deve essere presente un criterio di conservazione valido o basato sul tempo anche sui dati.
Il diagramma seguente illustra come i criteri di conservazione basati sul tempo e i blocchi legali impediscono le operazioni di scrittura ed eliminazione mentre sono attive.
Esistono due funzionalità sotto l'ombrello di archiviazione non modificabile: WORM a livello di contenitore e WORM a livello di versione. WORM a livello di contenitore consente di impostare criteri solo a livello di contenitore, mentre WORM a livello di versione consente di impostare i criteri a livello di account, contenitore o versione.
Informazioni sull'archiviazione non modificabile per i BLOB
L'archiviazione non modificabile aiuta le organizzazioni sanitarie, le istituzioni finanziarie e i settori correlati, in particolare le organizzazioni che si occupano di intermediazione finanziaria, ad archiviare i dati in modo sicuro. È possibile usare l'archiviazione non modificabile in qualsiasi scenario per proteggere i dati critici da modifiche o eliminazioni.
Le applicazioni tipiche includono:
Conformità alle normative: l'archiviazione non modificabile per Archiviazione BLOB di Azure aiuta le organizzazioni a soddisfare i requisiti di SEC 17a-4(f), CFTC 1.31(d), FINRA e altre normative.
Conservazione sicura dei documenti: l'archiviazione non modificabile per i BLOB assicura che i dati non possano essere modificati o eliminati da alcun utente, neanche da quelli con privilegi amministrativi dell'account.
Blocco a fini giudiziari: l'archiviazione non modificabile per i BLOB consente agli utenti di archiviare informazioni riservate di importanza critica per una controversia o l'uso aziendale in uno stato antimanomissione per il periodo di tempo desiderato, fino alla rimozione del blocco. Questa funzionalità non è limitata solo ai casi d'uso legali, ma può anche essere considerata come blocco basato su eventi o blocco aziendale, in cui è necessario proteggere i dati in base a trigger di eventi o criteri aziendali.
Conformità alle normative
Microsoft ha mantenuto una società di valutazione indipendente leader specializzata nella gestione dei record e nella governance delle informazioni, Cohasset Associates, per valutare l'archiviazione non modificabile per i BLOB e la conformità ai requisiti specifici del settore dei servizi finanziari. Cohasset ha convalidato che l'archiviazione non modificabile, se usata per conservare i BLOB in uno stato WORM, soddisfa i requisiti di archiviazione pertinenti della regola CFTC 1.31(c)-(d), la regola FINRA 4511 e la regola SEC 17a-4(f). Microsoft ha preso di mira questo set di regole perché rappresentano le linee guida più prescrittive a livello globale per la conservazione dei record per gli istituti finanziari.
Il report Cohasset è disponibile nel Centro protezione del Servizio Microsoft. Il Centro protezione di Azure contiene informazioni dettagliate sulle certificazioni di conformità di Microsoft. Per richiedere una lettera di attestazione da Microsoft per quanto riguarda la conformità all'immutabilità WORM, contattare il supporto tecnico di Azure.
Criteri di conservazione basati sul tempo
I criteri di conservazione basati sul tempo archivia i dati BLOB in un formato WORM per un intervallo specificato. Quando vengono impostati criteri di conservazione basati sul tempo, i client possono creare e leggere BLOB, ma non possono modificarli o eliminarli. Dopo la scadenza dell'intervallo di conservazione, i BLOB possono essere eliminati ma non sovrascritti.
Ambito
È possibile configurare criteri di conservazione basati sul tempo negli ambiti seguenti:
- Criteri WORM a livello di versione: i criteri di conservazione basati sul tempo possono essere configurati a livello di account, contenitore o versione. Se è configurato a livello di account o contenitore, verrà ereditato da tutti i BLOB nel rispettivo account o contenitore. Se è presente un blocco a fini giudiziari in un contenitore, non è possibile creare un WORM a livello di versione per lo stesso contenitore. Ciò è dovuto al fatto che le versioni non possono essere generate a causa del blocco legale.
- Criteri WORM a livello di contenitore: un criterio di conservazione basato sul tempo configurato a livello di contenitore si applica a tutti i BLOB in tale contenitore. Non è possibile considerare i singoli BLOB con criteri di immutabilità propri.
Intervallo di conservazione per i criteri basati sul tempo
L'intervallo di conservazione minimo per un criterio di conservazione basato sul tempo è un giorno e il valore massimo è 146.000 giorni (400 anni). Quando si configura un criterio di conservazione basato sul tempo, gli oggetti interessati rimangono nello stato non modificabile durante il periodo di conservazione effettivo. Il periodo di conservazione effettivo per gli oggetti i è uguale alla differenza tra l'ora di creazione del BLOB e il periodo di conservazione specificato dall'utente. Poiché è possibile estendere l'intervallo di conservazione di un criterio, l'archiviazione non modificabile usa il valore più recente dell'intervallo di conservazione specificato dall'utente per calcolare il periodo di conservazione effettivo.
Supporre ad esempio che un utente crei un criterio di conservazione basato sul tempo con un intervallo di conservazione di cinque anni. Un BLOB esistente in tale contenitore, testblob1, è stato creato un anno fa, quindi il periodo di conservazione effettivo per testblob1 è di quattro anni. Quando un nuovo BLOB, testblob2, viene caricato nel contenitore, il periodo di conservazione effettivo per testblob2 è di cinque anni dal momento della creazione.
Criteri bloccati e sbloccati
Quando si configurano per la prima volta criteri di conservazione basati sul tempo, i criteri vengono sbloccati a scopo di test. Al termine dei test, è possibile bloccare i criteri in modo che siano completamente conformi a SEC 17a-4(f) e ad altre normative.
Sia i criteri bloccati che i criteri sbloccati proteggono dalle eliminazioni e dalle sovrascrizioni. Tuttavia, è possibile modificare un criterio sbloccato abbreviando o estendendo il periodo di conservazione. È anche possibile eliminare un criterio sbloccato. Non è possibile eliminare un criterio di conservazione basato sul tempo bloccato. È possibile estendere il periodo di conservazione, ma non è possibile ridurlo. Un massimo di cinque aumenti al periodo di conservazione effettivo è consentito per tutta la durata di un criterio bloccato definito a livello di contenitore. Per i criteri configurati per una versione del BLOB, non è previsto alcun limite al numero di aumenti al periodo di validità.
Importante
I criteri di conservazione basati sul tempo devono essere bloccati perché il BLOB sia in uno stato non modificabile conforme (protetto da scrittura ed eliminazione) per la conformità a SEC 17a-4(f) e ad altri requisiti normativi. Microsoft consiglia di bloccare i criteri in un periodo di tempo ragionevole, in genere inferiore a 24 ore. Sebbene lo stato sbloccato fornisca una protezione non modificabile, non è consigliabile usare lo stato sbloccato per qualsiasi scopo differente dai test a breve termine.
Registrazione di audit dei criteri di conservazione
Ogni contenitore con criteri di conservazione basati sul tempo abilitato fornisce un log di audit dei criteri. Il log di audit include fino a sette comandi di conservazione basati sul tempo per i criteri di conservazione basati sul tempo bloccati. La registrazione viene in genere avviata dopo aver bloccato i criteri. Le voci di log includono l'ID utente, il tipo di comando, i timestamp e l'intervallo di conservazione. Questo log di audit viene mantenuto per tutta la durata dei criteri, in conformità alle linee guida delle normative SEC 17a-4(f).
Il log delle attività di Azure offre un registro più completo di tutte le attività del servizio di gestione. I log delle risorse di Azure mantengono le informazioni sulle operazioni sui dati. È responsabilità dell'utente archiviare questi log in modo permanente, come potrebbe essere richiesto per scopi legali o di altro tipo.
Le modifiche ai criteri di conservazione basati sul tempo a livello di versione non vengono controllate.
Blocchi a fini giudiziari
un blocco a fini giudiziari è un criterio di immutabilità temporaneo che è possibile applicare per scopi di indagine legale o criteri di protezione generale. Un blocco legale archivia i dati BLOB in un formato Write-Once, Read-Many (WORM) fino a quando il blocco non viene cancellato in modo esplicito. Quando viene applicato un blocco a fini giudiziari, i BLOB possono essere creati e letti, ma non modificati o eliminati. Usare un blocco a fini giudiziari quando il periodo di tempo per cui i dati devono essere conservati in uno stato WORM non è noto.
Ambito
I criteri di blocco legale possono essere configurati in uno degli ambiti seguenti:
Criteri WORM a livello di versione: un blocco legale può essere configurato a livello di versione singola del BLOB per la gestione granulare dei dati sensibili.
Criteri WORM a livello di contenitore: un blocco a livello di contenitore configurato a livello di contenitore si applica a tutti i BLOB in tale contenitore. Non è possibile considerare i singoli BLOB con criteri di immutabilità propri.
Tag
Un blocco a livello di contenitore deve essere associato a uno o più tag alfanumerici definiti dall'utente che fungono da stringhe di identificatore. Ad esempio, un tag può includere un ID maiuscolo o un nome evento.
Registrazione del controllo
Ogni contenitore con blocco a fini giudiziari fornisce un log di audit dei criteri. Il log contiene l'ID utente, il tipo di comando, i timestamp e i tag di blocco a fini giudiziari. Questo log di audit viene mantenuto per tutta la durata dei criteri, in conformità alle linee guida delle normative SEC 17a-4(f).
Il log delle attività di Azure offre un registro più completo di tutte le attività del servizio di gestione. I log delle risorse di Azure mantengono le informazioni sulle operazioni sui dati. È responsabilità dell'utente archiviare questi log in modo permanente, come potrebbe essere richiesto per scopi legali o di altro tipo.
Le modifiche ai blocchi legali a livello di versione non vengono controllate.
Opzioni delle funzionalità di archiviazione non modificabili
La tabella seguente illustra una suddivisione delle differenze tra WORM a livello di contenitore e WORM a livello di versione:
| Categoria | WORM a livello di contenitore | WORM a livello di versione |
|---|---|---|
| Livello di granularità dei criteri | I criteri possono essere configurati solo a livello di contenitore. Ogni oggetto caricato nel contenitore eredita il set di criteri non modificabile. | I criteri possono essere configurati a livello di account, contenitore o BLOB. Se un criterio viene impostato a livello di account, tutti i BLOB caricati in tale account ereditano i criteri. La stessa logica segue con i contenitori. Se un criterio viene impostato a più livelli, l'ordine di precedenza è sempre BLOB -> Contenitore -> Account. |
| Tipi di criteri disponibili | È possibile impostare due differenti tipi di criteri a livello di contenitore: criteri di conservazione basati sul tempo e blocchi legali. | A livello di account e contenitore, è possibile impostare solo i criteri di conservazione basati sul tempo. A livello di BLOB, è possibile impostare sia i criteri di conservazione basati sul tempo che i blocchi legali. |
| Dipendenze delle funzionalità | Nessun'altra funzionalità è un prerequisito o un requisito per il funzionamento di questa funzionalità. | Il controllo delle versioni è un prerequisito per questa funzionalità da usare. |
| Abilitazione per account/contenitori esistenti | Questa funzionalità può essere abilitata in qualsiasi momento per i contenitori esistenti. | A seconda del livello di granularità, questa funzionalità potrebbe non essere abilitata per tutti gli account/contenitori esistenti. |
| Eliminazione di account/contenitori | Quando un criterio di conservazione basato sul tempo è bloccato in un contenitore, i contenitori possono essere eliminati solo se sono vuoti. | Una volta abilitato WORM a livello di versione a livello di account o contenitore, possono essere eliminati solo se sono vuoti. |
| Supporto per Azure Data Lake Storage (account di archiviazione con uno spazio dei nomi gerarchico abilitato) | I criteri WORM a livello di contenitore sono supportati negli account con uno spazio dei nomi gerarchico. | I criteri WORM a livello di versione non sono ancora supportati negli account con uno spazio dei nomi gerarchico. |
Per altre informazioni su WORM a livello di contenitore, vedere Criteri WORM a livello di contenitore. Per altre informazioni su WORM a livello di versione, visitare i criteri WORM a livello di versione.
WORM a livello di contenitore e a livello di versione
La tabella seguente consente di decidere quale tipo di criteri WORM usare.
| Criteri | Utilizzo WORM a livello di contenitore | Utilizzo WORM a livello di versione |
|---|---|---|
| Organizzazione dei dati | Si desidera impostare criteri per set di dati specifici, che possono essere classificati in base al contenitore. Tutti i dati in tale contenitore devono essere mantenuti in uno stato WORM per la stessa quantità di tempo. | Non è possibile raggruppare gli oggetti in base ai periodi di conservazione. Tutti i BLOB devono essere archiviati con un singolo tempo di conservazione in base agli scenari del BLOB oppure l'utente ha un carico di lavoro misto in modo che alcuni gruppi di dati possano essere raggruppati in contenitori, mentre altri non possono. È anche possibile impostare criteri a livello di contenitore e criteri a livello di BLOB all'interno dello stesso account. |
| Quantità di dati che richiedono criteri non modificabili | Non è necessario impostare criteri in più di 10.000 contenitori per account. | Si desidera impostare criteri per tutti i dati o grandi quantità di dati che possono essere delineati dall'account. Se si usa WORM a livello di contenitore, è necessario superare il limite di 10.000 contenitori. |
| Interesse per l'abilitazione del controllo delle versioni | Non si desidera gestire l'abilitazione del controllo delle versioni a causa del costo o perché il carico di lavoro crea numerose versioni aggiuntive da gestire. | Si desidera usare il controllo delle versioni o non è consigliabile usarlo. Se non abilitano il controllo delle versioni, non è possibile mantenere le modifiche o sovrascrivere i BLOB non modificabili come versioni separate. |
| Percorso di archiviazione (Archiviazione BLOB e Data Lake Storage) | Il carico di lavoro è interamente incentrato su Azure Data Lake Storage. Non si ha alcun interesse immediato o si prevede di andare all'uso di un account che non dispone della funzionalità dello spazio dei nomi gerarchico abilitata. | Il carico di lavoro si trova nell'archiviazione BLOB in un account che non dispone della funzionalità dello spazio dei nomi gerarchico abilitata e può ora usare WORM a livello di versione oppure si è disposti ad attendere che il controllo delle versioni sia disponibile per gli account con uno spazio dei nomi gerarchico abilitato (Azure Data Lake Storage). |
Livelli di accesso
Tutti i livelli di accesso BLOB supportano l'archiviazione non modificabile. È possibile modificare il livello di accesso di un BLOB con l'operazione Imposta livello BLOB. Per altre informazioni, vedere Livelli di accesso per i dati BLOB.
Configurazioni di ridondanza
Tutte le configurazioni di ridondanza supportano l'archiviazione non modificabile. Per altre informazioni sulle opzioni di ridondanza, vedere Ridondanza di Archiviazione di Azure.
Tipi di BLOB consigliati
Microsoft consiglia di configurare i criteri di immutabilità principalmente per i BLOB in blocchi e i BLOB di accodamento. La configurazione di un criterio di immutabilità per un BLOB di pagine in cui è archiviato un disco VHD per una macchina virtuale attiva è sconsigliata perché le scritture nel disco verranno bloccate o, se il controllo delle versioni è abilitato, ogni scrittura viene archiviata come nuova versione. Microsoft consiglia di esaminare attentamente la documentazione e testare gli scenari prima di bloccare i criteri basati sul tempo.
Archiviazione non modificabile con eliminazione temporanea BLOB
Quando l'eliminazione temporanea del BLOB è configurata per un account di archiviazione, si applica a tutti i BLOB all'interno dell'account, indipendentemente dal fatto che sia attivo un criterio di conservazione valido o basato sul tempo. Microsoft consiglia di abilitare l'eliminazione temporanea per una protezione aggiuntiva prima dell'applicazione di eventuali criteri di immutabilità.
Se si abilita l'eliminazione temporanea del BLOB e si configura un criterio di immutabilità, tutti i BLOB che sono già stati eliminati temporaneamente vengono eliminati definitivamente dopo la scadenza dei criteri di conservazione dell'eliminazione temporanea. I BLOB eliminati soft possono essere ripristinati durante il periodo di conservazione dell'eliminazione temporanea. Un BLOB o una versione che non è ancora stata eliminata temporaneamente è protetta dai criteri di immutabilità e non può essere eliminata temporaneamente fino a quando i criteri di conservazione basati sul tempo non sono scaduti o il blocco legale viene rimosso.
Usare l'inventario BLOB per tenere traccia dei criteri di immutabilità
L'inventario BLOB di Archiviazione di Azure offre una panoramica dei contenitori negli account di archiviazione e dei BLOB, degli snapshot e delle versioni BLOB all'interno di essi. È possibile usare il report di inventario BLOB per comprendere gli attributi dei BLOB e dei contenitori, incluso se una risorsa ha un criterio di immutabilità configurato.
Quando si abilita l'inventario BLOB, Archiviazione di Azure genera un report di inventario ogni giorno. Il report fornisce una panoramica dei dati per i requisiti aziendali e di conformità.
Per altre informazioni sull'inventario BLOB, vedere Inventario BLOB Archiviazione di Azure.
Nota
Non è possibile configurare un criterio di inventario in un account se il supporto per l'immutabilità a livello di versione è abilitato in tale account o se il supporto per l'immutabilità a livello di versione è abilitato nel contenitore di destinazione definito nei criteri di inventario.
Configurazione dei criteri su larga scala
È possibile usare un'attività di archiviazione per configurare un criterio di immutabilità su larga scala in più account di archiviazione in base a un set di condizioni definite. Un’attività di archiviazione è una risorsa disponibile in Azioni di archiviazione di Azure; un framework serverless che è possibile usare per eseguire operazioni dei dati comuni su milioni di oggetti in più account di archiviazione. Per altre informazioni, vedere Che cos’è Azioni di Archiviazione di Azure?.
Prezzi
Non sono previsti costi aggiuntivi per l'uso dell'archiviazione non modificabile. Il prezzo dei dati non modificabili è lo stesso dei dati modificabili. Se si usa WORM a livello di versione, la fattura potrebbe essere superiore perché è stato abilitato il controllo delle versioni ed è previsto un costo associato a versioni aggiuntive archiviate. Per altre informazioni, vedere i criteri di prezzi di controllo delle versioni. Per informazioni sui prezzi di Archiviazione BLOB di Azure, vedere la pagina dei prezzi di Archiviazione di Azure.
La creazione, la modifica o l'eliminazione di un criterio di conservazione basato sul tempo o di un blocco a fini giudiziari in una versione dei BLOB comporta un addebito per la transazione di scrittura.
Se non si paga la fattura e l'account ha un criterio di conservazione attivo basato sul tempo, i normali criteri di conservazione dei dati vengono applicati come previsto nei termini e nelle condizioni del contratto con Microsoft. Per informazioni generali, vedere Gestione dei dati in Microsoft.
Supporto funzionalità
Questa funzionalità non è compatibile con il ripristino temporizzato e l'ultimo rilevamento degli accessi. Questa funzionalità è compatibile con il failover non pianificato gestito dal cliente, tuttavia, le modifiche apportate ai criteri non modificabili dopo l'ultima sincronizzazione (ad esempio il blocco di un criterio di conservazione basato sul tempo, l'estensione e così via) non verranno sincronizzate con l'area secondaria. Al termine del failover, è possibile ripetere le modifiche apportate all'area secondaria per assicurarsi che sia aggiornato con i requisiti di immutabilità. I criteri di immutabilità non sono supportati negli account in cui è abilitato il protocollo NFS (Network File System) 3.0 o SSH File Transfer Protocol (SFTP).
Alcuni carichi di lavoro, ad esempio Backup SQL nell'URL, creano un BLOBe lo aggiungono. Se un contenitore ha un criterio di conservazione basato sul tempo attivo o un blocco legale, questo criterio non avrà esito positivo. Per altri dettagli, vedere Consenti scritture BLOB di accodamento protette.
Per informazioni vedere Supporto delle funzionalità di archiviazione BLOB negli account di archiviazione di Azure.