Dérive de l’infrastructure et détection des dérives : explications
Lauren Place
9 mars 2022
0 minutes de lectureAvis de dépréciation : détection de la dérive des ressources gérées
La détection de la dérive des ressources gérées, notamment snyk iac describe --only-managed and snyk iac describe --drift, est obsolète. La détection de la dérive des ressources gérées prendra fin le 30 septembre 2023.
Les attentes ne correspondent pas toujours à la réalité. Si vous avez commencé à utiliser l’infrastructure as code (IaC) pour gérer votre infrastructure, vous êtes déjà sur la bonne voie pour sécuriser davantage vos processus de provisionnement cloud. Mais le cycle de vie de l’infrastructure comporte une autre étape : comment savoir quelles ressources de votre cloud ne sont pas encore gérées par l’IaC ? Et parmi celles qui le sont, leur état dans le cloud correspond-il toujours à leur définition dans le code ?
Les charges de travail cloud évoluent constamment. Plus elles sont nombreuses dans le cloud, plus un grand nombre de personnes et de services authentifiés interagissent avec les infrastructures, dans plusieurs environnements cloud. À mesure que l’adoption de l’IaC se généralise et que les bases de code IaC s’étoffent, il devient de plus en plus difficile de suivre les modifications ou de s’assurer que les changements de configuration manuels sont pris en compte. C’est pourquoi la détection des dérives est essentielle pour sécuriser ce qui est automatisé, une fois déployé et exécuté dans le cloud.
Dans cet article, nous allons aborder la dérive de l’infrastructure, ses causes et des conseils pour la gérer, que vous soyez développeur indépendant ou membre d’une grande organisation. Pour en savoir plus sur la détection et la prévention des dérives de l’infrastructure, consultez cet article.
Qu’est-ce que la dérive de l’infrastructure ?
La dérive de l’infrastructure, ou simplement « dérive », désigne le décalage entre l’état réel de l’infrastructure et celui défini dans votre configuration IaC. Cet écart entre le code et les ressources présentes dans le cloud peut avoir de nombreuses causes.
L’un des avantages de l’IaC, ou d’une couverture plus étendue des ressources cloud par l’IaC, est de réduire les cas de dérive ! Définir les configurations souhaitées et les bonnes pratiques de sécurité avant le déploiement limite le besoin de modifier ensuite la configuration dans votre console cloud. Des changements restent toutefois inévitables en cas d’urgence ou d’erreur humaine.
Les dérives peuvent être causées par des interventions humaines, une configuration inadéquate, des changements indésirables apportés par des applications, et bien d’autres facteurs. Deux des causes les plus fréquentes sont liées aux processus ou aux flux de travail : par exemple, des changements manuels dans une console cloud qui ne sont pas reportés dans le code, ou des changements appliqués à un environnement mais pas propagés aux autres.
Voici les causes courantes des dérives de l’infrastructure :
Modifications manuelles : une personne crée ou modifie des ressources manuellement dans la console, en dehors de Terraform, CloudFormation ou d’un autre outil IaC.
Applications authentifiées : des microservices qui ne fonctionnent pas comme prévu.
Environnements IaC non synchronisés : des changements cachés ou invisibles d’un environnement à l’autre.
Qu’est-ce que la détection des dérives ?
La détection des dérives consiste à surveiller en continu les dérives de l’infrastructure cloud gérée par IaC, en particulier les écarts par rapport à votre IaC qui présentent un risque pour la sécurité de votre organisation. Idéalement, un outil de détection des dérives présente les résultats dans un format adapté aux développeurs (par exemple, une ressource Terraform affichée directement avec une mise en forme appropriée), afin de les aider à comprendre rapidement le problème et à le corriger dans l’infrastructure déployée.
Vous pouvez y voir la deuxième étape de la sécurité IaC. Vous repérez les problèmes de configuration et appliquez des garde-fous de sécurité dans l’IaC pendant le développement et les pipelines de build, mais aussi une fois les changements déployés en production.
« Chaque événement de dérive génère de l’incertitude, un délai de résolution et un risque potentiel pour la sécurité. »
Personne interrogée dans le cadre d’un entretien DevOps
La détection des dérives est essentielle, car la sécurité de votre environnement cloud ne peut pas dépasser celle de ce qui y est réellement déployé et exécuté. La gestion automatisée de votre infrastructure avec l’IaC peut donner un faux sentiment de sécurité, mais les choses évoluent ! D’où l’importance de détecter les dérives. Vous devez suivre ce qui est automatisé et assurer la sécurité _tout au long du cycle de vie de votre infrastructure_, depuis la rédaction d’une configuration IaC jusqu’à son déploiement dans le cloud.
Que se passe-t-il si les dérives ne sont pas gérées ?
Qu’il le veuille ou non, un développeur peut causer de gros dégâts avec de simples clés IAM et un SDK. Il est essentiel de repérer rapidement les mauvaises décisions et de rétablir une situation saine et sécurisée.
Parmi les conséquences néfastes des dérives de configuration de l’infrastructure, citons…
Fuites de données : les dérives peuvent exposer des données critiques.
Indisponibilité des applications : les dérives peuvent provoquer le plantage des applications.
Échecs de déploiement : les dérives peuvent faire échouer vos déploiements.
Dans chacun de ces cas, étendre la couverture IaC ou veiller à ce qu’une plus grande part de l’infrastructure soit gérée par l’IaC peut réduire les dérives ou accélérer la résolution des problèmes, par rapport à une infrastructure _non gérée par l’IaC_. Contrairement aux déploiements automatisés par IaC, les ressources configurées manuellement — ou non gérées — demandent plus de temps à mettre en place et sont sujettes aux erreurs. L’IaC vous permet de standardiser la configuration de l’infrastructure et de réduire ainsi les risques d’erreurs ou de suppression de dépendances (comme une règle manquante dans un groupe de sécurité ou une stratégie IAM).
En cas de fuite de données, si toutes les ressources sont gérées par l’IaC, vous pouvez standardiser les contrôles de sécurité et prévenir ou atténuer des problèmes tels que l’exposition publique d’un compartiment S3. En cas d’interruption de service, vous pouvez suivre votre infrastructure plus efficacement et redéployer la dernière version saine antérieure à l’incident.
Détection des dérives et gestion des dérives
La gestion des dérives est une approche de sécurité plus globale qui vise à réduire les risques et à corriger rapidement les dérives. Elle consiste à détecter les dérives des ressources gérées _et_ les ressources non gérées dans vos environnements cloud, afin de les prendre en charge.
Dans l’idéal, les équipes de sécurité et de développement pourraient couvrir 100 % de leurs ressources cloud avec l’IaC. Le flux de travail ressemblerait alors à ceci : une ressource non gérée est détectée, importée sous forme de code, puis testée et mise dans un état sain et sécurisé, conformément aux bonnes pratiques de sécurité IaC et aux politiques de conformité définies par votre organisation.
Sécuriser l’infrastructure et la synchroniser avec le code
Voici les étapes clés d’une stratégie complète de sécurité IaC :
Étendez la couverture IaC de vos ressources cloud à l’ensemble de vos environnements cloud.
Adoptez un outil de sécurité IaC pour analyser vos configurations pendant le développement et dans les pipelines de build. Vous détecterez ainsi rapidement les problèmes de configuration et pourrez passer les revues de sécurité.
Utilisez votre IaC (Terraform ou AWS CloudFormation) pour détecter les infrastructures synchronisées.
Utilisez un outil open source de détection des dérives (driftctl) pour repérer les problèmes de dérive en production et en présenter les résultats aux développeurs dans des termes qu’ils comprennent.
Traitez les résultats de driftctl en demandant aux développeurs d’ajouter le code nécessaire et de l’importer tel quel dans Terraform.
Bouclez la boucle de rétroaction en utilisant votre outil de sécurité IaC (ou
snyk iac test) pour sécuriser ces nouvelles configurations Terraform.Répétez ces étapes jusqu’à obtenir la couverture souhaitée, région par région si nécessaire.
Enfin, créez autant de tâches récurrentes que nécessaire pour générer des alertes (par exemple, une vérification toutes les heures des changements IAM et une vérification quotidienne des services cloud moins critiques).
Points à prendre en compte pour atténuer les dérives
Il existe aujourd’hui de nombreux outils de détection et de gestion des dérives. Voici quelques éléments à prendre en compte pour choisir le vôtre.
Avant de prendre votre décision, demandez-vous quel niveau d’accès vous accordez à l’outil (accès complet, en lecture seule ou stratégie de privilèges minimaux). Certains outils, comme Terraform, nécessitent un accès entièrement authentifié, tandis que d’autres se contentent d’un accès en lecture seule. Driftctl (mentionné plus haut) fonctionne avec des privilèges minimaux, c’est-à-dire le niveau d’accès nécessaire pour détecter les dérives.
Gérer les dérives avec Snyk IaC
Si vous souhaitez intégrer les ressources non gérées à l’IaC tout en détectant les dérives des ressources gérées, Snyk vous aide à le faire. La gestion des dérives dans Snyk IaC vous aide à sécuriser plus rapidement votre infrastructure en signalant les problèmes et les correctifs directement aux développeurs, dans des termes adaptés à leur métier. En accélérant la boucle de rétroaction entre les équipes de sécurité cloud et de développement, elle permet aux développeurs de prendre en charge Terraform, du code au cloud, et de sécuriser les configurations d’infrastructure après leur déploiement. Elle permet également de mettre en évidence les ressources non gérées dans vos environnements cloud, afin que vous puissiez les intégrer à l’IaC et réduire les risques de dérive dès le départ.
Sécurisez votre infrastructure dès la source
Snyk automatise la sécurité et la conformité de l’IaC dans vos workflows, et détecte les ressources dont la configuration a dérivé ou qui sont manquantes.
