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
มาถึง แต่เริ่มจากการรู้ว่า วันนี้องค์กรมีอะไรที่ต้องปกป้อง
และข้อมูลเหล่านั้นเดินทางผ่านระบบใดบ้าง
ที่มา : กรุงเทพธุรกิจ
