Comment protéger les secrets et informations d’identification sensibles dans votre référentiel Git

Les pirates qui accèdent au code de votre application peuvent être dévastateurs pour les logiciels propriétaires, mais le stockage des informations d’identification dans Git peut leur donner un accès élevé à la base de données. Même si vous ne prévoyez pas que votre référentiel Git soit piraté, c’est une bonne gestion des risques pour minimiser les dommages potentiels.

Accès au contrôle de source comme vecteur d’attaque

Les logiciels open source ne sont pas dangereux ; après tout, une grande partie des logiciels utilisés pour faire fonctionner Internet sont développés publiquement sur GitHub. Bien que le fait que le code soit public signifie que les pirates peuvent trouver des exploits plus facilement, l’open source a prouvé qu’il peut être excellent pour la transparence et la résolution de bogues par la communauté.

Cependant, cela ne signifie pas que les logiciels à source fermée sont intrinsèquement plus sûrs. Lorsque les développeurs supposent que le contrôle de source est privé, ils choisissent souvent la solution la plus simple pour gérer les secrets tels que les clés d’API ou les informations d’identification de la base de données : les coder en dur dans l’application plutôt que d’utiliser une gestion appropriée des secrets.

L’un des principaux vecteurs d’attaque pour les pirates informatiques consiste à accéder au contrôle des sources et à analyser les projets à la recherche de clés API ou d’autres secrets qui ne devraient pas s’y trouver. Cela leur permet d’élever leurs autorisations et d’attaquer le reste du réseau, en accédant souvent à des données client ou à des bases de données sensibles.

Récemment, la liste « No-Fly » de la TSA a été divulguée via cette méthode exacte. Un serveur de construction Jenkins non sécurisé a été laissé ouvert au public, une erreur courante commise lors de la configuration d’un logiciel censé se trouver dans des sous-réseaux privés derrière le contrôle d’accès. Sur le serveur Jenkins, le pirate a pu accéder à l’historique de construction, qui contenait le code, et a trouvé les informations d’identification AWS S3 pour la compagnie aérienne qui étaient codées en dur dans l’application.

Ne stockez pas de secrets dans le contrôle de code source

Chaque application aura différentes méthodes pour stocker en toute sécurité les clés d’API et les informations d’identification de la base de données, mais il existe quelques méthodes courantes.

La première consiste à utiliser des fichiers de configuration, qui peuvent être déployés en production sur le serveur, et lus par l’application lors de l’exécution. Par exemple, les projets ASP.NET utilisent par défaut un appsettings.json fichier qui est vide lorsqu’il est stocké dans le contrôle de code source. Il appartient à l’administrateur déployant l’application de déployer le fichier de configuration de production.

Vous pouvez également utiliser des variables d’environnement, qui sont définies par le système avant d’exécuter une application. Ceci est couramment utilisé pour les conteneurs Docker, car il s’agit d’un moyen simple d’injecter des informations d’identification dans un conteneur déjà construit. Par exemple, Portainer propose la gestion des variables d’environnement dans le cadre de son interface Web Docker.

En règle générale, il est conseillé de faire régulièrement tourner les secrets, car les informations d’identification obsolètes présentent un risque pour la sécurité. L’un des outils capables de gérer la rotation des secrets est le gestionnaire de secrets d’AWS, qui agit comme un système de stockage qui peut facilement fournir des secrets à vos applications AWS.

Pour les applications en dehors d’AWS, ou toute application utilisant un service similaire, il y a un petit problème dans la mesure où vous aurez toujours besoin d’une clé IAM pour accéder à Secrets Manager, ce qui signifie que vous devrez gérer une clé IAM, qui est l’exacte problème avec lequel vous avez commencé.

Cependant, le système IAM d’AWS permet une gestion discrète des rôles et des autorisations. Vous pouvez, par exemple, créer un utilisateur pour chaque serveur dont vous disposez et contrôler les clés auxquelles ils peuvent accéder dans Secrets Manager. Vous pouvez également appliquer des politiques de sécurité aux utilisateurs IAM, ce qui nécessite également une rotation régulière de ceux-ci.

Ne stockez pas de secrets dans les scripts de construction

L’une des pires erreurs de sécurité que les développeurs peuvent commettre est de stocker les clés pour les déploiements de production dans des scripts de construction utilisés dans un pipeline CI/CD.

Par exemple, vous pouvez avoir un script shell ou un fichier YAML utilisé pour contrôler la création, les tests et, surtout, le déploiement de votre application sur vos serveurs ou un service de stockage comme Amazon S3. Cependant, si un attaquant devait accéder à ce script, il pourrait déployer n’importe quoi sur vos serveurs ou compartiments de stockage.

L’un des moyens les plus courants de contourner ce problème consiste à utiliser un outil de gestion des secrets tel que GitHub Secrets, qui stocke les informations d’identification dans votre référentiel accessibles par nom dans les scripts de génération GitHub Actions.

Si votre application est automatiquement déployée à l’aide de GitHub Actions et a besoin d’informations d’identification pour fonctionner, vous pouvez également utiliser des secrets pour les injecter dans le processus de génération au moment de l’exécution, soit en créant les fichiers de configuration nécessaires, soit en définissant les variables d’environnement nécessaires. De cette façon, votre référentiel pourrait même être public et toujours créer une application qui reçoit des informations d’identification de production avant le déploiement.

Les secrets GitHub créés au sein d’une organisation peuvent même être partagés entre plusieurs référentiels, offrant un moyen simple de gérer de manière centralisée les clés sécurisées. D’autres outils de serveur de build comme Jenkins ou TeamCity auront également une gestion intégrée des secrets.