La crittografia dell'intero disco su un server in un data center sicuro è inutile?

Due cose generiche che a quanto pare ti sono sfuggite:

• In caso di errore del disco, avere i dati crittografati a riposo risolve il problema di avere dati potenzialmente sensibili su un supporto a cui non si può accedere più. Rende più facile e meno costoso lo smaltimento di unità difettose (ed è un problema in meno)

• La crittografia completa del disco rende anche più difficile per un utente malintenzionato recuperare i dati dallo spazio "vuoto" sulle unità (che spesso contiene tracce di dati precedentemente validi)

E se usi le macchine virtuali:

• La crittografia della partizione ti rende meno dipendente dalla sicurezza del tuo hypervisor: se in qualche modo il contenuto grezzo di una delle tue unità "perde" su un'altra VM (che potrebbe accadere se lo spazio su disco viene riallocato su un'altra VM e non azzerato) ), che VM avrà meno probabilità di accedere ai dati effettivi (dovrebbe ottenere anche la chiave di decodifica).

Se la chiave di decrittografia è memorizzata in chiaro sullo stesso supporto dei dati crittografati, la crittografia non ha senso. Se si dispone di un insieme di regole, che richiedono che i dati siano crittografati, ma consentono di archiviare la chiave in chiaro sullo stesso supporto, le regole sono imperfette. Se ti trovi di fronte a un insieme di regole così imperfetto, dovresti indicare il difetto.

Se la chiave non è memorizzata sullo stesso supporto dei dati. Quindi la crittografia ha uno scopo. Ciò tuttavia solleva la domanda su dove il server ottiene la chiave all'avvio. Ci sono alcune opzioni:

• Richiedi una password da inserire durante l'avvio. Questo non è molto pratico per un server.
• Recupera la chiave di decodifica da un server delle chiavi. Questo può impedire la decifrazione dei dati in caso di furto del server, richiede semplicemente che il server delle chiavi risponda solo alle richieste provenienti dal centro dati.
• Segreto condivide la chiave su più dischi. Non fa nulla per il caso in cui il server viene rubato. Ma se si dispone di un RAID in cui occasionalmente vengono sostituiti singoli dischi, garantisce che tutti i dati lasciati sui dischi restituiti in garanzia siano correttamente crittografati. Quando un nuovo disco viene aggiunto al RAID, un'implementazione di questa tecnica dovrebbe fare quanto segue:
  • Genera una chiave di crittografia per questo singolo disco.
  • Genera una nuova chiave master.
  • Segreto condivide la nuova chiave principale su tutti i dischi.
  • Su ogni disco scrivere la chiave di crittografia del disco crittografata con la nuova chiave principale.

I tre approcci descritti sopra possono essere combinati. Se sono combinati, il server delle chiavi potrebbe essere implementato utilizzando RSA cieco.

Ci sono attacchi al firmware dei dischi rigidi. Googling per hard drive firmware attack restituirà alcuni risultati su ciò che l'NSA fa o può fare, il che probabilmente non è molto pertinente per te; ma anche gli hobbisti sono in grado di modificare il firmware delle unità. Questo tizio ha persino installato un kernel linux sul suo hard disk - no, non era il PC che girava linux, il disco rigido lo stesso controller lo ha fatto.

Se qualcuno ottiene l'accesso al firmware dei propri dischi (ad esempio, qualcuno affitta un server dal centro dati per un mese, quindi lo restituisce, la società del data center pulisce le unità, quindi assegna a tale server), potrebbero fare in modo che il firmware dell'unità faccia qualcosa del tipo "Ogni volta che un blocco scritto su disco contiene uno schema speciale, per i successivi 5 minuti, in ogni blocco di lettura che inizia con root:$1$ , sostituire i primi byte con (un po 'di hash della password)" , hai un attacco quasi inosservabile. Il tuo file /etc/shadow ti sembrerà normale tranne durante la finestra temporale di 5 minuti dopo che l'utente malintenzionato ha richiesto un file con un nome contenente il pattern di attivazione dal tuo server web, che lo ha scritto nel suo log degli errori.

Improbabile? Sicuro. Impossibile? Sicuramente no. È paranoico presumere che ciò potrebbe accadere? Probabilmente sì, a seconda di quanto siano interessanti i tuoi dati. Ma la crittografia delle unità ti proteggerà da questo tipo di attacco e non ti costerà nulla se non alcuni cicli di CPU. E, se ci sono leggi o regolamenti da seguire, in caso di una violazione della sicurezza, di certo non voglio essere nella posizione di poter spiegare perché ho pensato che non avrebbe importanza.

Considera cosa intendi per data center "sicuro".

In generale, non considero nulla di sicuro contro un aggressore determinato e dotato di risorse. È vero, avere 18 "di cemento armato, doppie trappole per uomini e sicurezza armata fornisce una buona dose di protezione, ma è raro che questa protezione sia tutta per te. Nella maggior parte delle strutture di co-location, l'unica cosa che ti protegge da un persona con $ 500 e conoscenze sufficienti per affittare spazio rack nella stessa struttura in cui si trova una gabbia di sicurezza sospetta con un dispositivo a tre spinotti.

Occasionalmente, i disastri naturali e provocati dall'uomo invadono le cose, riducono il potere, avvelenano i rifornimenti idrici e fanno ogni sorta di cose insolite che fanno sì che le guardie di sicurezza ei tecnici non si presentino al lavoro o vadano a casa dalle loro famiglie - cosa ho Diciamo che i data center forniscono solo un livello di sicurezza che probabilmente non è tanto quanto pensano molti dei loro clienti.

Riconsidera la tua posizione a basso rischio di perdita di unità da parte del tuo imprenditore dismesso.

Un certificato di distruzione autorizza anche te ..... il $ 20 che hai pagato per distruggere un disco che non è stato effettivamente distrutto?

Hai visitato il tuo impianto di smaltimento delle unità? Controllato le loro procedure di assunzione? Visto le loro garanzie? Assicurati di essere assolutamente sicuro su questo perché è una delle vulnerabilità più ovvie - un cambiamento nella custodia.

Quindi, non è affatto quello che hai chiesto, che dire della minaccia interna che hai effettivamente chiesto.

Ok, un insider avrebbe accesso tramite il tuo FDE e vedrebbe i file non criptati. Nel tuo scenario FDE, non farà nulla per fermare o rallentare l'insider da ottenere i dati.

Quello che farà è canalizzare la tua minaccia interna per passare attraverso il tuo FDE, che ti permetterebbe di accedere, monitorare e identificare un colpevole, o almeno un sospetto. Essere in grado di identificare il tuo aggressore è un livello di sicurezza.

Ma sono abbastanza sicuro che la canalizzazione non è principalmente ciò che serve per FDE. Anche se hai FDE puoi ancora implementare un altro livello di file o altra crittografia dei dati su FDE. Puoi anche utilizzare i controlli di accesso del sistema operativo.

FDE protegge dagli addetti ai lavori che non hanno accesso tramite FDE. Protegge contro i tecnici dei server che sostituiscono le unità che ne assumono una e fanno i conti con i dati. Protegge contro un dipendente della struttura del server che ne preleva uno da un container di spedizione presso la tua struttura in attesa del trasporto al tuo contraente di distruzione.

FDE ti offre un altro livello per bloccare anche le minacce interne, se segreggi la tua fattoria o usi l'accesso granulare - ad esempio i tuoi interni hanno solo accesso a determinati server, ecc. FDE impedirebbe loro semplicemente di copiare le unità all'ingrosso che non fanno avere accesso tramite FDE per.

In poche parole, FDE protegge i dati sull'unità dall'accesso fisico all'unità. Puoi provare a controllare l'accesso fisico tutto quello che desideri, ma le unità si troveranno sempre con qualche vulnerabilità (essere rubate da addetti ai lavori, essere copiate da addetti ai lavori, passare in custodia dove gli addetti ai lavori lo toccano, non sorvegliate a causa di un disastro, ecc. ). Se le persone toccano il disco, FDE è uno strato di difesa contro di esso.

David

Non sicuramente. Dipende da, contro ciò che vuoi difendere. Alcuni esempi:

• Se vivi in un Paese, dove il governo può confiscare il tuo server per analizzarne il contenuto e poi usarlo contro di te o il tuo datore di lavoro.
• Se sei il proprietario del server, ma non gli darai la possibilità che il tuo dipendente / collegiale abbia accesso fisico ad esso, che lo rubano / rispecchiano il suo contenuto. Quindi abilitali a eseguire il servizio / avviarlo, ma non fornire loro le chiavi di crittografia.
• Lo stesso potrebbe essere una protezione efficace se non puoi / non ti fideresti della soluzione di hosting del tuo server.

Dipende dalle circostanze. Queste circostanze che ho mostrato come esempio, sono almeno non comuni nel mio ambiente, ma potrebbero essere possibili.

Se ti trovi in un normale ambiente di lavoro, non farlo. Ha richiesto un sacco di ore di lavoro e ha un tempo di assistenza prolungato. A mio parere, nella maggior parte dei casi non vale il suo prezzo.

Citazione: "... hanno fatto poco o niente a ridurre effettivamente il rischio associato a dati non criptati ..."

Ok, sì, penso che tu abbia ragione. La semplice risposta è "non ha senso", ma "non è neanche inutile". Ecco perché, e perdonami per averlo detto, penso che potresti essere abbaiare sull'albero sbagliato. Lasciatemi spiegare. La crittografia completa del disco (FDE) ha un qualche scopo - anche se è solo per un sottoinsieme di exploit che hanno bassa probabilità. Ci sono un certo numero di possibili exploit - e la probabilità BASSA non è uguale a NO probabilità.

Quindi, è inutile? Non del tutto. Ma perché stai litigando? Vuoi prestare più attenzione alla sicurezza quando i server sono in esecuzione e i dati non sono crittografati? Questo entra nella regione in cui i fatti potrebbero farti meno bene, e un senso di politica potrebbe darti una buona posizione.

Potrebbe essere che il tuo obiettivo in questa discussione al lavoro sia stabilire la tua esperienza. O forse c'è qualcosa che pensi che abbia bisogno di fare, e nessuno sta prestando attenzione. Tutto quanto sopra è valido e ragionevole, e parte dell'ambiente di lavoro quotidiano. Potrei fraintendere la tua domanda, ma mi sembra che potresti ottenere un risultato migliore argomentando per l'azione che pensi debba essere fatta, piuttosto che contro un'azione che viene fatta. Scegli i tuoi combattimenti.

Dalla tua descrizione, sospetto la tua corretta. Cioè, la crittografia completa del disco non aggiunge alcuna protezione reale per i dati su un server in esecuzione nel caso qualcuno dovesse compromettere tale server per estrarre i dati. Questo non è ciò che la crittografia del disco completo è progettata per raggiungere. Tuttavia, questo non significa che non vi è alcun caso per avere la crittografia completa del disco su un server. Come sottolineato in altri post, ci sono buone ragioni per avere la crittografia completa del disco su un server, come la protezione contro il furto, un controllo efficace per lo smaltimento del disco o la necessità di restituire dischi non funzionanti al fornitore ecc. Tuttavia, se è necessario proteggere i dati sul server quando è in esecuzione, in genere è necessaria la crittografia di file, tabelle, ecc. oltre alla crittografia del disco - non è necessariamente una / o situazione.

L'altra cosa da considerare è che la sicurezza riguarda gli strati di protezione. Suggerendo di avere dei buoni controlli per lo smaltimento dei dischi e quindi non è necessario il pieno cifraggio del disco, si presume che i controlli utilizzati nello smaltimento dei dischi non falliranno mai. Tuttavia, questi tipi di controlli hanno solitamente un alto contenuto procedurale e umano - si basa pesantemente sull'amministratore seguendo la procedura correttamente. Nella mia esperienza, questi sono i tipi di controlli che hanno maggiori probabilità di fallire. Potrebbe essere quel nuovo dipendente che dimentica o non è a conoscenza della procedura, potrebbe essere che l'amministratore di sistema esperto si occupi di un guasto ad alta pressione in cui il capo lo sta facendo pressioni per ottenere il backup del servizio ASAP ecc. Avere crittografia completa del disco è semplicemente un altro controllo protettivo che toglie parte della pressione al personale e riduce il possibile impatto da un semplice errore umano.

Dove le cose vanno male con la cifratura completa del disco si ha quando le persone pensano che risolva più problemi di quanti ne faccia effettivamente - questo sembrerebbe essere il valore del tuo argomento / preoccupazione. Ho visto molti venditori e persino amministratori che convincono il management che i dati sono sicuri semplicemente perché utilizza la crittografia completa del disco. Di conseguenza, vengono eseguite poche o eventuali analisi di rischio reali per quanto riguarda i rischi quando il server è in esecuzione. Recentemente ho fatto un grande progetto di archiviazione dei dati per un cliente che ha coinvolto dati potenzialmente sensibili e / o preziosi. Era abbastanza sorprendente il numero di venditori che non rispondevano correttamente alle domande di crittografia. La loro risposta è stata che "è ok, il sistema utilizza la crittografia completa del disco". Una volta eseguito il drill down e fornito esempi e chiesto come la loro crittografia completa del disco potesse proteggere da vari scenari per un server in esecuzione, la loro risposta generale era "Oh, questo è un problema che l'applicazione deve risolvere".

Per me, il problema più grande che ho incontrato sia con la crittografia completa del disco sia con la crittografia a livello di file / tabella è la frequente mancanza di una reale considerazione per quanto riguarda la gestione delle chiavi. Per me, la maggior parte delle soluzioni sembra debole nel supporto per consentire una gestione delle chiavi coerente e affidabile. Ci sono state molte volte in cui ho visto un sistema in cui mi è stato detto tutto il meraviglioso uso della crittografia per proteggere i dati solo per scoprire che le chiavi utilizzate sono scarsamente protette - quasi un ripensamento. Peggio ancora, a causa della mancanza di un approccio valido o comprensibile, ci si imbatte in data center in cui la stessa chiave viene utilizzata in più punti o su più livelli solo in modo che gli amministratori possano gestirli in modo efficace ed essere in grado di recuperare quando necessario.

Grazie a tutti per il feedback. In breve, la domanda per il titolo è FDE per un server in un centro dati sicuro inutile? La risposta non è necessariamente come potrebbero esserci scenari in cui si vorrebbe la protezione aggiuntiva sui dispositivi fisici. Ad esempio, protezione durante la distruzione, protezione dal paese ospitante o protezione in caso di guasto del disco tra le altre situazioni.

Nel testo la domanda è stata in qualche modo modificata rispetto a quella dichiarata nel titolo. La preoccupazione nella domanda principale era che i dati venivano compromessi non attraverso l'accesso fisico al server ma l'accesso logico ai dati. In base alle risposte, sembra che FDE non fornisca questa protezione. La soluzione è trasparente per l'utente in cui i dati vengono decodificati sul server all'avvio. A quel punto ci si può affidare ad altri controlli come firewall, buona gestione degli accessi, autenticazione strong e patch.

La mia preferenza è che oltre a quei controlli per la crittografia a livello di file o di campo da utilizzare con l'accesso alle chiavi di crittografia viene limitato per fornire un ulteriore livello di sicurezza.

Una cosa che non ho visto menzionato è che ho sentito che FDE può anche fornire protezione da alcuni tipi di malware che potrebbero copiare le informazioni a livello di programmazione. Tuttavia, non sono stato in grado di confermare questa affermazione attraverso la ricerca.

Ecco altri 2 vantaggi (supponendo che si utilizzino nuove chiavi di crittografia ogni volta che si reinstalla):

• Se si eseguono strumenti di recupero file che eseguono la scansione del dispositivo a blocchi completo, ad es. PhotoRec, non devi controllare tonnellate di vecchi file che non ti interessano più.

• Se si eseguono strumenti di riparazione del filesystem che eseguono la scansione del dispositivo a blocchi completo, non si corre il rischio di confondere strutture e metadati di un vecchio filesystem con quello corrente.

JJ