Sécurité GPU multi-locataire : stratégies d'isolation pour les infrastructures partagées

Mis à jour le 11 décembre 2025

Mise à jour de décembre 2025 : 90 % des organisations déploient l'IA, mais seulement 5 % se sentent confiantes dans leur préparation en matière de sécurité. 97 % des organisations victimes de violations manquaient de contrôles d'accès IA appropriés. NVIDIA a divulgué sept vulnérabilités de sécurité (27 janvier 2025), dont CVE-2025-23266 permettant un accès root via le contournement du Container Toolkit. Le marché américain de la sécurité des infrastructures IA atteint 2,99 milliards de dollars (TCAC de 22,8 %).

Quatre-vingt-dix pour cent des organisations déploient des systèmes d'IA, mais seulement 5 % se sentent confiantes dans leur préparation en matière de sécurité.¹ Les organisations disposant d'une automatisation de sécurité spécifique à l'IA réalisent des économies de 1,9 million de dollars par violation et réduisent les cycles de vie des incidents de 80 jours.² Pendant ce temps, 97 % des organisations victimes de violations manquaient de contrôles d'accès IA appropriés.³ Alors que l'infrastructure GPU devient le fondement de l'IA d'entreprise, le modèle de sécurité des ressources GPU partagées détermine si les organisations peuvent consolider leurs charges de travail en toute sécurité ou doivent maintenir du matériel dédié coûteux pour chaque locataire.

Le défi va au-delà de la sécurité de virtualisation traditionnelle. Les GPU traitent des données sensibles, notamment les poids des modèles, les données d'entraînement et les entrées d'inférence qui représentent la propriété intellectuelle de l'organisation. Une violation au niveau du GPU pourrait compromettre le « cerveau » d'un système d'IA.⁴ Les environnements GPU multi-locataires introduisent des surfaces d'attaque qui diffèrent fondamentalement de la virtualisation basée sur CPU, nécessitant des stratégies de sécurité conçues spécifiquement pour les architectures GPU.

Le paysage de la sécurité GPU multi-locataire

Le 27 janvier 2025, NVIDIA a divulgué sept nouvelles vulnérabilités de sécurité affectant les pilotes d'affichage GPU et le logiciel GPU virtuel.⁵ Ces failles critiques impactent des millions de systèmes, de l'infrastructure IA d'entreprise aux plateformes de cloud computing. La vulnérabilité CVE-2025-23266 du NVIDIA Container Toolkit permettait à des acteurs malveillants de contourner les mécanismes d'isolation et d'obtenir un accès root aux systèmes hôtes.⁶ Cette divulgation a mis en évidence des faiblesses systémiques dans les piles logicielles GPU que les organisations ne peuvent ignorer.

Le marché américain de la sécurité des infrastructures IA a atteint 2,99 milliards de dollars et croît à un taux de croissance annuel composé de 22,8 %.⁷ Les attaques alimentées par l'IA représentaient 16 % de toutes les violations en 2025.⁸ Cet investissement reflète la reconnaissance croissante que l'infrastructure GPU nécessite une attention sécuritaire dédiée au-delà des protections générales des centres de données.

La sécurité GPU diffère de la sécurité CPU de manière fondamentale. Les GPU traitent temporairement des données incroyablement sensibles pendant le traitement. Contrairement aux CPU, les GPU n'ont pas toujours une isolation mémoire robuste, en particulier dans les environnements multi-locataires.⁹ Si la mémoire ne s'efface pas correctement à la fin d'un processus, un attaquant pourrait récupérer des données résiduelles de la charge de travail d'un autre utilisateur.¹⁰ L'architecture partagée des GPU modernes permet des canaux auxiliaires basés sur la contention par lesquels les attaquants peuvent déduire des informations sensibles, perturber les charges de travail colocalisées ou établir des canaux de communication secrets.¹¹

Isolation matérielle avec Multi-Instance GPU

La technologie Multi-Instance GPU de NVIDIA fournit une isolation au niveau matériel qui permet une multi-location sécurisée sur du matériel GPU de haute valeur.¹² À partir de l'architecture Ampere, MIG permet de partitionner un seul GPU en jusqu'à sept instances séparées pour les applications CUDA.¹³ Les GPU Blackwell et Hopper étendent les capacités MIG avec des configurations multi-locataires et multi-utilisateurs dans des environnements virtualisés, sécurisant chaque instance avec le calcul confidentiel au niveau matériel et hyperviseur.¹⁴

L'architecture fournit une véritable séparation matérielle. Les processeurs de chaque partition MIG ont des chemins séparés et isolés à travers l'ensemble du système mémoire.¹⁵ Les ports du crossbar sur puce, les banques de cache L2, les contrôleurs mémoire et les bus d'adresses DRAM reçoivent une attribution unique aux instances individuelles.¹⁶ Un locataire ne peut pas lire ou écraser la mémoire GPU d'un autre locataire. L'isolation des pannes empêche le code planté d'un utilisateur d'affecter l'ensemble du GPU ou d'impacter les autres.¹⁷

MIG prend en charge les systèmes d'exploitation Linux, les charges de travail conteneurisées utilisant Docker Engine, l'orchestration avec Kubernetes et les environnements virtualisés via des hyperviseurs, notamment Red Hat Virtualization et VMware vSphere.¹⁸ Le large support de plateformes permet aux organisations d'implémenter l'isolation GPU au sein de l'infrastructure existante sans changements d'architecture de grande envergure.

La limitation de MIG réside dans la granularité. Une partition en 7 représente la subdivision maximale sur le matériel actuel. Les organisations nécessitant un partage plus fin ou prenant en charge des générations de GPU plus anciennes doivent envisager des approches alternatives.

Alternatives vGPU et time-slicing

Le logiciel GPU virtuel NVIDIA permet à plusieurs machines virtuelles avec protection complète de l'unité de gestion mémoire d'entrée-sortie d'accéder simultanément à un seul GPU physique.¹⁹ Au-delà de la sécurité, vGPU permet la gestion des VM avec migration à chaud et la capacité d'exécuter des charges de travail VDI et de calcul mixtes.²⁰ L'hyperviseur virtualise le GPU et attribue des tranches à plusieurs VM, chaque VM percevant une portion virtualisée du GPU pour ses charges de travail.

Le time-slicing fournit un modèle de partage différent. Un administrateur système définit un ensemble de répliques pour un GPU, chacune pouvant être distribuée indépendamment à un pod exécutant des charges de travail dans Kubernetes.²¹ Contrairement à MIG, le time-slicing ne fournit pas d'isolation mémoire ou de pannes entre les répliques.²² Si une tâche plante ou se comporte mal, elle peut affecter les autres partageant le GPU.²³ Le compromis favorise l'accès plutôt que l'isolation : le time-slicing permet le partage par un plus grand nombre d'utilisateurs et fournit un accès aux générations de GPU plus anciennes qui ne prennent pas en charge MIG.²⁴

Les implications de sécurité nécessitent une compréhension claire. Le time-slicing fonctionne pour les environnements de développement, les tests et les charges de travail où les locataires se font confiance ou où la sensibilité des données ne justifie pas l'isolation matérielle. Les déploiements de production avec des exigences de sécurité multi-locataires devraient préférer MIG ou des GPU dédiés au time-slicing.

Les approches hybrides combinent les deux technologies. Les organisations peuvent partitionner un GPU en instances MIG qui assurent l'isolation des groupes, puis exécuter des planificateurs de time-slicing au sein de chaque instance.²⁵ Dans les clusters Kubernetes, l'allocation d'une tranche MIG par namespace et le partage temporel des tâches au sein de chaque tranche équilibrent la sécurité avec l'efficacité des coûts.²⁶

Calcul confidentiel sur GPU

Le GPU NVIDIA H100 Tensor Core a introduit le calcul confidentiel sur les GPU, utilisant un environnement d'exécution de confiance basé sur le matériel ancré dans une racine de confiance matérielle sur puce.²⁷ Avant le H100, les fonctionnalités de calcul confidentiel n'existaient que dans les CPU d'AMD et Intel.²⁸ Le H100 fournit une protection des données pour les charges de travail d'entraînement et d'inférence IA impliquant des informations sensibles.²⁹

L'architecture technique s'appuie sur les capacités de machine virtuelle confidentielle du CPU. La solution GPU repose sur un environnement d'exécution de confiance de VM confidentielle activé par AMD SEV-SNP ou Intel TDX sur le CPU.³⁰ Le pare-feu PCIe bloque l'accès CPU à la plupart des registres et à toute la mémoire protégée du GPU. Le pare-feu NVLink bloque l'accès des GPU pairs à la mémoire protégée.³¹ La communication entre CVM et GPU utilise le chiffrement AES-GCM avec des clés de session pour se protéger contre le système hôte.³²

Le moteur DMA du H100 prend en charge le chiffrement AES GCM 256 pour les transferts de données entre CPU et GPU.³³ Un GPU en mode calcul confidentiel bloque l'accès direct à la mémoire interne et désactive les compteurs de performance qui pourraient permettre des attaques par canal auxiliaire.³⁴ L'architecture a évolué à partir de fonctionnalités de sécurité antérieures : authentification AES sur le firmware depuis Volta, firmware chiffré et révocation depuis Turing et Ampere, et maintenant un démarrage mesuré et attesté complet avec racine de confiance matérielle dans Hopper.³⁵

Microsoft Azure propose des VM confidentielles avec GPU NVIDIA H100 en préversion, permettant l'entraînement, l'affinage et le service de modèles comme Stable Diffusion et les grands modèles de langage avec des protections de calcul confidentiel.³⁶ L'architecture Blackwell fait progresser davantage l'IA confidentielle avec des performances quasi identiques, que les modèles soient exécutés chiffrés ou non, même pour les LLM.³⁷

Considérations de sécurité GPU Kubernetes

L'isolation des namespaces dans Kubernetes ne fournit pas une sécurité suffisante pour la planification GPU multi-locataire.³⁸ Les organisations exécutant des charges de travail IA sur Kubernetes bare metal avec des GPU doivent implémenter des contrôles supplémentaires. Le NVIDIA GPU Operator permet la configuration du time-slicing et de MIG, mais la sécurité dépend d'une configuration et d'un renforcement appropriés.

Le bulletin de sécurité du NVIDIA Container Toolkit de septembre 2024 a incité à des mises à niveau urgentes. Les organisations devraient exécuter Container Toolkit v1.16.2 ou supérieur, ou GPU Operator v24.6.2 ou supérieur.³⁹ Les vulnérabilités ont démontré que les attaques d'évasion de conteneur pouvaient compromettre l'isolation GPU même lorsqu'elle est correctement configurée aux niveaux supérieurs.

Les solutions tierces comblent les lacunes de la gestion GPU native de Kubernetes. Volcano fournit un planificateur de lots cloud-native avec un contrôle fin des priorités et de l'équité pour les charges de travail haute performance.⁴⁰ Run:ai, désormais partie de NVIDIA, gère et optimise les ressources GPU pour les charges de travail IA avec des fonctionnalités conçues pour les environnements multi-locataires.⁴¹ vCluster Labs a annoncé sa plateforme d'hébergement d'infrastructure pour l'IA à KubeCon North America 2025, offrant des fondations Kubernetes-natives pour l'infrastructure GPU NVIDIA.⁴²

Les organisations utilisant vCluster rapportent une amélioration de 40 % de l'utilisation GPU et une réduction de 60 % des coûts d'infrastructure grâce à l'orchestration dynamique multi-locataire.⁴³ Les gains d'efficacité démontrent que des architectures multi-locataires appropriées peuvent améliorer à la fois la sécurité et l'économie par rapport aux allocations GPU dédiées.

Attaques par canal auxiliaire et menaces émergentes

Les attaques mémoire GPU exploitent l'architecture partagée dans les environnements multi-locataires pour violer la confidentialité des données et dégrader les performances.⁴⁴ Les attaquants utilisant des canaux auxiliaires basés sur la contention peuvent déduire des informations sensibles des charges de travail colocalisées.⁴⁵ Les attaques mémoire GPU ciblent la mémoire partagée pour faciliter les fuites d'informations et les canaux secrets entre locataires.⁴⁶

Une attaque matérielle Rowhammer, précédemment connue pour affecter la mémoire CPU, compromet les GPU avec mémoire GDDR et cause une perte sévère de précision des modèles IA.⁴⁷ L'attaque exploite le parallélisme GPU pour induire des inversions de bits, posant des risques particuliers dans les environnements cloud où les attaquants peuvent se colocaliser avec les charges de travail cibles.⁴⁸

Le risque principal dans les environnements GPU virtualisés reste les attaques inter-machines virtuelles.⁴⁹ Plusieurs locataires exécutant des charges de travail sur le même GPU physique créent des opportunités pour que les failles des mécanismes d'isolation permettent l'espionnage. Cela brise fondamentalement le modèle de sécurité cloud et pose des risques sérieux pour la confidentialité des données.⁵⁰

Les stratégies d'atténuation incluent une isolation forte des charges de travail qui évite d'exécuter des charges de travail sensibles et non sensibles sur le même GPU, le partitionnement du cache pour réduire l'exposition au cache partagé, et la planification aléatoire pour compliquer les attaques basées sur le timing.⁵¹ Les technologies de virtualisation améliorées pour la sécurité comme Single Root I/O Virtualization fournissent une protection supplémentaire.⁵² Les GPU confidentiels représentent la prochaine frontière, étendant les protections de type TEE à la mémoire GPU et aux flux d'exécution.⁵³

Meilleures pratiques de sécurité en entreprise

Les organisations déployant une infrastructure GPU partagée devraient implémenter des contrôles de sécurité appropriés à leur tolérance au risque et à leurs exigences réglementaires.

Pour les charges de travail sensibles, les options mono-locataire où les GPU ne sont pas partagés réduisent le risque d'attaques par canal auxiliaire et s'alignent sur les exigences de conformité.⁵⁴ Certaines certifications exigent du matériel dédié pour certains types de données.⁵⁵ La prime de coût pour les GPU dédiés peut être justifiée par les exigences de sécurité.

La sécurité des pilotes et du firmware nécessite des mises à jour cohérentes avec les correctifs de sécurité les plus récents.⁵⁶ NVIDIA recommande des mises à jour trimestrielles du firmware et des validations des pilotes pendant les fenêtres de maintenance planifiées.⁵⁷ La divulgation de vulnérabilités de janvier 2025 démontre l'importance d'un correctif rapide.

L'hygiène mémoire entre les sessions empêche les fuites de données. Mettre à zéro la mémoire GPU entre les sessions élimine une classe majeure d'attaques avec un impact minimal sur les performances.