
Le calcul sécurisé consiste à protéger les systèmes et les données utilisés pour exécuter une tâche. Il peut associer contrôle des identités, isolation réseau, durcissement logiciel, chiffrement et surveillance. L'expression seule ne précise ni les protections d'un service ni les personnes qui pourraient encore accéder aux données.
L'informatique confidentielle a un sens plus précis : protéger les données pendant leur traitement grâce à un environnement d'exécution de confiance matériel, avec attestation, ou TEE. Cette distinction compte pour comparer des services cloud, notamment pour des données sensibles, des modèles de machine learning privés ou des projets de recherche communs. Un réseau privé, un disque chiffré et une machine virtuelle confidentielle répondent à des problèmes différents.
Commencez par trois questions : que faut-il protéger, contre qui et à quelle étape du traitement ? Une équipe qui traite des documents clients peut devoir protéger les fichiers sources, les identifiants, les entrées du modèle, les fichiers temporaires et les résultats. Ces éléments peuvent traverser plusieurs services avant qu'un utilisateur reçoive une réponse.
Les principaux objectifs sont la confidentialité, l'intégrité et la disponibilité : limiter les divulgations non autorisées, empêcher ou détecter les modifications indésirables et maintenir l'accès aux traitements autorisés. La sécurité dépend aussi des pratiques d'exploitation. Un serveur bien protégé peut exposer des données à cause d'un jeton trop permissif ou d'un dossier de résultats public.
Notre guide de la sécurité cloud présente la répartition générale des responsabilités. Pour une charge de calcul, attribuez ces responsabilités à des personnes identifiées : mises à jour du système d'exploitation, accès à l'application, secrets, sauvegardes et réponse aux incidents.
Le chiffrement au repos protège les informations stockées selon les garanties du système de stockage et de gestion des clés. Le chiffrement en transit protège les échanges entre des points de communication. Aucun des deux n'empêche, à lui seul, une application autorisée de lire les données en clair pendant leur traitement.
La présentation de l'informatique confidentielle par Microsoft décrit une frontière matérielle supplémentaire pour les données en cours d'utilisation. Elle vise à réduire leur exposition à des acteurs extérieurs à l'environnement protégé, dont l'opérateur cloud. La frontière exacte et sa configuration comptent ; cette appellation n'offre pas une garantie universelle de sécurité.
Dans un TEE, le code autorisé peut manipuler les données en clair à l'intérieur de cette frontière. Dire qu'un tel calcul ne déchiffre jamais les données confond informatique confidentielle et chiffrement homomorphe. La documentation de Microsoft sur les TEE précise ce fonctionnement.
Ces mécanismes peuvent se compléter. Choisissez-les en fonction d'une menace précise, plutôt que de les considérer comme des améliorations interchangeables.
| Mécanisme | Problème traité | Points restant à examiner |
|---|---|---|
| Gestion des identités et des accès | Qui peut accéder aux ressources et effectuer quelles actions | Vol d'identifiants, permissions excessives et révision des accès |
| Réseau privé | Accessibilité réseau et chemins de communication autorisés | Authentification applicative et compromission de clients autorisés |
| Informatique confidentielle | Données utilisées dans une frontière matérielle attestée | Logiciels de confiance, entrées, sorties et limites propres à la plateforme |
| Chiffrement homomorphe | Calculs compatibles sur des valeurs chiffrées | Algorithmes adaptés, gestion des clés et performances |
| Calcul multipartite sécurisé | Calcul commun à partir des entrées privées de plusieurs participants | Hypothèses du protocole, participants et informations révélées par le résultat |
Le projet du NIST sur la cryptographie préservant la confidentialité distingue le chiffrement homomorphe du calcul multipartite sécurisé. Le premier permet des opérations sur des données chiffrées ; le second permet un calcul commun sans que les parties se divulguent leurs entrées individuelles. Les deux nécessitent une conception adaptée au calcul concerné. Aucun ne constitue une option générale qui rendrait privée toute application existante.
Une enclave sécurisée peut isoler une partie du code applicatif, tandis qu'une machine virtuelle confidentielle peut protéger un environnement plus large, comprenant son système d'exploitation invité. Cela change les composants auxquels il faut faire confiance et qu'il faut maintenir. Demandez si la frontière couvre un petit service, une VM entière ou un groupe précis de conteneurs.
Identifiez ensuite les logiciels présents à l'intérieur. Si l'application est autorisée à lire des données sensibles, une faille applicative peut encore les exposer. Une VM confidentielle nécessite aussi des mises à jour et une gestion rigoureuse des accès administrateur dans le système invité. L'isolation matérielle ne décide ni si une requête est appropriée, ni si un utilisateur doit recevoir une réponse, ni si un résultat contient des informations privées.
Pour choisir un fournisseur, demandez son modèle de menace documenté. Il doit préciser les composants protégés, ceux auxquels il faut faire confiance, les configurations compatibles, les procédures de mise à jour et les limites connues. Une affirmation comme « aucun administrateur ne peut jamais accéder aux données » exige des preuves.
L'attestation distante permet à un vérificateur d'évaluer des preuves concernant un environnement d'exécution. Un service peut utiliser ce résultat pour décider de transmettre une clé ou un autre secret. La politique doit définir les mesures et configurations acceptables ; recevoir une réponse d'attestation ne suffit pas.
La documentation sur l'attestation des VM Azure illustre ce processus et précise une distinction importante : vérifier l'environnement de la VM ne prouve pas automatiquement que l'image de la charge de travail est approuvée. La mesure de cette charge et sa vérification nécessitent une conception spécifique.
Lors d'un pilote, testez l'acceptation et le refus. Un déploiement approuvé doit recevoir le secret nécessaire ; une configuration non approuvée ne doit pas l'obtenir. Désignez les responsables de la politique d'acceptation et prévoyez le traitement des mises à jour, des révocations et des échecs de vérification, sans contournement d'urgence qui expose les données.
Un traitement GPU ajoute des emplacements où les données privées peuvent circuler : mémoire CPU, mémoire de l'accélérateur, transferts entre composants, caches de modèles, points de contrôle et journaux d'inférence. Documentez ces chemins avant de choisir une instance. Une frontière de protection CPU ne doit pas être supposée couvrir chaque accélérateur ou service externe.
Demandez quelle combinaison CPU et GPU prend en charge le mode confidentiel requis, comment chaque composant est attesté et où les données deviennent accessibles en dehors de cette frontière. Mesurez la configuration exacte avec votre modèle et vos logiciels. Évitez les pourcentages génériques de surcoût du chiffrement et les équivalences de performances présumées entre matériels différents.
Utilisez des données synthétiques ou des données non sensibles approuvées pour le premier test. Limitez les identifiants d'accès aux dépôts de modèles à la tâche nécessaire, conservez-les hors du code versionné et révoquez-les lorsqu'ils ne servent plus. Le guide des jetons d'accès Hugging Face présente les contrôles adaptés à cette étape.
Vercel Secure Compute désigne une fonctionnalité réseau. Sa documentation décrit un réseau dédié, des adresses IP sortantes fixes et des connexions privées vers l'infrastructure backend. Cela aide les équipes à limiter le trafic qui peut atteindre les bases de données et autres services.
Évaluez cette fonctionnalité selon ses protections réseau documentées. Des adresses IP dédiées ne prouvent ni la présence d'un TEE ni une protection contre les administrateurs d'infrastructure pendant le traitement. Vercel précise également que le filtrage IP nécessite toujours des identifiants d'authentification. Vérifiez les environnements d'exécution compatibles et l'inclusion éventuelle des builds dans la connexion.
Avant de déplacer des charges sensibles, décrivez les flux de données et la décision que chaque contrôle doit permettre. Une revue utile peut tenir sur une page si les réponses sont concrètes.
Cette démarche rejoint les recommandations zero trust du NIST : la localisation réseau seule ne doit pas accorder une confiance implicite. Un service sur un sous-réseau privé nécessite encore des contrôles d'identité et des autorisations adaptés à la ressource.
Pour Compute with Hivenet, partez des capacités documentées du service et des besoins de votre application. La référence actuelle des GPU indique des instances RTX 5090 avec 32 Go de VRAM par GPU et précise que la flotte RTX 4090 est retirée du service. Confirmez les configurations disponibles et les tarifs actifs dans la console.
La disponibilité d'un GPU ne prouve pas la prise en charge de l'informatique confidentielle. Si vous exigez une attestation matérielle ou une protection contre l'accès des administrateurs de l'hôte, obtenez une confirmation explicite pour la configuration complète avant d'y placer des données sensibles. Ne déduisez pas cette protection du modèle de GPU, de l'isolation d'une VM ou du mot « sécurisé ».
Pour les charges compatibles avec le service documenté, examinez les ports exposés, l'authentification applicative, les mises à jour du système invité, les jetons et l'export des données. La présentation des VM Hivenet aide à comprendre l'accès à l'instance. Votre application nécessite toujours sa propre politique d'accès et ses vérifications d'exploitation.
Non. Le calcul sécurisé décrit au sens large la protection des traitements. L'informatique confidentielle utilise une isolation matérielle attestée pour les données en cours d'utilisation. Demandez le mécanisme précis et le modèle de menace correspondant à chaque affirmation.
Un contrôle technique ne règle pas toute la question. Une revue doit également examiner la collecte, l'utilisation, la conservation, l'accès et les transferts de données, ainsi que les exigences contractuelles et organisationnelles applicables. Ne présentez pas une charge comme conforme simplement parce qu'elle utilise un environnement protégé.
Il n'existe ni tarif unique ni supplément universel fiable. Comparez la configuration, le stockage, les transferts, les services de vérification et le travail d'ingénierie nécessaires. Mesurez le coût par tâche terminée et l'effort d'exploitation des contrôles à partir des prix actuels du fournisseur.
Aucun contrôle isolé ne le garantit. Un système peut appliquer des règles d'accès alors qu'un traitement autorisé utilise les informations de manière inappropriée. Notre guide sur la sécurité et la vie privée dans le cloud explique pourquoi la protection des accès et la définition des usages acceptables demandent des examens distincts.
Choisissez une charge de travail d’IA, de calcul ou de stockage à tester sur Hivenet, ou échangez avec notre équipe sur sa mise en production.