Enkripsi Adalah: Kewajiban di 16 Aturan Indonesia dan Batasnya

Enkripsi adalah proses mengubah data yang bisa dibaca (plaintext) menjadi ciphertext memakai algoritma dan kunci, sehingga hanya pemegang kunci yang dapat membacanya kembali. Dari 16 instrumen Indonesia yang kami baca pada 30 Oktober 2026, hanya Pasal 15 ayat (2) Permenkominfo 20/2016 yang mewajibkannya secara umum, itu pun untuk data pribadi yang disimpan, dan hanya standar teknis SNAP yang menyebut versi TLS dan algoritma. Enkripsi melindungi pipanya, bukan nasabah yang dibujuk mengirim uang lewat pipa itu: 11 host konsumen bank yang kami uji semuanya menolak TLS 1.0 dan 1.1, sementara IASC menerima 702.342 laporan penipuan.

Enkripsi data adalah satu jaminan, bukan lima

Enkripsi data hanya menjamin kerahasiaan. AI Overview Google untuk "enkripsi adalah", yang kami ambil dari Indonesia pada 30 Oktober 2026, ikut menuliskan integritas dan autentikasi sebagai manfaatnya. Integritas baru benar pada mode AEAD, dan autentikasi datang dari primitif lain. Arsitek dan pemeriksa perlu memisahkan kelimanya, karena tiap teknik menjawab pertanyaan yang berbeda.

Contoh enkripsi di kanal bank: AES-256 untuk basis data (data at rest), TLS 1.3 untuk koneksi aplikasi ke server (data in transit), dan end-to-end encryption di WhatsApp. Yang terakhir berarti pesan penipu juga sampai utuh. Kanal terenkripsi tidak berkata apa pun tentang kejujuran pengirimnya.

Di mana aturan Indonesia menulis enkripsi

Kami menghitung kata "enkripsi", termasuk "terenkripsi" dan "dienkripsi", pada teks PDF setiap instrumen dengan pencarian otomatis (pypdf, spasi dinormalkan). Tanggal adalah tanggal terbit atau diundangkan. Dua angka perlu dibaca dengan catatan. Salinan UU 27/2022 di BPK adalah pindaian OCR, jadi angka nolnya belum dikonfirmasi dengan salinan born-digital. PP 33/2026 kami baca dari transkripsi pihak ketiga oleh Meridian Hukum (SHA-256 berawalan edb207c89259), karena salinan dari penerbitnya belum kami temukan. Jadi kami memarafrasekannya, dan rumusannya perlu dicek ulang ke salinan resmi sebelum dikutip.

Satu kewajiban tegas, dan batasnya

"Data Pribadi yang disimpan dalam Sistem Elektronik harus dalam bentuk data terenkripsi." (Permenkominfo 20/2016, Pasal 15 ayat 2)

Kalimat ini hanya mengenai data at rest. Algoritma dan panjang kunci tidak disebut. JDIH Komdigi masih menandainya berlaku, dan Pasal 36 ayat (1) memberi sanksi administratif.

PP 33/2026 membuatnya lebih rumit. Peraturan ini diundangkan 16 Juli 2026, dan Pasal 225 memberlakukannya enam bulan kemudian. Hitungan kami jatuh pada 16 Januari 2027, jadi saat tulisan ini terbit ia belum berlaku. Pasal 123 ayat (2) huruf a mendaftar pseudonimisasi, enkripsi Data Pribadi, dan/atau langkah teknis lain, sehingga di sana enkripsi adalah pilihan, bukan kewajiban yang berdiri sendiri. Begitu berlaku, Pasal 224 mempertahankan aturan lama sepanjang tidak bertentangan. Apakah "dan/atau" itu melunakkan "harus" dalam Permen? Kami tidak menemukan jawabannya. Saran kami: jangan hapus kontrol enkripsi hanya karena membaca bahwa ia kini opsional.

UU PDP tidak menyebut enkripsi

Satu halaman di sepuluh besar untuk kueri ini, saat kami cek 30 Oktober 2026, menulis enkripsi sebagai metode penting untuk memenuhi standar keamanan yang diwajibkan UU PDP. Kata itu sendiri tidak ada di undang-undangnya: Pasal 35 meminta "langkah teknis operasional", Pasal 39 ayat (2) meminta sistem keamanan, dan penjelasan keduanya hanya "Cukup jelas".

Akibatnya, UU PDP juga tidak punya pengecualian untuk data terenkripsi pada pemberitahuan 3 x 24 jam di Pasal 46. GDPR Pasal 34 ayat (3) huruf a punya pengecualian semacam itu untuk pemberitahuan kepada subjek data. Bacaan kami: ciphertext yang dicuri bisa saja tetap memicu pemberitahuan, karena Penjelasan Pasal 46 ayat (1) mencakup akses tidak sah atas data yang "dikirim, disimpan, atau diproses". Kami belum menemukan putusannya, jadi tanyakan ke penasihat hukum sebelum menulisnya di playbook insiden.

Kontrol OJK ada di lampiran, dan contohnya SSL

Untuk bank umum, kewajiban yang bisa diaudit ada di Lampiran I SEOJK 29: "metode pengendalian kriptografi" (2.3.d, hlm. 38), enkripsi untuk nirkabel, perangkat mobile dan media penyimpanan ekstern (2.f butir 7, hlm. 64), serta autentikasi "melalui saluran terenkripsi" (2.g butir 11, hlm. 67). Versi TLS, algoritma dan panjang kunci tidak ada.

PADK 1/2026, yang berlaku sejak 1 Maret 2026, memberi contoh standar jaringan "misalnya penggunaan Secure Socket Layer (SSL)" (hlm. 48). IETF sudah menyatakan "SSLv3 MUST NOT be used" di RFC 7568 pada Juni 2015. Kami membaca "SSL" di sini sebagai istilah longgar untuk TLS, bukan perintah memakai protokol lama. Tetap saja, kebijakan internal bank sebaiknya menyebut versi TLS, karena teks OJK tidak melakukannya. Non-bank mendapat lebih sedikit lagi: satu-satunya kata itu di SEOJK 22/2021 adalah "menyimpan password secara aman (terenkripsi)" (hlm. 24).

Perban BSSN 8/2020 tidak diam sepenuhnya. Butir 1.4 lampirannya (hlm. 26) memuat jawaban "[C] Tidak ada penggunaan teknik kriptografi" pada kuesioner kategorisasi. Itu pilihan skor, bukan kontrol. Pasal 9 mewajibkan SNI ISO/IEC 27001 secara tegas hanya untuk Sistem Elektronik strategis. Kategori tinggi boleh menerapkan 27001 dan/atau standar lain yang ditetapkan BSSN, dan kategori rendah 27001 atau standar lain itu. Annex A ISO/IEC 27001:2022 memuat kontrol kriptografi, jadi bagi sistem yang memang menerapkan 27001, rujukan praktisnya ada di Statement of Applicability sertifikat ISO 27001.

SNAP: tenggat TLS 1.2 sudah lewat

Standar Teknis dan Keamanan SNAP v1.0.2 (September 2024) mengikat lewat Pasal 14 ayat (1) PADG 23/15/PADG/2021, yang mewajibkan Open API Pembayaran berbasis SNAP. Butir 2.1.10 (hlm. 28) meminta TLS 1.3. Negosiasi ke TLS 1.2 dengan empat cipher suite DHE/ECDHE-RSA AES-GCM "hanya dapat diterapkan oleh Penyedia Layanan dan Pengguna Layanan sampai dengan tanggal 30 Juni 2026." Butir 2.1.9 (hlm. 27) menyebut SHA256withRSA, HMAC_SHA512 dan AES-256.

Di antara 16 instrumen tadi, inilah satu-satunya baris kripto yang punya tanggal. Menurut kami, itu layak diperlakukan seperti tenggat, bukan catatan kaki. Kami tidak memeriksa apakah tanggal itu diubah oleh amandemen PADG, dan versi yang lebih baru tidak kami temukan di portal. Konteks kepatuhannya ada di pembahasan bukti kepatuhan SNAP.

Pengukuran kami: TLS di host bank, 30 Oktober 2026

Kami menjalankan handshake read-only dengan OpenSSL 3.5.8 dari svr.webarq.com pada 30 Oktober 2026, pukul 15.42 UTC. Sampelnya 11 host konsumen dan 13 host API. api.bni.co.id dan apidev.bni.co.id tidak menjawab, jadi tidak ada data untuk API BNI. api.btn.co.id tidak resolve dan tidak dihitung.

Tiga host API hanya melayani TLS 1.3: api.klikbca.com, api.bankmandiri.co.id dan api.danamon.co.id. Delapan lainnya, termasuk dua host sandbox, masih menerima TLS 1.2 empat bulan setelah tanggal SNAP. Host ini tidak terbukti sebagai endpoint SNAP, jadi kami tidak menyebut satu pun tidak patuh.

Static RSA diterima oleh ib.bri.co.id, bni.co.id dan cimbniaga.co.id di sisi konsumen, serta partner.api.bri.co.id, sandbox.partner.api.bri.co.id, api.cimbniaga.co.id dan api.ocbc.id di sisi API. Suite ini tidak memberi forward secrecy: kalau kunci privat server bocor, trafik lama yang direkam bisa dibuka. Hasil ini datang dari satu titik ukur pada satu hari, dan host bisa berperilaku lain untuk klien lain. Daftar API-nya berbeda dari survei 15 host kami pada 2 September, jadi jangan bandingkan totalnya.

Tiga cara gagal, dan yang ketiga bukan soal kriptografi

1. Kriptonya lemah. Algoritma atau protokol usang, seperti SSLv3. Tabel TLS di atas mengukur lapisan ini.
2. Kuncinya dicuri. Lewat akses admin, phishing pegawai atau pengelolaan kunci yang buruk. Enkripsi hanya memindahkan pertanyaan ke siapa yang memegang kunci: CDN yang mendekripsi TLS di edge, penyedia cloud, atau malware di ponsel, yang berjalan di ujung tempat data sudah didekripsi.
3. Kriptonya bekerja sempurna, dan nasabah sah sendiri yang mengirim uangnya. Regulator Inggris menyebutnya authorised push payment fraud: tidak ada sistem yang diretas, perintah transfernya sah, dan koneksinya tetap terenkripsi sampai uang keluar.

Tidak satu pun halaman "enkripsi adalah" yang kami baca membahas kasus ketiga, begitu juga AI Overview-nya. Sejak 22 November 2024 sampai 30 September 2026, IASC menerima 702.342 laporan, memblokir 702.833 rekening dan Rp811,1 miliar, dan mengembalikan Rp207,16 miliar dari rekening di 24 bank. Angka itu mencakup semua penipuan transaksi, bukan phishing saja, dan siaran persnya tidak memberi total kerugian. Seluruh 11 host konsumen kami menolak TLS 1.0 dan 1.1. Kalau pemeriksa bertanya soal penipuan dan bank menjawab "semuanya sudah terenkripsi", jawaban itu benar untuk pertanyaan yang salah.

Kontrol yang relevan ada di baris lain. SEOJK 29 Lampiran I.c butir 2.g mengatur OTP "untuk transaksi yang berisiko tinggi" (butir 4), IP reputation (butir 5) dan MFA "untuk akses data sensitif" (butir 7). SNAP punya bagian fraud detection system (hlm. 30-31), yang bukan enkripsi. Bahkan faktor kedua SNAP, "SMS TOTP dengan 6 digit- numerik dengan durasi 5 menit" (butir 2.1.8), bisa diserahkan nasabah kepada penipu. Di sisi umpan, artikel phishing kami menjelaskan mengapa gembok HTTPS hanya membuktikan koneksi. Setelah uang hilang, kejadiannya masuk ke sandi 303 dan 305 POJK 12/2024.

Yang perlu diputuskan CTO, CISO dan kepatuhan

• Tulis profil kripto sendiri. Di luar SNAP, regulator tidak menetapkannya. Sebutkan versi TLS minimum, cipher suite, algoritma at rest, panjang kunci dan pemilik rotasi kunci.
• Petakan host API ke SNAP. Tandai mana endpoint SNAP, lalu buktikan TLS 1.2 sudah ditutup atau alasan pengecualiannya tertulis.
• Buat inventaris pemegang plaintext. Catat setiap titik dekripsi, termasuk CDN, WAF dan penyedia cloud.
• Pisahkan anggaran. Kontrol kripto menjawab kasus 1 dan 2. Kasus 3 butuh friksi transaksi, deteksi dan kontrol kanal.
• Siapkan dua skenario Pasal 46. Satu jika ciphertext tanpa kunci yang dicuri, satu jika kuncinya ikut bocor.

Pengungkapan: tidak satu pun dari 13 studi kasus dan 201 entri portofolio WEBARQ yang dipublikasikan mencatat pekerjaan enkripsi, TLS atau manajemen kunci. Jadi perlakukan artikel ini sebagai bacaan aturan dan hasil ukur kami, bukan sebagai rekam jejak proyek. Kunci keputusan di atas sebelum proyek pengembangan aplikasi mobile atau pengembangan cloud-native application dimulai, bukan sesudahnya.