Augmentation de la surface d'attaque par la présence de secrets dans le code source

Premier article d'une série sur la problématique des "secrets" dans le code source : clés d'API, certificats, clés privées. Ce premier volet aborde le concept de fuites de secrets, leur distribution non maîtrisée sur plusieurs systèmes, et la manière de les empêcher.

Qu'est-ce qu'un secret et comment les utiliser ?

Pour vraiment comprendre comment les secrets fuitent, nous devons d'abord comprendre ce qu'est un secret, et comment ils sont utilisés.

Un secret peut être toute donnée sensible que l'on souhaite garder privée. Lorsqu'on parle de secrets dans le contexte du développement de logiciels, on fait généralement référence à des éléments d'authentification qui permettent d'accéder à des services, des systèmes et des données. Il s'agit le plus souvent de clés API, de noms d'utilisateur et de mots de passe, ou de certificats de sécurité.

Comment les secrets sont-ils utilisés ? Les applications ne sont plus des monolithes autonomes, elles s'appuient désormais sur des milliers de blocs indépendants : infrastructure dans le cloud, bases de données, composants SaaS tels que Stripe, Slack, HubSpot... Il s'agit d'un changement important en ce qui concerne le développement logiciel.

Les secrets servent à relier les différents blocs d'une application en créant une connexion sécurisée entre chaque composant.

La création d'applications sous forme de clusters de service indépendants (on parle d’architecture en microservices) présente d'énormes avantages par rapport à l’architecture monolithique. Cela inclut la possibilité de mettre à jour les services de manière indépendante, de faire évoluer rapidement les applications et de décharger le travail de développement vers des services externes dédiés. Cependant, en contrepartie nous devons maintenant gérer des centaines, voire des milliers de secrets pour chaque composant et ces secrets sont critiques pour les organisations. Les secrets donnent accès aux systèmes les plus sensibles.

Le dilemme du secret

Comme ces secrets relient chaque composant d'une application, les développeurs doivent y avoir accès pour construire, connecter, déployer et tester les applications. Cela crée un dilemme car les secrets sont extrêmement sensibles, mais ils doivent être accessibles aux développeurs, aux applications et à l'infrastructure.

Pour faire face à ce dilemme, il faut des systèmes et des politiques de gestion des secrets réfléchies et souvent complexes. S'ils ne sont pas traités avec une attention et un soin extrêmes, vos secrets se disperseront facilement dans de nombreux systèmes différents.

Comment les secrets se répandent sur les réseaux

Si une personne veut se rendre d'un point A à un point B, il est évident qu'elle choisira le chemin de moindre résistance pour y parvenir. Soyons réalistes : nous n'allons pas choisir un chemin plein d'obstacles si nous pouvons l'éviter.

Cela peut s'appliquer à la gestion des secrets. En gardant les secrets cryptés et très protégés, il est plus difficile pour les développeurs d'y accéder et de les distribuer. Cela peut nous amener à choisir la voie de la moindre résistance lors de leur manipulation, ce qui peut inclure leur codage en dur dans le code source, leur distribution par courrier électronique ou par des systèmes de messagerie comme Slack, leur enregistrement direct dans des fichiers de configuration et leur stockage dans des wikis internes.

Le danger n'est peut-être pas immédiatement apparent, car tous ces systèmes disposent encore d'un certain niveau de contrôle d'accès, mais dès que des secrets commencent à se répandre dans différents systèmes, vous perdez :

Le contrôle de l'endroit où vos secrets aboutissent et qui y a accès.
La visibilité sur l'emplacement de vos secrets.

Pourquoi la dispersion des secrets est-elle dangereuse : la surface d'attaque

Prenons l'exemple du codage en dur de secrets dans le code source. Ce code pourrait être partagé dans un message sur Slack, téléchargé dans un dépôt git, cloné sur plusieurs postes de travail professionnels et personnels différents, forké dans un projet différent, inclus dans un gestionnaire de package et finalement accessible à un acteur malveillant.

Tous ceux qui ont accès à ces systèmes ont maintenant accès aux secrets qu'ils contiennent. Ce qui est encore plus inquiétant, c'est que vous n'avez aucune visibilité sur la destination finale de ces secrets et que vous ne savez peut-être même pas quand ils sont compromis.

Même si les secrets ne se retrouvent pas sur l'espace public sur internet (par exemple dans un dépôt git public), ils doivent être considérés comme compromis s'ils existent dans des systèmes non sécurisés où que ce soit. Considérez les numéros de carte de crédit stockés en clair, les incluriez-vous dans un dépôt git ? Les partageriez-vous sur Slack ? Les secrets sont tout aussi sensibles, sinon plus.

Lorsque des secrets sont disséminés dans plusieurs systèmes, cela augmente ce que l'on appelle la surface d'attaque, c'est-à-dire le nombre de points où un utilisateur non autorisé peut accéder à vos systèmes ou à vos données. Dans le cas d'une dispersion de secrets, chaque fois qu'un secret entre dans un autre système, c'est un autre point d’entrée pour un attaquant essayant d’accéder à vos secrets.

Considérez les secrets comme des portes d'entrée dans votre organisation. Plus il y a de portes, plus il y a de chances que quelqu'un les trouve. Ces portes ne peuvent pas seulement être utilisées pour accéder à des données ou des systèmes sensibles. Elles peuvent aussi donner accès à d'autres systèmes et être utilisées latéralement entre eux. En d'autres termes, un secret peut déverrouiller plusieurs portes dans votre organisation.

Ce qui rend l'accès non autorisé par le biais de secrets particulièrement inquiétant, c'est qu'une fois qu'une personne est authentifiée par le biais d'un secret, elle agit et semble être un utilisateur valide. Cela rend la détection très difficile et permet à un attaquant de se cacher dans les systèmes sans être détecté pendant de longues périodes.

Empêcher la dispersion des secrets

Il n'y a pas de solution magique que je puisse proposer dans cette section, mais la prévention de la dispersion des secrets s'articule autour de quatre éléments liés entre eux :

Mise en œuvre de politiques et de bonnes pratiques en matière de traitement des secrets,
Visibilité fine des systèmes et des services,
Application des politiques et des pratiques,
Stockage sécurisé des secrets.

Mise en œuvre de la détection automatique des secrets et de la remédiation par les développeurs

La création de politiques relatives au traitement des secrets et l'utilisation des meilleures pratiques de codage sont des mesures importantes pour lutter contre la dispersion des secrets, mais elles sont inutiles si elles ne sont pas appliquées.

Dans le monde réel, la plupart des développeurs et des organisations fonctionnent à l'aveugle, sans visibilité sur leurs systèmes, ce qui entraîne une absence de visibilité sur les pratiques et les politiques. Si vous ne voyez pas le problème, vous ne pouvez pas appliquer la solution. C'est pourquoi la lutte contre la dispersion des secrets commence par une visibilité fine de vos systèmes.

Il existe des outils de détection des secrets permettant une analyse historique et incrémentale du code et alertant le développeur et l'équipe de sécurité des applications en temps réel pour s'assurer que les informations d'identification exposées sont correctement révoquées, que les politiques en matière de secrets sont respectées et que les normes de conformité sont respectées.

Stockez vos secrets en toute sécurité grâce à un contrôle d'accès strict

Une fois que vous avez acquis une visibilité sur vos systèmes, vous devez être en mesure de stocker vos secrets dans un endroit sûr et de l'entourer d'un contrôle d'accès strict. La nécessité de ce système diffère réellement selon les projets. Ce qui importe, c'est que vos secrets restent cryptés lorsqu’ils sont stockés et lorsqu’ils sont utilisés.

Pour les projets de grande envergure, utilisez un produit "secrets en tant que service" qui stocke vos secrets en toute sécurité avec un contrôle d'accès de haut niveau. Il permet des secrets dynamiques (avec rotation automatique des secrets), ce qui vous donne un plus grand contrôle, et il fournit également des logs d'accès. La mise en place et le fonctionnement de ces systèmes nécessitent beaucoup de ressources.

Les petites équipes peuvent envisager de chiffrer les secrets et de les stocker dans git pour en faciliter la distribution. Vous pouvez utiliser une solution open-source comme git-secret. Moins de ressources sont nécessaires, mais il faut introduire une master key qui peut être difficile à distribuer, et qui ne dispose pas de logs d'accès.

En résumé

Les secrets, comme les clés API, les certificats de sécurité, et les informations d'identification, sont très sensibles car ils permettent d'accéder à des données et des systèmes sensibles. Entre de mauvaises mains, ces secrets peuvent permettre à un attaquant de rester à l'intérieur des systèmes sans être détecté.

Les secrets étant largement utilisés dans le cycle de vie du développement logiciel moderne, ils ont facilement tendance à se disperser dans les dépôts git, les systèmes de messagerie, les infrastructures et les postes de travail.

La surface d’attaque augmente alors, ce qui permet à un acteur malveillant de découvrir plus facilement des secrets et même de se déplacer latéralement dans les systèmes. Pour éviter la dispersion des secrets, les développeurs devraient se former, utiliser des produits de détection automatique des secrets, et des systèmes de gestion des secrets.