กฎหมายคุ้มครองข้อมูลส่วนบุคคลของไทย (Personal Data Protection Act B.E. 2562 / 2019 หรือ PDPA) กำหนดให้ผู้ประมวลผลข้อมูลส่วนบุคคลต้องมี "มาตรการรักษาความมั่นคงปลอดภัยทางเทคนิคที่เหมาะสม" แต่ไม่ได้ระบุวิธีการเข้ารหัสลับที่เฉพาะเจาะจงไว้ ทั้งนี้ AES-256 เป็นการเข้ารหัสลับแบบสมมาตรที่ได้รับการรับรองโดยรัฐบาลกลางสหรัฐฯ, FIPS 197 และ ISO/IEC 18033-3 ซึ่งถูกนำมาใช้เป็นมาตรฐานพื้นฐานของ "มาตรการที่เหมาะสม" ในทางปฏิบัติอย่างแพร่หลาย บทความนี้จัดทำขึ้นสำหรับฝ่ายไอทีและนักพัฒนาที่ดูแลผลิตภัณฑ์ AI ในบริษัทไทย โดยจะสรุปรูปแบบการนำ AES-256 ไปใช้งานเพื่อให้สอดคล้องกับ PDPA ตั้งแต่การคัดเลือกข้อมูลที่จะเข้ารหัส การจัดการกุญแจ (Key Management) ไปจนถึงการรองรับการตรวจสอบ (Audit) ทั้งนี้ รายการตรวจสอบสำหรับการปฏิบัติตาม PDPA ของไทยในภาพรวม (เช่น การขอความยินยอม, การแต่งตั้ง DPO, การโอนข้อมูลข้ามพรมแดน ฯลฯ) จะถูกกล่าวถึงในบทความอื่น โดยบทความนี้จะเน้นไปที่ชั้นการนำไปใช้งานทางเทคนิคโดยเฉพาะ

ภายใต้ PDPA ของไทย ผู้ควบคุมข้อมูลส่วนบุคคลจำเป็นต้องใช้มาตรการรักษาความมั่นคงปลอดภัยทั้งทางเทคนิคและทางองค์กรที่เหมาะสม เพื่อป้องกันการรั่วไหล การเข้าถึง การใช้ การแก้ไขเปลี่ยนแปลง หรือการเปิดเผยข้อมูลส่วนบุคคลโดยมิชอบ เนื่องจากในตัวบทกฎหมายไม่ได้ระบุอัลกอริทึมการเข้ารหัสลับที่เฉพาะเจาะจงไว้ การนำ AES-256 มาใช้จึงถือเป็นทางเลือกที่เหมาะสมในทางปฏิบัติ

เมื่ออ่านตัวบทของ PDPA จะพบว่ามีถ้อยคำที่เป็นนามธรรมอยู่มาก ทำให้ยากต่อการตัดสินว่า "ต้องดำเนินการอย่างไรจึงจะถือว่าผ่านเกณฑ์" ในส่วนนี้จะขอสรุปข้อกำหนดของ PDPA บทบาทของ AES-256 และการแบ่งหน้าที่กับบทความรายการตรวจสอบการปฏิบัติตาม PDPA ที่มีอยู่เดิม

PDPA มาตรา 37(1) ของไทย กำหนดให้ผู้ควบคุมข้อมูลส่วนบุคคล (Data Controller) มีหน้าที่ "จัดให้มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม ทั้งในด้านเทคนิคและด้านการบริหารจัดการ เพื่อป้องกันการสูญหาย การเข้าถึง การใช้ การเปลี่ยนแปลง หรือการเปิดเผยข้อมูลส่วนบุคคลโดยมิชอบ" โครงสร้างของมาตรานี้มีความใกล้เคียงกับ GDPR มาตรา 32 ของสหภาพยุโรปเป็นอย่างมาก และนับตั้งแต่มีการบังคับใช้เต็มรูปแบบ แนวทางปฏิบัติที่ออกโดยคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) ของไทย ก็ได้ระบุให้การเข้ารหัส (Encryption) การทำข้อมูลนิรนาม (Pseudonymization) และการควบคุมการเข้าถึง (Access Control) เป็น "มาตรการที่คาดหวัง" ไว้ด้วยเช่นกัน

ในกรณีที่มีการฝ่าฝืน อาจนำไปสู่ปัญหาทั้งในด้านบทลงโทษตามกฎหมาย การดำเนินการทางปกครอง และการเยียวยาทางแพ่ง ซึ่งจำเป็นต้องตรวจสอบเพดานค่าปรับสูงสุดและการแบ่งประเภทตามตัวบทกฎหมายฉบับล่าสุดเพื่อความชัดเจน

ระบบ AI มีการประมวลผลข้อมูลส่วนบุคคลในปริมาณมาก โดยเฉพาะข้อมูลส่วนบุคคลอ่อนไหว (เช่น ข้อมูลสุขภาพ ความเชื่อ หรือข้อมูลชีวภาพ) ซึ่งมาตรา 26 กำหนดให้ต้องมีการคุ้มครองเพิ่มเติมอย่างเข้มงวด

ในทางปฏิบัติ "มาตรการรักษาความมั่นคงปลอดภัยทางเทคนิคที่เหมาะสม" หมายถึงสิ่งใดนั้น ขึ้นอยู่กับมาตรฐานอุตสาหกรรม โดยทั่วไปมักอ้างอิงตามมาตรฐานสากล เช่น ISO/IEC 27001, ISO/IEC 29100 หรือการควบคุมตาม NIST SP 800-53 ซึ่ง AES-256 ได้รับการจัดให้เป็นอัลกอริทึมที่แนะนำในมาตรฐานเหล่านี้ทั้งหมด

เหตุผลในการเลือกใช้ AES-256 เป็น "มาตรการที่เหมาะสม" นั้นได้รับการสนับสนุนจากการรับรองของหน่วยงานสาธารณะหลายแห่ง เนื่องจาก AES-256 ได้รับการกำหนดมาตรฐานโดย NIST FIPS 197 และยังถูกระบุให้เป็นอัลกอริทึมที่ใช้สำหรับการป้องกันข้อมูลระดับ Top Secret ใน CNSA Suite ของ NSA จึงทำให้ง่ายต่อการนำไปใช้งานจริง อย่างไรก็ตาม ความสมเหตุสมผลในการตรวจสอบ PDPA จำเป็นต้องอธิบายอย่างครอบคลุม ทั้งในส่วนของแบบจำลองภัยคุกคาม (Threat Model) การจัดการกุญแจ (Key Management) การควบคุมการเข้าถึง (Access Control) และบันทึกการตรวจสอบ (Audit Trail) ทั้งนี้ AES เป็นการเข้ารหัสแบบบล็อกสมมาตรที่ได้รับมาตรฐานโดย NIST FIPS 197 และมีการอ้างอิงอย่างกว้างขวางในมาตรฐานสากล หากมีการระบุชื่อมาตรฐาน ควรตรวจสอบเวอร์ชันและสถานะที่เป็นทางการของมาตรฐานนั้นๆ ให้ถูกต้อง

Cloud KMS และ TLS 1.3 เป็นกลไกที่มีประโยชน์ในการสนับสนุนการดำเนินงานด้านการเข้ารหัสที่เป็นมาตรฐานในปัจจุบัน อย่างไรก็ตาม เนื่องจากชุดรหัส (Cipher Suite) ของ TLS 1.3 และการตั้งค่าเริ่มต้นของ Cloud KMS แต่ละแห่งมีความแตกต่างกันตามบริการนั้นๆ จึงจำเป็นต้องตรวจสอบข้อมูลจำเพาะล่าสุดจากผู้ให้บริการแต่ละรายเมื่อนำมาใช้งาน แม้ว่า PDPC ของไทยจะยังไม่มีแนวปฏิบัติเฉพาะสำหรับ AES-256 ออกมา แต่หากมีความสอดคล้องกับมาตรฐานสากล ก็จะสามารถอธิบายต่อผู้ตรวจสอบว่าเป็น "การตัดสินใจที่สมเหตุสมผล" ได้ง่ายขึ้น

ในทางกลับกัน หากเลือกใช้การเข้ารหัสแบบเก่าที่ไม่ใช่ AES (เช่น DES, 3DES, RC4) หรือการเข้ารหัสที่พัฒนาขึ้นเองภายในองค์กร จะทำให้เกณฑ์ในการพิสูจน์ "ความเหมาะสม" ในการตรวจสอบสูงขึ้นทันที ประโยชน์เชิงปฏิบัติที่สำคัญที่สุดของการเลือก AES-256 คือ "ความจำเป็นในการอธิบายเหตุผลของการเลือกใช้นั้นมีน้อยที่สุด"

การปฏิบัติตาม PDPA จำเป็นต้องดำเนินการควบคู่กันทั้งในด้านเทคนิคและด้านองค์กร ซึ่งหากนำทั้งสองส่วนมารวมไว้ในบทความเดียวจะทำให้เนื้อหาไม่เข้มข้น บทความนี้จึงมุ่งเน้นไปที่เลเยอร์การนำเทคโนโลยีไปใช้งานจริง โดยเฉพาะเรื่องการเข้ารหัส (Encryption) และการจัดการกุญแจ (Key Management) ส่วนประเด็นด้านองค์กรและสัญญาจะถูกแยกไปสรุปในอีกบทความหนึ่ง อย่างไรก็ตาม ขั้นตอนการแจ้งเตือนและการแบ่งความรับผิดชอบจำเป็นต้องได้รับการทบทวนให้สอดคล้องกับการดำเนินงานตาม PDPA ล่าสุดอยู่เสมอ

บทความนี้มุ่งเน้นไปที่เลเยอร์การนำเทคโนโลยีไปใช้งานจริงที่ไม่ได้กล่าวถึงในบทความก่อนหน้า โดยเฉพาะเรื่องการเข้ารหัสและการจัดการกุญแจ บทความทั้งสองฉบับถูกออกแบบมาให้ใช้ควบคู่กัน โดยวางตำแหน่งบทความนี้ไว้สำหรับทีมพัฒนาที่ได้จัดเตรียมโครงสร้างองค์กรตามรายการตรวจสอบ (Checklist) เรียบร้อยแล้ว และเหลือภารกิจในการนำ "มาตรการคุ้มครองทางเทคนิค" ไปปฏิบัติจริง

ขั้นตอนการอ่านที่แนะนำมีดังนี้: ในช่วงเริ่มต้นของโครงการปฏิบัติตาม PDPA ให้ศึกษาบทความรายการตรวจสอบเพื่อเตรียม DPO และร่างสัญญาให้เรียบร้อย จากนั้นเมื่อทีมพัฒนาเข้าสู่ขั้นตอนการนำการเข้ารหัสไปใช้งานจริง ให้กลับมาอ่านบทความนี้ เมื่อการดำเนินการด้านเทคนิคเสร็จสิ้นในระดับหนึ่งแล้ว ให้กลับไปตรวจสอบความต่อเนื่องของการดำเนินงานในระดับองค์กรผ่านบทความรายการตรวจสอบอีกครั้ง ซึ่งการสลับไปมาระหว่างสองบทความนี้ถือเป็นแนวทางปฏิบัติที่เหมาะสมที่สุด

ในระบบ AI ข้อมูลส่วนบุคคลอาจปะปนอยู่ในพรอมต์ (Prompt), การตอบกลับ (Response), บันทึก (Log), เวกเตอร์การฝัง (Embedding Vector) และข้อมูลที่ใช้ในการฝึกฝน (Training Data) จึงจำเป็นต้องออกแบบการจัดเก็บ การเข้าถึง และระยะเวลาการเก็บรักษาแยกตามแต่ละชั้น (Layer) สำหรับความจำเป็นในการเข้ารหัสข้อมูลนั้น ให้พิจารณาโดยคำนึงถึงความสมดุลระหว่างความสามารถในการสืบค้น (Searchability) และข้อกำหนดในการตรวจสอบ (Audit Requirements)

ความเข้าใจผิดที่ว่า "แค่ส่งข้อมูลผ่าน API ไปยัง LLM ภายนอก จึงไม่จำเป็นต้องเข้ารหัสในฐานข้อมูลของบริษัท" ถือเป็นรูปแบบการละเมิด PDPA ที่พบบ่อย ต่อไปนี้จะแบ่ง 4 ชั้นข้อมูลเฉพาะของ AI ออกเป็น 2 หัวข้อหลักตามลักษณะของข้อมูล

ในพรอมต์ (Prompt) ของระบบ AI มักมีข้อมูลส่วนบุคคลที่ผู้ใช้พิมพ์ลงไปโดยไม่รู้ตัว ตัวอย่างเช่น "ฉันชื่อ 〇〇 และผลตรวจสุขภาพเมื่อเดือนที่แล้วบอกว่า △△ ฉันควรตีความข้อมูลนี้อย่างไร" ซึ่งเป็นสิ่งที่เกิดขึ้นเป็นปกติในการใช้งาน AI หากพรอมต์ถูกบันทึกลงในฐานข้อมูล (DB) ในรูปแบบข้อความธรรมดา (Plain text) ฐานข้อมูลนั้นทั้งชุดจะตกอยู่ภายใต้การกำกับดูแลของ PDPA

ในฝั่งของการตอบกลับก็มีโอกาสที่จะแสดงข้อมูลส่วนบุคคลออกมาเช่นกัน ในกรณีที่ใช้ RAG (Retrieval-Augmented Generation) ระบบจะดึงเอกสารภายในองค์กร (เช่น การประเมินผลพนักงาน รายชื่อลูกค้า หรือบันทึกทางการแพทย์) มาเป็นผลลัพธ์ ดังนั้นตัวข้อความที่ตอบกลับมาจึงอาจมีข้อมูลส่วนบุคคลรวมอยู่ด้วย หากมีการเก็บรักษาการตอบกลับนั้นไว้เป็นประวัติการสนทนา สถานที่จัดเก็บดังกล่าวก็จะต้องถูกเข้ารหัสด้วยเช่นกัน

สิ่งที่มักถูกมองข้ามคือไฟล์บันทึกการทำงาน (Log file) ซึ่งบ่อยครั้งมีการบันทึกพรอมต์และคำตอบลงในไฟล์ Log แบบข้อความธรรมดาเพื่อวัตถุประสงค์ในการดีบั๊ก (Debug) และเก็บรักษาไว้นานหลายเดือนหรือหลายปี ไฟล์ Log มักจะ "ขยายขนาดขึ้นเรื่อยๆ โดยไม่รู้ตัว และมีนโยบายการลบที่ไม่ชัดเจน" ซึ่งกลายเป็นช่องทางการรั่วไหลที่พบบ่อยเมื่อเกิดการละเมิด PDPA จึงควรเข้ารหัสไฟล์ Log ตามระดับความละเอียดอ่อนของข้อมูล กำหนดนโยบายระยะเวลาการจัดเก็บ และลบข้อมูลที่ไม่จำเป็นทิ้งอย่างเหมาะสม โดยระยะเวลาการจัดเก็บควรสอดคล้องกับข้อกำหนดทางธุรกิจและภาระหน้าที่ในการเก็บรักษาข้อมูลตามกฎหมาย

เวกเตอร์ที่ถูกฝัง (Embedding vectors) ซึ่งจัดเก็บอยู่ในเวกเตอร์ฐานข้อมูล (เช่น Pinecone, Supabase pgvector, Chroma ฯลฯ) มีความเสี่ยงที่อาจถูกคาดเดาเนื้อหาต้นฉบับได้ ดังนั้นหากข้อมูลดังกล่าวมีข้อมูลที่ละเอียดอ่อน จำเป็นต้องออกแบบวิธีการจัดเก็บอย่างระมัดระวัง โดยควรพิจารณาถึงความสมดุลระหว่างความต้องการในการสืบค้น (Search requirements) ควบคู่ไปกับการใช้การเข้ารหัส (Encryption), การควบคุมการเข้าถึง (Access control) และการจัดการระยะเวลาการจัดเก็บข้อมูลร่วมกัน

ประวัติการสนทนา (Chat history) มีระยะเวลาการจัดเก็บที่แตกต่างกันไปตามแต่ละผลิตภัณฑ์ ตั้งแต่ไม่กี่ชั่วโมงไปจนถึงหลายปี อย่างไรก็ตาม เพื่อให้เป็นไปตามข้อกำหนดด้านระยะเวลาการจัดเก็บข้อมูลของ PDPA (ลบข้อมูลเมื่อบรรลุวัตถุประสงค์แล้ว) จึงจำเป็นต้องมีการออกแบบที่รองรับทั้งการเข้ารหัสและนโยบายการลบข้อมูล โดยรูปแบบมาตรฐานที่นิยมใช้คือการใช้ส่วนขยาย pgcrypto สำหรับ Postgres, InnoDB TDE สำหรับ MySQL หรือตัวเลือกการเชื่อมต่อกับ KMS สำหรับ NoSQL

ข้อมูลสำหรับการเรียนรู้ (คลังข้อมูลสำหรับ Fine-tuning, เอกสารสำหรับ RAG) ถือเป็นส่วนที่มีความเสี่ยงสูงสุด เนื่องจากมักประกอบด้วยข้อมูลทางธุรกิจจำนวนมาก ข้อมูลเหล่านี้ควรได้รับการออกแบบให้ "ถอดรหัสเฉพาะในขณะประมวลผลเท่านั้น" และจัดเก็บในสถานะที่เข้ารหัสไว้ในเวลาปกติ หากมีการถอดรหัสในงานประมวลผล (Learning job) บนคลาวด์ ควรตรวจสอบให้แน่ใจว่าไม่มีข้อมูลตกค้างอยู่ในพื้นที่จัดเก็บชั่วคราว (/tmp) และรวมถึงการตรวจสอบการล้างข้อมูลหลังเสร็จสิ้นกระบวนการ (Cleanup) เข้าไว้ในขอบเขตของการตรวจสอบ (Audit) ด้วย

AES-256 จะไม่ปลอดภัยเพียงแค่การเลือก "ชื่ออัลกอริทึม" เท่านั้น แต่ความลับและความสมบูรณ์ของข้อมูลจะถูกรับประกันได้ก็ต่อเมื่อมีการผสมผสาน 3 องค์ประกอบ ได้แก่ โหมด (Mode), เวกเตอร์เริ่มต้น (Initialization Vector: IV) และแท็กการตรวจสอบความถูกต้อง (Authentication Tag) อย่างถูกต้องเท่านั้น ความผิดพลาดในการเลือกใช้งานระหว่างการติดตั้งจริงอาจส่งผลให้ผลลัพธ์ที่ได้ไม่ต่างจากการใช้ข้อความธรรมดา (Plaintext) แม้ว่าจะใช้ AES-256 แล้วก็ตาม

ในการปฏิบัติงานจริง การเลือกใช้ระหว่าง GCM และ CBC รวมถึงความสอดคล้องระหว่างการส่งข้อมูลและการจัดเก็บข้อมูลเป็นประเด็นที่ถูกตั้งคำถามบ่อยที่สุด โดยจะขอสรุปรายละเอียดของทั้งสองประเด็นในหัวข้อ H3 ต่อไปนี้

AES には複数のブロック暗号モードが定義されているが、新規実装では、原則として GCM のような AEAD モードを採用するのがよい。環境によっては他の AEAD 方式がより適切な場合もあるため、性能要件や既存資産との互換性を踏まえて選定する。GCM は AEAD（Authenticated Encryption with Associated Data）方式であり、暗号化と同時に認証タグを生成する。これにより、暗号文が改ざんされた場合に復号段階で検出できる。

CBC（Cipher Block Chaining）モードは歴史的に広く使われてきたが、認証機能を持たないため、別途 HMAC を付与しない限り改ざんを検出できない。CBC + HMAC の組み合わせを自前実装するより、GCM を使うほうが実装ミスが入り込む余地が少ない。既存レガシーシステムとの互換性が必要な場合を除いて、CBC を新規採用する理由は乏しい。

GCM を使う上での最大の落とし穴は IV（初期化ベクトル、nonce）の再利用だ。同じ鍵と同じ IV で 2 つの平文を暗号化すると、XOR 関係から平文を復元できる致命的な脆弱性が生じる。実装では必ず暗号学的に安全な乱数で IV を生成し、同じ鍵での再利用を避けるカウンター管理や、専用ライブラリ（例: Node.js crypto.createCipheriv、Python cryptography.hazmat）の推奨パターンに従う。

AES มีการกำหนดโหมดการเข้ารหัสแบบบล็อกไว้หลายรูปแบบ แต่สำหรับการใช้งานใหม่ โดยหลักการแล้วควรเลือกใช้โหมด AEAD เช่น GCM ในบางสภาพแวดล้อม วิธีการ AEAD อื่นๆ อาจเหมาะสมกว่า ดังนั้นควรพิจารณาเลือกโดยคำนึงถึงข้อกำหนดด้านประสิทธิภาพและความเข้ากันได้กับระบบเดิมที่มีอยู่ GCM เป็นวิธีการแบบ AEAD (Authenticated Encryption with Associated Data) ซึ่งจะสร้างแท็กการตรวจสอบความถูกต้องไปพร้อมกับการเข้ารหัส ทำให้สามารถตรวจพบได้ในขั้นตอนการถอดรหัสหากข้อความที่เข้ารหัสถูกแก้ไข

โหมด CBC (Cipher Block Chaining) ถูกใช้งานอย่างแพร่หลายในอดีต แต่เนื่องจากไม่มีฟังก์ชันการตรวจสอบความถูกต้อง จึงไม่สามารถตรวจพบการแก้ไขได้หากไม่มีการเพิ่ม HMAC เข้าไปแยกต่างหาก การใช้ GCM มีโอกาสเกิดข้อผิดพลาดในการใช้งานน้อยกว่าการสร้างระบบ CBC + HMAC ขึ้นมาเอง ยกเว้นในกรณีที่จำเป็นต้องรักษาความเข้ากันได้กับระบบเดิม (Legacy System) จึงแทบไม่มีเหตุผลที่จะเลือกใช้ CBC ในการใช้งานใหม่

ข้อควรระวังที่สำคัญที่สุดในการใช้ GCM คือการนำ IV (Initialization Vector, nonce) กลับมาใช้ซ้ำ หากเข้ารหัสข้อความธรรมดา (Plaintext) สองชุดด้วยคีย์เดียวกันและ IV เดียวกัน จะทำให้เกิดช่องโหว่ร้ายแรงที่สามารถกู้คืนข้อความธรรมดาได้จากความสัมพันธ์แบบ XOR ในการใช้งานจริง ต้องสร้าง IV ด้วยตัวเลขสุ่มที่ปลอดภัยทางวิทยาการรหัสลับเสมอ และปฏิบัติตามรูปแบบที่แนะนำ เช่น การจัดการตัวนับ (Counter) เพื่อป้องกันการใช้ซ้ำภายใต้คีย์เดียวกัน หรือใช้ไลบรารีเฉพาะทาง (เช่น Node.js crypto.createCipheriv, Python cryptography.hazmat)

เพื่อให้มั่นใจถึงการเข้ารหัสข้อมูลตลอดทั้งวงจรชีวิต (Data Lifecycle) จำเป็นต้องครอบคลุมทั้งในระหว่างการรับส่ง (In-Transit) และในระหว่างการจัดเก็บ (At-Rest) การเลือกทำเพียงอย่างใดอย่างหนึ่งจะทำให้เกิดช่องโหว่ที่ข้อมูลแบบ Plaintext รั่วไหลได้เสมอ

สำหรับการรับส่งข้อมูล ให้ยึด TLS 1.3 เป็นมาตรฐาน โดยเลือก Cipher Suite ตามนโยบายการตั้งค่าของสภาพแวดล้อมและผู้ให้บริการ แม้ว่า AES-256-GCM จะเป็นตัวเลือกที่น่าสนใจ แต่ไม่ควรยึดติดว่าเป็นค่าเริ่มต้นสำหรับ TLS 1.3 ทั้งหมด ให้กำหนดค่า CDN หรือ Reverse Proxy ให้รองรับเฉพาะ TLS 1.3 + AES-256-GCM เท่านั้น และปิดการใช้งานโปรโตคอลรุ่นเก่า เช่น TLS 1.2 หรือต่ำกว่า รวมถึงอัลกอริทึมอย่าง RC4 และ 3DES

สำหรับการจัดเก็บข้อมูล ให้ใช้ AES-256 ครอบคลุมทั้ง 3 เลเยอร์ ได้แก่ การเข้ารหัสระดับคอลัมน์ในฐานข้อมูล (Postgres pgcrypto, MySQL InnoDB TDE, SQL Server Always Encrypted), การเข้ารหัสระดับไฟล์สตอเรจ (AWS S3 SSE-KMS, Google Cloud Storage CMEK, Azure Storage CMK) และการเข้ารหัสข้อมูลสำรอง (Snapshot ที่เชื่อมต่อกับ KMS)

สิ่งที่มักถูกมองข้ามคือไฟล์บันทึก (Log), ไฟล์ชั่วคราว (Temporary files) และไฟล์ดัมพ์ในสภาพแวดล้อมการพัฒนา (Development environment) ควรมีการตรวจสอบเป็นระยะว่าเมื่อคัดลอกฐานข้อมูลจากระบบจริงไปยังสภาพแวดล้อมการพัฒนา ข้อมูลนั้นถูกจัดเก็บโดยไม่มีการเข้ารหัสหรือไม่ สิ่งที่การตรวจสอบตามมาตรฐาน PDPA ให้ความสำคัญไม่ใช่แค่ "การออกแบบให้มีการเข้ารหัส" แต่คือ "การรักษาการเข้ารหัสไว้ในการปฏิบัติงานจริง" หรือไม่

ความปลอดภัยที่แท้จริงของ AES-256 นั้นขึ้นอยู่กับการจัดการกุญแจ (Key Management) มากกว่าตัวอัลกอริทึมเอง หากวางกุญแจไว้ในรูปแบบข้อความธรรมดา (Plaintext) ในที่เก็บโค้ดหรือไฟล์การตั้งค่า ต่อให้การเข้ารหัสแข็งแกร่งเพียงใดก็ไร้ความหมาย การใช้ KMS, HSM และการแยก Tenant ร่วมกันถือเป็นมาตรฐานพื้นฐานในการปฏิบัติงานยุคใหม่

ในการออกแบบการจัดการกุญแจ มีแกนตัดสินใจที่สำคัญ 3 ประการ ได้แก่ จะใช้บริการใด (KMS / HSM), จะหมุนเวียนกุญแจ (Rotation) อย่างไร และจะแยกส่วนในสภาพแวดล้อมแบบ Multi-tenant อย่างไร

ในสภาพแวดล้อมคลาวด์ การใช้บริการจัดการกุญแจ (Key Management Service: KMS) เช่น AWS KMS, Google Cloud KMS และ Azure Key Vault ถือเป็นมาตรฐานหลักที่ควรเลือกใช้ KMS ช่วยให้สามารถควบคุมการสร้าง การจัดเก็บ และการใช้งานกุญแจผ่าน API ได้ โดยที่แอปพลิเคชันไม่ต้องจัดการกับกุญแจในรูปแบบข้อความธรรมดา (Plaintext) เลย เนื่องจาก KMS มีการนำ "Envelope Encryption" (โครงสร้าง 2 ชั้นที่ใช้ KEK เข้ารหัส DEK) มาใช้ภายใน จึงทำให้สามารถรักษาทั้งประสิทธิภาพและความปลอดภัยไปพร้อมกันได้

HSM เป็นกลไกที่ปกป้องกุญแจไว้ภายในขอบเขตของฮาร์ดแวร์เฉพาะทาง ในการเลือกใช้งานจำเป็นต้องตรวจสอบว่าผลิตภัณฑ์นั้นเป็นไปตามมาตรฐาน FIPS 140-2 หรือ FIPS 140-3 หรือไม่ แม้ว่าในสถาบันการเงิน สถาบันทางการแพทย์ และหน่วยงานรัฐบาล HSM อาจกลายเป็นข้อกำหนดทางกฎหมาย แต่สำหรับ PDPA ของไทยเพียงอย่างเดียวนั้น การใช้ HSM ไม่ใช่ข้อกำหนดบังคับ

สำหรับการตัดสินใจในทางปฏิบัติ ผลิตภัณฑ์ AI ทั่วไปสามารถใช้ KMS ก็เพียงพอแล้ว แต่หากเป็นงานที่เกี่ยวข้องกับข้อมูลส่วนบุคคลที่มีความละเอียดอ่อน (เช่น ข้อมูลสุขภาพ ความเชื่อ ข้อมูลชีวภาพ) หรืออยู่ในอุตสาหกรรมที่มีกฎระเบียบเข้มงวด เช่น การเงินและการแพทย์ ควรพิจารณาใช้ HSM โดยสามารถจัดหา HSM ได้ผ่านบริการอย่าง AWS CloudHSM หรือ Azure Dedicated HSM ซึ่งมีต้นทุนการดำเนินงานสูงกว่า KMS ถึง 1-2 หลัก ดังนั้นจึงควรตัดสินใจโดยพิจารณาจากความต้องการทางธุรกิจเป็นสำคัญ

การหมุนเวียนคีย์ (Key Rotation) เป็นการดำเนินงานที่จำเป็นเพื่อจำกัดความเสียหายในกรณีที่เกิดการรั่วไหลของคีย์ AWS KMS และ Google Cloud KMS มีฟังก์ชันการหมุนเวียนคีย์ซึ่งสามารถเปิดใช้งานได้ตามการออกแบบการดำเนินงาน โดยรอบระยะเวลาการหมุนเวียนจะแตกต่างกันไปตามบริการและประเภทของคีย์ ดังนั้นควรตั้งค่าตามข้อกำหนดล่าสุดของระบบคลาวด์ที่ใช้งาน นอกจากนี้ ควรเตรียมขั้นตอนการหมุนเวียนคีย์ด้วยตนเองในทันทีไว้ด้วย หากเกิดเหตุการณ์ที่สงสัยว่ามีการรั่วไหลเกิดขึ้น

การแยกคีย์ (Key Separation) คือหลักการออกแบบโดยใช้คีย์แยกกันตามวัตถุประสงค์และสภาพแวดล้อม ตัวอย่างเช่น การออกคีย์สำหรับ "การเข้ารหัสคอลัมน์ในฐานข้อมูล" "การเข้ารหัสบันทึก (Log)" และ "การเข้ารหัส API Token" แยกจากกัน รวมถึงการใช้คีย์ที่แตกต่างกันในสภาพแวดล้อมการใช้งานจริง (Production), สภาพแวดล้อมทดสอบ (Staging) และสภาพแวดล้อมการพัฒนา (Development) วิธีนี้จะช่วยจำกัดขอบเขตของผลกระทบหากคีย์ใดคีย์หนึ่งเกิดการรั่วไหล

อีกหนึ่งเทคนิคในทางปฏิบัติคือการจัดลำดับชั้นของคีย์ (Key Hierarchy) โดยการจัดเก็บมาสเตอร์คีย์ (KEK) ไว้ภายใน KMS และให้แอปพลิเคชันดึงข้อมูลคีย์เข้ารหัสข้อมูล (DEK) มาใช้ชั่วคราว หากใช้โครงสร้างที่จัดการ DEK ผ่าน KEK ด้วย API ของ KMS (Encrypt/Decrypt) จะทำให้ DEK ไม่ตกค้างอยู่ในหน่วยความจำนานเกินไป ซึ่งช่วยลดความเสี่ยงในการรั่วไหลแม้จะเกิดเหตุการณ์ Core dump หรือ Memory dump ก็ตาม

ในการออกแบบระบบ Multi-tenant SaaS เพื่อรองรับ PDPA อย่างจริงจัง ขอแนะนำให้ใช้ "การจัดการกุญแจแยกตามผู้เช่า" (Tenant-specific key management) ซึ่งเป็นการกำหนดให้แต่ละผู้เช่ามีกุญแจเข้ารหัสแยกจากกัน เพื่อหลีกเลี่ยงสถานการณ์เลวร้ายที่สุดที่ว่า "หากกุญแจหนึ่งดอกรั่วไหล ข้อมูลของผู้เช่าทั้งหมดจะถูกเปิดเผย"

ใน AWS KMS การออกแบบที่นิยมคือการใช้ Customer Managed Key (CMK) แยกกันสำหรับแต่ละผู้เช่า ทั้งนี้ควรตัดสินใจเลือกระหว่างการใช้กุญแจเดี่ยว (Single key), กุญแจแยกตามสภาพแวดล้อม (Environment-specific key) หรือกุญแจแยกตามผู้เช่า โดยพิจารณาจากต้นทุนและภาระในการดำเนินงาน

ข้อมูลในแต่ละแถวของฐานข้อมูล (DB row) ของผู้เช่าแต่ละราย จะถูกเข้ารหัสด้วย Data Encryption Key (DEK) ซึ่งถูกเข้ารหัสซ้อนอีกชั้นด้วย CMK ของผู้เช่านั้นๆ ทำให้ในกรณีที่โค้ดซึ่งพยายามถอดรหัสข้อมูลของ Tenant A เข้าถึงข้อมูลของ Tenant B โดยผิดพลาด จะไม่สามารถถอดรหัสได้เนื่องจากไม่สามารถเรียกใช้ CMK ที่ถูกต้องได้

สำหรับโครงสร้างพื้นฐานแบบ Multi-tenant ที่ใช้ PostgreSQL การออกแบบที่รวม RLS (Row-Level Security) เข้ากับการเข้ารหัสถือเป็นแนวทางที่มีประสิทธิภาพ หากใช้ Supabase จำเป็นต้องตรวจสอบโมเดลสิทธิ์การเข้าถึงในปัจจุบันและตัวเลือกการเข้ารหัสก่อนเริ่มออกแบบ แม้ต้นทุนในการติดตั้งจะสูงกว่าการใช้เพียง RLS ปกติ แต่จะเป็นหลักฐานสำคัญในการอธิบายถึง "ความเหมาะสมของมาตรการคุ้มครองทางเทคนิค" ตามข้อกำหนดของ PDPA ได้เป็นอย่างดี

ในโครงการที่นำ AES-256 มาใช้งาน ข้อผิดพลาดที่มักถูกตรวจพบระหว่างการตรวจสอบ PDPA มักไม่ได้อยู่ที่การเลือกอัลกอริทึม แต่อยู่ที่ "ช่องโหว่ในการดำเนินงาน" โดยเฉพาะอย่างยิ่ง 3 รูปแบบหลัก ได้แก่ การสำรองข้อมูลแบบ Plaintext, การรั่วไหลผ่าน SaaS ของบุคคลที่สาม และความไม่สมบูรณ์ของบันทึกการตรวจสอบ (Audit Log)

ปัญหาเหล่านี้มักมองไม่เห็นในขั้นตอนการเลือกเทคโนโลยี และมักจะพบหลังจากเริ่มใช้งานจริงแล้ว ในหัวข้อ H3 สองหัวข้อถัดไปนี้ จะสรุปข้อผิดพลาดที่พบบ่อยและประเด็นสำคัญในการรับมือกับการตรวจสอบ

แม้ว่าฐานข้อมูลจริง (Production DB) จะถูกเข้ารหัสด้วย AES-256 แต่ก็มีหลายกรณีที่น่าตกใจซึ่งเส้นทางการสำรองข้อมูลยังคงเป็นข้อความธรรมดา (Plaintext) ไม่ว่าจะเป็นไฟล์ SQL ที่ส่งออกมาจาก pg_dump, ไฟล์ CSV ที่ส่งออกเพื่อเก็บไว้ในเครื่องเป็นรายสัปดาห์ หรือสแนปชอตที่คัดลอกไปยังสภาพแวดล้อมการพัฒนาเพื่อตรวจสอบ QA หาก "ข้อมูลที่แตกแขนง" เหล่านี้ไม่ได้รับการเข้ารหัส การเข้ารหัสในฐานข้อมูลจริงก็จะสูญเสียความหมายไปครึ่งหนึ่ง ควรใช้ฟังก์ชันสแนปชอตที่เชื่อมต่อกับ KMS และต้องตรวจสอบให้แน่ใจว่าไฟล์ดัมพ์ได้รับการเข้ารหัสด้วย AES-256 เสมอ

การรั่วไหลผ่าน SaaS ของบุคคลที่สามก็เป็นจุดบอดทั่วไปเช่นกัน ในหลายกรณี ข้อมูล Prompt หรือการตอบกลับจะถูกส่งไปยังบริการตรวจสอบข้อผิดพลาด (Sentry), APM (Datadog, New Relic) หรือการวิเคราะห์ผลิตภัณฑ์ (Mixpanel, Amplitude) ในรูปแบบข้อความธรรมดา แม้ว่าบริการเหล่านี้จะมีการเข้ารหัสภายในบริษัทเอง แต่ประเด็นสำคัญคือ "ใครเป็นผู้ถือกุญแจ" นอกเหนือจาก SSE (Server-Side Encryption) แล้ว ควรพิจารณา CSE (Client-Side Encryption) และใช้รูปแบบการทำ Masking หรือ Hashing ข้อมูล PII ที่ฝั่งแอปพลิเคชันก่อนส่งออกไปจะมีความปลอดภัยมากกว่า

การสร้างกลไกที่ประมวลผล "การลบ PII ก่อนส่งไปยัง SaaS ภายนอก" โดยใช้ไลบรารีส่วนกลาง และบังคับให้การส่งข้อมูล Telemetry ทั้งหมดต้องผ่านกระบวนการนี้ จะช่วยป้องกันการรั่วไหลได้โดยที่นักพัฒนาไม่จำเป็นต้องคอยระมัดระวังด้วยตนเอง

สิ่งที่การตรวจสอบ PDPA ให้ความสำคัญไม่ใช่เพียงแค่ "มีการเข้ารหัสลับอยู่ในขณะนี้หรือไม่" เท่านั้น แต่ยังรวมถึง "มีการดำเนินการเข้ารหัสลับอย่างต่อเนื่องหรือไม่" ด้วย ซึ่งรากฐานสำคัญสำหรับเรื่องนี้คือบันทึกการตรวจสอบ (Audit Logs) และการทบทวนอย่างสม่ำเสมอ

บันทึกการใช้งาน KMS จะถูกบันทึกไว้ใน AWS CloudTrail หรือ Google Cloud Audit Logs โดยควรตั้งค่าการแจ้งเตือนสำหรับความถี่ในการใช้คีย์ การเข้าถึงในช่วงเวลาที่ผิดปกติ หรือการเรียกใช้งานจาก IAM Role ที่ไม่คุ้นเคย สำหรับผลิตภัณฑ์ AI นั้น ทีมพัฒนาอาจเผลอทำตามรูปแบบที่ไม่ควรทำ (Anti-pattern) เช่น "การส่งคีย์ผ่านตัวแปรสภาพแวดล้อม (Environment Variables) แทนที่จะผ่าน KMS" ได้ง่าย การทบทวนร่องรอยจากบันทึกการใช้งานอย่างสม่ำเสมอจึงช่วยป้องกันปัญหาเหล่านี้ได้ตั้งแต่ต้น

รายการที่ควรทบทวนเป็นประจำทุกปีเป็นอย่างน้อย ได้แก่ 1. การสำรวจข้อมูลที่ต้องเข้ารหัส 2. ประวัติการหมุนเวียนคีย์ (Key Rotation) 3. สถานะการเข้ารหัสลับของเส้นทางการสำรองข้อมูล 4. การอัปเดตนโยบายการเข้ารหัสลับของ SaaS จากภายนอก และ 5. การปฏิบัติตามแนวทางปฏิบัติล่าสุดจาก PDPC นอกจากนี้ ควรจัดเก็บบันทึกการปฏิบัติงานเมื่อมีการตอบสนองต่อสิทธิของเจ้าของข้อมูลตาม PDPA (คำร้องขอให้เปิดเผยหรือลบข้อมูล) ไว้ในระดับเดียวกับข้อมูลที่เข้ารหัสลับ ทั้งนี้ การตรวจสอบส่วนใหญ่มักจะ "ผ่านไปได้หากมีหลักฐานการตรวจสอบ" และตัวหลักฐานเหล่านั้นเองก็ถือเป็นการแสดงให้เห็นถึงการปฏิบัติตาม PDPA ได้อย่างชัดเจน

สรุปคำถามที่พบบ่อยในทีมพัฒนาเกี่ยวกับการใช้งาน AES-256 และ PDPA ซึ่งเป็นประเด็นที่หากไม่ทราบอาจนำไปสู่การแก้ไขงานครั้งใหญ่ได้

Q1: หากนำ AES-256 มาใช้ จะถือว่าปฏิบัติตามมาตรการคุ้มครองทางเทคนิคของ PDPA ได้อย่างสมบูรณ์หรือไม่? ไม่สมบูรณ์ AES-256 เป็นเพียงมาตรฐานพื้นฐานของการเข้ารหัสเท่านั้น การจะเป็น "มาตรการที่เหมาะสม" ได้นั้น ต้องอาศัยการทำงานร่วมกับส่วนอื่น ๆ เช่น การควบคุมการเข้าถึง (RBAC/IAM), บันทึกการตรวจสอบ (Audit Log), การจำแนกประเภทข้อมูล, นโยบายการลบข้อมูล และการอบรมพนักงาน PDPA ไม่ได้เรียกร้องเพียงแค่การเข้ารหัสเท่านั้น แต่ครอบคลุมถึงกลไกการคุ้มครองข้อมูลโดยรวมทั้งหมด

Q2: AES-128 ถือว่าไม่เพียงพอต่อข้อกำหนดของ PDPA หรือไม่? AES-128 เป็นอัลกอริทึมที่ได้รับการรับรองตามมาตรฐาน FIPS 197 และเป็นที่ยอมรับในหลายกฎระเบียบ ความแตกต่างเมื่อเทียบกับ AES-256 คือ AES-256 มีความได้เปรียบในด้าน "ความทนทานต่อการถอดรหัสในอนาคต" แต่สำหรับการปฏิบัติตาม PDPA ในปัจจุบัน ทั้งสองแบบมีโอกาสสูงที่จะถูกตัดสินว่าเป็น "มาตรการที่เหมาะสม" หากระบบเดิมใช้งาน AES-128 อยู่และมีต้นทุนในการเปลี่ยนสูง การใช้งานต่อไปก็ถือว่าสมเหตุสมผล แต่สำหรับการพัฒนาระบบใหม่ การเลือกใช้ AES-256 จะปลอดภัยกว่า

Q3: หากฐานข้อมูลเดิมเปิดใช้งาน TDE (Transparent Data Encryption) อยู่แล้ว จำเป็นต้องมีการติดตั้งเพิ่มเติมหรือไม่? TDE มีประสิทธิภาพในการ "ป้องกันข้อมูลเมื่อดิสก์ถูกขโมย" แต่เนื่องจากข้อมูลจะถูกถอดรหัสโดยอัตโนมัติสำหรับผู้ใช้ที่มีสิทธิ์เข้าถึง SQL จึงไม่สามารถป้องกันการทุจริตภายในหรือการรั่วไหลผ่าน SQL Injection ได้ สำหรับคอลัมน์ที่มีข้อมูลอ่อนไหว (Sensitive Column) การเพิ่มการเข้ารหัสระดับคอลัมน์ (เช่น pgcrypto หรือการเข้ารหัสระดับแอปพลิเคชัน) ควบคู่ไปกับ TDE จะเป็นแนวทางที่อธิบายต่อการตรวจสอบ PDPA ได้ง่ายกว่า

Q4: จำเป็นต้องคำนึงถึงการเข้ารหัสที่ทนทานต่อควอนตัม (Quantum-Resistant Cryptography) ตั้งแต่ตอนนี้เลยหรือไม่? ปัจจุบันยังไม่มีการโจมตี AES-256 ที่ใช้งานได้จริงด้วยคอมพิวเตอร์ควอนตัม แม้ว่า NIST จะประกาศมาตรฐานการเข้ารหัสที่ทนทานต่อควอนตัม (ML-KEM, ML-DSA) ออกมาแล้ว แต่จุดเน้นหลักคือการแทนที่การเข้ารหัสแบบกุญแจสาธารณะ (RSA, ECDH) ส่วน AES ซึ่งเป็นการเข้ารหัสแบบสมมาตรนั้น ถือว่ายังปลอดภัยในระยะนี้หากรักษาความยาวกุญแจไว้ที่ 256 บิต ยกเว้นกรณีที่ต้องจัดเก็บข้อมูลระยะยาว (10 ปีขึ้นไป) จึงควรวางแผนสำหรับการเข้ารหัสใหม่ในอนาคตไว้ด้วย

สำหรับการปฏิบัติตามข้อกำหนด "มาตรการคุ้มครองทางเทคนิคที่เหมาะสม" (Appropriate Technical Measures) ภายใต้ PDPA ของไทยนั้น AES-256 ถือเป็นตัวเลือกที่อธิบายได้ง่ายที่สุดในทางปฏิบัติ อย่างไรก็ตาม การเพียงแค่ระบุว่า "ใช้ AES-256" ไม่ได้หมายความว่าจะผ่านการตรวจสอบได้เสมอไป การจะเป็นโครงสร้างพื้นฐานทางเทคนิคที่สอดคล้องกับ PDPA ได้นั้น จำเป็นต้องมีการออกแบบที่บูรณาการร่วมกัน ทั้งการออกแบบขอบเขตการเข้ารหัส (4 ชั้น ได้แก่ Prompt, Response, Vector และ Training Data), การเลือกโหมด (แนะนำ GCM เป็นอันดับแรก), การจัดการกุญแจเข้ารหัส (KMS, Tenant Isolation, Rotation), มาตรการป้องกันข้อมูลรั่วไหลผ่านการสำรองข้อมูลและ SaaS รวมถึงบันทึกการตรวจสอบ (Audit Log) และการทบทวนอย่างต่อเนื่อง

บทความนี้เน้นไปที่ชั้นการนำไปใช้งานทางเทคนิค (Technical Implementation Layer) แต่การปฏิบัติตาม PDPA จำเป็นต้องดำเนินการควบคู่ไปกับด้านองค์กร ในส่วนของด้านองค์กรและสัญญา เช่น การขอความยินยอม, การแต่งตั้ง DPO, สัญญาการโอนข้อมูลข้ามพรมแดน และการตอบสนองต่อคำร้องขอจากเจ้าของข้อมูลนั้น ได้มีการสรุปไว้ใน "รายการตรวจสอบการปฏิบัติตามข้อกำหนดเพื่อรองรับ PDPA ของไทยและการใช้ AI" ของบริษัทเรา นอกจากนี้ สำหรับการออกแบบธรรมาภิบาล AI ทั้งระบบ สามารถดูได้ที่ "AI Governance คืออะไร? คู่มือการปฏิบัติงานตั้งแต่การรองรับ EU AI Act ไปจนถึงการจัดทำกฎระเบียบภายในองค์กร" และสำหรับความเสี่ยงด้านความปลอดภัยโดยรวม สามารถดูได้ที่ "แนวโน้มล่าสุดด้านความปลอดภัยทางไซเบอร์สำหรับ AI" ซึ่งขอแนะนำให้ศึกษาประกอบกัน

ขั้นตอนถัดไปคือการทำรายการข้อมูล (Data Inventory) ที่ใช้ในผลิตภัณฑ์ AI ของบริษัทคุณ โดยแบ่งออกเป็น 4 ชั้น (Prompt, Response, Vector, Training Data) และทำการแมปสถานะการเข้ารหัสในปัจจุบันของแต่ละชั้น เมื่อเห็นช่องว่าง (Gap) อย่างชัดเจนแล้ว ลำดับความสำคัญในการดำเนินการจะปรากฏขึ้นมาเองโดยธรรมชาติ