Cifra la macchina virtuale nel cloud

Mentre Thomas Pornin sottolinea correttamente che l'unico modo per fidarsi di un host sotto attacco è l'utilizzo della crittografia omomorfica in pratica, puoi provare a ovviare a questo requisito.

Un potenziale aggressore ha il pieno controllo della CPU, della memoria e del disco. Quindi non è possibile fare calcoli su dati preziosi in una VM che potrebbe non essere sotto il tuo controllo. D'altra parte spesso non è necessario. Se si desidera utilizzare la VM come database o servizio di archiviazione / backup, la VM non ha mai bisogno di accedere a informazioni non crittografate. È possibile memorizzare file o voci in un database, memorizzare gli hash dei file crittografati o nomi di file e ad es. ordina la dimensione del file o recupera un determinato file in cui il client fornisce il nome del file come valore hash.

Un tale schema limita ciò che puoi fare con i tuoi dati, ma data una buona crittografia è impossibile per un utente malintenzionato rubare i tuoi dati. Nel peggiore dei casi possono modificarlo, quindi hai bisogno di firme crittografate per impedire la manomissione dei dati.

Un esempio popolare è boxcryptor , che utilizza un contenitore crittografato per archiviare i file in modo sicuro presso diversi provider cloud. Un altro è duplicato , che consente il backup crittografato usando rsync e GnuPG.

Cifratura della memoria della VM stessa, ad es. TrueCrypt o Bitlocker non aumentano significativamente il livello di sicurezza. Potrebbe sventare un attacco se la VM viene spenta, ma non appena la si esegue, il sistema operativo ha bisogno della chiave per accedere al volume crittografato e in quel momento un potenziale aggressore può ottenere la chiave.

Se l'host è ostile allora la resistenza è inutile .

L'host può leggere lo stato del disco, della RAM e della CPU della macchina virtuale. Solo la crittografia completamente omomorfica ti farebbe risparmiare, ma non funziona ancora (la scienza non ha ancora scoperto una soluzione efficiente; ma questo è solo un fattore di un miliardo circa, quindi possiamo ancora sperare in qualcosa ... più avanti).

Altre persone stanno parlando in modo assoluto (in teoria). Sì, se l'attaccante ha accesso al sistema operativo host, in teoria la VM non può più essere considerata sicura. Tuttavia, per fare ciò nella pratica, richiede un lavoro di hacking non standard, il che implica che si tratta di un attacco mirato contro YOU , perché ci saranno un sacco di altre macchine virtuali che non saranno crittografate e sarebbero obiettivi molto più facili della tua VM. La crittografia completa del disco nel cloud ti proteggerà dalla folla di altre macchine virtuali, ma se sei specificamente mirato, sei morto. Non esiste un sistema assolutamente sicuro, solo diverse difficoltà per accedervi. La crittografia del disco aumenta la difficoltà. Se vuoi una maggiore sicurezza, esegui il tuo host, ma solo se sei competente, altrimenti potrebbe essere peggio.

Il tuo problema qui è lo stesso vecchio: un utente malintenzionato che ha accesso alla casella fisica, o in questo caso l'host, può accedere alla tua VM.

Questo è uno dei rischi che devi considerare se esternalizzi le cose: usi il tuo contratto con il fornitore per darti la certezza di cui hai bisogno.

Suddividi i tuoi dati su molte VM, ospitate da diversi host (e provider, se possibile) in modo che i dati della singola VM siano inutili. Ovviamente questo potrebbe uccidere l'usabilità e / o le prestazioni. Idea molto approssimativa.

Usa la crittografia completa del disco se puoi, dove puoi. La crittografia completa del disco maturerà solo e preclude l'attacco fisico, che è il tempo libero nel lavoro di sicurezza per i problemi reali con accesso logico. Per attacco fisico, intendo dal BIOS della macchina virtuale, i registratori di tasti. Inoltre, proteggerebbe l'unità dall'essere montata da altrove se gli infra circostanti venissero rubati e portati fuori linea, invece di essere attaccati attivamente. Penso che quel particolare modello di minaccia mi suona abbastanza importante perché oscilli la decisione di usare FDE se possibile e se hai coperto eventuali problemi di sicurezza più grandi.

Credo che proteggere VM in un host di rimonta non sia facile. Il meglio che devi fare come segue: Primo: Stabilisci fiducia reciproca tra te e l'host visitato.

Secondo: Aggiungi strumenti di verifica all'interno della tua VM per rilevare comportamenti anomali nell'host visitato.

Terzo: Aggiungi meccanismi di protezione per proteggere i dati più sensibili con cui VM gestisce.

Potrebbe essere necessario mettere "VM Obfuscation" sotto la tua considerazione.

Grazie