Présentation des dérives de l’infrastructure et de la détection de ces dérives.

Dans certains cas, la réalité est bien différente de nos attentes. Si vous utilisez déjà l’infrastructure en tant que code (IaC) pour gérer votre infrastructure, vous avez fait un premier pas vers une meilleure sécurisation de vos processus de provisioning dans le cloud. Mais la gestion du cycle de vie de votre infrastructure vous impose aussi de savoir quelles ressources ne sont pas encore gérées par l’IaC dans votre cloud. Et parmi les ressources qui le sont, restent-elles conformes à leur définition dans le cloud ?

Les charges de travail dans le cloud évoluent en permanence. L’augmentation du nombre de ces charges de travail dans le cloud se traduit par une multiplication du nombre de personnes et de services authentifiés qui interagissent avec les infrastructures sur plusieurs environnements cloud. Avec l’adoption toujours plus large de l’IaC et l’extension des bases de code IaC, il est aussi de plus en plus difficile de suivre les changements et de s’assurer que les modifications manuelles de configuration sont répertoriées. Il est ainsi important de détecter les dérives pour sécuriser les ressources automatisées déployées dans le cloud.

Dans cet article de blog, nous allons voir ce que sont les dérives d’infrastructure, quelles en sont les causes et comment les gérer, que vous soyez développeur solo ou membre d’une grande organisation. Pour plus de conseils sur la détection et la prévention des dérives d’infrastructure, consultez cet article.

Que sont les dérives d’infrastructure ?

Les dérives d’infrastructure, ou appelées ici plus simplement « les dérives », désignent le découplage entre l’état de l’infrastructure à un instant T et sa configuration dans l’IaC. De nombreux facteurs peuvent expliquer pourquoi la configuration inscrite dans le code n’est plus celle déployée dans le cloud.

L’avantage du recours à l’IaC ou de l’extension des ressources cloud couvertes par l’IaC est sa capacité à limiter les dérives. En définissant les configurations souhaitées et les meilleures pratiques de sécurité avant le déploiement, vous réduisez la nécessité de procéder à des modifications de la configuration par la suite ou dans votre console cloud. Pour autant, les modifications restent inévitables, que ce soit en raison d’urgences ou d’erreurs d’origine humaine.

Les dérives peuvent ainsi être causées par une intervention humaine, une configuration inappropriée, des modifications indésirables effectuées par des applications, etc. Deux des causes les plus fréquentes des dérives sont liées à des problèmes de processus ou de workflow, comme des modifications manuelles effectuées dans une console cloud, mais non transposées dans le code, ou des modifications apportées dans un environnement, mais pas propagées dans les autres.

Causes fréquentes des dérives d’infrastructure :

1. Modifications manuelles : une personne accède à la console et crée ou modifie manuellement des ressources en dehors de Terraform, CloudFormation ou autre système IaC.

2. Applications authentifiées : des micro-services ne se comportent pas comme ils le devraient.

3. Environnements IaC désynchronisés :modifications cachées ou passées inaperçues entre les environnements.

En quoi consiste la détection des dérives ?

La détection des dérives désigne le processus continu de détection des dérives de votre infrastructure cloud gérée par l’IaC, et en particulier les écarts par rapport à l’IaC qui génèrent un risque de sécurité pour votre organisation. Dans l’idéal, les résultats de l’outil de détection des dérives se présentent sous un format facile à comprendre par les développeurs (par exemple, une ressource Terraform est signalée directement, dans le format approprié) pour les aider à comprendre rapidement le problème et à le corriger dans l’infrastructure déployée.

Vous pouvez considérer ce processus comme la deuxième phase de la sécurité IaC. Vous devez rechercher les erreurs de configuration et appliquer les guardrails de sécurité dans l’IaC pendant le développement et dans les pipelines de build, mais aussi une fois le code poussé en production.

« Chaque dérive est synonyme d’incertitude, de délai de résolution et de problème de sécurité potentiel. »

Un participant à notre enquête sur DevOps

La détection des dérives est essentielle, car votre sécurité dépend du code déployé et exécuté dans vos environnements cloud. Bien souvent, la gestion automatisée de l’infrastructure avec l’IaC induit un faux sentiment de sécurité. Mais il faut garder à l’esprit que les choses changent ! Et c’est précisément pour cette raison que la détection des dérives est nécessaire. Il est important de suivre les processus automatisés et d’intégrer la sécurité dans l’ensemble du cycle de vie de l’infrastructure, depuis l’écriture de la configuration IaC, jusqu’à après son déploiement dans le cloud.

Que se passe-t-il si les dérives ne sont pas gérées ?

Que ce soit intentionnellement ou non, un développeur peut faire beaucoup de dégâts simplement avec les clés IAM et un SDK. La capacité à identifier rapidement les mauvaises décisions et à rétablir la sécurité est essentielle.

Parmi les conséquences négatives des dérives de la configuration de l’infrastructure, citons...

• Les violations de données : les dérives peuvent exposer des données stratégiques.

• Une indisponibilité des applications : lest dérives peuvent entraîner une panne des applications.

• Les échecs de déploiement : les dérives peuvent aboutir à l’échec de votre déploiement.

Dans chacun de ces cas, l’extension de la couverture par l’IaC, à savoir l’augmentation de la part de l’infrastructure gérée par l’IaC, peut contribuer à limiter les dérives ou à accélérer la correction des problèmes. Contrairement aux déploiements d’infrastructures automatisés par l’IaC, les ressources configurées manuellement, ou non gérées, demandent plus de temps pour leur mise en place et sont souvent source d’erreurs. Avec l’IaC, vous pouvez normaliser la mise en place de l’infrastructure pour limiter le risque d’erreur de configuration ou de suppression de dépendances (règle de groupe de sécurité ou politique IAM manquante, par exemple).

Dans le cas de violations de données, lorsque toutes les ressources sont gérées par l’IaC, vous pouvez standardiser les contrôles de sécurité et éviter ou limiter les problèmes d’accès public à un compartiment S3 par exemple. Lors d’une panne, vous pouvez suivre plus efficacement votre infrastructure et redéployer la dernière version fonctionnelle précédant le sinistre.

Différence entre détection des dérives et gestion des dérives

La gestion des dérives est une solution de sécurité complète de réduction du risque de dérive et de correction rapide des dérives. Elle détecte à la fois les dérives des ressources gérées \_et_ les ressources non gérées de vos environnements cloud pour qu’elles puissent être contrôlées.

Dans un monde idéal, les équipes de sécurité et de développement pourraient placer la totalité de leurs ressources sous le contrôle de l’IaC, et le workflow se présenterait alors comme suit : une ressource non gérée est détectée. Elle est importée sous forme de code, puis testée et sécurisée conformément aux politiques de conformité et meilleures pratiques de sécurité IaC de votre organisation.

Maintien de la sécurité et de la synchronisation de l’infrastructure avec le code

Voici la marche à suivre pour une sécurité IaC complète :

1. Étendez la couverture par l’IaC des ressources cloud de vos environnements.

2. Adoptez un outil de sécurité IaC capable d’analyser vos configurations pendant le développement et dans les pipelines de build pour repérer les erreurs de configuration rapidement et réussir les révisions de sécurité.

3. Utilisez votre système IaC (Terraform ou AWS CloudFormation) pour détecter l’infrastructure synchronisée.

4. Appuyez-vous sur un outil de détection des dérives open source (driftctl) pour identifier les problèmes de dérive en production et générer des informations pour vos développeurs dans un format qu’ils comprennent.

5. Traitez les résultats de driftctl en demandant aux développeurs d’ajouter du code et de l’importer tel quel dans Terraform.

6. 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.

7. Répétez ce processus jusqu’à ce que la couverture obtenue vous convienne, région par région si nécessaire.

8. Enfin, créez autant de tâches récurrentes d’alerte que nécessaire (par exemple un contrôle horaire des modifications IAM et un contrôle quotidien pour les services cloud moins essentiels).

Points à prendre en compte pour la limitation des dérives

De nombreux outils de détection et de gestion des dérives sont disponibles sur le marché. Pour faire les bons choix, vous devez tenir compte d’un certain nombre de points.

Avant de prendre votre décision, demandez quel niveau d’accès vous devez accorder à l’outil (accès complet, en lecture seule ou de moindre privilège). Certains outils comme Terraform exigent un accès entièrement authentifié, tandis que d’autres se contentent d’un accès en lecture seule. Driftctl, que nous avons mentionné précédemment, s’appuie sur un accès de moindre privilège, à savoir les droits strictement nécessaires pour détecter les dérives.

Gestion des dérives avec Snyk IaC

Si vous souhaitez placer des ressources non gérées sous le contrôle de l’IaC et détecter les dérives de vos ressources gérées, Snyk est l’outil qu’il vous faut. La fonction de gestion des dérives de Snyk IaC vous aide à sécuriser votre infrastructure plus rapidement en signalant les problèmes et leurs correctifs directement aux développeurs, dans un format qu’ils comprennent. En créant une boucle de rétroaction plus rapide entre les équipes de sécurité du cloud et de développement, les développeurs pourront prendre le contrôle de leur propre infrastructure Terraform du code au cloud, mais aussi sécuriser les configurations après le déploiement. La deuxième partie de ce processus consiste à localiser les ressources non gérées de l’environnement cloud pour les contrôler via l’IaC et réduire le risque de dérive dès le départ.