Les entreprises ont des secrets… que les développeurs dévoilent par manque de rigueur, d’organisation, de formation. Il est temps d’opter pour un modèle mature de stockage des identifiants et des mots de passe.
C’est probablement l’un des sujets les plus en vogue chez les DevOps : comment trouver le meilleur équilibre entre sécurité et flexibilité lorsqu’il s’agit de gérer les secrets au sein des applications et des systèmes ? Et malgré le fait que de nombreuses approches soient régulièrement suggérées, aucune ne semble avoir résolu le problème.
Pourquoi ? Parce qu’il n’existe tout simplement pas de solution universelle !
Les secrets sont partout. Ils sont utilisés tant au sein des actifs de l’entreprise (machines, applications) que par l’ensemble des développeurs. Il est donc illusoire de vouloir appliquer des restrictions extrêmes et parfois simplistes telles que le fameux « les développeurs ne devraient jamais avoir à toucher un secret » que l’on entend parfois. C’est peut-être une bonne idée sur le papier, mais sur le terrain, cela ne fonctionne pas !
Et même des suggestions moins extrêmes, telles que l’interdiction des secrets à longue durée de vie (bon courage !) sont souvent complexes à mettre en œuvre efficacement sur des périmètres étendus.
Le fait est que la réponse dépend fortement du contexte et de la maturité de l’organisation. Il y aura donc probablement plusieurs approches à combiner, mais surtout il sera impossible de les connaître sans avoir au préalable une idée claire du niveau de maturité de l’organisation en matière de gestion des secrets – et cela va de la supervision de leur usage jusqu’à la détection de leurs fuites involontaires.
Le point de départ de cette réflexion est que l’état de la gestion des secrets dans les usines de logiciel modernes est toujours un mélange de diverses solutions ad hoc. Il est d’ailleurs possible de les faire correspondre à quatre grands domaines du cycle de développement sécurisé (SDLC) traditionnel :
* L’environnement du développeur
* La gestion du code source
* Les pipelines CI/CD et artefacts
* Les environnements d’exécution
À partir de là, il est possible d’évaluer sa maturité actuelle sur une échelle de cinq niveaux pour chacun de ces domaines, et de déterminer comment passer au niveau suivant. Le schéma ci-dessous présente ces niveaux et la maturité globale qui leur est associée :
Au niveau zéro, rien n’est en place : les secrets prolifèrent de manière anarchique, ils sont utilisés n’importe où et par n’importe qui en fonction des besoins immédiats, et il est impossible de détecter une fuite.
Au niveau 1, les secrets ne sont pas chiffrés au repos, mais ils sont regroupés dans des fichiers de configuration partagés (on sait donc au moins où ils sont, et on évite les duplications inutiles). Des campagnes de recherche de secrets sont par ailleurs lancées manuellement de temps à autre, mais les développeurs ne sont pas impliqués dans la remédiation lorsque des écarts sont identifiés.
Au niveau 2, les secrets sont enfin chiffrés au sein d’espaces protégés, dont les mots de passe d’accès sont conservés dans un coffre dédié. La recherche de secrets hors espace protégé, ainsi que leur rotation, est régulière.
Au niveau 3, les secrets sont groupés par famille ou usage (« scoping ») et sont consommés au travers d’un gestionnaire de secrets (« secret manager »), ce qui permet une gestion centralisée tout en contrôlant plus efficacement les usages.
Au niveau 4, les secrets sont « scopés » et consommés via un gestionnaire de secrets comme au niveau 3, mais la détection des fuites et des mauvais usages est désormais préventive, car parfaitement intégrée au cycle du développement (sur la machine du développeur, dans les pipelines d’intégration, etc.). Les développeurs participent systématiquement à la remédiation.
Au-delà du modèle de maturité, un élément clé à retenir est qu’un processus de gestion des secrets efficace doit aussi anticiper l’échec. Il convient en particulier d’avoir réfléchi aux questions suivantes pour améliorer la résilience du modèle :
* Que se passe-t-il après qu’un secret ait été divulgué ?
* Comment pouvons-nous être sûrs qu’aucun secret n’ait été divulgué dans le passé ?
* Que pouvons-nous faire pour empêcher qu’ils ne soient divulgués en premier lieu ?
En définitive, les secrets ne sont pas très différents des autres processus de sécurité, dans la mesure où l’erreur humaine est, de loin, la première cause des défaillances. Se préparer à savoir quand (et non si !) un secret sera codé en dur quelque part dans le cycle de développement doit faire partie du processus de gestion des secrets.
Armées de ces conseils et équipées de ce modèle de maturité, les organisations ont désormais toutes les clés en main pour évaluer où elles en sont exactement, et mettre en œuvre une stratégie cohérente afin de renforcer leur résilience face aux pertes de secrets, l’une des principales causes de fuite de données massive.
___________________
Par Thomas Segura, Technical Specialist, GitGuardian
puis