Mengenkripsi Email: Kenapa “Sudah Pakai TLS” Belum Menjawab, dan Pilihan yang Realistis untuk Kantor

Ketika kami menanyakan bagaimana sebuah organisasi mengirim data sensitif, jawaban yang paling sering muncul berbunyi: “lewat email kantor, sudah terenkripsi kok.”

Pernyataan itu biasanya benar, tetapi tidak menjawab pertanyaan yang sedang diajukan. Ada dua hal berbeda yang sama-sama disebut enkripsi email, dan keduanya melindungi dari ancaman yang berbeda pula.

Dua hal yang sama-sama disebut enkripsi

TLS itu penting dan sudah jadi standar — hampir semua layanan surel bisnis memakainya secara bawaan. Yang perlu diluruskan hanyalah cakupannya. Ia melindungi pesan di jalan, bukan di tempat tujuan.

Kapan TLS saja sudah cukup

Sebagian besar surel harian tidak perlu lebih dari itu. Menambahkan enkripsi ujung ke ujung ke semua pesan hanya akan membuat orang mencari jalan memutar, dan jalan memutar itu biasanya lebih tidak aman daripada keadaan semula.

Yang perlu perlakuan lebih adalah isi yang konsekuensinya berat bila terbaca pihak lain:

• Data pribadi pelanggan atau pasien — identitas, rekam medis, data rekening.
• Dokumen keuangan dan kontrak yang belum diumumkan.
• Kredensial dan konfigurasi sistem. Idealnya tidak dikirim lewat surel sama sekali.
• Berkas kepegawaian — data gaji, hasil penilaian, dokumen kedisiplinan.

Daftar itu juga menjelaskan kenapa persoalan ini berpindah dari ranah teknis ke ranah kepatuhan.

Kaitannya dengan UU PDP

Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi berlaku penuh sejak 17 Oktober 2024, setelah masa transisi dua tahun. Sejak itu, kewajiban yang sebelumnya terasa sebagai anjuran menjadi mengikat — termasuk kewajiban memberitahukan kebocoran data dalam waktu 3x24 jam, dan sanksi administratif yang dihitung dari pendapatan tahunan.

Yang berubah bagi pekerjaan sehari-hari: cara Anda mengirim data pribadi kini termasuk hal yang bisa ditanyakan dan diperiksa. Mengirim berkas berisi data ratusan nasabah sebagai lampiran biasa ke alamat pribadi seseorang bukan lagi sekadar kebiasaan yang kurang rapi.

Tiga cara mengenkripsi, dan mana yang realistis

Untuk organisasi menengah di Indonesia, baris pertama hampir selalu jadi jawaban yang bertahan. Alasannya bukan karena paling canggih, melainkan karena tidak menuntut apa pun dari penerima — dan penerima adalah pihak yang paling tidak bisa Anda kendalikan.

S/MIME masuk akal ketika pertukarannya berulang dengan mitra yang sama, misalnya antara bank dan penyedia sistem intinya. PGP layak dipertimbangkan hanya bila kedua sisi memang terbiasa memakainya; memaksakannya ke pengguna umum hampir selalu berakhir dengan pesan yang dikirim tanpa enkripsi karena “kuncinya bermasalah”.

Menerapkannya tanpa membuat orang mencari jalan memutar

1. 01

   Tentukan dulu apa yang wajib dienkripsi

   Satu halaman berisi jenis data dan perlakuannya. Tanpa batas yang jelas, hasilnya salah satu dari dua ekstrem: semua dienkripsi sampai orang menyerah, atau tidak ada yang dienkripsi karena tidak ada yang merasa wajib.

2. 02

   Nyalakan mekanisme yang sudah ada di langganan Anda

   Sebagian besar paket surel bisnis sudah menyertakan kemampuan mengirim pesan terenkripsi lewat portal. Memakai yang sudah dibayar lebih cepat daripada mengadakan yang baru.

3. 03

   Beri satu cara memicunya yang mudah diingat

   Tombol di aplikasi surel, atau kata kunci tertentu di baris subjek. Kalau caranya harus dicari dulu, ia tidak akan dipakai saat orang sedang terburu-buru — dan justru saat itulah kesalahan terjadi.

4. 04

   Latih dengan contoh, bukan dengan kebijakan

   Tunjukkan tiga contoh nyata dari pekerjaan mereka sendiri. Sesi lima belas menit dengan contoh konkret lebih melekat daripada dokumen kebijakan yang dibagikan lewat surel.

5. 05

   Periksa ulang setelah sebulan

   Lihat apakah benar-benar dipakai. Bila tidak, penyebabnya hampir selalu prosedurnya terlalu berat — bukan orangnya tidak peduli.

Kesalahan yang paling sering terjadi

1. Mengirim kata sandi di surel yang sama dengan lampirannya. Ini meniadakan seluruh manfaatnya. Kata sandi harus lewat jalur lain — pesan singkat atau telepon.
2. Memakai kata sandi yang sama untuk semua pengiriman. Sekali bocor, seluruh riwayat kiriman ikut terbuka.
3. Mengira melindungi lampiran dengan kata sandi sama dengan mengenkripsi. Sebagian format lama mudah dibuka paksa; gunakan format arsip dengan enkripsi yang layak, atau mekanisme dari platform surel Anda.
4. Menyalakan enkripsi untuk semua pesan tanpa kecuali. Berujung pada orang yang berpindah ke aplikasi pesan pribadi supaya pekerjaannya selesai — dan data itu jadi berada di luar kendali organisasi sama sekali.

Yang tidak diselesaikan enkripsi email

Agar tidak menimbulkan rasa aman yang keliru, tiga hal berikut tetap berada di luar jangkauannya:

• Akun yang diambil alih. Bila penyerang masuk sebagai penggunanya, ia membaca pesan sebagaimana pemiliknya membaca. Yang menutup jalur ini adalah autentikasi dua faktor.
• Penerima yang meneruskan pesannya. Enkripsi mengatur siapa yang bisa membuka, bukan apa yang dilakukan setelah dibuka.
• Penipuan yang menyamar sebagai atasan. Pesan palsu yang meminta transfer tidak dihalangi enkripsi. Penangkalnya verifikasi lewat jalur berbeda, seperti dibahas di cybersecurity 101.

Penutup

Enkripsi email bukan satu sakelar yang perlu dinyalakan untuk seluruh organisasi. Ia keputusan per jenis data: sebagian besar surel cukup dengan TLS yang memang sudah berjalan, dan sebagian kecil yang isinya berat perlu perlindungan yang bertahan sampai di kotak surat penerima.

Kalau ingin memulai dengan satu langkah: periksa apakah paket surel yang sudah Anda bayar hari ini menyertakan pengiriman pesan terenkripsi. Pada banyak organisasi kemampuan itu sudah ada dan belum pernah dinyalakan — dan menyalakannya makan waktu jauh lebih sedikit daripada rapat memilih solusi baru.