"VPS cifrato" è una frase che molti host sbandierano senza dire da cosa protegge. Preferiamo essere diretti, perché chi tiene a questo tiene all'accuratezza. Puoi eseguire archiviazione cifrata su un VPS — un volume dati cifrato con LUKS che sblocchi con una passphrase — e protegge davvero i tuoi dati a riposo. Ciò che non fa è rendere un server in esecuzione invisibile a chi controlla l'hardware fisico. Ecco la forma onesta della cosa, e come configurarla.
Cosa fa la cifratura su un VPS — e cosa no
Cosa è reale: un volume LUKS è testo cifrato quando è bloccato. Spegni il server, o semplicemente non sbloccare il volume, e i file sono illeggibili senza la tua passphrase. Un disco dismesso, imageato a freddo o sequestrato da spento non consegna nulla di leggibile. È una protezione genuina e utile — ed è la minaccia comune per la maggior parte delle persone (un disco ritirato, uno snapshot a freddo, un accesso occasionale).
Cosa non è: finché il volume è montato e il server gira, la chiave di cifratura è nella RAM, e il provider opera l'hypervisor sotto la tua VM. La cifratura dell'intero disco su qualsiasi VPS — nostro o di chiunque — non può proteggere un volume in esecuzione e sbloccato da un operatore determinato della macchina fisica. Qualsiasi host che promette il contrario sta vendendo troppo. Noi non lo faremo.
Quindi: protezione reale a riposo, limiti onesti in esecuzione. Quel compromesso vale la pena per un archivio dati privato che tieni illeggibile quando inattivo — abbinato a registrazione senza KYC così che l'archivio non sia legato alla tua identità in primo luogo.
Configura un volume cifrato LUKS (Ubuntu 24.04)
# encrypt a data file/volume with LUKS; keep the passphrase OFF the server
apt update && apt install -y cryptsetup
# create a 20 GB encrypted container (or point at a raw data disk)
fallocate -l 20G /srv/secure.img
cryptsetup luksFormat /srv/secure.img # sets your passphrase
cryptsetup luksOpen /srv/secure.img secure # unlock → /dev/mapper/secure
mkfs.ext4 /dev/mapper/secure
mkdir -p /mnt/secure && mount /dev/mapper/secure /mnt/secure
# your files live in /mnt/secure — ciphertext once closed
Dopo un riavvio il volume resta bloccato finché non lo sblocchi tu stesso:
cryptsetup luksOpen /srv/secure.img secure # enter passphrase over SSH
mount /dev/mapper/secure /mnt/secure
Non memorizzare mai la passphrase sul server. Sblocca manualmente (o incanalala tramite la tua sessione SSH) così che la chiave esista solo in memoria mentre la usi. Non metterla in uno script di boot — questo vanifica lo scopo.
Ambito onesto, un'altra volta
- Protegge: i dati a riposo — spento, prima dello sblocco, snapshot a freddo, disco ritirato.
- Non protegge: un volume in esecuzione e sbloccato da qualcuno con controllo fisico/hypervisor.
- Non è anonimato di per sé: il tuo server ha ancora un IP pubblico e traffico sul filo. Questo riguarda la riservatezza dei dati a riposo, combinata con fatturazione senza KYC.
Se il tuo modello di minaccia è la pressione legale più che un disco rubato, il segnale più significativo è il nostro warrant canary — una dichiarazione datata che non abbiamo avuto ordini segreti o richieste di indebolire la sicurezza, tenuta aggiornata. Un canary che puoi osservare batte un distintivo di cifratura che non puoi verificare. Vedi anche l'analisi onesta del VPS anonimo su cosa il senza-KYC ti dà e non ti dà.
Perché EQVPS per archiviazione cifrata
- Root completo, così LUKS e il tuo flusso di sblocco sono interamente tuoi — nessun deposito chiave del provider, nessuna passphrase memorizzata al boot a meno che tu lo scelga.
- Niente KYC, pagamento in cripto. Email per registrarti, USDC/USDT per pagare — l'archivio non è saldato alla tua identità.
- UE (Germania, Finlandia), vera legge sulla protezione dei dati, un warrant canary pubblico, root in ~60 secondi.
VPS anonimo, senza KYC — la versione onesta → · Self-host Vaultwarden (cassaforte cifrata) →
Commenti
Ancora nessun commento. Sii il primo.