Les secrets autour du code source sont souvent mal gardés… parce que mal compriss. C’est l’avis de Thomas Segura, Technical Content Writer, GitGuardian.

La gestion des secrets est sans doute devenue l’un des sujets DevOps les plus discutés ces dernières années. « Nous avons assisté à de nombreux débats techniques sur la manière de trouver le meilleur équilibre entre sécurité et flexibilité, mais aucun ne semble avoir vraiment résolu le problème avec une réponse définitive. Le fait est que nous sommes presque sûrs qu’une telle réponse n’existe pas, estime Thomas Segura. Pourquoi ? Parce qu’il n’y a tout simplement pas de solution unique. »

Mais alors, quelles sont les meilleures options ? Les opinions diffèrent sur « la bonne façon » de gérer les secrets. Ici, on vous dira : « vous devriez toujours utiliser un coffre ! ». Là, « les secrets chiffrés dans git ne sont pas sûrs ! ». Là, encore, « les secrets de longue durée devraient être interdits ». Plus radical : « certains développeurs ne devraient jamais avoir à toucher à un secret ». Ce n’est évidemment pas réaliste. Les secrets sont utilisés par toutes les personnes et tous les actifs dans les usines de logiciels modernes ; ils ne montrent aucun signe de ralentissement.

Le code source, un actif qui fuit

Avoir une meilleure idée de la maturité d’une organisation concernant la façon dont les secrets sont gérés, supervisés et protégés contre les fuites (involontaires) est primordial. C’est exactement l’objectif du Secrets Management Maturity Model.

« Numérique par essence, le code source est un actif qui fuit, illustre Thomas Segura. Les systèmes de contrôle de version distribués et les plateformes de partage de code ont grandement facilité la prolifération et le clonage de bases de code entières sur Internet. »

Cette situation a alimenté la communauté des logiciels libres et conduit à de grandes réalisations, mais reste problématique pour un nombre croissant d’entreprises pour lesquelles le code source est un actif de valeur fondamentale. Assurer le respect des droits d’auteur du code source à l’échelle mondiale est devenu une tâche presque impossible.

Les secrets sont partout

Le code source peut également contenir des secrets commerciaux, qui ne peuvent être protégés par des droits d’auteur, des brevets ou des marques. Dans un secteur où l’innovation et la rapidité sont si cruciales, ne pas réussir à garder ce type d’informations secrètes pourrait signifier la fin du jeu pour les entreprises les plus jeunes. D’une manière générale, pour les entreprises, éviter les frais de justice est également un motif pour mieux surveiller et contrôler quelle partie du code source a été partagée, et avec qui. Sur un autre plan, le code source publié donne aux pirates une vue de l’intérieur des systèmes déployés en production au service, parfois, de millions d’utilisateurs. Cela peut également poser problème.

« 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 ! »

Ne nous leurrons pas. Même des suggestions moins extrêmes, telles que l’interdiction des secrets à longue durée de vie 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. Cela va de la supervision de leur usage jusqu’à la détection de leurs fuites involontaires.

Le Software Development Life Cycle comme base

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 SDLC (Software Development Life Cycle) traditionnel :

* L’environnement du développeur
* La gestion du code source
* Les pipelines CI/CD et artefacts
* Les environnements d’exécution

Quatre niveaux

À 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.

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.

L’erreur est… humaine

Au-delà du modèle de maturité, un élément clé à retenir est qu’un processus efficace de gestion des secrets doit gérer ses modes de défaillance : « Que se passe-t-il après qu’un secret a fui ? », « Comment pouvons-nous être sûrs qu’aucun secret n’a fui dans le passé ? », « Que pouvons-nous faire pour les empêcher de fuir en premier lieu ? » sont quelques-unes des questions les plus importantes à se poser pour une organisation souhaitant améliorer la résilience de la sécurité de ses secrets.

Les secrets ne sont pas 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 de sécurité. La préparation du moment où (pas si) un secret sera codé en dur quelque part dans le cycle de développement doit faire partie du processus de gestion des secrets.