Soyons honnêtes : tous les projets Cloud ne réussissent pas du premier coup. De la cible initiale à ce qui passe effectivement en production plusieurs mois plus tard, il y a parfois un écart. Nous vous proposons ici un retour d’expérience sur un projet de transformation Cloud à grande échelle : certaines choses ont fonctionné, d’autres pas, notre objectif ici sera de mettre en avant les facteurs clés de succès, et de tirer les enseignements des échecs constatés, en faisant un focus sur la thématique “sécurité”.

Contexte

Pour situer le contexte, l’entité française d’une grande entreprise internationale, dont l’IT est en partie externalisée, a souhaité lancer une initiative Cloud afin d’accroître son agilité et son “Time to Market”.

L’objectif était d’engager un vaste programme de transformation et de migration, en partant de zéro, et de démarrer plusieurs chantiers fondateurs de façon simultanée. Généralement sur ce type de projet, deux approches sont possibles. Un démarrage progressif avec un ou plusieurs POC, puis une accélération au fil du temps, ou une approche globale avec un démarrage rapide, comme ce fut le cas ici :

• Création d’une plateforme Cloud (avec environnement de production et accès Internet dédié)
• Conception d’un modèle opérationnel Cloud au sens large
• Construction d’une roadmap de migration des applications
• Mise en place d’une communauté Cloud 

Ambition sécurité du projet

Ce projet avait notamment pour enjeu d’intégrer la sécurité dès les toutes premières étapes du MVP. La prise en compte de la sécurité dès le démarrage de ce type de projet est un choix stratégique, malheureusement, encore trop rare.

C’est pourquoi nous avons tenu, à travers cet article de blog, à faire un focus sur cet aspect pour montrer les facteurs clés de succès et les limites lorsque l’on cherche à adresser en parallèle tous les sujets suivants :

• Sécurité technique, à travers notamment le déploiement, dès les premières semaines du projet, de mesures de sécurisation de la landing zone et de l’accès Internet, et de contrôle des règles de sécurité interne.
• Gouvernance de sécurité, à travers notamment la définition du RACI des équipes sécurité, la mise à jour des processus opérationnels sécurité et l’identification des outils de gestion opérationnelle,…
• La définition d’un plan de conduite du changement sécurité, incluant la définition d’un plan de sensibilisation et de formation des référents sécurité (pour accompagner la montée en compétence des interlocuteurs sécurité sur les spécificités “Exploitation du Cloud” et “Sécurité Cloud”)…

Le RSSI, les référents sécurité opérationnelle, les responsables Contrôles Permanents, les responsables des migrations applicatives et les référents Gouvernance de la donnée ont été impliqués dans ces discussions initiales autour de la sécurité. 

Bilan de la mise en oeuvre

Sur le papier donc, nous avions là un cas d’école parfait de démarrage de projet. Plusieurs mois plus tard, nous devons cependant constater que tout ne s’est pas déroulé comme prévu. À titre d’exemple, les bastions d’accès, briques fondamentales du dispositif sécurité, ne sont toujours pas déployés. 

On peut citer aussi les difficultés dans le choix d’une solution pérenne de gestion des secrets, en raison d’une divergence entre les outils proposés par le Groupe et ceux recommandés pour un usage Cloud. 

Dans la plupart des cas, les freins au déploiement de solutions de sécurité n’ont pas été liés à des problèmes d’ordre technique mais en grande partie à des problématiques fonctionnelles et organisationnelles : difficulté à avoir accès aux bonnes informations, organisation des équipes en silo, gestion d’une partie de l’IT par un département externe et à la sous-traitance d’une partie des prestations IT, manque de connaissance des outils et services de sécurité spécifiques au Cloud . 

Heureusement, le tableau n’est pas complètement noir, et même loin de ça ! Inclure la sécurité en amont du projet a aussi apporté des gains significatifs : via un accompagnement dès le début des référents sécurité il a été possible de faciliter le recrutement d’experts sécurité Cloud dès les premiers mois du projet. Cela a fait la différence en termes de niveaux de contribution sécurité au projet. De même, les équipes ont pu ainsi rapidement mettre à jour le plan de contrôles permanents de l’organisation, pour intégrer les environnements et processus Cloud. 

En prenant le temps de former, d’informer, d’alerter et d’expliquer, il est plus facile aussi de trouver des relais en interne capables de mobiliser du temps et du budget pour engager les ressources nécessaires à la transformation, y compris sur le volet sécurité. 

Cela montre bien qu’imposer un changement de technologie à grande échelle demande surtout et avant tout de bien se préparer à la gestion du changement.

Les enjeux techniques sont simples, les enjeux organisationnels et fonctionnels sont clés et surtout complexes. La gestion du changement est donc bien un investissement, et non un coût. 

Au final, l’implication de l’équipe sécurité et l’approche collaborative a, par la bande, largement contribué à casser les idées reçues liées à une organisation en silo et à améliorer l’image de marque des référents sécurité auprès des autres parties prenantes : beaucoup craignaient qu’inclure dès le départ les responsables sécurité soit un frein, et pourtant ce mode de fonctionnement a apporté, de l’avis de tous, un véritable gain pour le projet.

À ce jour, après une phase de trois mois pour construire la Landing Zone puis une phase de déploiement automatisé au fil de l’eau des workloads de 200 entités, le bilan sécurité du projet s’établit comme suit :

• Mise en place d’un socle standard de sécurité au démarrage du projet (gestion des accès, de l’authentification, filtrage réseau, centralisation et analyse des logs , chiffrement, ségrégation des comptes et rôles, etc)
• Création de User Stories Sécurité et définition de “critères de clôture sécurité” pour toutes les user stories
• Identification de référents sécurité Cloud, parties prenantes des cérémonies projet Agile (planning, rétro…) 
• Positionnement d’ateliers d’échanges avec toutes les parties prenantes IT et Métier autour des enjeux sécurité Cloud 

S’il reste encore du travail pour atteindre l’ensemble des cibles de sécurité, on constate que le travail de sensibilisation et d’acculturation a bien fonctionné : certaines solutions, comme la mise en place d’un SD-WAN, ont été proposées par le client (et déployées avec l’aide des équipes Revolve). 

Conclusion 

Pour conclure, nous retiendrons l’importance du travail sur la résistance au changement de toutes les parties prenantes, la nécessité de mobiliser des ressources en interne sur la mise en place opérationnelle des outils et le bénéfice qu’on peut retirer de l’implication des référents sécurité gouvernance et opérationnelle dès le lancement du projet.