タイ中央銀行のAPIペイロード暗号化規則
目次
長年、「転送中データの暗号化」は一つのことを意味しました。HTTPSをつけること。TLSはロードバランサーで終端し、ペイロードは内部ネットワークを平文で流れ、皆それを暗号化と呼びました。 タイ中央銀行はその隙間を着実に閉じており、方向性は明確です。機密性の高い金融データに対して、伝送暗号化だけではもう足りないのです。
伝送暗号化とペイロード暗号化の違い #
TLSは回線上の二点間のデータを守ります。アプリケーション内のデータは守りません。TLSがリバースプロキシやAPIゲートウェイ、ロードバランサーで終端する瞬間、ペイロードは復号され平文でバックエンドに渡されます。
その平文は、望まない場所を通り、留まります:
- ログ: 念入りすぎるゲートウェイがrequest bodyを記録し、完全なPANと口座番号を残します。
- サービスメッシュと内部ホップ: マイクロサービス間のeast-westトラフィックは「ネットワークは信頼できる」との想定で暗号化されないことが多い。
- メモリとキャッシュ: メモリ上のリクエストオブジェクト、デバッグダンプ、APMトレースが復号済みペイロードを保持しうる。
- オブザーバビリティ基盤: チームやサードパーティへspanを転送するmetricsやtraceが内容ごと運ぶ。
アプリケーション層ペイロード暗号化はメッセージそのものを暗号化してこの隙間を塞ぎます。いくつのホップを越えようと、インフラがどう扱おうと、保護が続きます。
標準は何を使えと言っているか #
ペイロード暗号化の仕組みは標準化され、よく理解されています:
- JSON Web Encryption(JWE)(RFC 7516): 構造化APIペイロード暗号化の事実上の標準。対称データ鍵を非対称受取人鍵で包みます。
- AES-256-GCM: ペイロード本体のauthenticated encryption主力。機密性と完全性の両方を提供します。
- RSA-OAEPまたはECDH: 対称鍵を転送中・保存中に保護する鍵カプセル化層。
パターンはTLS自身が使うものと同じです。大量データに高速な対称暗号、非対称鍵交換で包む。違いはメッセージレベルに適用されるため、TLSセッションの外でも生き延びることです。
BOTが今この件を推す理由 #
規制当局の論理は奇抜ではありません。金融APIは今やタイ決済エコシステム全体の結合組織です。銀行、PSP、フィンテック、加盟店。ゲートウェイの一つの設定ミスで、ログアクセス権のある誰もが口座データに触れてよいはずがありません。ペイロード暗号化は多層防御の施策です。伝送路はいずれ必ず検査・記録・侵害されると仮定し、その瞬間に機密データが読めないことを保証します。
これは保存されたカードホルダーデータ保護というPCI DSS要件の背後にある原則と同じです。どれか単一のホップを信頼するのをやめた瞬間、「ネットワークが安全」を唯一の統制として扱うのをやめることになります。
エンジニアリングチームへの実務的含意 #
ペイロード暗号化の採用は設定トグルではありません。以下を意味します:
- 鍵管理が一等の関心事になります。ローテーション、署名鍵と暗号化鍵の分離、保護された鍵保管が必要です。
- ゲートウェイとロギングの変更: request bodyを読んだり記録したりするものはすべて再評価が必要です。ミドルウェアがもう本文を読めないからです。
- 契約変更: 下流の消費者が復号できなければなりません。チェーンの各当事者間での鍵配布と版管理を意味します。
- テスト: オブザーバビリティは「ペイロードを吐き出せ」から「認証・認可してから必要箇所のみ復号」へ移行する必要があります。
BOTの管轄圏で運営するなら、どれも選択肢ではありません。「管を暗号化する」から「メッセージを守る」への転換です。
当社の規制コンプライアンスはBOTガイダンスを具体的なエンジニアリング要件へマッピングし、 API & アプリケーションセキュリティレビューはペイロードがエンドツーエンドで実際どう保護されているかを検証します。