MCO et MCS d’un parc de VM de grande entreprise

1. Introduction

1.1 Contraintes des grands systèmes d’information en production

Assurer disponibilité, sécurité et bon fonctionnement d’un grand système d’information (SI) en production ne vient pas sans son lot de contraintes :

• Augmentation de la complexité : la taille d’un système d’information augmente chaque année qu’importe la taille de l’entreprise. Cela s’accompagne souvent d’une forte fluctuation, à la hausse comme à la baisse des machines gérées, notamment grâce à la démocratisation du cloud computing et des conteneurs. La quantité et la complexité des technologies augmentant également, l’ensemble du système d’information se complexifie petit à petit.
• Hétérogénéité des systèmes : le SI de production possède son propre cycle de vie, le plus souvent sur des temps longs. Sans entrer frontalement sur le sujet de l'obsolescence des systèmes, de la nécessité d’innovation et du time to market de nouvelles technologies, la réalité confronte généralement les responsables d’infrastructures et leurs équipes à des systèmes extrêmement hétérogènes. Certains systèmes doivent fonctionner sur plusieurs années (voire décennies dans un contexte militaire ou industriel), alors que d'autres doivent se renouveler constamment. De plus, les systèmes d’exploitation peuvent énormément varier (Linux, Windows, AIX, etc.) et plus encore dans leurs versions. Enfin, chaque système fournit des services extrêmement diversifiés : frontal web, serveur d’impression, poste de travail… Le SI est donc composé de multiples variations et d’exceptions qui rendent sa gestion difficile.
• Hétérogénéité des équipes : une production informatique nécessite la collaboration de différentes équipes ayant des compétences, des cultures et des besoins différents. Sécurité opérationnelle, responsable applicatif, administrateur système, techniciens de support… Autant d’acteurs qui apportent leurs expertises pour le bon fonctionnement des systèmes, mais qui peuvent également introduire des besoins et des contraintes antagonistes et donc hétérogènes. La culture devsecops a largement contribué à améliorer la situation, mais tout le monde ne peut pas être expert de tous les outils et tous les domaines.
• Standards et procédures : une DSI répond à un ensemble d’exigences de qualité et de sécurité. La gestion du SI doit donc suivre un ensemble de règles et de procédures, dont le suivi et l'audit de conformité aux standards de sécurité comme ISO 27 001 ou PCI-DSS, mais également aux règles et standards internes. Si l’application et le contrôle de ces standards ne sont pas automatisés, il en résulte souvent des dérives et une lourde charge pour les équipes. Comité d’approbation des changements, traçabilité et suivi des incidents, audit et reporting… Autant de processus qui deviennent des contraintes dans la gestion du SI pour les équipes opérationnelles.
• Criticité du SI et budgets en tension : dans la majorité des cas, le SI d’une entreprise est aujourd’hui indispensable à son activité. En cas d’incident, le métier est donc directement impacté. Pourtant les infrastructures reçoivent peu d’investissements. Il faut bien souvent attendre un incident majeur pour que la DSI s’y investisse humainement et financièrement. Pour quelles raisons ? Car les infrastructures étant invisibles du métier, elles font face à des contraintes budgétaires où le retour sur investissement doit être nécessairement visible et clair pour chaque projet.

Bref, une grande production informatique possède de nombreuses contraintes avec des enjeux impactant directement le bon fonctionnement de l’entreprise. Et travailler ces environnements complexes dans une dynamique d’agilité, le tout sur des systèmes hétérogènes, peut être éprouvant pour les équipes en charge du maintien de la sécurité et de la disponibilité des plateformes. C’est là qu'interviennent le MCO et le MCS.

1.2 Le Maintien en Condition Opérationnelle et de Sécurité

C’est la partie de l’iceberg cachée du service informatique ; cachée au métier et au comité exécutif, mais qui pourtant différencie une production fonctionnelle d’un système d’information erratique impactant toute l’entreprise. Le Maintien en Condition se décline aussi bien pour la Sécurité (MCS) que pour l’Opérationnel (MCO). Dans les deux cas, il s’agit d’un ensemble de méthodes et de procédés qui garantissent respectivement un niveau de sécurité minimum (application du standard de sécurité, suivi et correction des vulnérabilités, détection des intrusions…) et un niveau de service minimum (disponibilité des services critiques, accès garanti aux systèmes, correction des problèmes...).

Le MCO et le MCS permettent ainsi d’avoir une visibilité sur l’ensemble des systèmes et des couches techniques, de détecter rapidement des anomalies et de les corriger. L’objectif est de garantir qu’une stratégie est bien déployée et maintenue dans le temps. L’automatisation de ces processus est donc à privilégier.

À défaut de solutions d’automatisation performantes et adaptées, le MCO et le MCS reposent sur des processus documentés, testés et maintenus régulièrement (par exemple via un Plan de Continuité et de Reprise Informatique). Une approche en continu reste cependant indispensable au vu des contraintes en volumétrie, en agilité et en hétérogénéité explicitées précédemment. Pour les couches systèmes, middleware et applicatives, ce sont les outils de configuration management (gestion des configurations) comme Rudder, Puppet ou Chef qui ont apporté ces solutions depuis 10 ans.

2. Usage du Configuration Management

Le Configuration Management est devenu un standard dans le maintien en condition opérationnelle et de sécurité des grandes productions informatiques. Dans la suite de l’article, nous nous concentrerons sur la partie opérationnelle (le fonctionnel étant plutôt destiné aux product owner et équipes applicatives), avec un focus particulier sur la gestion des machines virtuelles (VM). La majorité des SI en production est en effet composée de VM. Les enjeux et contraintes de ce type d’environnement, y compris en cloud hybride, sont suffisamment polyvalents pour servir le propos de cet article.

2.1 Définition

Le Configuration Management est une ingénierie système issue du monde industriel et militaire, dont l’objectif est d’établir et maintenir la consistance d’un produit, aussi bien sur un plan technique que fonctionnel. Appliqué au milieu informatique et logiciel, il permet de maintenir les systèmes dans un état défini en amont, en proposant des fonctionnalités d’inventaire, de déploiement, d’audit et de correction de ces systèmes, fondées généralement sur l’automatisation.

Comme beaucoup de technologies, le Configuration Management suit le « Cycle de la Hype » (illustré en figure 1). Il se situe actuellement plutôt en fin de phase dite d’illumination. C’est donc une technologie mature, principalement en ce qui concerne le MCO. Le MCS s’étant plus récemment démocratisé auprès des équipes opérationnelles, seuls les outils les plus récents intègrent des notions utiles aux besoins de sécurité : audit, conformité, suivi de référentiel, etc.

Le principe de fonctionnement du Configuration Management moderne s’appuie en grande partie sur les travaux de Mark Burgess débutés à la fin des années 90 et formalisés autour de la Théorie des Promesses en 2004 [1]. Afin d’avoir une confiance complète sur l’ensemble de son parc, le Configuration Management repose sur une approche déclarative d’un état cible : on déclare le comportement attendu des systèmes que l’outil va devoir observer. Autrement dit, il s’agit d’une promesse que l’outil va s’atteler à respecter. Il met ainsi en exergue la cohérence de l’état des machines avec cette promesse, montrant tous les changements prévus et imprévus.

Ce principe est essentiel en MCO et MCS puisqu’il permet de limiter l’impact de l’hétérogénéité des systèmes. En voici un exemple : pour notre état cible, nous souhaitons que le service SSH ne permette pas d’accès Root, donc que PermitRootLogin No soit déclaré sur l’ensemble des systèmes. L’outil ira alors s’en assurer, qu’importe le système sous-jacent, en observant sa bonne conformité ou non au moment de sa vérification. Si c’est correct, tout va bien. Si c’est positionné sur Yes, alors l’outil corrigera automatiquement l’anomalie selon l’état cible souhaité et en fournira un rapport.

Les notions importantes du Configuration Management sont donc la déclaration d’état cible, ainsi que le système de promesses appliquées par idempotence (chaque exécution, qu’elle soit unique ou multiple, doit fournir le même résultat) à des agents autonomes.

2.2 Configuration Management & Continuous Deployment

Pourquoi ne pas parler d’Ansible ou Rundeck ? Ce sont des outils d'automatisation qui ciblent le Continuous Deployment (CD), moins bien dotés pour le MCO/MCS, en particulier à cause de leur approche procédurale et non continue, et de leur modélisation interne souvent moins poussée du SI.

Un outil d’orchestration comme Ansible est conçu pour de l’exécution unitaire : il exécute un playbook une fois sur un ensemble de nœuds. Bien sûr, on peut le détourner afin de lancer une exécution toutes les 5 minutes pour essayer d’atteindre un fonctionnement continu, mais on se heurte aux limites du modèle. Par exemple, sur un grand parc, la charge réseau des connexions SSH sera souvent rédhibitoire, et les zones isolées ne peuvent plus être maintenues en condition.

Les outils de Configuration Management, notamment grâce à leur agent, permettent de mieux répartir la charge et surtout peuvent continuer à maintenir les configurations même lorsqu’il n’y a plus de réseau. En revanche, les outils de CD sont très adaptés pour des scénarios de déploiement complexes. Ils sont donc tout à fait complémentaires et sont avantageusement utilisés de façon interconnectée.

2.3 Inventaire et classification en groupes des nœuds

Sans inventaire des systèmes (nommés usuellement « nœuds »), il est impossible de connaître ceux concernés par le Configuration Management. Il est en effet très difficile de gérer un système que l’on ne connaît pas : cela revient à ne pas avoir de carte du théâtre des opérations. En pratique, soit une base de données d’inventaire (CMDB) existe et est utilisable (donc à jour et avec suffisamment de données), soit l’outil apportera sa propre brique d’inventaire.

L’inventaire est souvent technique, listant par exemple l’adresse MAC du nœud, la version des logiciels installés, etc. Mais il peut également être fonctionnel et étendu à des informations comme l’appartenance à un cluster applicatif, à un niveau de service, etc. Avec ces caractéristiques opérationnelles, il devient vite nécessaire de pouvoir appliquer aux nœuds des tags ou des propriétés qui les définissent.

Ces données brutes d'inventaire vont permettre de classer et regrouper les nœuds en fonction des besoins opérationnels. Ils vont également permettre l'établissement de politiques compréhensibles. Ces groupes de nœuds peuvent être statiques ou dynamiques ; ce dernier choix étant préférable pour que la liste s'adapte aux évolutions rapides des infrastructures modernes. En d’autres termes, il s’agit à nouveau de préférer la déclaration d'intention au processus impératif.

On pourra par exemple définir un groupe représentant les nœuds en DMZ selon leur appartenance à un sous-réseau, plutôt que par une liste d'IP. De plus, il est nécessaire de prendre en compte très rapidement toutes les nuances applicables au système d’information. Les groupes sont en effet multidimensionnels et répondent à de nombreux critères comme leurs responsables, les applications, le niveau de sécurité, le client concerné, le type d’OS, la présence d’une vulnérabilité, etc. L’outil doit donc pouvoir gérer facilement des centaines de variations de groupe. Par exemple, dans Rudder il a été choisi de pouvoir créer des groupes à partir de critères se basant sur des opérateurs logiques et de composition d'autres groupes, formant des hiérarchies.

2.4 Création intelligente des configurations

La définition de l’état cible des nœuds se trouve bien sûr au cœur de l’usage de l’outil : c’est à cette étape que l’on spécifie ce qu’on souhaite auditer ou déployer. La mise en œuvre de « bonnes » configurations est une étape longue et complexe. L’objectif est de pouvoir obtenir une abstraction suffisante afin de bénéficier du levier de l’automatisation et d’avoir des règles compréhensibles et debuggables par des êtres humains, tout en étant suffisamment spécifique et paramétrable pour être applicable réellement sur le système d’information et son hétérogénéité.

L’industrialisation des configurations, via l’usage d’un unique template pour des milliers de machines, n’est souvent pas facilement applicable, car chaque nœud possède des nuances. Trouver un bon équilibre permet de limiter les erreurs et de garantir le bon fonctionnement du SI dans le temps, y compris lorsque les administrateurs de l’outil changeront et qu’ils auront besoin de comprendre ce qui est configuré.

L’outil doit intégrer un moteur dynamique pour décliner un état cible dans le contexte spécifique d’un nœud, et être capable de prendre en compte les éléments extérieurs, la nature des systèmes et les configurations souhaitées fournies par l’utilisateur. Cela permet de respecter le principe de séparation entre, d’une part, le code (au sens infrastructure-as-code) et d'autre part, les données de configuration (par exemple, l’adresse IP exacte du serveur de résolution DNS). Un article dédié au principe de séparation serait très intéressant, mais dans les grandes lignes, il faut retenir qu’il permet d’avoir des configurations définies par le code, dont les valeurs peuvent provenir de multiples sources (aux formats et origines variés), et établies à différents moments (en amont, lors du calcul de configuration, à l'exécution locale, etc.). L'outil doit aussi apporter une assistance à l’utilisateur et vérifier autant que possible les contraintes issues des interactions complexes, comme le fait qu'un paramètre n'a pas sa valeur surchargée de façon incohérente sur un système.

Un autre bénéfice de cette séparation est d’en faciliter l’usage. Le code permettant de configurer un service complexe (comme une application métier) peut être conçu par des experts de l’automatisation, alors que le paramétrage de l’application sur un serveur peut être effectué par le responsable applicatif.

L’outil est ainsi accessible à toutes les équipes, selon leur niveau d’expertise et leur besoin. De la même manière, la politique de sécurité peut être déclinée techniquement par les équipes opérationnelles, tandis que le RSSI pourra simplement obtenir le résultat : mon SI est conforme ou non à ma PSSI.

2.5 Contrôle, vérification et application des configurations

Dans un contexte de maintenance, il est essentiel de pouvoir remédier à une anomalie. Si l’état cible n’est pas conforme sur un nœud, il doit être mis en conformité : c’est ce qu’on appelle la remédiation. Elle peut être automatique ou nécessiter une validation - voire même être manuelle si l’on souhaite plus de contrôle. L’automatisation apporte en effet son lot de risques : si on peut tout réparer en même temps, on peut aussi tout casser.

Pour un maximum de contrôle, l’idéal est donc d’avoir un outil capable de :

• Fonctionner uniquement en mode audit pour mesurer l'écart par rapport à un état cible et que l’on peut basculer en mode remédiation si besoin (ces fonctionnalités sont appelées audit mode et enforce mode dans le logiciel Rudder).
• Pouvoir contrôler les mises en production, par exemple via un système de validation de changement. Si tous les éléments de configuration de l’outil sont bien versionnés, alors chaque changement sera analogue à une pull-request pour qu’il soit validé avant mise en production.

Un outil de Configuration Management bénéficie de l’avantage de fonctionner en continu, permettant ainsi de créer une rétroaction (ou feedback) rapide entre une modification et les conséquences de cette dernière : l'outil va pouvoir immédiatement indiquer si les nœuds impactés sont toujours « au vert ». Cette rétroaction rapide permet de réaliser des changements plus souvent, plus itératifs, et plus maîtrisés. L’équipe a ainsi confiance en sa capacité à maîtriser l’infrastructure et le processus. Elle connaît l’ensemble d’un système, puisqu’il est défini via l’outil, mais aussi l’ensemble des politiques qui lui sont appliquées. Et elle voit l'état réel de leur bonne (ou mauvaise) application sur les nœuds.

Si un système est modifié hors de l'outil (comme ouvrir temporairement un flux pour débugger un incident), l’outil corrigera automatiquement l'anomalie en documentant ce qu'il s'est passé.

Si l’outil ne fonctionne pas en continu, alors on se retrouve dans le syndrome habituel de la peur de l’impact. Par exemple, la peur de lancer un playbook qui n’a pas été exécuté depuis plusieurs mois. C'est le fameux syndrome du « pas de déploiement le vendredi » [2].

2.6 Visibilité contextuelle de l’état

« Abstraction is selective ignorance. » est une citation d’Andrew Koenig qui nous explique que l’on n’a pas besoin de connaître les moindres détails d'un système pour en créer un modèle qui apporte de la valeur, même s'il est par définition faux. Cela nous permet d’être plus attentifs aux éléments importants. Dans le cadre du Configuration Management, on ne peut pas se contenter d’une visibilité technique machine par machine. L’outil doit donc s’intéresser à l’état et à la sécurité de l’infrastructure dans son ensemble pour permettre la création d'une conscience situationnelle de l'état du SI.

Au-delà de la gestion de machines individuelles, il fournit donc une vision de plus haut niveau correspondant au socle système, unifiée et orientée métier, rendant visible l’état réel de l’infrastructure et du service rendu. L’idée est de pouvoir fournir suffisamment de contexte pour que les équipes puissent prendre les bonnes décisions puisque l’observabilité technique des logs ne suffit pas forcément : c’est l’ensemble de l’environnement qui permet de comprendre ce qui se passe sur le SI.

Pour obtenir cette visibilité haut niveau, l’outil Rudder a introduit la notion de Règle regroupant un ensemble d’états cibles et de groupes de nœuds. La règle SecNumCloud - Chap 12 - Production Clients permet ainsi de connaître, en un coup d'œil, le niveau de conformité du maintien en sécurité des systèmes clients via le chapitre SecNumCloud concernant la sécurité liée à l’exploitation. En cas de besoin, il reste possible de zoomer sur les détails de configuration pour un nœud donné.

Conclusion

Cet article a présenté succinctement les bonnes pratiques de gestion des configurations dans un objectif de maintien en condition opérationnelle et de sécurité d’un large parc constitué de machines virtuelles. L’avenir se porte sur l’amélioration des collaborations entre équipes de sécurité et équipes opérationnelles dans une pure approche SecOps ayant pour objectif :

• la co-construction des processus de vérification et d’implémentation des politiques de sécurité et de gestion de risque ;
• la co-définition des rétroactions et de l’observabilité afin de comprendre et d’agir face à un incident.

Cela passe notamment par des équipes pluridisciplinaires, mais aussi par des outils adaptés aux deux univers. Car non, un outil de détection des vulnérabilités n’est pas un bon outil de remédiation : en production, on n’applique pas simplement un script de mise à jour sur l’ensemble du SI. Et non, l’outil DevOps d’infra-as-code ne fournit peut-être pas assez de métriques compréhensibles pour permettre aux équipes de sécurité de pouvoir évaluer les risques correctement.

Références

[1] Wikipédia, page sur la théorie des promesses : https://en.wikipedia.org/wiki/Promise_theory

[2] Charity Majors, « Friday Deploy Freezes Are Exactly Like Murdering Puppies » : https://charity.wtf/2019/05/01/friday-deploy-freezes-are-exactly-like-murdering-puppies/