Gestione della crittografia del nastro e best practice

Voglio abilitare la crittografia su tutti i miei nastri di backup. So più o meno come farlo tecnicamente, ma gli elementi procedurali e umani di attuazione di questo sono difficili.

Uso le unità HP LTO4 con bacula, che non ha alcuna funzionalità di gestione delle chiavi. In effetti, il suo supporto per la crittografia hardware consiste nel chiamare uno script esterno che imposta la chiave sull'unità prima di leggere e scrivere.

Le mie domande:

1. Come devo tenere traccia di quali nastri hanno la crittografia? Ho già alcune centinaia di nastri senza crittografia. Anche se mi prendo il tempo per riscriverli tutti con la crittografia, ci saranno mesi di sovrapposizione in cui alcuni ce l'hanno e altri no. Come farà bacula a sapere se impostare la chiave prima di leggere un determinato nastro? L'unità è abbastanza intelligente da leggere nastri non crittografati anche quando è impostata una chiave?
2. Se la chiave viene mai compromessa, dovremo cambiarla e avremo lo stesso problema del n. 1.
3. Se la chiave viene persa, abbiamo effettivamente perso tutti i nostri backup. Come posso mitigarlo senza aumentare il rischio che sia compromesso?
4. La chiave dovrebbe cambiare regolarmente? Una volta all'anno? Qual è la migliore pratica?
5. In che modo i grandi sistemi di backup ISV gestiscono questi problemi?

Domande molto buone. Anch'io vorrei vedere delle buone risposte da persone che ne sanno di più di me. :-)

3 Se la chiave viene persa, abbiamo effettivamente perso tutti i nostri backup

Proprio per questo motivo molte o la maggior parte delle persone non utilizza backup crittografati.

Un possibile modo di procedere è costruire un paio di "scialuppe di salvataggio", ovvero pacchetti con supporti di installazione, nomi utente e password per sistemi essenziali come backup, Active Directory e altri (ovvero le cose necessarie per caricare un backup se il sito principale è stato completamente distrutto da un incendio, ma non dai dati di backup stessi). È necessario conservare queste scialuppe di salvataggio in modo sicuro fuori sede, ad esempio in un caveau di una banca o in una cassaforte di alta sicurezza in un ufficio remoto con un sistema di allarme. E infine documentalo, in modo che altri possano capire come usare le scialuppe di salvataggio dopo che hai lasciato la compagnia, se necessario.

4 La chiave dovrebbe cambiare regolarmente? Una volta all'anno? Qual è la migliore pratica?

Da un punto di vista pratico, direi di non cambiare i tasti, dato che diventa rapidamente ingestibile se lo fai. Se sei preoccupato che la sicurezza del backup non sia abbastanza buona, allora rinforza la sicurezza fisica attorno ai tuoi nastri, usando un servizio come Iron Mountain o costruendo tu stesso un sistema di archiviazione con una buona sicurezza fisica.

Infine: preferirei avere tutta la crittografia e la gestione dei backup in un unico sistema, quindi c'è meno rischio che il recupero non funzioni. Con questo intendo utilizzare la crittografia integrata in software come Retrospect o Backup Exec, piuttosto che la crittografia a livello di unità.

Uso un FS dm-crypt, crittografandolo con una passphase lunga e potente.

Per evitare di perdere il passfrase, l'ho scritto su una lettera sigillata a cera, l'ho dato alla proprietà dell'azienda e l'ha conservato in una cassaforte.

Ovviamente puoi darlo a un notaio o qualunque cosa tu pensi.

Penso che un passfrase sia migliore per questo lavoro, poiché può essere solo nella mente delle persone autorizzate a conoscerlo, mentre un dispositivo digitale può essere perso, rubato e così via.

Puoi essere torturato, ovviamente :)

Sto rispondendo a questo e lo sto trasformando in un wiki della comunità, dal momento che sto copiando e incollando da un documento esistente.

Per la cronaca, utilizzo Amanda Enterprise come soluzione di backup e non utilizzo la crittografia a nastro fornita, proprio per le ragioni che lei menziona.

Stavo studiando la crittografia del nastro e mi sono imbattuto in un ottimo white paper di HP che parla della crittografia LTO-4 e ho incluso molte possibilità per la gestione delle chiavi. Ecco una carrellata di base delle opzioni disponibili presentate:

• Crittografia in modalità nativa (a volte indicata come imposta e dimentica). Questo metodo controlla la crittografia LTO4 dalla libreria dell'unità nastro. Esiste una chiave impostata tramite l'interfaccia di gestione della libreria (GUO Web o Pannello di controllo operatore). Questo metodo crittografa tutti i nastri con la stessa chiave, con il rovescio della medaglia che influisce negativamente sul livello di sicurezza.

• La crittografia basata su software crittografa i dati prima che escano dal server e le chiavi vengono archiviate nel database interno o nel catalogo dell'applicazione. Questo metodo di crittografia pone un carico elevato sul server poiché il software esegue molte operazioni matematiche utilizzando la potenza di elaborazione dell'host. Diverse applicazioni tra cui HP Open View Storage Data Protector 6.0 offrono la crittografia come funzionalità. Sebbene la sicurezza della data crittografata in questo modo sia molto elevata (poiché i dati sono crittografati in transito), poiché i dati crittografati sono altamente casuali, diventa impossibile ottenere una compressione dei dati a valle nell'unità nastro e quindi l'archiviazione è inefficiente.

• Chiavi gestite dall'applicazione ISV, nota anche come gestione delle chiavi in ​​banda. Il software ISV fornisce le chiavi e le gestisce, quindi l'unità a nastro Ultrium LTO4 esegue la crittografia. Le chiavi verrebbero referenziate dai dati associati alle chiavi e archiviate nel database interno delle applicazioni. (Fare riferimento al proprio fornitore di applicazioni di backup ISV individuale per il supporto di questa funzionalità).

• Un'appliance di crittografia in-band intercetta i collegamenti Fibre Channel e crittografa i dati durante il volo. Questi prodotti sono disponibili presso numerosi fornitori come Neoscale e Decru. La gestione delle chiavi proviene da un'appliance di gestione delle chiavi rafforzata. Questo metodo è indipendente dal software ISV e supporta unità nastro e librerie legacy. La compressione dei dati deve essere eseguita da questi dispositivi poiché la compressione all'interno dell'unità nastro non è possibile dopo la crittografia.

• Uno switch fabric SAN con funzionalità di crittografia è simile all'appliance in-band, ma l'hardware di crittografia è incorporato nello switch.

• Un'appliance di gestione delle chiavi funziona con librerie di classe enterprise come le librerie HP StorageWorks EML ed ESL serie E. È noto come gestione delle chiavi fuori banda, poiché la chiave viene fornita all'unità nastro dall'appliance di gestione delle chiavi. La Figura 8 mostra i componenti di base di un'appliance di gestione delle chiavi. Le applicazioni di backup non sono a conoscenza della capacità di crittografia dell'unità a nastro. Le chiavi vengono fornite al controller della libreria a nastro tramite una connessione di rete mediante un protocollo SSL (Secure Sockets Layer), recentemente rinominato Transport Layer Security (TLS). Questa è una connessione crittografata necessaria per proteggere la sicurezza delle chiavi in ​​transito dall'appliance. Per impostare la sicurezza, un certificato digitale viene installato nell'hardware di gestione della libreria. Ciò stabilisce la connessione sicura necessaria. L'installazione di SSL / TLS utilizza la crittografia della chiave pubblica, ma al termine dell'handshake, passa una chiave segreta per crittografare il collegamento. Quando vengono ripristinati i nastri, i dati associati alla chiave (recuperati dal nastro) vengono utilizzati per fare riferimento alla richiesta della chiave corretta per decrittografare il nastro indipendentemente dall'applicazione di backup.

Ciò che ci manca davvero è, ovviamente, ciò che stanno facendo le persone nel mondo reale. I white paper sono fantastici, ma ciò non riflette necessariamente la realtà.

Inoltre, ho pubblicato questa domanda sul mio blog , quindi alcune risposte o esempi potrebbero anche apparire lì.