DebugMac fournit à chaque commande un nœud physique Mac Mini M4 dédié : les environnements d’exécution ne sont pas partagés entre locataires. Cette page explique l’émission des identifiants, les opérations à la charge de l’utilisateur, la récupération des données et la gestion des incidents.
L’isolation commence par l’attribution de l’appareil, et non par le découpage de ressources virtuelles sur un hôte partagé.
Une fois la commande activée, l’environnement d’exécution du nœud n’est partagé avec aucun autre locataire. Le CPU, la mémoire, le SSD de base et les sessions système sont hébergés sur le Mac Mini M4 associé à cette commande.
La clé publique SSH, les identifiants VNC et l’empreinte hôte servent respectivement à l’accès en ligne de commande, à la session graphique et à la vérification de l’identité de l’hôte. Toute modification doit respecter le contrôle de l’identité de la commande.
Commencez par accorder les droits nécessaires au flux de travail réel, puis ajoutez des capacités au besoin. Les clés partagées, les identifiants orphelins conservés à long terme et les journaux d’accès communs réduisent tous la traçabilité.
Une connexion réussie n’est que la première étape. Le processus complet comprend aussi la vérification d’identité, la réduction des privilèges, la rotation des identifiants et la récupération des accès en fin de location.
Fournissez uniquement la clé publique à installer sur le nœud, jamais la clé privée. Dans un contexte d’équipe, utilisez une clé par membre afin d’éviter le partage d’un même élément d’identité.
Avant la première connexion, comparez caractère par caractère l’empreinte du reçu de livraison avec celle affichée par le client. Si elle change de manière inattendue, interrompez la connexion et faites-la vérifier via un ticket dans la console.
Gérez séparément les identifiants de session graphique et la clé publique SSH. Ne fournissez les identifiants VNC qu’aux membres qui ont besoin d’une interface graphique et renouvelez-les dès qu’une personne quitte le projet.
Séparez les tâches automatisées, le développement manuel et les opérations de publication dans des journaux d’accès identifiables. Avant toute opération privilégiée, vérifiez la sauvegarde, la procédure de retour arrière et le périmètre d’impact.
En cas de changement d’équipe, de suspicion de fuite de clé, de connexion inhabituelle ou de migration du flux de travail, remplacez immédiatement les identifiants concernés et vérifiez que les anciens ont bien été entièrement révoqués.
Récupérez les accès distants à la fin de la location. Exportez les données avant l’échéance et vérifiez que les pipelines automatisés n’envoient plus de tâches à l’ancien nœud.
Les limites ci-dessous visent à réduire les modifications irréversibles. Pour toute action ayant un impact étendu sur le système, le disque ou le réseau, conservez d’abord les données et les éléments permettant la reproduction.
| Catégorie d’opération | Exécution directe par l’utilisateur | Assistance requise | Vérifications préalables |
|---|---|---|---|
| Environnement de développement | Cloner un dépôt, installer les dépendances du projet, changer de chaîne d’outils Xcode fournie, lancer des builds et des tests | Anomalie de l’environnement système, configuration livrée et informations de commande incohérentes | Consigner la version, les commandes, le code de sortie et les étapes de reproduction |
| Contrôle d’accès | Gérer les clés du projet, réduire les droits des membres et arrêter les tâches automatisées inutilisées | Remplacement d’une clé publique SSH, renouvellement des identifiants VNC, vérification d’une anomalie d’empreinte hôte | Confirmer l’identifiant de commande, la région du nœud et l’identité du demandeur |
| Stockage et données | Nettoyer le cache de build, exporter les archives et vérifier l’intégrité des fichiers du projet | Activer les options SSD +1 To, SSD +2 To ou Thunderbolt 5 en parallèle | Effectuer d’abord une sauvegarde et vérifier la capacité cible ainsi que la période de facturation |
| Système et réseau | Exécuter ping, traceroute, des contrôles de ports et des tests de transfert contrôlés | Migration de région, anomalie réseau au niveau du nœud, modification système affectant l’accès distant | Conserver la chronologie, le réseau d’origine et les résultats de diagnostic désensibilisés |
| Actions à haut risque | Suspendre l’action et exporter les données encore accessibles | Réinitialisation du disque, restauration du système, modification irréversible des droits ou des éléments de démarrage | Définir clairement l’impact, les conditions de retour arrière et le chemin de récupération des données |
Pour déterminer si l’objectif est atteint, vérifiez séparément la fenêtre de mesure, les relevés de surveillance des nœuds, les opérations côté utilisateur et les limites liées aux événements indépendants de la volonté des parties.
Calculée sur une fenêtre glissante de près de 90 jours, avec un fonctionnement normal des nœuds 365 jours par an.
La perte de paquets d’un seul ping ou une instabilité du réseau local ne suffit pas à établir l’indisponibilité d’un nœud. Toute déclaration doit préciser l’heure, la région du nœud, le réseau d’origine et le mode de reproduction.
Si, sur une même période, seul un port, un client ou un projet échoue, commencez par distinguer les identifiants d’accès, la configuration du projet et l’état du service du nœud.
Après vérification de la chronologie et du périmètre d’impact, si l’objectif convenu n’est pas atteint, les crédits de service correspondants sont traités conformément aux conditions de service.
Le cycle de vie des données ne commence pas à la fin de la location. Les éléments d’accès, fichiers du projet, résultats exportés et relevés de récupération doivent être gérés séparément dès le jour de la livraison.
Vérifiez la configuration Debug M4, la région du nœud, l’adresse hôte, le nom d’utilisateur, l’empreinte hôte et l’état d’émission des accès afin d’éviter d’intégrer une mauvaise cible aux tâches automatisées.
Gérez les dépôts, dépendances, caches de build et artefacts, contrôlez les droits des membres selon le flux de travail et conservez une copie indépendante des données essentielles.
Téléchargez les archives, journaux et données du projet avant l’échéance, vérifiez l’intégrité des fichiers et arrêtez les runners ou tâches planifiées qui ciblent encore ce nœud.
Révoquez les éléments d’accès SSH et VNC, désactivez les points d’entrée liés à la commande et vérifiez que les anciens identifiants ne peuvent plus établir de session.
Traitez les données de location selon le processus de récupération du nœud et conservez les relevés nécessaires liés à la commande, à la sécurité et aux opérations. Consultez la déclaration de confidentialité pour les règles détaillées de traitement des informations.
Lors du traitement d’un incident de sécurité, préservez d’abord les preuves et limitez la propagation de l’impact. Les notifications doivent s’appuyer sur des faits confirmés et non sur des conclusions non vérifiées.
Recevez les alertes du nœud, les signalements des utilisateurs ou les anomalies d’accès, puis consignez l’heure la plus ancienne, le point d’entrée affecté et les premiers symptômes.
Participation de l’utilisateur : conservez l’erreur originale et l’heure de survenue.Vérifiez la commande, la région, les journaux d’accès et les conditions de reproduction afin de distinguer le réseau local, les identifiants, la configuration du projet et le nœud.
Participation de l’utilisateur : fournissez l’identifiant de commande et des journaux désensibilisés.Limitez les chemins d’accès anormaux, renouvelez les identifiants concernés ou suspendez les opérations à haut risque afin d’empêcher l’extension de l’impact.
Participation de l’utilisateur : cessez les tentatives répétées et les nouvelles tentatives automatisées.Traitez la cause confirmée, vérifiez les limites des droits, du service et des données, puis consignez les modifications et les conditions de retour arrière.
Participation de l’utilisateur : confirmez les étapes de validation côté métier.Rétablissez progressivement les accès et les flux de tâches, puis vérifiez que les connexions, builds et exports d’artefacts sont revenus à un état contrôlable.
Participation de l’utilisateur : exécutez la tâche minimale de validation.Rassemblez la chronologie, le périmètre d’impact, les actions prises et les améliorations à venir. Mettez à jour si nécessaire la gestion des identifiants et la liste de contrôle opérationnelle.
Participation de l’utilisateur : confirmez les points en suspens et leurs responsables.Envoyez tout rapport de sécurité à support@debugmac.com ou connectez-vous à la console pour ouvrir un ticket. N’envoyez jamais de clé privée, d’identifiants complets, d’informations personnelles non désensibilisées ni de données de projet sans rapport avec le problème.
Seul Debug M4 est actuellement disponible : M4, 16 Go de RAM et SSD de 256 Go, commandable à Singapour, au Japon, en Corée du Sud, à Hong Kong et dans l’ouest des États-Unis. L’état réel de disponibilité est indiqué en temps réel dans la console.