คู่ค้าพร้อม PQC หรือยัง? คำถามที่ควรถาม วิธีจัดลำดับ และเงื่อนไข TOR ตามคู่มือควอนตัมของ ก.ล.ต.
คำถามความพร้อม PQC ที่ควรส่งถึงคู่ค้า วิธีจัดลำดับผู้ให้บริการ และ 6 เงื่อนไข TOR ตามบทที่ 7 และเครื่องมือที่ 4 ของคู่มือควอนตัม ก.ล.ต. ใช้ได้ก่อนต่อสัญญา
คู่ค้าพร้อม PQC หรือยัง? คำถามที่ควรถาม วิธีจัดลำดับ และเงื่อนไข TOR ตามคู่มือควอนตัมของ ก.ล.ต.
ตัวอย่างสมมติ: ฝ่ายไอทีของบริษัทหลักทรัพย์ส่งอีเมลถามผู้ให้บริการระบบ back office ว่าพร้อมรับมือความเสี่ยงจากควอนตัมหรือยัง ได้คำตอบกลับมาบรรทัดเดียวว่า "ผลิตภัณฑ์ของเรารองรับ PQC แล้ว" ทีมแนบอีเมลเข้ารายงานความเสี่ยง แล้วปิดประเด็น
ตามคู่มือการกำกับดูแลความเสี่ยงจากเทคโนโลยีควอนตัมที่ ก.ล.ต. เผยแพร่เมื่อกันยายน 2569 คำตอบแบบนี้ยังไม่พอ บทที่ 7 ว่าด้วยความเสี่ยงจากห่วงโซ่อุปทาน แนะนำให้ขอหลักฐานประกอบ แทนการรับแค่คำยืนยันว่า "รองรับ PQC แล้ว" (หน้า 22)
PQC (Post-Quantum Cryptography) คือวิทยาการรหัสลับที่ออกแบบให้ทนต่อการโจมตีจากทั้งคอมพิวเตอร์ทั่วไปและคอมพิวเตอร์ควอนตัม (หน้า 38) ส่วน TOR (Terms of Reference) คือเอกสารกำหนดขอบเขตของงาน (หน้า 22–23)
สรุปสั้น: จัดลำดับคู่ค้าตามผลกระทบ ขอหลักฐานที่ระบุรุ่น มาตรฐาน ผลทดสอบ ข้อจำกัด และวันที่ใช้งานได้จริง ใส่เงื่อนไขไว้ใน TOR ก่อนเลือกผู้ขาย และให้คณะกรรมการเห็นคู่ค้ารายสำคัญในรายงานหน้าเดียวก่อนต่อสัญญาที่มีนัยสำคัญ
คู่มือนี้เป็นแนวทาง ไม่ใช่กฎหมาย ตัวคู่มือเขียนไว้ว่า "มิใช่ข้อกำหนดหรือข้อบังคับทางกฎหมาย" (PDF หน้า 2) และไม่ได้กำหนดเส้นตายให้บริษัทใด ภาพรวมทั้งเล่มอยู่ในบทความหลักของซีรีส์นี้
ทำไมความพร้อมของเราอย่างเดียวไม่พอ
คู่มือชี้ว่าคลาวด์ ซอฟต์แวร์สำเร็จรูป ระบบซื้อขาย ระบบชำระเงิน อุปกรณ์รักษากุญแจ ใบรับรอง และการเชื่อมต่อกับหน่วยงานอื่น ล้วนมีอัลกอริทึมรหัสลับของผู้ให้บริการภายนอกอยู่เบื้องหลัง ถ้าผู้ให้บริการรายสำคัญเปลี่ยนไม่ทัน องค์กรอาจยังมีจุดเสี่ยงค้าง หรือถึงขั้นให้บริการไม่ได้ แม้ระบบภายในจะพร้อมแล้ว ความเสี่ยงนี้ไม่ได้ย้ายไปอยู่กับผู้ให้บริการ ถ้าคู่ค้าตอบไม่ชัด คู่มือแนะนำให้บันทึกเป็นความเสี่ยงและกำหนดวันที่ติดตาม (หน้า 22)
บทที่ 5 ก็ให้ขอบเขตของบัญชีรายการการใช้รหัสลับ (CBOM) รวมสิ่งที่องค์กรไม่ได้ควบคุมเอง เช่น คลาวด์ API และอุปกรณ์จากผู้ขาย (หน้า 17) หากต้องทบทวนทะเบียนสินทรัพย์เดิม อ่านแนวทางเพิ่มเติมได้ในบทความเรื่องทะเบียนสินทรัพย์กับการป้องกัน ransomware วิธีเริ่มทำ CBOM อยู่ในบทความเรื่อง CBOM และ Crypto Agility
จัดลำดับก่อน: คู่ค้ารายไหนต้องถามละเอียด
คู่มือแนะนำให้ปรับระดับการประเมินตามความสำคัญของบริการและผลกระทบต่อธุรกิจ (หน้า 23) โดยเริ่มจากผู้ให้บริการที่ถ้าสะดุดแล้วกระทบธุรกิจสูง เช่น คลาวด์ ระบบแกนหลัก ระบบซื้อขายและชำระเงิน ผู้ให้บริการใบรับรอง อุปกรณ์บริหารกุญแจ และผู้เชื่อมต่อผ่าน API แล้วจัดลำดับจากหลายปัจจัย (หน้า 22) ผู้ออกใบรับรองให้เว็บไซต์และระบบที่เปิดสู่อินเทอร์เน็ตก็อยู่ในกลุ่มนี้ ถ้ายังไม่รู้ว่ามีอะไรเปิดอยู่บ้าง เริ่มจากการสำรวจ external attack surface คอลัมน์ขวาของตารางเป็นตัวอย่างของผู้เขียน
| ปัจจัยตามคู่มือ (หน้า 22) | ตัวอย่างในงานตลาดทุน |
|---|
| ความสำคัญของบริการ | ระบบรับคำสั่งซื้อขาย ระบบชำระราคา |
| ข้อมูลที่ผู้ให้บริการเข้าถึง | ผู้เก็บไฟล์ KYC และประวัติการซื้อขายที่ต้องเป็นความลับนาน |
| การใช้ลายมือชื่อดิจิทัลหรือการยืนยันตัวตน | ระบบเปิดบัญชีออนไลน์ ระบบลงนามเอกสารยืนยันรายการ |
| ความยากในการเปลี่ยนผู้ให้บริการ | ระบบหลักที่ผูกกับข้อมูลและกระบวนการทั้งบริษัท |
| เวลาที่ผู้ให้บริการต้องใช้ปรับปรุงผลิตภัณฑ์ | อุปกรณ์ที่ต้องอัปเดตเฟิร์มแวร์หรือเปลี่ยนเครื่อง |
คู่มือระบุปัจจัยที่ควรพิจารณา แต่ไม่ได้กำหนดน้ำหนัก องค์กรควรกำหนดวิธีจัดลำดับให้เหมาะกับความเสี่ยงของตน ผลที่ต้องการคือรายชื่อสั้นๆ ของคู่ค้าที่ถ้าเขาช้า เราก็ช้าตาม
คำถามที่ควรส่งถึงคู่ค้า
หน้า 22 ระบุสิ่งที่องค์กรอย่างน้อยควรทราบจากผู้ให้บริการไว้ห้าเรื่อง ส่วนหน้า 23 ระบุว่าการขอ CBOM อาจทำได้เฉพาะบางราย เพราะ "ผู้ให้บริการบางรายยังมิได้จัดทำ CBOM หรือมีข้อจำกัดด้านความลับทางการค้า" จึงแนะนำให้กำหนดข้อมูลขั้นต่ำที่จำเป็นต่อการประเมินความเสี่ยงแทน อาทิ "หน้าที่ของอัลกอริทึมรหัสลับที่ใช้ มาตรฐานที่รองรับ รุ่นผลิตภัณฑ์ กำหนดการปรับปรุง และส่วนที่องค์กรต้องดำเนินการเอง"
เราเรียบเรียงทั้งสองส่วนเป็นคำถามเจ็ดข้อ (คอลัมน์กลางเป็นถ้อยคำของผู้เขียน):
| คำถามถึงคู่ค้า | หลักฐานที่ควรได้ | หน้า |
|---|
| 1. รุ่นไหนรองรับมาตรฐานอะไร | ชื่อรุ่นและเลขมาตรฐาน | 22, 23 |
| 2. อัลกอริทึมในผลิตภัณฑ์ทำหน้าที่อะไร | เช่น แลกเปลี่ยนกุญแจ ลงลายมือชื่อ | 23 |
| 3. ต้องปรับซอฟต์แวร์ เฟิร์มแวร์ หรืออุปกรณ์ไหม | อัปเดตได้ หรือต้องเปลี่ยนฮาร์ดแวร์ | 22 |
| 4. ทดสอบกับระบบใดแล้ว | ผลทดสอบและสภาพแวดล้อมที่ใช้ | 22 |
| 5. ข้อจำกัดด้านประสิทธิภาพและความเข้ากันได้ | ผลต่อความเร็วและระบบที่เชื่อมต่อ | 22 |
| 6. ใช้งานได้จริงเมื่อไร | วันที่ที่ผูกกับรุ่นผลิตภัณฑ์ | 22, 23 |
| 7. ส่วนไหนที่เราต้องทำเอง | เช่น เปลี่ยนการตั้งค่า ออกใบรับรองใหม่ | 23 |
ราคาผลิตภัณฑ์ของ zcr ดูได้ที่หน้าราคา
สำหรับข้อ 1 ให้ขอเลขมาตรฐานให้ชัด คู่มืออ้าง FIPS 203–205 ของ NIST ว่าเป็นมาตรฐาน PQC ชุดแรก (หน้า 9, 38) เอกสาร NIST ที่ประกาศเมื่อ 13 สิงหาคม 2024 ระบุว่า FIPS 203 คือ ML-KEM สำหรับสร้างกุญแจลับร่วม ส่วน FIPS 204 (ML-DSA) และ FIPS 205 (SLH-DSA) เป็นลายมือชื่อดิจิทัล ชื่ออัลกอริทึมเหล่านี้มาจาก NIST ไม่ได้อยู่ในคู่มือ ก.ล.ต.
เอกสาร Quantum-Readiness ของ CISA, NSA และ NIST (สิงหาคม 2023) เสริมว่าเครื่องมือค้นหาอาจมองไม่เห็นรหัสลับที่ฝังในผลิตภัณฑ์ จึงควรขอรายการจากผู้ขายโดยตรง พร้อมถามว่าจะส่งอัปเดตเมื่อไร อย่างไร และมีค่าใช้จ่ายเท่าไร
อ่านคำตอบ: ยืนยันแล้ว ยืนยันบางส่วน หรือยังไม่ยืนยัน
เครื่องมือที่ 4 ในภาคผนวก ก มีช่อง "แผนรองรับ PQC และวันที่พร้อม" ให้เลือก ยืนยันแล้ว ยืนยันบางส่วน หรือยังไม่ยืนยัน (หน้า 36) คู่มือไม่ได้นิยามแต่ละสถานะ แต่คำถามข้อ 2 ของบทที่ 7 ใช้เทียบได้ดี:
"หลักฐานความพร้อมของผู้ให้บริการภายนอกรายสำคัญได้ระบุรุ่นผลิตภัณฑ์ มาตรฐานที่รองรับ ผลการทดสอบ สิ่งที่ลูกค้าต้องดำเนินการปรับปรุง และวันที่สามารถใช้งานได้จริงไว้ครบถ้วนแล้วหรือไม่?" (หน้า 24)
ข้อเสนอของผู้เขียน ไม่ใช่นิยามของคู่มือ: ใช้ห้าเรื่องนี้ตรวจว่าข้อมูลครบหรือไม่ แล้วให้ผู้รับผิดชอบสอบทานหลักฐาน รุ่นผลิตภัณฑ์ ขอบเขตผลทดสอบ และวันที่พร้อมใช้กับระบบขององค์กรก่อนกำหนดสถานะ ข้อมูลครบเพียงอย่างเดียวยังไม่ยืนยันความพร้อม ถ้าอยากคุยเรื่องเกณฑ์นี้ คุยกับทีมเราได้ ส่วนงานประเมินคู่ค้าแบบลงมือจริงทำผ่านพาร์ทเนอร์
คำตอบไม่ควรจบที่แฟ้มจัดซื้อ หน้า 23 แนะนำให้เชื่อมผลประเมินคู่ค้ากับ CBOM เพื่อให้เห็นว่าความล่าช้าของผู้ให้บริการรายใดจะกระทบระบบใด
TOR สัญญา และรอบต่อสัญญา
ระดับนโยบาย คู่มือแนะนำให้คณะกรรมการกำหนดให้ใส่ความพร้อมด้าน PQC และ Crypto Agility ไว้ในเกณฑ์จัดซื้อจัดจ้างใหม่ทุกรายการตั้งแต่ขั้นกำหนดความต้องการ ให้ฝ่ายจัดซื้อ ฝ่ายกฎหมาย และเจ้าของระบบรับผิดชอบร่วมกัน และรายงานผลต่อคณะกรรมการเป็นระยะ (หน้า 22)
สำหรับบริการที่มีความสำคัญ เงื่อนไขใน TOR หรือสัญญา "ควรครอบคลุมอย่างน้อย 6 ประการ" (หน้า 22–23):
- มาตรฐานและผลิตภัณฑ์ที่ผู้ขายต้องรองรับ
- กำหนดส่งมอบและแผนการปรับปรุงผลิตภัณฑ์
- การแจ้งให้องค์กรทราบล่วงหน้าเมื่อผู้ขายมีการเปลี่ยนแปลงแผน
- การร่วมทดสอบ
- สิทธิในการขอข้อมูลหรือเข้าสอบทาน
- แนวทางดำเนินการในกรณีที่ผู้ขายไม่สามารถส่งมอบได้ตามกำหนด
คู่มือเติมท้ายว่า "ควรกำหนดระดับความเข้มข้นของเงื่อนไขให้เหมาะสมกับความสำคัญของบริการ" และให้มาแค่หัวข้อ ไม่ได้ให้ถ้อยคำสัญญา ส่วนนั้นเป็นงานของฝ่ายกฎหมาย
เรื่องจังหวะ ตาราง do/don't หน้า 23 เตือนว่าถ้าเลือกผู้ให้บริการไปก่อนแล้วค่อยเจรจาเรื่อง PQC ทีหลัง อำนาจต่อรองอาจลดลง
กับคู่ค้ารายเดิม จุดที่ใช้ได้คือรอบต่อสัญญา เครื่องมือที่ 4 ให้ฝ่ายบริหารรวบรวมและรับรองข้อมูล แล้วเสนอ "ตามรอบเดียวกับเครื่องมือที่ 3 และก่อนต่อสัญญาที่มีนัยสำคัญ" มีช่องวันต่อสัญญาและตัวเลือกทบทวนเงื่อนไขสัญญา (หน้า 36) คำถามของบทที่ 9 ถามว่าแผนเปลี่ยนผ่านเชื่อมกับ "รอบการต่ออายุสัญญากับคู่ค้าและผู้ให้บริการหรือไม่" (หน้า 28) และบทที่ 5 ถามถึงกลไกที่ทำให้ CBOM ปรับตามการต่อสัญญา (หน้า 19)
ข้อเสนอของผู้เขียน: ใช้รอบต่อสัญญาเป็นจังหวะให้ฝ่ายจัดซื้อและฝ่ายกฎหมายทบทวนเงื่อนไขทั้งหกข้อ โดยปรับให้เหมาะกับความสำคัญของบริการ
แผนสำรอง: ตัดสินใจไว้ก่อนวันที่คู่ค้าบอกว่าไม่ทัน
หน้า 23 แนะนำให้คณะกรรมการขอหลักฐานว่ามีแผนสำรองสำหรับผู้ให้บริการรายสำคัญ และกำหนดจุดตัดสินใจไว้ล่วงหน้า ทางเลือกที่ยกตัวอย่างไว้ เช่น จำกัดข้อมูลหรือบริการที่ใช้ แยกการเชื่อมต่อ ใช้มาตรการชั่วคราว เร่งเปลี่ยนรุ่นผลิตภัณฑ์ หรือเตรียมผู้ให้บริการทางเลือก โดยประเมินผลกระทบ ต้นทุน ระยะเวลา และผู้มีอำนาจตัดสินใจของแต่ละทางไว้ก่อนเกิดเหตุ
คู่มือยังชี้ว่าความร่วมมือระดับอุตสาหกรรมอาจลดการประเมินซ้ำซ้อน และทำให้ข้อกำหนดที่ส่งถึงผู้ขายสอดคล้องกันขึ้น ประเด็นนี้อาจนำไปพิจารณาร่วมกันได้ หากพบว่าหลายองค์กรพึ่งพาผู้ให้บริการรายเดียวกัน
เครื่องมือที่ 4: หน้าเดียวที่คณะกรรมการควรเห็น
"สรุปภาพรวมคู่ค้า / ผู้ให้บริการรายสำคัญสำหรับคณะกรรมการ" เป็นรายงานหน้าเดียว แสดงคู่ค้าที่ถ้าเปลี่ยนผ่านไม่ทันจะกระทบระบบหรือบริการสำคัญ (หน้า 36) นอกจากหัวฟอร์มและช่อง "ข้อจำกัดสำคัญของแผน" กับ "สิ่งที่ขอจากคณะกรรมการ" ตารางมีห้าคอลัมน์:
| คอลัมน์ | ช่องที่ต้องกรอก |
|---|
| ชื่อคู่ค้า / ผู้ให้บริการ | ชื่อ, ผู้รับผิดชอบ |
| ระบบที่พึ่งพา และสัดส่วนการพึ่งพา | ระบบที่พึ่งพา, สูง / กลาง / ต่ำ |
| แผนรองรับ PQC และวันที่พร้อม | ยืนยันแล้ว / ยืนยันบางส่วน / ยังไม่ยืนยัน, วันที่พร้อม |
| ผลกระทบหากไม่ทัน / ทางเลือกสำรอง / วันต่อสัญญา | ผลกระทบ, ทางเลือกสำรอง, วันต่อสัญญา |
| ความเร่งด่วน และเรื่องที่เสนอ | สูง / กลาง / ต่ำ; กำหนดกรอบเวลา, อนุมัติทางเลือกสำรอง, ทบทวนเงื่อนไขสัญญา, พิจารณายอมรับความเสี่ยง |
ข้อควรระวัง: แถวตัวอย่างในเครื่องมือที่ 4 เป็นบริษัทนามสมมติ และกรอบเวลาให้คู่ค้ายืนยันแผนที่เห็นใน Dashboard ของเครื่องมือที่ 3 ก็เป็นค่าสมมติ ซึ่งคู่มือหมายเหตุว่า "มิใช่ข้อกำหนดหรือแนวทางตามความคาดหวังของสำนักงาน ก.ล.ต." (หน้า 34) ใช้แค่โครงฟอร์ม แล้วตั้งกรอบเวลาเอง
คำถามที่พบบ่อย
ก.ล.ต. กำหนดเส้นตายให้คู่ค้าต้องพร้อม PQC ไหม?
ไม่มี ปี 2026–2035 ในคู่มือมาจาก (ร่าง) กรอบของ สกมช. ซึ่งคู่มือใช้คำว่าองค์กร "อาจพิจารณา" วางแผนให้สอดคล้อง (หน้า 2, 27)
คู่ค้าไม่ยอมส่ง CBOM ทำอย่างไร?
ขอข้อมูลขั้นต่ำแทน (หน้า 23) ถ้ายังตอบไม่ได้ ให้บันทึกเป็นความเสี่ยงและกำหนดวันติดตาม (หน้า 22)
เริ่มจากตรงไหนในเดือนนี้
- ดึงรายชื่อคู่ค้าจากทะเบียนสัญญา คัดด้วยห้าปัจจัยให้เหลือรายสำคัญ
- ส่งคำถามเจ็ดข้อ พร้อมวันที่ต้องการคำตอบที่องค์กรกำหนดเอง
- ลงคำตอบในฟอร์มแบบเครื่องมือที่ 4 แล้วเชื่อมกับ CBOM
- เรียงวันต่อสัญญา แล้วส่งหกข้อของ TOR ให้ฝ่ายจัดซื้อและฝ่ายกฎหมาย
- อีกเรื่องที่ควรตรวจแยกจากแผน PQC ของคู่ค้า คือที่มาของ dependency ที่ทีมพัฒนาใช้จาก npm, PyPI, Go และ Maven โดย supply-chain posture ของ zcrX ยืนยันที่มาของ dependency เหล่านี้ด้วย cryptographic proof หรือการยืนยันจาก Agent บน host และระบบ build ที่ติดตั้ง Agent ไว้ เครื่องที่ไม่มี Agent จะขึ้นว่ายังไม่ได้วัด ไม่ใช่ถือว่าปลอดภัย แต่ zcrX ตรวจ dependency ของซอฟต์แวร์ ไม่ได้ประเมินแผน PQC ของคู่ค้า ข้อ 1–4 จึงยังเป็นงานของทีมคุณและพาร์ทเนอร์ ดูขอบเขตการวัดของ zcrX ได้ที่หน้า PQC Readiness
อ่านต่อในซีรีส์นี้: สรุปคู่มือควอนตัมของ ก.ล.ต. สำหรับกรรมการ · CBOM และ Crypto Agility
ติดต่อทีมงาน
อยากคุยว่าควรเริ่มถามคู่ค้ารายไหนก่อน และคำถามชุดนี้ควรปรับอย่างไรให้เข้ากับคู่ค้าแต่ละกลุ่ม คุยกับทีมเราได้ฟรี ไม่มีค่าใช้จ่าย zcr ให้ซอฟต์แวร์ ส่วนงานประเมิน ติดตั้ง และวางแผนเปลี่ยนผ่านแบบลงมือจริงดำเนินการผ่านพาร์ทเนอร์
แหล่งข้อมูลอ้างอิง
- ก.ล.ต. ฝ่ายกำกับและตรวจสอบความเสี่ยงด้านเทคโนโลยีสารสนเทศ — คู่มือการกำกับดูแลความเสี่ยงจากเทคโนโลยีควอนตัม (Quantum Risk Governance & PQC Transition) สำหรับกรรมการบริษัท, กันยายน 2569 — บทที่ 7 (หน้า 22–24), ภาคผนวก ก เครื่องมือที่ 3–4 (หน้า 34, 36), บทที่ 5 (หน้า 17, 19), บทที่ 9 (หน้า 27–28), ข้อความสถานะของคู่มือ (PDF หน้า 2) — อ่านเมื่อ 27 ตุลาคม 2026
- CISA, NSA และ NIST — Quantum-Readiness: Migration to Post-Quantum Cryptography (21 สิงหาคม 2023) — รหัสลับที่ฝังในผลิตภัณฑ์, การถามผู้ขายเรื่องกำหนดการอัปเดตและค่าใช้จ่าย — อ่านเมื่อ 27 ตุลาคม 2026
- NIST — FIPS 203, FIPS 204, FIPS 205 — ชื่อมาตรฐาน ชื่ออัลกอริทึม และวันที่ประกาศ 13 สิงหาคม 2024 — อ่านเมื่อ 27 ตุลาคม 2026
