Bonnes pratiques de sécurité DevOps

La sécurité DevOps consiste à appliquer des politiques et des technologies de sécurité de l’information à l’ensemble du cycle de vie et de la chaîne de valeur DevOps. Comme le DevOps couvre généralement toutes les étapes du cycle de vie du développement logiciel (SDLC), une sécurité efficace est d’autant plus essentielle.

Pour la plupart des organisations, la sécurité de l’information n’est pas une nouveauté. L’une des principales préoccupations des équipes informatiques est la suivante : comment se protéger contre les compromissions ? Cependant, l’infrastructure DevOps marque une rupture importante avec les modèles informatiques plus traditionnels. Comment appliquer efficacement la sécurité de l’information au DevOps ?

Comparaison entre DevOps et DevSecOps

Découvrez ici comment passer du DevOps au DevSecOps.

4 principaux défis de la sécurité DevOps

Le passage des modèles informatiques traditionnels et du développement logiciel à l’approche moderne et agile du DevOps a fait émerger de nouveaux défis de sécurité. Il exige non seulement de nouveaux outils de sécurité, mais aussi une évolution de la culture, des équipes et des processus. Bien que le DevOps soit souvent considéré comme la fusion du développement et des opérations, la sécurité reste à part.

1. Un rythme de changement rapide

L’un des effets les plus marquants sur la sécurité est le rythme rapide des changements dans le DevOps. Dans les environnements traditionnels, les nouvelles infrastructures étaient généralement déployées sur du matériel physique dédié, avec un long délai entre la demande de provisionnement et la mise à disposition opérationnelle. Le développement logiciel suivait généralement un modèle en cascade, avec des versions majeures publiées tous les quelques mois ou trimestres. À l’inverse, les environnements agiles modernes peuvent connaître plusieurs déploiements en production en une seule journée.

De plus, avec une infrastructure cloud, il est possible d’augmenter la capacité en quelques minutes, au lieu de plusieurs heures ou jours. Tout cela accélère considérablement le rythme des changements dans un environnement donné. Les technologies et processus traditionnels n’étaient pas conçus pour s’adapter à une telle ampleur de changements.

2. Sécurité du cloud

Un autre défi découle directement de la généralisation des architectures privilégiant le cloud. Par rapport à un déploiement traditionnel sur site, le cloud présente une surface d’attaque bien plus vaste, avec des limites réseau floues et mal définies. Presque toutes les ressources provisionnées peuvent être configurées pour être accessibles depuis l’Internet public en quelques clics ou lignes de code. La sécurité réseau traditionnelle partait du principe que le réseau serait bien défini, avec quelques points d’entrée et de sortie clairement établis. Découvrez les défis de la sécurité du cloud.

3. Conteneurisation des charges de travail

Cela introduit également de nouvelles variables dans l’environnement de sécurité. Les conteneurs offrent des fonctionnalités intéressantes pour les workflows modernes de développement et de déploiement, mais la complexité supplémentaire du moteur sous-jacent, de l’orchestration et du réseau crée davantage de vecteurs d’attaque potentiels à surveiller et à sécuriser.

4. Collaboration

Les outils, technologies et processus de sécurité traditionnels n’ont tout simplement pas été conçus pour prendre en charge nombre de ces cas d’usage. Des équipes sécurité et ingénierie cloisonnées ne peuvent pas suivre le rythme rapide et itératif d’une culture axée sur le DevOps. Lorsqu’elles travaillent séparément, les équipes sécurité et ingénierie redoublent souvent d’efforts et dupliquent des flux d’information qui pourraient facilement être regroupés.

Il est également essentiel de mettre en place un pipeline unique pour que les équipes soient coordonnées et obtiennent les mêmes informations à partir de la même source. Pourtant, il n’est pas rare de voir des organisations exécuter deux agents Splunk sur une même machine — un pour l’équipe sécurité et l’autre pour l’équipe application — ou une équipe antifraude recevoir des flux à la fois de la sécurité et de l’infrastructure, chacune disposant de pipelines d’événements entièrement distincts et parallèles.

Qu’en est-il du DevSecOps ?

Le DevSecOps associe le modèle DevOps — livraison logicielle à rétroaction rapide et culture organisationnelle — aux pratiques de sécurité de l’information. Contrairement à la sécurité DevOps, qui ajoute la sécurité de l’information a posteriori aux différentes étapes du cycle DevOps, le DevSecOps vise à intégrer les objectifs de sécurité et d’ingénierie dans une démarche de « shift left ».

La sécurité se déplace vers la gauche

Figure 2 : les objectifs de sécurité sont déplacés vers la gauche

La sécurité DevOps repose généralement sur un état d’esprit ou une posture globale. Dans le DevOps, les outils ne font pas tout. Les pratiques DevSecOpsne consistent pas à cocher des cases sur une liste de tâches. Sans un état d’esprit axé sur la sécurité au sein de l’équipe, il est presque impossible de parvenir à sécuriser une plateforme.

Dans le DevSecOps, les objectifs de sécurité sont appliqués aux différentes étapes du cycle de vie grâce aux outils et processus mis à disposition. Les équipes sécurité peuvent toujours fonctionner en silos distincts des équipes d’ingénierie et d’exploitation, même si la culture est plus collaborative. Depuis ses débuts, le DevOps repose sur le principe d’une responsabilité partagée entre le développement et les opérations. Pourtant, la sécurité implique encore généralement l’intervention d’une équipe ou d’une organisation de sécurité externe et cloisonnée.

Le DevSecOps vise à intégrer les objectifs de sécurité à l’ensemble du cycle de vie DevOps, en particulier aux premières étapes de conception et de développement. Les responsabilités en matière de sécurité sont « déplacées vers la gauche », afin que les développeurs prennent en charge la correction des problèmes avant que ceux-ci n’atteignent des environnements soumis à des SLA plus stricts.

Pour les entreprises aux équipes réduites, le shift left peut alléger une partie de la charge de correction qui incombe aux équipes sécurité. Chez Reddit, une API automatisée a permis à une petite équipe sécurité de gérer un grand nombre de dépôts et a également donné aux développeurs les moyens de prendre en charge les corrections de sécurité :

« Après avoir nettoyé nos dépôts, nous avons inversé la logique : les nouvelles pull requests échouent désormais si elles contiennent des vulnérabilités de sécurité. Reddit est ainsi passé d’une approche réactive, pilotée par l’équipe sécurité, à une approche centrée sur les développeurs et pilotée par eux. La seule façon de gérer tout ce travail était d’utiliser l’API Snyk. »

Spencer Koch, professionnel de la sécurité chez Reddit

La rétroaction rapide offerte par le DevOps et les outils DevSecOps, en particulier le CI/CD, permet aux développeurs de réagir immédiatement aux commentaires automatisés sur la sécurité. Les cycles de revue manuelle sont ainsi éliminés et la posture de sécurité s’améliore tout au long du SDLC.

Passer du DevOps au DevSecOps

Comment une organisation peut-elle passer d’une culture DevOps à une culture DevSecOps ? La réponse peut sembler contre-intuitive : elle doit cesser de s’inquiéter de la sécurité. Elle doit plutôt donner à chacun les moyens d’en assumer la responsabilité. Quelques stratégies clés peuvent aider à amorcer cette démarche.

Comme indiqué précédemment, le shift left est un axe essentiel de toute démarche DevSecOps sérieuse. Intégrer les objectifs de sécurité plus tôt dans le SDLC améliore les résultats globaux en matière de sécurité. Concrètement, au lieu que les équipes de développement transmettent leurs livrables de déploiement à l’équipe sécurité pour une revue et un rapport tardifs dans le SDLC, la sécurité s’intègre naturellement aux premières étapes du développement, notamment à la collecte des exigences et à la conception.

Il ne s’agit pas d’imposer des exigences contraignantes ou des processus supplémentaires aux workflows existants. L’objectif est de réduire au minimum les frictions à chaque étape. Le DevSecOps permet à une organisation d’adopter un cycle de vie de développement logiciel sécurisé (SSDLC).

Figure 3 : DevSecOps + SDLC = SSDLC

En poussant plus loin l’approche shift left, donner aux développeurs et aux ingénieurs infrastructure la responsabilité des objectifs de sécurité de bout en bout renforce la posture de sécurité d’une application. Pour y parvenir, il faut mettre l’accent sur l’automatisation et des cycles de rétroaction rapides. Lorsqu’un développeur pousse du code, il doit recevoir un retour immédiat sur les éventuels problèmes de sécurité liés aux nouvelles fonctionnalités ou aux corrections. Si ce retour est exploitable, le développeur apporte les modifications nécessaires et l’organisation améliore immédiatement sa sécurité, sans intervention d’un ingénieur sécurité.

Chez Red Ventures, la priorité accordée à une expérience « sans friction » pour les développeurs a favorisé l’adoption rapide des initiatives visant à améliorer des aspects essentiels de la sécurité, en particulier des charges de travail conteneurisées. Les workflows existants peuvent renforcer la sécurité avec un minimum de perturbations.

Intégrer davantage cette automatisation au CI/CD permet d’analyser le code applicatif ainsi que les changements d’infrastructure as code (IaC) afin de détecter d’éventuels problèmes et de fournir rapidement des retours lorsque nécessaire.

Le DevSecOps permet aux organisations d’améliorer leurs résultats en matière de sécurité

Figure 4 : la proposition de valeur du DevSecOps

En cessant de s’inquiéter de la sécurité DevOps et en adoptant le DevSecOps, les organisations font évoluer le développement et la livraison de leurs logiciels vers une nouvelle étape de la culture DevOps. Dans une culture DevSecOps, la sécurité rejoint le modèle collaboratif partagé par les opérations et le développement.

Déplacer la sécurité vers la gauche signifie intégrer les objectifs de sécurité dès le départ. Les développeurs, les ingénieurs infrastructure et les équipes d’exploitation ont tous les moyens d’assumer la responsabilité des problèmes de sécurité. Les cycles de rétroaction rapides propres à la culture et aux outils DevSecOps permettent à l’automatisation, notamment aux pipelines CI/CD, de fournir en quelques secondes ou minutes une vue détaillée des problèmes de sécurité potentiels, plutôt qu’en plusieurs heures ou jours.

Choisir des outils modernes pour soutenir une initiative DevSecOps est essentiel. Les outils et processus de sécurité traditionnels n’ont pas été conçus pour suivre le rythme rapide des changements propres aux architectures cloud natives.

Grâce au DevSecOps, une organisation peut livrer des logiciels plus rapidement et en toute sécurité, et ainsi créer davantage de valeur pour ses clients comme pour elle-même.