Peraturan Penyulitan Muatan API Bank of Thailand

Bertahun-tahun, “sulitkan data dalam transit” bermaksud satu perkara: pasang HTTPS. TLS ditamatkan di load balancer, muatan mengalir melalui rangkaian dalaman dalam teks kosong, dan semua orang menyebutnya sulit. Bank of Thailand telah secara beransur menutup jurang itu, dan arahnya jelas: bagi data kewangan sensitif, penyulitan pengangkutan sahaja sudah tidak mencukupi.

Perbezaan antara penyulitan pengangkutan dan penyulitan muatan #

TLS melindungi data antara dua titik atas wayar. Ia tidak melindungi data di dalam aplikasi. Sebaik sahaja TLS ditamatkan di reverse proxy, gerbang API atau load balancer, muatan itu dinyahsulit dan diserahkan kepada backend dalam teks kosong.

Teks kosong itu kemudian bergerak melalui, dan berehat di, tempat yang anda tidak mahu ia berada:

• Log: gerbang yang terlalu rajin merekod badan permintaan menangkap PAN penuh dan nombor akaun.
• Service mesh dan lompatan dalaman: trafik timur-barat antara mikroservis kerap tidak disulitkan atas anggapan rangkaian “dipercayai”.
• Memori dan cache: objek permintaan dalam memori, longkai debug dan jejak APM semuanya boleh menyimpan muatan yang telah dinyahsulit.
• Saluran paip kebolehlihatan: metrik dan jejak yang meneruskan span merentas pasukan dan pihak ketiga.

Penyulitan muatan pada lapisan aplikasi menutup jurang ini dengan menyulitkan mesej itu sendiri, supaya ia kekal dilindungi tanpa kira berapa banyak lompatan yang dilaluinya atau apa yang infrastruktur lakukan dengannya.

Apa kata standard #

Mekanisme penyulitan muatan telah distandardkan dan difahami dengan baik:

• JSON Web Encryption (JWE) (RFC 7516): standard de facto untuk menyulitkan muatan API berstruktur, membungkus kunci data simetri dengan kunci penerima asimetri.
• AES-256-GCM: enjin penyulitan terautentik bagi badan muatan, menyediakan kerahsiaan dan integriti.
• RSA-OAEP atau ECDH: lapisan enkapsulasi kunci yang melindungi kunci simetri dalam transit dan semasa rehat.

Coraknya sama dengan yang digunakan TLS sendiri: sifir simetri pantas bagi data pukal, dibungkus oleh pertukaran kunci asimetri, tetapi digunakan pada aras mesej supaya ia kekal melebihi sesi TLS.

Mengapa BOT mendesaknya sekarang #

Penaungan pengawal selia ini bukanlah eksotik. API kewangan kini menjadi tisu penghubung seluruh ekosistem pembayaran Thailand: bank, PSP, finTech, pedagang. Satu salah konfigurasi gerbang tidak sepatutnya mendedahkan data akaun kepada sesiapa yang mempunyai akses log. Penyulitan muatan ialah ukuran pertahanan berlapis: ia mengandaikan pengangkutan akan diperiksa, direkod atau dikompromi pada suatu masa, dan memastikan data sensitif tidak boleh dibaca apabila itu berlaku.

Ini sejajar dengan prinsip yang sama di sebalik keperluan PCI DSS untuk melindungi data pemegang kad yang disimpan: sebaik sahaja anda berhenti mempercayai sebarang lompatan tunggal, anda berhenti merawat “rangkaian selamat” sebagai satu-satunya kawalan anda.

Implikasi praktikal untuk pasukan kejuruteraan anda #

Mengambil penyulitan muatan bukanlah satu suis konfigurasi. Ia bermakna:

• Pengurusan kunci menjadi kebimbangan utama. Anda perlukan rotasi, pemisahan antara kunci menandatangan dan kunci menyulit serta storan kunci yang dilindungi.
• Perubahan gerbang dan log: semua yang membaca atau merekod badan permintaan mesti dinilai semula, kerana badan itu tidak lagi boleh dibaca oleh middleware.
• Perubahan kontrak: pengguna hiliran mesti boleh menyahsulit, iaitu pengedaran dan pensijilan versi kunci merentasi setiap pihak dalam rantaian.
• Pengujian: kebolehlihatan mesti beralih daripada “longkok muatan” kepada “autentikasi dan benarkan, kemudian nyahsulit hanya di tempat perlu”.

Tiada satu pun daripada ini bersifat pilihan jika anda beroperasi dalam orbit BOT. Ini adalah anjakan daripada “sulitkan paip” kepada “lindungi mesej”.

Penjajaran Pematuhan Peraturan kami memetakan panduan BOT kepada keperluan kejuruteraan konkrit, dan Semakan Keselamatan API & Aplikasi kami mengesahkan bagaimana muatan anda sebenarnya dilindungi dari hujung ke hujung.