Sécuriser la chaîne

Sécuriser la chaîne

1. Chaîne d'approvisionnement logicielle

   La chaîne d'intégration est elle-même du code : elle dépend de la plateforme, d'actions tierces et de dépendances. Une action compromise, ou un jeton volé, donne un accès direct à la production.

   La menace la plus courante : le jeton

   Un jeton de déploiement est aussi un mot de passe. Il se protège comme tel : périmètre restreint, durée de vie courte, révocation immédiate possible, journalisation des usages.

   • un jeton par usage et par environnement, jamais un jeton qui touche tout ;
   • jamais de jeton écrit dans un fichier du dépôt ;
   • accès en lecture seule pour tout ce qui n'écrit pas ;
   • vérifier qui a utilisé le jeton, et quand.

   La dépendance non maîtrisée

   Une action est un logiciel que l'on exécute avec nos identifiants. Deux questions à poser avant de l'ajouter : qui la maintient, et que se passe-t-il si elle est compromise ? On privilégie les actions de l'éditeur du dépôt lui-même, et on épingle les versions.

2. Permissions minimales

   La règle est simple et rarement appliquée : la chaîne reçoit le strict nécessaire, et pas plus.

   1. une chaîne de lecture ne peut pas écrire ;
   2. une chaîne de construction n'a pas à déployer en production ;
   3. les chaînes déclenchées depuis l'extérieur sont plus restraints que celles déclenchées par le dépôt ;
   4. les modifications de configuration du dépôt peuvent exiger une approbation explicite.

   Une pull request qui touche la configuration de la chaîne elle-même mérite un regard humain : c'est elle qui définit ce qui a le droit de se produire.

3. Secrets et environnement

   Un secret ne doit apparaître ni dans le dépôt, ni dans les journaux, ni dans les artefacts.

   • stockage dédié de la plateforme, chiffré, avec journalisation des lectures ;
   • injection dans l'environnement de l'étape, jamais dans la ligne de commande (elle se lit dans les journaux) ;
   • masquage dans la sortie d'exécution : la majoration des plateformes masque les secrets connus, mais pas une valeur écrite par erreur dans un echo ;
   • rotation régulière, et immédiate en cas de doute.

         - name: Publier
           env:
             JETON: ${{ secrets.JETON_PUBLICATION }}
           run: |
             # la variable d'environnement est injectee, elle n'apparait pas dans la commande
             curl --header "Authorization: Bearer $JETON" https://registre.exemple.fr/v2/

   Le point souvent ignoré : un secret retiré d'un fichier ne l'est pas de l'historique git, ni des caches de la chaîne, ni des journaux déjà collectés. Le changer est la seule action qui vaut.

4. Provenance et traçabilité

   À la fin, deux questions doivent pouvoir obtenir une réponse rapide : quelle version tourne en production, et quelle version a introduit ce comportement.

   • un identifiant unique par artefact, propagé jusque dans l'application exposée ;
   • les journaux applicatifs portent cet identifiant : on sait immédiatement quelle version écrit la ligne ;
   • les images publiées ne sont jamais réécrites : une étiquette est immuable une fois poussée ;
   • la chaîne elle-même est versionnée et revue.

   Sans cela, un incident se passe à deviner. Avec cela, on remonte de l'incident à la révision en une requête.

5. Exercices

   1. Audit : prenez une chaîne existante et listez tous les secrets qu'elle utilise, puis dites pour chacun s'il est trop large et comment le restreindre.
   2. Traçabilité : ajoutez l'identifiant de révision dans les journaux de votre application et vérifiez qu'une ligne de log permet de retrouver la version déployée.
   3. Fuite simulée : mettez par erreur un secret en clair dans un journal, expliquez ce qui se passe ensuite, et corrigez la chaîne.