Enkripsi Sisi Server vs. Sisi Klien: Model Mana yang Harus Kamu Percaya?
Oleh Maxim Novak
Enkripsi sisi server mengenkripsi data di server setelah menerima plaintext, sehingga mengharuskan kamu mempercayai penyedia layanan. Enkripsi sisi klien mengenkripsi data di browsermu sebelum dikirim, sehingga server tidak pernah melihat plaintext. Untuk berbagi rahasia, enkripsi sisi klien lebih aman karena menghilangkan layanan sebagai titik kepercayaan — bahkan server yang sudah disusupi pun tidak bisa membaca datamu.
Artikel ini membandingkan kedua pendekatan: cara kerjanya, apa yang diminta masing-masing untuk kamu percayai, dan di mana letak pertukaran sesungguhnya. Ini bukan pembelaan untuk satu sisi — ini adalah kerangka untuk mengevaluasi model mana yang sesuai dengan model ancamanmu.
Untuk gambaran singkat mengapa enkripsi sisi klien penting, baca artikel kami sebelumnya. Untuk melihat secara detail implementasi spesifik Vaulted, baca deep-dive zero-knowledge kami.
Cara kerja enkripsi sisi server
Dalam model sisi server, layanan menangani enkripsi atas namamu. Alur umumnya:
- Kamu memasukkan rahasia di browser
- Browsermu mengirimkan plaintext ke server melalui TLS
- Server mengenkripsi data menggunakan kunci yang dikelolanya sendiri
- Ciphertext disimpan di database
- Saat penerima meminta rahasia tersebut, server mendekripsinya dan mengembalikan plaintext
Kunci enkripsi tidak pernah meninggalkan server. Kunci itu bisa tersimpan di hardware security module (HSM), cloud key management service (KMS), atau file konfigurasi — tetapi server mengendalikannya sepenuhnya.
Model kepercayaan sisi server
Dengan enkripsi sisi server, kamu mempercayai:
- Operator layanan untuk tidak membaca datamu (mereka memiliki kunci dan plaintext di memori selama proses enkripsi/dekripsi)
- Infrastruktur untuk tidak disusupi (server yang dikompromikan mengekspos kunci sekaligus data)
- Karyawan operator untuk tidak menyalahgunakan akses (siapa pun yang memiliki akses server berpotensi membaca rahasia)
- Yurisdiksi hukum untuk tidak memaksa pengungkapan (operator bisa dipaksa menyerahkan data karena mereka memegang kunci)
- Log dan pemantauan server untuk tidak menangkap plaintext (framework logging bisa secara tidak sengaja merekam data sensitif)
Ini tidak selalu merupakan model yang buruk. Banyak layanan menggunakannya dengan sukses — penyimpanan cloud, penyedia email, dan layanan database semuanya mengandalkan enkripsi sisi server. Pertanyaannya adalah apakah pertukaran ini sesuai dengan kasusmu.
Cara kerja enkripsi sisi klien
Dalam model sisi klien, enkripsi terjadi di browser sebelum data apa pun mencapai server. Alurnya berbeda:
- Kamu memasukkan rahasia di browser
- Browser menghasilkan kunci enkripsi dan mengenkripsi data secara lokal
- Hanya ciphertext yang dikirim ke server
- Kunci enkripsi dikirimkan ke penerima melalui saluran terpisah (biasanya fragment URL)
- Browser penerima mendekripsi ciphertext secara lokal
Server tidak pernah melihat plaintext dan tidak pernah menyimpan kunci enkripsi. Server hanya menyimpan dan mengambil blob terenkripsi — tidak lebih dari itu.
Vaulted menggunakan model ini. Setiap rahasia mendapatkan kunci AES-256-GCM baru. Kunci ditempatkan di fragment URL (#), yang tidak pernah disertakan browser dalam permintaan HTTP sesuai RFC 3986. Server menerima ciphertext dan IV acak 12-byte untuk penyimpanan, tetapi kunci sepenuhnya tetap berada dalam tautan yang dibagikan antara pengirim dan penerima.
Model kepercayaan sisi klien
Dengan enkripsi sisi klien, kamu mempercayai:
- Browser untuk mengimplementasikan kriptografi dengan benar (Web Crypto API mendelegasikan ke mesin kripto native seperti BoringSSL atau NSS)
- Kode aplikasi untuk benar-benar melakukan enkripsi di sisi klien (kamu bisa memverifikasi ini dengan memeriksa permintaan jaringan)
- Saluran pengiriman tautan untuk aman (siapa pun yang memiliki URL lengkap, termasuk fragment, dapat mendekripsi rahasia)
- Perangkat penerima untuk tidak disusupi (setelah dekripsi, malware atau tangkapan layar dapat mengakses plaintext)
Kamu tidak mempercayai server, operator layanan, karyawan mereka, atau yurisdiksi hukum mereka. Server adalah relay penyimpanan untuk data terenkripsi yang tidak bisa dibacanya.
Membandingkan pertukaran
Tidak ada model yang secara universal lebih baik. Masing-masing membuat pertukaran berbeda antara keamanan, kemudahan penggunaan, dan kekayaan fitur.
Properti keamanan
| Properti | Sisi server | Sisi klien |
|---|---|---|
| Eksposur saat server disusupi | Kunci + ciphertext terekspos | Hanya ciphertext terekspos (tidak berguna tanpa kunci) |
| Operator bisa membaca data | Ya (memegang kunci) | Tidak (tidak pernah memiliki kunci) |
| Risiko paksaan hukum | Operator bisa mematuhi (memiliki akses) | Operator tidak bisa mematuhi (tidak memiliki akses) |
| Risiko intersepsi tautan | Tidak berlaku (tidak ada kunci di tautan) | URL lengkap = akses penuh (dimitigasi oleh passphrase) |
| Man-in-the-middle | TLS melindungi transit; server melihat plaintext | TLS melindungi ciphertext; kunci di fragment tidak pernah dikirim |
Properti kemudahan penggunaan
| Properti | Sisi server | Sisi klien |
|---|---|---|
| Beban pengelolaan kunci | Tidak ada untuk pengguna (server yang menangani) | Pengguna harus berbagi tautan dengan aman |
| Pemulihan kata sandi | Mungkin (server menyimpan kunci) | Tidak mungkin (kunci hanya ada di tautan) |
| Pencarian dan pengindeksan | Server bisa mencari plaintext | Tidak mungkin tanpa dekripsi |
| Fleksibilitas berbagi | Server bisa mengenkripsi ulang untuk penerima baru | Membutuhkan tautan baru per penerima |
| Akses offline | Membutuhkan koneksi server untuk mendekripsi | Mungkin jika ciphertext dan kunci di-cache secara lokal |
Pertukaran fitur
| Fitur | Sisi server | Sisi klien |
|---|---|---|
| Audit logging konten | Mungkin | Tidak mungkin (server tidak bisa membaca konten) |
| Kebijakan berbasis konten | Mungkin (DLP, pemindaian kepatuhan) | Tidak mungkin tanpa dekripsi |
| Rotasi kunci | Server bisa mengenkripsi ulang dengan kunci baru | Membutuhkan regenerasi dan berbagi ulang tautan |
| Kontrol akses multi-pihak | Server bisa mengelola kunci per pengguna | Setiap penerima membutuhkan kunci secara langsung |
| Jaminan zero-knowledge | Tidak | Ya |
Kapan enkripsi sisi server bisa diterima
Enkripsi sisi server adalah pilihan yang masuk akal ketika:
- Kamu mempercayai operator layanan dan praktik keamanan mereka
- Kamu membutuhkan fitur yang memerlukan akses data sisi server (pencarian, berbagi, pemindaian kepatuhan)
- Sensitivitas data tidak membenarkan biaya kemudahan penggunaan dari enkripsi sisi klien
- Kamu beroperasi di lingkungan yang diatur di mana sertifikasi kepatuhan operator lebih penting daripada jaminan zero-knowledge
- Kompleksitas pengelolaan kunci perlu ditangani oleh layanan, bukan pengguna
Layanan penyimpanan cloud, email enterprise, dan enkripsi database terkelola semuanya menggunakan model ini secara efektif.
Kapan enkripsi sisi klien diperlukan
Enkripsi sisi klien menjadi diperlukan ketika:
- Kamu tidak bisa atau tidak seharusnya mempercayai operator layanan dengan datamu
- Data cukup sensitif sehingga pelanggaran server tidak boleh mengekspos plaintext
- Kamu membutuhkan jaminan zero-knowledge — bukti matematis bahwa server tidak bisa membaca datamu
- Persyaratan hukum atau kepatuhan menuntut agar operator layanan tidak memiliki akses ke konten
- Kamu ingin perlindungan terhadap ancaman orang dalam di penyedia layanan
Berbagi rahasia adalah salah satu kasus penggunaan terkuat untuk enkripsi sisi klien. Datanya secara inheren sensitif (kata sandi, kunci API, kredensial), berbaginya bersifat sementara (dibatasi tampilan, dibatasi waktu), dan hubungan kepercayaannya minimal (kamu mungkin tidak mengenal atau mempercayai operator layanan).
Cara Vaulted mendekati ini
Vaulted menggunakan enkripsi sisi klien secara eksklusif. Setiap rahasia dienkripsi di browser dengan kunci AES-GCM baru sebelum data apa pun mencapai server. Kunci hanya berjalan di fragment URL, dan perlindungan passphrase opsional menambahkan lapisan kedua melalui derivasi kunci PBKDF2 dan key wrapping AES-KW.
Server menyimpan ciphertext terenkripsi dengan time-to-live dan penghitung tampilan. Server tidak bisa mendekripsi, mencari, atau memeriksa konten. Pelanggaran database secara penuh hanya menghasilkan blob terenkripsi — tidak berguna secara komputasi tanpa kunci yang hanya ada di tautan yang dibagikan.
Untuk detail kriptografi lengkap — pembuatan kunci, penanganan IV, pembungkus passphrase, dan panggilan Web Crypto API yang tepat — baca deep-dive enkripsi zero-knowledge kami.
Membuat pilihanmu
Model enkripsi yang tepat bergantung pada apa yang kamu lindungi dan siapa yang bersedia kamu percayai.
Jika kamu membutuhkan fitur seperti pencarian, pemulihan, atau pengelolaan kunci terpusat, enkripsi sisi server adalah pilihan praktis. Jika kamu membutuhkan jaminan bahwa tidak ada seorang pun — bukan layanan, bukan karyawannya, bukan perintah pengadilan — yang bisa membaca datamu, enkripsi sisi klien adalah satu-satunya model yang menyediakan itu.
Untuk berbagi rahasia, jawabannya jelas: datanya sensitif, interaksinya singkat, dan semakin sedikit pihak yang dapat mengakses plaintext, semakin baik.
Siap berbagi rahasia dengan enkripsi zero-knowledge? Buat rahasia di Vaulted — datamu tidak pernah meninggalkan browsermu dalam keadaan tidak terenkripsi.
Terkait
- Mengapa Enkripsi Sisi Klien Penting — argumen untuk mengenkripsi di browser
- Enkripsi Zero-Knowledge: Cara Vaulted Menjaga Rahasiamu Tetap Privat — deep-dive ke implementasi kriptografi
- Keamanan di Vaulted — ringkasan model keamanan kami