De nombreuses entreprises françaises ont commencé à expérimenter sur le Cloud AWS il y a quelques années, et ce parfois en toute indépendance des structures Groupe. Que se passe-t-il alors quand, quelques années plus tard, toutes les applications sont sur le Cloud AWS, mais sans que n’aient été prises en compte toutes les exigences Cloud prescrites par la maison mère ? Comment se mettre en conformité a posteriori aux règles de gestion de la gouvernance Cloud, d’architecture d’une Landing zone, de paramétrage des comptes et de gestion des droits d’accès, etc. ? 

Nous vous proposons ici un retour d’expérience projet, pour lequel nous avons accompagné le client pour sécuriser ses comptes AWS et refondre la chaîne CI/CD utilisée par ses applications métier afin de répondre au plus vite aux exigences de sécurité du Groupe.

Etat des lieux des problématiques de sécurité

Lors de l’étape initiale de cadrage du projet, nous avons commencé par inventorier toutes les non-conformités aux exigences Groupe. Parmi celles-ci, nous pouvons citer : 

• Hébergement notamment de l’outillage de la chaîne CI/CD des infrastructures et des applications métier sur un compte AWS de type sandbox.
• Ouverture d’un accès sur Internet, sans mécanisme de chiffrement, et exposition directe de plusieurs ressources.
• Existence de multiples instances Jenkins non normalisées.
• Existence d’instances Nexus et SonarQube utilisant une version obsolète.
• Absence de gestion centralisée des accès. 

Objectifs prioritaires du client

Les collaborateurs IT du client qui pouvaient contribuer au déploiement des mesures de mise en conformité avaient une disponibilité limitée. Par le fait, il a été nécessaire de prioriser les mesures à implémenter. 

La deuxième étape de la phase de cadrage a donc consisté à formaliser un plan complet de traitement des non-conformités et de faire arbitrer les priorités par le client. 

Il est important de souligner que cette étape a été menée en sollicitant l’ensemble des parties prenantes client, à savoir les référents des équipes de dev, d’exploitation, de sécurité, de pilotage projet et des représentants de la direction de la DSI ; cela afin de garantir une pleine adhésion et un total support lors du déploiement du plan de correction.

Les actions jugées comme prioritaires pour le client ont été les suivantes :

• Modifier l’architecture de la Landing Zone et le paramétrage de ses composants pour respecter les exigences sécurité émises par le Groupe.
• Remplacer l’outil CI/CD Jenkins par Gitlab CI, et sécuriser sa configuration.
• Décommissioner Ansible et utiliser Terraform pour la gestion as Code de l’ensemble des composants Cloud hébergeant les applications métier.

Un cadrage nécessaire

Un projet colossal et non sans risque opérationnel qui nécessite une excellente connaissance de l’existant.  Afin d’identifier et d’approfondir les enjeux précis de chaque axe technique, fonctionnel et organisationnel du projet, il a été jugé requis de commencer par une phase de cadrage. 

Ce temps passé dans l’échange et la réflexion avec le client, a permis de confirmer tous les axes de travail, d’estimer le temps nécessaire, d’identifier les parties prenantes (local, Groupe et externes), d’évaluer les risques projet et d’établir un planning d’intervention.

Cette phase de cadrage était d’autant plus importante que les délais de mise en œuvre étaient serrés, le client s’étant engagé vis-à-vis du Groupe à réaliser toutes les corrections dans un délai de quelques mois. Il était donc impératif d’éviter la découverte de (mauvaises) surprises en cours de route !

De la mise en conformité à l’évolution de la chaîne CI/CD

Le cadrage a porté sur deux macros périmètres, à savoir : 

• La roadmap de mise en conformité sécurité, pour couvrir les écarts entre les exigences Groupe et l’état actuel identifié lors de l’audit  et 
• L’évolution de la chaîne CI/CD. Pour ce dernier sujet :
  • Nous avons réalisé une analyse de différents scénarios d’outillages, en nous appuyant sur une étude des outils disponibles sur le marché : capacité à répondre aux besoins client et adéquation des coûts aux enveloppes budgétaires disponibles (selon les choix de licences). 
  • Le passage d’Ansible à Terraform a été étudié en intégrant le fait que cela impliquerait de reconstruire les environnements et donc de migrer la zone d’hébergement des applications. 

Plusieurs propositions à options ont été faites, sur ces deux sujets, avec des scénarios de tarification, de calendrier de mise en œuvre et de risques opérationnels. Ceci nous a permis de mieux comprendre les priorités exactes du client et de limiter le périmètre du projet de mise en œuvre au strict nécessaire.

Pour réaliser ce cadrage, nous avons mené des interviews, animé des workshops et effectué des revues de documentation. La difficulté de l’exercice a été que nous avons dû mener le projet entièrement à distance (ce projet a été lancé juste au début de la phase de confinement!) et sans accès aux repositories ni aux environnements AWS client (là encore en raison de mesures de ségrégation des accès difficilement contournables par un externe en situation de confinement).

Dans ces conditions, il était plus difficile de créer le liant nécessaire à l’appropriation du projet par toutes les parties prenantes. D’un point de vue technique, il était aussi du coup très difficile de recenser l’ensemble des applications, pipelines de déploiement et dépendances entre composants. Or, une connaissance détaillée des dépendances entre les différents composants est pourtant indispensable dans tout projet de migration quel qu’il soit. 

Ce point illustre les impacts négatifs d’un manque de documentation régulière des environnements IT  et de transferts de connaissances incomplets lors du départ de certains collaborateurs clés. Nous avons ainsi découvert lors de la phase de mise en œuvre que des instances Jenkins, qui n’étaient plus connues des équipes internes, hébergeaient pourtant des pipelines critiques (mais rarement exécutés).

Plus qu’un projet technique

Pour mener à bien ce projet, nous avons donc en quelque sorte mené un processus de “reverse engineering” du système d’information, afin d’identifier l’ensemble de ses composants et leurs interdépendances. Nous avons ensuite travaillé avec les équipes en interne pour leur expliquer les interactions, ainsi que les modifications à apporter en vue de leur migration sur la nouvelle chaîne CI/CD. Plusieurs sessions ont été ainsi organisées, pour les développeurs et pour les équipes ops, et tous étaient demandeurs d’informations et de détails. De fait, le transfert de compétences s’est fait au fur et à mesure de l’avancée du projet, et les équipes dev et devops ont pu monter en compétence au jour le jour dans la prise en main des nouvelles fonctionnalités proposées.

Dans la prochaine partie de cet article, nous passerons au bilan de ce projet : quelles actions de simplification et de sécurisation ont été menées suite à cette phase de cadrage ?