Comment sécuriser votre jeu de données sur un nœud GPU loué ou public

Quand vous louez un GPU, quelqu’un d’autre a les droits root sur la machine qui contient vos données. Le chiffrement protège le jeu de données pendant le transfert et sur le disque, mais votre tâche d’entraînement doit le déchiffrer en mémoire pour s’en servir, et à ce moment-là un hôte déterminé peut le lire. Les vraies décisions sont donc : à qui vous faites confiance (un data center contrôlé ou un serveur anonyme chez un particulier), combien de données vous envoyez, et si vous avez besoin du confidential computing, seule option qui sort l’exploitant de l’hôte de la chaîne de confiance.

Ce guide concerne les machines sur lesquelles vous vous connectez, comme les instances Vast.ai ou RunPod. Il passe en revue le modèle de menace, ce que couvre chaque protection, et une routine de nettoyage qui tient sur le stockage moderne. Les sources sont en fin d’article ; tout a été vérifié en septembre 2026.

Le modèle de menace

Commencez par nommer qui pourrait accéder aux données, et comment. Sur une instance GPU louée, il y a sept voies réalistes.

L’exploitant de l’hôte. Celui qui possède la machine physique en a les droits root. Sur une place de marché à conteneurs comme Vast.ai, les clients tournent dans des conteneurs Docker non privilégiés, ce qui vous isole des autres locataires, mais pas de l’hôte : root sur l’hôte peut lire les fichiers et la mémoire d’un conteneur. C’est ainsi que fonctionnent les conteneurs sur toutes les plateformes.

Le trajet réseau. Les données qui voyagent de votre portable ou de votre bucket jusqu’au nœud. C’est la voie la plus facile à fermer.

La place de marché. L’entreprise qui se trouve entre vous et l’hôte détient votre compte, vos clés SSH et ce que conservent ses propres logs. Ce qu’elle a le droit d’en faire est fixé par ses conditions, d’où l’importance de la section sur les contrats plus bas.

Les restes sur le disque. Les fichiers que vous supprimez peuvent survivre sur le disque après votre location, où le locataire suivant ou l’hôte pourrait les retrouver.

Les snapshots et volumes persistants. Les copies que vous avez demandées (un volume réseau, une instance arrêtée) ou que l’hôte a faites (sauvegardes) survivent à la tâche.

Les autres locataires. Les autres clients sur la même machine. Avec une isolation par VM ou une machine entière pour vous, le risque est faible, mais les GPU ont connu de vrais bugs à ce niveau. LeftoverLocals (CVE-2023-4969) permettait à un processus de lire la mémoire locale GPU d’un autre sur certains GPU Apple, AMD et Qualcomm ; Trail of Bits a récupéré environ 181 Mo par requête LLM sur une AMD Radeon RX 7900 XT, de quoi reconstruire la réponse du modèle. Trail of Bits n’en a trouvé aucune trace sur les GPU NVIDIA, ARM ou Intel.

Vos propres oublis. Un token Hugging Face, des clés cloud ou une clé privée SSH laissés sur le nœud. En pratique, c’est ainsi que commencent la plupart des fuites.

Ce que couvre le chiffrement, et ce qu’il ne peut pas couvrir

Le chiffrement a trois rôles, et un GPU loué vous permet d’en assurer deux vous-même.

En transit : facile. Utilisez SSH (scp, sftp, rsync -e ssh) ou HTTPS depuis un bucket. Vast.ai indique que les connexions SSH et son API sont chiffrées. N’utilisez jamais de liens HTTP simples ni de services de partage de fichiers sans authentification.

Au repos : chiffrez avant l’envoi, pour que le fichier sur le disque de l’hôte soit inutilisable sans la clé. age est l’outil le plus simple pour cela :

# on your own machine
tar -cf - train/ | age -p > train.tar.age
scp -P 22345 train.tar.age [email protected]:/workspace/

Sur le nœud, déchiffrez directement en mémoire pour que le texte en clair ne touche jamais le disque :

mkdir -p /dev/shm/train
age -d /workspace/train.tar.age | tar -xf - -C /dev/shm/train

age -d demande la phrase de passe dans le terminal : la clé n’est jamais écrite sur le nœud. /dev/shm est un système de fichiers en RAM ; vérifiez d’abord sa taille avec df -h /dev/shm, car les configurations de conteneur le rendent souvent petit. Si les données ne tiennent pas en RAM, il vous faudra une copie déchiffrée sur disque, et la section sur le nettoyage prend alors plus d’importance.

Le chiffrement complet du disque avec LUKS est la réponse habituelle sur vos propres serveurs, mais vous ne pouvez généralement pas configurer dm-crypt dans un conteneur non privilégié, et l’hôte détiendrait de toute façon la clé en cours d’utilisation.

En cours d’utilisation : c’est là que se trouve le trou. Pour entraîner, le GPU a besoin de tenseurs en clair, et la mémoire CPU qui l’alimente contient elle aussi du clair. Quiconque a les droits root sur l’hôte peut en principe vider cette mémoire. Le chiffrement au repos ne sert à rien face à un hôte hostile et actif. Seul le confidential computing matériel répond à ce problème.

Secure cloud ou community cloud

Comme l’hôte est le seul risque que l’hygiène ne peut pas supprimer, le choix de l’hôte est la décision la plus importante. Les deux grandes places de marché séparent leur offre pour cette raison.

Option	Qui exploite le matériel	Ce que dit la plateforme
RunPod Secure Cloud	Data centers T3/T4	Pour « la production, les données sensibles »
RunPod Community Cloud	Fournisseurs de pair à pair	Pour « les charges de travail sensibles au coût » ; plus de nouveaux hôtes acceptés
Vast.ai Secure Cloud	Data centers contrôlés	ISO 27001, normes Tier 3/4, sécurité physique vérifiée
Autres hôtes Vast.ai	Du data center au particulier	Les hôtes individuels « peuvent avoir des mesures de sécurité moins formalisées »

Pour les données sensibles, Vast.ai conseille lui-même de n’utiliser que des fournisseurs Secure Cloud, de chiffrer les données au repos, de ne pas laisser d’identifiants sur les instances et d’utiliser une gestion de clés externe. C’est ce que je dirais à n’importe qui.

Deux limites s’appliquent même dans un data center certifié. D’abord, ISO 27001 certifie les processus de l’exploitant ; elle ne peut pas exclure un employé malhonnête. Ensuite, un hôte qui traite des données personnelles pour vous est un sous-traitant au sens du RGPD, et l’article 28 exige un contrat qui encadre ce traitement, alors que la place de marché se trouve entre vous et l’hôte. Vérifiez avec quelle société vous contractez réellement et ce qu’elle garantit sur ses hôtes.

Pour un travail vraiment sensible, l’étape suivante est une instance GPU dans un compte hyperscaler avec lequel vous avez déjà un DPA, voire un BAA : vous sortez alors du monde des places de marché, et l’heure coûte plus cher. Notre comparatif des prix de location de GPU donne les fourchettes de prix.

Le confidential computing sur GPU H100

Le confidential computing (CC) est la seule technologie présentée ici conçue pour protéger les données de l’exploitant de l’hôte pendant que la tâche tourne. Sur les GPU de data center NVIDIA Hopper et Blackwell, cela fonctionne ainsi :

• La charge de travail tourne dans une VM confidentielle (CVM) reposant sur AMD SEV-SNP ou Intel TDX côté CPU. La conception de NVIDIA part du principe que l’hyperviseur et l’OS de l’hôte peuvent être compromis ; un exploitant ayant accès à l’hyperviseur « voire au système lui-même » ne doit pas pouvoir lire la mémoire de la CVM.
• Avant utilisation, la VM vérifie que le GPU est authentique et en mode CC grâce à un certificat d’appareil signé, vérifiable auprès du service d’attestation à distance de NVIDIA (NRAS).
• Les données, les tampons de commandes et les noyaux CUDA qui traversent le PCIe sont chiffrés et signés, et passent par un tampon intermédiaire chiffré en mémoire partagée.

NVIDIA a rendu le CC mono-GPU sur H100 généralement disponible avec CUDA 12.4 en avril 2024. Où le louer concrètement en septembre 2026 :

Cloud	Instance	GPU	TEE côté CPU
Azure	NCCads H100 v5	1 × H100 NVL, 94 Go	AMD SEV-SNP (EPYC Genoa)
Google Cloud	a3-highgpu-1g, Confidential VM	1 × H100	Intel TDX
Google Cloud	g4-standard-48, Confidential VM	RTX PRO 6000	AMD SEV

Connaissez les limites avant de bâtir dessus :

• Un GPU par VM. La série Azure a un seul GPU, et les VM GPU confidentielles de Google ne prennent pas en charge les clusters multi-nœuds. Les gros entraînements multi-GPU sont exclus.
• Le provisionnement. Sur Google Cloud, l’A3 High confidentielle ne tourne qu’en Spot ou en flex-start et ne prend pas en charge les réservations.
• La vitesse de transfert. L’article technique de NVIDIA de 2023 situait la bande passante CPU vers GPU en mode CC autour de 4 Go/s, limitée par le chiffrement côté CPU. Charger un checkpoint de 16 Go prend donc environ 16 ÷ 4 = 4 secondes de transfert pur, ce qui convient à l’inférence, mais un pipeline de données qui fait transiter de nombreux gigaoctets à chaque pas le sentira. Les versions ultérieures du pilote mentionnent des améliorations de performances : mesurez votre propre tâche.
• La mémoire GPU n’est pas chiffrée. NVIDIA laisse la HBM intégrée au boîtier en clair, en considérant que les outils d’attaque physique courants ne peuvent pas l’atteindre.
• Pas sur les places de marché. Les cartes GeForce grand public, courantes chez les hôtes communautaires de Vast.ai et RunPod, ne figurent dans aucune de ces listes.

Le CC change la personne à qui vous devez faire confiance : le matériel et l’attestation de NVIDIA, le fabricant du CPU et votre propre image de VM, au lieu du personnel de l’hôte. Pour des données réglementées où la réponse « les administrateurs du fournisseur cloud ne peuvent pas les lire » compte, c’est la seule option sur du matériel loué qui y parvient.

Avant et pendant la tâche

Réduire avant d’envoyer

La protection la moins chère, ce sont les données qui ne quittent jamais votre machine. Avant le transfert :

• Supprimez les colonnes dont le modèle n’a pas besoin, en particulier les noms, e-mails, numéros de compte et notes en texte libre.
• Remplacez les identifiants directs par des jetons aléatoires et gardez la table de correspondance chez vous.
• Réduisez le corpus à ce dont la méthode a besoin. Un fine-tuning LoRA ou QLoRA ajuste un petit ensemble de poids supplémentaires et a rarement besoin d’une base de production entière ; notre guide du fine-tuning décrit une configuration réaliste.
• N’oubliez pas que les poids d’un modèle portent de l’information. Un modèle fine-tuné sur des textes sensibles peut en répéter des morceaux : traitez aussi l’adaptateur comme sensible.

Des données désidentifiées, c’est aussi ce qui fait disparaître la plupart des questions juridiques abordées plus bas.

Identifiants et réseau sur le nœud

Partez du principe que tout ce que vous mettez sur le nœud peut être copié.

• Utilisez un token Hugging Face à permissions fines, en lecture seule sur le seul dépôt dont vous avez besoin, et révoquez-le à la fin de la tâche.
• Ne copiez jamais votre clé privée SSH principale, vos identifiants root cloud ou les mots de passe de vos bases de production sur une machine louée. Si la tâche doit écrire ses résultats dans un bucket, créez une clé qui ne peut écrire que sous un seul préfixe et qui expire dans la journée.
• Rapatriez les résultats par SSH au lieu de les pousser depuis le nœud avec des clés à longue durée de vie.
• Vérifiez ce qui écoute avec ss -tulnp. Liez Jupyter, TensorBoard et les serveurs d’inférence à 127.0.0.1 et accédez-y par un tunnel SSH (ssh -L 8888:127.0.0.1:8888 ...) plutôt que d’exposer un port public.

Un nettoyage qui tient sur les disques modernes

Le conseil habituel est de passer le jeu de données à shred une fois fini. Il ne fait pas ce que l’on croit. Le manuel de GNU coreutils indique que shred compte sur le système de fichiers et le matériel pour écraser les données sur place, et liste les cas où cela échoue : les systèmes de fichiers journalisés ou structurés en log comme ext4 en mode data=journal, Btrfs, XFS et ZFS, le RAID, les systèmes de fichiers avec snapshots, les systèmes de fichiers compressés, et les SSD, dont la répartition de l’usure écrit les nouvelles données ailleurs. Un nœud GPU loué cumule très probablement plusieurs de ces cas.

Ce qui fonctionne à la place :

1. Rendre la copie sur disque sans valeur. Si seule l’archive chiffrée avec age a touché le disque, la supprimer suffit ; sans la phrase de passe, ce n’est que du bruit. Le guide du NIST sur l’assainissement des supports (SP 800-88 Rev. 2, septembre 2025) traite cette idée, l’effacement cryptographique, comme une technique standard.
2. Détruire, pas arrêter. Sur Vast.ai, arrêter une instance conserve ses données (et continue de facturer le stockage) ; la détruire « supprime définitivement l’instance et toutes ses données ». Sur RunPod, le disque de conteneur est effacé à l’arrêt du pod, le volume /workspace survit aux arrêts et est supprimé à la résiliation (terminate), et un volume réseau survit à tout jusqu’à ce que vous le supprimiez.
3. Supprimer les volumes réseau que vous avez créés. Par conception, ils survivent aux pods.
4. Révoquer ce que vous avez utilisé. Token Hugging Face, clés de bucket, et retirez de la place de marché toute clé SSH publique ajoutée pour cette seule tâche.

La façon dont l’hôte efface les disques entre deux locataires n’est décrite dans aucune des documentations de places de marché que j’ai lues. Partez du principe que cela n’a pas lieu : l’étape 1 vous couvre dans tous les cas.

Contrats et réglementation

Les contrôles techniques comptent moins qu’un fait juridique : mettre des données sur la machine de quelqu’un en fait une partie prenante.

• RGPD. Un hôte GPU qui traite des données personnelles pour vous est un sous-traitant. L’article 28 exige un sous-traitant qui présente des « garanties suffisantes » et un contrat qui vous lie. Un hôte de pair à pair avec qui vous n’avez rien signé ne remplit pas ces conditions, et la machine peut se trouver hors de l’UE. Désidentifiez, ou passez par un fournisseur qui signe un DPA.
• HIPAA. Le HHS indique qu’un fournisseur cloud qui stocke des données de santé électroniques est un business associate, même si les données sont chiffrées et qu’il n’a pas la clé. Chiffrer des dossiers médicaux avant de les envoyer à un hôte non contrôlé ne dispense pas d’un BAA.
• Les contrats de vos clients. Beaucoup de contrats d’entreprise encadrent les sous-traitants et la localisation des données. Vérifiez-les avant le premier envoi. Le risque juridique dépasse souvent le risque technique.

L’article compagnon sur pourquoi les entreprises restreignent les outils d’IA publics aborde les mêmes règles du côté des chats.

L’inférence sur GPUFlow : un autre compromis

GPUFlow n’est pas un endroit où déposer un jeu de données. C’est une place de marché d’inférence : vous louez un GPU à l’heure et obtenez une clé API compatible OpenAI (URL de base https://gpuflow.app/v1) pour le modèle ouvert qu’un fournisseur fait tourner (généralement avec Ollama) sur son propre ordinateur. Il n’y a ni SSH, ni shell, ni accès aux fichiers, et vous ne pouvez ni entraîner ni fine-tuner. Rien de ce que vous envoyez ne reste sur le disque du fournisseur, puisque vous ne pouvez rien y déposer.

Cela supprime les problèmes de disque et d’identifiants décrits dans ce guide. Pas le problème de l’hôte. Chaque prompt et chaque réponse passent en clair par la machine du fournisseur pendant la location. Les conditions de GPUFlow interdisent aux fournisseurs de les enregistrer, de les lire, de les conserver ou de les partager, et GPUFlow ne stocke pas le texte lui-même, mais le fournisseur a les droits root sur la machine : la règle ne repose que sur le contrat. Si vous faites passer un jeu de données à raison d’un enregistrement par prompt, chaque enregistrement arrive sur cet ordinateur.

Utilisez-le donc pour des données publiques, synthétiques ou correctement désidentifiées, et pour tester un modèle ouvert ou une application contre une API de type OpenAI. Gardez les données réglementées et confidentielles sur votre propre matériel, chez un fournisseur avec qui vous avez un contrat, ou dans une VM confidentielle. Le démarrage rapide de l’API le résume en une ligne : n’envoyez pas de mots de passe, de numéros de carte ni d’autres secrets que vous ne confieriez pas à un inconnu. Le même dispositif, vu du côté du fournisseur, est décrit dans louer son GPU, est-ce sans risque ?.

Liste de vérification

Avant :

• Déterminez la catégorie des données. Les données réglementées ou confidentielles d’un client vont chez un fournisseur sous contrat ou dans une VM confidentielle, pas chez un hôte communautaire.
• Réduisez et désidentifiez.
• Chiffrez avec age ; gardez la phrase de passe hors du nœud.

Pendant :

• Déchiffrez dans /dev/shm quand ça tient.
• Uniquement des tokens à portée limitée et de courte durée.
• Services liés à localhost, accessibles par tunnel SSH.

Après :

• Rapatriez les résultats par SSH ; traitez les poids fine-tunés comme sensibles.
• Détruisez l’instance et tous les volumes réseau.
• Révoquez les tokens et les clés à usage unique.

Sources

• Isolation des conteneurs et Secure Cloud sur Vast.ai : FAQ sécurité de Vast.ai ; arrêt ou destruction : gérer les instances
• RunPod Secure Cloud et Community Cloud : choisir un pod ; persistance du stockage : types de stockage
• LeftoverLocals : Trail of Bits, janvier 2024
• age : github.com/FiloSottile/age
• Limites de shred : manuel de GNU coreutils, invocation de shred
• NIST SP 800-88 Rev. 2 : annonce du NIST, septembre 2025
• Conception du confidential computing sur H100 : NVIDIA, Confidential Computing on H100 GPUs for Secure and Trustworthy AI ; disponibilité générale : NVIDIA, avril 2024
• Azure : série NCCads H100 v5
• Google Cloud : configurations prises en charge pour Confidential VM, créer une instance Confidential VM avec GPU
• Article 28 du RGPD : gdpr-info.eu
• HIPAA et fournisseurs cloud : HHS, recommandations sur HIPAA et le cloud computing
• GPUFlow : démarrage rapide de l’API, ce à quoi les locataires ont accès ou non, conditions d’utilisation, politique de confidentialité

Toutes vérifiées en septembre 2026.