Chaque location VMCache correspond à un nœud physique dédié, sans partage du processeur, de la mémoire unifiée ni du stockage local avec d’autres locataires. L’isolation matérielle est une base et ne remplace ni la gestion des comptes, ni la protection des identifiants, ni les sauvegardes, ni le contrôle d’accès aux services.
Ces points sont indépendants. En valider un ne signifie pas que les autres sont automatiquement satisfaits.
Un nœud physique dédié réduit les perturbations liées aux ressources de calcul partagées. La sécurité du service dépend toutefois aussi de la répartition des comptes, du stockage des secrets, de l’exposition des services réseau et de la conservation des copies de données.
La commande fournit une machine physique dédiée. Le processeur, la mémoire unifiée et le stockage local ne sont pas partagés avec d’autres locataires et il ne s’agit pas d’une instance virtuelle partagée.
Les informations de connexion indiquent uniquement qui peut accéder au nœud. Les opérations possibles après la connexion dépendent toujours des comptes système, des droits sur les répertoires, de l’identité de la tâche et des autorisations internes de l’équipe.
Le disque local du nœud est un espace d’exécution et ne doit pas être la seule copie. Le code, les modèles, les artefacts, les journaux et la configuration doivent suivre les processus de versionnage, d’artefacts ou de sauvegarde déjà utilisés par l’équipe.
Les informations de connexion doivent être consultées uniquement via le processus de gestion des commandes. Ne les copiez pas dans des canaux publics, titres de tickets, dépôts de code, sorties de build ou documents d’équipe sans contrôle d’accès.
Vérifiez d’abord l’identifiant de commande, le modèle, le nœud et l’état actuel de la livraison afin de ne pas associer les informations de connexion d’une autre machine aux journaux d’opération.
Accédez à la console via un réseau fiable et un appareil local géré. N’affichez pas les informations complètes pendant un partage d’écran, un enregistrement ou une diffusion en direct.
Si l’équipe doit partager l’accès, utilisez votre propre outil de gestion des secrets et limitez les destinataires, la durée de validité et le périmètre d’audit.
Conservez les noms de champs, l’étape de l’erreur et le contexte nécessaire, puis supprimez les mots de passe, clés privées, jetons, chaînes de connexion complètes et données personnelles.
La connexion interactive, la CI/CD et le service de modèles présentent des risques différents. Des identités, droits de répertoire et périmètres de lecture des secrets distincts réduisent l’impact d’une erreur ou d’une fuite d’identifiants.
| Usage de l’identité | Autorisations recommandées | Périmètre des secrets | Exigences de journalisation |
|---|---|---|---|
| Connexion interactive Configuration et diagnostic manuels |
Accorder uniquement les droits système et de répertoire nécessaires au travail en cours | Ne pas conserver durablement les jetons des tâches automatisées | Enregistrer l’heure, l’objet et le résultat de chaque modification |
| CI/CD Récupération des dépendances, build et archivage |
Limiter le répertoire de travail, les outils de build et le répertoire des artefacts | Lire les éléments de signature et jetons de dépôt nécessaires selon le pipeline | Conserver l’identifiant de tâche dans les journaux et filtrer les variables d’environnement et signatures |
| Service de modèles Charger les modèles et traiter les requêtes |
Limiter les répertoires de modèles, le processus de service et les ports d’écoute | Lire uniquement la source du modèle, l’authentification du service et les identifiants de stockage nécessaires | Ne pas enregistrer les invites complètes, les jetons ni le contenu sensible des réponses |
Commencez chaque nouvelle tâche sans autorisation supplémentaire et n’ajoutez qu’un accès auditable en cas de besoin explicite.
Après toute évolution des personnes, pipelines ou services de modèles, revérifiez les comptes, jetons, répertoires et autorisations réseau.
Chaque identité de tâche doit pouvoir être désactivée séparément, sans supprimer le nœud entier ni interrompre les autres charges de travail.
Le nœud convient aux tâches de build et d’inférence, mais ne doit pas être le seul emplacement de conservation du code, des modèles ou des artefacts. Prévoyez la sortie dans le plan de déploiement afin de ne pas découvrir l’absence de copie récupérable à la fin de la location.
Supprimez d’abord les archives inutiles, anciens identifiants, copies de données de production et informations personnelles. Les éléments récupérables via un gestionnaire de dépendances n’ont pas à être intégrés dans une image conservée à long terme.
Répartissez les répertoires par projet ou lot de tâches. Conservez séparément caches de build, fichiers de modèles, artefacts de sortie et journaux afin de gérer les droits, quotas d’espace et règles de nettoyage.
Placez le code source dans la gestion de versions, les artefacts dans le processus de livraison et les modèles et données dans un emplacement approuvé par l’équipe. Vérifiez régulièrement que la copie peut réellement être restaurée.
Exportez les artefacts, configurations et journaux désensibilisés nécessaires, puis vérifiez l’intégrité des fichiers et leur emplacement de réception. Après confirmation de l’inutilité des données restantes, appliquez votre propre processus de nettoyage.
Les fichiers de signature, jetons de dépôt, clés de service et variables d’environnement doivent être fournis par le processus de gestion des secrets de l’équipe. Les scripts de build ne référencent que des noms de variables ou des chemins de fichiers contrôlés, sans conserver les valeurs réelles.
Conserver les valeurs réelles, limiter les lecteurs et garder l’historique des modifications et révocations.
Lire uniquement, pendant l’exécution, l’ensemble minimal de secrets requis par le pipeline actuel.
Afficher l’étape, le statut de sortie et l’emplacement des artefacts, sans reproduire les secrets.
Avant de mettre en ligne une interface d’inférence MLX, vérifiez séparément la portée d’écoute du processus, le contrôle d’accès, les limites de concurrence, le contenu des journaux et la provenance des dépendances du modèle. Validez d’abord sur un réseau restreint, puis élargissez l’accès.
Confirmer le format du modèle, le chargement, l’utilisation de la mémoire unifiée et la réponse de base.
Ouvrir l’accès uniquement aux appelants de test et vérifier les échecs d’authentification, les délais d’attente et les requêtes anormales.
Augmenter progressivement les requêtes et observer la mémoire, la latence, le taux d’erreur et les journaux de chargement du modèle.
Consigner la portée d’écoute finale, l’identité appelante, la stratégie de journalisation et la méthode d’arrêt.
| Point de contrôle | Conclusion acceptable | Signal nécessitant un ajustement |
|---|---|---|
| Portée d’écoute | L’interface prévue est la seule liaison, avec un chemin d’accès réseau clairement défini | Écoute par défaut sur toutes les interfaces, sans source d’appel identifiable |
| Contrôle d’accès | L’identité appelante est révocable séparément et les échecs ne divulguent aucune information interne | Jeton partagé à long terme, ou jeton écrit dans le client et les journaux |
| Journaux des requêtes | Conserver l’heure, le statut et l’identifiant de tâche nécessaires, avec contenu désensibilisé | Enregistrement intégral d’invites sensibles, jetons ou données d’entrée du modèle |
| Provenance des dépendances | Provenance des modèles et paquets traçable, versions et contrôles clairement indiqués | Dépendances téléchargées à l’exécution dont la source ou la version est invérifiable |
En cas d’accès anormal, de transmission accidentelle d’identifiants, de processus inconnu ou de problème d’exposition d’un service, limitez d’abord les identités et services concernés selon le processus de l’équipe, puis rassemblez l’identifiant de commande, la chronologie, l’étendue de l’impact et les preuves désensibilisées.
L’adresse d’assistance externe à utiliser est uniquement support@vmcache.com. N’envoyez jamais de clés réelles dans le corps ou les pièces jointes de l’e-mail.
Vérifiez d’abord le modèle, le nœud et la durée de location, puis ajoutez comptes, secrets, sauvegardes et contrôles d’interface à la liste de livraison de votre équipe.