Mengenkripsi VPS terlihat seperti satu baris perintah — cryptsetup luksFormat, selesai — lalu diam-diam gagal memberikan apa yang orang kira mereka dapatkan. Di mesin yang Anda sewa, ada hypervisor yang duduk di bawah kernel Anda, sehingga model ancamannya bukan yang dirancang untuk dihadapi oleh full-disk encryption. Panduan ini adalah versi jujurnya: apa yang benar-benar dikalahkan LUKS di VPS, apa yang tidak, dua jalur deployment yang benar-benar berfungsi, dan cara membuka root terenkripsi lewat SSH supaya Anda tidak pernah terkunci dari server Anda sendiri.
Apa yang sebenarnya Anda dapatkan dari enkripsi di server sewaan
Full-disk encryption melindungi data at rest. Istilah itu menanggung banyak makna, dan di VPS ada gunanya menjabarkan momen mana yang terhitung "diam" dan mana yang tidak — celah di antara keduanya adalah tempat sebagian besar ekspektasi orang runtuh.
Hardware yang dipensiunkan
Drive rusak, diganti, lalu meninggalkan rak server. Volume LUKS di disk yang sudah mati hanyalah blok noise bagi siapa pun yang menanganinya berikutnya. Enkripsi menyelesaikan kasus ini sepenuhnya.
Volume yang dilepas atau disalin
Jika sebuah volume dicabut dari instance Anda, di-clone, atau di-image saat mesin dalam keadaan mati, hasilnya adalah ciphertext dan header — bukan file Anda.
Mesin yang sedang berjalan
Begitu volume terbuka, master key berada di memori kernel. Akses tingkat hypervisor pada prinsipnya bisa menjangkaunya. Enkripsi menaikkan biayanya di sini; ia tidak menutup pintunya.
Kesalahan Anda sendiri
Swap yang tidak terenkripsi, backup plaintext, dan log yang ditulis sebelum mount — semuanya berada di luar container. Sebagian besar kebocoran nyata dari server terenkripsi terjadi di sini, bukan lewat cipher-nya.
Ucapkan batasannya dengan jelas supaya Anda bisa merencanakan sekitarnya: selama volume terbuka, key-nya berada di RAM pada hardware yang bukan milik Anda. LUKS di VPS adalah jawaban yang kuat untuk akses offline, dan jawaban yang parsial untuk akses saat mesin hidup. Padukan dengan yurisdiksi yang benar-benar Anda percayai — lihat /offshore-hosting — alih-alih memperlakukannya sebagai pengganti yurisdiksi tersebut.
Pilih bentuknya sebelum Anda mengetik satu perintah pun
Empat susunan ini mencakup hampir semua kebutuhan nyata. Memilih yang salah berakibat pada instal ulang, jadi putuskan di sini, bukan di tengah jalan.
Jalur A — mengenkripsi volume data di server yang sudah Anda jalankan
Ini adalah versi yang sebenarnya diinginkan kebanyakan orang: sepuluh menit kerja, tanpa instal ulang, dan semua yang penting berakhir di dalam container. Pasang volume kedua terlebih dahulu — pada paket /storage itu adalah disk besarnya; pada /vps standar Anda bisa menambahkannya saat deploy.
- 1
Identifikasi device target
Jalankan lsblk dan pastikan device yang akan Anda format memang yang kosong. luksFormat menghancurkan apa pun yang ada di dalamnya dan tidak ada undo.
- 2
Buat container LUKS2
cryptsetup luksFormat --type luks2 /dev/vdb akan meminta Anda mengetik YES dalam huruf kapital, lalu mengatur passphrase. Pilih passphrase yang bisa Anda ketik ulang dengan benar di console tanpa history dan tanpa echo.
- 3
Buka lalu pasang filesystem
cryptsetup open /dev/vdb cryptdata membuat /dev/mapper/cryptdata. Lalu mkfs.ext4 /dev/mapper/cryptdata dan mount di tempat data itu akan berada, misalnya /srv/data.
- 4
Tentukan cara volume ini dibuka saat boot
Anda bisa mengetik passphrase setiap kali reboot, atau menambahkan keyfile dengan cryptsetup luksAddKey dan menyimpannya di root. Keyfile itu praktis dan jelas-jelas lebih lemah — pahami betul trade-off yang Anda ambil.
- 5
Sambungkan crypttab dan fstab
Tambahkan mapping-nya ke /etc/crypttab menggunakan UUID= alih-alih nama device, lalu mount dari /etc/fstab dengan opsi nofail supaya kegagalan unlock tidak pernah menggantung proses boot.
Jika keyfile itu berada di root yang tidak terenkripsi, pahami dengan tepat apa yang Anda dapatkan: volume itu terlindungi dari disk yang meninggalkan rak atau dilepas dari instance Anda, tapi tidak terlindungi dari salinan seluruh VM — karena salinan itu memuat key-nya juga. Apa pun yang lebih kuat dari ini membutuhkan passphrase yang datang dari luar server.
Jalur B — root terenkripsi dari custom ISO
Ketika kebutuhannya adalah tidak ada apa pun yang bisa dibaca di mesin itu saat mati, root itu sendiri harus berada di dalam LUKS. Itu berarti instalasi baru yang dijalankan dari console, di provider yang mengizinkan Anda boot dari ISO Anda sendiri.
- 1
Boot installer dari console
Mount ISO netinst Debian atau Ubuntu sebagai custom ISO dan jalankan instalasinya lewat VNC atau serial. Semua ini tidak bisa dilakukan lewat SSH — belum ada sistem yang bisa disambungi.
- 2
Gunakan guided partitioning dengan LVM terenkripsi
Installer meninggalkan /boot kecil dalam keadaan tidak terenkripsi, karena ada sesuatu yang harus berjalan sebelum volume itu terbuka, lalu menempatkan root dan swap di dalam satu container LUKS.
- 3
Pilih passphrase yang bisa Anda ketik tanpa melihat
Anda akan mengetiknya ulang lewat SSH di setiap reboot, tanpa echo dan tanpa autocomplete. Passphrase lima kata lebih unggul daripada kumpulan simbol acak di sini.
- 4
Siapkan remote unlock sebelum Anda log out
Root yang baru saja dienkripsi akan diam selamanya di prompt passphrase setelah reboot berikutnya. Konfigurasikan remote unlock dalam sesi yang sama, selagi console masih ada di depan Anda.
Pada paket dengan RAM 1–2 GB, key derivation Argon2id default bisa meminta memori lebih banyak daripada yang dimiliki initramfs, sehingga unlock gagal saat boot meskipun passphrase-nya benar. Batasi saat format dengan cryptsetup luksFormat --pbkdf-memory 262144, atau periksa header yang sudah ada dengan cryptsetup luksDump sebelum mempercayakan instance kecil untuk reboot tanpa pengawasan.
Remote unlock lewat SSH dengan dropbear-initramfs
Root terenkripsi membutuhkan passphrase sebelum sistem operasinya ada. dropbear-initramfs menaruh SSH server mungil di dalam initramfs supaya Anda bisa memasukkan passphrase itu dari mana saja — inilah bedanya antara server terenkripsi dan batu bata terenkripsi.
- 1
Instal package-nya
apt install dropbear-initramfs. Package ini mengait ke proses pembuatan initramfs dan otomatis dibangun ulang ke setiap image kernel berikutnya.
- 2
Otorisasi satu key, dan hanya satu perintah
Taruh public key Anda di /etc/dropbear/initramfs/authorized_keys — pada Debian 11 dan versi lebih lama, di /etc/dropbear-initramfs/authorized_keys. Beri prefix baris itu dengan no-port-forwarding,no-agent-forwarding,no-x11-forwarding,command="cryptroot-unlock" supaya key yang dicuri sekalipun cuma mendapat sebuah prompt, tidak lebih.
- 3
Berikan initramfs sebuah jaringan
DHCP berfungsi di tempat provider menyediakannya; jika tidak, tambahkan parameter statis ip=ADDRESS::GATEWAY:NETMASK::eth0:off ke GRUB_CMDLINE_LINUX lalu jalankan update-grub. Selesaikan dengan update-initramfs -u -k all supaya perubahannya masuk ke dalam image.
- 4
Uji satu reboot penuh sebelum Anda mengandalkannya
Reboot dengan console provider terbuka di jendela lain, sambungkan, masukkan passphrase, dan amati proses boot berlanjut. Jalur unlock yang belum diuji bukanlah fitur, melainkan outage yang menunggu waktu.
initramfs membawa SSH host key-nya sendiri, berbeda dari yang ditampilkan sistem setelah boot selesai, sehingga klien SSH Anda akan memperingatkan soal host key yang berubah di setiap reboot. Jalankan dropbear di port terpisah lewat DROPBEAR_OPTIONS di /etc/dropbear/initramfs/dropbear.conf, atau sambungkan dengan ssh -o HostKeyAlias=box-initramfs, dan catat kedua fingerprint-nya.
Key management adalah titik di mana enkripsi disk biasanya gagal
Cipher-nya bukan bagian yang lemah, dan memang tidak pernah menjadi bagian yang lemah. Setiap bencana yang masih bisa dipulihkan yang melibatkan LUKS pada akhirnya selalu berujung pada key atau header, jadi perlakukan keduanya sebagai infrastruktur.
- Backup header-nya segera — cryptsetup luksHeaderBackup /dev/vdb --header-backup-file luks-header.img — dan simpan di luar server. Header yang rusak akibat satu kesalahan dd saja berarti kehilangan data permanen, sekalipun passphrase-nya sempurna.
- Gunakan dua slot. LUKS2 memberi Anda 32 slot: passphrase Anda di satu slot, recovery key acak yang panjang di slot lain, disimpan di password manager. Satu slot saja adalah single point of failure yang Anda ciptakan sendiri.
- Rotasi dengan urutan yang benar di mesin remote — tambahkan key baru dengan luksAddKey, verifikasi key itu bisa membuka volume, baru kemudian hapus key lama dengan luksKillSlot. Jangan pernah membalik urutannya.
- Simpan passphrase dan detail koneksi server di tempat yang terpisah. Satu catatan yang bocor seharusnya tidak menyerahkan alamat sekaligus key-nya.
Berapa biaya enkripsi dari sisi performa
Overhead-nya nyata tapi biasanya tidak terasa. Ukur di mesin yang benar-benar Anda pakai, bukan sekadar percaya pada benchmark dari dekade lain.
Bagian-bagian yang sering dilupakan orang
Volume terenkripsi yang di sekelilingnya masih bocor plaintext hanyalah rasa aman yang palsu, dan itu lebih buruk daripada tidak ada rasa aman sama sekali. Tutup lima celah ini sebelum menganggap pekerjaannya selesai.
- Swap. Partisi swap yang tidak terenkripsi bisa menyimpan potongan dari apa pun yang pernah melewati memori. Enkripsi dengan key acak yang baru di setiap boot lewat entry /dev/urandom di /etc/crypttab.
- Log yang ditulis sebelum mount. Apa pun yang dicatat selagi volume terenkripsi masih tertutup akan mendarat di root yang polos. Arahkan log aplikasi dan database ke path di dalam container.
- Backup. Menyalin isi volume terenkripsi ke object storage plaintext membatalkan seluruh usaha ini. Enkripsi backup-nya secara terpisah dengan restic, borg, atau age, dan simpan key-key itu di tempat lain.
- Snapshot. Snapshot dari provider menangkap disknya, bukan RAM Anda, sehingga volume LUKS tetap berupa ciphertext di dalamnya — tapi semua yang tertinggal di root yang tidak terenkripsi ikut tertangkap persis apa adanya.
- Discard. Meneruskan flag discard lewat LUKS menjaga trim NVMe tetap berfungsi, tapi juga mempublikasikan blok mana yang tidak terpakai — membocorkan seberapa penuh filesystem-nya dan kira-kira bagaimana bentuknya. Pilih ini dengan sengaja, bukan dengan menyalin config orang lain.
Di mana host masih berperan
Enkripsi adalah lapisan yang Anda kendalikan: ia menentukan seberapa mahal biaya untuk membaca data Anda begitu mesinnya mati atau disknya meninggalkan gedung. Lapisan di sekelilingnya — siapa yang bisa memaksa akses ke hardware, dan catatan apa yang menghubungkan server dengan Anda — adalah wilayah provider dan yurisdiksinya. Enam dari lima belas region kami adalah yurisdiksi privacy-tier; /locations mencantumkan daftarnya, dan /offshore-hosting membahas apa yang sebenarnya berubah karena itu.
Tiga kemampuan provider yang menentukan apakah jalur-jalur di atas bahkan tersedia: boot custom ISO, yang tanpanya Jalur B mustahil dilakukan; akses console out-of-band untuk reboot di saat remote unlock tidak kembali menyala; dan proses signup yang sejak awal tidak pernah mengaitkan mesin itu dengan identitas legal Anda. Setiap paket /offshore-vps dan /storage di sini bisa boot custom ISO, dilengkapi akses console, dan ditagih dari saldo crypto prabayar tanpa KYC — sehingga disk terenkripsi Anda tidak duduk di atas jejak dokumen yang sudah menyebut nama Anda. /guides punya panduan jujur soal apa yang bisa dan tidak bisa dilihat oleh sebuah host.
Checklist deployment
- Kenali dulu ancamannya: drive yang dipensiunkan, volume yang dilepas, dan image offline adalah hal-hal yang dijawab oleh enkripsi — hypervisor yang hidup bukan salah satunya.
- Enkripsi volume data (Jalur A) jika server sudah berjalan; instal ulang dari custom ISO (Jalur B) hanya ketika root itu sendiri harus dienkripsi.
- LUKS2 dengan aes-xts-plain64, dan batasi memori Argon2id pada paket mana pun dengan RAM di bawah 2 GB.
- Passphrase di satu key slot, recovery key acak yang panjang di slot lain, keduanya disimpan di luar server.
- Ambil backup header LUKS sebelum menulis byte pertama data sungguhan.
- dropbear-initramfs di port non-default, hanya lewat key, dibatasi hanya pada perintah cryptroot-unlock.
- Uji satu siklus reboot-dan-unlock secara lengkap dengan console provider tetap terbuka di samping Anda.
- Backup offsite yang terenkripsi, ditambah satu latihan restore — backup yang belum diuji hanyalah harapan, bukan backup.
Apakah enkripsi disk menghentikan penyedia hosting saya dari membaca data saya?
Saat data at rest, ya: begitu mesin mati, volume-nya adalah ciphertext dan passphrase-nya tidak pernah keluar dari kepala Anda. Selagi server berjalan dengan volume terbuka, master key-nya berada di RAM pada hardware yang dioperasikan provider. Enkripsi menutup setiap jalur offline — drive yang dipensiunkan, volume yang dilepas, image dingin — dan menaikkan biaya untuk sisanya. Ini melengkapi yurisdiksi yang bisa dipercaya, bukan menggantikannya.
Bisakah saya mengenkripsi VPS yang sudah ada tanpa instal ulang?
Untuk volume data terpisah, bisa, dalam waktu sekitar sepuluh menit — itulah Jalur A di atas. Untuk root filesystem, secara realistis tidak. cryptsetup reencrypt bisa mengonversi filesystem di tempat, tapi koneksi yang terputus atau listrik yang mati di tengah proses pada mesin remote akan meninggalkan server yang tidak bisa boot dan malam yang panjang. Instal ulang dari custom ISO lebih cepat dan jauh lebih aman.
Berapa banyak performa yang dikorbankan LUKS?
Lebih sedikit daripada yang dikira kebanyakan orang. Dengan AES-NI, AES-XTS hanya memakan beberapa persen pada workload campuran yang umum, dan cryptsetup benchmark di core EPYC modern melaporkan beberapa GB/s. Kasus yang terasa adalah I/O sequential single-threaded terhadap NVMe cepat, di mana satu core bisa jenuh sebelum drive-nya sendiri. Benchmark instance Anda sendiri, jangan menebak-nebak.
Apa yang terjadi jika saya lupa passphrase-nya?
Datanya hilang. Tidak ada mekanisme recovery, tidak ada master key di sisi provider, dan tidak ada tiket support yang bisa membatalkannya — sifat itu memang tujuan dari desainnya. Lindungi diri Anda dengan key slot kedua yang menyimpan recovery key acak, dan dengan backup header LUKS yang disimpan di tempat lain, bukan di server.
Apakah menjalankan SSH di dalam initramfs berisiko?
Ini adalah eksposur kecil yang sudah dipahami dengan baik. dropbear hanya berjalan selama beberapa detik sebelum root filesystem Anda ada, hanya menerima public key, dan bisa dibatasi hanya pada satu perintah paksa yang tidak melakukan apa-apa selain menampilkan prompt passphrase. Di port non-default, dengan host key initramfs yang dicatat terpisah, risiko praktisnya minimal dibanding kepastian terkunci keluar tanpa fitur ini.
