Come migliorare le prestazioni del database MySQL crittografato sul server di back-end di Linux?

2

La tecnologia di crittografia trasparente di ezNcrypt è l'unico modo per ottenere un notevole incremento delle prestazioni? Ci sono altre buone soluzioni là fuori che potremmo considerare per la crittografia dell'intero database con un impatto marginale sulle prestazioni? Da quello che so. molti database Linux MySQL non vengono criptati a causa del problema di prestazioni. Non vogliamo farlo.

Con l'hosting in outsourcing, anche con un server dedicato, non sono sicuro che abbiamo troppe opzioni hardware. A meno che qualcuno non conosca un'azienda di hosting specializzata in applicazioni ad alta sicurezza. Abbiamo pensato di provare le unità SSD (disponibili da alcune società di hosting) ma non siamo sicuri di quale sarebbe l'impatto sulle prestazioni di crittografia. Sarebbe utile qualsiasi commento su questo e su ezNcrypt o altre soluzioni non hardware. Grazie.

    
posta Dan 14.02.2012 - 01:15
fonte

2 risposte

4

Full Disclosure: sono l'architetto capo di Gazzang, nonché uno degli autori e l'attuale manutentore upstream del filesystem crittografato eCrypfs.

Ciao @ Dan,

ezNcrypt è un prodotto commerciale venduto dal mio datore di lavoro, Gazzang . È costruito su eCryptfs , un filesystem crittografato open source integrato nel kernel di Linux e con utility per lo spazio utente disponibili in tutte le principali distribuzioni Linux. Cercherò di rispondere alla tua domanda in modo imparziale: -)

eCryptfs è al 100% GPLv2 software gratuito. È un file system crittografato maturo ampiamente disponibile in Linux. Si stima che 3 milioni di utenti desktop di Ubuntu utilizzino eCryptfs tramite la Directory home crittografata di Ubuntu. Ogni file viene crittografato individualmente (giustapposto alla crittografia full-disk e full-parting mappata al dispositivo). eCryptfs riduce al minimo la penalizzazione delle prestazioni rispetto ad alcune altre opzioni di crittografia, come indicato in questo report da Phoronix e questo documento di design da Google ChromeOS che utilizza eCryptfs. Se sai cosa stai facendo (o con un bel po 'di ricerca indipendente), potresti quasi certamente eseguire la crittografia del tuo database MySQL usando eCryptfs minimizzando l'impatto sulle prestazioni. Ci vorrà un bel po 'di sforzi e la tua configurazione avrà una limitata garanzia della qualità e riproducibilità, anche se conosco molte persone che usano eCryptfs per casi d'uso molto più pazzi!

ezNcrypt include un open source ( GPLv2 ) DKMS modulo del kernel, ma uno spazio utente proprietario venduto come prodotto commerciale con licenza da Gazzang . Con la licenza commerciale, i clienti ricevono un supporto clienti di prima classe e una suite di utility che rendono la crittografia di qualsiasi database (incluso MySQL) molto, molto "più facile" come suggerisce il nome. Al livello più basso, ezNcrypt utilizza ancora eCryptfs, ma la suite di strumenti accuratamente testata e basata sul database è un prodotto a pagamento commercialmente supportato.

    
risposta data 21.02.2012 - 20:36
fonte
3

Ciò che accelererebbe le cose sarebbe che i campi sensibili fossero cifrati usando Advanced Encryption Standard (AES) su un sistema con una CPU AES-Instruction-Set- (IS) -capable, preferibilmente con chiavi a 256-bit, preferibilmente in Modalità Cocket-Block Chaining (CBC) o, almeno, Electronic Codebook Mode (ECB) con un salt - questo può essere fatto semplicemente anteponendo almeno 1 carattere / byte ai dati da crittografare.

Ciò che sarebbe ancora più sicuro sarebbe criptare tutto tranne / boot con AES in Extended Schedule con la modalità Ciphertext Stealing (XTS) in aggiunta così sensibili nel database. Puoi utilizzare TrueCrypt per crittografare un intero disco, partizione o semplicemente un contenitore TrueCrypt in questo modo, tuttavia, ti consiglio di crittografare il sistema in modo che nessuno può vedere il codice PHP (?) contenente la chiave di crittografia se i tuoi dischi vengono sottratti.

Un attacco di forza bruta con testo in chiaro noto su una chiave AES per dati crittografati in modalità ECB su un Cray XE6 con 1 milione di chip della serie 6200 Opteron richiederebbe al massimo 1.34188978904574248034587874518e + 71 anni solo per le istruzioni AES-NI. Farlo su un Cray XK6 lo collocherebbe da qualche parte tra 1.34e + 69 anni al massimo. Questo è, tuttavia, solo un attacco a forza bruta, senza rompere AES. La rottura parziale di AES lo velocizzerebbe in modo esponenziale.

La cosa più importante è usare una passphrase complessa. Ciò significa che deve essere una lunga stringa di un piccolo insieme di caratteri (ad esempio le lettere dell'alfabeto inglese) o una breve stringa di, in pratica, bit casuali il cui valore byte non è zero (null-terminator). Utilizzando una frase passata di 8 caratteri composta da lettere dell'alfabeto inglese, inserisce un attacco a forza bruta sui dati crittografati con AES a sotto i 10 secondi su un Cray XE6 con 1 milione di chip Opteron serie 6200 e sotto 100 millisecondi su un Cray XK6. Vedi Attacco brute force non in chiaro noto al dizionario su AES-256 .

Ancora più sicuro sarebbe utilizzare qualcosa di diverso da AES con un acceleratore hardware, perché l'accelerazione AES è ampiamente disponibile. Ancora più sicuro sarebbe utilizzare entrambi.

    
risposta data 14.02.2012 - 17:38
fonte

Leggi altre domande sui tag