Enkripsi Disk Penuh di VPS

Enkripsi disk penuh menjawab tepat satu pertanyaan: apa yang didapat penyerang ketika mereka menguasai storage Anda dan mesinnya dalam keadaan mati? Setiap pertanyaan lain yang mungkin Anda miliki — apa yang bisa dilihat oleh host, apa yang terjadi jika server yang sedang berjalan disita, apakah backup Anda aman — punya jawaban yang berbeda, dan memperlakukan semuanya sebagai satu hal adalah cara orang berakhir dengan enkripsi yang tidak melindungi apa pun.

Perbedaan itu layak disampaikan secara terus terang, karena "LUKS-encrypted" muncul di setiap halaman privacy-hosting di industri ini, termasuk milik kami. Ini adalah kontrol yang nyata, hampir tidak memakan biaya untuk dijalankan, dan sekaligus merupakan kontrol yang paling berlebihan klaimnya dalam hosting. Panduan ini membahas apa yang sungguh-sungguh dicegah oleh enkripsi saat disimpan pada server sewaan, tiga susunan yang layak diterapkan beserta perintah untuk masing-masing, dua pengaturan yang benar-benar penting pada VPS kecil, dan sederet kesalahan yang mengubah seluruh usaha ini menjadi sekadar dekorasi.

Apa yang sebenarnya dilindungi oleh enkripsi saat disimpan

Enkripsi saat disimpan berarti byte pada media storage adalah ciphertext setiap kali volume dalam keadaan tertutup. Itu adalah klaim yang sempit, dan nilainya bergantung pada satu variabel: di mana kunci itu berada pada saat penyerang datang.

Bacalah itu sebagai sebuah definisi, bukan sebuah kekecewaan. Menghilangkan kelas eksposur akibat disk yang dicabut layak diperjuangkan dengan satu jam kerja justru karena itulah satu-satunya kelas yang tidak Anda miliki pertahanan lain untuknya, dan yang terjadi tanpa ada seorang pun menargetkan Anda: hardware rusak dan dikembalikan, array dipensiunkan, volume diterbitkan ulang untuk penyewa berikutnya. Enkripsi mengubah semua itu menjadi bukan-peristiwa.

Mengapa VPS bukan laptop

Pada laptop, desainnya sudah jelas dengan sendirinya. Anda mengetik passphrase saat boot, kuncinya hanya ada di RAM selagi mesin menyala, dan mematikannya mengakhiri cerita itu. Server tidak punya siapa pun di depan konsolnya. Sesuatu harus menyediakan kunci pada setiap boot, dan setiap kandidat untuk "sesuatu" itu mempertukarkan ketersediaan dengan perlindungan:

• Seorang manusia mengetikkannya. Susunan paling kuat, karena kuncinya tidak pernah beristirahat di mesin — tapi server tidak bisa kembali dari reboot tanpa Anda, dan Anda butuh cara masuk sebelum sistem operasinya ada.
• Mesin itu sendiri yang menyimpannya. Praktis, dan pada sebagian besar setup buatan sendiri justru menggagalkan tujuannya sendiri: file kunci pada virtual disk yang sama berarti siapa pun yang menguasai disk itu juga menguasai kuncinya.
• Mesin lain yang menyerahkannya. Unlock terikat jaringan, biasanya Clevis dengan server Tang. Server hanya membuka dirinya sendiri selama ia masih bisa menjangkau host yang Anda kendalikan, yang merupakan sifat yang sungguh berguna — sekaligus pemindahan kepercayaan, bukan penghapusannya.

Ada perbedaan kedua yang dilewatkan sebagian besar panduan. Pada VPS, /boot dan initramfs berbentuk plaintext, keduanya berada pada storage yang pada akhirnya dikuasai oleh provider, dan tidak ada rantai boot yang bisa Anda verifikasi — tidak ada TPM milik Anda sendiri, tidak ada measured boot, tidak ada yang bisa di-attest. Host yang menginginkan passphrase Anda bisa mengubah initramfs dan mengumpulkannya pada kali berikutnya Anda melakukan unlock. Itu bukan gambaran tentang sesuatu yang kami lakukan; itu gambaran tentang apa yang diizinkan oleh arsitekturnya, yang merupakan satu-satunya cara jujur untuk menalar tentang komputer yang Anda sewa. Perbandingan VPS versus dedicated kami menyusuri batas kepercayaan yang sama dari sisi hardware, dan jawaban jujur kami soal anonimitas offshore menerapkan disiplin yang sama pada pemasaran di sekitarnya.

Tiga susunan yang layak diterapkan

Tidak ada satu setup tunggal yang benar — yang ada adalah setup yang mode kegagalannya bisa Anda terima. Ketiga susunan ini mencakup hampir semua kasus nyata.

Mulailah dengan yang pertama kecuali Anda punya alasan khusus untuk tidak melakukannya. Ini memberikan sebagian besar perlindungan dengan sebagian kecil risiko operasional, dan memiliki satu sifat yang tidak dimiliki dua lainnya: tidak ada apa pun di dalamnya yang bisa menghalangi server untuk kembali online. Susunan ketiga adalah satu-satunya di mana passphrase menjadi fakta yang tidak bisa dijangkau host, bukan sekadar janji yang dibuat host, itulah sebabnya dedicated server kami menerapkan LUKS saat instalasi dengan passphrase yang tidak pernah kami lihat.

Mengenkripsi volume data pada VPS yang sedang berjalan

Inilah susunan yang layak dicoba lebih dulu. Tidak ada yang perlu diinstal ulang, tidak ada yang berubah pada proses boot, dan jika Anda membuat kesalahan, hasil terburuknya hanyalah sebuah file container yang Anda buang. Lima belas menit pada server Debian atau Ubuntu yang aktif.

• Instal tooling-nya. apt install cryptsetup. Jika paket Anda memberi Anda block device kedua, gunakan itu langsung dan lewati langkah berikutnya.
• Buat sebuah container. Pada VPS dengan satu disk, cara praktisnya adalah sebuah file: fallocate -l 40G /var/lib/vault.img. Ini berperilaku seperti disk dan bisa diperbesar nanti.
• Format sebagai LUKS2. cryptsetup luksFormat --type luks2 /var/lib/vault.img. Gunakan default untuk cipher-nya; bagian di bawah membahas satu parameter yang layak disentuh pada server kecil.
• Buka dan pasang filesystem. cryptsetup open /var/lib/vault.img vault memberi Anda /dev/mapper/vault; lalu mkfs.ext4 /dev/mapper/vault dan mount /dev/mapper/vault /srv/vault.
• Pindahkan data yang penting, lalu arahkan layanan ke sana. Bind mount, atau rsync dengan layanan dihentikan sementara, biasanya lebih bersih dibanding symlink — database khususnya tidak suka diikuti ke mana-mana.
• Backup header LUKS-nya. cryptsetup luksHeaderBackup /var/lib/vault.img --header-backup-file vault-header.bin, lalu pindahkan file itu keluar dari server. Beberapa kilobyte yang rusak di awal container menghancurkan setiap byte di belakangnya, secara permanen, dan inilah satu-satunya asuransi yang ada.
• Tutup, lalu buktikan Anda bisa masuk kembali. umount /srv/vault && cryptsetup close vault, lalu buka lagi berdasarkan catatan Anda, bukan dari ingatan. Lakukan ini sebelum ada apa pun yang berharga di dalamnya.

Setelah reboot, vault-nya tetap tertutup sampai Anda login dan membukanya. Itu bukan keterbatasan yang perlu direkayasa ulang — itu justru intinya. Volume yang membuka dirinya sendiri adalah volume yang kuncinya ada di mesin.

Enkripsi full-root dengan remote unlock lewat SSH

Ketika kebutuhannya adalah tidak ada yang bisa dibaca yang selamat dari penyitaan saat mesin mati — log, riwayat shell, daftar paket, gambaran umum tentang apa yang Anda jalankan — root filesystem-nya juga harus berada di dalam container. Masalahnya kemudian menjadi bagaimana memasukkan passphrase ke mesin yang belum boot, dan jawabannya adalah SSH server mungil yang hidup di dalam initramfs.

• Instal dalam keadaan terenkripsi sejak awal. Boot installer distro lewat unggah ISO kustom dan pilih guided partitioning dengan LVM terenkripsi. Mengonversi root filesystem yang sedang berjalan di tempatnya mungkin dilakukan, tapi tidak sepadan dengan risikonya.
• Tambahkan SSH server pre-boot. apt install dropbear-initramfs, lalu masukkan public key Anda ke /etc/dropbear/initramfs/authorized_keys. Ini adalah set kunci terpisah dari SSH normal Anda — gunakan kunci khusus.
• Kunci semuanya. Di /etc/dropbear/initramfs/dropbear.conf, atur DROPBEAR_OPTIONS="-I 180 -j -k -p 2222 -s": tanpa login kata sandi, tanpa port forwarding, port sendiri, dan idle timeout supaya sesi yang macet tidak menahan proses boot tetap terbuka.
• Beri initramfs sebuah jaringan. Tambahkan parameter ip= statis ke GRUB_CMDLINE_LINUX di /etc/default/grub — bentuknya adalah ip=address::gateway:netmask::interface:off. Mengandalkan DHCP pada tahap ini adalah cara orang berakhir terkunci di luar.
• Rebuild dan reboot. update-initramfs -u && update-grub, lalu reboot dan sambungkan dengan ssh -p 2222 root@your-server serta jalankan cryptroot-unlock. Klien Anda akan memperingatkan soal host key yang tidak dikenal: initramfs punya host key sendiri, itu memang wajar dan layak di-pin dalam entri known_hosts yang terpisah.
• Uji jalur kegagalannya sebelum Anda mengandalkannya. Instal update kernel, reboot, lakukan unlock lagi. Upgrade kernel meregenerasi initramfs, dan justru di situlah kesalahan konfigurasi muncul ke permukaan.

Dua pengaturan yang penting, dan jebakan VPS kecil

LUKS2 secara default menggunakan AES-XTS dengan kunci 512-bit dan key derivation Argon2id. Keduanya sudah tepat. Menyetel cipher secara manual adalah cara untuk menjadi lebih lambat sekaligus lebih lemah, dan internet penuh dengan baris perintah hasil salin-tempel yang melakukan persis itu. Meski begitu, ada dua hal yang layak mendapat perhatian Anda.

Performa bukan masalah, sampai ia menjadi masalah

Periksa akselerasi hardware dengan grep -m1 -o aes /proc/cpuinfo dan ukur dengan cryptsetup benchmark. Pada CPU mana pun dengan AES-NI — yaitu setiap node yang kami jalankan — AES-XTS memproses beberapa gigabyte per detik per core, jauh di atas apa yang bisa diberikan satu virtual disk, sehingga biaya yang terlihat hanyalah beberapa persen CPU di bawah I/O berat dan sedikit peningkatan latency. Tanpa AES-NI, gambarannya berbalik dan enkripsi menjadi bottleneck; itulah satu-satunya kasus di mana cipher alternatif menjadi keputusan yang sungguhan, bukan sekadar cargo cult.

Memori Argon2id adalah yang menggigit

Argon2id sengaja dibuat rakus memori, dan cryptsetup mengkalibrasinya pada saat format terhadap RAM mesin tempat Anda melakukan format. Format sebuah volume pada workstation 32 GB, pindahkan ke VPS 1 GB, dan proses unlock bisa gagal total karena memori yang dibutuhkan key derivation-nya tidak tersedia di sana — lebih parah lagi di dalam initramfs, di mana memori yang tersedia jauh lebih sedikit dibanding pada sistem yang sedang berjalan. Pada instance kecil, patok nilainya: cryptsetup luksFormat --type luks2 --pbkdf argon2id --pbkdf-memory 262144 /dev/vdb membatasinya pada 256 MB. Nilai yang lebih rendah adalah pengurangan nyata terhadap ketahanan atas offline brute force, jadi kompensasikan dengan passphrase yang lebih panjang.

Satu flag opsional layak mendapat keputusan sadar alih-alih salin-tempel: --allow-discards meneruskan TRIM ke device di bawahnya, yang bagus untuk keausan SSD dan performa steady-state, dan yang juga mengungkapkan seberapa banyak volume yang sedang dipakai dan kira-kira di mana. Ini nonaktif secara default. Aktifkan dengan mengetahui apa yang dibocorkannya.

Swap, log, snapshot — bagian yang sering dilupakan orang

Vault terenkripsi dengan plaintext yang bocor di sekelilingnya adalah kegagalan paling umum dari semuanya, dan ia tetap tidak terlihat sampai seseorang memeriksanya.

• Swap. Apa pun di memori bisa di-page ke disk, termasuk materi yang sudah Anda simpan dengan hati-hati di vault. Nonaktifkan swap, atau beri ia kunci acak pada setiap boot dengan baris /etc/crypttab seperti swap /dev/vdb1 /dev/urandom swap,cipher=aes-xts-plain64,size=256.
• Segala sesuatu yang menulis ke tempat yang tidak Anda periksa. /var/log, /tmp, direktori data database, /var/lib/docker, riwayat shell, journal systemd. Mengenkripsi /srv/vault sementara PostgreSQL menulis ke /var/lib/postgresql tidak mencapai apa-apa sama sekali. Daftar semuanya dulu sebelum Anda mengenkripsi.
• Snapshot. Snapshot level-blok dari volume terenkripsi adalah ciphertext dan karena itu aman. Snapshot yang menangkap state memori adalah objek yang sama sekali berbeda dan bisa berisi kuncinya. Ketahui jenis mana yang diambil oleh panel provider Anda sebelum Anda memakainya.
• Backup. Tujuannya adalah tempat yang salah untuk menyelesaikan ini. Tool seperti restic dan BorgBackup mengenkripsi di sumbernya dengan kunci yang tidak pernah dilihat oleh tujuannya, itulah sebabnya backup server bisa berupa mesin biasa di yurisdiksi lain, alih-alih mesin yang harus dipercaya.
• Plaintext yang sudah Anda kirim ke suatu tempat. Enkripsi saat disimpan tidak berlaku surut. Apa pun yang sudah disalin, dikirim lewat email, atau disinkronkan ke tempat lain berada di luar batas yang baru saja Anda gambar.

Di mana kunci itu berada adalah keseluruhan desainnya

Setiap susunan di atas sebenarnya adalah sebuah pernyataan tentang custody kunci. Ada empat opsi dan mereka tidak setara:

• Di kepala Anda, diketik setiap boot. Perlindungan maksimum, friksi operasional maksimum. Mesin itu benar-benar tidak bisa dibaca tanpa Anda.
• Dalam sebuah file di mesin yang terenkripsi. Melindungi dari penjualan kembali disk yang naif dan tidak lebih dari itu. Jika file itu berada di /boot yang plaintext, ia tidak melindungi apa pun sama sekali — kesalahan paling umum dalam enkripsi self-hosted.
• Pada mesin yang Anda kendalikan, diambil lewat jaringan. Clevis yang terikat ke server Tang: clevis luks bind -d /dev/vdb tang '{"url":"https://tang.example.net"}'. Server boot tanpa pengawasan selama ia bisa menjangkau rumah dan menolak untuk unlock di tempat lain mana pun. Sangat baik untuk armada headless, dan ini menjadikan host Tang sebagai hal yang harus dipertahankan.
• Dalam sebuah TPM. Bermakna pada hardware yang Anda miliki sendiri. Pada VPS, virtual TPM-nya disediakan oleh hypervisor yang sama yang sedang Anda coba kecualikan, jadi ia menyelesaikan kenyamanan, bukan kepercayaan.

Satu pengujian menyelesaikan sebagian besar desain: jika mesin bisa mencapai login prompt tanpa Anda, kuncinya ada di mesin itu. Itu bisa jadi trade-off yang sepenuhnya masuk akal — banyak beban kerja lebih menginginkan reboot tanpa pengawasan dibanding ketahanan terhadap penyerang yang gigih. Buatlah pilihan itu secara sadar, dan jangan menggambarkan hasilnya sebagai sesuatu yang bukan itu.

Apa yang bisa dilihat host Anda, dan di mana yurisdiksi mengambil alih

Pada VPS, sebuah hypervisor berada di bawah Anda. Kami tidak membaca memori guest, dan kami tidak menyimpan log traffic, koneksi, atau DNS serta tidak ada jejak konsol — tapi itu semua adalah kebijakan, dan kerangka yang jujur adalah bahwa VPS meminta Anda untuk mempercayainya. Pada bare metal tidak ada hypervisor antara Anda dan silikonnya: enkripsi disk penuh yang disiapkan saat instalasi dengan passphrase yang tidak pernah kami terima adalah sifat fisik dari mesinnya, bukan jaminan dari kami. Perbedaan itu, bukan pilihan cipher, adalah yang sebenarnya sedang Anda pilih di antaranya.

Itulah sebabnya enkripsi dan yurisdiksi adalah dua bagian dari satu jawaban. Enkripsi menentukan berapa nilai salinan disk Anda; yurisdiksi menentukan siapa yang bisa memaksa mesinnya untuk dihadirkan, lewat proses apa dan seberapa cepat. Kami beroperasi di tujuh yurisdiksi — Islandia, Swiss, Panama, Rumania, Moldova, Belanda, dan Rusia — dan pertimbangan untuk memilih di antara mereka ada di panduan yurisdiksi kami, atau dalam bentuk yang lebih ringkas lewat jurisdiction selector dan halaman lokasi.

Bagian yang tidak bisa disentuh oleh enkripsi adalah pengungkapan paksa, karena itu ditujukan kepada Anda, bukan kepada hardware-nya. Inggris, Prancis, dan Australia termasuk di antara negara yang hukumnya bisa mewajibkan seseorang untuk menyerahkan kunci dekripsi atau menghadapi hukuman karena menolak. Eksposur itu mengikuti di mana Anda berada, bukan di mana servernya berada, dan tidak ada konfigurasi apa pun pada mesin yang mengubahnya. Mendaftar tanpa dokumen identitas membatasi seberapa banyak jejak kertas yang ada sejak awal — alasan praktis dan tidak glamor mengapa hosting tanpa KYC dan enkripsi berakhir dalam percakapan yang sama — tapi itu bukan pertahanan terhadap pengadilan yang sudah mengetahui nama Anda.

Sembilan kesalahan yang mengubah enkripsi menjadi dekorasi

• Auto-unlock dari file kunci pada disk yang sama. Mayoritas server yang "terenkripsi", setara dengan meninggalkan kunci di dalam gemboknya.
• Mengenkripsi volume yang tidak pernah dijangkau oleh data sensitifnya. Vault-nya kosong dan database-nya tidak ada di dalamnya.
• Tidak pernah membackup header LUKS. Satu sektor rusak di awal container dan setiap byte di belakangnya hilang untuk selamanya.
• Tidak pernah menguji jalur unlock. Lalu upgrade kernel meregenerasi initramfs dan reboot berikutnya berubah menjadi operasi penyelamatan.
• Melakukan format pada mesin besar dan unlock pada mesin kecil. Argon2id meminta memori yang tidak bisa disediakan VPS-nya, dan volume itu tidak akan terbuka.
• Memilih passphrase seperti kata sandi login. Tidak ada yang membatasi laju serangan offline kecuali key derivation function-nya. Panjang adalah yang membeli waktu.
• Bermigrasi dari plaintext ke enkripsi dan menganggap yang asli sudah hilang. Pada storage yang divirtualisasi, penimpaan data tidak menghapus secara andal.
• Mengirim passphrase lewat kanal yang sama dengan yang dipakai untuk mengelola mesin. Server OpSec membahas masalah korelasi yang ditimbulkannya.
• Mencampuradukkan enkripsi provider Anda dengan enkripsi Anda sendiri. "Seluruh infrastruktur terenkripsi saat disimpan" — termasuk milik kami — melindungi infrastrukturnya. Hanya kunci yang Anda pegang sendiri yang melindungi Anda dari infrastruktur itu.

Jadi, apakah ini layak dilakukan pada VPS?

Ya, dengan ekspektasi yang terkalibrasi. Untuk satu jam kerja dan tanpa biaya operasional yang terukur, sebuah volume data terenkripsi menghilangkan seluruh kelas eksposur yang tidak bisa Anda atasi dengan cara lain, dan menghilangkannya secara permanen: hardware yang dipensiunkan, storage yang diterbitkan ulang, mesin mati dalam penguasaan orang lain. Lakukan itu pada setiap server yang menyimpan apa pun yang penting, tepat setelah checklist hardening jam pertama.

Yang tidak dilakukannya adalah mengubah komputer sewaan menjadi komputer Anda sendiri. Jika model ancaman Anda menempatkan host itu sendiri sebagai penyerang, tidak ada cipher yang bisa memperbaikinya — jawabannya adalah hardware dedicated di mana kunci diketik lewat IPMI dan tidak pernah melewati hypervisor, yurisdiksi yang dipilih dengan sengaja, dan disiplin untuk tidak menaruh di server apa pun yang tidak perlu berada di sana. Menyesuaikan kontrol dengan ancaman yang sebenarnya adalah perbedaan antara privasi dan sekadar tampilan privasi.