Sécuriser les transferts de fichiers sur un Mac distant

Lorsque l’équipe transfère vers un Mac dans le cloud des éléments de signature, des données de test ou des artefacts de build en attente de validation, l’erreur la plus courante consiste à les déposer directement à la racine du dépôt. Dès leur arrivée, ces fichiers peuvent être lus par les indexeurs, les scripts de build ou les tâches de nettoyage. Si une archive contient des chemins qui sortent du répertoire prévu, des autorisations incorrectes ou des attributs étendus non documentés, le problème peut se propager immédiatement à l’espace de travail. La méthode la plus sûre consiste à séparer le « transfert » de l’« utilisation » en deux étapes distinctes.

Définir d’abord le périmètre du transfert

Chaque transfert doit préciser au minimum quatre éléments : l’expéditeur, le destinataire, l’usage des fichiers et leur durée de conservation. Les correctifs de code source, les fixtures de test, les artefacts de build et les identifiants ne doivent pas être regroupés dans une même archive. Les identifiants doivent être fournis au moyen d’un mécanisme d’injection contrôlé, et ne doivent apparaître ni dans les conversations, ni dans les journaux de build, ni dans des paquets de fichiers ordinaires.

Même sur un nœud physique dédié de VMRunner, créez un répertoire de dépôt distinct pour chaque tâche au lieu de réutiliser un dossier Downloads permanent. Le nom du répertoire peut reprendre un numéro de ticket ou un identifiant de tâche interne, mais ne doit contenir ni nom de client, ni adresse e-mail, ni autre information sensible.

umask 077
handoff_root="$HOME/Handoffs/task-4821"
install -d -m 700 "$handoff_root/incoming"
install -d -m 700 "$handoff_root/verified"
install -d -m 700 "$handoff_root/logs"
stat -f '%Su %Sg %Sp %N' "$handoff_root" "$handoff_root/incoming"

umask 077 garantit que les fichiers créés par la suite ne sont accessibles par défaut qu’à l’utilisateur courant. install -d crée le répertoire et définit simultanément ses autorisations, ce qui évite une brève exposition entre la création du répertoire et la correction de ses droits.

Une zone de dépôt n’a pas vocation à conserver les fichiers de manière permanente. Elle fournit une couche tampon dans laquelle ils peuvent être inspectés, refusés et supprimés avant leur entrée dans l’espace de travail du projet.

Créer une liste de contrôle avant l’envoi

L’expéditeur doit d’abord figer le contenu du répertoire, puis générer les sommes de contrôle. Il ne faut pas calculer les hachages pendant qu’une tâche de build continue de modifier les artefacts, car la liste reçue pourrait alors correspondre à plusieurs versions différentes. Il est recommandé de commencer par copier les fichiers dans un répertoire de livraison en lecture seule, de vérifier leur nombre, puis de générer une liste SHA-256.

Éviter le contenu superflu lors de l’archivage

Pour livrer du code source, excluez .git, les caches locaux, les données dérivées et les fichiers d’environnement. Pour livrer des artefacts de build, conservez en revanche les structures de signature et les attributs étendus nécessaires. Ne reconditionnez pas arbitrairement un répertoire d’application dans le seul but de réduire sa taille.

cd "$HOME/Delivery/task-4821"
find . -type f ! -name 'SHA256SUMS' -print0 \
  | sort -z \
  | xargs -0 shasum -a 256 > SHA256SUMS
shasum -a 256 SHA256SUMS

Le destinataire doit obtenir séparément, par un canal interne préalablement vérifié, la somme de contrôle du fichier SHA256SUMS lui-même. Si la liste et les fichiers sont transmis par le même chemin non vérifié, un attaquant peut remplacer les deux simultanément.

Vérifier avant de décompresser

Les fichiers doivent d’abord être placés dans incoming, et non écraser directement le dépôt. Une fois le transfert terminé, consignez leur nom, leur taille, leur propriétaire et leurs autorisations avant de comparer les sommes de contrôle. En cas de divergence, quelle qu’elle soit, interrompez le processus. N’essayez pas de « corriger le problème puis de continuer », car l’écart peut provenir d’une interruption du transfert, d’un nouveau conditionnement par l’expéditeur ou d’un remplacement des fichiers.

cd "$handoff_root/incoming"
shasum -a 256 -c SHA256SUMS
find . -maxdepth 2 -print0 \
  | xargs -0 stat -f '%z %Su %Sg %Sp %N' \
  > "$handoff_root/logs/received-files.txt"

Inspecter les chemins de l’archive au préalable

Pour une archive ZIP, exécutez d’abord unzip -l package.zip ; pour une archive tar, exécutez tar -tf package.tar. Refusez toute archive contenant des chemins absolus, des chemins ../ sortant du répertoire prévu ou des liens symboliques inattendus. Une fois le contenu validé, décompressez-le uniquement dans un répertoire vide, puis contrôlez à nouveau la liste des fichiers et leurs autorisations.

Les fichiers macOS peuvent également comporter des attributs étendus. Utilisez xattr -lr pour examiner les marqueurs de provenance et les autres attributs, sans les supprimer systématiquement de manière récursive. Ne modifiez un attribut précis sur un fichier donné que si son origine est clairement établie, si ses effets sont compris et si la tâche l’exige réellement.

Restreindre les autorisations lors de l’intégration

Après validation, copiez les fichiers dans verified, puis laissez le responsable du projet les déplacer dans l’espace de travail. Cette procédure conserve une version validée séparée du contenu reçu à l’origine. Les documents ordinaires peuvent rester accessibles en lecture et en écriture à l’utilisateur courant ; les entrées figées destinées uniquement à être lues par le build peuvent être placées en lecture seule.

cp -R "$handoff_root/incoming/ProjectInput" \
  "$handoff_root/verified/"
chmod -R go-rwx "$handoff_root/verified"
find "$handoff_root/verified" -type f -exec chmod 600 {} +
find "$handoff_root/verified" -type d -exec chmod 700 {} +

N’exécutez pas aveuglément un chmod récursif sur l’ensemble du projet. Les scripts exécutables, les paquets d’applications et les frameworks ont des exigences différentes en matière d’autorisations ; tout ramener à 600 peut compromettre les tâches suivantes. Le durcissement des droits doit s’appliquer uniquement à la copie temporaire concernée. Lors de l’intégration définitive, restaurez les autorisations nécessaires conformément aux données du dépôt ou aux règles de build.

Si plusieurs personnes collaborent sur le même Mac dans le cloud, privilégiez des comptes système et des répertoires distincts. Accorder temporairement des droits globaux en lecture et en écriture peut sembler pratique, mais empêche de retracer l’origine des fichiers et la responsabilité des modifications.

Vérifier l’absence de résidus à la clôture

Avant de terminer la tâche, vérifiez que le projet a bien récupéré les fichiers nécessaires et consignez leur somme de contrôle finale. Recherchez ensuite les copies décompressées, les archives issues de tentatives échouées, les pièces jointes aux journaux et les processus qui maintiennent encore des fichiers ouverts. lsof +D pouvant être lent sur les grands répertoires, exécutez-le uniquement sur la zone de dépôt de cette tâche.

lsof +D "$handoff_root" 2>/dev/null
find "$handoff_root" -type f -maxdepth 4 -print
rm -rf "$handoff_root"
test ! -e "$handoff_root" && printf '%s\n' 'handoff removed'

La suppression de la zone de dépôt ne suffit pas à assurer la gestion des secrets. Si une valeur sensible a été enregistrée dans des arguments de ligne de commande, l’historique du shell, les journaux de build ou les rapports d’erreur, supprimez également ces traces et renouvelez l’identifiant concerné. Pour les transferts courants, ne conservez que le minimum nécessaire à l’audit : l’identifiant de la tâche, les heures d’envoi et de réception, la somme de contrôle de la liste, le résultat de la validation et le résultat de la suppression. Ne conservez pas le contenu des fichiers.

Un processus fiable de collaboration à distance ne repose pas sur l’espoir que « tout le monde pensera à être prudent ». Il impose quatre étapes explicites : isolation, vérification, autorisation et suppression. Après avoir regroupé ces commandes dans des scripts d’équipe, testez régulièrement, avec des échantillons inoffensifs, les échecs de hachage, les chemins sortant du répertoire prévu et les anomalies d’autorisations, afin de vérifier que les procédures de refus sont aussi opérationnelles que le parcours normal.

Questions fréquentes