Périmètre des responsabilités de sécurité

Un nœud physique dédié, contrôlé à chaque étape, de l’accès à la restitution sécurisée

VMKeep attribue une machine physique dédiée à chaque commande : les instances ne sont pas partagées avec d’autres locataires. La plateforme prend en charge la mise à disposition du nœud, l’accès au compte et l’assistance en cas d’incident. L’utilisateur reste responsable des droits et des sauvegardes des identifiants, dépôts, modèles, éléments de signature et données métier.

Louer un Mac dans le cloud Voir les options de connexion

1 commande: 1 machine physique dédiée
2 types d’accès: Ligne de commande SSH et interface graphique VNC
365 jours: Nœud maintenu en fonctionnement normal

VMKEEP / SECURITY DOSSIER Journal de contrôle des accès au nœud

Modèle en quatre niveaux

Nœud physique dédié Une commande correspond à un équipement physique, pas à une machine virtuelle

Isolé

Contrôle d’accès au compte L’accès, la commande et les tickets d’assistance sont associés

Contrôlé

Identifiants de connexion à distance Mettez à jour le mot de passe après la première connexion et configurez les clés SSH

Géré par l’utilisateur

Processus de gestion des incidents Vérification de l’état, conservation des preuves et assistance à la récupération à distance

Traçable

Modèle de sécurité en quatre niveaux

Identifiez d’abord qui contrôle chaque niveau, puis définissez vos processus d’équipe

La sécurité ne repose pas sur un simple bouton. L’isolation physique évite le partage des ressources d’exécution, le contrôle du compte confirme l’appartenance de la commande, la connexion à distance détermine qui peut accéder à la machine et les processus opérationnels encadrent le signalement et la récupération en cas d’incident.

Couche physique

Un équipement physique dédié

Chaque commande correspond à une machine physique dédiée ; le CPU, la mémoire, le disque système et l’instance d’exécution ne sont pas partagés avec d’autres locataires. Il ne s’agit pas d’une solution de machine virtuelle qui divise un hôte entre plusieurs utilisateurs.

Configuration livrée selon les spécifications M4, mémoire et stockage de la commande
Le même compte de commande gère le nœud physique pendant toute la durée de la location
La région du nœud est celle indiquée par la commande et renvoyée en temps réel par la console

Couche compte

Commandes, connexions et tickets associés

Le compte sert à identifier la commande, consulter la durée de location et envoyer des tickets d’assistance. L’équipe doit utiliser une adresse e-mail professionnelle capable de recevoir durablement les informations de vérification et supprimer rapidement les membres qui ne participent plus au projet.

Ne partagez pas les identifiants de connexion à la console
Mettez immédiatement à jour les mots de passe après tout changement d’équipe
Associez les questions de facturation et de nœud au numéro de commande

Couche connexion

Les identifiants sont gérés en continu par l’utilisateur

SSH convient à l’automatisation et aux tâches en ligne de commande, tandis que VNC est adapté aux opérations graphiques. Après la première connexion, mettez à jour le mot de passe initial, ajoutez la clé publique SSH de votre équipe et vérifiez les services exposés.

Conservez les clés privées uniquement sur des appareils contrôlés ou dans un gestionnaire de clés
Attribuez une clé distincte à chaque membre ; ne partagez pas le même fichier
N’ouvrez que les ports d’écoute réellement nécessaires à la charge de travail

Couche processus

Les informations d’incident doivent être reproductibles

La plateforme peut aider à vérifier l’état du nœud, les points d’accès et les journaux d’incident. Après réception de l’heure, de la région du nœud, du numéro de commande, des étapes de reproduction et de preuves expurgées, l’analyse peut commencer à partir d’un moment précis.

Conservez les extraits essentiels de la sortie des commandes et des journaux applicatifs
Indiquez l’heure de la dernière exécution normale
Distinguez les problèmes réseau, système, chaîne d’outils et application métier

Isolation dédiée

Une commande correspond à un équipement physique, sans instance d’exécution partagée

VMKeep fournit un Mac dans le cloud sur machine physique dédiée. Le système d’exploitation, les processus, l’espace mémoire et le disque local s’exécutent sur le nœud physique attribué à la commande, sans partager la même instance virtuelle avec d’autres locataires.

L’exclusivité physique isole les ressources de calcul et l’environnement d’exécution, mais ne remplace pas les droits des dépôts, la rotation des clés, le chiffrement des données ni le contrôle d’accès propre aux applications. L’équipe doit toujours appliquer le principe du moindre privilège selon la sensibilité du projet.

Attribution de l’équipement VMKeep

Une machine physique dédiée est livrée selon la configuration de la commande et le nœud sélectionné.

Comptes système Équipe utilisatrice

Configure les mots de passe, les clés publiques SSH, les droits des membres et les services locaux.

Projets et données Équipe utilisatrice

Gère les dépôts, modèles, artefacts de build, jetons, sauvegardes et chiffrement.

Collaboration en cas d’incident Les deux parties

La plateforme vérifie le nœud et les accès ; l’utilisateur fournit des preuves expurgées et reproductibles.

Ce que l’isolation garantit

Les ressources d’exécution ne sont pas partagées avec d’autres locataires

Une configuration fixe du processeur et de la mémoire facilite la reproductibilité des builds, le fonctionnement continu des runners et la comparaison des résultats de tests d’inférence MLX sur le même matériel.

Ce que l’isolation ne remplace pas

Les droits applicatifs et les règles de données doivent toujours être configurés

Les accès aux dépôts, jetons métier, fichiers de modèles, éléments de signature, ports exposés et cycles de sauvegarde sont gérés par l’équipe utilisatrice selon ses propres processus.

Gestion des identifiants d’accès

Après la première connexion, remplacez immédiatement l’accès temporaire par votre propre contrôle

Intégrez l’initialisation de la connexion à la checklist de mise à disposition de chaque nouveau nœud. Vérifiez les mots de passe, clés SSH, droits des membres et ports d’écoute avant de synchroniser le code et les données.

01
Mettez à jour le mot de passe initial

Changez le mot de passe système après la première connexion. Évitez de conserver des mots de passe en clair dans les conversations, journaux de build ou documents du projet. Le mot de passe doit être géré séparément des autres systèmes internes.
02
Ajoutez une clé publique SSH dédiée

Configurez une clé publique distincte pour chaque membre ayant besoin d’un accès en ligne de commande. Ne téléversez pas la clé privée sur le Mac dans le cloud et ne la transmettez pas par e-mail ou messagerie classique.
03
Limitez la distribution des identifiants

Utilisez des identifiants différents pour le runner CI, les scripts de déploiement et les opérations manuelles. Accordez à chaque jeton uniquement les privilèges nécessaires à sa tâche.
04
Révoquez les accès lors d’un départ ou d’un changement d’équipe

Lorsqu’un membre quitte le projet ou change de rôle, révoquez sa clé publique SSH, ses jetons de dépôt et ses droits système, puis vérifiez que les tâches automatisées n’utilisent plus d’anciens identifiants.

Protection des données

Gérez séparément le code, les modèles, les éléments de signature et les données métier

Un Mac dans le cloud peut exécuter durablement des tâches de build et d’inférence, mais être en ligne en continu ne signifie pas être sauvegardé. L’équipe doit définir des processus clairs de classification, chiffrement, export vérifié et test de restauration.

REPO

Dépôts de code

Utilisez les droits des membres et les identifiants de déploiement propres au dépôt. Limitez la portée des jetons automatisés et n’inscrivez pas de jetons longue durée dans les scripts, images ou journaux de build.

Points à vérifier : portée des droits, durée de validité des jetons, expurgation des journaux

BUILD

Artefacts de build

Distinguez les caches régénérables des artefacts de livraison à archiver. Attribuez aux paquets, fichiers de symboles et rapports de test une version et un emplacement d’export traçables.

Points à vérifier : version, valeur de contrôle, archivage externe

MODEL

Fichiers de modèles

Consignez la source du modèle, sa version quantifiée, ses paramètres et ses dépendances d’exécution. Chiffrez les modèles sensibles et limitez l’adresse d’écoute ainsi que les droits d’appel du service d’inférence.

Points à vérifier : source, version, périmètre d’accès, chiffrement

SIGN

Éléments de signature

Séparez les certificats, clés privées et mots de passe associés des fichiers ordinaires du projet. Ne fournissez les éléments nécessaires qu’au moment du build, puis supprimez les copies temporaires à la fin de la tâche.

Points à vérifier : exposition minimale, copies temporaires, processus de révocation

DATA

Données métier

Décidez de l’utilisation du nœud selon le niveau de sensibilité. Chiffrez les données à conserver et synchronisez-les vers un emplacement de sauvegarde contrôlé par l’équipe ; vérifiez régulièrement leur restauration.

Points à vérifier : classification, chiffrement, sauvegarde, validation de restauration

Bonnes pratiques de fiabilité

Gérez les incidents avec des contrôles d’état, une chronologie et des preuves reproductibles

Tous les nœuds fonctionnent normalement 365 jours par an, sans arrêt périodique programmé. La plateforme vérifie en continu l’état des nœuds, les points d’accès et les incidents. En cas de problème d’accès ou de tâche, elle commence par déterminer l’étendue de l’impact, vérifie ensuite l’état du nœud et de la connexion, puis s’appuie sur les journaux fournis pour localiser le problème au niveau du système, de la chaîne d’outils ou de l’application.

VMKeep ne remplace pas des procédures concrètes par un taux de disponibilité impossible à vérifier. Pour l’équipe utilisatrice, il est plus utile de consigner précisément l’heure de l’incident, le dernier état normal, les tâches affectées et les actions déjà réalisées.

Ouvrir un ticket depuis la console Voir les moyens de contact

Fiche de gestion des incidents de sécurité Du symptôme à la récupération

ÉTAPE 01

Déterminez l’étendue de l’impact

Une commande, un projet, l’ensemble du nœud ou le point d’accès distant.

ÉTAPE 02

Vérifiez l’état du nœud

Vérifiez la commande, la région, les informations de connexion et l’heure de la dernière exécution normale.

ÉTAPE 03

Conservez les preuves de l’incident

Rassemblez les journaux expurgés, la sortie des commandes, les codes d’erreur et les étapes de reproduction fiables.

ÉTAPE 04

Mettez en œuvre l’assistance à la récupération à distance

Déterminez les actions à effectuer au niveau de la connexion, du système ou de l’application selon l’état du nœud et les preuves disponibles.

ÉTAPE 05

Consignez le résultat et les actions suivantes

Confirmez le rétablissement de la tâche et conservez la liste des éléments à faire pivoter ou corriger.

Rapport d’incident de sécurité

Un rapport exploitable doit contenir six catégories de champs clairement renseignés

Si vous suspectez un accès non autorisé, une fuite d’identifiants, un processus inhabituel ou un risque lié aux données, cessez de diffuser des informations sensibles, conservez la chronologie originale et envoyez les éléments expurgés via un ticket de la console ou à support@vmkeep.com.

Champs du rapport SECURITY INCIDENT INTAKE

01

Heure de l’incident

Indiquez le fuseau horaire, l’heure de la première détection et celle de la dernière confirmation d’un fonctionnement normal.
02

Région du nœud

Copiez les informations de région depuis la commande ; ne les remplacez pas par l’emplacement de sortie réseau.
03

Numéro de commande

Il sert à associer le nœud, la période de location et les demandes d’assistance. Ne fournissez aucune donnée de paiement.
04

Étendue de l’impact

Précisez les membres, projets, services, fichiers ou tâches de build concernés.
05

Procédure de reproduction

Énumérez dans l’ordre les commandes, opérations, résultats attendus et symptômes observés.
06

Preuves expurgées

Joignez les codes d’erreur et les extraits de journaux nécessaires, en supprimant les mots de passe, clés privées, jetons complets et éléments de signature.

Commande existante

Privilégiez l’envoi d’un ticket depuis la console

Un ticket peut être directement associé à la commande et au nœud. Il convient aux problèmes de connexion, à l’état du nœud, à la facturation et au suivi continu.

Accéder à la console

Rapport de sécurité

Envoyez les informations expurgées par e-mail d’assistance

L’objet peut contenir « Rapport de sécurité », le numéro de commande et la région du nœud. N’envoyez ni mot de passe de compte, ni clé privée, ni jeton complet.

Envoyer à support@vmkeep.com

Limites de mise à disposition et de restitution

Avant la fin de la location, remettez la machine dans un état ne contenant plus les actifs de l’équipe

N’attendez pas le dernier moment pour migrer vos ressources. Vérifiez d’abord que les données peuvent être restaurées ailleurs, révoquez ensuite les accès externes, puis supprimez les copies locales et les identifiants automatisés du nœud.

Pendant la location

Organisez continuellement les actifs à migrer

Conservez le code principalement dans un dépôt distant ; ne faites pas du nœud votre copie unique
Synchronisez les artefacts de build par version vers l’emplacement d’archivage de l’équipe
Consignez les versions des modèles, de la chaîne d’outils et des dépendances système
Vérifiez régulièrement les droits des membres et les jetons automatisés

Avant la fin

Exportez et vérifiez le résultat de la restauration

Exportez les fichiers, journaux et résultats de build à conserver
Vérifiez à l’emplacement cible que les fichiers sont lisibles et que le projet peut être restauré
Arrêtez les runners, services d’inférence et tâches planifiées
Confirmez qu’aucun build ni aucune synchronisation n’est en attente

Vérification finale

Révoquez les accès et supprimez les identifiants

Révoquez les jetons de dépôt, jetons de déploiement et clés de service
Supprimez les clés publiques SSH, certificats temporaires et éléments de signature
Supprimez les copies locales des modèles, données métier et caches
Confirmez que l’équipe n’a plus besoin d’aucun fichier présent sur la machine

Commencer à configurer un nœud dédié

Choisissez d’abord la configuration, le nœud et la durée, puis intégrez la checklist de sécurité au processus de mise à disposition

Les trois configurations de machines physiques dédiées Apple Silicon peuvent être louées à la journée, à la semaine, au mois ou au trimestre. La disponibilité réelle est celle renvoyée en temps réel par la console.

Louer un Mac dans le cloud Voir les trois offres Lire le guide de connexion et de migration