กฎการเข้ารหัส Payload ของ API ตามข้อกำหนดธนาคารแห่งประเทศไทย

หลายปีที่ผ่านมา “เข้ารหัสข้อมูลระหว่างทาง” แปลว่าอย่างเดียว: ใส่ HTTPS TLS สิ้นสุดที่ load balancer แล้ว payload ก็ไหลผ่านเครือข่ายภายในเป็นข้อความล้วน โดยทุกคนเรียกว่ามันเข้ารหัสแล้ว ธนาคารแห่งประเทศไทย กำลังปิดช่องว่างนี้อย่างต่อเนื่อง และทิศทางก็ชัดเจน: สำหรับข้อมูลทางการเงินที่ละเอียดอ่อน การเข้ารหัสเฉพาะระดับ transport ไม่เพียงพออีกต่อไป

ความแตกต่างระหว่างการเข้ารหัส transport กับ payload #

TLS ปกป้องข้อมูล ระหว่างสองจุดบนสายสัญญาณ แต่ไม่ได้ปกป้องข้อมูล ภายในแอปพลิเคชัน ทันทีที่ TLS สิ้นสุดที่ reverse proxy, API gateway หรือ load balancer payload ก็ถูกถอดรหัสแล้วส่งต่อให้ backend เป็นข้อความล้วน

ข้อความล้วนนั้นจึงไหลผ่าน และค้างอยู่ในที่ที่คุณไม่อยากให้มันอยู่:

• Log: gateway ที่ log request body มากเกินไป จะเก็บ PAN เต็มและเลขบัญชีไว้
• Service mesh และ hop ภายใน: การสื่อสาร east-west ระหว่าง microservices มักไม่เข้ารหัส เพราะสันนิษฐานว่าเครือข่าย “เชื่อถือได้”
• Memory และ cache: request object ในหน่วยความจำ, debug dump และ APM trace ล้วนเก็บ payload ที่ถอดรหัสแล้วไว้ได้
• Observability pipeline: metrics และ traces ที่ส่งต่อ span ข้ามทีมและบุคคลที่สาม

การเข้ารหัส payload ระดับแอปพลิเคชันปิดช่องว่างนี้ด้วยการเข้ารหัส ตัวข้อความเอง เพื่อให้ข้อมูลยังคงปลอดภัยไม่ว่าจะผ่านกี่ hop หรือโครงสร้างพื้นฐานจะทำอะไรกับมัน

มาตรฐานกำหนดให้ใช้อะไร #

กลไกการเข้ารหัส payload นั้นเป็นมาตรฐานและเข้าใจกันดี:

• JSON Web Encryption (JWE) (RFC 7516): มาตรฐานโดยพฤตินัยสำหรับการเข้ารหัส payload ของ API แบบมีโครงสร้าง โดยห่อ data key แบบ symmetric ด้วย recipient key แบบ asymmetric
• AES-256-GCM: ตัวเข้ารหัสแบบ authenticated ที่เป็นแรงม้าหลักของ payload ให้ทั้งความลับและความถูกต้องครบถ้วนของข้อมูล
• RSA-OAEP หรือ ECDH: ชั้น key-encapsulation ที่ปกป้อง symmetric key ทั้งระหว่างทางและขณะพัก

รูปแบบนี้คือแบบเดียวกับที่ TLS ใช้เอง: cipher แบบ symmetric ที่เร็วสำหรับข้อมูลจำนวนมาก ห่อด้วยการแลกเปลี่ยน key แบบ asymmetric แต่ใช้ในระดับข้อความ เพื่อให้อยู่รอดเกินกว่า TLS session

ทำไม ธปท. ถึงผลักดันเรื่องนี้ในตอนนี้ #

เหตุผลของหน่วยงานกำกับดูแลไม่ใช่เรื่องแปลกใหม่ ปัจจุบัน API ทางการเงินเป็นเส้นใยเชื่อมต่อ ของระบบนิเวศการชำระเงินไทยทั้งหมด: ธนาคาร, PSP, fintech, ร้านค้า การตั้งค่า gateway ผิดจุดเดียวไม่ควรทำให้ข้อมูลบัญชีหลุดถึงมือใครก็ตามที่เข้าถึง log ได้ การเข้ารหัส payload คือมาตรการ defence-in-depth: มันตั้งสมมติฐานว่า transport จะ ถูกตรวจสอบ ถูก log หรือถูกเจาะ ณ จุดใดจุดหนึ่ง และทำให้แน่ใจว่าข้อมูลละเอียดอ่อนจะอ่านไม่ออกเมื่อถึงเวลานั้น

เรื่องนี้สอดคล้องกับหลักการเดียวกับข้อกำหนดของ PCI DSS ที่ให้ปกป้องข้อมูลผู้ถือบัตรที่จัดเก็บ: ทันทีที่คุณเลิกเชื่อถือ hop ใด hop หนึ่ง คุณก็เลิกใช้ “เครือข่ายปลอดภัย” เป็นมาตรการเดียวของคุณ

ผลกระทบเชิงปฏิบัติต่อทีมวิศวกรรมของคุณ #

การนำการเข้ารหัส payload มาใช้ไม่ใช่แค่เปิด config มันหมายถึง:

• การจัดการ key กลายเป็นเรื่องอันดับต้น ๆ คุณต้องมี rotation การแยกระหว่าง signing key กับ encryption key และที่เก็บ key ที่ปลอดภัย
• การเปลี่ยน gateway และ logging: ทุกอย่างที่อ่านหรือ log request body ต้องถูกประเมินใหม่ เพราะ body ไม่สามารถอ่านได้โดย middleware อีกต่อไป
• การเปลี่ยน contract: ผู้บริโภคปลายทางต้องถอดรหัสได้ ซึ่งหมายถึงการแจกจ่าย key และการกำหนด version ให้ทุกฝ่ายในสายโซ่
• การทดสอบ: observability ต้องย้ายจาก “dump payload” ไปเป็น “authenticate และ authorise ก่อน แล้วค่อยถอดรหัสเฉพาะที่จำเป็น”

สิ่งเหล่านี้ไม่มีข้อใดเป็นตัวเลือกหากคุณอยู่ในวงโคจรของ ธปท. มันคือการเปลี่ยนจาก “เข้ารหัสท่อ” เป็น “ปกป้องข้อความ”

บริการ การปฏิบัติตามกฎระเบียบและกรอบมาตรฐาน ของเราแปลงแนวปฏิบัติ ธปท. เป็นข้อกำหนดเชิงวิศวกรรมที่จับต้องได้ และ การตรวจสอบความมั่นคงปลอดภัยของ API และแอปพลิเคชัน ตรวจสอบว่า payload ของคุณถูกปกป้องจริงตลอดเส้นทางหรือไม่