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.
Un pipeline de déploiement (automatique ou semi-automatique) gère le processus de configuration d’un environnement pour livrer une nouvelle version d’application ou logiciel. Plusieurs environnements sont en jeu (par exemple, développement, staging et production) et en fonction de critères prédéfinis (branches, tags, quality gate, etc.) le pipeline peut orchestrer des tests post-déploiement tels que :
- UAT
- tests de charge, etc.
La mise en place de bonnes pratiques et d’outils adéquats est essentielle pour garantir un déploiement sécurisé et efficace.
Cet article de Gologic se concentre sur la sécurité des pipelines de déploiement continu (CD). Vous verrez qu’il est essentiel de mettre en place des mesures de conformité et d’audit pour assurer la sécurité des pipelines, des environnements cibles et des points d’intégration entre les outils et les environnements.
Il convient de bien isoler les environnements de déploiement, de restreindre correctement les accès et de protéger votre dépôt d’artefacts en signant les artefacts pour renforcer la sécurité. La détection précoce de toute anomalie est essentielle pour maintenir l’intégrité de ces systèmes. Une intervention humaine est requise pour valider les étapes critiques du processus.
Sécuriser les environnements cibles et les points d’intégration
Les points d’intégration font référence aux systèmes qui déploient les applications dans les environnements cibles (développement, staging et production), ainsi qu’aux autres outils tiers requis pour le déploiement, tels que le dépôt d’artefacts ou la détection de secrets.
En ce qui concerne les techniques et les outils de déploiement, nous observons deux grandes tendances : déclarative et impérative.
- Déploiements impératifs : utilise des scripts pour exécuter le déploiement, par exemple, la commande kubectl ou helm dans le cas de Kubernetes. Dans ce cas, le script de déploiement est exécuté par des pipelines à l’aide d’outils tels que Jenkins, Azure Pipeline, GitHub Actions, etc. Cette approche s’appelle aussi un « push system », où les modifications sont poussées vers l’environnement.
- Déploiements déclaratifs : connus sous le nom de GitOps, ils reposent sur la modification de la configuration dans un dépôt de code Git pour définir l’état souhaité. Dans le cas de Kubernetes, un opérateur tel que ArgoCD ou FluxCD appliquera, ces modifications dans le cluster. Cette approche s’appelle aussi un « pull system », où l’environnement extrait les modifications d’une source de vérité.
Chacune de ces deux méthodes de déploiement a ses avantages et les organisations peuvent choisir l’une ou l’autre en fonction de leurs attentes en matière de contrôle et sécurité.
Les déploiements impératifs offrent un contrôle plus explicite, mais souffrent du même risque de sécurité que les pipelines CI que nous avons discuté dans l’article : « Sécuriser les pipelines d’intégration continue (CI) ». Chaque pipeline doit être capable de déployer uniquement dans un environnement donné et posséder seulement le minimum d’accès requis. Des vérifications automatiques de conformité doivent être en place et empêcher le déploiement si les critères ne sont pas remplis.
Les déploiements déclaratifs nécessitent un contrôle d’accès robuste du référentiel Git pour empêcher les modifications non autorisées, similaires à ce que nous avons vu dans l’article « Sécurité du système de gestion des versions ». Dans ce cas, il n’y a pas de préoccupation concernant les cibles de déploiement, car l’environnement lui-même est responsable de synchroniser les modifications. Cependant, une pull-request devrait être requise, et une vérification de conformité devrait être en place, comme nous le verrons dans la section suivante.
Conformité et audit
Le déploiement automatisé doit suivre un processus de validation clair. Il peut être principalement automatisé, mais avoir ce processus améliorera non seulement la sécurité, mais aussi la fiabilité. Voici les principales règles que vous devriez intégrer à votre pipeline de déploiement :
- Maintenir la chronologie de tous les déploiements, y compris l’ajout de nouvelles fonctionnalités, les mises à jour de configuration et l’historique du changement de code. Cela peut être réalisé en publiant une « note de livraison » et en faisant approuver ces changements par les parties prenantes.
- Des preuves (évidences) de scan de vulnérabilité, de tests de pénétration et/ou d’analyse de code statique doivent exister avant le processus de déploiement.
- Pour les versions majeures, définissez un processus de gestion des changements qui inclut l’approbation des changements par les parties prenantes concernées. Les changements majeurs peuvent être identifiés en utilisant le système de version sémantique et même la quantité de code modifié pour évaluer le risque.
Enfin, il peut être important de travailler en étroite collaboration avec les équipes de conformité et juridiques de votre organisation. Cela est utile pour établir des règles et des procédures spécifiques pour les environnements avec des normes de conformité imposées par une législation (exemples concrets : HIPAA, GDPR, PCI DSS).
Répertoires d’artefacts sécurisés
Un point d’intégration que nous n’avons pas encore couvert dans la première section concerne les répertoires d’artefacts. Ils stockent les artefacts produits pendant la phase d’intégration continue et déployés dans votre environnement. Idéalement, vous devez vous assurer que l’artefact produit est réellement celui utilisé. Cela permet de détecter les brèches de votre système de déploiement continu (CI) ou de votre répertoire d’artefacts et d’empêcher la diffusion d’artefacts contrefaits ou corrompus en production.
Les artefacts peuvent être signés numériquement dans le cadre du processus de build. Cette signature sert de sceau. Le pipeline de déploiement peut ensuite vérifier cette signature pour s’assurer qu’aucune modification n’a été apportée. Cela est particulièrement important lors du déploiement en production, car cela contribue à garantir l’intégrité de votre logiciel.
Conclusion
La sécurité des pipelines de livraison continue est cruciale pour livrer des logiciels à la fois sécurisés et fiables. Après tout, c’est la dernière étape du processus, une revue minutieuse à cette étape garantira de livrer des applications de meilleure qualité.
Il est important de s’assurer que des mesures de conformité sont en place. Vous devez principalement sécuriser les points d’intégration tels que le référentiel Git (en particulier pour les déploiements déclaratifs) ou le système de pipelines (particulièrement pour les déploiements impératifs). Dans les deux cas, la sécurisation des répertoires d’artefacts (avec l’inclusion de la signature d’artefact) est cruciale pour protéger le système et détecter les problèmes avant la mise en production.
Cet article est le quatrième de notre série : « DevSecOps : Pipelines CI/CD sécurisés » où nous avons cartographié les différentes failles de sécurité et couvert la plupart des flux CI/CD. Cela comprend :
- les systèmes de gestion des versions
- les pipelines d’intégration continue
- les pipelines de déploiement continu
Prochainement, nous aborderons des sujets plus spécifiques, notamment la gestion des secrets, la gestion des artefacts, l’observabilité et la gestion des incidents de sécurité.
Ne manquez pas cette occasion d’approfondir vos connaissances en DevSecOps. Restez à jour, améliorez vos compétences et sécurisez vos pipelines CI/CD avec nos guides pratiques. Contactez-nous pour une consultation personnalisée.
Par Gologic, en collaboration avec Alexandre Couëdelo.
