Points clés
- C’est l’ouverture de ce que j’appelle la confiance zéro 2.0 avec une couche matérielle : gardez le plan de contrôle centré sur l’identité, et ajoutez l’isolation matérielle pour que privilège d’infrastructure ≠ privilège sur les données.
- C’est la grammaire de la confiance zéro appliquée au calcul, pas seulement aux sessions réseau.
- L’isolation matérielle nous permet d’exploiter des charges de travail sensibles d’IA et de données sur une infrastructure à laquelle on ne fait pas entièrement confiance — y compris l’accès hôte de nos propres administrateurs — sans abandonner les plateformes modernes.
La confiance zéro a d’abord corrigé la mauvaise confiance implicite — et c’était déjà un progrès
La première vague de confiance zéro avait un ennemi clair : le réseau plat et l’idée que « dedans = sûr ».
On s’est améliorés sur :
- Une identité forte pour les utilisateurs et les services
- Les signaux de santé des appareils
- L’accès au moindre privilège aux applications
- La segmentation et l’autorisation continue
- La réduction du VPN comme trait de personnalité
Je n’ai aucun intérêt à me moquer de ce travail. Il a fermé de vrais chemins d’attaque.
Mais la sécurité de production a l’habitude de déplacer la confiance plutôt que de la supprimer. Après avoir cessé de faire confiance au réseau, bien des architectures traitaient encore ceci comme à peu près sûr :
- La frontière du compte infonuagique
- Les opérateurs du plan de contrôle Kubernetes
- L’hyperviseur
- Le root sur le nœud
- Les outils d’administration « privilégiés mais réputés »
Si votre modèle de menace inclut une identité d’administrateur compromise, un initié malveillant dans l’équipe de plateforme, une atteinte à la chaîne d’approvisionnement sur un agent hôte, ou une histoire d’évasion de colocataire — et les modèles modernes devraient — les contrôles classiques de confiance zéro ne couvrent pas entièrement les données en cours d’utilisation.
C’est l’ouverture de ce que j’appelle la confiance zéro 2.0 avec une couche matérielle : gardez le plan de contrôle centré sur l’identité, et ajoutez l’isolation matérielle pour que privilège d’infrastructure ≠ privilège sur les données.
L’hypothèse de l’infrastructure non fiable
Le modèle de menace de l’informatique confidentielle est d’une clarté presque impolie. Le cadrage du Confidential Computing Consortium inclut depuis longtemps le SE hôte, l’hyperviseur, les administrateurs système et les propriétaires d’infrastructure parmi les entités qui ne devraient pas voir automatiquement les données à l’intérieur d’un TEE (livre blanc de sensibilisation du CCC).
L’architecture d’usine d’IA de confiance zéro de NVIDIA applique la même colonne vertébrale à l’IA : SE hôte, hyperviseur et fournisseur sont non fiables; les charges de travail tournent dans des environnements adossés au matériel; les secrets ne sont divulgués qu’après la réussite de l’attestation à distance (Building a Zero-Trust Architecture for Confidential AI Factories).
C’est la grammaire de la confiance zéro appliquée au calcul, pas seulement aux sessions réseau.
Ce que « couche matérielle » veut dire, sans mysticisme
Pas besoin de vénérer le silicium. Il faut trois idées mécaniques :
- Racine de confiance dans le matériel — les mesures partent de quelque chose de plus difficile à usurper qu’un processus hôte
- Isolation / chiffrement de la mémoire pour les données en cours d’utilisation — le logiciel hôte privilégié n’est pas un lecteur légitime du texte en clair de la charge de travail
- Attestation — les parties distantes vérifient « ce qui tourne » avant de traiter l’environnement comme acceptable
Sur CPU, cette conversation, c’est Intel TDX, AMD SEV-SNP et les technologies semblables. Sur GPU d’IA, l’informatique confidentielle de classe Hopper (lignée H100/H200) étend l’isolation jusque dans l’accélérateur. L’histoire combinée compte : protéger seulement l’invité CPU en laissant la mémoire GPU exposée est une réponse incomplète pour le travail sur LLM.
Confiance zéro 1.0 contre 2.0 (selon mon usage)
| Couche | Accent de la confiance zéro 1.0 | Confiance zéro augmentée par le matériel |
|---|---|---|
| Réseau | Aucune confiance implicite fondée sur la localisation | Toujours vrai; non remplacé |
| Identité | Utilisateurs et services vérifiés en continu | Toujours fondamental |
| Accès aux applis | Intermédié, moindre privilège | Toujours fondamental |
| Plateforme hôte | Souvent fiable si « gérée » | Traitée comme hostile pour les données en cours d’utilisation |
| Secrets | Coffre + IAM | Coffre + IAM et divulgation conditionnée à l’attestation |
| Modèles et données d’IA | Contrôlés par l’IAM de projet | Chiffrés jusqu’à ce que l’enclave fasse ses preuves |
Si quelqu’un dit « nous sommes déjà en confiance zéro » et ne peut pas répondre comment un utilisateur root du nœud est empêché de lire la mémoire de la charge de travail, il décrit un déploiement partiel. C’est correct — il ne faut juste pas le survendre.
Pourquoi l’IA et les données réglementées forcent la question maintenant
Trois pressions frappent en même temps :
- Du contenu sensible dans les invites et les réglages fins — plus de renseignements personnels et de données d’affaires confidentielles en mouvement à travers les modèles
- La PI des modèles sur les machines d’autrui — distribution de modèles de fondation, inférence hébergée par des fournisseurs, grappes multi-équipes
- Le rayon d’impact des administrateurs — l’accès de l’ingénierie de plateforme est large par conception; les contrôles d’identité sur les humains aident, mais le privilège hôte reste un risque structurel
Dans le travail de protection des données, je vois sans cesse les revues de sécurité s’arrêter au chiffrement en transit vers le point de terminaison du modèle. Bien. Insuffisant si l’hôte du point de terminaison est dans le périmètre du risque d’inspection.
Des briques qui correspondent à la pensée architecturale du CISSP
La décision et l’application de politiques existent toujours — on ajoute un nouveau type de preuve Votre histoire PDP/PEP gagne les résultats d’attestation comme intrants : « autoriser le secret X seulement si type de TEE ∈ liste d’autorisation ET mesures conformes ET CC du GPU = activé. »
Les frontières de confiance sont redessinées La frontière n’est pas « le VPC ». C’est « l’enclave attestée ». Tout ce qui est hors de là est un problème de transport et de plan de contrôle.
Le moindre privilège devient bidimensionnel
- Moindre privilège pour les identités (classique)
- Moindre privilège pour la visibilité de l’infrastructure (imposé par le matériel)
La journalisation et la surveillance doivent être repensées L’introspection au niveau de l’hôte rétrécit. Il faut prévoir une télémétrie consciente des enclaves qui ne ré-exfiltre pas du contenu sensible vers des agents non fiables.
Un flux de contrôle de référence (à utiliser dans les revues de conception)
- L’utilisateur ou le service s’authentifie (identité CZ)
- L’autorisation vérifie la politique de ressource (accès CZ)
- La charge de travail est planifiée sur de la capacité de calcul confidentiel
- L’environnement s’atteste (CPU ± GPU)
- Le courtier de clés valide la preuve contre la politique
- Clés et données divulguées dans le TEE seulement
- Sortie des extrants contrôlée; stockage rechiffré
- Preuves de session et de machine réévaluées en continu là où la plateforme le permet
Les étapes 1 à 2 sans les étapes 4 à 6 reposent sur un plancher de verre.
Ce qui casse quand même si on n’achète que des TEE
La confiance zéro matérielle n’est pas une greffe de personnalité pour un programme faible.
Il faut toujours :
- La discipline des correctifs pour les charges de travail invitées
- Un cycle de développement sécurisé pour les serveurs de modèles et les outils
- Le chiffrement réseau hors de l’enclave
- Une identité forte pour les humains et les comptes de service
- Une manipulation soigneuse des invites et des extrants dans les journaux d’application
- Des contrôles de chaîne d’approvisionnement pour les images de conteneurs et les modèles
Les TEE réduisent une classe de risque d’inspection hôte. Ils ne font pas disparaître le « l’admin peut supprimer la grappe », et ils n’empêchent pas une application d’envoyer volontairement des secrets sur Internet.
Les notes d’architecture de NVIDIA sont explicites sur le périmètre résiduel : les vulnérabilités d’application, les attaques de disponibilité et le réseau et le stockage hors de la frontière CoCo restent votre problème (article de NVIDIA sur les usines d’IA de confiance zéro).
Friction opérationnelle — attendez-vous à de la résistance
Les équipes de plateforme s’inquiéteront de la débogabilité et de la performance. Elles n’ont pas tort; répondez avec un surcoût mesuré et un meilleur outillage côté invité, pas des slogans.
Les équipes de sécurité essaieront de boulonner l’attestation comme une liste de vérification trimestrielle. Elle doit siéger dans le chemin des clés, sinon elle sera désactivée à la première panne.
L’approvisionnement demandera si cela remplace le fournisseur de confiance zéro X. Non. Cela complète la CZ centrée sur l’identité avec des garanties centrées sur le calcul.
La conformité demandera des preuves. Gardez les politiques d’attestation, les valeurs de référence et les registres de changements. « On a activé les machines virtuelles confidentielles » n’est pas une preuve en soi.
Le coût apparaît comme de la fragmentation de capacité (nœuds compatibles CC), du temps d’ingénierie et parfois une taxe de débit sur les chemins CC des GPU. Budgétisez le programme, pas seulement l’indicateur de fonction.
Comment j’en parle à la direction sans mots creux
J’utilise une histoire simple :
On refuse déjà de faire confiance au chemin réseau. On fait encore trop confiance à l’ordinateur. L’isolation matérielle nous permet d’exploiter des charges de travail sensibles d’IA et de données sur une infrastructure à laquelle on ne fait pas entièrement confiance — y compris l’accès hôte de nos propres administrateurs — sans abandonner les plateformes modernes.
Puis je montre un flux de travail où un secret ne peut pas être récupéré à moins que l’attestation réussisse. Les dirigeants comprennent les serrures de porte. L’attestation est une serrure de porte avec vérification du numéro de série.
Étapes de maturité concrètes (pas une fausse échelle de 1 à 5)
- Étape A : Modélisez la menace de l’admin hôte/hyperviseur comme dans le périmètre pour un service d’IA ou de données joyau de la couronne
- Étape B : Déployez des machines virtuelles confidentielles pour le chemin de contrôle de ce service
- Étape C : Ajoutez le CC du GPU si des GPU traitent le matériel sensible
- Étape D : Liez la divulgation des clés du KMS à l’attestation
- Étape E : Alimentez la posture d’attestation dans la même cadence de gouvernance que la posture des appareils
- Étape F : Faites un exercice d’équipe rouge avec des scénarios « compromission hôte présumée »
Si vous sautez à E sans D, vous avez bâti du rapportage, pas de l’application.
Sources
- NVIDIA : Building a Zero-Trust Architecture for Confidential AI Factories
- NVIDIA : Confidential Computing on H100 GPUs
- Livre blanc du Confidential Computing Consortium (le modèle de menace des TEE inclut le SE hôte, l’hyperviseur et les administrateurs) : PDF
- Matériel de la communauté technique Microsoft sur l’informatique confidentielle et la confiance zéro (le TEE permet de traiter les logiciels hors périmètre comme non fiables) : discussion PDF sur l’informatique confidentielle Azure et la confiance zéro
À retenir et à appliquer
La confiance zéro sans couche matérielle laisse encore une île de confiance implicite : l’hôte et l’hyperviseur. Les TEE et l’attestation étendent les principes de confiance zéro aux données en cours d’utilisation, exactement là où vivent l’IA moderne et le traitement à haute valeur. Gardez l’identité, la segmentation et l’évaluation continue — et cessez de traiter le privilège de plateforme comme inoffensif. Si les secrets peuvent circuler avant que la machine prouve ce qu’elle est, vous pratiquez encore une confiance zéro partielle avec une meilleure image de marque.