Introduction au DevSecOps

1. Bob le développeur

Nous pouvons résumer les missions de Bob en quatre axes principaux :

Bien entendu, cette liste n’est pas exhaustive, et ne présente que les missions principales de Bob.

Seulement Bob doit souvent attendre des jours, des semaines, et parfois des mois, avant que son nouveau code ne soit déployé en production et mis à disposition des clients. Ce délai est induit par les contraintes de mise en production et les démarches administratives nécessaires, l’entreprise perd alors en compétitivité face à des concurrents qui n’auraient pas ce type de problématiques (notamment les start-up).

1. Le « c » de la culture

La culture correspond au premier pilier et se concentre sur les exécutants techniques, les décisionnaires, les managers, ou encore la sécurité. En somme, toutes les personnes qui vont avoir une interaction avec le(s) produit(s) et service(s).

L’accent est mis sur les changements, la manière dont les mutations de structure et de culture au sein des équipes sont amenées, et surtout sur la capacité à évoluer vers une culture de l’expérimentation.

Cela signifie qu’il n’y a pas de problème à échouer, à commettre des erreurs, ou à ne pas réussir à atteindre l’objectif fixé. L’important est alors d’essayer, de gagner en connaissances et en maturité, permettant ainsi de ne pas réitérer les erreurs déjà commises. 

2. L’automatisation : une méthode indispensable

Le second pilier autour duquel se concentre le DevOps correspond à l’automatisation. Même si ce pilier revêt une très grande importance, il ne résume pas à lui tout seul le DevOps.

Il est question, cette fois, de déploiement continu (CD) et d’intégration...

1. Le business d’aujourd’hui

De nombreux intervenants nous font de plus en plus savoir que l’IT est devenu le vrai business des entreprises aujourd’hui. En effet, existe-t-il une entreprise de taille importante dont l’informatique ne consiste pas en un poste de coût majeur, et en un département qui produit également de la valeur ?

Les demandes se font toujours de plus en plus nombreuses pour avoir des applications et des services à consommer rapidement (un peu comme les applications sur smartphone), et cela malgré des risques en cybersécurité qui apparaissent chaque jour. Il est rare de rester plus d’un mois sans entendre qu’un très grand groupe a été la victime d’une attaque informatique.

Comment continuer à produire rapidement des services et produits de forte qualité, tout en maintenant des conditions de sécurité élevées pour l’infrastructure et le code ? Le DevSecOps apparaît comme une réponse possible à cette équation.

2. Le fonctionnement dans « l’ancien monde » en silos

Pour délivrer des logiciels et effectuer du développement, les entreprises ont beaucoup fonctionné en silos (et nombre d’entre elles le font toujours aujourd’hui). C’est-à-dire qu’elles étaient (et sont parfois toujours) composées en équipes séparées, chargées de s’occuper d’une partie du système d’information : une équipe de développeurs, une équipe pour les systèmes Linux, une équipe pour la virtualisation, une équipe pour le réseau, une équipe pour les datacenters, une équipe pour la sécurité, etc.

Malheureusement...

1. Segmentation des environnements et des applications

Dans des environnements Cloud, nous pourrions être tentés, par facilité, de mettre tous nos environnements et toutes nos applications dans un seul et même VPC (Virtual Private Cloud).

Cependant, pour répondre aux bonnes pratiques de sécurité, il convient de mettre chaque environnement d’une application dans des VPC différents : un VPC de développement qui permet de se connecter aux autres VPC qui contiennent les environnements de préproduction et de production.

Il faut ensuite effectuer la même démarche pour toutes les applications, afin de respecter la segmentation des environnements.

2. Gestion des accès et des identités (IAM) sur le Cloud

La gestion des accès et des identités par les services IAM (Identity and Access Management) des fournisseurs de service Cloud est un enjeu extrêmement important.

En effet, elle permet aux équipes de développement d’effectuer des requêtes pour obtenir des accès spécifiques, avec la possibilité d’obtenir des comptes applicatifs et des rôles par l’IAM.

Un des gros avantages de ces attributions contrôlées (qui peuvent se faire via une interface web, avec création automatique) consiste à pouvoir ajouter ces comptes au fur et à mesure à un Cloud Profiler. Des scans sont ensuite effectués sur les comptes applicatifs pour vérifier la configuration et l’utilisation...

1. Une nouvelle façon de travailler

Le DevSecOps modifie la façon de travailler des équipes, mais aussi de la partie business. En effet, par sa culture qui lui est propre, il implémente de nouveaux processus et de nouvelles technologies pour mener à bien les différentes tâches et problématiques auxquelles il a pour vocation de répondre.

Cette culture tourne autour de quelques principes importants, qui sont intimement liés au DevOps. En effet, la coopération entre les équipes, mais également entre le business et la technique, est indispensable à l’adoption de cette nouvelle organisation. Les éléments technologiques peuvent apporter des outils intéressants, permettant notamment l’automatisation de certaines tâches de sécurité, comme la capacité à effectue du « Shift Left ». Enfin, tous ces éléments peuvent être mesurés afin de démontrer l’efficacité de ces nouvelles pratiques.

2. La règle du IN : Input, Involve et Invest (contribution, implication et investissement)

Plus les stakeholders (parties prenantes) sont impliqués tôt dans les processus, mieux les projets se déroulent. Cela permet d’identifier et d’anticiper les prérequis, les défis ou les risques inhérents.

En effet, lorsque ces contributions sont obtenues dès les premières étapes de la réalisation d’un projet, il devient possible d’obtenir des shorten feedback loops, c’est-à-dire des avis et des retours, très rapidement. Les équipes DevOps peuvent ainsi facilement s’adapter et ajuster leurs pratiques. En somme, il est possible d’éviter que l’équipe...