Cependant, il est complexe de mettre en place une chaine CI/CD pertinente et ou on-premise qui demandent également un investissement des équipes d’infrastructure. Les solutions Cloud (PaaS) apparaissent alors comme un bon intermédiaire entre customisation de la chaine CI/CD et simplicité de mise en place. Les solutions cloud permettent également de provisionner des ressources sur demande de façon à s’adapter au mieux aux besoins métier.

Il existe un grand nombre de solutions CI/CD dans le cloud permettant potentiellement de satisfaire les besoins à la fois de sécurité et d’efficacité d’une chaine de développement. Nous proposons ici de présenter notre vision des solutions d’Amazon Web Services (AWS) qui reste un des leader du marché.

Qu’est-ce que les services CI/CD AWS peuvent offrir en termes de fonctionnalités ? Quelle est leur valeur ajoutée ?

Si vous ne connaissez pas AWS CodeCommit, CodePipeline, CodeBuild ou CodeDeploy, nous proposons une entrée en matière pour mieux comprendre le fonctionnement de l’environnement DevSecOps AWS. Afin de présenter un aperçu des outils proposé par AWS, nous décrivons dans les paragraphes suivants le fonctionnement des différents services.

Reprenons depuis le début : du DevOps au DevSecOps

Le DevOps constitue un élément clé du cycle de vie du développement logiciel des entreprises. Le DevOps s’appuie sur un outillage de type CI/CD. C’est une chaîne sur laquelle repose l’évolution du code source en une application livrée en production. La CI/CD accélère les phases de construction, de test et de déploiement afin d’augmenter la fréquence de livraison des applications. Cette accélération est notamment rendue possible par l’automatisation d’un grand nombre de tâches au sein d’un « pipeline CI/CD », comprenez une succession d’actions menant au déploiement en production.

Le DevSecOps rajoute les aspects sécurité au DevOps et s’appuie sur certains outils internes à la CI/CD. Ces outils s’intègrent à tout niveau de la chaîne CI/CD afin de scanner le code source (SAST), les dépendances (SCA) etc. L’objectif est d’intégrer la sécurité au plus tôt, comme présenté dans notre article précédent.

La chaine CI/CD se positionne comme un composant d’intérêt majeur afin d’assurer la sécurité des développements. On peut aller jusqu’à dire que la chaîne CI/CD joue un rôle aussi important dans le développement sécurisé que celui qu’occupe l’AD dans la gestion des identités et des accès (IAM).

La CI/CD dans AWS

AWS offre une multitude de services permettant, en plus des services d’infrastructure classiques, de mettre en place des chaînes de développement continue (du code source à son déploiement) tout en assurant la bonne réalisation des tests de sécurité.

L’orchestrateur CodePipeline permet d’organiser et de lier les différentes étapes de la CI/CD. C’est cet outil qui coordonne la progression au sein du pipeline CI/CD en fonction des résultats des autres outils et services. Si un des outils renvoi un code d’échec, le pipeline peut être bloqué si nécessaire. Les raisons d’un échec du pipeline peuvent être nombreuses : score de sécurité du code insuffisant, échec du déploiement d’un outil…

La gestion du code : SCM et AWS CodeCommit

Les gestionnaires de versions de code (ou SCM : Source Code Manager) sont des outils indispensables dans le développement et sont le point de départ des chaînes d’intégration continue. Ces outils sont essentiels afin d’éditer du code de manière collaborative.

A date, seuls 3 SCM disposent d’une intégration native : GitHub, BitBucket et leur solution propriétaire AWS CodeCommit. Pour toute autre intégration avec un SCM non supporté nativement, il est possible de créer une routine à base de fonctions serverless Lambda et de webhook (notification HTTP) de façon à télécharger le code source dans AWS S3 à chaque commit d’un développeur.

AWS CodeCommit est le service SCM proposé par AWS. C’est un service d’hébergement de code permettant le contrôle de versions et la collaboration supportant les commandes Git, au même titre que GitHub ou GitLab. Ce service a l’avantage d’être pleinement intégré à l’environnement AWS ce qui facilite l’interconnexion avec les autres services AWS. L’utilisation d’AWS CodeCommit permet aussi d’utiliser la solution AWS IAM de gestion des identités et des accès ce qui évite la duplication d’un référentiel d’identité et la gestion des rôles au sein d’un SCM tiers.

Néanmoins, AWS CodeCommit offre des fonctionnalités relativement limitées par rapport à GitHub (ex : UI et expérience utilisateur) et dispose d’une communauté bien plus faible que GitHub ou GitLab.

Tout ceci fait d’AWS CodeCommit une solution convenable dans le cas d’une utilisation au sein d’un environnement entièrement AWS en raison de son intégration étroite à d’autres services AWS tel que AWS CodeBuild ou CodePipeline. En revanche, lorsque la chaîne CI/CD comprend plusieurs solutions externes à AWS, une autre solution telle que GitHub ou GitLab offrira plus de flexibilité.

La phase de build : AWS CodeBuild

Une fois le développement terminé, AWS CodeBuild prend le relais. Cet outil permet aussi bien de compiler/construire une application qu’exécuter des tests via des runners CI. Le service exécute  les instructions qui lui sont passées en entrée dans un fichier buildspec.yml. C’est un outil polyvalent et similaire à un outil CI classique tel que GitLab CI ou GitHub Actions.

AWS CodeBuild permet également d’exécuter les tests de sécurité (SAST, SCA…) en installant et utilisant des applications sur ses runners. Prenons l’exemple de SonarQube, un outil de qualité de code avec un module SAST permettant de scanner du code source pour en ressortir les vulnérabilités. L’exécution fonctionne de la façon suivante :

1. Lorsque le code source est modifié, une notification webhook (requête HTTP POST du SCM) est transmise à AWS (en pratique, cet évènement est géré par AWS EventBridge ou AWS CodePipeline) qui déclenche le test.
2. Le code source est dupliqué sur le runner CI qui effectue un scan de celui-ci et produit un rapport.
3. Ce rapport est ensuite envoyé à un serveur SonarQube (on-premise ou sur une EC2).
4. Après analyse SonarQube produit un rapport final indiquant le niveau de sécurité du code.
5. Ces résultats sont envoyés à CodeBuild qui interprète, selon les conditions présentes dans le fichier yml, si le test est réussi ou non.

Encore une fois, l’intérêt de CodeBuild réside essentiellement dans son intégration à l’environnement et permet une collaboration étroite avec les autres services AWS. Il sera par exemple plus aisé d’attribuer des rôles particuliers aux projets CodeBuild, d’utiliser AWS Secrets Manager (pour la gestion des secrets) ou de permettre le déploiement avec AWS CodeDeploy.

Le déploiement : AWS CodeDeploy

Le déploiement d’une application constitue la fin de son cycle de développement. Au sein d’AWS, le déploiement s’effectue via AWS CodeDeploy. Son rôle est de récupérer les et fichiers de configuration nécessaires dans les buckets S3 dédiés pour ensuite les déployer sur le serveur choisi (EC2…). Il diffère d’AWS Elastic Beanstalk qui permet de déployer une application uniquement grâce à son code (ne supporte généralement pas les langages compilés tel que le C/C++).

Le fonctionnement de CodeDeploy permet de déployer du code sur n’importe quel type de serveur, qu’il soit hébergé par AWS ou non. Son fonctionnement est simple : il suffit d’installer un agent (CodeDeploy agent) sur le serveur cible. C’est cet agent qui est chargé de télécharger les artéfacts, de les installer et de lancer l’application.

Il est nécessaire de définir en amont les instances concernées par le déploiement et leur appliquer un tag AWS arbitraire permettant de les identifier. L’ensemble de ces instances constitue alors un « groupe de déploiement ». Lorsque le déploiement est déclenché, CodeDeploy sélectionne les instances concernées et publie ses instructions. La communication est néanmoins initiée par l’instance cible, c’est bien l’agent CodeDeploy qui contacte (toutes les secondes par défaut) le service CodeDeploy en scrutant pour de nouvelles instructions (polling mode). Ce mode de communication évite toute ouverture de port amenuisant la posture sécurité de l’instance.

AWS CodeDeploy est un outil efficace qui permet le déploiement sur n’importe quel type d’infrastructure. Néanmoins, il nécessite l’installation d’un agent managé par AWS sur l’instance où est déployée le code, ce qui n’est pas toujours souhaitable en fonction du contexte client. On peut imaginer que le polling des instances EC2 peut impacter les performances d’une application critique ou être détecté comme malveillant par un EDR ou NDR (Network Detection & Response).

Sécurisation de la CI/CD AWS

Au vu du rôle essentiel de la chaîne CI/CD dans le développement d’applications, il est essentiel de sécuriser cette infrastructure (sécurisation de l’outillage, intégration, configuration de la chaine…). Ci-dessous nous récapitulons quelques axes d’études à ne pas négliger lors de la mise en place d’une chaine CI/CD AWS. Ces grands principes peuvent être maitrisés via la création de politiques AWS de façon à alerter ou à imposer leur application.

Gestion des flux

Par défaut, les flux vers les services managés AWS (CodeBuild, CodeDeploy…) transitent sur internet avant de revenir vers l’instance cliente de la ressource. Afin d’éviter de faire transiter l’ensemble des flux vers les services AWS par internet, nous recommandons de mettre en place des interfaces VPC endpoints. Ces points d’accès réseaux permettent aux instances au sein d’un VPC de contacter les services AWS comme s’ils étaient déployés au sein du VPC.

Gestion des secrets

Les secrets permettant d’accéder aux services ou à d’autres APIs ne peuvent être stockés en clair dans les SCM ou dans les fichiers de configuration de la chaine. On souhaite éviter toute fuite d’information confidentielle lors d’un accès – légitime ou non – à ces répertoires.

Nous recommandons la mise en place d’un coffre-fort AWS Secret Manager chargé de stocker les secrets (ex : clés API SonarQube…) et de les distribuer aux services uniquement lorsque nécessaire. La récupération d’un secret se fait alors par un appel API à ce coffre-fort avec vérification des privilèges.

Supervision / monitoring

Tout comme n’importe quelle infrastructure, la chaine CI/CD nécessite d’être supervisée. Les solutions AWS natives pour la supervision de services sont AWS CloudWatch pour le recueil de logs, AWS EventBridge pour la création d’alertes et AWS SNS / SQS permettent l’envoie de notification à des groupes prédéfinis (mail, SMS, push notification…). La supervision de la chaine CI/CD permettrait d’alerter des mises en production dangereuses par exemple dans le cas où un projet souhaiterai contourner les politiques de sécurité mises en œuvre.

Identity and Access Management

La gestion des privilèges au sein d’AWS est traité selon le modèle Rôle Based Access Control (RBAC). Chaque action utilisateur requiert une permission spécifique. Par exemple, si un utilisateur souhaite accéder à un bucket S3, il doit d’abord obtenir la permission en lecture associée à la ressource correspondante au S3. On rappellera l’importance du principe du moindre privilège qui consiste à attribuer aux clients (utilisateurs & services) uniquement les droits dont ils ont besoin.

Les droits AWS permettent une configuration totale des accès de chaque client à chaque service / ressource. Cette flexibilité permet de définir précisément le périmètre d’autorisation de chaque acteur de l’environnement AWS. Néanmoins, la finesse des droits peut être fastidieuse à configurer dans une infrastructure CI/CD de grande ampleur.

AWS propose des rôles prédéterminés qui permettent d’appliquer rapidement un ensemble de permissions. Néanmoins, ces rôles prédéfinis ne permettent souvent pas de respecter le principe du moindre privilège. Il est donc important de créer des rôles permettant d’appliquer le principe du moindre privilège sans rentrer dans une micro-gestion des droits.

Nos convictions sur la CI/CD AWS

Les solutions CI/CD présentes dans le Cloud AWS sont intéressantes et nativement intégrées avec les autres services AWS. L’intégration native est particulièrement appréciable notamment dans le cas d’un pipeline entièrement hébergé par AWS. L’appartenance de l’ensemble des outils au même environnement Cloud permet une grande flexibilité, une supervision ainsi que la gestion des droits et identités de manière centralisée. Cependant, le nombre d’options de configurations engendre aussi de la complexité rendant sa maintenance potentiellement fastidieuse au sein d’infrastructures conséquentes.

AWS est un bon choix lorsqu’une entreprise a déjà migré la majeure partie de ses infrastructures chez AWS. Il est possible de tirer avantage des interconnexions entre services et notamment des puissantes solutions de gestion des accès et de monitoring avec peu de configuration additionnelle. En revanche, dans le cadre d’une utilisation simple et isolée, on ne privilégiera pas AWS CodeCommit ou AWS CodeBuild. Des solutions telles que GitHub / GitLab proposent des solutions plus complètes, une meilleure intégration avec d’autres éditeurs et une interface utilisateur plus accessible. Idem côté sécurité, AWS n’offre pas nativement les services de sécurité CI/CD pour attester du code déployé (SAST, DAST…). AWS ne propose pas d’intégration native mais des services tiers peuvent toujours être intégrées relativement simplement.

* « Exemple d’intégration BitBucket dans AWS CodeBuild » – Source 

Cet article CI/CD dans AWS : la solution à tous vos problèmes ? Ce qu’il faut savoir. est apparu en premier sur RiskInsight.

Comment assurer la sécurité de vos applications malgré l’externalisation de leur développement ?

L’intégration de la sécurité dans les projets est un processus important pour les entreprises pour définir et intégrer les aspects sécurité au plus tôt dans les produits. Cela évite d’augmenter le coût des remédiations si celles-ci n’ont pas été prévues et sont implémentées en fin de projet.

Dans le cadre de développements, l’Agile Security et le DevSecOps définissent les processus et outils à mettre en place pour intégrer la sécurité au plus tôt, comme présenté dans notre article précédent donnant des exemples.

Ces méthodes sont souvent définies sur les développements internes. Cependant, il est fréquent que les entreprises fassent appel à des prestataires externes pour développer une application ou une fonctionnalité particulière. Dans ce cas, il est important de s’assurer que ces prestataires suivent des pratiques de sécurité rigoureuses et qu’ils intègrent la sécurité dans leurs processus de développement aux mêmes standards que le demandeur. Ce qui amène la question suivante :

Développements externes : comment maintenir la confiance dans le code développé de manière externalisée ?

Dans la suite de cet article, nous entendons par code externe l’ensemble des éléments de code qui n’ont pas été développés en passant par une chaîne CI/CD internalisée. Par exemple, un développeur freelance utilisant la chaîne CI / CD interne ou un poste de travail entreprise n’est pas considéré comme un code externe.

Par ailleurs, nous considèrerons deux modèles de livraison d’applicatif en fonction du modèle de développement utilisé par le prestataire :

• la livraison du code source lui-même
• la livraison de l’exécutable, c’est-à-dire le code déjà précompilé

Il est important de noter que ces deux modèles de livraison d’applicatif ont des implications différentes en termes de cybersécurité et de DevSecOps.

Livraison de code

Dans le cas d’une livraison de code, les prestataires externes remettent le code qu’ils ont écrit, généralement sous forme de fichiers sources (par exemple des fichiers .java pour du code Java), à l’entreprise. Cette dernière peut alors auditer, compiler et déployer le code sur ses propres serveurs.

La livraison de code présente plusieurs avantages. Le premier avantage repose sur la flexibilité : en livrant le code source, l’entreprise peut facilement effectuer des modifications et personnalisations sur le code. Elle peut également intégrer le code dans son environnement de développement et de déploiement (CI/CD) existant contenant l’ensemble des outils de sécurité préconfigurés.

L’entreprise n’a alors pas à placer sa confiance dans la sécurité de la chaîne CI du prestataire sur laquelle elle n’a aucun contrôle. De plus, l’entreprise ayant accès au code source peut également l’auditer et ainsi vérifier qu’il est sécurisé. Ces audits tendent à être plus exhaustifs puisque l’auditeur a accès à beaucoup plus de détails sur le fonctionnement du code et peut effectuer à la fois une analyse statique et dynamique du code.

En revanche, la livraison de code présente certains inconvénients. L’entreprise doit disposer de compétences pour adapter les étapes de compilation et déploiement au contexte de production. Si elle ne dispose pas de ces compétences en interne, cela peut entraîner des coûts supplémentaires.x

Voici donc quelques bonnes pratiques afin de maximiser la confiance dans le code livré :

• Partager au plus tôt (contrat, réunion de lancement) les exigences attendues sur la sécurité dans le développement, les versions des logiciels, l’outillage utilisé en interne pour le déploiement, la confidentialité du code source, etc. Certains clients demandent à ce que les développeurs externes aient un certain niveau de certification ou de formation (par exemple, un palier de formation sur Secure Code Warrior, dans un certain langage de programmation).
• Définir et contractualiser les engagements sur les processus de remédiation des vulnérabilités identifiées après livraison du code et le suivi associé (outillage pour le suivi, SLA, etc.)
• Implémenter un contrôle de type hash ou signature sur le code envoyé pour en assurer l’intégrité et définir les modalités de transfert sécurisé du code source avec le prestataire
• Intégrer le code reçu dans la chaîne CI/CD existante y compris les fichiers d’Infrastructure as Code (IaC)
• Réaliser les tests fonctionnels sécurité définis initialement lors du threat modeling : Evil User Stories et Security Stories

Certaines organisations peuvent être confrontées à une situation où la notion de développeurs externes correspond à des développeurs d’autres entités au sein d’un même groupe. Ces entités peuvent avoir leur propres chaînes CI mais dépendre de la chaîne CD ou CI/CD de l’équipe centrale de production.

Dans ces cas, une interconnexion des différentes chaînes CI sur la chaîne CI/CD centrale peut être envisagée. Cette solution permet aux différentes équipes de développer avec les outils leur convenant au mieux.

Le niveau de sécurité assuré par la chaîne CI/CD projet est idéalement équivalent à celui de la production mais ce n’est pas nécessairement le cas. La chaîne CI/CD de production contrôle le code à déployer.

Cependant, le contrôle de la sécurité est souvent effectué trop tard dans le processus de développement. Pour garantir une sécurité efficace dans les développements, il est crucial de s’assurer que la sécurité est intégrée dès le début du cycle de développement (shift-left). Pour remédier à cela, il est recommandé d’offrir des outils de sécurité en libre-service pour les équipes projet afin qu’elles puissent identifier les vulnérabilités dès le début de leur développement en utilisant les outils cibles appropriés.

Dans le cas contraire, les outils de sécurité de la chaîne CI/CD de production permettront d’assurer la conformité aux règles du groupe sans ralentir la mise en production si des contrôles sécurités automatisés ont été mis en place au sein de la chaîne projet.

Cette solution permet aussi à la production de s’assurer de l’utilisation des images (systèmes, docker, etc.) ou des artefacts (bibliothèques) validés par l’entreprise.

Ces interconnexions entre les différentes pipelines peuvent par exemple cloner la branche voulant être déployée par l’équipe produit afin de les pousser en entrée de la chaine CD. Les équipes de production doivent cependant posséder les droits appropriés. Techniquement, le modèle de gestion des droits accordés (idéalement temporairement) doit répondre à la fois au besoin de faciliter l’exécution et au besoin de provision des droits (manuelle vs. automatique), tout en limitant l’accès à l’ensemble des branches ou des projets afin de respecter le principe du moindre privilège.

La majorité des bonnes pratiques citées précédemment s’appliquent aussi afin de réduire le temps de mise en production.

Bien que les méthodes décrites ci-dessus apparaissent comme les plus efficaces pour avoir un contrôle sur des applications développés par des tiers, les entreprises se retrouvent parfois à recevoir des exécutables sans accès au code source. Ceci peut par exemple être le cas pour des raisons de restrictions liées aux licences. Dans ce cas, certaines bonnes pratiques énoncées plus haut ne s’appliquent pas, il est nécessaire de repenser la manière d’intégrer les changements à la production pour ne pas négliger certains aspects sécurité.

Livraison d’exécutable

Dans le cas d’une livraison d’exécutable, les prestataires externes remettent un fichier exécutable (par exemple, un fichier .exe pour des serveurs Windows) qui peut être directement exécuté par l’entreprise sans compilation. Cette méthode de livraison est souvent utilisée pour les logiciels commerciaux qui nécessitent tout de même quelques ajustements de configuration.

Dans ce cadre, l’intégration dans la chaîne de déploiement est beaucoup plus limitée et seules quelques étapes classiques d’une CD peuvent être effectuées sans que les étapes de sécurité de la chaîne CI puissent être vérifiée :

• Réaliser un scan des artefacts
• Réaliser un scan DAST pour détecter les vulnérabilités les plus classiques
• Réaliser des tests d’intrusion

Les rapports des outils de sécurité de la chaîne du prestataire effectuant le développement peuvent aussi être demandés. Ceci doit être inscrit en amont dans le contrat de prestation, avec les exigences sécurité sur le niveau de sécurité du code.

Enfin, une signature du code pour s’assurer de son intégrité est nécessaire lors de l’échange et de l’exécutable. Privilégiez pour cela les signatures via certificats plutôt que les empreintes hash puisque celles-ci permettent de vérifier l’origine (non-répudiation) en plus de l’intégrité de l’exécutable.

Pour conclure, il est important pour les entreprises de s’assurer de la qualité et de la sécurité du code livré par les prestataires externes, surtout lorsque ces derniers développent du code sur des chaînes CI externes. Il existe plusieurs moyens de se convaincre de la sécurité du code livré :

• Des clauses contractuelles claires et précises peuvent aider à définir les attentes et les responsabilités de chacune des parties en ce qui concerne la qualité et la sécurité du code.
• Le partage des spécifications et des attentes en matière de sécurité avec les prestataires externes peut également aider à s’assurer que le code livré répond aux exigences de l’entreprise.
• L’intégration avec les outils de la chaîne de développement interne peut faciliter la vérification de la qualité et de la sécurité du code, ainsi que la mise en place de tests automatisés. Ces intégrations soulèvent des défis à la fois techniques et de processus qu’il faut anticiper pour faciliter le déploiement des développements externes.

En implémentant ces différentes approches, les entreprises peuvent renforcer leur confiance dans le code livré par les prestataires externes et s’assurer de la sécurité de leurs applications.

Cet article Gardez le contrôle de vos développements externes est apparu en premier sur RiskInsight.