• Cloud, Guide, Sicurezza
• 5 Marzo 2022

La protezione dei dati in Azure Storage si riferisce alle strategie per proteggere l’account di archiviazione e i dati al suo interno dall’eliminazione o dalla modifica o per il ripristino dei dati dopo l’eliminazione o la modifica. Azure offre anche opzioni per il ripristino di emergenza, tra cui più livelli di ridondanza per proteggere i dati dalle interruzioni del servizio a causa di problemi hardware o calamità naturali e il failover gestito dal cliente nel caso in cui il data center nell’area primaria diventi non disponibile.

Tra le tante funzionalità di protezione degli Storage Account o di Azure Data Lake vi raccomando:

• Utilizzo dei Lock per prevenire la modifica o la cancellazione degli Azure Storage Account.
• Abilitazione del soft delete per i container degli Azure Storage Account.
• Salvataggio ad intervalli regolari dei BLOB (Binary Large Object) utilizzando il blob versioning nei Blob Storage workloads, in modo tale che venga salvato lo stato dei dati ogni volta che il dato viene sovrascritto.
• Creazione di snapshot manuali per gli Azure Data Lake Storage workloads, in modo tale da salvare lo stato dei dati in un particolare momento.

Figura 1: Configurazione della Data Protection durante la creazione dell’Azure Storage Account

Figura 2: Funzionalità di protezione dei Blob Service

Soft delete per i containers

Container soft delete protegge i dati dall’eliminazione accidentale mantenendo i dati eliminati nel sistema per un periodo di tempo specificato. Durante il periodo di conservazione, è possibile ripristinare lo stato di un contenitore eliminato in modo soft e il relativo contenuto al momento dell’eliminazione. Dopo la scadenza del periodo di conservazione, il contenitore e il relativo contenuto vengono eliminati definitivamente.

Il periodo di retention può variare tra 1 e 365 giorni e può essere abilitato e modificato in qualsiasi momento dal portale nella pagina Data protection dello Storage Account.

Figura 3: Principio di funzionamento per il soft delete per i containers

Soft delete per i blobs

Blob soft delete protegge un singolo Blob e le relative versioni, snapshot e metadati da eliminazioni o sovrascritture accidentali mantenendo i dati eliminati nel sistema per un periodo di tempo specificato. Durante il periodo di conservazione, è possibile ripristinare lo stato del BLOB al momento dell’eliminazione. Dopo la scadenza del periodo di conservazione, il BLOB viene eliminato definitivamente.

Il periodo di retention può variare tra
1 e 365 giorni e può essere abilitato e modificato in qualsiasi momento dal portale nella pagina Data protection dello Storage Account. Il periodo inizia nel momento in cui l’oggetto viene eliminato o sovrascritto.

Figura 4: Principio di funzionamento per il soft delete per i blobs

Blob versioning

Si può abilitare il Blob storage versioning  per mantenere automaticamente le versioni precedenti di un oggetto. Quando il controllo delle versioni dei Blob è abilitato, è possibile accedere alle versioni precedenti di un blob per ripristinare i dati se vengono modificati o eliminati.

Una versione acquisisce lo stato di un BLOB in un determinato momento. Ogni versione viene identificata con un ID versione. Quando il controllo delle versioni del Blob è abilitato per un account di archiviazione, Azure Storage crea automaticamente una nuova versione con un ID univoco quando viene creato un Blob per la prima volta e ogni volta che il Blob viene modificato successivamente.

Le versioni dei Blob non sono modificabili e non è possibile modificare il contenuto o i metadati di una versione del BLOB esistente. Maggiori informazioni sono disponibili alla pagina Blob versioning – Azure Storage | Microsoft Docs

Figura 5: Principio di funzionamento per il blob versioning

Nella figura sotto sono mostrate le configurazioni che è possibile effettuare relative a soft delete for blobs, soft delete for containers e versioning for blobs.

Figura 6: Gestione della Data protection per gli Azure Storage Account

Change feed support in Azure Blob Storage

Lo scopo del Change feed è fornire i log delle transazioni di tutte le modifiche apportate ai Blob e ai metadati del Blob nell’account di archiviazione. Il Change feed fornisce un log ordinato, garantito, durevole, non modificabile e di sola lettura di queste modifiche. Le applicazioni possono leggere questi log in qualsiasi momento, in streaming o in modalità batch.

Il Change feed viene archiviato come Blob in un contenitore speciale nell’account di archiviazione, allo stesso costo standard dei Blob . È possibile controllare il periodo di conservazione (retention) di questi file in base ai propri requisiti.

È possibile elaborare questi log in modo asincrono, incrementale o completo.

Figura 7: Il diagramma illustra come vengono aggiunti i record al Change feed

È necessario abilitare il Change feed nell’account di archiviazione per iniziare ad acquisire e registrare le modifiche. Questa operazione può essere fatta sia al momento della creazione dell’Azure Storage Account che successivamente, dalla sezione Data protection.

Figura 8: Abilitazione del Change feed per l’Azure Storage Account

Point-in-time restore per i block blobs

Il Point-in-time restore permette di proteggere i block blobs dalla cancellazione o dalla corruzione del dato, abilitando la possibilità di ripristinarli ad uno stato precedente.

I Point-in-time restore sono disponibili solo negli Azure Storage account general purpose v2 e nel tier Standard. Inoltre, possono essere ripristinati solo i dati che si trovano nell’access tier Hot o Cool, ma non quelli nell’access tier Archive.

Prima di poter abilitare questa funzionalità è necessario abilitare:

• Soft delete
• Change feed
• Blob versioning

Figura 9: Principio di funzionamento del Point-in-time restore

Figura 10: Abilitazione della funzionalità Point-in-time restore per l’Azure Storage Account

Immutable storage per Azure Blob Storage

Immutable storage per Azure Blob Storage consente agli utenti di archiviare i dati business critical in uno stato WORM (Write Once, Read Many). In uno 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 sovrascrittura ed eliminazioni.

Sono supportate due tipi di immutable policy:

• Time-based retention policy: gli utenti possono impostare criteri per archiviare i dati per un intervallo specificato. Quando viene impostato un criterio di conservazione basato sul tempo, gli oggetti possono essere creati e letti, ma non modificati o eliminati. Dopo la scadenza del periodo di conservazione, gli oggetti possono essere eliminati ma non sovrascritti.
• Legal hold policy: Con questi criteri i dati non saranno modificabili fino a quando il blocco a termine (legal hold) non viene esplicitamente cancellato. Quando viene impostato un blocco a termine, gli oggetti possono essere creati e letti, ma non modificati o eliminati.

Il diagramma seguente illustra come i criteri di conservazione basati sul tempo e i blocchi a livello legale impediscono le operazioni di scrittura ed eliminazione mentre sono in vigore.

Figura 11: Principio di funzionamento delle policy di time-base retention e di legal hold dell’Immutable storage per Azure Blob Storage

Le applicazioni tipiche per gli immutable storage sono:

• Conformità alle normative: consente alle organizzazioni di essere conformi a normative che prevedono la preservazione del dato.
• Conservazione sicura dei documenti: garantisce che i dati non possano essere modificati o eliminati da alcun utente, nemmeno dagli utenti con privilegi amministrativi dell’account.
• Blocco a livello legale: consente agli utenti di archiviare informazioni riservate o di mantenerle in uno stato a 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 pensata come un blocco basato su eventi o un blocco aziendale, in cui è necessario proteggere i dati.

NOTA: Per configurare criteri di immutabilità che hanno come ambito una versione blob (blob versioning), è necessario abilitare il supporto per l’immutabilità a livello di versione nell’account di archiviazione o in un contenitore, che può essere fatto solo al momento della loro creazione.

Nelle figure sotto viene mostrato come abilitate il version-level immutability support sia per lo Storage Account che per il singolo container.

Figura 12: Il version-level immutability support non è disponibile per l’account di archiviazione in quanto deve essere abilitato al momento della creazione dello storage account

Figura 13: Il version-level immutability support è disponibile solo al momento della creazione del container

Time-based retention policies per i dati immutable blob

Una time-based retention policy conserva i dati Blob in un formato WORM (Write-Once, Read-Many) per un intervallo specificato. Quando è impostato un criterio di conservazione basato sul tempo, i client possono creare e leggere i Blob, ma non possono modificarli o eliminarli. Dopo la scadenza dell’intervallo di conservazione, i Blob possono essere eliminati ma non sovrascritti.

L’intervallo di conservazione per un criterio di conservazione basato sul tempo è tra 1 giorno e 146.000 giorni (400 anni).

Quando si configurano criteri di conservazione basati sul tempo, gli oggetti interessati rimarranno nello stato non modificabile per la durata del 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.

Maggiori approfondimenti sono disponibili alla pagina Time-based retention policies for immutable blob data – Azure Storage | Microsoft Docs

Configurare le immutability policies for blob versions

I contenitori nuovi ed esistenti possono essere configurati per supportare l’immutabilità a livello di versione. Tuttavia, un contenitore esistente deve essere sottoposto a un processo di migrazione per abilitare il supporto.

NOTA: Tenete presente che l’abilitazione del supporto dell’immutabilità a livello di versione per un contenitore non rende i dati in tale contenitore non modificabili.

Per usare criteri di immutabilità a livello di versione, è prima necessario abilitare in modo esplicito il supporto per WORM a livello di versione nel contenitore. Successivamente dal portale di Azure si potrà creare una Time-based retention policies per i dati immutable blob

Per maggiori informazioni vi invito a leggere l’articolo Configure immutability policies for blob versions – Azure Storage | Microsoft Docs

NOTA: Se avete abilitato la version-level immutability per il container non sarà possibile creare una legal hold policy ma solo una time retention policy.

Figura 14: Creazione di una Time Retention policy per l’immutable blob storage

Figura 15: Retention policy a livello di versione creata

Legal holds per gli immutable blob

Il Legal Hold è un criterio di immutabilità temporaneo che può essere applicato a scopo 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 i blocchi non vengono cancellati in modo esplicito. Quando è attivo un blocco legale, i Blob possono essere creati e letti, ma non modificati o eliminati.

Quando viene applicato un blocco a un contenitore, tutti i Blob esistenti passano a uno stato WORM non modificabile in meno di 30 secondi. Anche tutti i nuovi Blob caricati in tale contenitore protetto da criteri verranno spostati in uno stato non modificabile. Quando tutti i Blob sono in uno stato non modificabile, le operazioni di sovrascrittura o eliminazione nel contenitore non modificabile non sono consentite.

Un blocco a livello di contenitore deve essere associato a uno o più tag alfanumerici definiti dall’utente, che fungono da stringhe identificatore. Ad esempio, un tag può includere un ID caso o un nome di evento.

Trovate maggiori informazioni alla pagina Legal holds for immutable blob data – Azure Storage | Microsoft Docs

Creazione delle Immutable Storage policy

La creazione delle Immutable Storage policy è molto semplice e si può fare a livello di container.

Nelle figure sotto è mostrato come creare sia una Legal Hold immutable storage policy che una Time-retention immutable storage policy.

Figura 16: Aggiunta di una Legal Hold policy al Container

Figura 17: Aggiunta di una Time retention policy al container

Figura 18: Immutability policies aggiunte al container

NOTA: Non ci sono differenze di prezzo per quanto riguarda l’immutable storage e i dati immutabili vengono addebitati come i dati modificabili. In più tutti i livelli di accesso Blob supportano l’archiviazione non modificabile.

Conclusioni

Le diverse modalità di proteggere gli Azure Storage Account ci permettono di essere sicuri che i nostri dati siano protetti sia dalla cancellazione accidentale che dalla manomissione, sia da parte degli utenti malintenzionati che dei ransomware. L’archiviazione non modificabile consente alle organizzazioni sanitarie, agli istituti finanziari e ai settori correlati, di archiviare i dati in modo sicuro e può essere sfruttata in qualsiasi scenario per proteggere i dati critici da modifiche o eliminazioni.