Guida al server di crittografia completa del disco LUKS

LUKS (Linux Unified Key Setup) crittografa un intero dispositivo a blocchi Linux in modo che i contenuti siano illeggibili senza la chiave master. Un disco rubato, uno chassis dismesso, un disco di backup dimenticato: nessuno di questi espone i vostri dati una volta che LUKS è configurato correttamente. Questo post illustra come implementare la crittografia completa del disco LUKS su un server, inclusi il layout LVM, la gestione delle chiavi, lo sblocco remoto e le modalità di errore che impediscono agli utenti di accedere ai propri dati.

L'implementazione di riferimento qui è LUKS2 con LVM all'interno del contenitore crittografato, su un server Linux con AES-NI nella CPU. Questa combinazione gestisce ogni carico di lavoro moderno, offre buone prestazioni e soddisfa i requisiti relativi ai dati inattivi previsti da HIPAA, PCI-DSS, GDPR e SOC 2.

Perché LUKS2 e cosa controllare per primo

LUKS esegue la crittografia a livello di dispositivo a blocchi utilizzando dm-crypt, con la chiave master memorizzata in slot all'interno dell'intestazione LUKS. Questa separazione è importante: è possibile ruotare le passphrase o aggiungere nuove chiavi senza ricrittografare il disco.

LUKS2 è l'impostazione predefinita attuale. Supporta fino a 32 slot per le chiavi, metadati in formato JSON, ricrittografia online e crittografia autenticata tramite il --integrity flag. LUKS1 supporta 8 slot per le chiavi e va bene sui sistemi più vecchi, ma le nuove installazioni dovrebbero partire con LUKS2.

Il sovraccarico di prestazioni con AES-NI è solitamente inferiore al 5% sull'hardware moderno. Verifica prima di iniziare:

grep -o aes /proc/cpuinfo | head -1
cryptsetup benchmark

Se grep non restituisce alcun risultato, la CPU non dispone di AES-NI e la crittografia sarà limitata dalla CPU in caso di I/O intenso. cryptsetup benchmark mostra la velocità effettiva per ogni algoritmo di cifratura, così puoi scegliere quello più veloce supportato dal tuo hardware. Verifica anche che cryptsetup sia installato e che il dm-crypt modulo del kernel sia disponibile. Entrambi sono forniti di default su Ubuntu, Debian, RHEL e Arch.

Layout del disco

Due partizioni rimangono non crittografate: la partizione di sistema EFI (512 MB FAT32) e /boot (da 1 a 2 GB, ext4 o xfs). GRUB deve leggere entrambe prima di poter richiedere la passphrase. Tutto il resto risiede all'interno del contenitore LUKS.

La struttura consigliata è LVM all'interno di LUKS: un contenitore LUKS che contiene un gruppo di volumi LVM, con volumi logici per root, swap e qualsiasi partizione di dati. Questo mantiene crittografati i metadati LVM e consente di ridimensionare o creare snapshot dei volumi senza toccare il livello LUKS. Anche LUKS su LVM funziona, ma espone la struttura del gruppo di volumi.

ext4 è l'impostazione predefinita sicura per il volume root. xfs gestisce meglio i file di grandi dimensioni e le scritture parallele, il che è importante per i server multimediali, di messaggistica istantanea e di database. Per SSD e NVMe, aggiungere l' discard opzione in /etc/crypttab per abilitare TRIM. TRIM rivela quali settori sono in uso, il che costituisce una piccola fuga di informazioni. Per la maggior parte dei carichi di lavoro vale la pena per il beneficio del livellamento dell'usura. Se il vostro modello di minaccia include l'analisi forense del dispositivo, lasciatela disabilitata.

Configurazione di LUKS con LVM

Identificare il disco di destinazione con lsblk e cancellare eventuali metadati esistenti:

wipefs -a /dev/sdX

Facoltativamente, sovrascrivere con dati casuali in modo che i blocchi crittografati non siano distinguibili dallo spazio vuoto:

dd if=/dev/urandom of=/dev/sdX bs=1M status=progress

Inizializza il contenitore LUKS2. Usa --sector-size 4096 per NVMe e SSD moderni con settori fisici da 4K:

cryptsetup luksFormat --type luks2 --sector-size 4096 /dev/sdX
cryptsetup luksOpen /dev/sdX cryptdata

Eseguire immediatamente il backup dell'intestazione, prima di inserire qualsiasi dato sul disco:

cryptsetup luksHeaderBackup /dev/sdX --header-backup-file luks-header-backup.img

Creare LVM sopra il contenitore sbloccato, quindi formattare i volumi logici:

pvcreate /dev/mapper/cryptdata
vgcreate vg_secure /dev/mapper/cryptdata
lvcreate -L 50G -n lv_root vg_secure
lvcreate -L 8G -n lv_swap vg_secure
 
mkfs.xfs /dev/vg_secure/lv_root
mkswap /dev/vg_secure/lv_swap

Aggiungere una voce a /etc/crypttab utilizzando l'UUID, non /dev/sdX, che può cambiare tra un riavvio e l'altro. Ottenilo con blkid /dev/sdX:

cryptdata UUID=<your-uuid> none luks,discard

Quindi montare tramite /etc/fstab:

/dev/vg_secure/lv_root  /  xfs  defaults,noatime  0 1

Rigenera l'initramfs in modo che i hook di crittografia vengano caricati all'avvio:

# Debian/Ubuntu
update-initramfs -u -k all
 
# RHEL/Fedora
dracut -f --regenerate-all

Riavvia, inserisci la passphrase e conferma la configurazione con cryptsetup status cryptdata e lsblk -f. Quest'ultimo dovrebbe mostrare crypto_LUKS come FSTYPE sulla partizione crittografata.

Gestione delle chiavi e sblocco remoto

LUKS2 supporta 32 slot per chiavi. Utilizzarne almeno tre fin dall'inizio: una passphrase di amministratore, una chiave di ripristino conservata offline (stampata e chiusa a chiave, oppure su una chiavetta USB crittografata in una cassaforte) e un file chiave per lo sblocco automatico dei volumi di dati secondari. Attenersi ai 95 caratteri ASCII stampabili, poiché i caratteri non ASCII causano problemi di layout della tastiera al prompt di avvio che sono fastidiosi da risolvere. Cambiare la passphrase di amministratore ogni volta che qualcuno con accesso lascia il team.

Visualizza gli slot attivi con cryptsetup luksDump /dev/sdX, aggiungi una chiave con cryptsetup luksAddKeye revoca una chiave con cryptsetup luksKillSlot. Proteggi tutti i file chiave con permessi rigorosi:

chmod 0400 /etc/luks/keyfile.bin

Per i server headless nei data center remoti, la richiesta della passphrase è un problema. Tre modi per gestirla:

Dropbear esegue un piccolo server SSH nell'initramfs. Si accede via SSH dopo l'avvio e si inserisce la passphrase manualmente. Clevis con Tang utilizza la crittografia del disco legata alla rete: il server si sblocca da solo purché riesca a raggiungere un server Tang sulla rete fidata. Tang non memorizza la tua chiave, ma fornisce una metà di uno scambio McCallum-Relyea. Utilizza più server Tang con il sss pin in modo che lo sblocco funzioni anche se uno è offline. Il binding TPM 2.0 tramite systemd-cryptenroll lega la chiave al PCR 7 (stato di avvio sicuro), quindi il server si sblocca solo se il firmware e il bootloader non sono stati manomessi. Mantenere sempre uno slot per la passphrase come soluzione di riserva quando si utilizza il TPM, poiché gli aggiornamenti del firmware modificano i valori PCR.

Rafforzamento della sicurezza ed evitare blocchi

Utilizzare passphrase di almeno 20 caratteri. Abilitare la crittografia autenticata con --integrity tempo luksFormat se il vostro modello di minaccia include la manomissione dei dati piuttosto che la sola riservatezza. Ciò comporta un costo di amplificazione della scrittura, quindi effettuate prima un benchmark.

Non clonare un contenitore LUKS su macchine diverse. La chiave del volume viene copiata insieme ad esso, quindi cambiare la passphrase su un host non proteggerà l’altro. Riformatta ogni disco singolarmente.

Per una messa fuori servizio sicura, cryptsetup erase /dev/sdX cancella tutti gli slot delle chiavi in pochi millisecondi, rendendo il disco irrecuperabile senza distruzione fisica. Questo da solo è un argomento forte a favore della crittografia di tutto per impostazione predefinita.

Modalità di guasto comuni:

La modalità di errore più grave è il danneggiamento dell'intestazione. Se l'intestazione LUKS viene persa o danneggiata, i dati vanno persi. Non c'è modo di recuperarli se non ripristinandoli da un backup dell'intestazione. Conserva una copia su un supporto separato, idealmente in due posizioni, e mai sul disco crittografato stesso. Per i volumi secondari non critici, aggiungi nofail a /etc/crypttab in modo che un montaggio non riuscito non blocchi l'avvio.

I server dedicati FDC vengono forniti con hardware che supporta AES-NI e la crittografia completa del disco già di serie. Configura un server dedicato quando sei pronto per l'implementazione.