Due cose generiche che apparentemente ti sei perso:

• In caso di guasto del disco, avere i dati crittografati a riposo risolve il problema di avere dati potenzialmente sensibili su un supporto che puoi " Non accedere più. Rende lo smaltimento delle unità difettose più facile ed economico (ed è un problema in meno)

• La crittografia dell'intero disco rende anche più difficile per un utente malintenzionato recuperare i dati dallo spazio "vuoto" su le unità (che spesso contengono tracce di dati precedentemente validi)

E se stai usando VM:

• Crittografare la partizione ti fa meno dipendente dalla sicurezza del tuo hypervisor: se in qualche modo il contenuto grezzo di una delle tue unità "trapela" a un'altra VM (cosa che potrebbe accadere se lo spazio su disco è riallocato su un'altra VM e non azzerato), quella VM sarà meno probabile per avere accesso ai dati effettivi (sarebbe necessario ottenere anche la chiave di decrittazione).

Se la chiave di decrittografia è archiviata in chiaro sullo stesso supporto dei dati crittografati, la crittografia è inutile. Se si dispone di una serie di regole, che richiedono la crittografia dei dati, ma consentono di archiviare la chiave in chiaro sullo stesso supporto, le regole sono difettose. Se mai dovessi affrontare un insieme di regole così imperfetto, dovresti sottolineare 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 decrittazione da un server delle chiavi. Ciò può impedire la decrittografia dei dati se il server è stato rubato, richiede solo che il server delle chiavi risponda solo alle richieste dall'interno del data center.
• Condivisione segreta della 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 i singoli dischi vengono occasionalmente sostituiti, si garantisce che tutti i dati lasciati sui dischi restituiti in garanzia siano adeguatamente crittografati. Quando un nuovo disco viene aggiunto al RAID, un'implementazione di questa tecnica dovrebbe eseguire le seguenti operazioni:
  • Genera una chiave di crittografia per questo singolo disco.
  • Genera una nuova chiave principale.
  • Secret condivide la nuova chiave master su tutti i dischi.
  • Su ogni disco scrivi la chiave di crittografia del disco crittografata con la nuova chiave master.

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

Sono presenti attacchi al firmware dei dischi rigidi. Cercare su Google un attacco al firmware del disco rigido restituirà alcuni risultati su ciò che l'NSA fa o può fare, il che probabilmente non è molto rilevante 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 disco rigido - no, non era il PC che eseguiva Linux, lo faceva lo stesso controller del disco rigido.

Se qualcuno riesce ad accedervi al firmware dei tuoi dischi (ad esempio, qualcuno noleggia un server dal tuo data center per un mese, poi lo restituisce; la società del data center pulisce le unità, quindi ti assegna quel server), potrebbe avere il firmware dell'unità 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 $ , sostituisci i primi byte con (un hash della password) ", hai un attacco quasi impercettibile. Il tuo file / etc / shadow ti sembrerà normale tranne durante il periodo di tempo di 5 minuti dopo che il tuo aggressore ha richiesto un file con un nome contenente il pattern di attivazione dal tuo server web, che lo ha scritto nel suo registro degli errori .

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

Considera cosa intendi per data center "sicuro".

In generale, non considero nulla di sicuro contro un aggressore determinato e dotato di risorse adeguate. È vero, avere 18 pollici di cemento armato, doppie trappole per l'uomo e sicurezza armata fornisce una discreta quantità di protezione, ma è raro che questa protezione sia tutta solo per te. Nella maggior parte delle strutture di co-locazione, l'unica cosa che ti protegge da un persona con $ 500 e conoscenze sufficienti per affittare uno spazio rack nella stessa struttura della tua è una gabbia metallica dubbiosamente sicura con un bicchiere a tre perni.

Occasionalmente, disastri naturali e causati dall'uomo allagheranno le cose, interromperanno l'alimentazione, avvelenare le scorte d'acqua e fare ogni sorta di cose insolite che inducono le guardie di sicurezza ei tecnici a non presentarsi al lavoro o semplicemente a tornare a casa dalle loro famiglie - quello che sto dicendo è che i data center forniscono solo un livello di sicurezza che probabilmente non è così tanto quanto pensano molti dei loro clienti.

Riconsidera la tua posizione sul basso rischio che il tuo appaltatore di smaltimento perda unità.

Un certificato di distruzione autorizza anche te ..... i $ 20 di rimborso che gli hai pagato per distruggere un'unità che non è stata effettivamente distrutta?

Hai visitato il tuo impianto di smaltimento dei motori? Hai controllato le procedure di assunzione? Visto le loro garanzie? Assicurati di essere solido come una roccia su questo perché è una delle vulnerabilità più evidenti: un cambio di custodia.

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

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

Quello che farà è incanalare la tua minaccia interna per passare attraverso il tuo FDE, che ti consentirebbe 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 il funneling non sia principalmente lo scopo di FDE. Anche se disponi di FDE, puoi comunque implementare un altro livello di file o un'altra crittografia dei dati oltre a FDE. Puoi anche continuare a utilizzare i controlli di accesso del sistema operativo.

FDE protegge dagli addetti ai lavori che non hanno accesso tramite FDE. Protegge dai tecnici del server che sostituiscono le unità che ne prendono una e che se ne vanno con i dati. Impedisce che un dipendente della struttura server ne raccolga uno da un container di spedizione presso la tua struttura in attesa del trasporto al tuo appaltatore di distruzione.

FDE ti consente un altro livello per fermare anche le minacce interne, se tu segrega la tua fattoria o usa un accesso granulare: supponiamo che i tuoi insider abbiano accesso solo a determinati server, ecc. FDE impedirebbe loro di copiare semplicemente le unità all'ingrosso per le quali non hanno accesso tramite FDE.

In poche parole , FDE protegge i dati sull'unità dall'accesso fisico all'unità. Puoi provare a controllare l'accesso fisico quanto vuoi, ma le unità si troveranno sempre con qualche vulnerabilità (essere rubate da addetti ai lavori, essere copiate da addetti ai lavori, custodia in transito dove gli addetti lo toccano, incustodite a causa di un disastro, ecc. ). Se le persone toccano l'unità, FDE è uno strato di difesa contro di essa.

David

Non sicuramente. Dipende da cosa vuoi difenderti. 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 contro il tuo datore di lavoro.
• Se sei il proprietario del server, ma non dai la possibilità ai tuoi dipendenti / colleghi di accedervi fisicamente, che hanno rubato / rispecchiato il suo contenuto. Quindi li abiliti per ripararlo / avviarlo, ma non fornire loro le chiavi di crittografia.
• Lo stesso potrebbe essere una protezione efficiente se non puoi / non ti fidi della tua soluzione di hosting del server.

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

Se ti trovi in ​​un ambiente lavorativo regolare, non farlo. Ha richiesto molte ore di lavoro e ha un tempo di servizio esteso. A mio parere, nella maggior parte dei casi non vale il suo prezzo.

Citazione: ".. .hanno fatto poco o nulla per ridurre effettivamente il rischio associato a dati non crittografati.................................................... La semplice risposta è "è inutile", ma "NON è anche inutile". Ecco perché, e perdonami per aver detto questo, penso che tu stia abbaiando sull'albero sbagliato. Lasciatemi spiegare. La crittografia completa del disco (FDE) ha uno scopo, anche se è solo per un sottoinsieme di exploit con bassa probabilità. Esistono numerosi exploit possibili e la probabilità BASSA non è uguale a NO probabilità.

Quindi, è inutile? Non del tutto. Ma perché discuti contro di essa? Vuoi che venga prestata maggiore attenzione alla sicurezza quando i server sono in esecuzione e i dati non sono crittografati? Questo entra nella regione in cui i fatti possono farti meno bene e il senso della politica può aiutarti.

Potrebbe essere che il tuo obiettivo in questo argomento al lavoro sia quello di stabilire la tua esperienza. O forse c'è qualcosa che pensi debba essere fatto e nessuno ti sta prestando attenzione. Tutto quanto sopra è valido e ragionevole e fa parte dell'ambiente lavorativo quotidiano. Potrei interpretare erroneamente la tua domanda, ma mi sembra che potresti ottenere un risultato migliore argomentando a favore dell'azione che ritieni debba essere eseguita, piuttosto che contro un'azione che è stata compiuta. Scegli i tuoi combattimenti.

Dalla tua descrizione, sospetto che tu sia corretto. Cioè, la crittografia completa del disco non aggiunge alcuna protezione reale per i tuoi dati su un server in esecuzione se qualcuno dovesse compromettere quel server per estrarre i dati. Questo non è ciò che la crittografia completa del disco è progettata per ottenere. Tuttavia, questo non significa che non sia necessario disporre della 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 i dischi guasti al fornitore ecc. Tuttavia, se è necessario proteggere i dati sul server quando è in esecuzione, di solito avrai bisogno della crittografia di file, tabelle, ecc. oltre alla crittografia del disco - non è necessariamente una situazione o / o.

L'altra cosa da considerare è che la sicurezza riguarda i livelli di protezione. Suggerendo di disporre di buoni controlli per lo smaltimento dei dischi e quindi non è necessaria la crittografia completa del disco, si presume che i controlli utilizzati per lo smaltimento dei dischi non falliranno mai. Tuttavia, questi tipi di controlli di solito hanno un alto contenuto procedurale e umano: si basa molto sull'amministratore che segue correttamente la procedura. Nella mia esperienza, questi sono i tipi di controlli che hanno maggiori probabilità di fallire. Potrebbe essere quel nuovo dipendente che si dimentica o non è a conoscenza della procedura, potrebbe essere quell'amministratore di sistema esperto che si occupa di un guasto ad alta pressione in cui il capo lo sta facendo pressioni per riavere il servizio il prima possibile ecc. Avere la crittografia completa del disco è semplicemente un altro controllo protettivo che toglie parte della pressione dal personale e riduce il possibile impatto di un semplice errore umano.

Dove le cose vanno storte con la crittografia completa del disco è quando le persone presumono che risolva più problemi di quanto non faccia in realtà: questo sembrerebbe essere il fulcro del tuo argomento / preoccupazione. Ho visto molti fornitori e persino amministratori convincere la direzione che i dati sono al sicuro semplicemente perché utilizza la crittografia completa del disco. Di conseguenza, viene eseguita poca o nessuna analisi dei rischi reali per quanto riguarda i rischi quando il server è in esecuzione. Recentemente ho realizzato un grande progetto di archiviazione dati per un cliente che coinvolgeva dati potenzialmente sensibili e / o preziosi. È stato piuttosto sorprendente il numero di fornitori che non hanno risposto correttamente alle domande sulla crittografia. La loro risposta standard è stata che "è ok, il sistema utilizza la crittografia completa del disco". Dopo aver approfondito e fornito esempi e chiesto in che modo la crittografia dell'intero disco avrebbe protetto i vari scenari per un server in esecuzione, la risposta generale è stata "Oh, beh, questo è un problema che l'applicazione deve risolvere".

Per me, il problema più grande in cui mi sono imbattuto sia con la crittografia completa del disco che con la crittografia a livello di file / tabella è la frequente mancanza di una reale considerazione riguardo alla 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 di tutto il meraviglioso uso della crittografia per proteggere i dati solo per scoprire che le chiavi utilizzate sono scarsamente protette, quasi un pensiero dopo. Peggio ancora, a causa della mancanza di un approccio buono o comprensibile, ti imbatti in data center in cui la stessa chiave viene utilizzata in più luoghi o a più livelli solo in modo che gli amministratori possano gestirli in modo efficace ed essere in grado di ripristinarli quando necessario.

Grazie a tutti per il feedback. In sintesi, la domanda del titolo è inutile FDE per un server in un data center sicuro? La risposta non è necessariamente poiché 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 leggermente modificata rispetto a quella dichiarata nel titolo. La preoccupazione nella domanda principale era che i dati venissero compromessi non tramite l'accesso fisico al server ma l'accesso logico ai dati. Sulla base delle risposte, sembra che FDE non fornisca questa protezione. La soluzione è trasparente per l'utente in cui i dati vengono decrittografati sul server all'avvio. A quel punto si fa affidamento su altri controlli come firewall, buona gestione degli accessi, autenticazione avanzata e applicazione di 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 limitato per fornire un ulteriore livello di sicurezza.

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

Ecco altri 2 vantaggi (supponendo che utilizzi nuove chiavi di crittografia ogni volta che reinstalli):

• Se esegui strumenti di recupero file che scansionano l'intero dispositivo a blocchi, ad es. PhotoRec, non devi controllare tonnellate di vecchi file che non interessano più.

• Se esegui strumenti di riparazione del filesystem che scansionano l'intero dispositivo a blocchi, non esegui il rischio di confondere strutture e metadati di un vecchio filesystem con quello attuale.

JJ