Cifratura del disco su una macchina che non si possiede

Ogni provider che vende privacy afferma che i dischi sono cifrati. Di solito è vero, e di solito risponde a una domanda che nessuno aveva posto. La cifratura riguarda tre stati, e un server trascorre l'intera vita operativa in quello che la cifratura dell'intero disco (la cosiddetta crittografia del disco) non copre. Ecco dove passa davvero il confine, cosa sta da ciascun lato, e quale dei due schemi venduti sotto le stesse quattro parole è quello in cui è il cliente a detenere la chiave.

Tre stati, e quello che nessuno cifra

I dati si descrivono come trovarsi in uno di tre stati, e il settore ne ha risolti convincentemente due. A riposo sono i dati fermi su un disco che al momento nessuno legge: risolto dalla cifratura dell'intero disco, e dalla cifratura del database o dell'object storage sovrapposta ad essa. In transito sono i dati che attraversano una rete: risolto dal TLS, in modo talmente solido che un certificato emesso per errore fa notizia. In uso sono i dati caricati nella memoria di un processo in esecuzione — dove ogni byte servito dal server deve necessariamente trovarsi, per quanto brevemente, per poter essere servito.

L'espressione crittografia dei dati a riposo è precisa, ed è precisa in un modo facile da leggere distrattamente. Descrive lo stato dei dati mentre la macchina è spenta. Un server è una macchina il cui intero compito consiste nel non essere spento. Per i mesi che trascorre in funzione, i suoi volumi restano aperti, i file del database sono leggibili da qualunque processo eseguito con l'utente giusto, e la cifratura non fa nulla se non attendere un'interruzione di corrente.

La seconda cosa che quelle quattro parole nascondono è di chi è la chiave. Sotto di esse si vendono due schemi completamente diversi. Un provider può cifrare il livello di storage con chiavi che gestisce lui stesso: questo protegge il suo processo di dismissione e riduce la propria esposizione in caso di violazione, e protegge davvero da un disco che esce fisicamente dall'edificio — ma la parte che detiene la chiave è proprio quella di cui ci si stava chiedendo. Oppure il volume può essere cifrato all'interno della propria macchina, con una chiave che non esiste da nessun'altra parte se non nella mente del cliente e nella memoria di un kernel in esecuzione. Solo il secondo schema cambia ciò che un terzo può ottenere, ed è solo al secondo che si riferisce il resto di questa guida.

Nulla di tutto ciò è un argomento contro la cifratura dei dischi. È un argomento a favore del sapere quali degli otto scenari qui sotto sono coperti e quali no. Una cifratura che ferma una sola cosa reale vale la pena di averla; una cifratura che si crede fermi tutte e otto è peggio di nessuna cifratura, perché quella convinzione chiude la discussione.

Dove vive la chiave mentre la macchina è in funzione

Quando si sblocca un volume LUKS, la passphrase digitata non è la chiave. Essa sblocca una chiave master conservata nell'header del volume, e quella chiave master viene poi mantenuta nella memoria del kernel finché il volume non viene chiuso o la macchina non perde alimentazione. Ogni lettura e ogni scrittura vi passa attraverso. Non esiste una configurazione di disco cifrato funzionante in cui la chiave si trovi altrove mentre il disco è in uso — non è un dettaglio implementativo che si possa correggere, è ciò che significa usare un disco cifrato.

Su hardware di proprietà, quella memoria si trova in un case, in una stanza sotto il proprio controllo, e l'attacco contro di essa è raro: presenza fisica, e i secondi di residuo che i chip di memoria trattengono dopo il taglio dell'alimentazione. Su un server virtuale la situazione cambia di natura, non solo di grado. La memoria del kernel è una regione della memoria dell'host. L'hypervisor può indirizzarla per definizione, perché indirizzarla è il modo stesso in cui l'hypervisor l'ha assegnata. Tre operazioni del tutto ordinarie la leggono:

• Una live migration. Spostare una macchina virtuale in funzione fra host fisici ne copia la memoria mentre è ancora in esecuzione. È una funzionalità — è così che un host viene mantenuto senza dover riavviare il cliente — e la chiave master si trova fra le pagine copiate.
• Uno snapshot che include la memoria. Uno snapshot che riguarda solo il disco di un volume cifrato autonomamente contiene solo testo cifrato. Uno snapshot che permette alla macchina di riprendere esattamente da dove si trovava contiene anche la chiave, perché la chiave fa parte di ciò che «esattamente da dove si trovava» comporta.
• Un memory dump. La memoria della macchina virtuale ospite vive all'interno dello spazio di indirizzamento di un processo sull'host. Leggere la memoria di quel processo è un'operazione di debug di routine, e gli strumenti per farlo sono già inclusi nello stack di virtualizzazione, non serve introdurli di nascosto.

Nulla di ciò afferma che il provider faccia una di queste cose. Afferma che queste azioni non richiedono alcuna collaborazione da parte del cliente, non lasciano traccia in nulla di visibile, e sono indistinguibili dalla normale manutenzione della piattaforma. È l'unica proprietà che vale la pena inserire in un modello di minaccia: non cosa qualcuno sta facendo, ma cosa è in grado di fare senza che ce ne si accorga. Lo stesso ragionamento, un livello più in là, è il motivo per cui il registry e il proxy davanti al server appartengono alla stessa lista dell'host.

Il problema del riavvio, e la scorciatoia che lo vanifica

Un volume di root cifrato deve essere sbloccato prima che il sistema si avvii a sufficienza per accettare una connessione SSH. Su un portatile la passphrase si digita sulla tastiera. Su una macchina a duemila chilometri di distanza, in un edificio mai visitato, non c'è alcuna tastiera raggiungibile nel momento in cui serve. Ogni risposta pratica a questo problema è un compromesso — e una delle quattro qui sotto non è affatto un compromesso, ma un modo di sembrarlo.

Quattro modi per sbloccare un volume di root cifrato su una macchina remota

Metodo	Riavvio non presidiato	Blocca un disco rubato	Cosa costa
SSH nell'immagine di boot	No	Sì	Un server SSH minimale dentro l'initramfs consente di collegarsi e digitare la passphrase. La macchina resta spenta finché una persona non è sveglia e raggiungibile. È l'opzione onesta, e il costo è reale: un riavvio alle quattro del mattino resta un'interruzione di servizio finché qualcuno non se ne accorge.
Chiave vincolata alla rete	Sì	Parzialmente	La macchina recupera la chiave di sblocco all'avvio da un server gestito altrove, ed è possibile rifiutarsi di fornirla a una macchina che si è spostata o che non è stata riavviata volontariamente. Il server delle chiavi deve restare attivo, e deve trovarsi in un luogo che lo stesso provvedimento non possa raggiungere — altrimenti la chiave è divisa fra due porte con una sola serratura.
File della chiave nell'immagine di boot	Sì	No	La chiave si trova nell'initramfs, l'initramfs si trova su una partizione di boot non cifrata, e la partizione di boot si trova sul disco che si voleva proteggere. Chi porta via il disco porta via anche la chiave. Questa configurazione è comune, si avvia perfettamente, e non difende assolutamente da nulla.
Sigillata a un TPM	Sì	Parzialmente	Su hardware di proprietà, un vero chip di sicurezza rilascia la chiave solo a una catena di avvio non alterata. Su un server virtuale quel chip è emulato dall'host, quindi sigillarvi una chiave la consegna esattamente alla parte da cui la si voleva proteggere.

La terza riga merita uno sguardo più attento. È dove si finisce quando il requisito è stato scritto come i dischi devono essere cifrati e nessuno si è chiesto per quale scopo. L'audit passa. Il block device è davvero cifrato. La chiave viaggia sullo stesso pezzo di metallo, in un file che una shell di recupero leggerà in circa quattro secondi.

Questa è anche la differenza pratica più netta fra una macchina virtuale in affitto e una macchina di proprietà. Su un hardware dedicato l'interfaccia di gestione out-of-band offre una console che sopravvive a un riavvio, così la prima riga smette di essere un'interruzione e diventa un fermo di due minuti — e il problema del chip emulato nella quarta riga scompare, perché il chip è saldato su una scheda anziché scritto in software dalla stessa parte da cui ci si vuole difendere.

Cosa compra davvero la cifratura dell'intero disco

La stessa domanda, posta in otto modi. La colonna che conta è l'ultima, perché in ogni riga in cui la cifratura non aiuta, qualcos'altro lo fa — e nominare quel qualcosa è tutto il valore dell'esercizio.

Otto scenari, e se la cifratura dell'intero disco cambi l'esito

Scenario	La cifratura aiuta	Cosa decide davvero
Un disco viene dismesso, rivenduto o restituito in garanzia	Sì	Nient'altro copre questo caso. I dischi escono dai data center di continuo, la sanificazione è un processo, e i processi falliscono in silenzio. È lo scenario per cui la cifratura dell'intero disco è stata inventata, e qui funziona esattamente come promesso.
La macchina viene spenta e il disco rimosso	Sì	Stessa protezione, stesso confine, e il confine è la parola spenta. Una macchina presa mentre è in funzione è una macchina presa sbloccata, con i volumi aperti e la chiave residente in memoria.
Una copia di backup si trova altrove	Parzialmente	La cifratura sul volume di origine non fa nulla per una copia dei dati. A deciderlo è se il backup è stato cifrato prima di uscire, con una chiave non conservata sulla macchina di cui si fa il backup.
La piattaforma esegue uno snapshot	Parzialmente	Uno snapshot che riguarda solo il disco di un volume cifrato autonomamente è testo cifrato, inutile a chiunque non abbia la passphrase. Uno snapshot che cattura anche lo stato della memoria cattura anche la chiave. Entrambi si chiamano snapshot.
Qualcuno ottiene una shell sulla macchina in funzione	No	Il volume è già aperto, e un intruso legge file, non blocchi. A decidere questa riga sono le patch, il privilegio minimo e credenziali non riutilizzate fra servizi diversi; la cifratura non vi contribuisce in nulla.
L'operatore dell'host, o chiunque disponga del suo accesso	No	Solo una cifratura la cui chiave non entra mai nella macchina. La cifratura hardware della memoria è la sola eccezione, disattivata di default ovunque, ed è trattata nella sezione successiva.
Un provvedimento viene notificato al provider	Parzialmente	La giurisdizione decide chi può chiedere e su quale base; la cifratura decide cosa può contenere una risposta. La nostra posizione pubblicata consiste in due frasi distinte, ed entrambe contano: non deteniamo le chiavi dei clienti e non possiamo produrle, e un volume non cifrato su un server virtuale richiede comunque un provvedimento che nomini quel servizio.
Si deve notificare una violazione	Parzialmente	Se gli utenti si trovano nell'UE, l'articolo 32 del GDPR cita la cifratura tra le misure attese, e l'articolo 34 solleva dall'obbligo di notificare le persone interessate — mai l'autorità di controllo — quando i dati sono stati resi inintelligibili. Che questo si applichi dipende interamente da dove si trovava la chiave nel momento in cui i dati sono usciti.

Sopra il disco: cosa sopravvive a un host ostile

Tutto quanto detto finora riguarda un livello che si ferma al block device. Tre cose si trovano sopra di esso, e insieme sono le uniche risposte alla quinta, sesta e settima riga di quella tabella.

Cifrare sopra l'applicazione, non sotto di essa

La cifratura a livello di campo significa che l'applicazione cifra un valore prima che raggiunga il database e lo decifra dopo averlo riletto. Un dump del database restituisce testo cifrato, chiunque l'abbia estratto e con qualunque metodo. Ha il costo di perdere la possibilità di cercare o indicizzare le colonne cifrate, motivo per cui va riservata ai pochi campi che lo meritano — corpo dei messaggi, documenti caricati, token di terze parti — e non a tutto. Il punto di arrivo di questa strada è l'end-to-end: la chiave appartiene all'utente, il server non detiene mai testo in chiaro, e un host ostile non ottiene nulla perché non c'è nulla da ottenere. È l'unica architettura di questa pagina genuinamente indifferente a chi gestisce il metallo, ed è una decisione di prodotto ben prima che di infrastruttura.

I backup sono una decisione separata, non una conseguenza

Il modo più comune in cui i dati escono da una macchina cifrata è un backup. Uno snapshot inviato a un object storage, un dump del database sincronizzato con un secondo provider, un archivio scaricato su una postazione di lavoro — nessuno di essi eredita alcunché dal volume da cui proviene. Cifrare nel momento in cui i dati vengono scritti nel backup, con una chiave conservata in un luogo che la macchina stessa non può raggiungere, così che un server compromesso non possa decifrare la propria storia. Poi ripristinarne uno, su una macchina diversa, prima che serva davvero: un backup cifrato che non si riesce ad aprire è un modo insolitamente ordinato di perdere tutto in una volta. Una copia in un altro paese è anche una copia sotto un altro insieme di regole, ossia una seconda giurisdizione scelta senza accorgersene.

Cifratura della memoria, e perché probabilmente non se ne dispone

Lo stato che nessuno cifra ha comunque una risposta hardware. Le estensioni di confidential computing — SEV-SNP di AMD, TDX di Intel — cifrano la memoria e lo stato dei registri della guest sotto una chiave detenuta da un processore di sicurezza separato anziché dall'hypervisor, così che un host che estrae un dump della memoria ottiene solo testo cifrato. È reale ed è già disponibile. Ma è anche limitata: SEV-SNP richiede silicio EPYC di terza generazione o successivo, l'host deve essere configurato deliberatamente per supportarla, e la guest deve attestare di averla ottenuta. Quasi nessun server virtuale general-purpose la offre, e nessuno la offre in modo silenzioso. Si dia per scontato di non averla, a meno che un provider non lo dichiari per iscritto e non sappia indicare come verificarne l'attestazione.

Una configurazione onesta sui propri limiti

Nulla di tutto ciò si conclude con non vale la pena. Si conclude con una configurazione i cui limiti si possono dichiarare ad alta voce senza esitare.

1. Scrivere l'unico scenario da cui ci si sta difendendo (5 min). Un disco dismesso, una macchina sequestrata mentre è in funzione, un host ostile, un provvedimento giudiziario, una violazione da notificare. Le risposte sono diverse, e una configurazione pensata per tutti e cinque non ne raggiunge in modo affidabile nessuno.
2. Mettere la cifratura dove sta la chiave (decisione). Se è il provider a detenere la chiave, si è comprata protezione contro un disco che lascia l'edificio, e nient'altro oltre a questo. Per ottenere di più, il volume va sbloccato dall'interno della guest, dal cliente stesso, con qualcosa che la piattaforma non vede mai.
3. Cifrare il volume dei dati anziché la root (configurazione). Una root cifrata significa che ogni riavvio attende un intervento umano. Un volume cifrato separato, che contiene la directory del database, gli upload e i segreti, permette alla macchina di ripartire da sola mentre la parte sensibile resta chiusa finché non viene aperta. È il compromesso che quasi tutte le piccole piattaforme dovrebbero adottare, e quasi nessuno lo mette per iscritto.
4. Non lasciare mai il file della chiave sulla partizione di boot non cifrata (regola). Se la macchina si avvia senza presidio, senza server delle chiavi e senza console, la chiave è sul disco; non esiste una terza possibilità. È un compromesso accettabile quando un disco rubato è davvero l'intero modello di minaccia, e un autoinganno in ogni altro caso.
5. Cifrare i backup nel momento in cui vengono scritti, con una chiave conservata altrove (configurazione). Poi ripristinarne uno su una macchina diversa, in un giorno in cui non è già tutto in fiamme.
6. Dire cosa è stato coperto, in una sola frase (5 min). Qualcosa di simile a: chi estrae questo disco dal rack non ottiene nulla, e chiunque abbia accesso root sulla macchina in funzione o sul suo host ottiene tutto. Se questa frase mette a disagio scriverla, è perché è vera.

Due di questi sei punti sono decisioni e quattro sono configurazione. Le decisioni richiedono un pomeriggio e la configurazione un'ora, e l'ora non vale nulla senza il pomeriggio. Farlo nell'ordine inverso è come si finisce nella terza riga della prima tabella, con una macchina che supera l'audit e non protegge nessuno.

Da quale scenario ci si stia difendendo è una domanda di threat modelling prima ancora che di cifratura, e la versione da un'ora di quell'esercizio produce la frase del sesto passaggio quasi come sottoprodotto. Se la risposta si rivela essere un provvedimento giudiziario anziché un disco, il livello che decide l'esito non è affatto sul disco — è di chi sia la legge che raggiunge il provider, e come verificarlo prima di fidarsi.

Scritto dagli ingegneri che gestiscono la piattaforma, e riletto il oggi. Se qualcosa qui è sbagliato o non è più aggiornato, lo segnali dal pannello cliente — è da lì che proviene circa la metà di queste voci.