↓Aller au contenu principal
Pure Security
  1. Analyses de Sécurité & Avis Techniques/

Directives de la Banque de Thaïlande sur le Chiffrement de Payload d'API

·4 min de lecture
Insights Data Protection Penetration Testing Compliance & Regulatory
Table des matières

Pendant des années, « chiffrer les données en transit » se résumait à activer HTTPS. Le protocole TLS se terminait sur le répartiteur de charge, la charge utile (payload) circulait en texte clair sur le réseau interne, et tout le monde considérait le flux sécurisé. La Banque de Thaïlande (BOT) comble progressivement cette lacune, et la direction est claire : pour les flux financiers sensibles, le chiffrement au niveau du transport ne suffit plus.

La différence entre chiffrement de transport et de charge utile #

TLS protège les données entre deux points d’une liaison réseau. Il ne protège pas les données au cœur de l’application. Dès que le flux TLS est terminé sur le proxy inverse, l’API Gateway ou le répartiteur de charge, le corps de la requête est déchiffré en clair.

Ce texte en clair circule ensuite dans, et réside dans, des composants où vous préféreriez qu’il ne soit pas :

  • Fichiers de logs : Des passerelles enregistrant l’intégralité des corps de requête capturent des numéros de carte et identifiants bancaires.
  • Service Mesh et flux internes : Le trafic est-ouest entre microservices est souvent non chiffré sous prétexte de circuler dans un réseau « de confiance ».
  • Mémoire et caches : Les traces APM et dumps de débogage conservent les données en clair.
  • Pipelines d’observabilité : Les outils de traçage partagent ces informations entre équipes et plateformes tierces.

Le chiffrement applicatif de la charge utile referme cette brèche en chiffrant le message lui-même, garantissant sa confidentialité quel que soit le nombre d’intermédiaires traversés ou ce que l’infrastructure en fait.

flowchart LR A[Client] -->|TLS| B[API Gateway: Terminaison TLS] B -->|Texte clair| C[Service Backend] C -->|Texte clair| D[Logs / Traces / Cache] subgraph "Chiffrement applicatif de payload" E[Payload chiffré] -.->|JWE / AES-GCM| B B -.-> E2[Chiffré au repos & en transit] end style D stroke:#F43F5E,stroke-width:2px style E2 stroke:#10B981,stroke-width:2px

Les standards préconisés #

Les mécaniques du chiffrement de payload sont normalisées et bien comprises :

  • JSON Web Encryption (JWE) (RFC 7516) : Le standard de référence pour le chiffrement structuré des requêtes d’API.
  • AES-256-GCM : Chiffrement symétrique authentifié assurant confidentialité et intégrité des données.
  • RSA-OAEP ou ECDH : Encapsulation asymétrique assurant la distribution sécurisée de la clé de chiffrement.

Le schéma est le même que celui utilisé par TLS lui-même : un chiffrement symétrique rapide pour les données en volume, enveloppé dans un échange de clés asymétrique, mais appliqué au niveau du message pour survivre au-delà de la session TLS.

Pourquoi la BOT impose cette règle #

Le raisonnement du régulateur n’a rien d’exotique. Les APIs financières constituent aujourd’hui le tissu conjonctif de tout l’écosystème de paiement thaïlandais : banques, PSPs, fintechs, commerçants. Une mauvaise configuration sur une passerelle ne doit jamais exposer des données bancaires à quiconque accède aux logs. Le chiffrement de payload applique le principe de défense en profondeur : il part du principe que le transport sera inspecté, journalisé ou compromis à un moment donné, et garantit que les données sensibles restent illisibles quand cela arrive.

Cela rejoint le même principe que l’exigence du PCI DSS de protéger les données de porteurs stockées : dès lors que vous cessez de faire confiance à n’importe quel saut pris isolément, vous cessez de traiter « le réseau est sûr » comme votre unique contrôle.

Impacts pour vos équipes d’ingénierie #

Adopter le chiffrement de payload ne se résume pas à activer une option de configuration. Cela signifie :

  • Gestion des clés (KMS/HSM) : Rotation automatisée, séparation stricte des clés de signature et de chiffrement, et stockage protégé des clés.
  • Supervision et observabilité : Tout ce qui lit ou journalise les corps de requête doit être réévalué, car le corps n’est plus lisible par les middlewares.
  • Contrats d’interfaces : Les consommateurs aval doivent pouvoir déchiffrer, ce qui suppose une distribution et un versionnage des clés entre chaque partie de la chaîne.
  • Tests : L’observabilité doit évoluer de « déverser la payload » vers « authentifier et autoriser, puis déchiffrer uniquement là où c’est nécessaire ».

Rien de tout cela n’est optionnel si vous opérez dans l’orbite de la BOT. C’est un passage de « chiffrer le tuyau » à « protéger le message ».

Vous souhaitez valider la conformité de vos APIs avec les exigences de la Banque de Thaïlande ? Contactez-nous par e-mail (hello@puresecurity.com) ou sur LINE (@PureSecurity).

Notre Évaluation de Sécurité des APIs & Applications valide la protection de vos flux de bout en bout, et notre service de Conformité Réglementaire vous accompagne auprès des auditeurs de la BOT.