Qu’est-ce que la dérive de configuration ?

Dans une certaine mesure, la dérive de configuration est inévitable au cours du cycle de vie d’un système. Elle peut être causée par des modifications manuelles apportées au réseau, qui affectent la façon dont ses composants interagissent les uns avec les autres, ou par des outils automatisés qui modifient les paramètres d’une manière que les administrateurs n’avaient pas prévue. En l’absence d’une documentation appropriée, des changements incompatibles ou préjudiciables peuvent être apportés lorsque d’anciens administrateurs partent et que de nouveaux arrivent.

Un exemple classique de dérive de configuration est le cas où un administrateur applique un correctif à un serveur dans un environnement à charge équilibrée, mais pas aux autres. Même si le système continue à fonctionner normalement pendant un certain temps, des problèmes peuvent survenir par la suite. Le serveur corrigé peut utiliser une nouvelle bibliothèque incompatible avec les futures mises à jour du réseau qui reprennent les conditions initiales, ce qui peut entraîner des pannes et des inefficacités.

La dérive de configuration ne constitue pas seulement une menace pour les performances. Les systèmes qui s’éloignent des paramètres prévus peuvent devenir plus vulnérables aux acteurs malveillants et aux violations de données. Par exemple, si les règles du pare-feu ne sont pas mises à jour au fur et à mesure que de nouvelles ressources sont ajoutées à un réseau, les pirates peuvent s’y infiltrer sans problème.

La dérive de configuration peut également affecter l’état de conformité. Une organisation peut échouer à un audit si la documentation du réseau décrit un ensemble de paramètres de sécurité mais que l’environnement réel est différent.

Les professionnels du DevOps et les administrateurs système ont des outils à leur disposition pour éviter les mauvaises configurations et lutter contre les dérives de configuration. Les outils d’infrastructure en tant que code (IaC) tels que Terraform relient la configuration du réseau à un fichier de configuration qui sert de référence. Les fichiers de configuration permettent de garantir que les nouvelles ressources réseau sont automatiquement fournies en bon état, réduisant ainsi les risques de dérive

Les outils d’observabilité donnent aux administrateurs une visibilité sur les indicateurs, les journaux et les traces, ce qui les aide à repérer les dérives de configuration au moment où elles se produisent et à appliquer des correctifs. L’infrastructure immuable limite les dérives en éliminant les serveurs obsolètes au lieu d’appliquer des correctifs. La dérive de configuration est également gérée par des outils de gestion de configuration tels qu’Ansible.

Les dérives de configuration sont le plus souvent causées par des modifications manuelles des configurations du système, un dysfonctionnement de l’automatisation, des problèmes au niveau organisationnel qui créent des incohérences, ou une combinaison de ces tous facteurs.

Les correctifs manuels ponctuels sont la principale cause de la dérive de configuration.

Un « correctif », ou une résolution appliquée en dehors du calendrier normal des mises à jour, peut résoudre des problèmes immédiats et urgents, tels qu’un serveur réglé sur une mauvaise valeur de timeout et qui plante donc sans cesse. Mais à terme, ce type de modification de configuration peut engendrer des dysfonctionnements du système :

• Une mise à jour ultérieure du système qui ne tient pas compte de ce correctif pourrait le remplacer, ramenant le bug initial.
  
  
• Le correctif peut inclure une dépendance non prise en compte et incompatible avec les futures mises à jour du réseau.
  
  
• Un identifiant administrateur temporaire créé pour le correctif peut rester valide, devenant ainsi une responsabilité supplémentaire en matière de sécurité.

Il existe des façons quasi illimitées dont l’erreur humaine, ou simplement les conséquences imprévues, peuvent détourner le système de l’état dans lequel il « devrait » se trouver. Même de petites modifications peuvent s’accumuler au point que l’environnement de production réel ne ressemble guère à celui du dépôt, car il est truffé de bugs et de risques de sécurité.

En l’absence de tests et de contrôles appropriés, les mises à jour et les processus automatisés peuvent éloigner d’importantes ressources du réseau de leur configuration prévue.

La qualité de l’automatisation dépend de sa source d’information. Par exemple, si un outil IaC s’appuie sur des fichiers de configuration obsolètes pour créer de nouveaux serveurs, il risque de perturber l’environnement. Les mises à jour logicielles automatisées des applications et des systèmes d’exploitation tels que Microsoft Windows peuvent s’appliquer à différents moments sur les serveurs, ce qui peut entraîner une divergence potentiellement préjudiciable. De plus, ces mises à jour peuvent ne pas fonctionner correctement avec l’architecture réseau unique d’une entreprise, ce qui entraîne d’autres problèmes.

Même les outils destinés à gérer la configuration peuvent entraîner des dérives si les circonstances s’y prêtent. Par exemple, des problèmes de connectivité pourraient amener Ansible à appliquer une mise à jour de configuration inégale, laissant un serveur inchangé. Ce serveur va progressivement s’éloigner de son environnement, ce qui pourrait provoquer des pannes de service.

Au niveau organisationnel, des problèmes liés au pipeline d’intégration et de livraison continues (CI/CD) et aux pratiques DevOps peuvent entraîner des problèmes de configuration.

Lorsque les équipes de développement, d’exploitation et de sécurité sont cloisonnées, la confusion, la mauvaise communication et le dépannage inadéquat sont inévitables. En plus des pratiques techniques divergentes, les équipes au sein d’une organisation peuvent avoir leurs propres pratiques de gestion du changement. Certaines organisations ne disposent pas du tout de processus formels de gestion du changement.

L’absence de pratiques établies et claires pour apporter et documenter les modifications peut entraîner des journaux de modifications incohérents, des modifications non autorisées et des workflows d’approbation non appliqués. En fin de compte, les administrateurs, les développeurs et les ingénieurs peuvent contourner entièrement le processus de gestion du changement.

La dérive de configuration présente des risques importants pour la sécurité, les performances et la conformité d’un système.

La dérive de configuration peut considérablement augmenter la surface d’attaque d’une entreprise en créant des exceptions aux politiques de sécurité qui restent inconnues des administrateurs et donc non corrigées.

Par exemple, un identifiant créé pour appliquer un correctif peut être laissé en place et être accessible aux pirates qui pourraient l’utiliser à des fins malveillantes. De même, un ingénieur peut faire une exception à une règle de pare-feu qu’il ne reviendra jamais fermer, ce qui affaiblit considérablement la posture de sécurité globale du réseau. Les développeurs peuvent activer une application avec des contrôles de sécurité incomplets à des fins de test et ne jamais la désactiver, créant ainsi une autre vulnérabilité que les acteurs malveillants peuvent exploiter.

De même, chaque nouvelle application, terminal ou autre ressource ajouté à un système peut entraîner une dérive de configuration si les contrôles de sécurité appropriés ne sont pas appliqués. Par exemple, ajouter un nouveau serveur sans configurer le système de détection et réponse des terminaux (EDR) proprement dit peut créer un maillon faible. Une simple erreur dans la configuration des microservices peut entraîner l’entrée d’un grand nombre d’actifs non protégés dans le réseau.

Outre la cybersécurité, les performances du réseau constituent le risque le plus important et le plus coûteux lié à la dérive de configuration.

Prenons l’exemple d’un serveur qui subit un trafic plus important que ses homologues. Il est possible que la taille du pool de connexions de ce serveur soit augmentée par un correctif afin d’améliorer les performances. Comme ce serveur se trouve derrière un équilibreur de charge, ce dernier définit automatiquement une politique visant à augmenter le trafic dans cette direction afin de répartir la charge du serveur de manière plus homogène.

Lorsque le serveur est remplacé lors d’un nouveau déploiement, le correctif qui a augmenté son pool n’est plus en place, et le serveur tombe en panne en raison du trafic supplémentaire. Le correctif initial appliqué pour accélérer le trafic constitue la dérive. Lorsqu’elle n’est pas prise en compte, toute modification ultérieure du réseau peut entraîner des temps d’arrêt coûteux jusqu’à ce que la cause soit identifiée.

La dérive de configuration peut amener une organisation à ne plus se conformer sans même en être consciente. Lorsque l’état d’un réseau diverge de ce qu’une organisation « pense » faire — ou de ce que sa documentation indique — l’organisation court un risque de non-conformité. Même si la non-conformité n’est pas intentionnelle, l’organisation peut se voir infliger des amendes et des frais.

Prenons l’exemple de la loi HIPAA (Health Insurance Portability and Accountability Act). L’HIPAA exige que les entreprises utilisent certaines méthodes de chiffrement pour protéger les données sensibles en transit et au repos.

Supposons qu’un administrateur ait besoin d’intégrer un système hérité à son réseau conforme à la loi HIPAA, et que ce système hérité utilise une méthode de chiffrement obsolète. Si cette méthode de chiffrement n’est pas prise en compte, l’intégration rendra l’organisation non conforme à l’HIPAA.

La détection des dérives, qui consiste à suivre les modifications apportées au réseau et à identifier les écarts par rapport à l’état prévu, nécessite une combinaison d’outils, notamment l’infrastructure en tant que code, GitOps, l’infrastructure immuable et l’observabilité.

L’infrastructure en tant que code, qui consiste à approvisionner et à gérer l’infrastructure informatique en utilisant des scripts plutôt que des processus manuels, est l’un des outils les plus puissants pour la gestion des dérives de configuration.

L’IaC permet de lutter contre la dérive de la configuration en transformant l’état souhaité du réseau en un code dont la version est contrôlée et auquel chaque composant du réseau peut être comparé.

Par exemple, dans Terraform, lorsqu’une modification est apportée, l’outil IaC compare le fichier d’état (la vue la plus récente du réseau sur la plateforme) aux fichiers de configuration déclarés, c’est-à-dire les fichiers qui indiquent ce que « devrait » être le réseau. Terraform résout ensuite les divergences entre le fichier d’état et la configuration déclarée en mettant à jour l’infrastructure pour qu’elle corresponde au fichier de configuration, ce qui réduit les risques de dérive.

Lorsque les entreprises imposent un contrôle d’accès strict aux outils d’IaC, elles peuvent réduire encore davantage les possibilités de dérive. En limitant l’accès à l’IaC aux seules personnes autorisées qui en ont besoin, les entreprises limitent la possibilité de modifier les configurations de l’infrastructure en général. Et lorsque des modifications sont apportées, elles passent par le processus de contrôle de version de l’IaC, ce qui réduit encore le risque de dérive.

GitOps est une pratique DevOps qui utilise le référentiel open-source Git comme source d’information unique pour les fichiers de configuration. GitOps aide de nombreuses organisations à déployer l’IaC avec un maximum d’efficacité et de sécurité.

Les pratiques GitOps se concentrent sur l’utilisation de l’automatisation pour valider l’état du réseau par rapport à l’état souhaité stocké dans Git en temps réel. Les plateformes GitOps peuvent scanner les réseaux en continu, détecter les erreurs de configuration, les signaler ou y apporter des correctifs, rendant ainsi temporaire toute dérive. Et comme toutes les modifications sont liées à Git, elles sont toutes suivies avec un auteur, un horodatage et une description.

Une infrastructure immuable atténue la dérive de configuration en réduisant considérablement le nombre total d’opportunités de modifier la configuration du réseau.

L'infrastructure immuable consiste à remplacer, et non à modifier, les serveurs et autres ressources informatiques lorsque des changements sont nécessaires.

Supposons, par exemple, qu’un serveur ait besoin d’une mise à jour de sécurité. Au lieu d’appliquer la mise à jour au serveur existant, les administrateurs le déclasseraient et le remplaceraient par un nouveau serveur mis à jour.

L’infrastructure immuable s’appuie sur les outils de l’IaC pour déployer automatiquement de nouveaux systèmes tels que décrits dans le code lorsque des changements sont nécessaires. Chaque nouveau composant ajouté au réseau correspond automatiquement à l’état souhaité.

Les trois pratiques IaC, GitOps et infrastructure immutable sont étroitement liées. Les outils IaC définissent les images des composants réseau tandis que GitOps facilite le déploiement, constitue un enregistrement complet du réseau et prévient les incohérences.

Les trois piliers de l’observabilité (journaux, indicateurs et traces) ont également un rôle à jouer dans la prévention des dérives de configuration.

Une plateforme d’observabilité, par exemple, pourrait détecter que les indicateurs sur un serveur (comme les temps de réponse ou l’utilisation du processeur) divergent significativement de ceux des serveurs qui devraient avoir des configurations identiques. Cette divergence est un symptôme potentiel de dérive. De même, les écarts dans les journaux des taux d’erreurs pour chaque serveur peuvent indiquer une dérive si un serveur présente un nombre anormalement élevé d’erreurs d’un certain type. Les traces de la chaîne d’appel d’une application peuvent également révéler des emplacements présentant des écarts et des dérives.

La détection des dérives consiste à comparer l’état réel d’un réseau à l’état souhaité afin de détecter les écarts. Bien que l’on puisse théoriquement effectuer ce processus manuellement, de nombreux fournisseurs de cloud et d’IaC proposent des outils dotés d’une fonctionnalité de détection des dérives, ce qui permet d’automatiser et de rationaliser un projet qui prendrait beaucoup de temps.

Par exemple, AWS Config enregistre les configurations des modules AWS, signale tout ce qui s’écarte de l’état souhaité et aide à corriger les dérives. Les évaluations de santé de Terraform vérifient que les réglages réels de l’infrastructure correspondent à ceux enregistrés dans le fichier d’état de l’espace de travail et valident continuellement que les ressources satisfont aux vérifications requises définies dans les configurations du système.

Terraform Enterprise compare les conditions au fichier d’état, ou met à jour le fichier d’état pour refléter les conditions réelles, révélant ainsi les changements. Des outils de gestion de configuration tels qu’Ansible et Puppet peuvent également être utilisés pour la détection de dérive.