Laktawan ang pangunahing nilalaman
  1. Mga Security Insight & Advisory/

Bank of Thailand API Payload Encryption Rules

Sa loob ng maraming taon, ang “encrypt data in transit” ay nangangahulugan lang ng isang bagay: lagyan ng HTTPS. Nagtatapos ang TLS sa load balancer, dumadaloy ang payload sa internal network na plaintext, at tinawag itong encrypted ng lahat. Patuloy na isinasara ng Bank of Thailand ang gap na iyan, at malinaw ang direksyon: para sa sensitibong financial data, hindi na sapat ang transport encryption mag-isa.

Ang pagkakaiba ng transport at payload encryption #

Pinoprotektahan ng TLS ang data sa pagitan ng dalawang punto sa kable. Hindi nito pinoprotektahan ang data sa loob ng application. Sa sandaling natapos ang TLS sa reverse proxy, API gateway o load balancer, dine-decrypt ang payload at inihahatid sa backend bilang plaintext.

Ang plaintext na iyon pagkatapos ay dumadaan sa, at nakatira sa, mga lugar na ayaw mong naroon siya:

  • Logs: sobrang masipag na gateway na naglo-log ng request bodies ay kumukuha ng buong PANs at account numbers.
  • Service mesh at internal hops: madalas walang encryption ang east-west traffic sa pagitan ng microservices sa palagay na “trusted” ang network.
  • Memorya at caches: in-memory request objects, debug dumps at APM traces ay maaaring mag-retain ng decrypted payload.
  • Observability pipelines: metrics at traces na nagpapadala ng spans sa iba’t ibang teams at third parties.

Ang application-layer payload encryption ay sumasara sa gap na ito sa pamamagitan ng pag-encrypt sa mensahe mismo, kaya nananatili itong protektado anuman ang bilang ng hops na dinaanan o anong ginawa ng infrastructure dito.

flowchart LR A[Client] -->|TLS| B[API Gateway: nagtatapos ang TLS] B -->|plaintext| C[Backend service] C -->|plaintext| D[Logs / traces / cache] subgraph "Application-layer encryption" E[Naka-encrypt na payload] -.->|JWE / AES-GCM| B B -.-> E2[Naka-encrypt pa rin habang naglalakbay] end style D stroke:#F43F5E,stroke-width:2px style E2 stroke:#10B981,stroke-width:2px

Ano ang iniutos gamitin ng standard #

Naka-standardise at malinaw ang mechanics ng payload encryption:

  • JSON Web Encryption (JWE) (RFC 7516): de facto standard para i-encrypt ang structured API payloads, bumabalot ng symmetric data key ng asymmetric recipient key.
  • AES-256-GCM: authenticated encryption workhorse para sa payload body, nagbibigay ng confidentiality at integridad sabay.
  • RSA-OAEP o ECDH: key-encapsulation layer na nagpoprotekta sa symmetric key sa transit at sa storage.

Parehong pattern ang ginagamit ng mismong TLS: mabilis na symmetric cipher para sa bulk data, binalot ng asymmetric key exchange, pero inilalapat sa message level kaya lumalagpas ito sa TLS session.

Bakit itinutulak ito ng BOT ngayon #

Hindi ekzotiko ang reasoning ng regulator. Ang financial APIs ngayon ang connective tissue ng buong Thai payments ecosystem: bangko, PSPs, fintechs, merchants. Hindi dapat isang gateway misconfiguration ang magbukas ng account data kahit kaninong may log access. Defense-in-depth measure ang payload encryption: ina-assume nitong mame-masse-inspect, ma-lo-log o makakompromiso ang transport balang araw, at sinisiguro nitong hindi nababasa ang sensitibong data kapag dumating iyon.

Naka-align ito sa parehong prinsipyo sa likod ng PCI DSS requirement na protektahan ang stored cardholder data: sa sandaling tumigil ka sa pagtitiwala sa kahit isang hop, tumigil ka rin sa pagtrato sa “safe ang network” bilang tanging control mo.

Mga praktikal na implikasyon sa engineering team mo #

Ang pag-ampon ng payload encryption ay hindi config toggle. Nangangahulugan ito ng:

  • Key management bilang first-class concern. Kailangan mo ng rotation, hiwalay na signing at encryption keys, at protected key storage.
  • Pagbabago sa gateway at logging: lahat ng bumabasa o nagla-log ng request bodies ay dapat muling suriin, dahil hindi na nababasa ng middleware ang body.
  • Mga pagbabago sa contract: kayang i-decrypt ng downstream consumers, na nangangahulugang key distribution at versioning sa bawat partido sa chain.
  • Testing: dapat lumipat ang observability mula “i-dump ang payload” tungo sa “mag-authenticate at authorise, tapos mag-decrypt lang kung kinakailangan.”

Walang opsyonal dito kung nasa orbit ka ng BOT. Paglipat ito mula “i-encrypt ang tubo” tungo sa “protektahan ang mensahe.”

Hindi sigurado kung pasado ang API payloads mo sa ekspektasyon ng Bank of Thailand? Mensahe kami para sa diretso at mabilis na pagsusuri. Kontakin ako sa LINE (@PureSecurity) o email (hello@puresecurity.com).

Ang Regulatory Compliance namin ay nagma-map ng BOT guidance sa konkretong engineering requirements, at ang API & Application Security Review namin ay bine-verify kung paano talaga pinoprotektahan ang payloads mo end to end.