Pourquoi votre équipe a besoin d'une politique de secrets (pas seulement d'un coffre)

Vous entrez dans une salle d'équipe et demandez à cinq développeurs où ils conservent les mots de passe de la base de données. L'un pointe vers un fichier .env à la racine du projet. Un autre a une note privée dans son gestionnaire de mots de passe. Un troisième a collé un jeton API en commentaire dans le code, juste au-dessus de la fonction qui l'utilise. Le quatrième développeur jure l'avoir mis dans le coffre, mais personne d'autre ne peut le trouver. Le cinquième hausse les épaules.

Ce n'est pas un échec de sécurité. C'est un échec de coordination. Chaque développeur avait une raison pour son choix. Le fichier .env était rapide. La note privée était pratique. Le commentaire dans le code était visible. L'entrée dans le coffre était techniquement correcte mais non documentée. Le haussement d'épaules était honnête.

Le problème n'est pas que les secrets existent. Le problème est qu'il n'y a pas de règle partagée sur la façon dont les secrets sont gérés dans toute l'équipe et dans tous les environnements. Sans politique, chaque développeur optimise pour son propre flux de travail, et le résultat est l'incohérence. L'incohérence signifie que vous ne pouvez pas garantir que les secrets de production sont traités de la même manière que les secrets de développement. Vous ne pouvez pas garantir qu'un secret tourné atteint chaque environnement. Vous ne pouvez pas garantir qu'un ancien membre de l'équipe n'a plus accès.

Une politique de secrets n'est pas un document formel qui est classé après une lecture. C'est un ensemble de règles qui est traduit en configuration du coffre et en comportement du pipeline. L'objectif est simple : quel que soit l'environnement que vous regardez, les secrets sont accédés et gérés de la même manière.

Qui peut accéder à quoi

La première règle à établir concerne l'accès. Qui peut lire un secret en développement ? Qui peut lire un secret en production ? Ce ne sont pas les mêmes questions.

En développement, la plupart des membres de l'équipe ont besoin d'accéder aux secrets pour que l'application puisse fonctionner sur leur machine locale. C'est acceptable. Le risque est faible, et bloquer l'accès ralentirait tout le monde. Mais en production, l'accès doit être restreint. Tous les développeurs n'ont pas besoin de connaître le mot de passe de la base de données de production ou le jeton API de la passerelle de paiement. Le principe ici est le moindre privilège : chaque personne ou système reçoit uniquement les secrets nécessaires à son travail.

La façon de faire respecter cela est d'utiliser des politiques de coffre. Une politique définit quels chemins un utilisateur ou un système peut lire. Par exemple, secret/development/* pourrait être lisible par tous les membres de l'équipe, tandis que secret/production/* serait lisible uniquement par le pipeline de déploiement et quelques ingénieurs seniors désignés. Ce n'est pas une règle écrite que les gens sont censés suivre manuellement. C'est une configuration que le coffre applique. Si un développeur essaie de lire un secret de production depuis son ordinateur portable, le coffre refuse. Le journal d'audit enregistre la tentative.

Gardez les environnements séparés

La deuxième règle concerne les limites des environnements. Les secrets de production ne doivent jamais être utilisés en développement ou en préproduction. Les secrets de développement ne doivent jamais fuir en production.

Cela semble évident, mais cela arrive plus souvent qu'on ne le pense. Une équipe est pressée. Elle doit tester une fonctionnalité qui communique avec un service externe. Au lieu de créer un identifiant de test séparé, elle copie le jeton de production dans la préproduction. Le test fonctionne. Personne ne se souvient de le supprimer. Plus tard, un développeur enregistre accidentellement les variables d'environnement de préproduction, et le jeton de production se retrouve dans un fichier journal visible par toute l'équipe. Maintenant, la production est exposée à cause d'un raccourci en préproduction.

L'application ici est structurelle. Des chemins de coffre séparés par environnement. Le pipeline de développement n'a accès qu'au chemin de développement. Le pipeline de préproduction n'a accès qu'au chemin de préproduction. Le pipeline de production n'a accès qu'au chemin de production. Si un pipeline essaie de lire un secret d'un environnement différent, le coffre refuse et enregistre la tentative. Il ne s'agit pas de confiance. Il s'agit de rendre l'action incorrecte impossible.

La rotation doit être automatisée

La troisième règle concerne la rotation. À quelle fréquence les secrets doivent-ils changer ? La réponse dépend de l'environnement.

Les secrets de développement peuvent être tournés moins fréquemment. Si un mot de passe de base de données de développement fuit, le rayon d'explosion est limité à l'équipe. Une rotation tous les trois mois est généralement suffisante. Les secrets de production nécessitent une rotation plus fréquente. Tous les mois est une base raisonnable. Chaque fois qu'un membre de l'équipe part, les secrets de production auxquels il avait accès doivent être tournés immédiatement.

Le point clé est que la rotation doit être automatisée. Les humains oublient. Les humains sont occupés. Les humains prennent des raccourcis quand une échéance approche. Le pipeline doit gérer la rotation selon un calendrier. Si un secret n'a pas été tourné à la date prévue, le pipeline doit le signaler ou bloquer les déploiements jusqu'à ce que la rotation ait lieu. Il ne s'agit pas de punir l'équipe. Il s'agit de supprimer la charge cognitive de se souvenir de tourner.

Planifiez la récupération

La quatrième règle concerne la récupération. Les secrets se perdent. Les chemins de coffre sont supprimés par accident. Quelqu'un tourne un secret et oublie de mettre à jour le service en aval. Quand cela arrive, l'équipe a besoin d'un moyen de récupérer sans modifier la configuration de l'application.

La plupart des coffres fournissent un historique des versions. Un secret supprimé peut être restauré à une version précédente. Mais la politique doit définir qui est autorisé à effectuer la récupération et comment le processus est journalisé. La récupération ne doit pas être une action libre que n'importe qui peut entreprendre. Elle doit nécessiter une approbation et laisser une trace d'audit. Sinon, la récupération devient une porte dérobée qui contourne toutes les autres règles.

Rendez-la applicable

Toutes ces règles sont inutiles si elles n'existent que sous forme de document. Une politique de secrets qui vit dans un wiki et n'est jamais traduite en configuration n'est pas une politique. C'est une suggestion.

Trois composants rendent une politique de secrets réelle :

• Des politiques de coffre qui appliquent les règles d'accès par environnement.
• Des pipelines qui sont isolés par environnement et ne peuvent pas croiser les chemins.
• Des journaux d'audit qui sont examinés régulièrement, pas seulement stockés.

Sans ces trois composants, la politique n'est que des mots. Avec eux, la politique devient le comportement par défaut du système. Les développeurs n'ont pas besoin de se souvenir des règles. Le système les applique automatiquement.

Liste de contrôle pratique

Si vous mettez en place une politique de secrets pour votre équipe, voici une courte liste à parcourir :

• Définissez quels chemins de coffre sont lisibles par quels rôles par environnement.
• Configurez les politiques de coffre pour appliquer ces règles, pas seulement les documenter.
• Séparez l'accès des pipelines pour que chaque environnement ne puisse atteindre que ses propres secrets.
• Définissez des calendriers de rotation par environnement et automatisez-les dans le pipeline.
• Définissez qui peut récupérer les secrets supprimés et comment la récupération est journalisée.
• Examinez les journaux d'audit au moins une fois par mois pour les tentatives d'accès inattendues.

L'essentiel

Un coffre à secrets est un outil. Une politique de secrets est le règlement qui rend l'outil utile. Sans la politique, le coffre n'est qu'un autre endroit où les secrets sont stockés de manière incohérente. Avec la politique, le coffre devient un système qui applique la façon dont les secrets sont accédés, tournés et récupérés dans tous les environnements que votre équipe exécute. Commencez par les règles, puis configurez le coffre pour les appliquer. C'est la différence entre avoir un outil de gestion des secrets et gérer réellement les secrets.