Cette série d’articles a pour but d’identifier les meilleures pratiques à mettre en place pour sécuriser votre processus de livraison et vos pipelines CI/CD :
0. DevSecOp : Sécuriser les pipelines CI/CD, comprendre les fondements
1. La sécurité du système de gestion des versions
2. Sécuriser les pipelines d’intégration continue (CI)
3. Sécuriser les pipelines de déploiement continu (CD)
Par Gologic, en collaboration avec Alexandre Couëdelo.
Le logiciel de contrôle de version Git est au cœur de la majorité des chaînes d’assemblage logicielles. De très nombreuses entreprises s’appuient sur des plateformes SaaS telles que Azure DevOps, GitHub ou GitLab pour bénéficier en plus de tout un écosystème d’outils incluant les pipelines CI/CD, la gestion des artefacts, voire même de l’infrastructure.
Dans ce contexte, nos services DevOps offrent une expertise approfondie pour optimiser et sécuriser ces environnements de développement, en veillant à intégrer de manière fluide leurs solutions au sein des processus existants. L’importance de choisir les meilleurs outils pour une gestion efficace ne peut être sous-estimée.
Le système de gestion des versions est utilisé pour archiver le code et produire un historique de toutes les modifications successives apportées. Particulièrement utiles pour référencer une version précédente d’un projet, ces systèmes facilitent la mise à jour et le suivi des changements dans le code. De plus, les systèmes de gestion des versions peuvent jouer un rôle crucial en tant que système de gestion de configuration via l’approche GitOps pour configurer le déploiement des applications et des composantes d’infrastructure.
Cet article examine comment mieux protéger votre système de contrôle des versions. Nous verrons d’abord les défis courants en matière de risque, puis comment encourager les développeurs à y accéder de manière plus sécuritaire.
Évaluation du risque
Le processus de développement est centré autour des dépôts Git (système de gestion des versions), ce qui en fait un élément critique que vous devez protéger en adoptant les meilleures pratiques de sécurité. Lorsqu’il s’agit de sécurité, il est essentiel de se demander d’abord ce que nous craignons (ou le risque). Dans le cas des systèmes de contrôle de version, nous devons considérer deux cas :
- Accès non autorisé : Lorsqu’un utilisateur externe (à votre entreprise) est en mesure de télécharger ou de consulter le code source archivé dans le système de gestion des versions, cela peut causer des fuites de code (code leak). Ces fuites peuvent aider des attaquants qui étudient votre système de l’intérieur et préparent la prochaine attaque. S’ils ont de la chance, ils peuvent trouver des données sensibles codées en dur (secrets ou données utilisateur)
- Écriture non autorisée : Lorsqu’un utilisateur externe (à votre entreprise) peut modifier le code source archivé dans le système de gestion des versions, c’est un problème beaucoup plus grave. L’attaquant peut injecter du code malveillant directement dans votre système en production.
Dans les sections suivantes, nous parlerons des techniques à mettre en place pour réduire les deux risques ci-dessus.
Accès aux dépôts de code (repositories)
La première étape consiste à définir correctement les droits d’accès au dépôt de code, en précisant qui peut y accéder à quoi. Ensuite, vous devez mettre en place des règles de contribution, c’est-à-dire décider comment utiliser l’outil Git en tenant compte d’éventuelles usurpations d’accès (l’attaquant se connecte avec un utilisateur valide). La plupart des équipes adoptant la livraison continue doivent protéger leur branche principale (celle qui est automatiquement déployée en production). Pour cela, nous identifions trois piliers :
- Obligation de contributions via des pull requests. Cela crée une zone d’attente
- Obligation d’avoir au moins une revue des contributions par un développeur
- Obligation de validation automatique (nous dédirons un article entier à ce sujet)
💡 Branch Protection and Policy with Azure DevOps
Dans le cas d’Azure DevOps, vous devriez envisager d’utiliser les fonctionnalités suivantes :
- Exiger un nombre minimum de réviseurs : un certain nombre de réviseurs doivent approuver une pull request avant qu’elle puisse être fusionnée
- Validation de build : Déclencher un pipeline de build pour vérifier si le code compile correctement et réussit les tests avant de permettre la fusion
- Vérifications d’état requises : Vous pouvez spécifier que certaines étapes de vérifications (Gates), comme l’analyse de code ou l’analyse de sécurité, doivent passer avant qu’une branche soit fusionnée
Identification du Développeur
Une fois que les autorisations sont correctement définies, vous devez vous assurer qu’un attaquant ne puisse pas se faire passer pour votre développeur (usurpation). Le risque de fuite de mots de passe ou de clés SSH par les développeurs est réel, et des stratégies de mitigation doivent être mises en place. Ceci peut être réalisé en employant une base de données sécurisée pour le stockage et la gestion de ces informations critiques.
Identifiants du développeur
L’accès à un dépôt Git peut être obtenu via HTTPS + mot de passe ou SSH. SSH est généralement considéré comme plus sécurisé, car une clé SSH est beaucoup plus complexe que les mots de passe de vos développeurs. Cependant, ces fichiers critiques (clés SSH) résident par défaut quelque part sur l’ordinateur de vos développeurs. Par bon sens, il est recommandé de changer fréquemment la clé SSH et d’utiliser des phrases secrètes (passphrase).
La phrase secrète empêche un attaquant d’utiliser une clé SSH volée, car il a besoin de connaître cette fameuse phrase secrète. Lorsque vous utilisez une passphrase, vous devez entrer votre phrase secrète la première fois que vous utilisez votre clé. Elle sera ensuite mémorisée par votre agent SSH jusqu’à ce que vous redémarriez votre ordinateur.
Une solution alternative consiste à utiliser un gestionnaire de mots de passe « intelligent » qui gère le SSH pour vous. Ils sauvegarderont la clé dans votre coffre-fort (vault) et se chargeront de la fournir à l’agent SSH sans jamais écrire la clé sur le disque dur. Elle sera ainsi très difficile à voler.
Identité du développeur
L’identité du développeur (courriel et nom) doit être définie dans leur fichier .gitconfig, ce qui permet d’associer tout commit au bon utilisateur. Cependant, il est assez facile de spécifier n’importe quel nom d’utilisateur en tant qu’auteur d’un commit.
Par conséquent, le nom et le courriel présents dans les commits ne sont pas fiables pour identifier le véritable auteur d’un commit. La signature des commits avec une clé SSH ou GPG est donc une sécurité supplémentaire recommandée pour assurer la traçabilité des modifications du code source.
💡 Developer Authentication on Azure DevOps
Utiliser la méthode d’authentification par clé SSH nécessite seulement deux étapes supplémentaires pour une meilleure sécurité. Cela en vaut surement la peine !
- Générez une paire de clés SSH : Si vous n’avez pas déjà une paire de clés SSH, générez-en une sur votre machine locale en utilisant l’utilitaire ssh-keygen
- Ajoutez la clé publique à votre compte Azure DevOps : allez sur votre compte Azure DevOps. Cliquez sur votre photo de profil en haut à droite et sélectionnez « Sécurité ». Sous « Clés publiques SSH », cliquez sur « Ajouter » et collez la clé publique
Conclusion
Protéger votre système de contrôle de versions est crucial pour la sécurité de votre chaîne de livraison de logiciels.
Cette approche, soutenue et recommandée par Gologic est essentielle pour le lancement réussi de nouvelles fonctionnalités. C’est le point de départ pour la plupart de vos systèmes de livraison continue.
Pour assurer la sécurité de votre code source, il est important de prendre des mesures pour empêcher l’accès non autorisé ou son altération. Vous devez vous assurer que les développeurs suivent les meilleures pratiques pour accéder à vos dépôts de code ainsi que configurer la protection pour les contributions (réviseurs requis et validation automatisée sur toutes les branches et pull request).
Cependant, sécuriser votre système de contrôle de versions n’est qu’un aspect de la sécurisation de l’ensemble de votre processus de développement logiciel. Êtes-vous prêt à renforcer la sécurité de votre système de contrôle de versions ? N’attendez plus pour adopter ces pratiques essentielles. Commencez dès aujourd’hui à protéger vos projets logiciels et prenez une longueur d’avance en matière de sécurité informatique. Contactez notre équipe d’experts pour des conseils personnalisés et assurez la pérennité de vos développements.
Notre prochain article portera sur les meilleures pratiques de sécurité pour le système d’intégration continue (CI).
Par Gologic, en collaboration avec Alexandre Couëdelo.
