การเตรียมองค์กรสำหรับ Post-Quantum Cryptography หรือ PQC ควรเริ่มจากการรู้ว่าองค์กรใช้การเข้ารหัสอยู่ตรงไหน ใครเป็นเจ้าของ และระบบใดเปลี่ยนแปลงได้ยาก ข้อมูลเหล่านี้ทำให้การเลือกเทคโนโลยี การคุยกับผู้ขาย และการจัดลำดับงบประมาณอิงกับความเสี่ยงจริง
รายงาน Postquantum Cryptography Starts With Cryptographic Visibility ของ Gartner ให้ความสำคัญกับการมองเห็นทรัพย์สินด้านการเข้ารหัสและการวางแผนเปลี่ยนผ่านหลายปี [1] ขณะที่ NIST ได้เผยแพร่มาตรฐาน PQC หลักชุดแรกแล้ว และแนะนำให้องค์กรเริ่มระบุจุดที่ใช้อัลกอริทึมเสี่ยงพร้อมวางแผนปรับเปลี่ยน [2] สำหรับองค์กรไทย งานเตรียมความพร้อมจึงเริ่มได้ทันที แม้ความพร้อมของผลิตภัณฑ์แต่ละประเภทจะแตกต่างกัน
เหตุใดต้องเริ่มก่อนวันที่ควอนตัมจะถอดรหัสได้
คอมพิวเตอร์ควอนตัมที่มีขนาดและความสามารถเพียงพออาจทำลายสมมติฐานความปลอดภัยของระบบกุญแจสาธารณะบางประเภท เช่น RSA และ ECC อย่างไรก็ตาม ยังไม่ควรระบุปีที่ระบบเหล่านี้จะถูกทำลายได้จริงเป็นข้อเท็จจริงแน่นอน การวางแผนควรใช้หลายสถานการณ์ และพิจารณาอายุความลับของข้อมูลควบคู่กับเวลาที่องค์กรต้องใช้เปลี่ยนระบบ [1–2]
ความเสี่ยงหนึ่งคือ Harvest Now, Decrypt Later ผู้โจมตีอาจเก็บข้อมูลที่เข้ารหัสไว้ในวันนี้ และรอความสามารถในการถอดรหัสในอนาคต ข้อมูลที่ต้องเป็นความลับนาน เช่น สูตรการผลิต ทรัพย์สินทางปัญญา หรือประวัติการรักษา จึงควรถูกนำมาพิจารณาก่อน [1]
อีกด้านคือความเชื่อถือในลายเซ็นดิจิทัล หากกลไกกุญแจสาธารณะที่ใช้ลงนามถูกทำลาย ผู้โจมตีอาจปลอมลายเซ็นหรือการยืนยันตัวตนได้ ความเสี่ยงจึงครอบคลุม Software update, Firmware, PKI และเอกสารที่ต้องตรวจสอบความถูกต้องในระยะยาวด้วย
Cryptographic Visibility: เห็นมากกว่าใบรับรองบนเว็บไซต์
การสแกน HTTPS หน้าเว็บไซต์ให้ข้อมูลเพียงบางส่วน องค์กรอาจใช้ Cryptography ใน API, VPN, ระบบยืนยันตัวตน, HSM, Cloud, แอปพลิเคชันภายใน และกระบวนการลงนามซอฟต์แวร์ ขณะเดียวกันระบบ OT และอุปกรณ์ฝังตัวอาจมีอายุใช้งานยาวและอัปเดตได้จำกัด [1]
แนวทางของ ALPHASEC คือผสานข้อมูลจากทะเบียนทรัพย์สิน การตรวจ Configuration และ Certificate การสำรวจ Library ในซอฟต์แวร์ การสังเกต Traffic ที่ได้รับอนุญาต และคำยืนยันจากผู้ขาย แล้วตรวจสอบความสอดคล้องระหว่างแหล่งข้อมูล ไม่ควรสรุปว่า “ครบแล้ว” จากผลสแกนเครื่องมือเดียว
สำหรับโรงงาน ควรเริ่มจากเอกสาร ผู้ดูแลระบบ และข้อมูลแบบ Passive เมื่อทำได้ การทดสอบเชิงรุกต้องผ่านการประเมินผลกระทบและอนุมัติร่วมกับทีม OT เพื่อรักษาความปลอดภัยและความต่อเนื่องของการผลิต
สร้างทะเบียน Cryptography และ CBOM ที่นำไปใช้ตัดสินใจได้
Cryptographic Bill of Materials หรือ CBOM ช่วยระบุองค์ประกอบและการพึ่งพาด้านการเข้ารหัสของซอฟต์แวร์หรือระบบ เมื่อนำมาเชื่อมกับทะเบียนทรัพย์สินขององค์กร จะช่วยติดตามว่าแต่ละบริการใช้กลไกใดและควรเปลี่ยนส่วนไหนก่อน [1]
| ข้อมูลที่ควรเก็บ | ประโยชน์ต่อแผน PQC |
|---|---|
| ระบบ บริการ และเจ้าของ | ระบุผู้รับผิดชอบและผลกระทบหากระบบหยุดทำงาน |
| วัตถุประสงค์ของ Cryptography | แยกการตั้งกุญแจ การเข้ารหัสข้อมูล และการลงลายเซ็น |
| Algorithm, Library, Protocol และเวอร์ชัน | ระบุส่วนประกอบที่ต้องอัปเดตและการพึ่งพาระหว่างระบบ |
| Certificate และการจัดการกุญแจ | เชื่อม CA, HSM, KMS, การหมุนกุญแจ และจุดเก็บรักษา |
| ประเภทข้อมูลและอายุความลับ | ประเมินความเสี่ยงจากการเก็บข้อมูลไปถอดรหัสภายหลัง |
| สถานะผู้ขายและอายุผลิตภัณฑ์ | แยกสิ่งที่อัปเกรดได้ สิ่งที่ต้องเปลี่ยน และสิ่งที่ต้องรอ |
| หลักฐานและวันที่ตรวจล่าสุด | แยกข้อมูลที่ยืนยันแล้วจากข้อมูลที่ยังต้องตรวจสอบ |
ทะเบียนนี้ควรเก็บข้อมูลอ้างอิงและ Metadata ไม่เก็บ Private key หรือ Secret จริง ให้กำหนดสิทธิ์เข้าถึงทะเบียนและอัปเดตเมื่อมีการเปลี่ยนซอฟต์แวร์ ต่ออายุใบรับรอง หรือเพิ่มผู้ให้บริการ เพื่อให้ข้อมูลใช้ได้ต่อเนื่อง
เข้าใจมาตรฐาน PQC ให้ตรงหน้าที่
NIST เผยแพร่ FIPS 203, 204 และ 205 ในเดือนสิงหาคม 2024 โดยมาตรฐานเหล่านี้มีหน้าที่ต่างกัน การออกแบบจึงต้องแยกการสร้างความลับร่วมสำหรับตั้งกุญแจออกจากการลงลายเซ็น [3–5]
| มาตรฐาน | อัลกอริทึม | หน้าที่หลัก |
|---|---|---|
| FIPS 203 | ML-KEM | กลไกสร้างความลับร่วมระหว่างคู่สื่อสาร เพื่อนำไปใช้กับระบบเข้ารหัสแบบสมมาตร |
| FIPS 204 | ML-DSA | สร้างและตรวจสอบลายเซ็นดิจิทัล |
| FIPS 205 | SLH-DSA | ลายเซ็นดิจิทัลแบบ Hash-based ที่ไม่ต้องเก็บสถานะการใช้กุญแจแบบ Stateful |
ML-KEM ไม่ใช่อัลกอริทึมที่นำมาแทน AES เพื่อเข้ารหัสข้อมูลทั้งหมดโดยตรง และการเปิด TLS 1.3 ก็ยังไม่เพียงพอจะสรุปว่าเป็น PQC ต้องตรวจกลไกตั้งกุญแจที่ตกลงใช้จริง รวมถึงการรองรับของทั้งสองฝั่งและอุปกรณ์กลาง
การเริ่มใช้ Hybrid key establishment ซึ่งผสานกลไกเดิมกับ PQC ในระบบที่รองรับ อาจช่วยการเปลี่ยนผ่าน แต่ไม่ได้ทำให้ Certificate หรือลายเซ็นของระบบกลายเป็น Post-quantum ไปด้วยโดยอัตโนมัติ ต้องวางแผนสองส่วนนี้แยกกัน และทดสอบตามมาตรฐานกับผลิตภัณฑ์ที่เลือกใช้ [1]
จัดลำดับจากอายุความลับ ผลกระทบ และความยากในการเปลี่ยน
ALPHASEC เสนอให้ประเมินอย่างน้อยสามด้านร่วมกัน ได้แก่ ข้อมูลต้องเป็นความลับอีกนานเท่าใด ระบบสำคัญต่อธุรกิจอย่างไร และการเปลี่ยนต้องพึ่งพาใครบ้าง ระบบที่ข้อมูลมีอายุความลับยาวและต้องใช้เวลาปรับเปลี่ยนหลายปีควรเริ่มเตรียมก่อน แม้ยังไม่ถึงรอบเปลี่ยนผลิตภัณฑ์
- ธนาคารและประกันภัย: สำรวจช่องทางแลกเปลี่ยนข้อมูลระหว่างองค์กร PKI และการลงนามที่เกี่ยวข้องกับบริการสำคัญ
- โรงพยาบาล: ประเมินข้อมูลสุขภาพที่เก็บระยะยาวและอุปกรณ์การแพทย์ที่มีข้อจำกัดในการอัปเดต
- โรงงาน: สำรวจการปกป้องสูตรการผลิต การเชื่อมต่อระหว่างโรงงาน และความเชื่อถือของ Firmware ในอุปกรณ์
ตัวอย่างเหล่านี้เป็นแนวทางตั้งขอบเขต ไม่ใช่การสรุปว่าทุกระบบในอุตสาหกรรมนั้นมีความเสี่ยงเท่ากัน ข้อกำหนดของลูกค้าหรือหน่วยงานกำกับที่ใช้บังคับจริงต้องนำมาประกอบการจัดลำดับด้วย
ระบบเก่าและ OT ต้องวางขอบเขตการป้องกันให้ชัด
บางระบบอาจใช้ PQC-aware Gateway, Proxy หรืออุปกรณ์เข้ารหัสภายนอกช่วยปกป้องช่องทางสื่อสารได้ โดยต้องประเมินความเข้ากันได้และผลกระทบต่อระบบ [1] การป้องกันจะครอบคลุมเฉพาะช่วงเส้นทางที่ใช้กลไกนั้น หาก Gateway ถอดรหัสก่อนส่งต่อไปยังระบบเก่า เส้นทางภายในที่เหลือยังต้องได้รับการป้องกันและประเมินแยกต่างหาก
มาตรการดังกล่าวไม่ได้เปลี่ยนลายเซ็น Firmware หรือความสามารถตรวจ Certificate ของอุปกรณ์เดิมโดยอัตโนมัติ ส่วน Network segmentation ช่วยจำกัดการเข้าถึงและผลกระทบ แต่ไม่ได้ทำให้อัลกอริทึมเดิมทนต่อควอนตัม จึงควรบันทึกข้อจำกัด ความเสี่ยงที่ยอมรับ และแผนทดแทนไว้ด้วย
PQC เป็นอัลกอริทึมที่ใช้งานบนระบบคอมพิวเตอร์ทั่วไปได้ ขณะที่ Quantum Key Distribution หรือ QKD ใช้โครงสร้างพื้นฐานทางควอนตัมเพื่อแจกจ่ายกุญแจ การพิจารณา QKD จึงเป็นโจทย์เฉพาะทาง และไม่ได้ทดแทนการวางแผน Cryptography ทั้งองค์กร [1]
90 วันแรก: สร้างฐานข้อมูลและแผนที่พิสูจน์ได้
วัน 1–30: แต่งตั้งเจ้าของโครงการ เลือกบริการสำคัญและข้อมูลอายุยาวเป็นขอบเขตแรก รวบรวมรายการระบบ ผู้ขาย และการใช้กุญแจหรือใบรับรอง พร้อมกำหนดวิธีสำรวจที่เหมาะกับ IT และ OT
วัน 31–60: ยืนยันข้อมูลจากหลายแหล่ง จัดทำทะเบียนและแผนความสัมพันธ์ของระบบ ประเมินความเสี่ยง ขอ Roadmap จากผู้ขาย และแยกสถานะว่าอะไรมีผลิตภัณฑ์รองรับจริง อะไรอยู่ใน Pilot และอะไรยังไม่มีแผน
วัน 61–90: เลือกเส้นทางทดสอบในสภาพแวดล้อมควบคุม วัดความเข้ากันได้ ประสิทธิภาพ ขนาดข้อความ และการทำงานผ่านอุปกรณ์กลาง ทดสอบแผนย้อนกลับ แล้วเสนอ Roadmap งบประมาณ เจ้าของงาน และเกณฑ์รับมอบสำหรับแต่ละระยะ
แผนนี้เป็นข้อเสนอเริ่มต้นของ ALPHASEC ไม่ใช่กรอบเวลาย้ายทั้งองค์กรเสร็จ การเปลี่ยนจริงอาจต้องดำเนินต่อหลายปีตามอายุระบบและการพึ่งพาผู้ขาย งานจัดซื้อใหม่ควรขอหลักฐานการรองรับอัลกอริทึม เวอร์ชันผลิตภัณฑ์ และกำหนดการสนับสนุนอย่างชัดเจน
รายงานความพร้อมด้วยหลักฐาน
ตัวชี้วัดที่มีประโยชน์ ได้แก่ สัดส่วนบริการในขอบเขตที่มีทะเบียน Cryptography ผ่านการยืนยันแล้ว สัดส่วนระบบสำคัญที่มีเจ้าของและแผนย้ายที่อนุมัติ สัดส่วนการเชื่อมต่อที่ผ่านการทดสอบจริง และจำนวนความเสี่ยงสำคัญที่ยังไม่มีแนวทางจัดการ ต้องระบุขอบเขตและตัวหารทุกครั้ง เพื่อไม่ให้จำนวนที่สำรวจได้บางส่วนถูกตีความว่าเป็นความพร้อมทั้งองค์กร
Crypto-agility คือความสามารถในการเปลี่ยนกลไกเข้ารหัสได้อย่างเป็นระบบ ทั้งด้านเทคโนโลยี คน และกระบวนการ ทะเบียนที่เป็นปัจจุบัน แผนทดสอบ และผู้รับผิดชอบที่ชัดเจนจะช่วยองค์กรรับมือกับการเปลี่ยนมาตรฐานในอนาคตได้ด้วย
ALPHASEC ช่วยวางจุดเริ่มต้นของ PQC Readiness
องค์กรสามารถเริ่มจากการประเมินขอบเขต สำรวจ Cryptographic assets และวาง Roadmap ที่เชื่อมกับความเสี่ยงธุรกิจ ดูรายละเอียด บริการ Post-Quantum Cryptography และ PQC Readiness ของ ALPHASEC หรือ การประเมินความเสี่ยงไซเบอร์ และ ติดต่อทีม ALPHASEC เพื่อกำหนดสิ่งส่งมอบให้เหมาะกับระบบขององค์กร
แหล่งอ้างอิง
- Gartner. Thomas Lintemuth. Postquantum Cryptography Starts With Cryptographic Visibility. 28 กันยายน 2026. รหัส G00858294, หน้า 1–13. เอกสารต้นทางที่ใช้ประกอบการเรียบเรียง
- NIST — Post-Quantum Cryptography Project
- NIST FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard
- NIST FIPS 204 — Module-Lattice-Based Digital Signature Standard
- NIST — ประกาศอนุมัติ FIPS 203, 204 และ 205, 13 สิงหาคม 2024
เรียบเรียงและวิเคราะห์โดย ALPHASEC · 28 ตุลาคม 2569 · ตารางทะเบียน ตัวอย่างอุตสาหกรรม และแผน 90 วันเป็นข้อเสนอเชิงประยุกต์ของ ALPHASEC ความพร้อมของผลิตภัณฑ์ต้องตรวจสอบเป็นรายระบบ ภาพปกเป็นภาพแนวคิดที่สร้างด้วย AI การอ้างอิงไม่หมายถึงการรับรองบริการของ ALPHASEC โดยเจ้าของแหล่งข้อมูล