CBOM คืออะไร: เริ่มทำบัญชีรายการการใช้รหัสลับ และสร้าง Crypto Agility ตามคู่มือ ก.ล.ต.
CBOM หรือบัญชีรายการการใช้รหัสลับคืออะไร เริ่มทำจากระบบไหน และ Crypto Agility ช่วยเปลี่ยนอัลกอริทึมโดยไม่หยุดธุรกิจอย่างไร สรุปจากคู่มือ ก.ล.ต. สำหรับกรรมการ
CBOM คืออะไร: เริ่มทำบัญชีรายการการใช้รหัสลับ และสร้าง Crypto Agility ตามคู่มือ ก.ล.ต.
ถ้ากรรมการอิสระถามกลางที่ประชุมว่า "ระบบไหนของเรายังใช้ RSA อยู่บ้าง" ฝ่ายไอทีอาจตอบเรื่องเว็บไซต์ได้ทันที แต่ลายมือชื่อบนเอกสารยืนยันการซื้อขาย หรือ API ของผู้ให้บริการ e-KYC ล่ะ?
คู่มือการกำกับดูแลความเสี่ยงจากเทคโนโลยีควอนตัมของ ก.ล.ต. (กันยายน 2569) เปิดบทที่ 5 ด้วยประเด็นนี้ องค์กรวางแผนเปลี่ยนผ่านไม่ได้ถ้ายังไม่รู้ว่ารหัสลับอยู่ตรงไหน (หน้า 17) นี่คือตอนที่ 3 ของซีรีส์ ถ้ายังไม่ได้อ่านภาพรวม เริ่มที่สรุปคู่มือความเสี่ยงควอนตัมของ ก.ล.ต. สำหรับกรรมการ ก่อนได้
คำตอบสั้น: CBOM (Cryptographic Bill of Materials) หรือ "บัญชีรายการการใช้รหัสลับ" คือทะเบียนที่บอกว่าระบบไหนใช้รหัสอะไร ทำหน้าที่อะไร ใครเป็นเจ้าของ และพึ่งพาใคร (หน้า 17) ส่วน Crypto Agility คือความสามารถเปลี่ยนหรือเลิกใช้อัลกอริทึมได้ทันเวลา โดยบริการไม่สะดุดและไม่ต้องรื้อระบบใหญ่ทุกครั้ง (หน้า 20) CBOM บอกว่าต้องแก้ที่ไหน Crypto Agility ทำให้แก้ได้ระหว่างที่ธุรกิจยังเดิน
คู่มือระบุสถานะตัวเองว่า "คู่มือนี้เป็นแนวทางหรือข้อแนะนำในเบื้องต้น มิใช่ข้อกำหนดหรือข้อบังคับทางกฎหมาย" (หน้าสรุปผู้บริหาร) สิ่งที่สรุปจากคู่มือด้านล่างจึงเป็นคำแนะนำให้แต่ละองค์กรปรับใช้ตามบริบท ส่วนตัวอย่างและความเห็นเรื่องเครื่องมือเป็นของเราเอง
CBOM คืออะไร ในภาษาห้องประชุม
หน้าสรุปผู้บริหารวาง CBOM เป็นขั้นที่ 2 จาก 5 ขั้น โดยทำ "เพื่อให้ทราบว่าแต่ละระบบใช้อัลกอริทึมการเข้ารหัสใด มีผู้รับผิดชอบและพึ่งพาผู้ให้บริการรายใด เพื่อใช้จัดลำดับการเปลี่ยนผ่าน" บทที่ 5 ขยายว่า CBOM มีค่าเมื่อตอบได้ว่าจุดไหนเสี่ยง จุดไหนต้องเปลี่ยนก่อน และถ้าเปลี่ยนแล้วจะกระทบระบบหรือผู้ให้บริการรายใด จำนวนรายการเพียงอย่างเดียวยังบอกไม่ได้ว่า CBOM ใช้จัดลำดับการเปลี่ยนผ่านได้หรือไม่ (หน้า 17)
รหัสลับแฝงอยู่ในเว็บไซต์ แอปพลิเคชัน การเชื่อมต่อระหว่างระบบ ลายมือชื่อดิจิทัล ใบรับรอง ฐานข้อมูล อุปกรณ์ และบริการของคู่ค้า (หน้า 17) คู่มือแนะนำให้กรรมการวัดความครบถ้วนของ CBOM จาก 6 คำถาม ตารางนี้วางคู่กับตัวอย่างที่เราสมมติขึ้นเอง ไม่ได้มาจากคู่มือ:
| คำถามที่ CBOM ต้องตอบ (หน้า 17) | ตัวอย่างสมมติ: แอปซื้อขายหุ้นของลูกค้า |
|---|
| รหัสลับอยู่ในระบบใด | การเชื่อมต่อแอปมือถือกับเซิร์ฟเวอร์รับคำสั่ง |
| ปกป้องข้อมูลหรือกระบวนการใด | การล็อกอินและคำสั่งซื้อขาย |
| ทำหน้าที่อะไร | แลกเปลี่ยนกุญแจ ยืนยันว่าเซิร์ฟเวอร์เป็นของจริง |
| ใครเป็นเจ้าของ | สายงานธุรกิจที่ดูแลช่องทางซื้อขาย (ไอทีดูแลเทคนิค) |
| พึ่งพาผู้ให้บริการรายใด | ผู้ให้บริการใบรับรอง บริษัทที่พัฒนาแอป |
| ต้องทำอะไรต่อ | ขอแผนจากผู้ให้บริการใบรับรอง นัดทดสอบกับผู้พัฒนาแอป |
รายละเอียดเทคนิค เช่น อัลกอริทึม กุญแจ ใบรับรอง โปรโตคอล และไลบรารี เป็นงานของเจ้าของระบบ โดยมีผู้สอบทานให้เป็นปัจจุบัน (หน้า 17) คู่มือไม่ได้กำหนดรูปแบบไฟล์หรือฟิลด์บังคับ แต่เตือนว่ารายชื่ออัลกอริทึมเฉยๆ ที่ไม่บอกระบบ สิ่งที่ปกป้อง และผู้รับผิดชอบ ยังใช้ไม่ได้ (หน้า 18)
ถ้ากำลังหาเครื่องมือช่วยเก็บข้อมูลฝั่งเทคนิค เช่นรายการ certificate และ algorithm บนเครื่องที่ใช้งานจริง ดูแพลนได้ที่หน้าราคา แล้วให้พาร์ทเนอร์ยืนยันขอบเขตก่อนตัดสินใจ
เริ่มทำ CBOM จากตรงไหน
ลำดับด้านล่างสรุปจากบทที่ 5 เป็นหลัก ร่วมกับหน้าสรุปผู้บริหาร (คู่มือไม่ได้ตั้งชื่อเป็นขั้นตอน)
- เริ่มจากระบบสำคัญ และบอกตรงๆ ว่าส่วนไหนยังไม่ครบ ตัวอย่างผลลัพธ์ 12 เดือนแรกในคู่มือคือ "มีบัญชีรายการใช้รหัสลับของระบบสำคัญ พร้อมระบุส่วนที่ยังสำรวจไม่ครบ" (หน้าสรุปผู้บริหาร ระบุว่าเป็นตัวอย่าง) ซึ่งดีกว่ารายงานเปอร์เซ็นต์ความคืบหน้าที่ไม่บอกขอบเขต (หน้า 15)
- นับสิ่งที่องค์กรไม่ได้ควบคุมเอง เช่น คลาวด์ ซอฟต์แวร์สำเร็จรูป API ระบบชำระเงิน ผู้ให้บริการใบรับรอง และอุปกรณ์จากผู้ขาย เพราะการเปลี่ยนรหัสอาจไปติดที่ผู้ให้บริการที่เปลี่ยนไม่ทัน (หน้า 17)
- ใช้หลายแหล่งข้อมูล ทั้งเจ้าของระบบ เอกสาร เครื่องมือค้นหา และข้อมูลจากผู้ขาย แล้วเชื่อมกับทะเบียนสินทรัพย์ที่มีอยู่ (หน้า 18) อย่าสรุปว่าครบจากเครื่องมือหรือแบบสอบถามแหล่งเดียว (หน้า 18) ถ้าทะเบียนสินทรัพย์มีช่องว่างและไม่ได้ตรวจทานกับแหล่งข้อมูลอื่น CBOM ก็อาจตกหล่นตามไปด้วย (หน้า 18 และดูทำไมต้องรู้ก่อนว่ามีเครื่องอะไรบ้าง) และ certificate บนโดเมนที่ไม่มีใครจำได้ว่าเปิดไว้ก็ต้องนับด้วย (เรื่อง external attack surface)
- จัดลำดับจากอย่างน้อย 5 ปัจจัย คือ ระยะเวลาที่ข้อมูลต้องได้รับการคุ้มครอง ความสำคัญของระบบต่อธุรกิจ การใช้รหัสที่คอมพิวเตอร์ควอนตัมอาจทำลายได้ ความเสี่ยงต่อการสวมรอยหรือปลอมลายมือชื่อ และการพึ่งพาคู่ค้าหรือระบบเดิม (หน้า 17) คู่มือแนะนำว่าไม่ควรใช้เส้นแบ่งตายตัวแบบข้อมูลเกิน 10 ปีเท่านั้นถึงเสี่ยงสูง และชี้ว่าระบบยืนยันตัวตน ลงลายมือชื่อ หรือทำธุรกรรม อาจสำคัญสูงแม้ไม่ได้เก็บข้อมูลนาน (หน้า 18) วิธีคิดเรื่องอายุความลับอยู่ในตอน Harvest Now, Decrypt Later
- สรุปเป็นรายการระบบที่ต้องทำก่อน แต่ละรายการมีเหตุผล ผู้รับผิดชอบ กรอบเวลา และทางเลือกในการแก้ไข (หน้า 18)
- ไม่ปล่อยให้ล้าสมัย มีกลไกปรับเมื่อระบบ ใบรับรอง ซอฟต์แวร์ หรือสัญญาผู้ให้บริการเปลี่ยน ทำครั้งเดียวแล้วถือว่าเสร็จคือสิ่งที่คู่มือบอกว่าไม่ควรทำ (หน้า 18)
Crypto Agility ในทางปฏิบัติ: เปลี่ยนอัลกอริทึมโดยไม่หยุดธุรกิจ
NIST ออกมาตรฐานแล้ว ทำไมยังต้องคล่องตัว? คู่มือเอ่ยถึงเพียง "FIPS 203–205" (หน้า 9) หน้าเว็บของ NIST ระบุว่า FIPS 203 คือ ML-KEM สำหรับสร้างกุญแจลับร่วมกัน ส่วน FIPS 204 (ML-DSA) และ FIPS 205 (SLH-DSA) ใช้ลงลายมือชื่อดิจิทัล (ชื่อเหล่านี้มาจาก NIST ไม่ได้อยู่ในคู่มือ) แต่อภิธานศัพท์ของคู่มือก็บอกว่า "ยังมีมาตรฐานลายมือชื่อทางเลือกเพิ่มเติมที่อยู่ระหว่างจัดทำ" (หน้า 38) และบทที่ 6 อธิบายว่าอัลกอริทึมที่ผ่านการรับรองแล้วก็อาจต้องเปลี่ยนอีก เมื่อเจอช่องโหว่ มีข้อกำหนดใหม่ หรือไม่เหมาะกับบางระบบ (หน้า 20)
คำถามจึงเป็นว่า ถ้าต้องเปลี่ยนอีกรอบ เราทำได้เร็วแค่ไหนโดยลูกค้าไม่สะดุด บทที่ 6 ให้แนวไว้ 4 ข้อ
- ไม่ผูกระบบกับอัลกอริทึมเดียว ระบบสำคัญควรเปลี่ยนวิธีเข้ารหัสได้โดยไม่ต้องแก้หลายจุดหรือรื้อทั้งระบบ กรรมการตั้งความคาดหวังและขอหลักฐาน ส่วนรายละเอียดสถาปัตยกรรมและการพัฒนาเป็นความรับผิดชอบของฝ่ายบริหารและทีมเทคนิค (หน้า 20) เช่น ถามว่าระบบสำคัญใดยังฝังอัลกอริทึมหรือใบรับรองไว้ตายตัว และมีแผนแก้พร้อมเจ้าของและงบหรือยัง (หน้า 21)
- คุมจุดตั้งค่ารหัสลับให้แน่น ถ้ารวมศูนย์การควบคุมโดยไม่มีมาตรการรัดกุม จุดนั้นอาจกลายเป็นเป้าหมายการโจมตีสำคัญ กรรมการจึงควรขอหลักฐานเรื่องการแบ่งแยกสิทธิ์ การอนุมัติ การบันทึกเหตุการณ์ และแผนสำรอง (หน้า 20–21)
- รู้คำตอบก่อนวันที่ต้องเปลี่ยนด่วน ต้องแก้ที่ไหน ใช้เวลาเท่าไร ใครอนุมัติ และระบบหรือผู้ให้บริการรายใดเป็นคอขวด คู่มือแนะนำให้ใช้ CBOM เป็นฐานตอบ (หน้า 20) นี่คือเหตุผลที่ CBOM กับ Crypto Agility ต้องทำคู่กัน
- ทดสอบกับปริมาณงานจริง และมีแผนถอยกลับ PQC มีขนาดกุญแจ ขนาดลายมือชื่อ และภาระประมวลผลต่างจากของเดิม ผลอาจไปโผล่ที่เวลาเข้าสู่ระบบ ความเร็วธุรกรรม เครือข่าย และอุปกรณ์ปลายทาง (หน้า 20) สำหรับระบบรับคำสั่งช่วงเปิดตลาด ทดสอบแค่ว่าเชื่อมต่อได้จึงไม่พอ (หน้า 21)
ส่วน Hybrid (ใช้รหัสเดิมคู่กับ PQC ระหว่างเปลี่ยนผ่าน) คู่มือแนะนำให้อนุมัติเฉพาะกรณีที่สอดคล้องกับมาตรฐานและมีเหตุผลรองรับ โดยให้ฝ่ายบริหารระบุวิธีผสมและเงื่อนไขเลิกใช้ให้ชัดเจน เพราะผสมผิดวิธีอาจเพิ่มช่องโหว่ (หน้า 21) และอย่าประเมินแค่แอปที่พัฒนาเอง Crypto Agility รวมถึงฮาร์ดแวร์ เฟิร์มแวร์ ใบรับรอง และบริการภายนอกด้วย (หน้า 20–21)
ถ้าอยากเห็นหน้าจอจริงก่อนคุยเรื่องขอบเขตกับพาร์ทเนอร์ เปิดหน้าเดโมดูประกอบได้
ผูกเข้ากับ SDLC การจัดซื้อ และการตรวจสอบ
ขั้นที่ 5 ในหน้าสรุปผู้บริหารให้ "ผนวกการดำเนินการเข้ากับวงจรการพัฒนาระบบ การจัดซื้อจัดจ้าง และการตรวจสอบ" ระยะที่ 5 ในบทที่ 9 ย้ำสามจุดเดิม โดยตั้งผลลัพธ์ไว้ว่า "องค์กรสามารถคงการมองเห็นการใช้อัลกอริทึมรหัสลับได้อย่างต่อเนื่อง ไม่ย้อนกลับสู่สภาวะที่ขาดการมองเห็นอีก" (หน้า 28)
| จุดเชื่อม | คู่มือแนะนำอะไร | คำถามสำหรับห้องประชุม |
|---|
| วงจรพัฒนาระบบ (SDLC) | ตั้งความคาดหวังว่าระบบใหม่ควรเปลี่ยนอัลกอริทึมได้ และให้ฝ่ายบริหารยืนยันว่าใส่ข้อกำหนดนี้ในกระบวนการออกแบบและจัดซื้อแล้ว (หน้า 21) | "ระบบใหม่และสัญญาใหม่ถูกกันไม่ให้เพิ่มภาระที่ต้องแก้ในอนาคตหรือไม่?" (หน้า 30) |
| การจัดซื้อจัดจ้าง | ใส่ความพร้อมด้าน PQC และ Crypto Agility ในเกณฑ์จัดซื้อใหม่ทุกรายการตั้งแต่ขั้นกำหนดความต้องการ (หน้า 22) และเชื่อมผลประเมินผู้ให้บริการรายเดิมเข้ากับ CBOM (หน้า 23) | มีกลไกให้ CBOM ปรับตามการต่อสัญญาและการเปลี่ยนใบรับรอง โดยไม่ต้องรอสำรวจใหญ่ใหม่หรือไม่ (หน้า 19) |
| การตรวจสอบ | ตาม Three Lines Model งานตรวจสอบควรเน้นคุณภาพหลักฐาน เช่น ความครบของขอบเขตสำรวจ เหตุผลในการจัดลำดับ การอนุมัติข้อยกเว้น และการติดตามแผนแก้ไข (หน้า 14) | "ฝ่ายบริหารมีวิธีการใดในการพิสูจน์ความครบถ้วนและความถูกต้องของ CBOM และได้สอบทานข้อมูลจากเจ้าของระบบ เครื่องมือค้นหา และผู้ขาย ประกอบกันแล้วหรือไม่?" (หน้า 19) |
ภาคผนวก ก ยังระบุหลักฐานที่ควรขอเมื่องานกลายเป็นงานประจำ เช่น หลักฐานการปรับ CBOM และผลการซ้อมเปลี่ยนรหัสเร่งด่วน (หน้า 32) ผลการซ้อมตอบคำถามว่าเปลี่ยนได้ภายในกี่วัน ด้วยตัวเลขที่วัดจากการลงมือจริง
คำถามที่มักตามมา
คู่มือฉบับนี้กำหนดเส้นตายให้ทำ CBOM เสร็จหรือไม่?
คู่มือฉบับนี้ไม่ได้กำหนดเส้นตายให้ทำ CBOM เสร็จ ตารางในหน้า 3 วางงาน CBOM ไว้ช่วงปี 2026–2027 แต่เป็นกรอบระดับประเทศจาก (ร่าง) กรอบของ สกมช. ที่องค์กร "อาจพิจารณา" ปรับใช้ (หน้า 2) และ "มิใช่การคาดการณ์ปีที่ภัยจากคอมพิวเตอร์ควอนตัมจะเกิดขึ้น" (หน้า 3)
ต้องรอ CBOM ครบทุกระบบก่อนเริ่มทดสอบไหม?
ไม่ต้อง ระบบเสี่ยงสูงไปก่อนได้ และทำหลายระยะคู่ขนานได้เมื่อควบคุมเพียงพอ (หน้า 28)
ซื้อเครื่องมือสแกนตัวเดียวแล้วจบได้ไหม?
ไม่จบ เครื่องมือค้นหาเป็นแค่หนึ่งในหลายแหล่ง (หน้า 18) และคู่มือไม่ได้รับรองผลิตภัณฑ์ใด (หน้า 42) เครื่องมือบอกได้ว่าเครื่องใช้ algorithm อะไร แต่ปกป้องกระบวนการไหนและใครเป็นเจ้าของ ต้องมาจากเจ้าของระบบ
ถึงอย่างนั้น ข้อมูลฝั่งเทคนิคก็ไม่ต้องกรอกมือทั้งหมด zcrX ใช้ Agent น้ำหนักเบาบนเครื่องและระบบ build ที่ลงทะเบียนไว้ รวบรวมรายการ certificate และ algorithm แล้วให้คะแนนเป็น quantum-safe, ready หรือ not ready เครื่องที่ไม่มี Agent จะขึ้นว่าไม่มีการวัด ไม่ถูกนับว่าปลอดภัย zcrX ช่วยให้เห็นรายการ certificate และ algorithm บนเครื่องที่ติดตั้ง Agent ส่วนการระบุว่าแต่ละรายการปกป้องกระบวนการใดและใครรับผิดชอบ การสำรวจบริการคลาวด์หรือระบบคู่ค้าที่ติด Agent ไม่ได้ การจัดลำดับ และการวางแผนเปลี่ยนผ่าน ยังเป็นงานของทีมคุณและพาร์ทเนอร์ ดูขอบเขตการวัดของ zcrX ได้ที่หน้า PQC Readiness
อ่านต่อในซีรีส์นี้
ติดต่อทีมงาน
มีคำถามเรื่องการเก็บรายการ certificate และ algorithm หรืออยากเห็นหน้าจอจริงก่อนตัดสินใจ คุยกับทีมเราได้ฟรี ไม่มีค่าใช้จ่าย zcr ให้ซอฟต์แวร์ ส่วนงานสำรวจระบบ ทดสอบ และเปลี่ยนผ่านแบบลงมือจริงดำเนินการผ่านพาร์ทเนอร์
แหล่งข้อมูลอ้างอิง
หน้าเว็บ NIST เปิดอ่านเมื่อ 27 ตุลาคม 2026 เลขหน้าในบทความคือเลขที่พิมพ์ในคู่มือ ส่วน "หน้าสรุปผู้บริหาร" คือหน้า Executive Summary ที่ไม่มีเลขหน้าพิมพ์ (หน้าที่ 2 ของไฟล์ PDF)
- ก.ล.ต. — คู่มือการกำกับดูแลความเสี่ยงจากเทคโนโลยีควอนตัม (Quantum Risk Governance & PQC Transition) สำหรับกรรมการบริษัท (กันยายน 2569) — หน้าสรุปผู้บริหาร, บทนำ (หน้า 2–3), บทที่ 2 (หน้า 9–10), บทที่ 4 (หน้า 14–15), บทที่ 5 (หน้า 17–19), บทที่ 6 (หน้า 20–21), บทที่ 7 (หน้า 22–23), บทที่ 9 (หน้า 28), ภาคผนวก ก (หน้า 30, 32), อภิธานศัพท์ (หน้า 38), หมายเหตุการจัดทำ (หน้า 42)
- NIST — FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard — ML-KEM สำหรับสร้างกุญแจลับร่วมกัน, เผยแพร่ 13 สิงหาคม 2024
- NIST — FIPS 204: Module-Lattice-Based Digital Signature Standard — ML-DSA สำหรับลายมือชื่อดิจิทัล, เผยแพร่ 13 สิงหาคม 2024
- NIST — FIPS 205: Stateless Hash-Based Digital Signature Standard — SLH-DSA สำหรับลายมือชื่อดิจิทัล, เผยแพร่ 13 สิงหาคม 2024
