Chaque commande valide correspond à un Mac mini physique dédié : les ressources de calcul et le stockage local de l’appareil ne sont pas partagés avec d’autres locataires. La sécurité est une responsabilité partagée : la plateforme gère le nœud physique et le plan de contrôle du service, tandis que l’utilisateur gère son compte, ses identifiants de connexion, son code et les autorisations des outils tiers.
Le fait de ne pas utiliser de machine virtuelle ne dispense pas de définir des règles de sécurité. Un appareil dédié réduit le mélange des ressources entre locataires, mais la protection du compte, la rotation des clés, le principe du moindre privilège et les sauvegardes restent à mettre en œuvre dans chaque projet.
MiniRent fournit une machine physique dédiée : le processeur, la mémoire et le SSD local d’un appareil ne sont pas répartis entre plusieurs locataires. La commande, l’appareil et les journaux d’accès forment une chaîne de propriété vérifiable.
Pendant la période de location valide, le Mac mini associé à la commande est utilisé par cette seule commande. Les tâches de calcul, l’état de la mémoire et le stockage local de l’appareil ne sont pas attribués à d’autres locataires comme des ressources virtuelles partagées.
La console sert à consulter les commandes et les dossiers de service, et à envoyer des tickets ; les identifiants de l’appareil servent à accéder à l’interface graphique de macOS ou à la ligne de commande. Ces deux types d’identifiants ne doivent pas être réutilisés ni stockés dans un même document partagé.
Configurez séparément les droits des comptes de build, des runners CI et des sessions distantes manuelles. N’autorisez que les répertoires, commandes et jetons nécessaires à la tâche, et évitez de fournir des identifiants permanents à privilèges élevés aux scripts automatisés.
Le compte permet de consulter les informations associées aux commandes et de lancer des opérations de service. Attribuez les accès selon les personnes et évitez que plusieurs utilisateurs partagent durablement les mêmes identifiants.
Commencez par cesser tout partage d’identifiants, notez l’heure, la commande concernée et les symptômes observables, puis envoyez un ticket depuis la console. Ne placez pas de clés non masquées ni de certificats complets dans le texte du ticket.
Envoyer un ticket depuis la consoleFaites immédiatement tourner les informations de connexion, clés SSH, jetons de dépôt et éléments de signature concernés, puis vérifiez les tâches automatisées, les dernières connexions et les journaux de build pour détecter toute utilisation anormale.
Voir les étapes de traitementConcevez les connexions distantes autour de la question suivante : qui accède à quel appareil, à quel moment et pour quelle tâche ? Une clé longue durée partagée peut sembler pratique, mais elle complique la révocation des accès et le suivi des incidents.
Ne réutilisez pas la clé par défaut de votre appareil personnel. Séparez les clés par équipe, projet ou tâche automatisée et protégez correctement les clés privées en local.
Tenez une liste claire des autorisations sur l’appareil. Les runners CI, les développeurs et les intervenants temporaires doivent utiliser des identifiants distincts afin de pouvoir les révoquer individuellement sans perturber les autres tâches.
Limitez les sources de connexion autorisées selon le réseau de l’équipe ; laissez fermés les services qui n’ont pas besoin d’être exposés et refermez rapidement les ports ouverts temporairement une fois la tâche terminée.
Après une rotation, déployez les nouveaux identifiants et vérifiez concrètement que les anciennes clés ne permettent plus d’ouvrir une session. En cas de changement d’équipe ou de suspicion de compromission, n’attendez pas le cycle habituel : procédez immédiatement à la rotation.
Le SSD local est dédié à la commande, mais la sécurité des données dépend toujours du mode de transfert, des droits des répertoires, de l’emplacement des sauvegardes et des habitudes de nettoyage. Les éléments sensibles ne doivent pas être traités comme du code source ordinaire.
Synchronisez les données via SSH, une connexion chiffrée au dépôt ou un moyen de transfert sécurisé approuvé par l’équipe. Ne placez pas de certificats, de clés privées ni de packages de build non masqués sur une URL de téléchargement publique.
Limitez la lecture des répertoires sensibles et séparez le compte de build du compte d’usage quotidien. Les scripts ne doivent disposer que des droits sur les fichiers et commandes nécessaires à leur tâche.
Définissez des stratégies de sauvegarde distinctes pour le code source, la configuration de build, les sauvegardes de certificats et les artefacts impossibles à recréer. Les données locales de l’appareil ne doivent pas constituer l’unique copie du projet.
Supprimez rapidement les certificats temporaires, fichiers de clés exportés et artefacts ponctuels une fois la tâche terminée, puis contrôlez les caches, répertoires temporaires et espaces de travail des pipelines.
| Type de données | Risque principal | Emplacement recommandé | Vérification avant de quitter l’appareil |
|---|---|---|---|
| Code source et configuration des dépendances | Élargissement des droits du dépôt, adresses privées exposées dans les journaux | Dépôt contrôlé et droits de lecture minimaux | Confirmer la fin du commit et supprimer les fichiers d’identifiants temporaires |
| Certificats et éléments de signature | Multiplication des copies, expiration non maîtrisée | Stockage chiffré, import limité à la tâche | Vérifier les copies exportées et supprimer les fichiers temporaires |
| Clés API et jetons à courte durée | Clés codées en dur, fuite dans les sorties de build | Injection via l’environnement ou stockage contrôlé des secrets | Révoquer les jetons inutilisés et vérifier les journaux |
| Artefacts de build et journaux de débogage | Présence de chemins, d’informations utilisateur ou d’adresses internes | Stockage classifié avec périmètre d’accès défini | Exporter les artefacts nécessaires et supprimer les données sans valeur de conservation |
Les pipelines accèdent souvent simultanément aux dépôts de code, services de dépendances, éléments de signature et stockages d’artefacts. Inscrire directement une clé permanente à privilèges élevés dans un script peut transformer la fuite d’un journal en risque d’accès à plusieurs systèmes.
Accordez les droits à un seul dépôt, une seule tâche et une durée précise. Ne laissez pas l’automatisation conserver durablement des identifiants à privilèges élevés couvrant toute l’organisation.
Injectez-les via des variables contrôlées ou un gestionnaire de secrets ; ne les écrivez ni dans le dépôt, ni dans l’image, ni dans les paramètres du script, ni dans un fichier de configuration lisible par les utilisateurs ordinaires.
Évitez d’afficher les variables d’environnement complètes, les en-têtes de requête et les chemins de certificats. En cas de dépannage, n’ajoutez que les journaux nécessaires, puis rétablissez un niveau de sortie contrôlé.
Supprimez les jetons temporaires, éléments de signature décompressés, artefacts intermédiaires et données sensibles du cache avant de confier le runner à la tâche suivante.
Utilisez des identités d’exécution distinctes pour les dépôts différents ou les tâches de niveaux de sécurité différents, afin d’empêcher un projet de lire les données d’un autre via un espace de travail partagé.
La surveillance de l’infrastructure porte sur la connectivité du nœud, l’état de fonctionnement de l’appareil, les anomalies de ressources et les signaux d’incident de sécurité. Le code source, le contenu des builds et les données métier des utilisateurs ne sont pas des indicateurs opérationnels courants.
À partir des signaux d’état, des rapports utilisateurs et des dossiers de service, confirmez les éléments touchés, l’heure d’apparition et les symptômes observables.
Limitez les chemins d’accès concernés pour empêcher l’incident de s’étendre, tout en conservant les enregistrements nécessaires à l’analyse.
Vérifiez l’appareil, la commande, les journaux d’opérations et les informations masquées fournies par l’utilisateur afin de distinguer les problèmes d’infrastructure, d’identifiants et d’outils tiers.
Transmettez les informations exploitables via un ticket ou l’adresse d’assistance, puis effectuez la rotation des identifiants, le rétablissement des accès ou les contrôles complémentaires selon l’étendue du problème.
Avant la fin de la location, vérifiez que toutes les données à conserver disposent d’une copie vérifiable. Après la récupération de l’appareil, les accès existants sont révoqués, puis l’appareil passe par le processus de nettoyage des données.
Vérifiez les modifications du code source, la configuration de build, les sauvegardes des éléments de signature, les artefacts de build, les journaux de débogage et les fichiers du projet présents uniquement sur l’appareil.
Transférez les éléments nécessaires vers un emplacement contrôlé par l’équipe, puis vérifiez que les fichiers s’ouvrent, que les commits du dépôt sont complets et que les sauvegardes contiennent les informations nécessaires à la restauration.
Supprimez les jetons de dépôt, l’enregistrement du runner, les clés de déploiement et les certificats temporaires utilisés par l’appareil, afin qu’aucun accès orphelin ne subsiste après la location.
À la fin de la location, révoquez l’accès à l’appareil, vérifiez le lien entre l’appareil et la commande, puis effectuez la récupération et le nettoyage afin que les identifiants et données de l’ancien locataire ne soient plus utilisés pour les services suivants.
Un problème de sécurité peut venir de l’infrastructure, du compte ou de la configuration de l’appareil, mais aussi du dépôt de code, de la plateforme CI ou d’un service de dépendances. Lors du signalement, commencez par distinguer le périmètre concerné et n’envoyez aucun élément sensible non masqué.
Gérer la propriété des appareils, le fonctionnement de l’infrastructure, l’association aux commandes, la révocation des accès et les processus de récupération et de nettoyage ; identifier les anomalies d’infrastructure et faire avancer l’analyse via le support.
Protéger le compte de la console et les identifiants de l’appareil, gérer le code, les certificats, les jetons et les artefacts de build, et appliquer le moindre privilège, les sauvegardes nécessaires, le masquage des journaux et la révocation des accès lors des changements d’équipe.
Les services tiers traitent les jetons, journaux et données selon leur propre modèle d’autorisations. Vérifiez leurs configurations, journaux d’accès et mécanismes de révocation, et limitez l’étendue des autorisations.
Indiquez le numéro de commande, l’identifiant de l’appareil, l’heure du problème, son périmètre, les étapes de reproduction, les mesures d’isolement déjà prises et les journaux masqués. N’envoyez ni clé privée, ni jeton complet, ni certificat complet, ni identifiant permettant une connexion directe.
Commencez par confirmer le modèle et le nœud, puis mettez en place des identifiants de connexion distincts, le moindre privilège et un processus de sauvegarde pour l’équipe. La commande et la gestion du Mac s’effectuent depuis la console.