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

L'accès des pirates au code de votre application peut être dévastateur 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.

L'accès des pirates au code de votre application peut être dévastateur 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é, il s'agit d'une bonne gestion des risques pour minimiser les dommages potentiels.

Accès au contrôle de source en tant que 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. Même si le fait de rendre le code public signifie que les pirates peuvent trouver plus facilement des exploits, l'open source a prouvé qu'il peut être excellent pour la transparence et la correction des bugs de la communauté.

Toutefois, cela ne signifie pas que les logiciels fermés sont intrinsèquement plus sécurisés. Lorsque les développeurs supposent que le contrôle de code source est privé, ils choisissent souvent la solution la plus simple lorsqu'ils gèrent des secrets tels que des clés API ou des informations d'identification de 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 des 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, accédant souvent à des données ou bases de données client sensibles.

Récemment, la liste d'interdiction de vol de la TSA a été divulguée via cette méthode exacte. Un serveur de build 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 informatique a pu accéder à l'historique de construction, qui contenait le code, et a trouvé les informations d'identification AWS S3 de 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 dispose de méthodes différentes pour stocker en toute sécurité les clés 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 au moment de l'exécution. Par exemple, les projets ASP.NET utilisent par défaut un

appsettings.json

fichier vide alors qu'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 définies par le système avant d'exécuter une application. Ceci est couramment utilisé pour les conteneurs Docker, car c'est 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, c'est une bonne idée d'effectuer régulièrement une rotation des secrets, car les informations d'identification obsolètes présentent un risque de sécurité. L'un des outils capables de gérer les secrets en rotation est le Secrets Manager d'AWS, qui agit comme un système de stockage pouvant 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 exactement la clé IAM. 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 de Secrets Manager auxquelles il peut accéder. Vous pouvez également appliquer des politiques de sécurité aux utilisateurs IAM, en exigeant également une rotation régulière.

Ne stockez pas de secrets dans les scripts de build

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

Par exemple, vous pouvez disposer d'un script shell ou d'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 parvenait à accéder à ce script, il serait en mesure de 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 des actions GitHub et a besoin d'informations d'identification pour fonctionner, vous pouvez également utiliser des secrets pour les injecter dans le processus de construction 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 tout en créant une application à laquelle des informations d'identification de production seront injectées avant son déploiement.

Les secrets GitHub créés au sein d'une organisation peuvent même être partagés sur plusieurs référentiels, offrant ainsi 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.