Comment détecter et prévenir la dérive de configuration

Comment détecter la dérive de configuration dans toute votre organisation

Quelle que soit l’approche de votre organisation en matière d’infrastructure — automatisée, manuelle, sur site, dans le cloud ou hybride — de petits changements quotidiens sont inévitables. Vos systèmes ont été conçus pour être utilisés et modifiés afin de répondre aux besoins internes et externes. Ils évoluent donc au fil du temps.

Lorsque plusieurs ingénieurs et équipes interviennent ponctuellement sur cette infrastructure sans suivre les protocoles adéquats, ces microchangements peuvent rapidement s’accumuler et créer des incohérences entre la configuration actuelle de votre système et sa configuration de référence. C’est ainsi que survient la dérive de configuration : des changements sont apportés de manière inappropriée, ce qui finit par poser des problèmes à votre infrastructure.

La dérive de configuration peut toucher tous les types d’infrastructure, mais les entreprises qui disposent d’environnements d’infrastructure as code (IaC) doivent relever plusieurs défis particuliers pour y remédier et la prévenir de manière proactive. Certaines causes sont limitées par défaut, car l’IaC offre des mesures telles que le contrôle de version, qui réduit le risque de déploiement d’un changement non documenté. Toutefois, la rapidité du provisionnement automatisé dans le cloud peut toujours entraîner d’autres problèmes. La dérive de configuration dans les environnements DevOps, CI/CD et autres environnements de développement automatisés peut notamment s’accumuler rapidement, tout simplement parce que les changements s’enchaînent à grande vitesse.

En définitive, dans l’IaC, la dérive se produit lorsque l’état actuel de l’infrastructure ne correspond pas à la configuration IaC codée. Les ingénieurs travaillent alors à partir d’une version obsolète de l’infrastructure, tandis qu’une version différente est en production.

Quelles sont les causes de la dérive de configuration ?

La dérive de configuration peut être provoquée par différents changements apportés à la structure de votre système. Parmi les causes les plus courantes, citons :

• Modifications manuelles du système. Lorsqu’une personne crée ou modifie manuellement des ressources en dehors de votre système IaC établi, par exemple Terraform ou CloudFormation, ces changements ne sont pas répercutés dans la configuration codée.

• Application authentifiée. Cela signifie que les microservices chargés d’effectuer des actions automatisées, comme lire un script ou écrire dans un bucket, ne fonctionnent pas comme prévu à cause d’un bug. Ces erreurs d’automatisation peuvent entraîner une dérive.

• Changements cachés ou invisibles dans l’IaC. Des changements inconnus désynchronisent les environnements IaC : un décalage apparaît entre ce sur quoi travaillent les ingénieurs et ce qui se passe réellement dans le système en production.

• Correctifs et mises à niveau. Pour publier de nouveaux correctifs ou de nouvelles mises à niveau, les ingénieurs doivent apporter au système des changements plus ou moins importants. Chacun de ces changements peut provoquer une dérive.

Que se passe-t-il lorsque la dérive n’est pas maîtrisée ?

La dérive de configuration peut entraîner de graves problèmes pour les équipes, en particulier celles qui utilisent l’IaC. En effet, lorsque l’état actuel de l’infrastructure ne correspond pas à la configuration IaC codée, les ingénieurs travaillent à partir d’une version obsolète de l’infrastructure, tandis qu’une version différente est en production. Plus l’écart entre ce que les ingénieurs savent du système et son état réel se creuse, plus la sécurité, les performances et la conformité du système se dégradent.

Risques de sécurité

Si elle n’est pas corrigée, la dérive peut entraîner de graves problèmes de sécurité et exposer vos systèmes aux attaquants. En effet, des changements ponctuels et non documentés peuvent créer des portes dérobées inconnues. Dans bien des cas, le véritable risque vient du fait que certains changements apportés au système passent inaperçus, laissant des vulnérabilités sans correction. Par exemple, la violation de données subie par Twilio en 2020 était due à une dérive de configuration d’un bucket S3. Un ingénieur a appliqué un correctif à un problème antérieur, mais a, ce faisant, rendu la configuration du bucket non sécurisée. Faute de détection et de mesures correctives pour rétablir la configuration sécurisée d’origine, la dérive est passée inaperçue pendant des années. Des attaquants ont fini par l’exploiter pour dérober les données personnelles des utilisateurs.

Problèmes de performances

La dérive de configuration ne crée pas seulement des vulnérabilités de sécurité : elle peut aussi nuire aux performances et provoquer des interruptions de service. Lorsque l’état actuel de votre infrastructure ne correspond pas au code IaC, cet écart peut entraîner un surprovisionnement des charges de travail, ainsi que des ressources et des processus mal optimisés. Toutes ces petites incohérences peuvent s’accumuler et provoquer de nombreux problèmes de performances.

Manquements à la conformité

L’IaC devrait servir de documentation vivante décrivant l’état actuel de votre système. Lorsque la dérive de configuration fausse les données IaC codées, les changements mineurs ne sont pas correctement pris en compte par vos politiques de sécurité. Imaginons qu’un ingénieur ouvre un port sans répercuter ce changement dans l’IaC. Même si ce changement est sans conséquence, il éloigne l’état actuel de votre système de celui défini dans l’IaC et les politiques de sécurité associées. Lors d’un audit, cela serait considéré comme un manquement à la conformité.

Comment détecter la dérive de configuration

Les pratiques de gestion de la dérive de configuration peuvent aider votre équipe à détecter et corriger les dérives avant qu’elles ne provoquent des problèmes sous-jacents. Il existe plusieurs outils permettant d’examiner votre infrastructure, de détecter les dérives et de proposer des mesures concrètes pour y remédier.

Ressources gérées et non gérées

Lorsque votre équipe évalue les outils de détection de la dérive de configuration, il est important de noter que certaines solutions sont spécialisées dans la gestion des ressources gérées, tandis que d’autres sont conçues pour traiter les ressources non gérées. Pour détecter la dérive dans les ressources gérées, telles que les ressources Terraform, votre équipe doit utiliser une solution capable d’analyser régulièrement les ressources identifiées afin d’y repérer les signes de dérive.

Pour gérer les ressources non gérées, votre équipe doit en revanche utiliser un outil capable d’inventorier les ressources qui ne sont pas documentées et qui, par conséquent, ne font pas l’objet de vérifications régulières de la dérive. Après avoir identifié les ressources non gérées, vous devez prendre des mesures pour les placer sous le contrôle de l’IaC.

Outils de gestion de la dérive de configuration

• Terraform plan. Il s’agit simplement d’une commande utilisable dans votre instance Terraform. Elle détecte les dérives dans vos ressources gérées et explique le changement non documenté qui s’est produit, ainsi que la marche à suivre pour y remédier. Toutefois, cette commande en ligne ne détecte les changements que dans vos ressources gérées, et non dans les ressources non gérées.

• Snyk IaC. Notre outil de gestion de la dérive de configuration vise à simplifier et accélérer la détection de la dérive pour les équipes. Il permet de placer les ressources non gérées sous le contrôle de Terraform afin d’étendre la couverture IaC de vos environnements cloud. Notre solution favorise la collaboration entre développement et sécurité grâce à des rapports faciles à utiliser.

• CloudQuery. Cet outil open source d’inventaire des ressources cloud peut rapidement répertorier les ressources cloud, détecter les ressources non gérées et analyser plusieurs fichiers d’état. Bien qu’il soit utile pour visualiser vos ressources cloud, il présente quelques inconvénients pour remédier à la dérive. CloudQuery peut manquer de précision lors de la recherche de dérives dans les buckets S3, offre une prise en charge limitée du stockage des fichiers d’état sur un backend, nécessite une base de données SQL et ne prend pas en charge toutes les ressources Terraform.

• Driftctl. Cette ressource open source — maintenue par Snyk — peut détecter, suivre et signaler les dérives. Polyvalente, elle peut détecter les dérives dans les ressources non gérées et analyser plusieurs fichiers d’état, mais présente aussi quelques lacunes. Par exemple, elle ne prend pas en charge toutes les ressources Terraform. En outre, certains utilisateurs ont rencontré des problèmes dus à la limitation du débit de l’API et à de longs délais d’attente lors des analyses approfondies.

La dérive de configuration est inévitable à mesure que les systèmes évoluent et changent au fil du temps. Mais si votre organisation s’attache à détecter et corriger les dérives dès qu’elles apparaissent, elles ne causeront pas de problèmes plus tard dans le cycle de développement, ce qui vous fera gagner du temps et économiser des ressources. Nous avons créé Snyk IaC pour aider les organisations à gérer et prévenir les dérives. Si vous souhaitez découvrir la solution en action, contactez-nous dès aujourd’hui pour une démonstration.