ความปลอดภัยของ GPU แบบ Multi-tenant: กลยุทธ์การแยกส่วนสำหรับโครงสร้างพื้นฐานที่ใช้ร่วมกัน

90% ขององค์กรกำลังนำ AI มาใช้งาน แต่มีเพียง 5% ที่รู้สึกมั่นใจในความพร้อมด้านความปลอดภัย 97% ขององค์กรที่ถูกโจมตีขาดการควบคุมการเข้าถึง AI ที่เหมาะสม NVIDIA เปิดเผยช่องโหว่ด้านความปลอดภัย 7 รายการ...

ความปลอดภัยของ GPU แบบ Multi-tenant: กลยุทธ์การแยกส่วนสำหรับโครงสร้างพื้นฐานที่ใช้ร่วมกัน

ความปลอดภัยของ GPU แบบ Multi-tenant: กลยุทธ์การแยกส่วนสำหรับโครงสร้างพื้นฐานที่ใช้ร่วมกัน

อัปเดตเมื่อวันที่ 11 ธันวาคม 2025

อัปเดตเดือนธันวาคม 2025: 90% ขององค์กรกำลังนำ AI มาใช้งาน แต่มีเพียง 5% ที่รู้สึกมั่นใจในความพร้อมด้านความปลอดภัย 97% ขององค์กรที่ถูกโจมตีขาดการควบคุมการเข้าถึง AI ที่เหมาะสม NVIDIA เปิดเผยช่องโหว่ด้านความปลอดภัย 7 รายการ (27 มกราคม 2025) รวมถึง CVE-2025-23266 ที่อนุญาตให้เข้าถึงระดับ root ผ่านการ bypass Container Toolkit ตลาดความปลอดภัยโครงสร้างพื้นฐาน AI ของสหรัฐฯ มีมูลค่าถึง 2.99 พันล้านดอลลาร์ (CAGR 22.8%)

เก้าสิบเปอร์เซ็นต์ขององค์กรนำระบบ AI มาใช้งาน แต่มีเพียง 5% ที่รู้สึกมั่นใจในความพร้อมด้านความปลอดภัย¹ องค์กรที่มีระบบรักษาความปลอดภัย AI แบบอัตโนมัติสามารถประหยัดค่าใช้จ่ายได้ 1.9 ล้านดอลลาร์ต่อการละเมิดหนึ่งครั้ง และลดระยะเวลาของเหตุการณ์ลง 80 วัน² ในขณะเดียวกัน 97% ขององค์กรที่ถูกโจมตีขาดการควบคุมการเข้าถึง AI ที่เหมาะสม³ เมื่อโครงสร้างพื้นฐาน GPU กลายเป็นรากฐานของ AI ระดับองค์กร โมเดลความปลอดภัยสำหรับทรัพยากร GPU ที่ใช้ร่วมกันจะเป็นตัวกำหนดว่าองค์กรสามารถรวม workload ได้อย่างปลอดภัย หรือต้องรักษาฮาร์ดแวร์เฉพาะที่มีราคาแพงสำหรับผู้เช่าแต่ละราย

ความท้าทายนี้ขยายไปไกลกว่าความปลอดภัยแบบ virtualization ทั่วไป GPU จัดการข้อมูลที่ละเอียดอ่อนรวมถึง model weights, ข้อมูลการฝึก และ inference inputs ที่เป็นทรัพย์สินทางปัญญาขององค์กร การละเมิดในระดับ GPU อาจทำให้ "สมอง" ของระบบ AI ถูกบุกรุก⁴ สภาพแวดล้อม GPU แบบ multi-tenant นำเสนอพื้นผิวการโจมตีที่แตกต่างอย่างสิ้นเชิงจาก virtualization บน CPU ซึ่งต้องการกลยุทธ์ความปลอดภัยที่ออกแบบมาโดยเฉพาะสำหรับสถาปัตยกรรม GPU

ภูมิทัศน์ความปลอดภัยของ GPU แบบ Multi-tenant

เมื่อวันที่ 27 มกราคม 2025 NVIDIA เปิดเผยช่องโหว่ด้านความปลอดภัยใหม่ 7 รายการที่ส่งผลกระทบต่อ GPU display drivers และซอฟต์แวร์ virtual GPU⁵ ข้อบกพร่องระดับวิกฤตเหล่านี้ส่งผลกระทบต่อระบบหลายล้านระบบตั้งแต่โครงสร้างพื้นฐาน AI ระดับองค์กรไปจนถึงแพลตฟอร์ม cloud computing ช่องโหว่ NVIDIA Container Toolkit CVE-2025-23266 อนุญาตให้ผู้ไม่หวังดี bypass กลไกการแยกส่วนและเข้าถึงระดับ root ของระบบ host⁶ การเปิดเผยนี้เน้นย้ำจุดอ่อนเชิงระบบใน GPU software stacks ที่องค์กรไม่สามารถเพิกเฉยได้

ตลาดความปลอดภัยโครงสร้างพื้นฐาน AI ของสหรัฐฯ มีมูลค่า 2.99 พันล้านดอลลาร์ และขยายตัวในอัตราการเติบโตแบบทบต้นต่อปี 22.8%⁷ การโจมตีที่ขับเคลื่อนด้วย AI คิดเป็น 16% ของการละเมิดทั้งหมดในปี 2025⁸ การลงทุนนี้สะท้อนถึงการยอมรับที่เพิ่มขึ้นว่าโครงสร้างพื้นฐาน GPU ต้องการความใส่ใจด้านความปลอดภัยเฉพาะทางนอกเหนือจากการป้องกัน data center ทั่วไป

ความปลอดภัยของ GPU แตกต่างจากความปลอดภัยของ CPU ในแง่พื้นฐาน GPU จัดการข้อมูลที่ละเอียดอ่อนอย่างมากชั่วคราวระหว่างการประมวลผล ต่างจาก CPU, GPU ไม่ได้มีการแยกหน่วยความจำที่แข็งแกร่งเสมอไป โดยเฉพาะในสภาพแวดล้อม multi-tenant⁹ หากหน่วยความจำไม่ถูกล้างอย่างเหมาะสมเมื่อ process สิ้นสุดลง ผู้โจมตีอาจดึงข้อมูลที่หลงเหลือจาก workload ของผู้ใช้รายอื่นได้¹⁰ สถาปัตยกรรมที่ใช้ร่วมกันของ GPU สมัยใหม่เปิดโอกาสให้เกิด contention-based side channels ซึ่งผู้โจมตีสามารถอนุมานข้อมูลที่ละเอียดอ่อน รบกวน workload ที่อยู่ร่วมกัน หรือสร้างช่องทางการสื่อสารลับ¹¹

การแยกส่วนระดับฮาร์ดแวร์ด้วย Multi-Instance GPU

เทคโนโลยี Multi-Instance GPU ของ NVIDIA ให้การแยกส่วนระดับฮาร์ดแวร์ที่ช่วยให้ multi-tenancy ปลอดภัยบนฮาร์ดแวร์ GPU มูลค่าสูง¹² เริ่มต้นจากสถาปัตยกรรม Ampere, MIG อนุญาตให้แบ่ง GPU เดียวออกเป็นสูงสุด 7 instances แยกกันสำหรับแอปพลิเคชัน CUDA¹³ GPU รุ่น Blackwell และ Hopper ขยายความสามารถของ MIG ด้วยการกำหนดค่า multi-tenant, multi-user ในสภาพแวดล้อมที่ virtualize โดยรักษาความปลอดภัยแต่ละ instance ด้วย confidential computing ในระดับฮาร์ดแวร์และ hypervisor¹⁴

สถาปัตยกรรมนี้ให้การแยกส่วนฮาร์ดแวร์ที่แท้จริง โปรเซสเซอร์ของ MIG partition แต่ละตัวมีเส้นทางที่แยกจากกันและถูกแยกส่วนผ่านระบบหน่วยความจำทั้งหมด¹⁵ on-chip crossbar ports, L2 cache banks, memory controllers และ DRAM address buses ได้รับการกำหนดให้เฉพาะกับ instances แต่ละตัว¹⁶ ผู้เช่ารายหนึ่งไม่สามารถอ่านหรือเขียนทับหน่วยความจำ GPU ของผู้เช่ารายอื่น การแยกส่วนความผิดพลาดป้องกันไม่ให้โค้ดที่ล่มของผู้ใช้รายหนึ่งส่งผลกระทบต่อ GPU ทั้งหมดหรือกระทบผู้อื่น¹⁷

MIG รองรับระบบปฏิบัติการ Linux, containerized workloads โดยใช้ Docker Engine, การจัดการด้วย Kubernetes และสภาพแวดล้อม virtualized ผ่าน hypervisors รวมถึง Red Hat Virtualization และ VMware vSphere¹⁸ การรองรับแพลตฟอร์มที่หลากหลายช่วยให้องค์กรสามารถนำการแยกส่วน GPU มาใช้ภายในโครงสร้างพื้นฐานที่มีอยู่โดยไม่ต้องเปลี่ยนสถาปัตยกรรมทั้งหมด

ข้อจำกัดของ MIG อยู่ที่ความละเอียด การแบ่ง 7 ส่วนเป็นการแบ่งย่อยสูงสุดบนฮาร์ดแวร์ปัจจุบัน องค์กรที่ต้องการการแบ่งปันที่ละเอียดกว่าหรือรองรับ GPU รุ่นเก่าต้องพิจารณาแนวทางอื่น

ทางเลือก vGPU และ Time-slicing

ซอฟต์แวร์ NVIDIA virtual GPU ช่วยให้ virtual machines หลายตัวที่มีการป้องกัน input-output memory management unit เต็มรูปแบบสามารถเข้าถึง GPU ทางกายภาพเดียวพร้อมกันได้¹⁹ นอกเหนือจากความปลอดภัย vGPU ยังเปิดใช้งานการจัดการ VM ด้วย live migration และความสามารถในการรัน VDI และ compute workloads แบบผสมผสาน²⁰ hypervisor ทำ virtualize GPU และกำหนด slices ให้กับ VMs หลายตัว โดยแต่ละ VM มองเห็นส่วนที่ virtualized ของ GPU สำหรับ workloads ของตน

Time-slicing ให้โมเดลการแบ่งปันที่แตกต่างออกไป ผู้ดูแลระบบกำหนดชุดของ replicas สำหรับ GPU แต่ละอันสามารถถูกแจกจ่ายอย่างเป็นอิสระให้กับ pod ที่รัน workloads ใน Kubernetes²¹ ต่างจาก MIG, time-slicing ไม่ได้ให้การแยกหน่วยความจำหรือความผิดพลาดระหว่าง replicas²² หาก task หนึ่งล่มหรือทำงานผิดปกติ อาจส่งผลกระทบต่อ task อื่นที่ใช้ GPU ร่วมกัน²³ การแลกเปลี่ยนเอื้อต่อการเข้าถึงมากกว่าการแยกส่วน: time-slicing ช่วยให้ผู้ใช้จำนวนมากขึ้นสามารถแบ่งปันได้ และให้การเข้าถึงสำหรับ GPU รุ่นเก่าที่ไม่รองรับ MIG²⁴

ผลกระทบด้านความปลอดภัยต้องมีความเข้าใจที่ชัดเจน Time-slicing ทำงานได้ดีสำหรับสภาพแวดล้อมการพัฒนา การทดสอบ และ workloads ที่ผู้เช่าเชื่อถือซึ่งกันและกัน หรือที่ความละเอียดอ่อนของข้อมูลไม่ต้องการการแยกส่วนระดับฮาร์ดแวร์ การ deploy ระดับ production ที่มีข้อกำหนดความปลอดภัย multi-tenant ควรเลือก MIG หรือ GPU เฉพาะมากกว่า time-slicing

แนวทางแบบ hybrid รวมทั้งสองเทคโนโลยีเข้าด้วยกัน องค์กรสามารถแบ่ง GPU ออกเป็น MIG instances ที่รับประกันการแยกส่วนของกลุ่ม จากนั้นรัน time-slicing schedulers ภายในแต่ละ instance²⁵ ใน Kubernetes clusters การจัดสรร MIG slice ต่อ namespace และ time-sharing jobs ภายในแต่ละ slice ช่วยสร้างสมดุลระหว่างความปลอดภัยกับประสิทธิภาพด้านต้นทุน²⁶

Confidential Computing บน GPU

NVIDIA H100 Tensor Core GPU นำ confidential computing มาสู่ GPU โดยใช้ trusted execution environment ที่ใช้ฮาร์ดแวร์เป็นฐานซึ่งยึดอยู่กับ on-die hardware root of trust²⁷ ก่อน H100 ฟีเจอร์ confidential computing มีอยู่เฉพาะใน CPU จาก AMD และ Intel²⁸ H100 ให้การปกป้องข้อมูลสำหรับ AI training และ inference workloads ที่เกี่ยวข้องกับข้อมูลที่ละเอียดอ่อน²⁹

สถาปัตยกรรมทางเทคนิคสร้างขึ้นบนความสามารถ CPU confidential virtual machine โซลูชัน GPU พึ่งพา confidential VM trusted execution environment ที่เปิดใช้งานโดย AMD SEV-SNP หรือ Intel TDX บน CPU³⁰ PCIe firewall บล็อกการเข้าถึง CPU ไปยัง registers ส่วนใหญ่และหน่วยความจำที่ได้รับการป้องกันของ GPU ทั้งหมด NVLink firewall บล็อกการเข้าถึง peer GPU ไปยังหน่วยความจำที่ได้รับการป้องกัน³¹ การสื่อสารระหว่าง CVM และ GPU ใช้การเข้ารหัส AES-GCM พร้อม session keys เพื่อป้องกันจากระบบ host³²

DMA engine ของ H100 รองรับการเข้ารหัส AES GCM 256 สำหรับการถ่ายโอนข้อมูลระหว่าง CPU และ GPU³³ GPU ในโหมด confidential computing บล็อกการเข้าถึงโดยตรงไปยังหน่วยความจำภายในและปิดใช้งาน performance counters ที่อาจเปิดให้มีการโจมตีแบบ side-channel³⁴ สถาปัตยกรรมพัฒนามาจากฟีเจอร์ความปลอดภัยก่อนหน้า: AES authentication บน firmware ตั้งแต่ Volta, encrypted firmware และ revocation ตั้งแต่ Turing และ Ampere และตอนนี้ full measured และ attested boot พร้อม hardware root of trust ใน Hopper³⁵

Microsoft Azure เสนอ confidential VMs พร้อม NVIDIA H100 GPUs ในรูปแบบ preview ช่วยให้สามารถ training, fine-tuning และ serving models เช่น Stable Diffusion และ large language models ด้วยการป้องกัน confidential computing³⁶ สถาปัตยกรรม Blackwell พัฒนา confidential AI ไปอีกขั้นด้วยประสิทธิภาพที่เกือบเท่ากันไม่ว่าจะรัน models แบบเข้ารหัสหรือไม่เข้ารหัส แม้แต่สำหรับ LLMs³⁷

ข้อพิจารณาความปลอดภัย Kubernetes GPU

การแยกส่วน Namespace ใน Kubernetes ไม่ได้ให้ความปลอดภัยเพียงพอสำหรับการ scheduling GPU แบบ multi-tenant³⁸ องค์กรที่รัน AI workloads บน bare metal Kubernetes พร้อม GPU ต้อง implement การควบคุมเพิ่มเติม NVIDIA GPU Operator เปิดใช้งานการกำหนดค่า time-slicing และ MIG แต่ความปลอดภัยขึ้นอยู่กับการกำหนดค่าและการ hardening ที่เหมาะสม

Security bulletin ของ NVIDIA Container Toolkit ในเดือนกันยายน 2024 กระตุ้นให้มีการอัปเกรดอย่างเร่งด่วน องค์กรควรรัน Container Toolkit v1.16.2 หรือสูงกว่า หรือ GPU Operator v24.6.2 หรือสูงกว่า³⁹ ช่องโหว่เหล่านี้แสดงให้เห็นว่าการโจมตีแบบ container escape สามารถทำลายการแยกส่วน GPU ได้แม้จะกำหนดค่าอย่างถูกต้องในระดับที่สูงกว่า

โซลูชันจากบุคคลที่สามตอบโจทย์ช่องว่างในการจัดการ GPU ของ Kubernetes ดั้งเดิม Volcano ให้ batch scheduler แบบ cloud-native พร้อมการควบคุมละเอียดเหนือ priorities และ fairness สำหรับ high-performance workloads⁴⁰ Run:ai ซึ่งปัจจุบันเป็นส่วนหนึ่งของ NVIDIA จัดการและเพิ่มประสิทธิภาพทรัพยากร GPU สำหรับ AI workloads ด้วยฟีเจอร์ที่ออกแบบมาสำหรับสภาพแวดล้อม multi-tenant⁴¹ vCluster Labs ประกาศ Infrastructure Tenancy Platform สำหรับ AI ที่ KubeCon North America 2025 โดยมอบรากฐาน Kubernetes-native สำหรับโครงสร้างพื้นฐาน NVIDIA GPU⁴²

องค์กรที่ใช้ vCluster รายงานว่ามีการปรับปรุงการใช้งาน GPU 40% และลดต้นทุนโครงสร้างพื้นฐาน 60% ผ่านการ orchestration multi-tenant แบบไดนามิก⁴³ การเพิ่มประสิทธิภาพแสดงให้เห็นว่าสถาปัตยกรรม multi-tenant ที่เหมาะสมสามารถปรับปรุงทั้งความปลอดภัยและเศรษฐศาสตร์เมื่อเทียบกับการจัดสรร GPU แบบเฉพาะ

การโจมตี Side-channel และภัยคุกคามที่เกิดขึ้นใหม่

การโจมตีหน่วยความจำ GPU ใช้ประโยชน์จากสถาปัตยกรรมที่ใช้ร่วมกันในสภาพแวดล้อม multi-tenant เพื่อละเมิดความลับของข้อมูลและลดประสิทธิภาพ⁴⁴ ผู้โจมตีที่ใช้ contention-based side channels สามารถอนุมานข้อมูลที่ละเอียดอ่อนจาก workloads ที่อยู่ร่วมกัน⁴⁵ GPU Memory Attacks กำหนดเป้าหมายหน่วยความจำที่ใช้ร่วมกันเพื่ออำนวยความสะดวกให้กับการรั่วไหลของข้อมูลและช่องทางลับระหว่างผู้เช่า⁴⁶

การโจมตีฮาร์ดแวร์แบบ Rowhammer ซึ่งก่อนหน้านี้ทราบว่าส่งผลกระทบต่อหน่วยความจำ CPU ได้บุกรุก GPU ที่มีหน่วยความจำ GDDR และทำให้ความแม่นยำของ AI model ลดลงอย่างรุนแรง⁴⁷ การโจมตีใช้ประโยชน์จาก GPU parallelism เพื่อกระตุ้น bit flips ซึ่งเป็นความเสี่ยงเฉพาะในสภาพแวดล้อม cloud ที่ผู้โจมตีอาจอยู่ร่วมกับ workloads เป้าหมาย⁴⁸

ความเสี่ยงหลักในสภาพแวดล้อม GPU ที่ virtualized ยังคงเป็นการโจมตีข้าม virtual machines⁴⁹ ผู้เช่าหลายรายที่รัน workloads บน GPU ทางกายภาพเดียวกันสร้างโอกาสให้ข้อบกพร่องของกลไกการแยกส่วนเปิดให้มีการสอดแนม สิ่งนี้ทำลายโมเดลความปลอดภัย cloud โดยพื้นฐานและก่อให้เกิดความเสี่ยงร้ายแรงต่อความลับของข้อมูล⁵⁰

กลยุทธ์การบรรเทาผลกระทบรวมถึงการแยกส่วน workload ที่แข็งแกร่งซึ่งหลีกเลี่ยงการรัน workloads ที่ละเอียดอ่อนและไม่ละเอียดอ่อนบน GPU เดียวกัน, การแบ่ง cache เพื่อลดการเปิดเผย shared cache และการ scheduling แบบสุ่มเพื่อทำให้การโจมตีแบบ timing ซับซ้อนขึ้น⁵¹ Single Root I/O Virtualization หรือเทคโนโลยี virtualization ที่เสริมความปลอดภัยที่คล้ายกันให้การป้องกันเพิ่มเติม⁵² Confidential GPUs แสดงถึงแนวหน้าถัดไป โดยขยายการป้องกันแบบ TEE ไปยังหน่วยความจำ GPU และ execution flows⁵³

แนวปฏิบัติที่ดีที่สุดด้านความปลอดภัยระดับองค์กร

องค์กรที่ deploy โครงสร้างพื้นฐาน GPU ที่ใช้ร่วมกันควร implement การควบคุมความปลอดภัยที่เหมาะสมกับระดับความเสี่ยงที่ยอมรับได้และข้อกำหนดด้านกฎระเบียบ

สำหรับ workloads ที่ละเอียดอ่อน ตัวเลือก single-tenant ที่ GPU ไม่ถูกแบ่งปันช่วยลดความเสี่ยงของการโจมตี side-channel และสอดคล้องกับข้อกำหนดการปฏิบัติตาม⁵⁴ การรับรองบางอย่างต้องการฮาร์ดแวร์เฉพาะสำหรับข้อมูลบางประเภท⁵⁵ ต้นทุนที่เพิ่มขึ้นสำหรับ GPU เฉพาะอาจสมเหตุสมผลจากข้อกำหนดด้านความปลอดภัย

ความปลอดภัยของ driver และ firmware ต้องการการอัปเดตอย่างสม่ำเสมอด้วย security patches ล่าสุด⁵⁶ NVIDIA แนะนำให้อัปเดต firmware รายไตรมาสและตรวจสอบ driver ระหว่าง scheduled maintenance windows⁵⁷ การเปิดเผยช่องโหว่ในเดือนมกราคม 2025 แสดงให้เห็นถึงความสำคัญของการ patching อย่างทันท่วงที

สุขอนามัยหน่วยความจำระหว่าง sessions ป้องกันการรั่วไหลของข้อมูล การ zeroing หน่วยความจำ GPU ระหว่าง sessions ขจัดการโจมตีประเภทสำคัญโดยมีผลกระทบต่อประสิทธิภาพน้อยที่สุด

ขอใบเสนอราคา_

แจ้งรายละเอียดโครงการของคุณ เราจะตอบกลับภายใน 72 ชั่วโมง

> TRANSMISSION_COMPLETE

ได้รับคำขอแล้ว_

ขอบคุณสำหรับคำสอบถาม ทีมงานจะตรวจสอบคำขอและติดต่อกลับภายใน 72 ชั่วโมง

QUEUED FOR PROCESSING