VMOrbit fournit des nœuds physiques Apple Silicon dédiés et prend en charge la prestation du service ainsi que le fonctionnement des nœuds. Les droits des comptes, les données des projets, les clés, les éléments de signature et la configuration des applications restent sous le contrôle de l’équipe utilisatrice. Cette séparation permet d’appliquer des mesures de sécurité concrètes au développement à distance, à l’intégration continue et à la migration des données.
Un nœud dédié ne dispense pas de configuration. L’isolation physique clarifie la propriété des ressources, mais l’équipe utilisatrice doit continuer à gérer les autorisations des membres, le stockage des clés, les droits sur les projets et la stratégie de sauvegarde.
| Domaine de contrôle | Responsabilité de VMOrbit | Responsabilité du client | Points à vérifier |
|---|---|---|---|
| Prestation du service | Fournir le modèle, le nœud et la durée correspondants à la commande confirmée, puis maintenir le nœud en fonctionnement normal. | Vérifier les informations de la commande, les utilisateurs autorisés et l’environnement de connexion. | Le modèle, la région, la durée de location et le contact correspondent-ils à l’usage prévu ? |
| Droits d’accès | Fournir les procédures de gestion et de support associées à la commande. | Créer des comptes individuels, attribuer le moindre privilège et révoquer l’accès des membres ayant quitté l’équipe. | Existe-t-il encore des comptes, clés ou accès distants sans nécessité opérationnelle ? |
| Données des projets | Maintenir l’environnement du nœud nécessaire au fonctionnement du service hébergé. | Gérer le code, les artefacts de build, les caches, les éléments de signature et les sauvegardes nécessaires. | Les données essentielles disposent-elles d’une copie récupérable hors du nœud ? |
| Configuration des applications | Aider à localiser les problèmes liés au nœud et à la connexion conformément au processus de support. | Gérer la chaîne d’outils, les dépendances, la configuration CI, les droits des jetons et la dépersonnalisation des journaux. | Les changements de configuration sont-ils consignés ? Les valeurs sensibles sont-elles exclues des journaux et des dépôts ? |
Le Mac dans le cloud de VMOrbit est une machine physique dédiée, et non une machine virtuelle. L’équipe doit séparer les personnes, les points d’entrée et les droits des projets en trois niveaux de contrôle indépendants, sans utiliser un même identifiant permanent partout.
Créez une identité individuelle et traçable pour chaque membre qui doit réellement intervenir sur le nœud. Ne partagez ni mot de passe permanent ni clé privée. Attribuez les droits selon les responsabilités — développement, build, audit — et vérifiez régulièrement la liste des membres.
SSH convient à l’administration en ligne de commande et aux tâches automatisées ; VNC convient aux opérations nécessitant l’interface graphique de macOS. N’ouvrez que les accès réellement utilisés et limitez le réseau source ainsi que les plages horaires autorisées.
Les dépôts, systèmes de build, processus de signature et services externes doivent être autorisés séparément. Les droits d’administration du nœud ne doivent pas donner automatiquement accès à toutes les clés de projet ou aux ressources de production.
À qui appartient-elle, à quoi donne-t-elle accès et quand faut-il la révoquer ? Tout identifiant pour lequel l’une de ces réponses manque ne convient pas comme accès permanent.
Chaque membre utilise un compte individuel traçable afin d’éviter le partage d’un même ensemble d’identifiants permanents.
Activez une authentification forte lorsque le système d’identité concerné la prend en charge et désignez un responsable contrôlé pour la procédure de récupération.
Définissez une périodicité de renouvellement pour les clés SSH, les jetons CI et les identifiants du processus de signature, puis vérifiez après chaque changement que les anciennes valeurs sont invalides.
Lorsqu’un membre quitte l’équipe, qu’un appareil est perdu, qu’une responsabilité change ou qu’un identifiant est probablement compromis, révoquez d’abord l’accès, puis évaluez l’impact.
N’inscrivez pas de clés privées, jetons permanents, codes de récupération ou informations de paiement complètes dans le code, les exemples de configuration, l’historique des commandes, les sorties de build ou les messages de support ordinaires.
Vérifiez également les autorisations SSH, les accès VNC, les membres des dépôts, l’enregistrement du runner, les variables d’environnement, le processus de signature et les éventuelles copies locales.
Commencez par confirmer l’identité autorisée, limitez ensuite la source, puis vérifiez les journaux de connexion. En cas d’échec, n’élargissez pas les accès à répétition : examinez successivement les identifiants, le port, le pare-feu local, le chemin réseau et l’état du nœud.
| Point de contrôle | SSH | VNC | Signaux d’anomalie |
|---|---|---|---|
| Tâches concernées | Administration en ligne de commande, automatisation, build et vérification des journaux. | Développement, débogage et utilisation d’outils nécessitant l’interface graphique de macOS. | Le mode de connexion ne correspond pas à la tâche et laisse un accès supplémentaire ouvert durablement. |
| Contrôle des identités | Privilégier des clés SSH individuelles et nettoyer régulièrement la liste des autorisations. | Utiliser des comptes individuels sur le nœud, sans partager d’identifiants de connexion permanents. | Une clé ou un compte inconnu, ou un ancien membre peut encore se connecter. |
| Limitation de la source | Limiter l’accès d’administration aux chemins réseau réellement utilisés par l’équipe. | Ouvrir l’accès uniquement aux membres qui ont besoin d’opérations graphiques et vérifier leur source. | Plusieurs sources inconnues ou tentatives de connexion anormales apparaissent en peu de temps. |
| Vérification des journaux | Vérifier l’heure, la source, le compte et les opérations importantes exécutées. | Vérifier la durée des sessions, les membres autorisés et les déconnexions anormales. | Session sans responsable, connexion à une heure inhabituelle ou changement soudain des droits. |
L’intégration continue se connecte aux dépôts, sources de dépendances, processus de signature et cibles de publication. Configurez ces droits séparément afin qu’un même jeton ne puisse pas lire tous les dépôts, modifier la configuration et publier.
N’enregistrez le runner que sur les dépôts ou groupes de projets qui en ont besoin. Définissez une limite d’exécution distincte pour les tâches issues de branches non fiables et de contributions externes.
Livrable : tableau de correspondance du runner et des dépôtsPlacez les éléments de signature, jetons d’accès et identifiants de déploiement dans un processus contrôlé de gestion des secrets. Injectez-les temporairement selon la tâche, sans les écrire dans le dépôt ni dans des scripts fixes.
Livrable : liste des usages des clés et de leurs responsablesÉvitez d’afficher des valeurs sensibles dans l’écho des commandes, les vidages de variables d’environnement, les traces d’erreur et les pièces jointes de build. Vérifiez et dépersonnalisez les journaux avant de les transmettre au support.
Livrable : règles de dépersonnalisation des journauxAprès chaque tâche, supprimez les fichiers temporaires, les données sensibles en cache et les artefacts de build inutiles, tout en conservant le minimum de traces réellement utile à la reproduction du problème.
Livrable : script de nettoyage post-tâcheL’unique copie présente sur le nœud ne doit pas constituer le plan de reprise de l’équipe. Le code, les artefacts de build, les caches et les éléments de signature ont des valeurs différentes : définissez séparément les règles de synchronisation, de sauvegarde, d’exportation et de nettoyage.
Vérifiez la source du transfert et le répertoire de destination afin de ne pas importer sur le nœud des identifiants sans rapport, des fichiers personnels ou d’anciennes archives.
Séparez le code source, le cache des dépendances, les données de test et les éléments de publication ; définissez les personnes autorisées pour les répertoires sensibles et consignez les changements de configuration importants.
Conservez les copies nécessaires hors du nœud et vérifiez régulièrement qu’elles peuvent être lues et restaurées. Une synchronisation réussie ne suffit pas à valider la restauration.
Avant la fin de la période de location, exportez le code, la configuration, les journaux nécessaires et les résultats de build. Vérifiez que l’environnement cible dispose des outils et des droits nécessaires pour poursuivre le travail.
Révoquez les accès distants, supprimez les clés, jetons, répertoires de travail et fichiers temporaires inutiles, puis confirmez l’exportation avec l’équipe.
Les demandes de support, événements du nœud et opérations nécessaires font l’objet d’enregistrements traçables, selon les politiques et procédures de service applicables. Les informations transmises par le client doivent rester limitées au strict nécessaire pour localiser le problème.
Consignez les informations associées à la commande, la région du nœud, le type de problème, son impact, les étapes de reproduction et les éléments complémentaires afin d’assurer le suivi dans la même conversation.
Organisez les enregistrements autour de la chronologie, des phénomènes observables, des mesures d’isolement prises et du résultat du rétablissement, plutôt que de ne conserver que des conclusions invérifiables.
Lorsque la collaboration est nécessaire, précisez l’objet de l’opération, l’étendue de l’autorisation et son état d’achèvement. Les extraits de journaux doivent se limiter au diagnostic nécessaire et être dépersonnalisés au préalable.
Ne continuez pas à utiliser des identifiants suspects en attendant une conclusion complète. Réduisez d’abord la zone d’impact, conservez ensuite la chronologie nécessaire, renouvelez les identifiants potentiellement concernés, puis ouvrez un suivi via un ticket associé dans la console.
Arrêtez les sessions suspectes, révoquez les comptes ou clés anormaux et suspendez les runners et tâches automatisées concernés. L’isolement doit couvrir les autres points d’entrée susceptibles d’utiliser le même identifiant.
Notez l’heure de découverte, les phénomènes anormaux, la source, les comptes concernés, les changements récents et les actions déjà exécutées. Conservez le minimum de journaux nécessaire sans écraser les informations temporelles d’origine.
Remplacez les clés SSH, identifiants des comptes du nœud, jetons des dépôts et clés CI potentiellement concernés, puis confirmez que les anciennes valeurs sont invalides au lieu de créer simplement de nouvelles valeurs.
Associez la commande correspondante dans la console et indiquez la région du nœud, l’heure, les symptômes, les actions entreprises et les journaux dépersonnalisés. Les deux parties pourront ensuite vérifier et rétablir le service selon l’impact.
Pour une commande existante ou un problème en cours sur un nœud, connectez-vous en priorité à la console et ouvrez le ticket associé. Si la console est inaccessible, envoyez un e-mail à support@vmorbit.com. Les rapports de sécurité, collaborations commerciales et demandes de documents de conformité doivent également être envoyés à cette adresse.
Les problèmes liés à une commande doivent être associés au nœud via un ticket dans la console ; si vous ne pouvez pas vous connecter ou pour une question générale de sécurité, utilisez l’adresse e-mail du support. Nous ne demandons pas l’envoi d’identifiants secrets par e-mail ordinaire.
Avant de choisir le modèle, le nœud et la durée, définissez les membres autorisés, les accès distants, le responsable des sauvegardes et le contact chargé des incidents. La disponibilité et les informations de livraison affichées en temps réel dans la console font foi.