วันอังคาร ที่ 11 สิงหาคม 2569

Login
Login

Q-Day ใกล้กว่าที่คิด! Red Hat แนะ 4 ขั้นตอนรับมือภัยถอดรหัสข้อมูล

ความก้าวหน้าของ ควอนตัมคอมพิวเตอร์ กำลังเปลี่ยนโจทย์ความปลอดภัยทางไซเบอร์ จากการรับมือภัยคุกคามในปัจจุบัน สู่การเตรียมพร้อมสำหรับวันที่เทคโนโลยีมีศักยภาพมากพอที่จะถอดรหัสข้อมูลที่ระบบปัจจุบันปกป้องไว้ หรือที่เรียกว่า Q-Day

ความเสี่ยงไม่ได้อยู่เฉพาะในวันที่ควอนตัมคอมพิวเตอร์สามารถถอดรหัสได้จริง แต่เกิดขึ้นแล้วในรูปแบบ “Harvest now, decrypt later” หรือการดักเก็บข้อมูลวันนี้เพื่อรอถอดรหัสในอนาคต

โดยกลุ่มผู้ไม่หวังดีสามารถดักจับและเก็บข้อมูลการรับส่งภายในองค์กรที่ผ่านการเข้ารหัส รวมถึงทรัพย์สินทางปัญญาและบันทึกข้อมูลระบบ (Data Logs) เพื่อนำไปประมวลผลเมื่อฮาร์ดแวร์ควอนตัมมีความพร้อม

เจพี จุง จาก Red Hat ระบุว่า การมาถึงของควอนตัมคอมพิวเตอร์ที่มีศักยภาพสูงพอสำหรับการถอดรหัส กำลังเปลี่ยนจากความท้าทายทางคณิตศาสตร์เชิงทฤษฎีในอนาคต ไปสู่กรอบเวลาที่ทีมความปลอดภัยไซเบอร์ต้องเริ่มวางแผนรับมือตั้งแต่วันนี้

Post-Quantum Cryptography ไม่ใช่เรื่องของอนาคตอีกต่อไป

ความเร่งด่วนดังกล่าวสอดคล้องกับทิศทางด้านความมั่นคงปลอดภัยของสหรัฐ โดยคำสั่งบริหารหมายเลข 14412 ของทำเนียบขาวกำหนดให้หน่วยงานรัฐบาลกลางนำร่องย้ายระบบไปสู่ความพร้อมด้าน Post-Quantum Cryptography (PQC)ภายในปี 2027 และดำเนินการเต็มรูปแบบให้เสร็จสิ้นภายในปี 2029

ขณะที่ Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) ของสำนักงานความมั่นคงแห่งชาติสหรัฐ (NSA) กำหนดให้มีการใช้อัลกอริทึมความปลอดภัยยุคควอนตัมกับระบบความมั่นคงแห่งชาติ และการปรับใช้กับโปรโตคอล TLS เชิงพาณิชย์ต้องเป็นไปตามกรอบเวลาภายในปี 2030

ดังนั้น ประเด็นเชิงกลยุทธ์สำหรับองค์กรจึงไม่ได้อยู่ที่การคาดการณ์ว่าควอนตัมคอมพิวเตอร์ที่สามารถถอดรหัสได้จริงจะเกิดขึ้นภายในปี 2030 หรือไม่ แต่เป็นการประเมินว่าองค์กรมั่นใจได้อย่างไรว่า จะไม่เกิดขึ้น

Red Hat มองว่าองค์กรที่รอจนกว่าควอนตัมคอมพิวเตอร์จะปรากฏขึ้นแล้วจึงเริ่มย้ายระบบ อาจพบว่าตัวเองล้าหลังไป 3-5 ปี และข้อมูลสำคัญที่จัดเก็บไว้ก่อนหน้านั้นอาจถูกเปิดเผยไปแล้ว

4 ขั้นตอนเตรียมองค์กรรับมือ Q-Day

1. สำรวจ Cryptographic Footprint บนไฮบริดคลาวด์

จุดเริ่มต้นคือการทำความเข้าใจว่าองค์กรใช้การเข้ารหัสอยู่ที่ใดบ้าง เพราะระบบไฮบริดคลาวด์มีการเชื่อมต่อซอฟต์แวร์แบบอัตโนมัติจำนวนมากที่ยังพึ่งพาอัลกอริทึมความปลอดภัยแบบเดิม

ทีมความปลอดภัยจึงต้องสำรวจว่า ข้อมูลถูกเข้ารหัสที่ใด และกุญแจดิจิทัลถูกสร้างขึ้นที่ใด ในสภาพแวดล้อมแบบกระจายตัว รวมถึงจัดทำแผนผังสินทรัพย์ที่มีมูลค่าสูง เช่น AI Model Weights และบันทึกการฝึกอบรม

การสำรวจยังครอบคลุมแพลตฟอร์มซอฟต์แวร์หลัก เพื่อระบุมาตรฐานความปลอดภัยแบบเก่าหรือมาตรฐานที่ถูกเขียนฝังไว้ในโค้ด (Hardcoded) พร้อมสร้างการมองเห็นการสื่อสารภายในเครือข่ายในระดับโครงสร้างพื้นฐาน

2. ทดสอบ PQC ก่อนนำไปใช้งานจริง

การเปลี่ยนผ่านไปสู่ระบบความปลอดภัยที่ต้านทานควอนตัมไม่ได้มีเพียงโจทย์เรื่องความปลอดภัย แต่ต้องประเมินผลกระทบต่อประสิทธิภาพของระบบด้วย

องค์กรจึงควรทดสอบชุดคำสั่งทางคณิตศาสตร์ของการเข้ารหัสยุคใหม่ในสภาพแวดล้อมที่ไม่ได้ใช้งานจริง เพื่อประเมินผลต่อ ประสิทธิภาพของแอปพลิเคชัน เวลาในการตอบสนองของเครือข่าย และ Processing Overhead หรือทรัพยากรส่วนเกินที่ต้องใช้ในการประมวลผล

การทดสอบดังกล่าวช่วยให้องค์กรเห็นผลกระทบของการเปลี่ยนระบบความปลอดภัยก่อนนำไปใช้กับสภาพแวดล้อมจริง

3. ย้ายการรักษาความปลอดภัยจากแอปพลิเคชันสู่แพลตฟอร์ม

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

Red Hat เสนอให้มองความปลอดภัยในระดับแพลตฟอร์มมากขึ้น ประเด็นนี้มีความสำคัญต่อระบบ AI เนื่องจากข้อมูลที่ถูกส่งผ่านระบบในปัจจุบันไม่ได้มีเพียงข้อมูลทั่วไป แต่รวมถึงข้อมูลการฝึกสอนที่ส่งไปยัง GPU Cluster, Model Weights ที่ถูกคัดลอกข้ามไซต์ และข้อมูลรับรองรหัสผ่าน (Credentials) ที่ Agent แลกเปลี่ยนระหว่างการทำงาน

ข้อมูลเหล่านี้จึงอยู่ในขอบเขตความเสี่ยงของกลยุทธ์ Harvest now, decrypt later แล้ว แม้ในวันนี้ข้อมูลที่ถูกดักเก็บจะยังไม่สามารถถอดรหัสได้ก็ตาม

Red Hat มองว่าการรักษาความปลอดภัยยุคควอนตัมจึงเป็นโจทย์ที่เกี่ยวข้องโดยตรงกับการปกป้องสินทรัพย์ AI ระหว่างการรับส่งข้อมูล ตั้งแต่ข้อมูลที่ใช้ฝึกโมเดล Model Weights ไปจนถึงบันทึกการทำงานของ Agent

4. ควบคุมจุดจัดเก็บและการประมวลผลข้อมูล

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

การมอบอำนาจการควบคุมทางสถาปัตยกรรมให้กับระบบควบคุมศูนย์กลางของ Public Cloud อาจทำให้องค์กรต้องพึ่งพานโยบายบริหารจัดการและการตัดสินใจของแพลตฟอร์มที่องค์กรไม่ได้เป็นเจ้าของเอง

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

องค์กรยังสามารถใช้ร่วมกับโซลูชันความปลอดภัยระดับฮาร์ดแวร์ เช่น การรันคอนเทนเนอร์ในพื้นที่ประมวลผลที่มีการเข้ารหัสและได้รับการปกป้องในระดับฮาร์ดแวร์ หรือ Confidential Containers เพื่อปกป้องข้อมูลสำคัญระหว่างการประมวลผล

เริ่มจากรู้ว่าองค์กรเข้ารหัสอะไรไว้บ้าง

สำหรับองค์กรที่ต้องการเตรียมรับมือ Q-Day สิ่งที่สามารถเริ่มทำได้ทันทีคือการสำรวจ Cryptographic Footprint หรือร่องรอยการเข้ารหัสทั้งหมดขององค์กร

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

เพราะการเตรียมความพร้อมสำหรับยุคหลังควอนตัมไม่ได้เริ่มต้นในวันที่ Q-Day มาถึง แต่เริ่มจากการรู้ว่า วันนี้องค์กรมีอะไรที่ต้องปกป้อง และข้อมูลเหล่านั้นเดินทางผ่านระบบใดบ้าง