Le DevSecOps, qu'est-ce que c'est ?

L'expression DevSecOps désigne à la fois le développement, la sécurité et l'exploitation. Il s'agit d'une approche de la culture, de l'automatisation et de la conception des plateformes qui intègre la sécurité en tant que responsabilité partagée tout au long du cycle de vie informatique.

Le modèle DevOps ne s'adresse pas uniquement aux équipes de développement et d'exploitation. Si vous souhaitez tirer pleinement parti de l'agilité et de la réactivité d'une approche DevOps, vous devez également intégrer la sécurité informatique au cycle de vie complet de vos applications.

Pourquoi ? Par le passé, la sécurité était reléguée à la toute fin du développement, sous la responsabilité d'une seule équipe. Cette méthode ne posait pas forcément de problèmes quand les cycles de développement duraient des mois, voire des années, mais cette époque est révolue. Si une approche DevOps efficace garantit des cycles de développement rapides et fréquents (parfois quelques semaines ou jours), des pratiques de sécurité dépassées peuvent réduire à néant les bénéfices des projets DevOps les plus efficaces.

À présent, dans le cadre de travail collaboratif du modèle DevOps, la sécurité est une responsabilité partagée, intégrée du début à la fin. Cette notion est si importante qu'elle a donné naissance à l'expression « DevSecOps » qui souligne la nécessité d'intégrer la sécurité aux projets DevOps.

L'approche DevSecOps implique de réfléchir à la sécurité des applications et de l'infrastructure dès le départ, et d'automatiser certaines passerelles de sécurité afin d'éviter tout ralentissement des workflows DevOps. Pour atteindre ces objectifs, il faut commencer par sélectionner les outils capables d'assurer l'intégration continue de la sécurité, par exemple avec un environnement de développement intégré commun qui offre des fonctions de sécurité. Néanmoins, de nouveaux outils ne suffisent pas à améliorer l'efficacité de la sécurité DevOps. Il faut également intégrer plus en amont le travail des équipes de sécurité.

« DevOps » ou « DevSecOps », quel que soit le nom donné à cette approche, il a toujours été préférable de faire de la sécurité une partie intégrante du cycle de vie des applications. Le DevSecOps implique une intégration totale de la sécurité. Il ne suffit pas de l'ajouter après coup aux applications et données. En effet, si elle est reléguée à la fin du processus de développement, les cycles de développement risquent de s'allonger, alors que c'est justement ce que les entreprises qui appliquent le modèle DevOps essayaient d'éviter.

Le DevSecOps met notamment l'accent sur la nécessité d'impliquer les équipes chargées de la sécurité et les partenaires dès le début des projets DevOps, afin d'y intégrer la sécurité des informations et d'en planifier l'automatisation. Cette approche souligne également la nécessité d'encourager le codage axé sur la sécurité. Pour ce faire, les équipes de sécurité doivent partager la visibilité dont elles bénéficient, ainsi que leurs observations et leurs informations sur les menaces identifiées telles que les menaces internes ou la présence potentielle de logiciels malveillants. L'approche DevSecOps se concentre également sur l'identification des risques liés à la chaîne d'approvisionnement des logiciels et renforce la sécurité des composants et des dépendances logiciels Open Source très tôt dans le cycle de vie de développement logiciel. Pour assurer une adoption efficace du modèle DevSecOps, il est aussi possible de former les équipes de développement à la sécurité, car celle-ci n'a jamais fait partie des préoccupations principales dans le développement traditionnel d'applications.

À quoi la sécurité intégrée ressemble-t-elle concrètement ? Pour commencer, une stratégie DevSecOps efficace consiste à déterminer la tolérance en matière de risque et de réaliser une analyse bénéfice-risque. Quel est le niveau de contrôle de sécurité nécessaire dans une application donnée ? Quelle est l'importance du délai de mise sur le marché pour différentes applications ? L'automatisation des tâches répétitives est essentielle pour le DevSecOps, car les contrôles de sécurité manuels dans le pipeline peuvent devenir chronophages.

Voici les objectifs à atteindre : conserver des cycles de développement courts et fréquents, intégrer des mesures de sécurité aux processus d'exploitation avec un minimum d'interruptions, rester en phase avec les technologies novatrices telles que les conteneurs et les microservices, tout en encourageant une collaboration plus étroite entre des équipes habituellement isolées. Cela représente un défi de taille pour les entreprises. Toutes ces initiatives débutent au niveau humain, avec les tenants et aboutissants de la collaboration au sein de votre entreprise. Pour faciliter l'évolution des comportements, le modèle DevSecOps introduit l'automatisation.

Mais que faut-il automatiser ? Et comment procéder ? Différents guides tentent de répondre à cette question. Il est important pour les entreprises de prendre du recul et d'envisager l'environnement de développement et d'exploitation dans son intégralité : les référentiels de contrôle des sources, les registres de conteneurs, le pipeline d'intégration et de déploiement continus (CI/CD), la gestion des API, l'automatisation de l'orchestration et des versions, ainsi que la gestion et la surveillance de l'exploitation.

Les nouvelles technologies d'automatisation ont aidé les entreprises à adopter des pratiques de développement plus agiles, et ont par ailleurs joué un rôle dans les progrès réalisés en matière de mesures de sécurité. Cela dit, l'automatisation n'est pas le seul domaine du paysage informatique qui ait changé au cours de ces dernières années. En effet, les technologies cloud-native, telles que les conteneurs et les microservices, font désormais partie intégrante de la plupart des projets DevOps, et les stratégies de sécurité DevOps doivent s'y adapter.

Les infrastructures plus étendues et plus dynamiques, qui ont vu le jour grâce aux conteneurs, ont totalement transformé les méthodes de travail de nombreuses entreprises. Pour cette raison, les pratiques de sécurité DevOps doivent s'adapter au nouveau paysage et se conformer aux instructions de sécurité spécifiques aux conteneurs.

Les technologies cloud-native ne sont pas compatibles avec des politiques et des listes de contrôle de sécurité statiques. Il est nécessaire que la sécurité soit continue et intégrée à chaque étape du cycle de vie de l'application et de l'infrastructure.

Le DevSecOps incorpore la sécurité du début à la fin du processus de développement d'applications. Cette intégration au pipeline implique un changement d'état d'esprit dans l'entreprise autant que de nouveaux outils. Les équipes DevOps doivent automatiser la sécurité pour protéger l'environnement global et les données, ainsi que le processus d'intégration et de distribution continue. Pour ce faire, elles devront probablement aussi sécuriser les microservices dans des conteneurs.

Red Hat® Advanced Cluster Security utilise les principes cloud-native, ainsi que des artéfacts de l'architecture de microservices, la définition déclarative et l'infrastructure immuable pour automatiser les meilleures pratiques DevSecOps. La plateforme fonctionne avec tous les environnements Kubernetes et s'intègre au DevOps et aux outils de sécurité pour permettre aux équipes d'exploiter et de mieux sécuriser leur chaîne d'approvisionnement, leur infrastructure et leurs charges de travail.

Sécurité de l'environnement et des données

• Standardiser et automatiser l'environnement : chaque service devrait disposer d'un minimum de privilèges, afin de limiter les connexions et accès non autorisés.
• Centraliser les identités d'utilisateurs et les fonctionnalités de contrôle d'accès : ces mécanismes stricts de contrôle d'accès et d'authentification centralisée sont indispensables à la sécurisation des microservices, puisque l'authentification est déclenchée en plusieurs points.
• Isoler les conteneurs qui exécutent des microservices les uns des autres et du réseau : ces mesures s'appliquent aux données en transit et au repos, étant donné que ces deux types de données sont des cibles très prisées des pirates.
• Chiffrer les données entre les applications et les services : une plateforme d'orchestration de conteneurs avec fonctions de sécurité intégrées permet de minimiser le risque d'accès non autorisé.
• Introduire des passerelles d'API sécurisées : les API sécurisées améliorent la visibilité sur les autorisations et les routages. En réduisant le nombre d'API exposées, les entreprises peuvent réduire leurs surfaces d'attaque.

Sécurité des processus CI/CD

• Intégrer des analyseurs de sécurité pour les conteneurs : cette démarche devrait faire partie du processus d'ajout de conteneurs au registre.
• Automatiser les tests de sécurité dans le processus CI : cette démarche implique l'exécution d'outils d'analyse statique de la sécurité dans le cadre du processus de création des versions, ainsi que l'analyse de toute image de conteneur préconçu, afin d'identifier les failles de sécurité connues avant leur ajout au pipeline de versions.
• Ajouter des tests automatisés de la sécurité au processus de test d'acceptation : il faut automatiser les tests de validation d'entrée, ainsi que les fonctions d'authentification et d'autorisation de vérification.
• Automatiser les mises à jour de sécurité, comme les correctifs pour les failles connues : à réaliser dans le pipeline DevOps. Cette approche devrait permettre aux administrateurs de ne plus avoir à se connecter à des systèmes de production, tout en créant un journal des modifications documenté et traçable.
• Automatiser les capacités de gestion de configuration des systèmes et des services : cette approche permet d'assurer la conformité vis-à-vis des politiques de sécurité et élimine par ailleurs les erreurs manuelles. Les audits et corrections devraient également être automatisés.

En savoir plus sur la sécurité CI/CD