Aturan Enkripsi Payload API Bank of Thailand

Selama bertahun-tahun, “enkripsi data saat transit” berarti satu hal: pasang HTTPS. TLS berakhir di load balancer, payload mengalir melintasi jaringan internal dalam plaintext, dan semua orang menyebutnya terenkripsi. Bank of Thailand secara bertahap menutup celah itu, dan arahnya jelas: untuk data finansial sensitif, enkripsi transport saja tidak lagi cukup.

Perbedaan enkripsi transport dan enkripsi payload #

TLS melindungi data antara dua titik pada kabel. Ia tidak melindungi data di dalam aplikasi. Begitu TLS berakhir di reverse proxy, API gateway, atau load balancer, payload didekripsi dan diserahkan ke backend dalam bentuk teks polos.

Plaintext itu kemudian melintas, dan menetap, di tempat-tempat yang tidak Anda inginkan:

• Log: gateway yang terlalu rajin mencatat request body merekam PAN penuh dan nomor rekening.
• Service mesh dan hop internal: trafik east-west antar microservices sering kali tanpa enkripsi dengan asumsi jaringan “dipercaya”.
• Memori dan cache: objek request in-memory, debug dump, dan trace APM semuanya bisa menyimpan payload hasil dekripsi.
• Pipeline observability: metrics dan trace yang meneruskan span lintas tim dan pihak ketiga.

Enkripsi payload lapisan aplikasi menutup celah ini dengan mengenkripsi pesan itu sendiri, sehingga tetap terlindungi berapa pun banyaknya hop yang dilalui atau apa yang infrastruktur lakukan terhadapnya.

Apa yang direkomendasikan standar #

Mekanika enkripsi payload sudah distandardkan dan dipahami dengan baik:

• JSON Web Encryption (JWE) (RFC 7516): standar de facto untuk mengenkripsi payload API terstruktur, membungkus kunci data simetris dengan kunci penerima asimetris.
• AES-256-GCM: andalan authenticated encryption untuk badan payload, menyediakan kerahasiaan sekaligus integritas.
• RSA-OAEP atau ECDH: lapisan key encapsulation yang melindungi kunci simetris saat transit maupun tersimpan.

Pola ini sama seperti yang dipakai TLS sendiri: cipher simetris cepat untuk data massal, dibungkus pertukaran kunci asimetris, tetapi diterapkan pada level pesan sehingga bertahan melebihi sesi TLS.

Mengapa BOT mendorong ini sekarang #

Penalaran regulatornya tidak eksotis. API finansial kini menjadi jaringan penghubung seluruh ekosistem pembayaran Thailand: bank, PSP, fintech, merchant. Satu kesalahan konfigurasi gateway tidak seharusnya membuka data rekening bagi siapa pun yang punya akses log. Enkripsi payload adalah langkah defense in depth: ia berasumsi transport akan diperiksa, dicatat, atau dikompromikan suatu saat, dan memastikan data sensitif tak terbaca saat itu terjadi.

Ini selaras dengan prinsip yang sama di balik kewajiban PCI DSS melindungi data pemegang kartu tersimpan: begitu Anda berhenti mempercayai hop mana pun, Anda berhenti menjadikan “jaringannya aman” sebagai satu-satunya kontrol.

Implikasi praktis bagi tim engineering Anda #

Mengadopsi enkripsi payload bukan sekadar mengubah satu konfigurasi. Artinya:

• Key management menjadi perhatian utama. Anda butuh rotasi, pemisahan kunci penandatanganan dan kunci enkripsi, serta penyimpanan kunci yang terlindungi.
• Perubahan gateway dan logging: semua yang membaca atau mencatat request body harus dievaluasi ulang, karena middleware tak lagi bisa membacanya.
• Perubahan kontrak: konsumen hilir harus bisa mendekripsi, artinya distribusi dan versioning kunci lintas setiap pihak dalam rantai.
• Pengujian: observability harus bergeser dari “dump payload” ke “autentikasi dan otorisasi dulu, dekripsi hanya bila perlu.”

Tak satu pun dari ini bersifat opsional jika Anda beroperasi dalam orbit BOT. Ini pergeseran dari “enkripsi pipanya” ke “lindungi pesannya”.

Layanan Regulatory Compliance kami memetakan panduan BOT menjadi persyaratan engineering konkret, dan API & Application Security Review kami memverifikasi bagaimana payload Anda benar-benar dilindungi secara end to end.