Quel est le quotidien de nos consultantes et consultants en projet ? Quels sont les challenges techniques à relever et quelles solutions sont apportées ? Derrière une mise en production réussie, un déploiement ou un Proof of Concept, il y a des consultantes et des consultants, une équipe, des technologies et beaucoup d’expertise et d’intelligence collective ! Cette série d’articles vise à vous dévoiler l’envers du décor, à travers leur témoignage.

Christine s’est passionnée très tôt pour les ordinateurs, et après une formation en management des SI, elle a commencé à travailler dans la sécurité, à Montréal puis en France. Elle a eu l’occasion de découvrir les deux aspects du métier, en interne en tant que RSSI, et en externe comme consultante sécurité. Elle a rejoint D2SI avec l’objectif d’améliorer les bonnes pratiques sécurité et de structurer une core team d’experts sécurité.

Quel est le contexte du projet sur lequel tu interviens actuellement ?

Le client lance sa première initiative structurée de passage au Cloud, dans le cadre d’une stratégie de transformation de la DSI, pour répondre aux besoins d’agilité des métiers. Dans ce contexte, D2SI fournit un accompagnement à trois niveaux : technique, fonctionnel et culturel. En effet, la mise en place d’une stratégie cloud implique que les entités IT passent par une phase d’acculturation et modifient à la fois leurs outils de production, leurs processus métier et leur modèle organisationnel.

Quelle est la particularité de cet accompagnement ?

J’interviens au sein d’une équipe pluridisciplinaire qui couvre tous les angles d’approche : acculturation/communication/formation, technique Cloud, CI/CD, Ops et Sécurité (fonctionnelle, organisationnelle et technique). C’est le premier projet auquel je participe qui répond au besoin de couvrir à 360° la transformation digitale d’une fonction IT.

Quel est ton rôle dans cette équipe ?

Je travaille sur le volet gouvernance de la sécurité. Mon rôle est d’identifier les exigences de sécurité du client, et de les traduire en mesures techniques, avec le support d’un autre consultant de D2SI chargé de la sécurité opérationnelle. Ce dernier s’assure ensuite que ces mesures sont mises en oeuvre au sein de la plateforme et dans les chaînes CI/CD. En complément des exigences du RSSI, il faut également être force de proposition sur de nouveaux aspects, comme par exemple les dispositifs de contrôle spécifiques aux technologies cloud.

Pour couvrir l’ensemble du spectre, je dois aussi identifier et solliciter tous les représentants des fonctions connexes à la sécurité IT, comme le DPO (Data Privacy Officer), le responsable de la continuité d’activité, de la gestion de l’exploitation, etc. Je collecte auprès d’eux les exigences complémentaires qui viennent enrichir le cadre de référence de la sécurité qui sera à mettre en oeuvre tout au long du projet.

En quoi la sécurité sur le Cloud demande un accompagnement particulier ?

Il y a un fort travail d’acculturation à faire quand on passe d’un environnement “on premise” à  un environnement Cloud. Les thématiques à couvrir en termes de sécurité restent les mêmes. Toutefois, de nouveaux risques viennent s’ajouter à ceux déjà connus. Et surtout, on n’opère pas la sécurité sur le Cloud de la même manière que dans un data center on premise. On passe en effet d’un monde où on travaille le plus souvent sur des cycles en V, à celui du Cloud où le DevOps et l’agilité sont la norme. Il faut donc faire évoluer les mentalités : les recommandations et exigences habituelles de la sécurité ne peuvent être déployées de la même façon. Les délais de mise en oeuvre, par exemple, ne sont plus les mêmes, ni les modèles d’accès aux ressources IT (on passe souvent d’un système d’accès centralisé à des processus en mode “self service”). On ne peut donc pas fonctionner selon les mêmes schémas. En conséquence, une partie de notre travail consiste à sensibiliser les différentes populations concernées (équipes sécurité, mais aussi devops, services support et d’exploitation…) pour les aider à définir comment faire évoluer leurs pratiques.

Comment le Cloud permet-il de faire évoluer le regard sur la sécurité ?

Dans le contexte de ce projet, impliquer l’équipe sécurité dès le lancement a été un vrai succès. Le client s’est rendu compte qu’il était gagnant à intégrer les questions de sécurité le plus tôt possible, et qu’on peut aussi avoir des discussions constructives avec les représentants sécurité, qui peuvent être force de proposition plutôt que d’opposition. En interne, on considère maintenant la sécurité différemment, le changement de mentalité a opéré. C’est un bon cas d’école sur ce qu’est le rôle d’un consultant sécurité dans le nouveau monde : il fait appel aux mêmes connaissances, mais son travail est beaucoup plus basé sur la discussion et l’échange, ce que je trouve très intéressant. Cela permet d’apporter une véritable plus value.

Quels sont les points de blocage ?

Beaucoup de services de sécurité des fournisseurs de services Cloud sont nouveaux et ils évoluent très vite.

De plus, certains intègrent des fonctionnalités très spécifiques. Par exemple, AWS a redéfini la notion de filtrage réseau à travers les concepts de Security Group et de NACL, en remplacement des pare-feux traditionnels. De même, un Security Group, par défaut, assure un filtrage en entrée mais est ouvert en sortie, et ne supporte pas plus de de 50 règles. Tout cela implique donc de penser sa stratégie de filtrage de façon différente. Ca peut être assez déroutant de prime abord !

Il n’y a pas de secret, il faut apprendre et creuser chacun de ces services en profondeur, apprendre à connaître leur fonctionnement et leurs spécificités. On ne peut pas improviser ou se fier uniquement à nos connaissances des technologies plus traditionnelles.

Peux-tu citer d’autres exemples de changement des pratiques de sécurité ?

La mise à disposition des plateformes Cloud s’accompagne d’une montée en puissance des projets construits en mode Agile. De fait, on ne peut plus construire sa stratégie sécurité comme on le faisait avec des projets organisés sur un cycle en V, en fournissant une longue liste exhaustive d’exigences en phase de développement, puis en effectuant un audit ou un test d’intrusion avant le passage en production.

Avec des mises en production fréquentes, comme c’est le cas sur le Cloud, la version produit n’est jamais “finale”, et les premières mises à disposition interviennent très tôt. Donc, on travaille sur des petits lots plutôt que sur un bloc monolithique. Dans un premier temps, on fixe un premier lot de règles incontournables, et on met en place un contrôle en continu. On reste vigilant sur le principe de “least privilege”. Mais on est amené aussi à plus déléguer aux équipes devops le paramétrage des règles de sécurité et leur adaptation au fil de l’eau, en fonction des besoins projet. Le renforcement du contrôle en continu permet d’enrichir les règles de sécurité pour détecter et prévenir les nouveaux comportements non conformes sans casser les cycles de développement et de production.

En quoi est-ce que cela change le travail des équipes sécurité ?

Elles doivent acquérir de nouvelles compétences en complément de leur savoir initial. Elles doivent se former aux services sécurité managés, accepter de revoir la manière dont elles découpent la mise en oeuvre de leurs mesures, et développer leurs expertises en développement, pour être capables de parler aux devops et comprendre leur univers (Gitlab, Kubernetes, etc.). Si on ne sait pas comment les environnements de développement fonctionnent, comment un Jenkins appelle des jobs, on ne peut pas mettre en place les bonnes règles de contrôle.

Les équipes sécurité doivent aussi comprendre le fonctionnement des projets métiers : par exemple pour un projet Data, c’est un grand challenge de concilier les besoins des data scientists, qui évoluent au fur et à mesure de leur exploration du contenu des datalakes, et l’objectif de définir des accès basés sur un inventaire a priori du besoin d’en connaître. On ne peut pas appliquer des recettes prédéfinies. Il est nécessaire de passer du temps avec les utilisateurs pour bien comprendre leurs besoins et leurs méthodes de travail afin de leur proposer un cadre de fonctionnement qui allie sécurité et flexibilité.

Alors comment faire ?

Une des clés est d’automatiser au maximum la sécurité : par exemple coder l’attribution des droits à la volée et des contrôles a posteriori. Il faut aussi adapter le modèle de responsabilités : le cloud permet de descendre le pouvoir d’action, il faut partager en même temps les actions de sécurisation avec les utilisateurs finaux. Un self-service IT doit s’assortir de la possibilité de “s’auto-sécuriser”. Il est essentiel de contrôler a posteriori plutôt que de tout interdire par défaut. Et enfin d’adopter une approche pédagogique : on sensibilise, on explique les règles nécessaires pour passer en production. Avec ce type d’approche, le nombre de bugs sécurité et d’alertes diminue. Pour un développeur qui peut faire sa mise en production sans ops parce qu’il a intégré les règles, c’est un vrai plus. C’est donnant-donnant : plus de liberté et de droits implique plus de responsabilités. Cependant, il n’y a pas de solution toute faite, chaque organisation doit trouver son équilibre, et c’est aussi tout l’intérêt de notre travail : contribuer à définir des réponses sur-mesure en apportant notre connaissance de solutions éprouvées par d’autres entreprises.

La sécurité n’est donc plus réservée aux équipes sécurité ?

Une des clés de la réussite pour les équipes sécurité est aussi de travailler de plus en plus en mode collaboratif. Certes il y aura toujours des experts, mais à l’image de notre organisation chez D2SI, la communauté sécurité, au sens large du terme, s’attachera à identifier, former et rassembler des « security champions » : des développeurs, Ops, PO, qui ont une forte appétence pour le sujet et qui contribueront à diffuser la culture sécurité dans chaque équipe. Nous recommandons à nos clients le même type d’organisation que celui que nous avons adopté : une core team sécurité qui s’appuie sur des architectes, des développeurs, des devops… Il ne s’agit pas de mettre en place une chaîne de commandement, mais d’avoir des early adopters qui relaient les bonnes pratiques.

Depuis ton arrivée sur ce projet, comment as-tu évolué personnellement ?

J’ai du faire ma propre acculturation, dés-apprendre pour ensuite me forger de nouveaux savoirs. Je me suis formée aux nouveaux services sécurité Cloud, en passant mes certifications AWS. A travers cette mission, j’ai aussi pu faire l’expérience concrète du besoin de changement de paradigme de la sécurité, et voir comment les équipes et les méthodes pouvaient évoluer. Je suis passée d’un ressenti théorique à des convictions pratiques.

On peut, on doit changer, c’est non seulement souhaitable, mais tout à fait faisable. Et puis on a construit une vraie communauté sécurité au sein de D2SI. Ce que nous préconisons chez nos clients, nous le portons et nous le mettons en oeuvre en interne.

Pour conclure, comment vois-tu cette évolution amenée par le Cloud ?

Ce n’est pas la première révolution, depuis que je travaille dans la sécurité, j’ai vu de nombreux changements de paradigmes, comme celui induit par l’arrivée du Bring Your Own Device. A l’époque, la sécurité ne pouvait plus empêcher les utilisateurs de lire leurs mails professionnels sur leur téléphone personnel. Elle a dû s’adapter à ce changement, où elle perdait la main sur le contrôle des ressources informatiques. On ne peut pas être dogmatique et imposer une vision, il faut au contraire descendre la responsabilité au maximum. Aujourd’hui avec l’arrivée du Cloud, toute la sécurité doit être réinventée. On connaît les grands principes, mais il reste à les mettre en oeuvre concrètement, à porter ce changement de culture, et c’est ce qui rend le métier passionnant.