การมาถึงของควอนตัมคอมพิวเตอร์ที่มีศักยภาพสูงพอในการถอดรหัส หรือ “Q-day” กำลังเปลี่ยนผ่านจากการเป็นเพียงความท้าทายทางคณิตศาสตร์เชิงทฤษฎีในอนาคต ไปสู่กรอบเวลาที่บีบบังคับให้ทีมความปลอดภัยไซเบอร์ต้องวางแผนรับมือตั้งแต่วันนี้
สาเหตุสำคัญมาจากกลุ่มผู้ไม่หวังดีเริ่มดำเนินกิจกรรมในลักษณะ “ดักเก็บข้อมูลวันนี้ เพื่อรอถอดรหัสในวันหน้า” (Harvest now, decrypt later) ด้วยการดักจับและกักเก็บข้อมูลการรับส่งภายในองค์กรที่ผ่านการเข้ารหัส ทรัพย์สินทางปัญญา ข้อมูลการฝึกอบรม AI Model Weights และบันทึกข้อมูลระบบ (data logs) เอาไว้ เพื่อรอนำไปประมวลผลผ่านฮาร์ดแวร์ควอนตัมทันทีที่เทคโนโลยีพร้อมใช้งาน
กรอบเวลาบีบบังคับ องค์กรต้องขยับก่อนสาย
ความเร่งด่วนนี้ไม่ใช่เรื่องสมมติ โดยคำสั่งบริหารหมายเลข 14412 ของทำเนียบขาว กำหนดให้หน่วยงานรัฐบาลกลางต้องนำร่องย้ายระบบไปสู่ความพร้อมด้านการเข้ารหัสยุคหลังควอนตัม (Post-Quantum Cryptography หรือ PQC) ภายในปี 2027 และดำเนินการเต็มรูปแบบภายในปี 2029
ขณะที่ข้อกำหนด Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) ของสำนักงานความมั่นคงแห่งชาติสหรัฐฯ (NSA) กำหนดให้ปรับใช้กับโปรโตคอล TLS เชิงพาณิชย์ภายในปี 2030 หากองค์กรรอจนกว่าควอนตัมคอมพิวเตอร์ปรากฏขึ้นแล้วค่อยเริ่มย้ายระบบ จะพบว่าตนเองล้าหลังไป 3-5 ปี และข้อมูลสำคัญที่เคยจัดเก็บไว้ก็มีโอกาสสูงที่จะถูกเปิดเผยไปเรียบร้อยแล้ว
เร้ดแฮท ชูสถาปัตยกรรมความปลอดภัยยุคควอนตัมระดับรากฐาน
เร้ดแฮท (Red Hat) นำเสนอโซลูชันด้วยการฝังความปลอดภัยยุคควอนตัม (quantum-safe) ลงในชั้นรากฐานของโครงสร้างพื้นฐานไฮบริดคลาวด์โดยตรง
- Red Hat Enterprise Linux 10 (RHEL 10): ระบบปฏิบัติการ Linux ระดับองค์กรรายแรกที่มาพร้อมอัลกอริทึมยุคหลังควอนตัมมาตรฐาน NIST เช่น ML-KEM และ ML-DSA เปิดใช้งานโดยตรงในระดับระบบปฏิบัติการ
- Red Hat OpenShift: นำขีดความสามารถจาก RHEL มาเปิดใช้งานจริงและขยายให้ครอบคลุมทั่วสภาพแวดล้อมแบบกระจายตัว ช่วยย้ายงานความปลอดภัยจากชั้นแอปพลิเคชันลงมาไว้ที่ชั้นโครงสร้างพื้นฐานแบบรวมศูนย์ ลดความซับซ้อนและค่าใช้จ่ายในการดำเนินงาน
4 ขั้นตอนสำคัญ ปูทางองค์กรพร้อมรับมือ Q-Day
1. สำรวจร่องรอยการเข้ารหัสที่แอบแฝงบนไฮบริดคลาวด์
องค์กรไม่สามารถปกป้องสิ่งที่มองไม่เห็นได้ ทีมความปลอดภัยต้องจัดทำแผนผังสินทรัพย์ที่มีมูลค่าสูง เช่น AI model weights และบันทึกการฝึกอบรม เพื่อตรวจสอบว่าข้อมูลถูกเข้ารหัสไว้ที่ใดและกุญแจดิจิทัลถูกสร้างขึ้นที่ใด การใช้นโยบายการเข้ารหัสเริ่มต้นใน RHEL 10 จะช่วยเปิดใช้งานอัลกอริทึมขั้นสูงที่ต้านทานควอนตัมสำหรับการแคปซูลกุญแจ (key encapsulation) ได้ทันที เพื่อทดสอบประสิทธิภาพระบบก่อนย้ายไปใช้งานจริง
2. ทดสอบชุดคำสั่งทางคณิตศาสตร์เข้ารหัสยุคใหม่ใน Sandbox
การเปลี่ยนผ่านสู่ระบบต้านทานควอนตัมต้องประเมินผลกระทบต่อประสิทธิภาพแอปพลิเคชัน นโยบาย FUTURE บน RHEL 10 ช่วยให้ผู้ดูแลระบบสับเปลี่ยนรูปแบบการเข้ารหัสของโฮสต์ทั้งหมดไปสู่มาตรฐานต้านทานควอนตัมได้ด้วยคำสั่งเดียว
นอกจากนี้ Red Hat OpenShift 4.22 ยังมาพร้อมขีดความสามารถแลกเปลี่ยนคีย์รหัส ML-KEM hybrid key exchange เป็นค่าเริ่มต้น ส่งผลให้ทุกขั้นตอนการสร้างความเชื่อมต่อแบบปลอดภัย (TLS handshake) ระหว่าง control plane ใช้การเข้ารหัสยุคหลังควอนตัมโดยอัตโนมัติโดยไม่ต้องแก้ไขโค้ดแอปพลิเคชัน
3. ย้ายขอบเขตความปลอดภัยจากเลเยอร์แอปพลิเคชันสู่เลเยอร์แพลตฟอร์ม
การคาดหวังให้ทีมพัฒนาแก้ไขโค้ดแอปพลิเคชันทุกตัวเพื่อรองรับ PQC สร้างอุปสรรคและเสี่ยงต่อข้อผิดพลาด การเปลี่ยนมาใช้ Red Hat OpenShift จะช่วยจัดการเปลี่ยนวิธีการเข้ารหัสในชั้นแพลตฟอร์มให้อัตโนมัติ ป้องกันข้อมูลที่ถูกดักจับในวันนี้ไม่ให้สามารถอ่านได้ในอนาคต โดยที่ทีมพัฒนาแอปพลิเคชันไม่จำเป็นต้องเข้าไปแก้ไขโค้ดเลยแม้แต่น้อย
4. ควบคุมตำแหน่งจัดเก็บและการประมวลผลข้อมูลอย่างเบ็ดเสร็จ
องค์กรต้องมีอำนาจสิทธิ์ขาดในการกำหนดจุดจัดเก็บและประมวลผลข้อมูล โดยสามารถใช้สภาพแวดล้อมแพลตฟอร์มแบบแยกส่วน (isolated platform environments) เพื่อแบ่งขอบเขตเวิร์กโหลด ป้องกันเส้นทางเดินข้อมูลรั่วไหล ควบคู่กับการใช้เทคโนโลยีประมวลผลที่ถูกเข้ารหัสในระดับฮาร์ดแวร์ (confidential containers) เพื่อปกป้องข้อมูลสำคัญระหว่างการประมวลผล
องค์กรยุคใหม่สามารถเริ่มต้นเตรียมความพร้อมได้ทันที โดยการสำรวจโครงสร้างการเข้ารหัส (cryptographic footprint) ทั้งหมดในระบบ เพื่อประเมินความพร้อมและวางโรดแมปการย้ายระบบล่วงหน้า ก่อนที่เส้นตายวิกฤตไซเบอร์จะมาถึง
บทความโดย JP Jung, Red Hat
