Suivre un pointeur de configuration jusqu'à un fichier d'environnement pour récupérer un token admin

Les applications matures évitent de coder les secrets en dur directement dans le code source. À la place, le code lit un secret depuis l'environnement du processus, et autre chose - une unité systemd, un env_file Docker, ou un wrapper shell - est responsable de placer cette valeur dans l'environnement au démarrage. Dans ce challenge, config.py appelle os.environ.get('ADMIN_TOKEN') et laisse même un indice : SECRET_ENV_PATH = '/etc/acme/secret.env'. Le secret est bien réel, il n'est qu'à un fichier de distance.

Cette indirection améliore l'hygiène dans le contrôle de version, le dépôt ne contient jamais le token, mais elle ne sert à rien une fois qu'un attaquant a un accès en lecture à l'hôte. Le fichier .env reste sur le disque en clair, et l'unité de service indique exactement où : EnvironmentFile=/etc/acme/secret.env. Quiconque peut lire ce chemin lit le token. Un point d'ancrage en tant qu'utilisateur du service suffit généralement, car le fichier doit être lisible par cet utilisateur pour que le service démarre.

La compétence exercée ici consiste à enchaîner un artefact après l'autre : une config qui nomme un chemin, une unité de service qui confirme ce chemin, et enfin le fichier .env qui contient la valeur. Quand le chemin n'est pas explicite, un grep récursif tel que grep -r ADMIN_TOKEN /etc tombe directement sur la ligne. Le token est stocké en clair car l'application doit l'envoyer tel quel, il suffit donc de lire le fichier.

• S'arrêter au fichier de config. config.py ne contient pas le token, il indique seulement le chemin. Ceux qui grep uniquement le répertoire de l'appli passent totalement à côté du secret.
• Ignorer l'unité de service. La ligne EnvironmentFile= de l'unité systemd est l'indice le plus fort sur l'endroit où le secret est chargé ; sauter /etc/systemd revient à deviner.
• Supposer que /etc est interdit d'accès. Le fichier .env doit être lisible par l'utilisateur du service, donc un shell peu privilégié en tant que cet utilisateur peut généralement le lire.
• Grepper le mauvais mot-clé. Chercher password trouve le mot de passe de la base de données, pas le token admin, il faut grep spécifiquement ADMIN_TOKEN.

Déplacer un secret du code source vers un fichier .env sur disque n'est qu'une demi-mesure ; le correctif durable consiste à garder la valeur entièrement hors du système de fichiers de l'hôte :

• Récupérer le token au démarrage depuis un gestionnaire de secrets (un service de type vault ou le coffre-fort de secrets de votre fournisseur cloud) et ne le garder qu'en mémoire du processus.
• Si un fichier .env est inévitable, verrouillez-le avec chmod 600 et un propriétaire dédié pour qu'un utilisateur de service compromis ne puisse pas le lire.
• Limitez la portée du token et faites-le tourner régulièrement pour qu'une fuite reste brève et limitée dans son impact.
• Auditez les lectures des chemins de secrets et déclenchez une alerte en cas d'accès depuis des utilisateurs ou processus inattendus.

Considérez comme déjà compromis tout token ayant touché un fichier lisible sur un hôte partagé : faites-le tourner et réémettez-le, car supprimer le fichier n'annule pas une lecture déjà survenue.