Modèle de sécurité des nœuds physiques dédiés

Définissez clairement le périmètre de sécurité de votre Mac dans le cloud

Chaque commande correspond à une machine physique dédiée pour une durée de location définie, et non à une machine virtuelle. ZoomMini exploite le nœud physique et la console ; le client gère les comptes système, la configuration des applications, le code, les secrets et les sauvegardes. Des responsabilités claires permettent d’auditer et de révoquer les accès.

Louer immédiatement un Mac mini dédié Consulter le guide de traitement des problèmes de sécurité
  • 1 commande correspond à 1 machine physique dédiée
  • Les accès distants, les droits système et les secrets applicatifs sont gérés par niveaux
  • Tous les nœuds fonctionnent normalement 365 jours par an
PÉRIMÈTRE DE SÉCURITÉ Vue d’isolation de la commande
Couche physique Mac mini dédié L’environnement système n’est pas partagé avec d’autres clients pendant la durée de la commande
Couche des accès Console et connexions distantes État de l’appareil, adresse et instructions de connexion
Couche système Comptes et droits Le client configure des comptes uniques avec les privilèges minimaux
Couche des charges de travail Code, secrets et builds Le client contrôle le stockage, la rotation et la migration
Périmètre identifiable PHYSIQUE / ACCÈS / CHARGE DE TRAVAIL
Modèle d’isolation

L’isolation physique élimine les conflits de ressources partagées ; l’isolation des droits doit toujours être configurée par le client

Une machine physique dédiée place les charges de travail du client dans un périmètre matériel clairement défini. Toutefois, une machine dédiée ne rend pas automatiquement sûrs tous les comptes, accès distants et identifiants applicatifs. Un modèle d’isolation réellement opérationnel associe les couches physique, de contrôle, système et applicative.

Périmètre du nœud physique

Chaque commande active correspond à une machine physique dédiée et à une durée de location définie. Il ne s’agit pas d’une machine virtuelle partagée : le processeur, la mémoire et le stockage local ne sont pas attribués à d’autres clients sous forme de sessions virtuelles mutualisées.

  • Objet du périmètreCommande, appareil, nœud, durée de location
  • Où vérifierDétails de l’instance dans la console
  • Action du clientConfirmer l’identifiant de l’appareil et les dates de début et de fin de location

Périmètre des accès distants

La console permet de consulter l’état de l’appareil et les informations de connexion ; VNC, le partage d’écran et SSH permettent d’accéder au système. La session de la console et la session du système d’exploitation constituent deux niveaux de privilèges distincts : protégez-les séparément et n’utilisez pas de mots de passe faibles communs.

  • Opérations graphiquesUtiliser VNC ou le partage d’écran
  • Tâches automatiséesPrivilégier des clés SSH contrôlées
  • Traitement des anomaliesLimiter d’abord les accès, puis vérifier les sessions système

Périmètre des droits système

L’obtention d’une adresse distante ne doit pas donner automatiquement tous les droits système. Les droits administrateur, le compte de développement quotidien, le runner CI et les comptes temporaires de dépannage doivent être séparés, accordés selon la tâche, puis révoqués rapidement une fois celle-ci terminée.

  • AdministrateurRéservé aux modifications système
  • Compte de développementUtilisé pour les tâches interactives quotidiennes
  • RunnerDispose uniquement des droits sur les répertoires et commandes nécessaires au build
Contrôle des accès

Transformez chaque connexion en un accès attribuable, limité et révocable

L’objectif du contrôle des accès n’est pas d’ajouter des étapes de connexion, mais de permettre à l’équipe de répondre à trois questions : qui a accédé à l’appareil, avec quels droits et l’accès a-t-il bien été supprimé après le départ du projet ?

  1. 01

    Attribuer un compte unique à chaque personne

    Évitez qu’un même compte système soit utilisé durablement par plusieurs personnes. Un compte unique associe l’historique du terminal, la propriété des fichiers, les actions du runner et les opérations de dépannage à une personne identifiée, tout en permettant de révoquer individuellement l’accès lors de son départ.

  2. 02

    Privilégier l’authentification par clé SSH

    Utilisez des clés différentes pour chaque personne et chaque tâche automatisée, et consignez leur usage ainsi que leur détenteur. Les clés privées doivent rester sur un terminal contrôlé ou dans un système de gestion des clés ; ne les transmettez ni par ticket, ni par e-mail, ni par messagerie, ni via un dépôt de code.

  3. 03

    Accorder les privilèges minimaux selon la tâche

    Les builds quotidiens ne doivent pas utiliser en permanence les droits administrateur. Limitez le runner CI à ses répertoires de travail, dépôts et commandes nécessaires ; en cas d’élévation temporaire, vérifiez d’abord son objectif puis rétablissez les droits initiaux.

  4. 04

    Faire tourner les identifiants selon les risques et les changements d’équipe

    L’équipe doit faire tourner régulièrement les mots de passe système, les clés SSH et les jetons de dépôt selon sa politique interne. En cas de départ d’un membre, de transfert d’appareil, d’exposition d’une clé ou de connexion inhabituelle, effectuez immédiatement une rotation sans attendre le cycle habituel.

  5. 05

    Supprimer les accès obsolètes

    Supprimez les clés publiques, comptes, enregistrements de runners, éléments enregistrés de bureau distant et tâches automatisées qui ne sont plus utilisés. Désactiver uniquement le compte d’un membre tout en conservant son jeton partagé laisse une voie d’accès persistante difficile à attribuer.

Protection des données

Le client conserve le contrôle du code et des secrets

ZoomMini fournit l’appareil et les accès distants. Le client décide quels codes, artefacts de build, données de test et secrets sont transférés sur l’appareil, et doit effectuer leur vérification, sauvegarde et migration avant la fin de la location.

Canaux de transmission

Choisissez VNC, le partage d’écran ou SSH selon la tâche. Avant la connexion, vérifiez l’adresse et les informations de l’appareil indiquées dans la console ; lors de la première connexion SSH, vérifiez l’empreinte de l’hôte. En cas de changement, interrompez la connexion et recherchez la cause.

À vérifier
Nœud, adresse, empreinte de l’hôte, compte
À éviter
Accepter directement la connexion après avoir ignoré la vérification d’identité

Code et secrets

Le client gère lui-même les identifiants de dépôt, éléments de signature, clés de déploiement et jetons de service. Privilégiez un système de clés contrôlé pour les injecter selon la tâche, définissez leur portée et leur révocation, et ne les écrivez pas dans le dépôt de versions.

À vérifier
Usage, portée, détenteur, méthode de rotation
À éviter
Configuration en clair, secrets codés en dur dans les scripts, jetons partagés

Anonymisation des journaux

Avant de transmettre des informations de dépannage, supprimez les mots de passe, clés privées, jetons complets, identifiants de paiement complets et données personnelles sans rapport avec le problème. Conservez l’heure, les commandes, les codes d’erreur et le contexte nécessaire afin de permettre la reproduction.

À conserver de préférence
Horodatage, code d’erreur, version, étapes de reproduction
À supprimer impérativement
Mots de passe, clés privées et secrets complets

Migrer les données avant la fin de la location

Migrez le code, les artefacts de build, les journaux et les données métier avant l’échéance, puis vérifiez que les sauvegardes sont lisibles. Révoquez ensuite les jetons de dépôt, identifiants de déploiement et enregistrements de runners, et supprimez les copies locales inutiles.

Critères de finalisation
Données migrées, sauvegarde vérifiable, accès révoqués
Où vérifier
État de l’appareil et date d’expiration dans la console
Ordre des opérations avant l’échéance

Ne confondez pas « déjà copié » et « migration terminée »

1. InventorierLister le code, les artefacts, les caches, les journaux et les secrets
2. CopierMigrer vers un stockage cible ou un nouvel environnement contrôlé par le client
3. VérifierContrôler l’intégrité d’un échantillon de fichiers et effectuer les tests de restauration nécessaires
4. RévoquerFaire tourner les jetons, dissocier le runner et supprimer les accès distants
Sécurité CI/CD

La machine de build peut rester disponible en continu ; les secrets ne doivent pas rester exposés

Les environnements d’intégration continue disposent souvent de droits de lecture du dépôt, de signature, de test et de publication. Séparez ces capacités en secrets distincts, injectez-les à chaque étape du pipeline et veillez à pouvoir renouveler ou révoquer chaque secret indépendamment.

01

Accès au dépôt

Les jetons doivent couvrir uniquement les dépôts et opérations nécessaires. Un runner dédié à la récupération ne doit pas disposer de droits d’administration, et une tâche temporaire ne doit pas réutiliser un jeton de publication permanent.

Limiter la portée
02

Build et tests

Le runner utilise un compte et un répertoire de travail dédiés. La source des caches de dépendances doit être vérifiable ; les scripts de build doivent éviter d’afficher les variables d’environnement et les secrets présents dans les en-têtes de requête.

Compte isolé
03

Éléments de signature

Placez les certificats de signature et leurs clés privées dans un système de gestion des clés contrôlé, et injectez-les uniquement dans les tâches qui signent. Supprimez les fichiers temporaires et l’environnement des processus à la fin de la tâche.

Injection à la demande
04

Identifiants de publication

Séparez les jetons de publication des jetons de dépôt ; le pipeline de test ne doit pas hériter des droits de publication en production. Lors d’un changement de personne ou de projet, révoquez-les séparément sans perturber les autres tâches.

Révocation indépendante
Contrôle avant mise en production

Rechercher les chemins d’exposition des secrets dans les scripts et les journaux

Vérifiez si les scripts de build affichent des variables d’environnement, si la gestion des erreurs renvoie la commande complète, si le cache contient des fichiers d’identifiants et si l’archive d’artefacts inclut par inadvertance des fichiers de configuration. Si un secret apparaît dans les journaux, ne vous contentez pas de les supprimer : faites aussi tourner l’identifiant concerné.

pipeline-security-check 
$ git grep -nE "TOKEN|PRIVATE_KEY|PASSWORD" -- .
$ find build/ -type f -name "*.env" -o -name "*.key"
$ security find-identity -v -p codesigning
$ launchctl list | grep runner

Résultats du contrôle :
✓ Aucun secret en clair trouvé dans le dépôt
✓ Aucun fichier d’identifiants dans l’archive de build
✓ Le runner utilise un compte système distinct
✓ Les éléments de signature sont injectés par un processus contrôlé
État de fonctionnement

Décrire le fonctionnement du service avec des objectifs clairs et des journaux d’événements

L’objectif de disponibilité du service ZoomMini est de 99,9 %. Tous les nœuds fonctionnent normalement 365 jours par an. Les relevés sont présentés jour par jour ; un marqueur d’événement signale un changement d’état à vérifier et ne signifie pas automatiquement une indisponibilité sur toute la journée.

Objectif de disponibilité 99,9 % Selon les méthodes de calcul et d’audit définies dans les conditions de service
État quotidien des 90 derniers jours Chaque barre d’état correspond à 1 jour
Fonctionnement normal Événement signalé

Si le client estime que le service n’a pas atteint l’objectif, il doit ouvrir un ticket dans la console et fournir l’identifiant de la commande, le nœud, la période concernée, les symptômes reproductibles et les journaux anonymisés. Les demandes éligibles sont examinées selon les conditions de service et donnent lieu à un crédit de service.

Consulter les conditions de service et les critères d’examen
Traitement des incidents de sécurité

Limiter d’abord les accès, puis conserver suffisamment de preuves

En cas de suspicion d’anomalie de compte, d’accès non autorisé ou de fuite de secrets, évitez de poursuivre des tâches à privilèges élevés en attendant une conclusion complète. Réduisez d’abord l’impact, conservez ensuite les éléments nécessaires, informez l’équipe d’assistance et faites tourner les secrets.

  1. 01

    Délimiter l’anomalie

    Notez l’heure de découverte, l’identifiant de l’appareil, le nœud, le compte concerné, les processus associés et les charges de travail affectées. Distinguez les anomalies de la console, du compte système, du jeton de dépôt et du comportement applicatif afin de ne pas confondre différents niveaux de privilèges.

    ProduireChronologie initiale et objets affectés
  2. 02

    Limiter les accès persistants

    Mettez en pause les tâches automatisées suspectes, révoquez les sessions anormales, désactivez les comptes ou clés publiques concernés et limitez les jetons à haut risque. Ne laissez pas un accès identifié comme anormal continuer à s’étendre pour préserver la scène ; consignez également l’heure et l’exécutant de chaque mesure.

    ProduireListe des accès révoqués et tâches suspendues
  3. 03

    Conserver les journaux nécessaires

    Conservez les journaux de connexion, l’historique des commandes, la sortie du runner, les informations de processus et les codes d’erreur liés à l’incident. Anonymisez les données avant export ; n’envoyez ni mots de passe, ni clés privées, ni identifiants de paiement complets, ni données personnelles sans rapport avec l’incident.

    ProduireJournaux anonymisés et éléments de reproduction
  4. 04

    Informer l’équipe d’assistance

    Via un ticket dans la console ou à l’adresse support@zoommini.com, transmettez l’identifiant de la commande, le nœud, l’heure de survenue, les mesures de limitation prises et les journaux anonymisés. Si le risque persiste, indiquez clairement « incident de sécurité » dans l’objet afin d’accélérer le triage.

    ProduireDescription de l’incident prête pour l’analyse
  5. 05

    Faire tourner les secrets et vérifier la restauration

    Faites tourner, selon l’impact, les identifiants système, clés SSH, jetons de dépôt, clés du runner, éléments de signature et identifiants de déploiement. Avant de relancer les tâches, vérifiez que les anciens identifiants sont invalides, que les nouveaux droits sont minimaux et qu’aucun processus anormal ne subsiste.

    ProduireJournal de rotation et résultat de la vérification de restauration
Informations à inclure lors de l’envoi

Fournir les informations permettant à l’assistance de commencer immédiatement l’analyse

Identifiant de la commandePour localiser le nœud physique correspondant
Nœud et appareilPour confirmer le périmètre de l’environnement concerné
Heure du problèmeIndiquer le fuseau horaire et l’heure de première découverte
Étapes de reproductionDécrire les conditions de déclenchement et le résultat attendu
Mesures déjà prisesLister les opérations de désactivation, révocation et rotation
Journaux anonymisésConserver les codes d’erreur sans joindre de secrets

Commande existante

Ouvrez un ticket depuis la console afin d’associer la demande à la commande, au nœud et à l’état de l’appareil.

Ouvrir un ticket depuis la console
Répartition des responsabilités

ZoomMini exploite l’infrastructure ; le client contrôle les charges de travail

Une répartition claire des responsabilités réduit les attentes et les vérifications répétées lors du dépannage. Les nœuds physiques, la console et la livraison de l’appareil relèvent de ZoomMini ; les comptes, applications, codes, secrets et sauvegardes après l’accès au système relèvent du client.

Comparatif des responsabilités de ZoomMini et du client en matière de protection des données et de sécurité
Domaine de contrôle Responsabilité de ZoomMini Responsabilité du client Point de vérification recommandé
Nœud physique Correspondance dédiée entre l’appareil et la commande, fonctionnement de base du nœud et état de l’appareil dans la console. Utiliser l’appareil selon l’objectif de la commande, gérer les charges de travail et migrer les données pendant la location. Identifiant de l’appareil, nœud, dates de début et de fin de location.
Compte de console Fournir l’accès au compte, la gestion des commandes, l’état de l’instance et l’accès aux tickets. Protéger les identifiants, détecter les accès anormaux et mettre à jour ou révoquer rapidement les droits concernés. Accès récents, changements de commande, historique des tickets.
Connexion distante Fournir dans la console les informations de connexion et l’état de l’appareil correspondant. Vérifier l’adresse et l’empreinte de l’hôte, protéger les identifiants distants et configurer un client fiable. Nœud, adresse, empreinte, compte de connexion.
Compte système Fournir un environnement macOS avec interface graphique et ligne de commande utilisable. Créer des comptes uniques, appliquer le principe du moindre privilège, faire tourner les identifiants et supprimer les membres partis. Liste des comptes, liste des clés publiques, droits administrateur.
Applications et CI/CD Maintenir le fonctionnement des services du nœud physique et de la console. Gérer Xcode, les dépendances, le runner, les scripts, les droits du dépôt et le processus de publication. Compte du runner, répertoire de travail, portée des jetons.
Code et clés Ne pas décider à la place du client où stocker les codes et secrets, ni de leur autorisation ou rotation. Utiliser un système de clés contrôlé et éviter le stockage en clair dans les scripts, dépôts et journaux. Usage, portée, détenteur et méthode de révocation du secret.
Journaux et assistance Analyser les problèmes liés au nœud physique et à la console à partir des informations du ticket. Fournir l’heure exacte, les étapes de reproduction et des journaux anonymisés, sans envoyer de secrets. Codes d’erreur, versions, chronologie, mesures déjà prises.
Sauvegarde et migration Afficher dans la console les informations de location de la commande et de l’appareil. Définir une stratégie de sauvegarde, vérifier la restauration et migrer les données avant la fin de la location. Intégrité des sauvegardes, tests de restauration, révocation des jetons.
Périmètre d’exploitation de ZoomMini

Nœuds physiques et console

Machine physique dédiée associée à la commande, fonctionnement de base du nœud, état de l’appareil, gestion de la commande et traitement des tickets d’assistance.

Périmètre contrôlé par le client

Comptes système et charges de travail

Droits du système d’exploitation, identifiants distants, configuration des applications, code, clés, pipelines de build, anonymisation des journaux, sauvegardes et migration.

Périmètre traité conjointement

Analyse des incidents et vérification de la restauration

Le client fournit la commande, le nœud, la chronologie et les journaux anonymisés ; ZoomMini localise l’état de l’infrastructure selon le périmètre défini, et chaque partie vérifie son propre niveau de privilèges.

Étape suivante

Confirmez d’abord le périmètre, puis migrez vos charges de travail vers un nœud dédié

Après avoir choisi le modèle et la durée de location adaptés, configurez l’environnement avec un compte unique, des clés SSH, le principe du moindre privilège, l’injection contrôlée des secrets et une liste de migration avant échéance.

Louer immédiatement un Mac dans le cloud Voir les étapes de démarrage sécurisé