Fondamentaux de la sécurité cloud, partie 3 : donnez les moyens d’agir à vos développeurs

Dans notre précédent article consacré aux 5 fondamentaux de la sécurité cloud, nous avons examiné l’importance de la prévention et d’une conception sécurisée. Cartographier les relations entre les ressources et appliquer des garde-fous de sécurité tout au long du développement permet de réduire considérablement la surface d’attaque. Mais qui veillera au respect de ces garde-fous lorsque votre équipe de sécurité sera occupée à d’autres tâches ? C’est là que les développeurs doivent pouvoir intervenir. Examinons donc un autre élément essentiel de la sécurité cloud : donner les moyens d’agir aux développeurs.

En 2013, Gene Kim, Kevin Behr et George Spafford ont écrit le livre de référence sur le DevOps : The Phoenix Project. Leur objectif était de promouvoir le DevOps, mais leur ouvrage s’est révélé plus visionnaire que les auteurs ne l’imaginaient, en particulier en matière de sécurité cloud.

Le DevOps visait à mieux intégrer les équipes d’exploitation informatique au cycle de vie du développement logiciel (SDLC) et à permettre aux équipes de créer et de déployer plus rapidement une meilleure infrastructure. Les équipes d’exploitation ont appris à comprendre les contraintes du développement, mais, plus important encore, les développeurs ont appris à planifier et à développer ensemble les applications et l’infrastructure dans une approche plus globale.

Vous avez probablement déjà entendu un nouveau terme : DevSecOps. Ce terme est apparu pour de nombreuses raisons, dont l’une se démarque particulièrement. Gene Kim explique :

Dans une organisation technologique type, le ratio entre les ingénieurs en développement, en exploitation et en sécurité informatique est de 100:10:1. Lorsque les équipes de sécurité sont aussi largement minoritaires, sans automatisation ni intégration de la sécurité de l’information au travail quotidien des équipes de développement et d’exploitation, elles ne peuvent effectuer que des contrôles de conformité, soit l’inverse de l’ingénierie de la sécurité.

En somme, ce ratio révèle la priorité numéro un de nombreuses entreprises : développer des logiciels, et non les sécuriser. La solution consiste à donner aux développeurs les moyens d’intégrer l’ingénierie de la sécurité à leurs processus de développement.

Dans cet article, nous présentons trois principes que les responsables du cloud peuvent appliquer pour donner les moyens d’agir à leurs développeurs et renforcer leur posture de sécurité à moindre coût.

1. Utilisez l’infrastructure as code dès que possible

Les logiciels n’ont pas seulement conquis le monde : ils ont aussi conquis le cloud.

L’infrastructure cloud peut désormais être entièrement logicielle ; en réalité, du point de vue des clients du cloud, elle est entièrement logicielle. Grâce aux outils d’infrastructure as code, tels que Terraform et AWS CloudFormation, les développeurs peuvent créer et gérer les environnements cloud par programmation.

Par le passé, la sécurité cloud était une activité cloisonnée, comme la plupart des fonctions de sécurité. Les équipes de sécurité devaient utiliser des outils de gestion de la posture de sécurité cloud (CSPM) pour analyser les environnements en cours d’exécution, provisionnés par les équipes d’ingénierie. Elles repéraient ensuite les erreurs de configuration, les classaient par gravité et confiaient les tâches de correction aux équipes DevOps.

Mais un problème majeur est apparu : les erreurs de configuration, comme d’autres problèmes de sécurité, ne peuvent être détectés qu’après coup. Une étude d’IBM publiée en 2017 explique pourquoi c’est problématique : « Corriger un bogue logiciel détecté pendant la phase de test peut coûter jusqu’à 15 fois plus cher que de corriger le même bogue détecté pendant la phase de conception. »

L’infrastructure as code change la donne. En permettant aux équipes de développement de définir par le code la configuration de leurs environnements cloud, les entreprises peuvent déplacer la sécurité vers la gauche, c’est-à-dire intervenir plus tôt dans le cycle de vie du développement logiciel de l’infrastructure cloud.

Les contrôles de sécurité peuvent alors avoir lieu avant le déploiement. Résultat : moins d’erreurs de configuration à l’exécution, moins de bogues déployés et une posture de sécurité bien plus solide, beaucoup plus tôt.

2. Donnez la priorité aux intégrations avec les outils des développeurs

La sécurité a parfois mauvaise réputation auprès des développeurs, car les entreprises la réduisent souvent à une série d’étapes ajoutées à la fin du cycle de développement logiciel. Les développeurs se retrouvent alors à effectuer de nombreuses tâches manuelles. Non seulement les bogues et autres défauts sont plus difficiles à détecter aux étapes ultérieures, mais ils sont aussi plus difficiles à identifier et à corriger, ce qui exige souvent des retouches longues et coûteuses.

L’essentiel est de choisir des outils offrant des intégrations complètes et pertinentes, puis de s’en servir pour ajouter des fonctionnalités de sécurité au processus de développement. Il ne s’agit pas de changer la façon dont les développeurs travaillent, mais d’intégrer la sécurité à leur façon de travailler déjà.

Concentrez-vous sur l’intégration des contrôles de sécurité aux outils des développeurs, aux dépôts de code source et aux chaînes CI/CD. De plus, lorsque vous choisissez des outils de sécurité, tenez compte à la fois de l’éventail des intégrations disponibles et de leur qualité. Ces deux aspects sont indispensables pour faire de la sécurité une composante à part entière du processus de développement. Les outils de sécurité destinés aux développeurs ne sont efficaces que s’ils les utilisent.

3. Fournissez des conseils utiles aux développeurs

Le DevSecOps n’est pas simplement un avantage supplémentaire. Lorsqu’ils disposent d’une infrastructure as code et d’intégrations étroites avec les outils de sécurité, les développeurs peuvent progresser constamment dans l’ingénierie de la sécurité. En leur donnant les moyens d’agir et les outils nécessaires, vous leur permettez de développer leurs compétences à grande échelle.

Avec l’infrastructure as code, les développeurs peuvent apprendre à créer des environnements sécurisés dès leur conception. Et lorsque les entreprises intègrent les approches DevSecOps à leurs programmes de sécurité cloud, les ingénieurs reçoivent automatiquement des retours et des conseils en matière de sécurité pendant qu’ils écrivent leur code.

Les développeurs peuvent ainsi améliorer leurs compétences en ingénierie de la sécurité au fil du temps et introduire moins de problèmes pendant le développement. Même lorsque des problèmes apparaissent à l’exécution, ils peuvent mieux déterminer où intervenir dans l’infrastructure pour les corriger.

L’essentiel est que les équipes de sécurité jouent le rôle de fournisseurs d’outils internes pour les développeurs. Dans l’idéal, elles travaillent en étroite collaboration avec les équipes de développement et d’ingénierie cloud pour comprendre leurs cas d’usage et leurs processus. Elles peuvent ensuite créer, acheter et intégrer des outils qui fournissent des retours utiles et rapides, ainsi que des conseils précis pour les corrections.

Plus tôt, plus vite, mieux, plus fort

Plus tôt vous corrigez les erreurs de configuration, les bogues et les vulnérabilités, mieux c’est.

FormHero, qui ne comptait qu’une personne à temps plein dédiée à la sécurité pour une équipe de développement de 10 personnes, a constaté la véracité de ce principe en cherchant des outils pour réduire le délai de correction.

Ryan Kimber, fondateur et PDG, explique : « Si vous ne traitez pas les problèmes pendant le processus de développement et que vous les détectez et les corrigez en phase d’assurance qualité, il vous faudra 10 fois plus de temps pour les résoudre. »

En combinant l’infrastructure as code, des outils de sécurité étroitement intégrés et des conseils automatiques aux développeurs, les responsables du cloud peuvent obtenir cette amélioration d’un facteur 10 et la déployer dans l’ensemble de leurs environnements cloud, pour une sécurité renforcée et moins coûteuse.