Storage WORM e legal hold: quando sono necessari archivi a scrittura singola
La maggior parte degli archivi documentali è mutabile. Un file memorizzato su un file system standard o su un object store può essere sovrascritto, eliminato o modificato silenziosamente da chiunque abbia le autorizzazioni appropriate, inclusi gli amministratori di sistema. Per la maggior parte degli scopi operativi, va bene. Per la conservazione regolamentata dei documenti, crea un problema: non si può affermare credibilmente che un documento archiviato non è stato alterato se il sistema che lo memorizza avrebbe potuto alterarlo.
Lo storage WORM e il legal hold sono i due meccanismi che affrontano questo problema a livello di storage.
Cosa significa WORM
WORM è l’acronimo di Write Once, Read Many (scrivi una volta, leggi molte volte). Un sistema di storage WORM accetta una scrittura esattamente una volta per ogni oggetto. Dopo che la scrittura è stata confermata, l’oggetto non può essere modificato, sovrascritto o eliminato fino alla scadenza del periodo di conservazione configurato.
Si tratta di un vincolo fisico o logico a livello di storage, non di un criterio di controllo degli accessi. La differenza è importante: un criterio di controllo degli accessi può essere modificato da un amministratore. Un vincolo WORM non può essere aggirato riconfigurando le autorizzazioni, perché la proprietà write-once è applicata dal sistema di storage stesso, non da uno strato di criteri sopra di esso.
WORM hardware: i supporti ottici (CD-R, BD-R), alcuni formati di nastro enterprise e array di dischi WORM specializzati lo applicano a livello fisico. Una volta scritti, i dati non possono essere alterati indipendentemente dal software in esecuzione.
WORM su object storage (applicato via software): la maggior parte dei moderni object store compatibili con S3 supporta una modalità “Object Lock” che implementa la semantica WORM via software. Quando Object Lock è abilitato con una data di conservazione, l’API di storage rifiuta le richieste di eliminazione e sovrascrittura per quell’oggetto fino alla scadenza del periodo di conservazione, anche per richieste effettuate con credenziali amministrative.
Modalità di conservazione
Gli object store con capacità WORM offrono tipicamente due modalità di conservazione:
Governance mode: gli amministratori con un’autorizzazione specifica possono ignorare il blocco di conservazione. Utile per correggere errori durante la configurazione iniziale del periodo di conservazione. Non adatta agli archivi regolamentati perché preserva la capacità di override amministrativo.
Compliance mode: nessun utente, incluso l’account root, può eliminare o modificare l’oggetto prima della data di conservazione. Il periodo di conservazione può essere esteso ma non ridotto. Questa è la modalità richiesta per la conformità normativa nella maggior parte delle giurisdizioni.
La distinzione è significativa durante gli audit. Un revisore che chiede “questo documento avrebbe potuto essere modificato dopo l’archiviazione?” dovrebbe ricevere la risposta “no, tecnicamente impossibile” e non “no, solo gli amministratori avrebbero potuto, e ci fidiamo dei nostri amministratori.”
Cosa significa legal hold
Il legal hold (anche chiamato litigation hold) è un meccanismo separato dalla conservazione. La conservazione definisce per quanto tempo un documento deve essere conservato. Il legal hold sospende l’eliminazione per un documento specifico indipendentemente dal fatto che il periodo di conservazione sia scaduto.
Quando un’organizzazione riceve un ordine del tribunale, un’indagine regolatoria, o viene informata di un potenziale contenzioso, ha l’obbligo di preservare tutti i documenti pertinenti. Il legal hold applica automaticamente questa conservazione: i documenti sotto hold non possono essere eliminati anche se il loro standard periodo di conservazione è scaduto.
Il hold viene revocato con un rilascio esplicito, tipicamente da parte del consulente legale, una volta risolta la questione.
Operativamente, il legal hold richiede di etichettare i documenti a livello di metadati e di avere il sistema di storage che applica il tag. Nell’object storage con capacità WORM, questo viene solitamente implementato come un flag di hold indefinito accanto al periodo di conservazione temporizzato.
Quando è richiesto WORM
I requisiti normativi per lo storage immutabile sono specifici per settore ma sempre più comuni.
Servizi finanziari (UE): MiFID II richiede che i registri delle transazioni e delle comunicazioni siano conservati in un formato che impedisce la modifica. Il requisito è esplicitamente per lo storage a prova di manomissione, che il WORM soddisfa. I periodi di conservazione sono cinque anni per la maggior parte dei registri delle transazioni, sette anni per alcune categorie.
Sanità: Il GDPR combinato con le norme specifiche del settore (in Germania, il Patientendatenschutzgesetz) richiede che le cartelle cliniche siano conservate per 10-30 anni a seconda del tipo, in una forma che garantisce l’integrità. Il WORM è l’implementazione più difendibile.
Settore pubblico: Molte normative sugli appalti degli Stati membri dell’UE richiedono che la documentazione contrattuale sia archiviata in forma immutabile per la durata del periodo di prescrizione più il periodo di conservazione, che può superare i 15 anni.
Contabilità (GoBD, Germania): La GoBD richiede la Unveränderbarkeit (immutabilità) per i documenti contabili archiviati. La guida stabilisce esplicitamente che i documenti archiviati devono essere protetti da successive modifiche. Lo storage WORM soddisfa questo requisito per progettazione.
WORM non sostituisce le catene di hash
Lo storage WORM dimostra che i bit memorizzati non sono cambiati dalla scrittura. Non dimostra quale processo ha prodotto quei bit, o che il processo era corretto.
Una catena di hash dimostra che la sequenza degli eventi di elaborazione era coerente e non modificata. Non impedisce che lo storage sottostante venga modificato (a meno che lo storage non sia anche WORM).
Insieme, affrontano modelli di minaccia diversi:
| Meccanismo | Cosa previene |
|---|---|
| Storage WORM | Modifica o eliminazione post-scrittura dei file archiviati |
| Catena di hash | Falsificazione retroattiva della storia di elaborazione |
| Timestamp RFC 3161 | Retrodatazione di documenti o eventi |
Un archivio a lungo termine pienamente difendibile utilizza tutti e tre: WORM per il livello di storage, catene di hash per la traccia di audit e timestamp RFC 3161 come ancoraggi temporali esterni. Ogni livello chiude le lacune che gli altri lasciano aperte.
Portabilità delle prove
Un rischio specifico degli archivi WORM è il vendor lock-in a livello di storage. Se l’implementazione WORM utilizza un formato proprietario o un’API proprietaria, la migrazione a un provider di storage diverso prima della scadenza del periodo di conservazione potrebbe essere impossibile o legalmente rischiosa.
L’architettura più sicura separa la prova dal meccanismo di storage: la prova (documento + catena di hash + timestamp) è verificabile autonomamente indipendentemente da dove è memorizzata. La proprietà WORM garantisce che non sia stata modificata dopo l’archiviazione, ma il pacchetto di prove dimostra l’integrità anche se la proprietà WORM potesse teoricamente essere aggirata.
Ciò significa che il formato del pacchetto di prove e il formato di storage devono essere scelti indipendentemente. PDF/A-3 per i documenti, JSON standard per le tracce di audit e token RFC 3161 nella loro codifica CMS standard sono tutti indipendenti dal formato. Vengono verificati con strumenti open source senza richiedere il sistema di storage originale.
SealDoc e l’archiviazione immutabile
La modalità di archiviazione di SealDoc scrive i documenti su object storage compatibile con WORM con blocchi di conservazione in modalità compliance. Il periodo di conservazione è configurabile per tipo di documento: sette anni per le fatture, dieci anni per i contratti, periodi personalizzati per i requisiti specifici del settore.
I documenti memorizzati in modalità archivio combinano lo storage WORM con tracce di audit a catena di hash e timestamp RFC 3161, fornendo tre livelli indipendenti di prova contro le manomissioni. Il legal hold può essere applicato tramite l’API e viene revocato solo con un rilascio esplicito.
Il Legal Evidence Pack generato al momento dell’archiviazione è esso stesso memorizzato con conservazione WORM, garantendo che gli artefatti di prova siano immutabili quanto i documenti che coprono.