Par définition, les secrets tels que les API key, les Oauth token, les mots de passe ou encore les certificats sont des données hautement sensibles. Pourtant, ils se retrouvent trop souvent sur les serveurs Git. Or ces secrets peuvent donner des droits très étendus et ouvrir l’accès à une importante partie du système d’information jusqu’aux données les plus sensibles et se traduire par des conséquences business catastrophiques.
Quelles sont les solutions pour stocker vos secrets ? Comment détecter les secrets présents dans vos codes sources ? Astrakhan vous propose une solution simple et efficace, quelle est-elle ? Lisez notre article ci-dessous.
Les secrets dans le code source
Les secrets tels que les API key, les Oauth token, les mots de passe ou encore les certificats sont par définition des données sensibles. Pour autant, ils se retrouvent trop souvent sur les serveurs Git et sont ainsi distribués et propagés à chaque nouveau clone ou fetch du repository. Il s’agit pourtant d’une mauvaise pratique et d’une vulnérabilité bien connue figurant dans le Top 10 OWASP (A3:2017-Sensitive data exposure). Il n’en reste pas moins qu’il soit courant que des AWS Access Key et AWS Secret Key fuitent dans des repositories sur GitHub pouvant mener, dans le meilleur des cas, à des grosses factures. Il suffit de consulter cet historique pour s’en convaincre :
Il s’agit donc d’un sujet d’autant plus problématique qu’avec l’adoption de l’« Infrastructure as Code », ces secrets peuvent donner des droits très étendus et ouvrir l’accès à une importante partie du système d’information jusqu’aux données les plus sensibles et se traduire par des conséquences business catastrophiques.
Ajoutons qu’une fois ajouté dans Git, un secret ne peut plus être supprimé ou difficilement. Pour ce faire, il faut en effet pouvoir réécrire l’historique Git, le propager historique dans toutes les copies et enfin s’assurer du passage de git-gc pour détruire définitivement les objets concernés. Finalement révoquer ce secret s’avère être la seule et unique solution viable.
Les solutions pour stocker vos secrets
Différentes solutions sont à disposition pour gérer vos secrets :
● Une première catégorie d’outils propose le chiffrement symétrique pour stocker une version chiffrée de vos secrets dans Git. C’est le cas d’outils comme Sealed Secret ou Ansible vault par exemple.
● Une deuxième catégorie se présente sous forme de services coffre-fort vous permettant de gérer vos secrets, y accéder depuis vos applications, organiser leur rotation et suivre précisément qui les consomment. Les fournisseurs de Cloud proposent tous ce service sous le nom de Secret Manager pour AWS et Google Cloud ou Key Vault pour Azure également disponible on-premise avec Hashicorp key vault.
● Enfin si vous travaillez sur un projet Cloud avec des services managés, les fournisseurs Cloud vous proposent des librairies à utiliser dans votre code source se basant sur l’authentification IAM. Cette dernière autorise la connexion à ses services sans nécessiter aucun secret. Cela consiste à créer et rattacher un rôle IAM à votre application. Ce rôle autorise l’accès à une base de données ou tout autre service supportant ce type d’authentification.
La dernière solution avec authentification IAM est recommandée, devançant l’utilisation de service de type coffre-fort, lui-même devançant l’utilisation de chiffrement symétrique.
Détecter les secrets présents dans vos codes sources
Git Secrets, Truffle Hog, Git Leaks, GitLab/GitHub Watchman, les outils se multiplient pour vous aider à détecter et protéger vos données sensibles en scannant vos repositories Git.
Pour éviter l’introduction de nouveaux secrets, une solution consiste à intégrer un de ces outils dans vos pipelines de CI/CD. Les nouveaux développements étant réalisés sur des « feature branches » soumis à la revue avant d’être mergés vers la branche « master » (ou « develop »), l’objectif de la CI/CD est alors de bloquer tout merge de « feature branch » qui contiendrait des secrets afin de conserver un historique Git propre sur la branche « master ».
Si cette solution est intéressante pour surveiller un repository, qu’en est-il si vous en avez des centaines ?
Chez Astrakhan, nous vous proposons une solution simple et efficace au travers de ce script qui va réaliser les étapes suivantes :
● Lister récursivement tous les projets d’un groupe GitLab
● Lancer Git Leaks sur chaque projet
● Transformer le rapport Git Leaks en rapport junitxml intégré et restitué via l’interface GitLab
Et même (commenter dans la version partagée) envoyer les secrets ainsi détectés vers Splunk (ou votre solution de monitoring) pour permettre un suivi au travers des tableaux de bord et aussi la mise en place d’alertes sous forme de notifications mail vers les auteurs des commits Git concernés.
