Crittografia full-disk su un VPS

La crittografia full-disk risponde esattamente a una domanda: cosa ottiene un avversario quando ha in mano il tuo storage e la macchina è spenta? Ogni altra domanda che potresti avere — cosa può vedere il provider, cosa succede se un server in esecuzione viene sequestrato, se i tuoi backup sono al sicuro — ha una risposta diversa, e trattarle tutte come una sola è il modo in cui si finisce con una crittografia che non protegge nulla.

Vale la pena essere netti su questa distinzione, perché «crittografato con LUKS» compare su ogni pagina di hosting per la privacy in questo settore, la nostra inclusa. È un controllo reale, costa quasi nulla da mantenere, ed è anche il controllo più sopravvalutato nell'hosting. Questa guida copre cosa impedisce davvero la crittografia a riposo su un server affittato, i tre schemi che vale la pena distribuire e i comandi per ciascuno, le due impostazioni che contano davvero su un piccolo VPS, e la manciata di errori che trasformano l'intero esercizio in pura decorazione.

Cosa protegge davvero la crittografia a riposo

Crittografia a riposo significa che i byte sul supporto di storage sono testo cifrato ogni volta che il volume è chiuso. È un'affermazione circoscritta, e il suo valore dipende da una sola variabile: dove si trova la chiave nel momento in cui arriva l'avversario.

Leggila come una definizione, non come una delusione. Eliminare la classe di esposizione legata al disco sottratto vale un'ora di lavoro proprio perché è la classe contro cui non hai altra difesa, e quella che si verifica senza che nessuno ti prenda di mira: l'hardware si guasta e viene restituito, gli array vengono dismessi, i volumi vengono riassegnati al prossimo inquilino. La crittografia trasforma tutto questo in un non-evento.

Perché un VPS non è un laptop

Su un laptop il disegno è evidente di per sé. Digiti una passphrase all'avvio, la chiave esiste solo in RAM finché la macchina è accesa, e spegnerla chiude la questione. Un server non ha nessuno alla console. Qualcosa deve fornire la chiave a ogni avvio, e ogni candidato per «qualcosa» scambia disponibilità con protezione:

• Un essere umano la digita. Lo schema più solido, perché la chiave non risiede mai sulla macchina — ma il server non può tornare operativo dopo un riavvio senza di te, e ti serve un modo per entrare prima che il sistema operativo esista.
• La macchina la conserva. Comodo, e nella maggior parte delle configurazioni fai-da-te controproducente: un file chiave sullo stesso disco virtuale significa che chiunque abbia il disco ha anche la chiave.
• Un'altra macchina la consegna. Sblocco vincolato alla rete, di solito Clevis con un server Tang. Il server si sblocca da sé soltanto finché riesce a raggiungere un host che controlli tu, una proprietà genuinamente utile — e uno spostamento della fiducia, non una sua eliminazione.

C'è una seconda differenza che la maggior parte delle guide tralascia. Su un VPS, /boot e l'initramfs sono in chiaro, risiedono su uno storage che in ultima analisi il provider controlla, e non esiste una catena di avvio che tu possa verificare — nessun TPM che ti appartenga, nessun measured boot, nulla da attestare. Un host che volesse la tua passphrase potrebbe alterare l'initramfs e raccoglierla al prossimo sblocco. Questa non è una descrizione di ciò che facciamo; è una descrizione di ciò che l'architettura permette, l'unico modo onesto di ragionare su un computer che affitti. Il nostro confronto tra VPS e dedicato percorre lo stesso confine di fiducia dal lato hardware, e la nostra risposta onesta sull'anonimato offshore applica la stessa disciplina al marketing che lo circonda.

I tre schemi che vale la pena distribuire

Non esiste un'unica configurazione corretta — esiste quella la cui modalità di guasto puoi accettare. Questi tre coprono sostanzialmente ogni caso reale.

Inizia dal primo, a meno che tu non abbia una ragione specifica per non farlo. Offre la maggior parte della protezione per una frazione del rischio operativo, e ha l'unica proprietà che agli altri due manca: nulla in esso può impedire al server di tornare online. Lo schema tre è l'unico in cui la passphrase è un fatto che il provider non può raggiungere, invece di una promessa che il provider fa, motivo per cui i nostri server dedicati applicano LUKS all'installazione con una passphrase che non vediamo mai.

Cifrare un volume dati su un VPS in esecuzione

Questo è lo schema da usare per primo. Non si reinstalla nulla, il processo di avvio non cambia in alcun modo, e se commetti un errore il risultato peggiore è un file container che butti via. Quindici minuti su un server Debian o Ubuntu attivo.

• Installa gli strumenti. apt install cryptsetup. Se il tuo piano ti ha assegnato un secondo block device, usalo direttamente e salta il passaggio successivo.
• Crea un container. Su un VPS a disco singolo la via pratica è un file: fallocate -l 40G /var/lib/vault.img. Si comporta come un disco e può essere ampliato in seguito.
• Formattalo come LUKS2. cryptsetup luksFormat --type luks2 /var/lib/vault.img. Mantieni i valori predefiniti per il cifrario; la sezione seguente tratta l'unico parametro che vale la pena modificare su un server piccolo.
• Aprilo e crea un filesystem. cryptsetup open /var/lib/vault.img vault ti dà /dev/mapper/vault; poi mkfs.ext4 /dev/mapper/vault e mount /dev/mapper/vault /srv/vault.
• Sposta i dati che contano, poi punta i servizi verso di essi. Un bind mount, oppure un rsync con il servizio fermato, è di solito più pulito dei symlink — i database in particolare non gradiscono essere spostati da un posto all'altro.
• Esegui il backup dell'header LUKS. cryptsetup luksHeaderBackup /var/lib/vault.img --header-backup-file vault-header.bin, poi sposta quel file fuori dal server. Pochi kilobyte corrotti all'inizio del container distruggono ogni byte che li segue, in modo permanente, ed è l'unica assicurazione che esiste.
• Chiudilo e verifica di poter rientrare. umount /srv/vault && cryptsetup close vault, poi riaprilo seguendo i tuoi appunti invece che la memoria. Fallo prima che ci sia dentro qualcosa di prezioso.

Dopo un riavvio il vault resta chiuso finché non accedi e lo apri. Non è un limite da aggirare con qualche accorgimento — è esattamente il punto. Un volume che si apre da solo è un volume la cui chiave si trova sulla macchina.

Cifratura full-root con sblocco remoto via SSH

Quando il requisito è che nulla di leggibile sopravviva a un sequestro a macchina spenta — log, cronologia della shell, elenchi dei pacchetti, la forma di ciò che esegui — anche il filesystem di root deve stare dentro il container. Il problema diventa allora far arrivare una passphrase a una macchina che non si è ancora avviata, e la risposta è un piccolo server SSH che vive nell'initramfs.

• Installa cifrato fin dall'inizio. Avvia il programma di installazione della distribuzione tramite il caricamento di un'ISO personalizzata e scegli il partizionamento guidato con LVM cifrato. Convertire in loco un filesystem di root già in esecuzione è possibile ma non vale il rischio.
• Aggiungi il server SSH pre-avvio. apt install dropbear-initramfs, poi inserisci la tua chiave pubblica in /etc/dropbear/initramfs/authorized_keys. È un set di chiavi separato dal tuo SSH normale — usa una chiave dedicata.
• Blindalo. In /etc/dropbear/initramfs/dropbear.conf, imposta DROPBEAR_OPTIONS="-I 180 -j -k -p 2222 -s": nessun login con password, nessun port forwarding, una porta propria, e un timeout di inattività così che una sessione bloccata non tenga l'avvio in sospeso.
• Dai una rete all'initramfs. Aggiungi un parametro statico ip= a GRUB_CMDLINE_LINUX in /etc/default/grub — la forma è ip=address::gateway:netmask::interface:off. Affidarsi al DHCP in questa fase è il modo in cui ci si ritrova bloccati fuori.
• Ricostruisci e riavvia. update-initramfs -u && update-grub, poi riavvia e connettiti con ssh -p 2222 root@your-server ed esegui cryptroot-unlock. Il tuo client avviserà di una host key sconosciuta: l'initramfs ha la propria, il che è previsto e vale la pena fissare in una voce known_hosts separata.
• Testa il percorso di fallimento prima di farci affidamento. Installa un aggiornamento del kernel, riavvia, sblocca di nuovo. Gli aggiornamenti del kernel rigenerano l'initramfs, ed è esattamente in quel momento che emerge una configurazione errata.

Le due impostazioni che contano, e la trappola dei VPS piccoli

LUKS2 usa per default AES-XTS con chiave a 512 bit e derivazione della chiave Argon2id. Entrambi sono corretti. Regolare manualmente il cifrario è un modo per essere più lenti e più deboli allo stesso tempo, e internet è pieno di righe di comando copiate che fanno esattamente questo. Due cose, tuttavia, meritano attenzione.

Le prestazioni non sono un problema, finché non lo diventano

Verifica l'accelerazione hardware con grep -m1 -o aes /proc/cpuinfo e misurala con cryptsetup benchmark. Su qualsiasi CPU con AES-NI — cioè ogni nodo che gestiamo — AES-XTS sposta diversi gigabyte al secondo per core, ben al di sopra di quanto un singolo disco virtuale possa erogare, quindi il costo visibile è una manciata di punti percentuali di CPU sotto I/O intenso e un piccolo aumento di latenza. Senza AES-NI il quadro si ribalta e la crittografia diventa il collo di bottiglia; è l'unico caso in cui un cifrario alternativo è una decisione reale e non un rito copiato senza pensarci.

La memoria di Argon2id è ciò che morde

Argon2id è deliberatamente affamato di memoria, e cryptsetup lo calibra al momento della formattazione in base alla RAM della macchina su cui stai formattando. Formatta un volume su una workstation da 32 GB, spostalo su un VPS da 1 GB, e lo sblocco può fallire del tutto perché la memoria richiesta dalla derivazione della chiave non c'è — peggio ancora dentro un initramfs, dove è disponibile molta meno memoria che in un sistema in esecuzione. Su istanze piccole, fissalo: cryptsetup luksFormat --type luks2 --pbkdf argon2id --pbkdf-memory 262144 /dev/vdb lo limita a 256 MB. Un valore più basso è una riduzione reale della resistenza al brute force offline, quindi compensa con una passphrase più lunga.

Un flag opzionale merita una decisione consapevole invece di un copia-incolla: --allow-discards lascia passare il TRIM verso il dispositivo sottostante, il che fa bene all'usura degli SSD e alle prestazioni a regime, e che rivela anche quanto del volume è in uso e più o meno dove. È disattivato per default. Attivalo sapendo cosa rivela.

Swap, log, snapshot — le parti che si dimenticano

Un vault cifrato con testo in chiaro che trapela intorno è il guasto più comune di tutti, e resta invisibile finché qualcuno non controlla.

• Swap. Qualsiasi cosa in memoria può finire su disco per paging, incluso il materiale che hai messo con cura nel vault. Disattiva lo swap, oppure assegnagli una chiave casuale a ogni avvio con una riga /etc/crypttab come swap /dev/vdb1 /dev/urandom swap,cipher=aes-xts-plain64,size=256.
• Tutto ciò che scrive dove non hai guardato. /var/log, /tmp, la directory dati del database, /var/lib/docker, la cronologia della shell, i journal di systemd. Cifrare /srv/vault mentre PostgreSQL scrive su /var/lib/postgresql non ottiene assolutamente nulla. Fai un elenco prima di cifrare.
• Snapshot. Uno snapshot a livello di blocco di un volume cifrato è testo cifrato e quindi va bene. Uno snapshot che cattura lo stato della memoria è un oggetto completamente diverso e può contenere la chiave. Sappi quale tipo effettua il pannello del tuo provider prima di usarlo.
• Backup. La destinazione è il posto sbagliato per risolvere questo problema. Strumenti come restic e BorgBackup cifrano alla fonte con una chiave che la destinazione non vede mai, motivo per cui un server di backup può essere una macchina ordinaria in un'altra giurisdizione invece che una macchina fidata.
• Il testo in chiaro che hai già inviato altrove. La crittografia a riposo non è retroattiva. Qualsiasi cosa già copiata, spedita via e-mail o sincronizzata altrove resta fuori dal confine che stai tracciando ora.

Dove vive la chiave è tutto il progetto

Ogni schema descritto sopra è in realtà un'affermazione sulla custodia della chiave. Esistono quattro opzioni e non sono equivalenti:

• Nella tua testa, digitata a ogni avvio. Massima protezione, massimo attrito operativo. La macchina non può davvero essere letta senza di te.
• In un file sulla macchina cifrata. Protegge contro una rivendita ingenua del disco e nient'altro. Se quel file si trova su un /boot in chiaro, non protegge assolutamente nulla — l'errore più comune in assoluto nella crittografia self-hosted.
• Su una macchina che controlli, recuperata via rete. Clevis vincolato a un server Tang: clevis luks bind -d /dev/vdb tang '{"url":"https://tang.example.net"}'. Il server si avvia senza supervisione finché riesce a raggiungere casa, e rifiuta di sbloccarsi altrove. Eccellente per flotte headless, e rende l'host Tang la cosa che va difesa.
• In un TPM. Ha senso su hardware che possiedi. Su un VPS il TPM virtuale è fornito dallo stesso hypervisor che stai cercando di escludere, quindi risolve la comodità, non la fiducia.

Un unico test chiarisce la maggior parte dei progetti: se la macchina può arrivare a un prompt di login senza di te, la chiave è sulla macchina. Può essere un compromesso del tutto ragionevole — molti carichi di lavoro vogliono riavvii senza supervisione più di quanto vogliano resistenza a un avversario determinato. Fai la scelta consapevolmente, e non descrivere il risultato come qualcosa che non è.

Cosa può vedere il tuo provider, e dove entra in gioco la giurisdizione

Su un VPS c'è un hypervisor sotto di te. Non leggiamo la memoria del guest, e non conserviamo log di traffico, connessione o DNS, né una traccia della console — ma queste sono politiche, e la cornice onesta è che un VPS ti chiede di fidarti di esse. Su bare metal non c'è alcun hypervisor tra te e il silicio: la crittografia full-disk configurata all'installazione con una passphrase che non riceviamo mai è una proprietà fisica della macchina, non una garanzia data da noi. È questa differenza, non la scelta del cifrario, ciò tra cui stai davvero scegliendo.

Ecco perché crittografia e giurisdizione sono due metà di un'unica risposta. La crittografia decide quanto vale una copia del tuo disco; la giurisdizione decide chi può obbligare a produrre la macchina, attraverso quale procedura e con quale rapidità. Operiamo in sette giurisdizioni — Islanda, Svizzera, Panama, Romania, Moldova, Paesi Bassi e Russia — e il ragionamento per scegliere tra loro si trova nella nostra guida alla giurisdizione, o in forma più breve tramite il selettore di giurisdizione e la pagina delle location.

La parte che la crittografia non può toccare è la divulgazione forzata, perché è rivolta a te, non all'hardware. Il Regno Unito, la Francia e l'Australia sono tra i paesi la cui legge può obbligare una persona a produrre una chiave di decrittazione o affrontare una sanzione per il rifiuto. Questa esposizione segue dove ti trovi tu, non dove si trova il server, e nessuna configurazione sulla macchina la cambia. Registrarsi senza documenti d'identità limita quanta traccia cartacea esiste fin dall'inizio — la ragione pratica, per nulla affascinante, per cui l'hosting no-KYC e la crittografia finiscono nella stessa conversazione — ma non è una difesa contro un tribunale che ha già il tuo nome.

Nove errori che trasformano la crittografia in decorazione

• Sblocco automatico da un file chiave sullo stesso disco. La maggioranza dei server «cifrati», l'equivalente di lasciare la chiave nella toppa.
• Cifrare un volume che i dati sensibili non raggiungono mai. Il vault è vuoto e il database non ci sta dentro.
• Non fare mai il backup dell'header LUKS. Un settore danneggiato all'inizio del container e ogni byte che lo segue è perso per sempre.
• Non testare mai il percorso di sblocco. Poi un aggiornamento del kernel rigenera l'initramfs e il riavvio successivo diventa un'operazione di soccorso.
• Formattare su una macchina grande e sbloccare su una piccola. Argon2id richiede memoria che il VPS non può fornire, e il volume non si aprirà.
• Scegliere una passphrase come una password di login. Nulla limita la velocità di un attacco offline tranne la funzione di derivazione della chiave. La lunghezza è ciò che compra tempo.
• Migrare testo in chiaro verso la crittografia presumendo che l'originale sia sparito. Su storage virtualizzato, la sovrascrittura non cancella in modo affidabile.
• Inviare la passphrase sullo stesso canale usato per amministrare la macchina. Server OpSec tratta il problema di correlazione che questo crea.
• Confondere la crittografia del tuo provider con la tua. «Tutta l'infrastruttura è cifrata a riposo» — la nostra inclusa — protegge l'infrastruttura. Solo una chiave che tieni tu ti protegge dall'infrastruttura.

Quindi vale la pena farlo su un VPS?

Sì, con aspettative calibrate. Per un'ora di lavoro e nessun costo di gestione misurabile, un volume dati cifrato elimina un'intera classe di esposizione a cui non puoi altrimenti porre rimedio, e la elimina in modo permanente: hardware dismesso, storage riassegnato, una macchina spenta in custodia altrui. Fai almeno questo su ogni server che contiene qualcosa di importante, subito dopo la checklist di hardening della prima ora.

Quello che non fa è trasformare un computer affittato nel tuo computer. Se il tuo modello di minaccia include il provider stesso come avversario, nessun cifrario risolve il problema — la risposta è l'hardware dedicato, dove la chiave viene digitata via IPMI e non passa mai attraverso un hypervisor, una giurisdizione scelta di proposito, e la disciplina di non mettere su nessun server ciò che non ha bisogno di starci. Far corrispondere il controllo alla minaccia reale è la differenza tra la privacy e la sua parvenza.