Modèle de sécurité et responsabilités

Distinguez d’abord isolation, accès et état avant de sécuriser chaque build.

Chaque commande correspond à une machine physique dédiée, et non à une machine virtuelle. L’isolation de l’appareil n’est qu’un point de départ : les identifiants, les sessions distantes, les éléments de signature, les sauvegardes et la configuration du projet doivent être gérés séparément selon les processus de développement.

Louer un Mac dans le cloud Voir le parcours de dépannage

Base d’isolation

1 commande correspond à 1 hôte dédié

Le calcul et le stockage local sont dédiés à la commande

Les liaisons réseau amont reposent sur une infrastructure partagée

L’utilisateur contrôle les comptes, les clés et les autorisations des projets

Un appareil dédié ne signifie pas que le réseau, les dépôts, les cibles d’envoi et les comptes d’équipe sont automatiquement isolés. Chaque couche doit faire l’objet de réglages d’accès et de signaux de surveillance distincts.

Modèle d’isolation

Seul l’hôte est dédié, pas l’ensemble du chemin réseau.

Pour évaluer le niveau d’isolation, vérifiez séparément l’appareil, le réseau, les comptes et les systèmes externes. Ne confondez pas « machine physique dédiée » avec une exclusivité automatique à tous les niveaux.

Couche appareil : dédié à la commande

Chaque commande valide correspond à une machine physique dédiée. Le CPU, la mémoire et le stockage local de l’appareil ne sont pas divisés en plusieurs instances virtuelles partagées avec d’autres commandes. L’interface graphique macOS et la ligne de commande peuvent être utilisées directement pour le build, le débogage et l’exécution des tâches.

Les autres commandes ne peuvent pas se connecter à cet hôte ni y planifier de tâches.
Le cache de build, le répertoire de travail et les journaux locaux restent dans l’environnement de l’appareil actuel.
Avant de libérer l’hôte, l’utilisateur doit migrer les données à conserver.

Couche réseau : infrastructure partagée

La sortie du centre de données, les liaisons opérateur et le routage Internet peuvent être partagés par plusieurs appareils. Un hôte dédié ne signifie donc pas que le chemin public l’est aussi : la qualité de connexion et les règles d’accès doivent être surveillées séparément.

N’ouvrez que les adresses, ports et services réellement nécessaires au workflow.
Les dépôts, les cibles d’envoi des artefacts et les sources de dépendances doivent continuer à utiliser leurs propres contrôles d’accès.
En cas d’anomalie, consignez séparément l’état de l’hôte, l’état de la connexion et la réponse du service cible.

Comptes et identifiants

Après la première connexion, commencez par réduire la surface d’accès.

Ne considérez pas les informations de connexion fournies à la livraison comme une porte d’entrée partagée durable. Après la première connexion, mettez immédiatement en place un accès traçable, révocable et renouvelable.

Mettre à jour les identifiants initiaux

Après la première connexion, mettez à jour les identifiants système et vérifiez que les anciens ne sont plus utilisés dans les scripts automatisés, l’historique du terminal ou la documentation d’équipe.

Privilégier les clés

Pour les connexions en ligne de commande, privilégiez des clés distinctes. Attribuez des clés différentes aux membres et aux tâches automatisées afin de pouvoir révoquer une seule source d’accès.

Éviter les comptes partagés

L’utilisation d’un même compte système par plusieurs personnes rend l’origine des actions difficile à établir. Attribuez les droits selon les responsabilités et ne laissez pas les privilèges de développement courants couvrir les opérations d’administration.

Examiner régulièrement les autorisations

Lors d’un changement de membre, à la fin d’un projet ou lors de l’arrêt d’une tâche automatisée, vérifiez si les comptes, clés, jetons de dépôt et identifiants d’envoi sont encore nécessaires.

Contrôle minimal des autorisations

Après chaque changement de membre ou de pipeline, vérifiez ces cinq points d’entrée.

Compte systèmeConserver uniquement l’opérateur actuel
Clés publiques SSHSupprimer les clés obsolètes
Autorisations du dépôtLimiter aux projets nécessaires
Variables d’environnementLimiter le périmètre de lecture
Identifiants d’envoiAutoriser séparément selon la tâche

Protection des accès distants

Limitez les points d’entrée au strict nécessaire pour le workflow.

SSH, VNC et le partage d’écran macOS répondent à des usages différents. Après avoir choisi le mode de connexion, configurez également le périmètre d’ouverture, le comportement des sessions, la version du client et le rythme de renouvellement des identifiants.

Liste de contrôle des accès distants
Point à vérifier	Action à effectuer	Pratique à éviter	Signal de validation
Périmètre d’ouverture	Ne conserver que les points d’entrée nécessaires au mode de connexion actuel et aux tâches automatisées.	Élargir temporairement l’accès pour dépanner puis oublier de le réduire.	Les points d’entrée inutilisés ne permettent pas d’établir une connexion.
Verrouillage de session	Verrouiller l’interface en quittant la session graphique et se déconnecter activement à la fin de la tâche.	Conserver une session authentifiée ouverte sur un terminal partagé.	Une nouvelle vérification est requise lors de la reconnexion.
Mise à jour du client	Utiliser un client SSH, VNC ou de partage d’écran maintenu.	Conserver durablement un ancien client dont l’origine ne peut pas être vérifiée.	La version du client correspond à la base de référence de l’équipe.
Vérification des anomalies	Contrôler les heures de connexion, les sources, les sessions actives et les changements de configuration récents.	Conclure que l’accès fonctionne uniquement parce que l’hôte est en ligne.	Chaque session active correspond à un opérateur réel identifié.
Renouvellement des identifiants	Renouveler immédiatement les identifiants après le départ d’un membre, un doute sur une exposition de clé ou une modification des autorisations.	Copier le même identifiant dans plusieurs projets et appareils de membres.	Les anciens identifiants sont invalides et les nouveaux existent uniquement aux endroits nécessaires.

Optimiser un réseau faible sans élargir la surface d’accès

Réduire la qualité graphique, fixer la résolution ou limiter les animations peut améliorer l’expérience distante, sans ajouter de point d’entrée ouvert. Pour un problème de connexion, vérifiez d’abord séparément la latence, la bande passante, les réglages du client et les sessions simultanées.

Voir les méthodes d’accès distant

Cycle de vie des données

Dès la première synchronisation, prévoyez le chemin de migration finale.

Pendant la période de location, l’utilisateur organise et sauvegarde le code source, les caches de build, les modèles, les ressources et les artefacts. N’attendez pas la libération de l’hôte pour déterminer quelles données doivent être récupérées.

Intégration

Définir les sources et les destinations des données

Répertoriez les dépôts, sources de ressources, caches de dépendances et cibles d’artefacts. Séparez les données régénérables de celles à conserver afin de ne pas faire de l’hôte votre unique copie.

Exécution

Faire suivre la sauvegarde au rythme des builds

Synchronisez les changements du code source, les artefacts exportés et les configurations essentielles au rythme du projet. Les tâches automatisées doivent préciser quels journaux conserver en cas d’échec et quels résultats envoyer en cas de succès.

Migration

Vérifier que la copie est réellement utilisable

Ne vérifiez pas seulement que les fichiers ont été copiés. Testez l’extraction d’une archive, la détection des configurations nécessaires par le projet et l’intégrité des artefacts, puis consignez les versions requises pour la restauration.

Libération

Terminer l’utilisation après une vérification point par point

Avant de libérer l’hôte, vérifiez que les artefacts, le code source, les certificats, les fichiers de description, la configuration du projet et les caches nécessaires ont été traités selon les règles de l’équipe, puis révoquez les jetons et clés externes devenus inutiles.

Protection des éléments de build

Les autorisations de signature, de dépôt et d’envoi ne doivent pas reposer sur un même secret tout au long du processus.

Séparez la lecture du code source, l’exécution du build, la signature et l’envoi des artefacts en domaines d’autorisation distincts. Même si un élément doit entrer sur l’hôte, limitez sa visibilité, sa durée de validité et sa présence dans les journaux.

Principes de séparation des autorisations et de masquage des éléments de build
Élément	Autorisations recommandées	Mode d’injection	Traitement des journaux
Certificat de signature	Autoriser uniquement les tâches et opérateurs qui doivent signer.	Importer lors d’une étape contrôlée, sans le disperser dans un répertoire partagé.	Ne pas afficher les mots de passe de certificat, d’exportation ni les identifiants complets.
Fichier de description	Gérer séparément par projet et environnement cible.	Faire sélectionner un fichier explicite par la tâche de build, sans correspondance ambiguë.	Conserver le type de fichier et le résultat de correspondance, en masquant les champs sensibles.
Variable d’environnement	La fournir uniquement aux processus qui l’utilisent réellement.	L’injecter à l’exécution, sans l’écrire dans le code source ni dans une configuration publique.	Masquer les secrets dans l’écho des commandes, les traces d’erreur et la sortie de débogage.
Jeton de dépôt	Privilégier la lecture seule et limiter aux dépôts nécessaires.	Le lire depuis l’environnement de tâche, sans le commiter dans le dépôt.	Supprimer le jeton des URL distantes et des en-têtes de requête.
Clé d’envoi	Autoriser uniquement l’écriture vers la cible d’artefacts indiquée.	La séparer des identifiants de lecture du code source et la charger selon l’étape du pipeline.	Conserver le code de réponse et l’identifiant de tâche, sans enregistrer la clé complète.

Principe de séparation des autorisations

Une tâche ne reçoit que les autorisations nécessaires à l’étape en cours.

Une tâche qui récupère le code source n’a pas besoin des droits d’envoi ; une tâche de test n’a pas besoin de lire les éléments de signature ; une tâche d’envoi d’artefacts n’a pas besoin de modifier le dépôt.

Principe de masquage

Conserver le contexte de dépannage et supprimer les secrets directement réutilisables.

Les journaux peuvent conserver l’heure, l’étape, le code de sortie, le type de fichier et l’emplacement de l’erreur, mais doivent supprimer les mots de passe, clés privées, jetons, en-têtes complets et extraits de code source non masqués.

Fiabilité d’exécution

Un nœud fonctionnel ne signifie pas que chaque connexion et chaque tâche de build fonctionnent.

Tous les nœuds fonctionnent normalement 365 jours par an. Pour diagnostiquer un problème précis, surveillez séparément les états du nœud, de l’hôte, de la connexion et de la tâche, plutôt que de résumer tout le workflow par un seul indicateur vert.

État du nœud

Accessibilité de l’infrastructure

Surveillez le réseau global et les capacités de gestion du nœud afin de déterminer si le problème affecte les services de base du même nœud.

Ne permet pas à lui seul de prouver

que la session système d’un hôte ou la tâche d’un projet fonctionne déjà.

État en ligne de l’hôte

Démarrage terminé de l’appareil

Vérifiez que l’hôte est en ligne et que l’interface de gestion peut lire l’état actuel de l’appareil.

Ne permet pas à lui seul de prouver

que l’adresse, le port et les identifiants SSH, VNC ou de partage d’écran sont tous corrects.

État de la connexion

Établissement réussi de la session

Consignez le mode de connexion, le client, l’adresse cible, le port, le réseau local et l’occupation de la session.

Ne permet pas à lui seul de prouver

que Xcode, les dépendances, les éléments de signature et la configuration du projet permettent de terminer le build actuel.

État de la tâche

Achèvement des étapes du build

Évaluez l’exécution à partir des journaux par étape, du code de sortie, de la validation des artefacts et du résultat de l’envoi.

Ne permet pas à lui seul de prouver

qu’une panne d’infrastructure affecte le nœud ou le réseau ; combinez-le aux trois premiers signaux.

Nœud Signal d’infrastructure

Hôte Signal d’appareil en ligne

Connexion Signal d’accessibilité de la session

Tâche Signal d’exécution du projet

Processus de signalement des incidents

Commencez par établir les faits, puis fournissez un contexte reproductible.

Un signalement de qualité permet au support de distinguer rapidement les problèmes de nœud, d’hôte, de connexion et de projet. Écrire seulement « impossible à utiliser » fait perdre des informations essentielles et multiplie les demandes de précision.

Informations à consigner avant l’envoi

Sept informations constituent le dossier minimal d’incident.

01 Heure de survenue

Indiquez le fuseau horaire et la période au cours de laquelle le problème est apparu pour la première fois.

02 Nœud

Précisez : Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong ou côte Est des États-Unis.

03 Identifiant de commande

Fournissez l’identifiant de commande ou d’hôte vérifiable dans la console.

04 Périmètre de l’impact

Indiquez si un seul travail, l’hôte entier ou plusieurs membres sont concernés.

05 Étapes de reproduction

Listez les entrées, actions et points d’échec dans l’ordre réel des opérations.

06 Comparaison des états

Indiquez séparément l’état du nœud, de l’hôte, de la connexion et de la tâche.

07 Journaux masqués

Conservez le contexte de l’erreur et supprimez les mots de passe, clés privées, jetons et secrets du code source.

Problème concernant une commande existante

Connectez-vous à la console pour envoyer un ticket et associez-y l’identifiant de commande. Cette procédure convient aux problèmes de connexion, d’état de l’hôte, de stockage supplémentaire, de renouvellement et de libération.

Envoyer un ticket depuis la console

Question de sécurité et de confidentialité

Envoyez l’heure de l’incident, son impact et les éléments masqués à l’adresse du support. N’incluez pas de mots de passe, clés privées, informations de paiement complètes ni code source non masqué.

support@minidebug.com

Responsabilités

La plateforme prend en charge les nœuds et la gestion ; l’utilisateur prend en charge les accès et les données de son workflow.

Définir les responsabilités ne consiste pas à rejeter le problème sur l’autre partie, mais à identifier directement le bon point de contrôle, les preuves et les actions à prendre lorsqu’un incident survient.

Responsabilités de MiniDebug

Nœuds physiques et interface de gestion

Livraison de l’hôte physique
Fournir une machine physique dédiée conformément à la commande et afficher l’état de l’hôte et de la commande dans l’interface de gestion.
Infrastructure des nœuds
Maintenir normalement toute l’année, 365 jours par an, les cinq nœuds de Singapour, du Japon (Tokyo), de la Corée du Sud (Séoul), de Hong Kong et de la côte Est des États-Unis.
Fourniture des informations de connexion
Fournir les informations de connexion correspondant à l’hôte actuel ainsi que les fonctions de gestion nécessaires.
Diagnostic des incidents d’infrastructure
Localiser les problèmes du nœud physique et de l’interface de gestion à partir de l’identifiant de commande, du nœud, de l’heure et des journaux masqués.
Gestion du cycle de vie de la commande
Gérer la commande, le renouvellement, l’état de l’hôte et la libération ; l’état réellement disponible est celui renvoyé en temps réel par la console.

Responsabilités de l’utilisateur

Comptes, code, identifiants et configuration du projet

Autorisations des comptes et des membres
Protéger les identifiants de connexion, contrôler les accès des membres de l’équipe et révoquer rapidement les comptes et clés devenus inutiles.
Droits d’utilisation du code et des éléments
Vérifier que le code source, les modèles, les ressources, les certificats, les fichiers de description et les autres éléments de build peuvent être utilisés conformément aux autorisations requises.
Configuration de l’environnement du projet
Gérer les versions de Xcode, les dépendances, les scripts, les chemins, les règles de signature, les variables d’environnement et les cibles d’envoi.
Sauvegarde et migration des données
Sauvegarder le code source et les artefacts pendant la période de location, puis effectuer la migration et la vérification de restauration nécessaires avant de libérer l’hôte.
Masquage des journaux et collaboration sur les incidents
Fournir suffisamment de contexte reproductible tout en supprimant les mots de passe, clés privées, jetons, informations de paiement et code source non masqué.

Orientation rapide

Déterminez la prochaine étape selon la couche concernée.

Anomalie de l’état du nœud ou de l’hôte

Consignez l’identifiant de commande, le nœud, l’heure et le périmètre de l’impact, puis envoyez un ticket depuis la console.

Connexion impossible à établir

Vérifiez d’abord l’état en ligne, l’adresse, le port, le réseau local, les identifiants, le client et les sessions simultanées.

Échec de la commande de build

Contrôlez Xcode, le cache des dépendances, l’espace disque, la configuration de signature, le code de sortie et les journaux par étape.

Risque lié aux éléments ou aux autorisations

Révoquez d’abord les identifiants concernés et réduisez le périmètre d’accès, puis conservez les preuves masquées et envoyez les informations de l’incident.

Étape suivante

Déployez votre environnement de build avec des responsabilités clairement définies.

Choisissez d’abord le nœud et la durée de location, puis établissez séparément les contrôles pour les membres, les tâches automatisées, les éléments de signature et les sauvegardes. La commande et la gestion de l’hôte s’effectuent dans la console.

Choisir un nœud et commander Accéder à la console