Avant-propos
La réalisation s’étant déroulée dans le domaine de la cybersécurité (qui est un contexte sensible), des informations ont été volontairement tronquées pour préserver la confidentialité de nos clients ainsi que des technologies employées.
1 – INTRODUCTION
Dans le cadre de mon Master Expert des Systèmes d’Information à INTECH Agen devenu ESIEA débuté en septembre 2022, j’ai travaillé pendant deux ans en alternance en tant que DevOps pour le compte de l’entreprise ITRUST (entreprise membre du groupe ILIAD).
ITRUST est une entreprise spécialisée dans la création de logiciels de cybersécurité pour les entreprises, dans la réalisation des audits de sécurité et dans l’analyse des incidents de sécurité pour le compte de ses clients.
J’ai intégré l’entreprise en tant que DevOps pour le logiciel Reveelium. Ce logiciel stocke et analyse les journaux d’événements des serveurs d’une entreprise pour générer des alertes comportementales appelées UEBA. Des technologies d’intelligence artificielle sont également utilisées pour mettre en corrélation des alertes entre elles et ainsi générer des menaces de différents niveaux.
Le métier que j’exerce chez ITRUST se nomme DevOps. C’est un métier du numérique qui a été réellement adopté par les entreprises depuis 2015. Il consiste en l’automatisation des différentes actions liées à l’opérationnel. Il y plusieurs années, pour mettre à jour un serveur, il fallait envoyer différentes commandes une par une manuellement ou grâce à un script. Désormais, avec le métier de DevOps, nous allons écrire des playbooks. Ce sont des scripts beaucoup plus intelligents et évolués qui permettent de simplifier la gestion des déploiements sur les infrastructures. J’exerce cette profession depuis deux ans et je travaille sur le logiciel Reveelium en participant à l’amélioration des différents Playbooks d’installation et de mise à jour.
En tant que DevOps pour ITRUST, j’ai également participé à la MCO du logiciel Reveelium auprès de nos clients. La MCO est la mise en condition opérationnelle. En cas d’incident sur le logiciel de cybersécurité, nous devons réagir très rapidement pour minimiser les conséquences sur la production.
2 – OBJECTIFS
Cette réalisation a été effectuée dans le cadre d’une alternance d’une durée de 24 mois. Les objectifs humains et techniques à atteindre étaient nombreux.
Humainement, j’ai pu développer mes aptitudes relationnelles en lien avec les interactions nécessaires à ce métier. Travailler en informatique, c’est avant tout être en capacité de répondre aux clients de manière appropriée et intelligente, mais également d’être en mesure de tenir des discours construits ainsi que de pouvoir présenter des présentations adaptées auprès des différents collaborateurs. Il est également important d’être capable de consulter les équipes chargées de la relation clientèle pour comprendre les vrais besoins du client pour ne pas répondre à un besoin de manière imprécise.
Les objectifs techniques comportaient quatre axes : le premier consistait en la maîtrise de l’installation du logiciel. Le logiciel étant très complexe, il m’a fallu d’abord comprendre les différentes phases de son installation. Le second objectif était d’être capable de créer ou d’adapter les playbooks d’installation et de mise à jour, autrement formulé, maîtriser le concept de DevOps, savoir ajouter, retirer, améliorer des briques du logiciel pour répondre au besoin toujours grandissant. Le troisième objectif était d’être capable de mettre à jour le logiciel Reveelium chez des clients déjà existants. Le dernier objectif était de savoir dépanner le logiciel en cas d’incident chez les clients, c’est-à-dire devenir un membre à part entière dans le RUN MCO (Maintien en Condition Opérationnelle) , ce qui signifie faire partie des équipes qui interviennent sur les incidents de production.
3 – CONTEXTE HUMAIN
La composition des effectifs d’équipe Reveelium chez ITRUST a évolué durant toute mon alternance. Au fur et à mesure, celle-ci s’est de plus en plus structurée. Pendant plus d’une année, les développeurs du logiciel et les DevOps étaient réunis en une seule équipe. Ensuite, eu égard au besoin grandissant, le responsable technique de Reveelium a choisi de diviser l’équipe en deux. La première serait l’équipe “Reveelium Dev”, composée des développeurs du logiciel, la seconde allait devenir l’équipe “Infrastructure” composée des DevOps & techniciens MCO. Bien que divisées en deux, les équipes restent évidemment intimement liées dans leur travail.
En tant que membre de l’équipe Infrastructure, j’ai fréquemment l’occasion d’échanger avec les clients du logiciel Reveelium qui rencontrent des incidents ou qui posent simplement des questions. Ces échanges peuvent être directs ou indirects. Durant ces entretiens, j’ai parfois été amené à gérer seul une conférence avec un client ou j’ai pu être accompagné par mon responsable technique ou un membre de l’équipe SDM selon le besoin. L’équipe SDM ou Service Delivery Management joue un rôle très important dans la gestion des incidents, elle procède à l’inventaire et au suivi des incidents et des demandes des clients.
Nous interagissons avec les analystes spécialisés en cybersécurité de l’entreprise. Ils analysent les alertes et les menaces qui sont générées par le logiciel Reveelium et réalisent des analyses de cybersécurité poussées. Ils sont donc en mesure de nous informer d’une défaillance du logiciel chez un de nos clients avant même qu’il ne s’en aperçoive.
Comme nous l’avons vu, pour exercer en tant que DevOps, il faut donc être apte à interagir avec de nombreux acteurs internes ou externes à l’entreprise.
4 – CONTEXTE TECHNIQUE
Reveelium est un logiciel déployé sur un ensemble de serveurs. C’est en utilisant la technologie Swarm (Swarm est un orchestrateur de conteneur Docker) que nous sommes en mesure de gérer le logiciel sur les serveurs.
Pour des raisons de confidentialité, je ne pourrais pas détailler ici l’architecture du logiciel, mais je peux dire que le logiciel est découpé en trois services. Le premier service est nommé “Collector” ; il a pour but de collecter et de sauvegarder les logs des clients. Le second service se nomme “Analysis” ; il est responsable de la génération des alertes et des menaces. Ce service analyse les logs collectés et génère des alertes ou des menaces de manière statique via des règles de sécurité ou via des procédés d’intelligence artificielle qui analysent et mettent en corrélation des signaux faibles (différents événements qui individuellement ne représentent pas de danger, mais quand ils sont groupés deviennent une réelle menace). Le service Analysis comporte également un outil de ticketing permettant la qualification d’alertes en menaces et leurs mitigations par une équipe d’experts en cybersécurité. Nous disposons d’un dernier service nommé “Monitoring”. Celui-ci nous permet de surveiller l’état physique (disques durs, RAM, CPU, etc.) des différents serveurs de Reveelium, mais également, de surveiller la santé de l’infrastructure logicielle.
Reveelium utilise donc Docker et Docker Swarm. Docker est défini comme “une plateforme logicielle qui permet de concevoir, tester et déployer rapidement des applications”. Docker est une technologie de cloisonnement des applications. Avant, nous utilisions un serveur pour une application, un service. Plus tard sont parus les systèmes d’hypervision permettant de créer des serveurs virtuels. Aujourd’hui, Docker permet d’isoler l’exécution d’une application sans avoir besoin d’exécuter un système d’exploitation supplémentaire. Swarm est défini comme un orchestrateur de conteneurs responsable de démarrer, stopper, répliquer et vérifier l’état de santé des conteneurs que nous lui confions”. Par conséquent, c’est Swarm qui s’occupe de gérer la réplication des conteneurs en cas d’incidents pour éviter les pannes de service.
5 – ENJEUX ET RISQUES
5.1 – ENJEUX
Les enjeux rencontrés dans le cadre de mon travail chez ITRUST sont nombreux. J’ai pu définir trois principaux enjeux : la satisfaction de la clientèle, les délais de réponses aux incidents et le maintien de l’expertise en cybersécurité. La satisfaction des clients est un enjeu majeur en entreprise. En tant que fournisseur de services de cybersécurité, nous devons protéger nos clients. Ils ont une attente particulière, car ceux-ci se reposent sur nous pour les prévenir de toute cybermenace. C’est pourquoi, en tant que DevOps et Technicien MCO, il est réellement primordial de prendre en compte l’importance du logiciel que je maintiens. Par conséquent, les délais de réponse aux incidents doivent être à la hauteur des attentes des clients et être les plus réduits possible. Une réalité persiste toutefois au sein des équipes qui monitorent et gèrent les incidents d’un logiciel, nous pouvons constater que certaines réponses ou corrections d’incidents nécessitent un certain temps. En effet, certaines demandes des clients ou certains incidents peuvent comporter une part d’inconnu. Cela peut-être une erreur physique ou logicielle dans l’application que nous n’avons jamais rencontrée. Il est fréquent que les clients souhaitent des ajouts personnalisés à leurs contextes techniques. Ces demandes engendrent des délais pour ITRUST afin de vérifier les faisabilités et les coûts qu’engendrerait la réalisation de ces besoins spécifiques. Un autre des enjeux auquel j’ai été confronté réside dans le fait que nous sommes une entreprise de cybersécurité, par conséquent, nous devons maintenir un niveau d’expertise en cybersécurité. N’étant pas un analyste spécialisé en cybersécurité, je ne suis pas amené à réaliser des audits ou des analyses poussées en cybersécurité, cependant la cybersécurité se traduit concrètement dans mon travail de DevOps par l’application des bonnes pratiques en matière de cybersécurité. Elles concernent les aspects techniques (sécuriser les échanges, préserver la confidentialité, cloisonner les applications, etc.) mais aussi les aspects extra-techniques de mon métier (la rédaction d’un mail, d’un compte-rendu ou d’une analyse technique pour un client).
5.2 – RISQUES
Le contexte de ma réalisation comprend aussi des risques. Nous en étudierons quatre.
Premièrement, les risques rencontrés pendant la modification du logiciel (playbooks et environnements de développements). En second lieu, nous évoquerons les risques liés aux différentes pertes de service du logiciel. Nous verrons ensuite les risques durant le dépannage de la solution et enfin les risques financiers.
En tant que DevOps, j’ai réalisé de multiples modifications dans les playbooks d’installation et de mise à jour du logiciel, mais aussi dans les environnements de développements et de tests ainsi que dans le parc applicatif permettant de réaliser de la CI/CD qui est l’implémentation de solutions d’automatisation pour procéder à de l’intégration et à la livraison continue. En tant que junior, il m’est arrivé de mal mesurer les risques encourus lors d’un changement. Il est donc très important pour moi de comprendre la sensibilité des environnements sur lesquels j’interviens. Chaque changement technique d’un projet ou d’une application peut causer des cessations du fonctionnement, c’est la raison pour laquelle son approbation par un responsable est nécessaire.
Le risque de perte de service est très important dans le cadre d’un logiciel comme Reveelium. Le logiciel étant complexe, sa stabilité peut-être mise à rude épreuve. C’est surtout dans le cadre du non-respect des prérequis en matière d’infrastructure (physiques comme réseaux) que des problèmes surviennent, le logiciel ne serait alors plus en mesure de collecter et d’analyser les journaux d’événements des serveurs des clients. Ce type de panne engendre deux conséquences. La première est que les journaux d’événements (appelés plus communément “logs”) envoyés par les serveurs des clients sont perdus. Il n’existe alors aucune possibilité pour récupérer un historique sur les logs perdus pendant les coupures de service. La seconde conséquence est la perte d’analyse de ces logs. Les logs perdus comportent des informations pouvant qualifier une cyberattaque et c’est pourquoi une perte de service constitue un vrai problème.
Quand un incident se produit, nous rencontrons différents risques. Nous avons évoqué la perte et l’analyse des logs. Dans le cadre des tentatives de rétablissement du service, nous sommes confrontés à un ensemble de risques bien réels. Plus haut, j’ai précisé que j’étais un technicien junior. Dans le cadre des résolutions d’incidents, je dois faire de mon mieux pour rester autonome et résoudre les incidents, cependant le risque principal dans ce genre de contexte est de faillir à mon investigation technique à cause de ma faible expérience. Les conséquences sont nombreuses, mais restent toujours liées à une interruption du bon fonctionnement du logiciel, c’est pourquoi, quand j’ai un doute sur mes analyses, je consulte mes responsables pour avoir un second avis.
Le respect des différents processus de l’entreprise est primordial pour éviter des coupures de services provoqués par un défaut d’expertise.
6 – ORGANISATION
L’équipe Infrastructure est composée de techniciens systèmes et réseaux ainsi que de DevOps. La volonté de notre responsable a été de spécialiser les différents membres de l’équipe. Le logiciel étant réellement complexe, chaque partie nécessite beaucoup d’heures d’apprentissage pour parvenir à une réelle maîtrise de sa compréhension, certains aspects ne sont maîtrisés que par une partie des effectifs. Dans la volonté de favoriser le rendement et le suivi dans la réponse aux incidents, un titre de responsable hebdomadaire de gestion des incidents (par roulement) a été établi. Un membre de l’équipe Infrastructure est ainsi chargé de répondre en temps réel aux incidents, mais également de qualifier les différents tickets présents dans le backlog (file de tickets) de notre logiciel de gestion de projet. Ce travail est régi par différents processus afin d’être les plus réactifs possible. Ce collaborateur est donc chargé de suivre l’ensemble des événements qui se produisent sur une semaine et d’en assurer le suivi. Même si sa semaine est terminée, il continue de mener à bien la résolution de chaque incident dont il était responsable. Le fait d’avoir une personne précise référente permet d’être sûr que chaque demande est qualifiée (définie comme un incident ou non) et traitée, mais, à tout moment, elle peut demander de l’aide si elle est soumise à une trop forte charge de travail, car nous sommes avant tout une équipe. Mon responsable convie alors toute l’équipe pour une réunion extraordinaire afin de départager le travail. La situation peut ainsi être gérée et les clients satisfaits. Il m’est arrivé régulièrement de me voir attribuer cette fonction et de devoir parfois demander de l’assistance, car trop de clients rencontraient des incidents simultanément.
En-dehors de ces périodes particulières, nous pouvons, à souhait, nous affecter des tâches grâce à l’outil de gestion de projet. Nous y disposons de la liste des dernières demandes des clients ou des derniers changements à réaliser, ainsi quand nous avons terminé une tâche, il nous suffit de chercher une autre tâche à réaliser sans oublier de prendre en compte leurs niveaux de criticités. Il m’est souvent arrivé d’avoir des doutes pour départager deux tâches entre elles : même niveau de criticité, même date de création et même niveau d’importance dans leur contenu. Travaillant pour un logiciel sensible, il est très fréquent que cela se produise, car tout incident est urgent. Pour départager ces tâches, je peux consulter mon responsable technique ou le SDM du client concerné. Connaître la relation que nous avons avec le client est intéressante pour départager les priorités.
Dans le cadre de mon travail, je suis beaucoup en contact par mail avec les clients. Je peux produire par exemple des comptes-rendus post-incidents rappelant les faits et les détails techniques qui ont causé les interruptions du service, rédiger des réponses à des questions techniques, notifier le client d’une coupure de service planifiée pour une action de mise à jour ou un changement d’infrastructure exceptionnel. Je suis toujours autonome sur la rédaction et la mise en page de toutes ces interactions avec les clients, mais tous mes mails sont relus par un tiers avant envoi. C’est pour moi l’opportunité d’améliorer les échanges que j’ai avec les clients en bénéficiant des conseils d’une personne expérimentée qui sont toujours très intéressants, notamment sur les tournures de phrases à employer dans certains contextes ou sur la façon de présenter à un client un coût supplémentaire à prévoir.
Je suis aussi souvent en relation avec les analystes du Centre des Opérations de Sécurité (SOC). Comme nous l’avons vu précédemment, ceux-ci ont pour rôle de qualifier les alertes et menaces du logiciel Reveelium et ce sont nos premiers utilisateurs. Quand un incident à lieu, les analystes sont directement affectés dans leur travail, c’est pourquoi la communication avec eux est très importante pendant et après un incident. Cela nous permet d’avoir un ressenti général sur l’outil. Ils nous informent par exemple si le logiciel est anormalement lent depuis plusieurs heures ou si certaines pages ne s’affichent pas correctement. Ils nous aident aussi pour valider le retour à la normale post-incident.
7 – TRAVAIL RÉALISÉ
7.1 – Premier ajout DevOps
Durant mon premier mois en tant que DevOps chez ITRUST, une tâche m’a été confiée. Avec un ensemble de contraintes techniques, je devais réaliser un script permettant d’automatiser la configuration d’un logiciel compris dans Reveelium. Pour des raisons de confidentialité, nous l’appellerons Alpha. Les contraintes techniques que l’on m’a imposées étaient les suivantes : le script devait être réalisé grâce à un langage de templating (volontairement non mentionné ici) au sein d’un playbook. Le format de la configuration du logiciel a aussi été défini par mon responsable.
Je n’avais jamais travaillé avec ce langage de templating (en français, langage de modélisation) et lors de cette réalisation, je suis allé proche des limites techniques de celui-ci. Il me paraît intéressant de mentionner que la volonté de ne pas réaliser un script dans un langage de programmation plus classique était réellement pertinente. Bien que d’autres langages soient plus rapides et beaucoup plus lisibles dans ce cas de figure, le fait d’utiliser notre logiciel de déploiement à cent pour cent grâce au langage de templating est beaucoup plus intéressant. Un bon logiciel de déploiement permet notamment de compter le nombre de changements réalisés sur une infrastructure, si nous utilisons des solutions de facilité externe, nous ne sommes pas en mesure de savoir ce qui va réellement changer sur un environnement de production quand nous appliqueront le playbook.
Dans un premier temps, mon responsable ne m’avait pas donné de contraintes particulières sur la façon de réaliser le script dans le langage choisi. La réalisation de cette tâche a alors été effectuée en trois livraisons. La première a été la livraison d’un script complètement fonctionnel, mais comportant beaucoup de défauts, la seconde avait une structure revue et bien plus optimisée et enfin la dernière comportait la correction de bugs rencontrés en production.
La première livraison était tout à fait fonctionnelle. Cependant, cette livraison était ma toute première réalisation dans le langage de programmation choisi. Je n’avais pas une connaissance approfondie des possibilités techniques, par conséquent, le script que j’ai produit comportait un grand nombre d’erreurs. Ici, nous parlons d’erreurs de mise en œuvre du langage, certaines façons de faire n’étaient pas conseillées ou dépréciées. Dans le but d’améliorer le livrable, mon responsable a relu avec moi chaque étape du script. Cette relecture m’a permis de mieux comprendre le langage et de mieux l’utiliser. Cette étape a été très intéressante pour simplifier le script rendu. Après avoir réalisé un grand changement sur le script, j’ai effectué une série de tests et j’ai publié le script en production. Quelques mois plus tard, nous nous sommes cependant rendu compte que le script avait un défaut. Celui-ci réalisait deux configurations dans le mauvais ordre ce qui a causé des problèmes sur les logs collectés pendant une courte période. Quand cet incident a été découvert, j’ai repris mes tests pour en confirmer la véracité. J’ai donc produit une troisième version du tout avec la correction à ce problème.
7.2 – Réalisation de l’installation du logiciel Reveelium
Les équipes commerciales de l’entreprise sont chargées de contacter différents prospects (clients potentiels) pour faire la promotion du produit. Si le prospect souhaite devenir client de la solution Reveelium, il devra se conformer au DAT (Document d’Architecture Technique) du logiciel. Comme nous l’avons mentionné, le logiciel est exécuté sur un cluster composé de plusieurs serveurs physiques. Le DAT spécifie l’ensemble des prérequis physiques et logiciels nécessaires au bon fonctionnement de la solution. Les serveurs physiques peuvent être situés à deux emplacements différents : chez le client ou dans le Cloud (un datacenter ITRUST situé en France). Reveelium peut-être vendu via trois offres différentes.
• La première propose au prospect de devenir client de la solution. Il possède une infrastructure (en Cloud ou sur site) dédiée à son besoin et profite de l’expertise du SOC (Security Operation Center) d’ITRUST.
• La seconde solution offre au client la possibilité de devenir revendeur de la solution Reveelium. Le client devient responsable de la gestion du SOC.
• Enfin, le client peut choisir d’être intégré dans une plateforme mutualisée ; une infrastructure Reveelium qui accueille plusieurs clients en simultané. Dans le cadre de cette dernière solution, les clients de ces plateformes ont des limites sur le nombre de logs à envoyer qui sont mesurées en logs par seconde. Un affinage des logs envoyés par chaque client est donc réalisé pour favoriser le bon fonctionnement de ces plateformes, mais également pour garantir la sécurité des clients.
Reveelium pouvant être installé de trois manières différentes, nous allons voir les différentes étapes d’installation de chacune d’entre elles. Dans un premier temps, nous verrons l’installation d’un nouveau client sur une plateforme mutualisée, puis l’installation d’un client sur une plateforme autonome et enfin, le procédé de mise à jour d’une plateforme.
7.3 – Installation d’un client sur une plateforme mutualisée
L’ajout d’un client à une plateforme mutualisée est une activité simple à réaliser, car nous ne faisons qu’altérer le fonctionnement d’une application déjà existante. Trois principales étapes sont à effectuer. Dans un premier temps, nous procédons à une prise d’information auprès des SDM (Service Delivery Management), puis nous réalisons des changements de configuration du logiciel mutualisé. Nous communiquons enfin à différents acteurs de l’entreprise la fin des opérations.
Quand un client contracte avec ITRUST pour être ajouté sur une plateforme mutualisée, nous sommes prévenu par l’équipe SDM. Cette notification est réalisée dans le logiciel de gestion du projet Reveelium. Dans cette notification (ce ticket) nous recevons le nom du client et une estimation du nombre de logs par seconde. Grâce à ces informations, je peux décider sur quelle plateforme mutualisée je vais positionner le client. Ce choix est sensible, car toutes les plateformes mutualisées de l’entreprise possèdent leurs spécificités. Réaliser un mauvais choix pourrait mettre en péril le bon fonctionnement de l’ensemble d’une plateforme, c’est pourquoi, en cas de doute, il est important d’échanger sur cette décision avec les différentes équipes concernées (SDM, Infrastructure, Build).
Dès l’instant où nous avons récupéré cet ensemble d’informations nécessaires à l’ajout d’un client, nous pouvons réaliser les changements sur la plateforme mutualisée. D’abord, nous allons ajouter le nom de la nouvelle organisation dans le logiciel Reveelium. Le procédé est différent selon les versions de Reveelium. L’objectif final est de rendre disponible une nouvelle zone cloisonnée de l’application pour le client. Dans cette phase se trouve notamment la création de différents comptes utilisateurs avec différents droits (lecture/écriture/administrateur). Après avoir créé ce nouvel environnement, nous allons procéder à des changements sur la partie “collector” de l’application. Cette partie est responsable de la récupération et du stockage des logs. Nous devons procéder à certains changements dans cette partie du logiciel pour ajouter des certificats, enfin nous modifions la partie “Analysis” de Reveelium. Cette étape contient un ensemble de règles rédigées par les analystes du SOC (Centre des Opérations de Sécurité). Pour que le logiciel fonctionne correctement, nous allons ajouter les règles par “défaut” qui sont déployées chez tous les clients. Un travail d’expertise en lien avec les règles de détection est réalisé par la suite par l’équipe Build. Cette équipe est chargée de déployer des règles en adéquation avec les différents types de logs que nous envoient les clients (Windows, Linux, Firewall, Proxy, Dns).
Après avoir réalisé la création de l’organisation sur la plateforme visée, nous allons pouvoir communiquer différentes informations. Nous allons premièrement communiquer à l’équipe SDM que le client a été ajouté. Cela est réalisé via un mail qui contient des informations techniques (URL et IP d’accès à Reveelium ; comptes utilisateurs), puis toujours par mail, nous allons informer l’équipe Build que la plateforme est prête à accueillir les logs du client. Cette communication permet à l’équipe Build de pouvoir démarrer les échanges avec les clients sur les types de logs que ceux-ci vont envoyer et ainsi définir les règles et les parsers (dans la partie segmentée du client dans Reveelium, les parsers sont des scripts qui permettent d’apporter des changements sur les logs entrants, ils permettent d’ajouter, de tronquer et de supprimer des informations dans les logs afin de simplifier les données).
7.4 – Installation d’un client sur une plateforme autonome
Comme nous l’avons vu dans le cadre d’une plateforme mutualisée, la première phase d’installation consiste en la prise d’information auprès du client. Pour procéder à l’installation de Reveelium sur une infrastructure dédiée, le client doit se conformer à un DAT (Document d’Architecture Technique). Ce document contient les informations nécessaires dont doit être composée l’infrastructure qui doit accueillir Reveelium. Au préalable, le client nous remet des informations liées à son infrastructure qui sera dédiée à l’installation du logiciel. Celles-ci sont composées des mots de passe d’accès aux différents serveurs, d’adresses IP diverses (serveurs, serveurs proxy, serveurs DNS, etc.).
Après avoir vérifié et corrigé si nécessaire l’infrastructure livrée, je dois effectuer un travail de préparation au déploiement. Je dois configurer deux espaces de développement différents (Repository Git). Le premier permet de définir les adresses IP des serveurs du client et la configuration du logiciel voulu pour ce client. C’est dans ce Repository Git que je dois définir les informations réseaux voulues pour le logiciel et l’ensemble des informations uniques par client. Le second Repository Git permet de définir les règles de détections qui seront exécutées par le client.
Après avoir configuré les deux Repository, nous sommes prêts pour procéder au déploiement de Reveelium sur l’infrastructure. Pour ce faire, nous utilisons quatre playbooks qui seront exécutés par un logiciel adapté. Ces playbooks sont nommés : “Vérification”, “Installation des prérequis”, “Installation de Reveelium” et “Configuration de Reveelium”. Ils sont chargés de déployer Reveelium de manière automatisée. C’est là tout l’art du DevOps. Autrefois, pour réaliser ces actions, deux semaines d’installation étaient nécessaires. Aujourd’hui, le délai est désormais de deux à trois heures pour que ces quatre playbooks se déroulent. Bien qu’elle soit automatisée, cette phase implique un suivi en temps réel des états des playbooks par un DevOps. Cette surveillance est liée à de possibles erreurs dans l’exécution des différents scripts. Les environnements de production ne pouvant jamais être parfaitement identiques, certaines erreurs sont rencontrées uniquement chez un client spécifique et d’autres peuvent être généralisées. Un client peut avoir une connexion internet instable qui rend l’installation compliquée chez lui, une image Docker peut aussi avoir été supprimée par son propriétaire. Nécessaire au bon déroulé de l’installation, le playbook nous informera de l’incident et le DevOps chargé de l’installation du client devra procéder à des corrections pour solutionner l’incident. Dans ce cas, la procédure est de comprendre l’erreur rencontrée, de procéder aux corrections adéquates, de tester la solution sur une plateforme de développement et de publier le changement. Cette publication est appelée “Hotfix” ou “Mise à jour technique de correctif” en français. À la fin de l’installation, les différents playbooks affichent tous un état de sortie. Si ceux-ci sont tous en succès, alors l’installation est terminée.
Reveelium étant installé chez le client, nous allons pouvoir le mettre en service. Pour cela, nous allons procéder aux mêmes changements que ceux décrits dans la phase d’ajout d’un client sur une plateforme mutualisée. Nous allons ajouter le nom du client, les règles de détection par défaut et la configuration des entrées de logs.
Le logiciel étant maintenant configuré convenablement, nous allons procéder à une série de tests qui visent à vérifier le bon fonctionnement de l’ensemble du logiciel. Celui-ci étant complexe, nous avons un processus de vérification de chacune de ses activités (collecte des logs/analyse des logs/fonctionnement de l’intelligence artificielle/etc.). Cette phase de test peut durer plusieurs heures selon le nombre d’opérations de correction à effectuer.
Le logiciel étant désormais opérationnel, nous allons pouvoir intégrer la plateforme dans notre logiciel de supervision. Ce logiciel nous permet de vérifier automatiquement et de manière continue l’état des Reveelium en production. Cette étape permet également d’avoir une seconde vérification de l’infrastructure. Si un problème est trouvé par la supervision, cela signifie que l’étape de vérification n’a pas été réalisée avec succès.
La phase d’installation du logiciel par l’équipe d’infrastructure étant terminée, nous allons communiquer les informations d’accès (URL, IP, comptes utilisateurs et mots de passe) à l’équipe SDM qui a pour responsabilité de transmettre ces informations au client. Par la suite, nous informons l’équipe Build qui va gérer les règles déployées sur la plateforme en adéquation avec les logs qui seront reçus. Enfin, nous informons par mail les équipes infrastructure et SOC que la plateforme a été correctement ajoutée.
7.5 – Réalisation de la mise à jour de Reveelium
J’ai intégré l’équipe Reveelium en septembre 2022 quand Reveelium 11.0 venait tout juste d’être finalisé. Par conséquent, les clients possédaient majoritairement Reveelium à la version 10.0. En amont de la sortie officielle, un plan de mise à jour a été préparé par notre responsable technique avec le soutien de l’équipe SDM qui permet notamment d’ apporter un point de vue très intéressant dans le choix de l’ordonnancement des clients à mettre à jour.
Les mises à jour de Reveelium entraînent une coupure de service pleine (perte totale de la collecte des logs) d’une durée de plusieurs heures et une coupure partielle d’une durée d’une semaine, car certaines parties du logiciel ne sont pas pleinement opérationnelles. Reveelium est un logiciel qui est complexe à mettre à jour. Son architecture étant altérée d’une version à l’autre, l’adaptation des playbooks pour prendre en compte les versions précédentes est réalisée durant toute la phase d’écriture de la nouvelle version du logiciel. J’ai eu pour responsabilité d’ajouter un ensemble de conteneurs supplémentaires développés par un membre de l’équipe Reveelium. Ce changement dans les Playbooks de Reveelium ne causant pas de modification d’une infrastructure passée, je n’ai pas eu à intégrer des tâches permettant de procéder à une mise à niveau qui aurait été nécessaire pour donner au logiciel la possibilité d’être mis à jour sans causer de perte de données. Adapter un Playbook signifie l’empêcher de réaliser certaines actions non désirées.
Nous avons besoin de l’accord d’un client pour procéder à la mise à jour du logiciel. Après avoir reçu son accord, nous lui communiquons une mise à jour des prérequis au bon fonctionnement du logiciel pour que celui-ci se conforme à la nouvelle architecture. Il s’agit principalement de changements mineurs à réaliser sur les pare-feux. Pendant ce temps, nous devons adapter les informations du client dans nos différents Repository Git en adéquation avec les nouvelles normes et réaliser une sauvegarde des parties sensibles de Reveelium. Toutes les bases de données et les fichiers de configuration sont sauvegardés à froid (sauvegarde externe au logiciel).
Nous procédons ensuite au lancement des playbooks d’installation de Reveelium. Ces playbooks se comportent différemment d’une simple installation quand il s’agit d’une mise à jour. Ainsi, certaines opérations supplémentaires sont réalisées, comme l’exécution de scripts de migration ou la suppression de configurations inutiles sur le disque. Un suivi en temps réel de l’état des playbooks est toujours réalisé. Lors des mises à jour, nous rencontrons toujours des problèmes. C’est pourquoi, des cellules de crise sont organisées pour répondre aux incidents en temps réel. Pour anticiper au mieux ces cellules de crise, nous réalisons des tests de mise à jour sur des environnements techniques prévus à cet effet, cependant la réalité de la gestion des infrastructures entraîne toujours des imprévus. Il faut ainsi répondre aux problèmes rencontrés avec grande attention. Notre équipe et nos responsables techniques sont toujours disponibles pour nous assister en cas de besoin. J’ai personnellement réalisé quelques mises à jour et assisté à la mise en œuvre de beaucoup d’autres. Après cette phase, nous procédons aux vérifications du bon fonctionnement du logiciel et nous contactons le client exactement de la même manière que lors d’une installation classique afin de l’informer du succès de l’opération.
7.6 – Installation d’un collecteur chez un client
Reveelium collecte les logs, ces logs peuvent être envoyés par les serveurs individuellement ou bien centralisés par ce qui s’appelle un collecteur.
L’ANSSI (Agence National de la Sécurité des Systèmes d’Information) recommande l’emploi d’un collecteur de logs. Cette recommandation est justifiée par l’apport en matière de cybersécurité qu’engendre l’ajout d’un collecteur en entreprise. Nos clients, tous à la recherche de solutions sécurisées, sont souvent favorables à cet ajout dans leurs environnements.
Je vais vous partager l’installation d’un collecteur que j’ai réalisé chez un client très sensible qui utilise une solution mutualisée de Reveelium et qui s’est montrée favorable à l’emploi d’un concentrateur au sein de son entreprise. Cette information a été transmise par l’équipe commerciale à l’équipe des SDM (Service Delivery Management). Les SDM ont ainsi créé un ticket dans notre logiciel de gestion du projet Reveelium. M’étant montré particulièrement intéressé par cette tâche, mon responsable technique m’en a confié la réalisation. Pour le convaincre, j’avais évoqué mes motivations à l’idée d’opérer chez un client aussi sensible, mais également de l’intérêt que cela avait pour moi, car je n’avais jamais réalisé une telle opération chez un client.
Avant d’accomplir la moindre action chez le client, j’ai réalisé une phase de préparation. Cette phase comprend toutes les actions que j’ai réalisées préalablement au jour de l’installation concrète pour le client. Cette étape était déterminante pour le succès de l’opération. Bien que je n’avais jamais réalisé l’opération d’installation du collecteur chez un client, le logiciel à installer ne m’était pas inconnu, car c’était celui utilisé pour réaliser la collecte des logs de Reveelium. J’ai pu me lancer dans cette installation, car j’avais réalisé de nombreuses tâches d’administration système sur ce logiciel. La phase préparatoire s’est déroulée en trois étapes : acquisition, documentation, tests et validation. Pendant la phase d’acquisition, j’ai consulté les différentes documentations du logiciel pour me familiariser avec son installation. J’ai également collecté l’ensemble des prérequis techniques nécessaires au bon déroulé de l’installation. Ces prérequis comprenaient la liste des flux (réseaux) nécessaires à l’installation du logiciel, mais aussi les permissions des différents dossiers de configuration, les logiciels dont il dépend et enfin les configurations à réaliser dans Reveelium. Après avoir réalisé la phase de préparation, j’ai procédé à la rédaction d’une documentation pour synthétiser l’ensemble des informations précédemment collectées. Cette documentation se devait d’être simple pour être facilement utilisable. Après avoir réalisé ces documents, j’ai procédé à l’installation du logiciel sur une plateforme de tests. Le test serait concluant uniquement si un log envoyé sur le collecteur était bien collecté par Reveelium.
Ce test m’a permis de corriger et d’améliorer ma documentation, car j’ai pu vérifier le fonctionnement des commandes que j’avais prévues pour la génération du certificat chargé de sécuriser les échanges entre le collecteur et Reveelium. Ce fut une phase très enrichissante pour moi, car j’ai pu approfondir ma compréhension du fonctionnement des certificats. La dernière phase réalisée fut la vérification de ma documentation par mon responsable technique. Cette étape était très intéressante, car son retour m’a apporté son expertise sur certains détails de l’installation. Je m’étais notamment trompé sur la version du logiciel ce qui entraînait des problèmes techniques et juridiques. Grâce à son analyse, j’ai pu apporter des changements sur ma documentation et être ainsi prêt pour procéder à l’action chez le client.
Suite à ces modifications, j’ai pris contact avec le client et lui ai proposé différents créneaux horaires pour réaliser une vidéoconférence. Cette proposition a été envoyée par mail dans lequel se trouvaient également des informations liées aux différents flux nécessaires au bon déroulé de l’installation et des tests. Après avoir convenu d’un rendez-vous, nous avons réalisé un premier entretien dans lequel j’étais le seul représentant d’ ITRUST. Le client m’a présenté le serveur qui allait accueillir le collecteur que j’allais installer.
Après cette présentation, nous avons procédé à une vérification du fonctionnement des flux en lien avec l’accès à certains serveurs Web (pour installer des logiciels) mais concernaient aussi les interactions entre le collecteur et le logiciel Reveelium hébergé chez ITRUST. Durant cette étape, je n’avais pas la “main” sur le serveur. J’ai dicté les différentes commandes au client qui me partageait son écran. Nous avons pu constater que certains flux n’étaient pas fonctionnels. Après avoir inventorié l’état des flux, nous avons procédé aux commandes d’installation du collecteur avant d’envoyer (de manière sécurisée) les certificats au client. Je lui ai indiqué où les envoyer précisément dans le serveur. J’ai vite compris qu’une seconde réunion serait nécessaire pour rendre fonctionnel le collecteur, car avec les problèmes de flux rencontrés, il ne nous serait pas possible d’aller plus loin dans la configuration à ce moment-là.
Après cette première réunion, j’ai contacté le datacenter hébergeant la plateforme Mutualized qui devait accueillir les logs du client, pour que l’on vérifie que les flux soient bien ouverts. Le datacenter nous a informé que les flux n’étaient pas fonctionnels et ils ont réalisé l’ouverture des flux.
Après avoir fait fonctionner les flux, nous avons pu nous entretenir une nouvelle fois par mail avec le client. Cette fois-ci, le client m’a donné l’accès en direct au serveur pour que je puisse réaliser la configuration et l’ensemble des tests nécessaires au bon fonctionnement du collecteur. J’étais ainsi connecté en temps réel à l’infrastructure du client. Quand nous sommes dans ce cas de figure, il est très important d’être conscient de l’impact sur le système d’information du client que peuvent engendrer certaines actions, c’est pourquoi j’ai redoublé de vigilance pour éviter toute action non mesurée. Pendant cette réunion, j’ai d’abord vérifié les flux manquants. Ceux-ci étaient désormais tous fonctionnels. J’ai configuré le logiciel et résolu des incidents de permission. Pour cela, j’ai lu les journaux de logs du logiciel et réalisé différentes actions en lien avec les erreurs que j’ai pu rencontrer, des problèmes de permission de certificats, mais aussi des problèmes dans la configuration du logiciel. J’ai facilement corrigé ces anomalies, car j’ai l’habitude de configurer ce logiciel. J’ai ensuite réalisé un test d’envoi de logs pour vérifier le bon fonctionnement de la configuration réalisée. Ce test a été un succès, cependant, avec le client, nous avons tenté d’intégrer directement un serveur Windows, ce test a échoué. J’ai réalisé différents tests pour confirmer que le problème ne venait pas du collecteur que je venais d’installer. J’ai alors effectué une analyse de trame en temps réel pour vérifier si le serveur Windows arrivait à échanger avec le collecteur. Mon investigation a démontré que l’incident de communication venait de la configuration des firewall situés chez le client, car le serveur ne recevait aucun trafic. Cette étape de l’installation n’étant pas à charge d’ ITRUST, j’ai simplement synthétisé au client les différents flux à ouvrir pour que le problème soit solutionné. J’ai enfin procédé à une communication auprès de l’équipe SDM (Service Delivery Management). Cette équipe étant responsable des échanges avec le client, je dois lui faire des comptes-rendus après chaque réunion réalisée avec un client. Cela lui permet de connaître l’état d’avancée des différentes actions menées chez le client. Cette notification a aussi été transmise auprès de l’équipe Revelium Infrastructure.
Quelques jours après notre seconde réunion, j’ai constaté que le client avait solutionné son problème de flux, car nous recevions les logs sur la plateforme mutualisée.
8 – FIN DU PROJET ET PERSPECTIVES D’AVENIR
La MCO (Mise en Condition Opérationnelles) d’un logiciel n’a jamais réellement de fin. Au fil des années, le logiciel est mis à jour et des problèmes et bugs sont découverts. Concernant Reveelium, sa version “12” a été annoncée pour mars 2024. Cette nouvelle version comprendra des améliorations d’architecture et l’ajout d’un grand nombre de fonctionnalités permettant de simplifier la compréhension des utilisateurs et d’améliorer la puissance du logiciel. Mon travail de DevOps sera de mettre à jour l’ensemble des Reveelium tout en continuant d’améliorer les playbooks.
L’avenir de Reveelium est très prometteur notamment grâce à l’intégration d’ ITRUST dans le groupe ILIADE (filiale de Free et de Free pro). Le monde de la cybersécurité se complexifie de jour en jour et Reveelium a déjà trouvé sa place dans le marché de la Cybersécurité en France et en Europe.
9 – CE QUE JE RETIENS
ITRUST m’a offert la possibilité d’exercer un métier qui me passionne. Je retiendrai de cette alternance la très grande satisfaction d’avoir pu travailler pour un logiciel aussi complexe et passionnant. C’est la première fois que je travaille aussi longtemps pour une entreprise. Je n’avais par le passé réalisé que des stages de maximum trois mois et demi. Au total, 24 mois d’alternance à 75 % chez ITRUST m’auront permis d’approfondir mes connaissances techniques et humaines. J’ai pu avec aisance trouver ma place au sein de l’entreprise et je souhaite exprimer aux équipes d’ ITRUST toute ma reconnaissance pour ces deux années. Ayant auparavant principalement exercé comme administrateur système et réseaux, j’ai beaucoup appris d’ ITRUST en matière d’édition de logiciel, de gestion de projet et de relation clientèle.