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, gli istituti finanziari e i settori correlati, in particolare le organizzazioni broker-dealer, a archiviare i dati in modo sicuro. L'archiviazione non modificabile può essere usata 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 consente alle organizzazioni di affrontare edizione Standard C 17a-4(f), CFTC 1.31(d), FINRA e altre normative.
Conservazione sicura dei documenti: l'archiviazione non modificabile per i BLOB garantisce che i dati non possano essere modificati o eliminati da nessun utente, nemmeno dagli utenti con privilegi amministrativi dell'account.
Blocco legale: l'archiviazione non modificabile per i BLOB consente agli utenti di archiviare informazioni riservate critiche per controversia legale o uso aziendale in uno stato di prova di manomissione per la durata desiderata 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 edizione Standard C 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 dei servizi 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.
- 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. I singoli BLOB non possono essere configurati con i propri criteri di immutabilità.
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 è uguale alla differenza tra l'ora di creazione del BLOB e l'intervallo di conservazione specificato dall'utente. Poiché l'intervallo di conservazione di un criterio può essere 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 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 del test, è possibile bloccare i criteri in modo che siano completamente conformi a edizione Standard C 17a-4(f) e ad altri requisiti normativi.
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 si trova in uno stato non modificabile conforme (scrittura ed eliminazione protetta) per edizione Standard C 17a-4(f) e 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 diverso dai test a breve termine.
Registrazione di controllo dei criteri di conservazione
Ogni contenitore con criteri di conservazione basati sul tempo abilitato fornisce un log di controllo dei criteri. Il log di controllo 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. Il log di controllo viene conservato per la durata dei criteri in conformità alle linee guida normative edizione Standard C 17a-4(f).
Il log attività di Azure offre un log 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. I singoli BLOB non possono essere configurati con i propri criteri di immutabilità.
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 controllo dei criteri. Il log contiene l'ID utente, il tipo di comando, i timestamp e i tag di blocco a fini giudiziari. Il log di controllo viene conservato per la durata dei criteri in conformità alle linee guida normative edizione Standard C 17a-4(f).
Il log attività di Azure offre un log 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 diversi 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 Archiviazione Gen2 (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 vogliono 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 vogliono 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 vuole gestire l'abilitazione del controllo delle versioni a causa del costo o perché il carico di lavoro crea numerose versioni aggiuntive da gestire. | Si vuole 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. |
| Archiviazione percorso (Archiviazione BLOB e Data Lake Archiviazione Gen2) | Il carico di lavoro è interamente incentrato su Azure Data Lake Archiviazione Gen2. Non si ha alcun interesse immediato o si prevede di passare all'uso di un account che non dispone della funzionalità dello spazio dei nomi gerarchico abilitata. | Il carico di lavoro si trova nel BLOB Archiviazione in un account che non dispone della funzionalità dello spazio dei nomi gerarchico abilitato e può 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 Archiviazione Gen2). |
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. 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 quindi 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à
Archiviazione di Azure inventario BLOB 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 giornaliero. Il report fornisce una panoramica dei dati per i requisiti aziendali e di conformità.
Per altre informazioni sull'inventario BLOB, vedere Archiviazione di Azure inventario BLOB.
Nota
Non è possibile configurare criteri 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.
Prezzi
Non sono previsti costi aggiuntivi per l'uso dell'archiviazione non modificabile. I dati non modificabili vengono addebitati allo stesso modo 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 un blocco legale in una versione BLOB comporta un addebito per le transazioni 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. 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 BLOB e quindi lo aggiungono. Se un contenitore ha un criterio di conservazione basato sul tempo attivo o un blocco legale, questo modello non avrà esito positivo. Per altri dettagli, vedere Consenti scritture BLOB di accodamento protette.
Per altre informazioni, vedere Supporto delle funzionalità di Archiviazione BLOB negli account Archiviazione di Azure.