SSL dan Enkripsi at Rest: Melindungi Data Saat Berjalan dan Saat Tersimpan

Dalam hidup sepotong data, cuma ada dua momen ketika seorang penyerang bisa menyambarnya: ketika data sedang bergerak dari satu mesin ke mesin lain, dan ketika data sedang diam tersimpan di disk. Enkripsi adalah cara kamu melindungi kedua momen itu — dan yang bikin gemas, mengamankan salah satunya sama sekali tidak membantu yang lain. Server dengan setelan HTTPS yang sempurna tetap bisa membocorkan semuanya kalau ada yang mengangkut harddisk-nya pergi. Disk yang terenkripsi penuh juga percuma kalau password menyeberangi jaringan dalam bentuk teks polos.

Artikel ini menyatukan dua sisi itu. Kita akan bahas enkripsi in transit (sisi SSL/TLS, bagian yang kebanyakan orang sudah setengah paham) dan enkripsi at rest (sisi disk dan database, bagian yang sering dilupakan), dan kita akan jujur soal apa yang sebenarnya dilindungi masing-masing — karena di situlah sebagian besar kesalahan beneran bersembunyi.

Dua keadaan data

Bayangkan satu potong data sensitif mana pun — password seorang pelanggan, nomor kartu kredit, pesan pribadi. Sepanjang hidupnya, dia menghabiskan waktu dalam dua kondisi berbeda:

In transit — data sedang bergerak melintasi jaringan: dari browser ke server, dari satu server ke server lain, antara server dan database-nya. Selama dia ada di “kabel”, siapa pun yang bisa melihat lalu lintas jaringan bisa membacanya kalau tidak dienkripsi.
At rest — data tersimpan di suatu tempat dan tidak bergerak: tertulis ke harddisk, tersimpan dalam berkas database, nganggur di arsip backup. Selama dia diam, siapa pun yang dapat akses ke penyimpanan itu bisa membacanya kalau tidak dienkripsi.

(Ada keadaan ketiga yang kadang disinggung orang — in use, yaitu data yang sedang dimuat di memori program yang berjalan — tapi melindunginya adalah topik khusus tingkat lanjut. Buat hampir semua orang, “in transit” dan “at rest” adalah dua hal yang wajib kamu tangani.)

Inti seluruh artikel ini sederhana: ini dua masalah terpisah dengan dua solusi terpisah, dan kamu butuh keduanya. Mengenkripsi transit tidak mengenkripsi disk-mu. Mengenkripsi disk tidak mengenkripsi jaringan. Lewatkan salah satunya, dan kamu meninggalkan satu pintu menganga.

        ┌─────────────┐        in transit         ┌─────────────┐
        │   Browser   │ ───── (TLS / HTTPS) ─────► │   Server    │
        └─────────────┘  terenkripsi di "kabel"    └──────┬──────┘
                                                          │
                                                  at rest  │ (enkripsi
                                                          ▼   disk / DB)
                                                  ┌─────────────────┐
                                                  │  Data tersimpan │
                                                  │  terenkripsi di │
                                                  │  dalam disk     │
                                                  └─────────────────┘

Enkripsi in transit: SSL/TLS

Mari mulai dari sisi yang mungkin sudah pernah kamu jumpai. Setiap kali kamu melihat https:// dan gembok di address bar, data antara browser-mu dan server itu dienkripsi in transit memakai TLS — Transport Layer Security. Kamu juga akan mendengarnya disebut SSL karena kebiasaan; SSL adalah protokol lama yang digantikan TLS, dan namanya kadung melekat walau SSL asli sudah lama mati dan tidak aman. Saat orang sekarang bilang “sertifikat SSL”, hampir selalu yang dimaksud adalah sertifikat TLS.

Apa yang diberikan TLS, dalam bahasa lugas:

Kerahasiaan — siapa pun yang mengintip jaringan (Wi-Fi kafe, penyedia internet, penyerang di jaringan yang sama) cuma melihat byte acak, bukan isi sebenarnya.
Integritas — data tidak bisa diam-diam diubah di tengah jalan tanpa perubahannya ketahuan.
Otentikasi — sertifikatnya membuktikan kamu memang berbicara dengan server yang kamu kira, bukan penyamar di tengah.

Ini model berpikir kuncinya: TLS melindungi data hanya selama dia berjalan di antara dua titik ujung. Begitu data tiba di server dan didekripsi, tugas TLS selesai — dia tidak peduli apa yang terjadi pada data setelah itu. Justru karena itulah enkripsi transit saja tidak cukup.

TLS melindungi pipanya, bukan isinya di kedua ujung

Salah paham yang umum: “kita pakai HTTPS, jadi data kita terenkripsi.” HTTPS mengenkripsi data selama dia melintasi jaringan. Begitu sebuah permintaan tiba di server-mu, dia didekripsi supaya aplikasimu benar-benar bisa membacanya — dan kalau aplikasimu lalu menulis data itu ke disk yang tidak terenkripsi atau mencatatnya di log dalam teks polos, perlindungannya hilang. TLS mengamankan perjalanannya. Mengamankan tujuannya adalah pekerjaan terpisah.

Kalau kamu mau mekanika lengkap soal cara kerja handshake dan sertifikat itu sebenarnya apa, itu dibahas sendiri. Artikel ini menganggap kamu sudah menangkap idenya dan fokus pada bagaimana dia masuk ke gambaran enkripsi yang lebih besar. (Lihat SSL, TLS, dan HTTPS untuk detail protokolnya, dan sertifikat SSL dalam praktik untuk cara benar-benar mendapatkan dan memasangnya.)

Enkripsi transit bukan cuma soal website publik

Orang ingat memasang HTTPS di pintu depan — website publik. Yang mereka lupa adalah koneksi internal. Data juga berjalan in transit ketika:

application server-mu berbicara dengan database-nya di mesin lain,
satu microservice memanggil microservice lain,
server menarik data dari message queue atau cache,
kamu mem-backup data lewat jaringan ke penyimpanan jarak jauh.

Tiap-tiap lompatan itu adalah koneksi jaringan, dan tiap-tiapnya bisa diintip kalau tidak dienkripsi. Setelan yang serius mengenkripsi lalu lintas internal juga, bukan cuma tepi yang menghadap publik. “Kan cuma di jaringan privat kita” adalah pembelaan yang lemah — jaringan internal pun bisa ditembus, dan begitu penyerang ada di dalam, lalu lintas internal yang polos jadi hidangan prasmanan.

Enkripsi at rest: melindungi disk

Sekarang sisi yang sering dilupakan. Enkripsi at rest berarti data yang tersimpan di disk dalam keadaan terenkripsi, sehingga kalau ada yang menguasai drive fisiknya — atau image disk yang dicuri, atau berkas backup — yang mereka dapat cuma omong kosong acak, bukan informasi pelangganmu.

Kenapa ini penting kalau server-nya terkunci rapat di data center? Karena “mendapatkan data” tidak harus dengan menjebol gedungnya:

Drive yang rusak dikirim balik ke pabrikan atau dibuang — dengan datamu masih terbaca di dalamnya.
Penyedia cloud menonaktifkan hardware, dan sebuah disk tidak dihapus dengan sempurna.
Penyerang menyalin image disk atau snapshot sebuah virtual machine.
Berkas backup nyasar ke bucket penyimpanan yang salah setel dan bisa dibaca publik.
Seseorang dengan akses terbatas ke satu bagian sistem membaca berkas database mentah yang seharusnya tidak boleh dia sentuh.

Dalam tiap kasus itu, enkripsi transit sama sekali tidak berbuat apa-apa — datanya sedang at rest. Enkripsi at rest adalah lapisan yang mengubah “kita kehilangan harddisk penuh data pelanggan” menjadi “kita kehilangan harddisk penuh ciphertext yang tidak berguna.”

Ada beberapa tingkat umum tempat kamu bisa menerapkannya, dan ketiganya tidak saling meniadakan:

Full-disk encryption (FDE) — seluruh disk dienkripsi. Apa pun yang ditulis ke sana otomatis dienkripsi; apa pun yang dibaca didekripsi seketika, secara transparan, selama sistemnya dalam keadaan terbuka. Ini melindungi dari disk fisik yang dicuri atau dibuang sembarangan. Dia tidak melindungi server yang sedang berjalan dan sudah terbuka dari penyerang yang sudah dapat akses — saat itu disk-nya sudah dalam keadaan terdekripsi dan bisa dibaca.
Enkripsi tingkat filesystem atau volume — sebuah volume atau partisi tertentu yang dienkripsi, bukan seluruh disk. Ide yang sama, cakupan lebih sempit.
Enkripsi tingkat database / aplikasi — kolom tertentu atau seluruh database dienkripsi oleh mesin database atau aplikasinya sendiri, sering disebut Transparent Data Encryption (TDE) di dunia database. Ini bisa melindungi kolom sensitif bahkan dari orang yang bisa membaca berkas mentahnya, dan membuatmu bisa mengenkripsi hanya yang benar-benar perlu.

  KASAR                                                    HALUS
  ───────────────────────────────────────────────────────────►
  Full-disk         Volume / filesystem        Database / per-kolom
  encryption        encryption                 encryption
  (seluruh drive)   (satu partisi)             (data tertentu)
  melindungi dari   melindungi dari            melindungi bahkan dari
  disk yang dicuri  partisi yang dicuri        pembaca berkas mentah

Full-disk encryption paling menolong disk yang sedang mati

Bagian ini sering bikin keliru. Full-disk encryption luar biasa untuk laptop yang dicuri, atau drive yang lepas dari kendalimu — karena disk-nya terkunci saat dimatikan. Tapi pada server yang menyala 24 jam dan sudah dalam keadaan terbuka, datanya sedang nganggur dalam kondisi terdekripsi selama pemakaian normal. FDE melindungi keadaan mati dan tercabut, bukan mesin hidup yang sudah berhasil ditembus penyerang. Itu bukan alasan untuk melewatkannya — itu alasan untuk paham bahwa dia menutup satu ancaman spesifik, dan untuk menumpuk enkripsi tingkat database di atasnya buat data sensitif.

Hal yang menentukan hidup-matinya enkripsi: kunci

Ini bagian yang menentukan apakah semua di atas jadi perlindungan beneran atau cuma sandiwara: enkripsi cuma sekuat cara kamu mengelola kuncinya. Mengenkripsi data berarti mengacaknya memakai sebuah kunci rahasia. Siapa pun yang punya kuncinya bisa mengembalikannya. Jadi keamanan datamu diam-diam berubah menjadi keamanan kuncimu.

Ini mengarah ke beberapa gol bunuh diri yang sayangnya sering terjadi:

Menyimpan kunci enkripsi di tempat yang sama dengan data terenkripsinya — seperti menempelkan kunci di gemboknya. Kalau penyerang mencuri disk beserta kunci yang nempel di sebelahnya, enkripsinya tidak menghasilkan apa-apa.
Menanam kunci langsung di kode sumber yang akhirnya masuk ke repositori Git.
Memakai passphrase lemah dan gampang ditebak untuk melindungi kunci yang kuat.
Tidak pernah merotasi kunci, sehingga satu kunci yang bocor mengompromikan data bertahun-tahun.

Melakukannya dengan benar berarti menjaga kunci terpisah dari data yang dilindunginya, membatasi siapa dan apa yang boleh mengaksesnya, serta punya rencana untuk merotasinya (menggantinya). Setelan yang lebih besar memakai pengelolaan kunci khusus — sebuah hardware security module (HSM) atau layanan kunci terkelola — yang seluruh tugasnya adalah menjaga kunci dan memberi kemampuan mengenkripsi atau mendekripsi tanpa pernah membuka kunci mentahnya. Konsepnya juga berlaku di skala kecil: paling tidak, kunci ke data terenkripsimu jangan pernah berada di sebelah data itu, dan jangan pernah ada di dalam kodemu.

Enkripsi at rest dengan kunci nempel di sebelahnya nyaris bukan enkripsi

Kalau kunci yang dibutuhkan untuk mendekripsi database-mu tinggal di server yang sama, dalam berkas polos yang dibaca aplikasi, maka penyerang yang masuk ke server itu mendapat kotak terkunci sekaligus kuncinya. Kamu memang menaikkan sedikit ambangnya, tapi belum benar-benar melindungi data at rest dari kompromi penuh. Perlindungan at rest yang nyata berarti kuncinya dijaga terpisah — oleh layanan pengelolaan kunci, sebuah HSM, atau minimal kontrol akses yang cukup ketat sehingga mendapatkan datanya tidak otomatis berarti mendapatkan kuncinya.

Contoh nyata: satu potong data, dua perlindungan

Mari ikuti satu proses reset password untuk melihat kedua lapisan bekerja.

Seorang pengguna, Jane Doe, mengetik password barunya di sebuah form lalu menekan kirim.
In transit (TLS): password itu berjalan dari browser-nya ke server ACY Partner Indonesia lewat HTTPS. Di perjalanan, dia terenkripsi — Wi-Fi kafe yang dia pakai cuma melihat ciphertext.
Server menerima permintaan itu dan TLS mendekripsinya, karena aplikasinya memang perlu mengolah password tersebut.
Aplikasinya tidak menyimpan password apa adanya — dia mem-hash-nya (transformasi satu arah, beda dari enkripsi) sebelum disimpan. Itu praktik terbaik tersendiri, tapi perlu dicatat: password khususnya sebaiknya di-hash, bukan sekadar dienkripsi.
At rest: hash itu, bersama sisa data Jane, ditulis ke database yang disk-nya terenkripsi. Kalau nanti ada yang mencuri drive atau backup-nya, yang mereka dapat ciphertext.
Ketika sistem perlu data itu lagi, dia didekripsi memakai kunci yang disimpan terpisah dan dikontrol aksesnya — bukan nganggur di berkas sebelah database.

Perhatikan bagaimana enkripsi transit (langkah 2) dan enkripsi at rest (langkah 5) melindungi momen yang benar-benar berbeda. Hilangkan salah satunya, dan ada celah ketika data Jane terbuka.

Hashing vs. enkripsi — selingan singkat tapi penting

Karena keduanya terus-terusan tertukar: enkripsi bisa dibalik, hashing tidak. Enkripsi mengacak data supaya orang yang punya kunci bisa mengembalikannya ke aslinya — kamu pakai ketika kamu masih akan butuh data aslinya (seperti membaca kartu kredit yang tersimpan untuk menagih). Hashing mengubah data jadi sidik jari berpanjang tetap yang tidak bisa dikembalikan — kamu pakai ketika kamu cuma perlu mengecek sebuah nilai, tidak pernah memulihkannya. Password adalah kasus klasiknya: kamu tidak perlu tahu password seorang pengguna, cuma perlu tahu apakah yang dia ketik cocok, jadi kamu simpan hash-nya, bukan salinan terenkripsi. Menukar keduanya — mengenkripsi password padahal seharusnya di-hash — adalah kesalahan yang sering dan serius.

Bagaimana ini menyatu dengan yang lain

Enkripsi adalah satu lapisan dalam sebuah tumpukan, bukan perisai ajaib. Dia berpasangan dengan pekerjaan keamanan lain di server: menjaga software yang menjalankan enkripsi itu tetap ter-patch dan mutakhir (cacat di satu pustaka TLS bisa membatalkan semuanya — lihat menjaga software tetap update), mengunci siapa yang sama sekali boleh menjangkau mesinnya, dan kebiasaan yang lebih luas yang dibahas di dasar hardening server. Enkripsi melindungi data bahkan ketika pertahanan lain jebol — tapi dia bekerja paling baik sebagai bagian dari pendekatan berlapis, bukan sebagai satu-satunya tembok.

Satu tempat yang gampang terlupa untuk enkripsi at rest: backup. Sebuah backup adalah salinan sempurna dan mudah dipindah dari seluruh datamu, dan dia sering tinggal di tempat yang penjagaannya lebih longgar dibanding server produksi. Kalau database-mu terenkripsi tapi backup harianmu ditulis dalam teks polos ke sebuah bucket jauh, kamu sudah mengenkripsi pintu depan tapi menaruh kunci cadangan di bawah keset. Backup berhak atas perlakuan at rest yang sama dengan data hidup — poin yang layak diingat saat kamu membaca soal strategi backup.

Penutup

Ini gambaran utuhnya dalam satu tempat:

Data rawan di dua keadaan: in transit (bergerak melintasi jaringan) dan at rest (tersimpan di disk). Masing-masing butuh enkripsinya sendiri, dan yang satu tidak menutup yang lain.
In transit ditangani oleh TLS (masih santai disebut SSL) — dia mengenkripsi data di “kabel”, memberimu kerahasiaan, integritas, dan otentikasi, tapi cuma selama data ada di antara dua titik ujung.
Jangan lupakan transit internal: koneksi database, panggilan antar-layanan, dan backup lewat jaringan juga perlu dienkripsi, bukan cuma website publik.
At rest ditangani oleh enkripsi full-disk, volume, atau tingkat database — dia melindungi data di drive yang dicuri, snapshot yang bocor, dan backup yang terekspos. Full-disk encryption terutama melindungi disk yang mati atau tercabut, jadi tumpuk enkripsi tingkat database di atasnya buat data sensitif.
Pengelolaan kunci adalah engselnya yang sesungguhnya: jaga kunci terpisah dari data yang dilindunginya, kontrol aksesnya, dan rotasi. Enkripsi dengan kunci nempel di sebelah data nyaris tidak terhitung.
Hashing (satu arah, untuk hal yang cuma perlu kamu cek, seperti password) tidak sama dengan enkripsi (bisa dibalik, untuk hal yang perlu kamu pulihkan). Jangan tukar keduanya.

Benarkan kedua sisinya — enkripsi perjalanannya dan enkripsi tujuannya, dengan kunci yang terjaga aman — dan kamu sudah menutup dua lubang terbesar dan paling sederhana tempat data sensitif bocor. Itulah beda antara disk yang dicuri jadi sebuah bencana, atau sekadar jadi peristiwa yang tidak ada artinya.