รับมือ Q-day เตรียมพร้อมความปลอดภัยยุคควอนตัม / JP Jung

1. หน้าหลัก 
2. Cyber BIZ 
3. บทความไอที  

รับมือ Q-day เตรียมพร้อมความปลอดภัยยุคควอนตัม / JP Jung

เผยแพร่: 15 ส.ค. 2569 00:34   ปรับปรุง: 15 ส.ค. 2569 00:34   โดย: ผู้จัดการออนไลน์

เนื่องจากกลุ่มผู้ไม่หวังดีเริ่มดำเนินกิจกรรมในลักษณะดักเก็บข้อมูลวันนี้ เพื่อรอถอดรหัสในวันหน้า (harvest now, decrypt later) ซึ่งหมายความว่าพวกเขากำลังดักจับและกักเก็บข้อมูลการรับส่งภายในองค์กรที่ผ่านการเข้ารหัส ทรัพย์สินทางปัญญา และบันทึกข้อมูลระบบ (data logs) เอาไว้ตั้งแต่วันนี้ โดยมีเป้าหมายที่จะนำข้อมูลเหล่านี้ไปประมวลผลผ่านฮาร์ดแวร์ควอนตัมทันทีที่เทคโนโลยีพร้อมใช้งาน
เร้ดแฮทเชื่อว่าการรับมือกับภัยคุกคามนี้อย่างจริงจัง หมายถึงการลงมือทำก่อนที่วิกฤตจะมาถึง เร้ดแฮทกำลังเป็นผู้นำในการขับเคลื่อนเรื่องนี้อย่างจริงจัง ด้วยการฝังขีดความสามารถด้านความปลอดภัยยุคควอนตัม (quantum-safe) ลงในชั้นรากฐานของโครงสร้างพื้นฐานไฮบริดคลาวด์โดยตรง แนวทางนี้ช่วยให้องค์กรมีเครื่องมือที่จำเป็นในการปกป้องสินทรัพย์ดิจิทัลตั้งแต่วันนี้ ควบคู่ไปกับการเตรียมความพร้อมรับมือกับ Q-day ที่กำลังจะมาถึงในอนาคตอันใกล้
ความเร่งด่วนนี้ไม่ใช่เรื่องสมมติ ตามคำสั่งบริหารหมายเลข 14412 ของทำเนียบขาว กำหนดให้หน่วยงานรัฐบาลกลางต้องนำร่องย้ายระบบไปสู่ความพร้อมด้านการเข้ารหัสยุคหลังควอนตัม (PQC) ภายในปี 2027 และดำเนินการเต็มรูปแบบให้เสร็จสิ้นภายในปี 2029 ซึ่งสอดคล้องกับข้อกำหนด Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) ของสำนักงานความมั่นคงแห่งชาติ (NSA) ที่กำหนดใช้อัลกอริทึมความปลอดภัยยุคควอนตัมสำหรับระบบความมั่นคงแห่งชาติ โดยการปรับใช้กับโปรโตคอล TLS เชิงพาณิชย์จะต้องปฏิบัติตามกำหนดเวลาอย่างเข้มงวดภายในปี 2030

ปัจจุบัน เร้ดแฮทรับมือความท้าทายอันเร่งด่วนเหล่านี้ด้วยแนวทางการนำเสนอโซลูชันร่วมแบบรวมศูนย์ ซึ่งฝังความปลอดภัยยุคควอนตัมลงไปในระดับรากฐานของไฮบริดคลาวด์โดยตรง โดย Red Hat Enterprise Linux 10 (RHEL10) ถือเป็นระบบปฏิบัติการ Linux ระดับองค์กรรายแรกที่มาพร้อมอัลกอริทึมยุคหลังควอนตัม ที่ได้มาตรฐาน NIST รวมถึง ML-KEM และ ML-DSA ที่เปิดใช้งานโดยตรงในระดับระบบปฏิบัติการ
Red Hat OpenShift สร้างขึ้นบนรากฐานที่แข็งแกร่ง จึงส่งต่อขีดความสามารถเหล่านี้มาโดยตรง OpenShift ไม่ได้พยายามสร้างคลังซอฟต์แวร์ (ไลบรารี่) สำหรับการเข้ารหัส (cryptographic libraries) ขึ้นมาใหม่ตั้งแต่ต้น แต่เลือกวางตำแหน่งให้ RHEL เป็นกลไกพื้นฐาน ทำหน้าที่คำนวณด้านความปลอดภัยและการปฏิบัติตามกฎระเบียบ ซึ่ง OpenShift จะนำขีดความสามารถเหล่านั้นมาเปิดใช้งานจริงและขยายขีดความสามารถให้ครอบคลุมทั่วทั้งสภาพแวดล้อมแบบกระจายตัว (distributed environments)

***4 สิ่งสำคัญ รับมือ Q-Day
1 ใน 4 สิ่งที่องค์กรทำได้ทันทีคือสำรวจร่องรอยการเข้ารหัสที่แอบแฝงอยู่บนไฮบริดคลาวด์ทั้งหมด

องค์กรไม่สามารถปกป้องสิ่งที่มองไม่เห็นได้ และองค์กรส่วนใหญ่ใช้งานการเชื่อมต่อซอฟต์แวร์แบบอัตโนมัตินับล้านรายการที่ยังพึ่งพาอัลกอริทึมความปลอดภัยสาธารณะแบบเก่า ซึ่งสุ่มเสี่ยงต่อการถูกโจมตีด้วยควอนตัม ทีมงานที่ดูแลด้านความปลอดภัยจึงต้องมีความเข้าใจอย่างถ่องแท้ว่า ข้อมูลถูกเข้ารหัสไว้ที่ใดและกุญแจดิจิทัลถูกสร้างขึ้นที่ใดบ้างในสภาพแวดล้อมแบบกระจายตัว ซึ่งเป็นการเปลี่ยนจุดโฟกัสการทำงานไปที่การจัดทำแผนผังสินทรัพย์ที่มีมูลค่าสูง เช่น AI model weights และบันทึกการฝึกอบรม
นโยบายการเข้ารหัสเริ่มต้นที่เป็นมาตรฐานทั่วทั้งระบบใน Red Hat Enterprise Linux 10 ให้การตั้งค่าการเข้ารหัสยุคใหม่ โดยการเปิดใช้งานอัลกอริทึมขั้นสูงที่ต้านทานควอนตัม ผู้ดูแลระบบสามารถเปิดใช้งานการสื่อสารหลักทั้งหมดของโฮสต์ให้ใช้มาตรฐานความปลอดภัยยุคควอนตัมสำหรับการแคปซูลกุญแจ (key encapsulation) ได้ทันที ซึ่งเปิดโอกาสให้ทีมงานสามารถทดสอบประสิทธิภาพการทำงานของแอปพลิเคชันจริง ทรัพยากรส่วนเกินที่ใช้ในการประมวลผล (processing overhead) และลาเทนซีก่อนที่จะย้ายเวิร์กโหลดไปใช้งานจริง 
สิ่งที่ 2 คือทดสอบชุดคำสั่งทางคณิตศาสตร์ของการเข้ารหัสยุคใหม่ ในสภาพแวดล้อมที่ไม่ได้ใช้งานจริง

การเปลี่ยนผ่านไปสู่ระบบความปลอดภัยที่ต้านทานควอนตัม จำเป็นต้องมีการประเมินว่า วิธีการเข้ารหัสทางคณิตศาสตร์แบบใหม่ส่งผลกระทบต่อประสิทธิภาพโดยรวมของแอปพลิเคชัน เวลาในการตอบสนองของเครือข่าย และทรัพยากรส่วนเกินที่ใช้ในการประมวลผล (processing overhead) อย่างไร ทั้งนี้ โปรไฟล์นโยบายการเข้ารหัสที่ใช้กับระบบในวงกว้างของ RHEL 10 ซึ่งรวมถึงนโยบาย FUTURE ช่วยให้ผู้ดูแลระบบสามารถสับเปลี่ยนรูปแบบการเข้ารหัสของโฮสต์ทั้งหมดไปสู่มาตรฐานที่ต้านทานควอนตัมได้ด้วยคำสั่งเดียว
Red Hat OpenShift 4.22 ที่เปิดตัวล่าสุด มอบความสามารถในการแลกเปลี่ยนคีย์รหัสที่มีความปลอดภัยในยุคควอนตัม ในสถานะที่พร้อมให้ใช้งาน (generally available) การแลกเปลี่ยนคีย์รหัส ML-KEM hybrid key exchange จะถูกเปิดใช้งานเป็นค่าเริ่มต้น 
การที่ RHEL เป็นผู้ดูแลไลบรารี่ความปลอดภัยระดับล่าง (เช่น OpenSSL) จึงช่วยให้นักพัฒนาแอปพลิเคชันแต่ละคนไม่จำเป็นต้องเขียนโค้ดใหม่ หรือยุ่งยากกับการเลือกใช้อัลกอริทึมที่ซับซ้อนด้วยตนเอง การส่งต่อคุณสมบัติด้านความปลอดภัยครอบคลุมทั้งแพลตฟอร์มเช่นนี้ แตกต่างอย่างสิ้นเชิงกับแนวทางแบบเดิมที่กระจัดกระจายบนแพลตฟอร์มอื่น ๆ ที่พัฒนามาจาก Kubernetes ซึ่งยังขาดการเชื่อมต่อการเข้ารหัสยุค PQC ในระดับ control plane แบบ native, end-to-end และพร้อมใช้งานทันที 
สิ่งที่ 3 คือย้ายขอบเขตความปลอดภัยจากเลเยอร์แอปพลิเคชันไปสู่เลเยอร์แพลตฟอร์ม

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

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

เร้ดแฮทเชื่อว่าความปลอดภัยยุคควอนตัมเป็นสิ่งจำเป็นเร่งด่วนที่ต้องทำทันทีเพื่อปกป้องสินทรัพย์ AI ระหว่างการรับส่งข้อมูล แนวทางนี้เปลี่ยนมุมมองจากเดิมที่เคยมองว่าเป็นปัญหาด้านเบราว์เซอร์ในอนาคตในเชิงทฤษฎี ไปสู่มุมมองในการปกป้องข้อมูลที่ใช้ในการฝึกอบรมที่เป็นกรรมสิทธิ์ขององค์กร ปกป้อง model weights และบันทึกการทำงานของเอเจนต์ จากการถูกดักจับข้อมูลได้ในทันที ลูกค้าของเร้ดแฮทจะได้รับประโยชน์จากการสร้างเลเยอร์แพลตฟอร์มแอปพลิเคชันแบบรวมศูนย์ที่มีความยืดหยุ่นคล่องตัวด้านการเข้ารหัส ซึ่งสามารถจัดการขั้นตอนสร้างความเชื่อมต่อแบบปลอดภัยให้กับเวิร์กโหลดพื้นฐานได้โดยอัตโนมัติ

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

สิ่งที่ 4 คือควบคุมการทำงานของตำแหน่งจัดเก็บและการประมวลผลข้อมูลอย่างเบ็ดเสร็จ

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

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

องค์กรไม่จำเป็นต้องรอให้ถึง Q-day แล้วค่อยเริ่มเตรียมตัว แต่สามารถเริ่มต้นได้เลยด้วยการสำรวจระบบและโครงสร้างการเข้ารหัสทั้งหมดขององค์กร (cryptographic footprint) เพื่อให้ทราบว่า แอปพลิเคชันในปัจจุบันขององค์กร ใช้งานอัลกอริทึมใด ใช้คีย์ที่ใช้ในการเข้ารหัสข้อมูลที่มีขนาดหรือความยาวเท่าไร และโพรโทคอลรูปแบบใดบ้าง.