Chaque location valide correspond à un Mac mini physique dédié, et non à une machine virtuelle. L’appareil n’est pas partagé avec d’autres locataires : processeur, mémoire et stockage local restent réservés. Cette page présente les limites de sécurité, les actions à effectuer et les éléments vérifiables.
L’évaluation de la sécurité porte sur trois niveaux : propriété des actifs, chemins d’accès et état de livraison. Pendant la location, les ressources physiques du Mac mini sont réservées au locataire actuel ; les opérations d’administration sont limitées par les autorisations et les journaux d’activité ; à la fin de la location, l’appareil est nettoyé puis vérifié avant sa nouvelle livraison.
Le processeur, la mémoire unifiée et le stockage intégré ne sont pas partagés avec d’autres locataires. Vos files de compilation, caches, processus de test et sessions de bureau à distance s’exécutent sur le même appareil dédié.
Les connexions distantes utilisent en priorité des clés et les accès internes suivent le principe du moindre privilège. Pour traiter un problème sur un nœud, l’étendue de la tâche est d’abord confirmée, puis les capacités nécessaires sont accordées.
Les contrôles de sécurité couvrent l’activation, l’utilisation, la fin de location, le nettoyage des supports et la vérification avant nouvelle livraison ; le traitement des données ne repose pas sur une seule action en fin de location.
Envoyez un ticket depuis la console avec le numéro de commande, le nœud, les contrôles à vérifier et la période concernée. L’assistance rassemblera les éléments disponibles sur l’association de l’appareil, le traitement des accès ou l’état du nettoyage. N’envoyez pas de clé privée, d’identifiants complets ni de données métier non anonymisées.
Se connecter à la console et envoyer un ticket de vérificationLe contrôle des accès ne consiste pas à définir un mot de passe une seule fois. Une approche plus fiable consiste à séparer clairement les accès utilisateur, l’administration de la plateforme et la gestion des incidents, tout en permettant la rotation des identifiants, le retrait des autorisations et la traçabilité des opérations.
Après la première connexion, configurez rapidement votre clé publique SSH personnelle. Utilisez des clés distinctes pour chaque membre, Runner automatisé et tâche de déploiement. Vous pourrez ainsi révoquer l’accès d’une seule entité sans remplacer tous les identifiants de connexion.
ssh-keygen -t ed25519
Un compte de compilation courant ne doit disposer que des droits nécessaires pour récupérer le code, installer les dépendances, exécuter les tests et écrire dans le répertoire des artefacts. Les actions nécessitant une élévation doivent être liées à une tâche précise, afin qu’un Runner permanent ne conserve pas durablement des capacités inutiles.
id && groups
Lorsqu’un membre quitte l’équipe, qu’un jeton d’automatisation est exposé, qu’un projet se termine ou que le périmètre d’accès change, révoquez immédiatement les anciens identifiants et générez-en de nouveaux. Ne partagez pas un jeton permanent entre plusieurs pipelines et n’inscrivez jamais de clés directement dans un dépôt ou un journal de compilation.
En cas de connexion provenant d’une source inconnue, de nombreux échecs inhabituels ou d’une activité hors horaires habituels, limitez d’abord les adresses sources et révoquez les identifiants concernés. Conservez ensuite la période, l’adresse source, le compte et les journaux nécessaires, puis transmettez des éléments anonymisés via un ticket pour permettre le suivi par nœud.
Chaque entité est identifiée séparément, ce qui facilite la révocation et l’audit.
Réduire la portée accessible selon le réseau de l’équipe et la chaîne d’outils.
Les tâches de développement et de compilation s’exécutent dans les limites de l’appareil du locataire.
L’accès administrateur sert à livrer l’appareil, diagnostiquer les pannes et effectuer les opérations d’assistance autorisées. Le trafic du locataire sert à SSH, à l’interface graphique, à la récupération du code et des dépendances, aux compilations et au transfert des artefacts. Ces deux chemins ne doivent pas être réunis dans un même périmètre d’autorisation par souci de commodité.
Seules les opérations nécessaires à la livraison du nœud ou au diagnostic d’un problème matériel ou réseau doivent entrer dans le processus d’administration. Avant tout accès, confirmez l’objet, la raison et la portée ; les actions à risque élevé exigent une confirmation supplémentaire. Fermez ensuite les autorisations temporaires et conservez les enregistrements nécessaires.
N’ouvrez que les services réellement utilisés, limitez les adresses sources des ports d’administration et utilisez des identifiants distincts pour les transferts de fichiers et les tâches automatisées. Fermez les ports de diagnostic temporaires dès la fin de la tâche et n’exposez pas directement les bases de données, caches ou panneaux internes à des réseaux non nécessaires.
Adapté aux équipes d’Asie du Sud-Est et aux pipelines interrégionaux. Testez le routage depuis vos principaux réseaux professionnels et ajoutez aux adresses autorisées uniquement celles nécessaires aux Runners, dépôts et stockages d’artefacts.
Points à vérifier : restrictions de source, sortie des dépendances, chemin de transfert des fichiersAdapté aux projets japonais et nord-asiatiques. Journalisez séparément les sessions distantes des développeurs et le trafic de compilation automatisé, afin d’éviter de copier les identifiants personnels sur un Runner permanent.
Points à vérifier : séparation des entités, jetons de compilation, journaux de sessionAdapté aux équipes coréennes et aux tests régionaux. Attribuez un compte distinct aux agents permanents, vérifiez régulièrement les clés autorisées et les étiquettes de tâches, puis supprimez les accès inutilisés.
Points à vérifier : agents permanents, clés autorisées, isolation des tâchesAdapté aux équipes qui se connectent à des dépôts de code et réseaux de collaboration répartis en Asie. Configurez les règles selon les chemins réellement utilisés et n’élargissez pas l’accès à tous les ports au nom de la collaboration transrégionale.
Points à vérifier : routage transfrontalier, plage de ports, journaux anonymisésLes 4 nœuds de Singapour, du Japon (Tokyo), de la Corée du Sud (Séoul) et de Hong Kong fonctionnent 365 jours par an. Le nœud détermine le point d’accès, mais ne limite pas automatiquement les adresses sources, ne sépare pas les identifiants de l’équipe et ne ferme pas les services inutiles ; ces contrôles doivent être configurés selon le réseau et les pipelines de l’équipe.
La sécurité des données ne se limite pas à la fin de la location. L’association de l’appareil, la gestion des autorisations pendant l’utilisation, la migration des utilisateurs, le nettoyage des supports et la vérification avant nouvelle livraison forment un processus complet.
Selon la commande, confirmez le modèle, la mémoire, le stockage, la durée de location et le nœud cible, puis associez l’identifiant de l’appareil physique à la location actuelle. Avant de transmettre les informations de connexion, vérifiez l’état du système de base et le chemin d’accès distant.
Éléments vérifiables : numéro de commande, modèle, nœud, état de l’association de l’appareilLe code, les caches de dépendances, les artefacts de compilation et les fichiers d’expérimentation sont stockés sur l’appareil loué ou sur un stockage distant configuré par l’utilisateur. L’équipe doit séparer les comptes, chiffrer les fichiers sensibles, limiter le contenu des journaux et créer des sauvegardes indépendantes des données essentielles.
Actions du locataire : séparation des autorisations, chiffrement des données, vérification des sauvegardes, anonymisation des journauxAvant la fin de la location, exportez le code, les artefacts et la configuration à conserver, puis vérifiez que les sauvegardes sont lisibles. Révoquez ensuite, dans les dépôts de code, plateformes CI/CD et systèmes de déploiement, les jetons et clés utilisés par ce nœud, puis arrêtez les agents permanents.
Critères de réussite : données migrées, sauvegardes lisibles, identifiants externes révoquésAprès sa sortie de la location actuelle, l’appareil entre dans un processus de nettoyage qui traite les données utilisateur locales, fichiers de projet, caches, clés, jetons et configurations d’accès distant. Le nettoyage est associé à l’état de l’appareil afin d’éviter qu’une simple suppression de répertoires visibles soit suivie d’une nouvelle livraison immédiate.
Objectif de contrôle : les données et identifiants de l’ancien locataire ne doivent pas être transmis lors de la prochaine livraisonAvant de réintégrer le processus de livraison, vérifiez que les anciens utilisateurs, clés, tâches permanentes et données de projet ont été supprimés, et que l’accès distant utilise de nouveaux identifiants de livraison. Ce n’est qu’après validation que l’appareil peut être associé à la location suivante.
Périmètre de vérification : utilisateurs, clés, tâches, répertoires de données, configuration de connexionLes journaux d’audit servent au diagnostic, à la revue des autorisations et aux enquêtes de sécurité. Leur portée se limite aux faits nécessaires et ne vise pas à recueillir le contenu métier du locataire ; le nœud, l’auteur de l’opération, la raison de l’autorisation, la période et le résultat sont les principaux champs associés.
Avant toute réinitialisation d’accès, modification de configuration système, opération sur les données ou action affectant l’état des connexions, précisez le nœud, la portée de l’impact et le résultat attendu.
Base de la tâche, périmètre confirmé, résultat de l’exécutionConservez l’identité, le nœud, l’heure, le type d’opération et l’état nécessaires au diagnostic ; n’inscrivez pas de clé privée, de jeton complet ni de données métier dans les journaux.
Entité, nœud, période, catégorie d’opérationLes accès internes sont accordés selon les responsabilités et les tâches temporaires reçoivent les droits correspondant à leur portée. Lorsque les responsabilités ou l’état d’une tâche changent, retirez rapidement les capacités devenues inutiles.
Entité autorisée, raison, portée des droits, étatAssociez les opérations d’assistance au nœud et au problème concernés afin de vérifier ensuite qu’elles sont restées dans les limites autorisées et de reconstituer l’ordre des actions essentielles lors d’une enquête.
Ticket associé, séquence des opérations, conclusionConfirmez le nœud cible, le problème observé, les actions autorisées et les limites des données à ne pas toucher. Si les informations sont insuffisantes, réunissez d’abord des éléments complémentaires au lieu d’élargir l’accès pour tenter de diagnostiquer le problème.
Privilégiez les opérations à faible impact et réversibles. Si le problème diffère de la tâche initiale, interrompez l’extension du traitement et reconfirmez l’autorisation et l’impact.
À la fin de la tâche, révoquez l’accès temporaire et consignez les actions réellement effectuées, l’état du nœud et les recommandations, afin que la prochaine vérification ne dépende pas d’un compte rendu oral.
En cas de connexion inconnue, d’exposition d’identifiants, d’activité réseau inhabituelle, de suppression accidentelle de données ou de comportement inattendu du nœud, limitez d’abord l’impact puis conservez les preuves. Pour rétablir rapidement le service, n’écrasez pas les journaux essentiels et ne continuez pas à utiliser des identifiants potentiellement compromis.
Notez l’heure de la première détection, le nœud, le compte, l’adresse source, l’anomalie observée et le dernier état normal. Conservez les journaux originaux nécessaires et préparez une copie anonymisée pour l’envoi.
Limitez les sources anormales, révoquez les clés ou jetons probablement exposés et suspendez les tâches automatisées concernées. Ciblez l’entrée précise autant que possible afin de ne pas détruire inutilement les autres preuves.
Établissez une chronologie autour du compte, du nœud, de la période, de la source réseau et de la séquence des opérations. Distinguez les changements de configuration utilisateur, le comportement des tâches automatisées et les événements nécessitant une vérification par la plateforme.
Supprimez les accès anormaux, faites tourner les identifiants concernés, restaurez la configuration nécessaire et vérifiez la compilation, la connexion distante et l’accès aux fichiers. Après correction, contrôlez à nouveau les clés autorisées, les processus permanents et les ports ouverts.
Via un ticket ou l’adresse d’assistance, transmettez les faits confirmés, l’impact, les actions effectuées et les étapes suivantes à réaliser par l’utilisateur. Toute nouvelle preuve doit rester associée à la même commande et au même périmètre d’incident.
Indiquez le numéro de commande, le nœud, la période de détection, la description de l’impact, les étapes de reproduction et les journaux anonymisés. Si vous ne pouvez pas vous connecter à la console, envoyez un e-mail à support@macrents.com. N’ajoutez pas de clé privée, de jeton d’accès complet, de mot de passe de certificat ni de données personnelles non traitées.
La plateforme fournit l’isolation des nœuds physiques et des contrôles d’administration ; le locataire doit néanmoins gérer les comptes de projet, les accès réseau, les clés, les jetons et les données métier. Cette checklist s’applique au développement distant, aux compilations Xcode, aux Runners permanents et aux expérimentations d’IA.
Les trois configurations sont des machines physiques dédiées, et non des machines virtuelles, disponibles sur 4 nœuds : Singapour, Japon (Tokyo), Corée du Sud (Séoul) et Hong Kong. La disponibilité réelle est celle renvoyée en temps réel par la console.