Sécuriser un Mac cloud de courte durée et effacer les secrets

À une semaine d’une mise en production, lorsqu’un Mac cloud est ajouté dans l’urgence, le principal risque négligé n’est généralement pas la vitesse de compilation, mais le périmètre d’accès. Les développeurs copient souvent leurs clés privées SSH habituelles, leurs jetons de dépôt et leurs éléments de signature sur la machine, puis se contentent de supprimer le répertoire du projet une fois la tâche terminée. Une approche plus sûre consiste à considérer chaque période de location comme un cycle de sécurité autonome : établir une référence lors de la prise en main, limiter les identifiants pendant l’utilisation, puis vérifier l’exportation et le nettoyage avant de restituer la machine.

Définir d’abord le périmètre de confiance de la location

Commencez par consigner l’usage du nœud, son responsable, la date de fin de location et les données auxquelles il devra accéder. Une machine destinée à tester du code public et un nœud de compilation manipulant des éléments de signature ne doivent pas utiliser les mêmes identifiants. En cas de travail à plusieurs, attribuez à chaque membre un mode de connexion distinct, sans partager de clé privée ni inscrire les identifiants d’administration dans la documentation de l’équipe.

Sur un nœud loué pour une courte durée, l’objectif n’est pas de conserver des identifiants valides indéfiniment, mais de garantir que chacun possède un usage précis, des privilèges minimaux et une date d’expiration vérifiable.

Les vérifications à effectuer dans les quinze minutes suivant la première connexion

Après la première connexion, n’importez pas immédiatement le projet. Vérifiez d’abord l’utilisateur actif, la version du système, l’état de la connexion à distance et celui du pare-feu, puis conservez les résultats. La décision d’installer immédiatement les mises à jour système doit tenir compte des versions requises par la chaîne d’outils de compilation, afin de ne pas modifier l’environnement en pleine publication.

whoami
sw_vers
sudo systemsetup -getremotelogin
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
softwareupdate --list

Créer une clé SSH réservée à la location

Générez une clé dédiée depuis un poste de travail contrôlé, sans copier une clé privée existante utilisée à long terme. Après avoir ajouté la clé publique au Mac cloud, ouvrez un second terminal pour tester la nouvelle connexion avant d’envisager toute modification de l’ancien mode d’accès.

umask 077
mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/armmacs-rental -C "temporary-build-node"
chmod 700 ~/.ssh
chmod 600 ~/.ssh/armmacs-rental

Dans le fichier local ~/.ssh/config, vous pouvez attribuer un alias distinct au nœud et utiliser IdentitiesOnly yes pour empêcher le client SSH d’essayer d’autres clés. L’adresse du nœud, le nom d’utilisateur et le chemin de la clé doivent provenir du dossier de cette location. Ne publiez jamais l’adresse réelle dans le dépôt de code.

Host rented-mac
    HostName <node-address>
    User <node-user>
    IdentityFile ~/.ssh/armmacs-rental
    IdentitiesOnly yes
    ServerAliveInterval 30

Ne rendre les secrets disponibles qu’au moment nécessaire

N’inscrivez pas les jetons dans des scripts, des configurations de projet ou des fichiers d’initialisation du Shell. Privilégiez la saisie interactive, des variables d’environnement à portée limitée ou le trousseau macOS, et vérifiez que les journaux de compilation ne reproduisent pas les valeurs des variables. Placez les fichiers temporaires dans un répertoire aux droits contrôlés, avec des autorisations par défaut qui en réservent la lecture à l’utilisateur actif.

umask 077
mkdir -p ~/secure-input
chmod 700 ~/secure-input
security add-generic-password -a build -s ci-token -w

Supprimez les variables du Shell actif dès que l’opération est terminée. Si un identifiant ne sert qu’à une seule publication, ne le conservez pas durablement d’une session à l’autre.

unset CI_TOKEN
security delete-generic-password -a build -s ci-token

Empêcher les journaux et les caches d’emporter des secrets

N’activez pas dans les scripts de compilation un mode de débogage affichant l’intégralité des commandes. Avant de partager un journal d’erreurs, recherchez les en-têtes de requête, variables d’environnement, adresses de nœud, noms d’utilisateur et chemins de fichiers. Derived Data, les caches des gestionnaires de paquets et les pièces jointes de test peuvent contenir des noms de projet ou des chemins internes. Décidez de les conserver ou non selon la sensibilité de la tâche, plutôt que de tout archiver par défaut.

Effectuer un audit léger pendant l’utilisation

Vérifiez les sessions ouvertes, les ports en écoute, les processus en arrière-plan et l’espace disque disponible au minimum lors d’un changement d’équipe, d’une rotation des identifiants et avant une publication critique. Si vous repérez un processus inconnu, consignez d’abord son identifiant, l’utilisateur qui l’a lancé et le chemin de la commande avant de décider de l’arrêter, afin de ne pas interrompre par erreur une compilation en cours.

who
ps -axo user,pid,ppid,command
lsof -nP -iTCP -sTCP:LISTEN
df -h
find ~/work -type f -perm -004

La dernière commande recherche dans le répertoire de travail les fichiers lisibles par d’autres utilisateurs. Elle ne remplace pas un audit complet des autorisations, mais permet de détecter rapidement les erreurs de configuration évidentes. Si plusieurs personnes utilisent le même nœud, séparez également les répertoires partagés des répertoires personnels et n’utilisez pas de répertoire accessible en écriture à tous pour transférer des éléments de signature.

Exporter puis nettoyer dans le bon ordre avant la fin de la location

Commencez par arrêter les Runner, les agents de compilation et les tâches personnalisées exécutées en arrière-plan, afin d’éviter la création de nouveaux fichiers pendant le nettoyage. Archivez ensuite les projets, journaux et artefacts à conserver, générez une somme de contrôle, puis décompressez quelques éléments sur un autre appareil contrôlé pour les vérifier. Ne supprimez les copies de travail du nœud qu’après avoir confirmé la réussite de l’exportation.

mkdir -p ~/export
ditto -c -k --keepParent ~/work/project ~/export/project.zip
shasum -a 256 ~/export/project.zip
git -C ~/work/project status --short

Le nettoyage doit au minimum couvrir les répertoires de projet et d’exportation, les caches de compilation, les répertoires temporaires, les entrées du trousseau, les autorisations SSH, les enregistrements de clés publiques et l’historique du Shell du compte dédié. Révoquez également les jetons de dépôt auprès du service qui les a émis et supprimez de votre poste de travail la clé privée créée pour cette location. Sur un SSD, écraser plusieurs fois un fichier individuel ne remplace pas la procédure de recyclage du nœud mise en œuvre par la plateforme. Le nombre d’écrasements ne constitue donc pas une preuve de nettoyage.

Avant de quitter le nœud, effectuez une dernière vérification en sens inverse : la clé dédiée permet-elle encore de se connecter, le jeton temporaire est-il bien invalide, des processus d’arrière-plan fonctionnent-ils toujours, des fichiers exportés restent-ils sur le nœud et le répertoire de travail contient-il des modifications non validées ? Consignez les résultats dans le relevé de restitution afin d’éviter l’écart entre ce que l’on pense avoir supprimé et ce qui reste réellement accessible.

Questions fréquentes