Les 5 principaux enjeux de sécurité liés à l’infrastructure as code

L’infrastructure as code (IaC) a transformé la manière dont nous déployons et gérons notre infrastructure cloud. Au lieu de configurer manuellement les serveurs et les réseaux avec une grande équipe des opérations, nous pouvons désormais définir l’architecture de nos services sous forme de code. L’IaC nous permet d’automatiser le déploiement de l’infrastructure, de faire évoluer l’ensemble de notre parc de serveurs, de conserver un historique des modifications apportées à notre architecture et de tester les changements progressifs du réseau. Il n’est donc pas étonnant que l’IaC soit devenue la méthode privilégiée des équipes et des entreprises pour configurer et gérer leurs services cloud.

Cependant, si l’IaC présente de nombreux avantages, elle n’est pas exempte de risques de sécurité. Examinons les 5 principaux enjeux de sécurité liés à l’IaC et les bonnes pratiques à mettre en œuvre pour les atténuer.

1. Erreurs de configuration dans les modèles IaC

L’un des principaux enjeux de sécurité liés à l’IaC réside dans les erreurs de configuration des modèles. Le code et les dépendances des modèles IaC peuvent contenir des bogues susceptibles de compromettre involontairement l’infrastructure ou de fournir à un attaquant averti un moyen d’exploiter le système.

Par exemple, imaginons qu’un modèle IaC contienne par inadvertance des identifiants de nom d’utilisateur et de mot de passe codés en dur pour une base de données renfermant des données sensibles sur les utilisateurs, telles que des informations financières ou des données à caractère personnel (PII). Un attaquant qui accéderait à ce modèle sans autorisation pourrait consulter les données et manipuler la base de données.

De même, imaginons qu’un modèle IaC contienne une adresse IP codée en dur pour un serveur critique. Ce serveur pourrait devenir la cible d’une attaque par déni de service (DoS), et il pourrait être difficile de réagir rapidement et de mettre à jour l’infrastructure. Il est essentiel d’utiliser des paramètres d’entrée ou des variables d’environnement pour séparer les identifiants et les informations sensibles du code du modèle.

Autre exemple : l’utilisation de frameworks IaC obsolètes ou dépréciés, ainsi que d’autres dépendances tierces. Les attaquants peuvent découvrir de nouvelles failles dans d’anciennes versions du code et exploiter ainsi des erreurs de configuration jusque-là inconnues. Le risque est encore plus grand lorsque les mêmes modèles IaC sont partagés entre différents environnements : une seule erreur de configuration peut alors avoir des conséquences bien plus importantes. Il est important de maintenir et de mettre à jour régulièrement le code, ainsi que de vérifier soigneusement les dépendances tierces pour s’assurer qu’elles sont à jour.

Pour sécuriser davantage les modèles IaC, nous devons appliquer des pratiques de codage sécurisé, notamment écrire du code IaC robuste qui valide les entrées et les paramètres dans les fonctions, et utiliser des frameworks de test et un système de contrôle de version pour valider et suivre les modifications du code afin de traiter rapidement les erreurs. Nous devons également vérifier que le modèle fonctionne correctement lors du déploiement et de la suppression des ressources, afin d’éviter des coûts imprévus liés à des services qui n’auraient pas été supprimés correctement.

2. Stockage et transmission non sécurisés des secrets

La gestion des secrets est un autre enjeu majeur de sécurité dans l’IaC. Les mots de passe et les clés d’API représentent un risque s’ils sont exposés. Des acteurs malveillants peuvent également utiliser d’autres informations sensibles, comme des URL de webhook ou des adresses IP, pour envoyer du spam, bloquer des ressources et mettre hors service un service ou un réseau.

Même un accès en lecture seule à un modèle IaC peut donner aux attaquants des informations précieuses sur l’infrastructure et les aider à repérer d’éventuelles erreurs de configuration. Il leur est alors plus facile de planifier et de mener des attaques ciblées.

Heureusement, les frameworks IaC et les plateformes cloud permettent de stocker et d’utiliser ces secrets en toute sécurité. Par exemple, Terraform Cloud propose une fonctionnalité de gestion des secrets qui garantit le chiffrement et le stockage adéquats de ces valeurs sensibles. Les services cloud fournissent souvent automatiquement des secrets — tels que des clés d’accès et des chaînes de connexion à une base de données — sous forme de variables d’environnement, que nous pouvons remplacer par nos propres valeurs lors du développement en local.

3. Politiques de contrôle d’accès mal configurées et dérive de configuration

L’OWASP Top 10, un document reconnu à l’échelle mondiale en matière de sécurité des applications Web, considère les contrôles d’accès insuffisants et les erreurs de configuration cloud comme des enjeux importants.

Les pirates peuvent exploiter des politiques d’accès trop permissives pour des ressources comme les serveurs et le stockage de données dans le cloud, afin de lancer des attaques ou de récupérer des informations privées. Des buckets AWS S3 mal configurés ont été à l’origine de fuites de données sensibles telles que des identifiants, des données à caractère personnel (PII) et des informations de carte bancaire.

Les attaquants peuvent exploiter des configurations vulnérables dues à des ports réseau ouverts, à des limites de débit inexistantes ou à des données non chiffrées en transit ou au repos. Ils peuvent ensuite tirer parti de ces erreurs de configuration pour obtenir un accès non autorisé, dérober des données sensibles ou perturber les services.

Des erreurs de configuration peuvent aussi apparaître plus discrètement au fil du temps, à cause de la dérive de configuration, qui se produit lorsque les modifications de l’infrastructure ne sont pas documentées ou correctement gérées. Par exemple, vous pouvez appliquer des correctifs système sans consigner les changements, ou des ingénieurs peuvent se connecter pour examiner des problèmes, effectuer des modifications manuelles et oublier de les annuler. Ces actions peuvent compliquer l’identification et la correction des risques potentiels qui échappent au modèle IaC, laissant le système exposé aux menaces.

Les modèles IaC contribuent à atténuer certains de ces risques grâce à l’automatisation et au contrôle de version, mais ils ne règlent pas tout. Il est frustrant d’attendre longtemps le déploiement d’un modèle IaC pour découvrir qu’il a échoué en raison d’un problème d’autorisations. On peut alors être tenté d’utiliser une politique accordant un accès complet pour résoudre le problème. Mais ce raccourci introduit des erreurs de configuration qui auraient pu être évitées.

Pour garantir un contrôle d’accès adéquat, appliquez toujours le principe du moindre privilège (PoLP) et limitez les autorisations autant que possible. N’accordez l’accès que lorsque cela est nécessaire, en utilisant des politiques de contrôle précisément définies, des clés à rotation automatique et des rôles d’accès temporaires.

Les outils d’audit de sécurité comme Snyk Infrastructure as Code et Snyk Container peuvent également aider à analyser et à surveiller l’infrastructure. Ils automatisent le processus et facilitent le maintien de configurations et de politiques d’accès sécurisées.

4. Fichiers d’état non sécurisés

Comme la plupart des frameworks IaC génèrent des fichiers d’état pour consigner l’état actuel de l’infrastructure déployée, il est essentiel de les sécuriser et de les synchroniser avec l’état réel du cloud. Les fichiers d’état en texte brut peuvent contenir des informations détaillées sur la sécurité des ressources cloud. Pour protéger ces informations, il faut chiffrer le fichier d’état et en sécuriser l’accès.

Si nous perdons ce fichier d’état, nous n’avons plus de trace de l’état de l’infrastructure déployée à l’aide des modèles ou du code IaC. Une telle perte nous obligerait à réimporter manuellement les ressources cloud existantes dans le fichier d’état persistant, afin de ne pas compromettre la gestion future de l’IaC.

Si l’IaC est gérée dans un pipeline CI/CD automatisé, la perte du fichier d’état pourrait entraîner la suppression ou la création de ressources, et provoquer une interruption du système ou une perte de données. De même, un fichier d’état corrompu ou désynchronisé peut vite devenir difficile à gérer lorsqu’il faut mapper manuellement les ressources et tout reconstituer.

Nous pouvons éviter cette situation en prenant quelques précautions simples :

• Stockez le fichier d’état à distance dans le cloud pour pouvoir le partager et le sauvegarder facilement.

• Activez le contrôle de version pour pouvoir le récupérer si le fichier est corrompu.

• Utilisez un mécanisme de verrouillage des fichiers afin qu’un seul utilisateur puisse déployer et modifier le fichier d’état à la fois.

• Chiffrez le fichier lors de son stockage afin qu’un attaquant ne puisse pas le déchiffrer, même s’il y accède.

• Limitez l’accès des utilisateurs au fichier d’état afin que seule l’équipe puisse le consulter. Même lorsque les secrets sont stockés de manière sécurisée et exclus des modèles IaC, ils peuvent apparaître en texte brut dans les fichiers d’état. Il est donc essentiel de chiffrer ces fichiers et d’en limiter l’accès pour éviter toute fuite de secrets.

5. Manque de tests et de validation

Des modèles IaC qui ne sont pas rigoureusement testés et validés peuvent entraîner des déploiements non sécurisés ou des erreurs de configuration, permettant aux attaquants de compromettre l’infrastructure.

En intégrant les tests et la validation à notre workflow de développement IaC, nous pouvons identifier, atténuer et réduire les risques dès le début du processus, et sécuriser notre infrastructure de manière proactive.

Posez-vous les questions suivantes lors des tests et de la validation d’une IaC :

• Le modèle IaC a-t-il été déployé correctement ?

• Les contrôles d’accès et les configurations sont-ils conformes au code ?

• Les ressources sont-elles correctement associées et référencées ?

• L’activité des serveurs est-elle correctement surveillée et consignée ?

• L’infrastructure peut-elle gérer la charge de trafic requise ?

Les bonnes pratiques en matière de test et de validation de l’IaC suivent les mêmes principes généraux que pour tout code. Mettez en place un processus de revue de code au sein de l’équipe. Testez le code dans un environnement de préproduction avant de le déployer en production. Utilisez des outils de linting pour détecter les erreurs de syntaxe et de formatage, et écrivez des tests unitaires — par exemple, pour vérifier les noms ou les identifiants des ressources. Analysez le code IaC de haut niveau généré par des outils comme Pulumi à l’aide d’outils automatisés de tests statiques de sécurité des applications (SAST), comme Snyk Code.

En définitive, la meilleure façon de développer, tester et valider l’IaC de manière sécurisée consiste à intégrer la sécurité au processus de développement. Pour ce faire, vous pouvez utiliser Snyk Infrastructure as Code, un outil spécialisé dans l’amélioration des tests et de la validation de l’IaC. Il s’intègre facilement aux outils et workflows de développement, pour permettre un développement IaC sécurisé, continu et en temps réel.

Snyk Infrastructure as Code analyse le code à la recherche d’éventuelles erreurs de configuration ou de violations de politiques, et fournit des conseils et des recommandations concrètes pour résoudre les problèmes détectés. Nous pouvons nous appuyer sur ces informations pour améliorer la posture de sécurité globale de notre IaC et garantir sa conformité.

Conclusion

Cet article a présenté cinq enjeux de sécurité liés à l’utilisation de l’IaC. Nous avons également découvert comment y remédier, notamment en appliquant le principe du moindre privilège, en adoptant des pratiques de codage sécurisé et en intégrant des outils de sécurité au processus.

Il est essentiel d’appliquer les bonnes pratiques pour sécuriser l’IaC, en particulier si l’on tient compte des conséquences potentielles d’une IaC non sécurisée. En négligeant des problèmes tels que les identifiants codés en dur, la mauvaise gestion des secrets et la dérive de configuration, nous risquons de perdre les avantages de l’IaC et de provoquer des violations de données, des accès non autorisés et des interruptions de services critiques.

En intégrant proactivement la sécurité au processus de développement de l’IaC et en appliquant les bonnes pratiques, nous pouvons atténuer efficacement les risques, protéger notre infrastructure et préserver nos entreprises et nos clients.