Comment sécuriser les outils d’Infrastructure as Code ?

Comme son nom l’indique, l’Infrastructure as Code (IaC) consiste à définir sous forme de code et de fichiers de configuration l’infrastructure sur laquelle s’exécutent vos applications. Cette approche permet non seulement d’automatiser le provisionnement des ressources, mais aussi de leur appliquer les mêmes processus de cycle de vie qui, jusqu’ici, concernaient uniquement le code des applications. Si vous découvrez l’IaC, consultez cet article dans lequel nous expliquons ce qu’est exactement l’Infrastructure as Code (IaC) et quelles sont les implications de son utilisation en matière de sécurité dans le monde réel.

Il existe de nombreux outils d’automatisation de l’infrastructure pour mettre en œuvre l’IaC. Beaucoup sont proposés par des fournisseurs de cloud public, comme CloudFormation d’Amazon Web Services et Resource Manager (ARM) d’Azure, tandis que d’autres projets prennent en charge plusieurs plateformes d’infrastructure, comme Terraform de HashiCorp et Pulumi.

Ces outils d’IaC déclaratifs, fondés sur des langages, se prêtent parfaitement aux techniques d’analyse statique, qui permettent de détecter et de résoudre plus efficacement les problèmes de sécurité avant même le déploiement de l’infrastructure définie. Les bonnes pratiques de sécurité dans le domaine de l’IaC continuent d’évoluer. Avec le développement du produit Snyk IaC, nous cherchons à faciliter autant que possible l’adoption de l’IaC par les organisations, en aidant les développeurs non seulement à repérer les problèmes, mais aussi à comprendre leur contexte et à savoir comment les corriger.

Découvrons quelques-uns des outils d’Infrastructure as Code les plus populaires et les mesures de renforcement de la sécurité que vous pouvez appliquer au niveau du code pour protéger vos applications et vos plateformes.

Outils d’Infrastructure as Code

Solutions proposées par les fournisseurs de cloud

AWS CloudFormation, Azure Resource Manager (ARM), et Google Deployment Manager (GDM)Tous les grands fournisseurs de cloud proposent leurs propres outils d’IaC pour automatiser le provisionnement de l’infrastructure. Ceux-ci définissent de manière déclarative l’état souhaité de vos déploiements à l’aide de modèles JSON ou YAML ; dans le cas de Google Deployment Manager, Jinja et Python peuvent également être utilisés.

Amazon Cloud Development Kit (CDK)Lancé en 2019, Amazon Cloud Development Kit (CDK) permet aux développeurs de définir leurs déploiements dans des langages de programmation de plus haut niveau, comme JavaScript, Python ou C# (consultez la liste complète des langages ici). Cette syntaxe leur est non seulement plus familière, mais elle permet également l’intégration à un IDE et la création de bibliothèques réutilisables et de structures de code testées, plutôt que de copier-coller des fichiers JSON/YAML d’un projet à l’autre. CDK génère en fait du JSON CloudFormation : Amazon a ainsi créé un environnement axé sur les développeurs qui tire toujours parti de son outil d’orchestration de l’infrastructure CloudFormation, éprouvé sur le terrain.

Solutions multicloud

Hashicorp TerraformTerraform est un outil de provisionnement automatisé qui permet de provisionner et de configurer un large éventail de plateformes et de produits grâce à des plug-ins de fournisseurs.

PulumiPulumi est un projet open source d’IaC qui propose des SDK dans plusieurs langages de programmation pour provisionner et gérer des ressources sur de nombreuses plateformes.

Points à surveiller et exemples d’analyse

Quel que soit le fournisseur de cloud ou l’outil d’IaC que vous choisissez, certains aspects communs méritent une attention particulière du point de vue de la sécurité. Examinons-en quelques-uns, avec des exemples utilisant Terraform et AWS. Tous ces exemples figurent dans ce dépôt GitHub. Vous trouverez également ci-dessous des captures d’écran montrant comment l’outil d’analyse Snyk IaC présente les problèmes potentiels détectés.

Identifiants

À la racine de notre dépôt Git, le fichier main.tf contient plusieurs problèmes courants. L’analyse de Snyk signale un problème de gravité élevée et cinq de gravité moyenne, comme illustré ci-dessous.

Tout d’abord, ne stockez jamais d’identifiants dans un système de gestion de versions. Cela peut sembler évident, mais les forums regorgent d’exemples de dépôts de code qui en contiennent, dont beaucoup sont accessibles au public ! Malheureusement, nombre de ces exemples n’ont été découverts qu’après leur exploitation. Souvent, le problème vient d’un commit accidentel effectué par un utilisateur inattentif. Il arrive aussi, de manière plus insidieuse, qu’un identifiant soit ajouté dans un commit, puis supprimé dans un commit ultérieur : le développeur peut ne pas le remarquer, mais l’identifiant reste dans l’historique du dépôt. Certaines techniques permettent de repérer ce problème, par exemple les fichiers .gitignore ou les scripts de hook pre-commit, comme « git-secrets » d’AWS Labs.

Nous relevons également plusieurs problèmes liés aux mots de passe des comptes IAM. Il est important de noter que vous disposez d’une seule stratégie par compte AWS et que, si vous en définissez une, elle remplacera la stratégie par défaut fournie par Amazon. Veillez donc à préciser toutes ces options.

Chiffrement des services de stockage

Par défaut, le chiffrement est activé pour les volumes EBS, mais pas pour les compartiments S3. Il est important de vérifier les deux afin de respecter les politiques de votre entreprise et les directives des organismes de réglementation. Dans notre dépôt de démonstration, nous avons déclaré quelques ressources de stockage dans le fichier modules/storage/main.tf, dont vous pouvez voir l’analyse ci-dessous :

On voit ici les deux violations signalées, ainsi qu’un avertissement de priorité moindre concernant la désactivation de la journalisation des accès au serveur S3. En examinant l’un de ces problèmes, vous trouverez des détails sur le problème, son impact et une recommandation pour le résoudre.

Vous pouvez modifier la classification de chaque stratégie (gravité élevée, moyenne ou faible) pour l’adapter aux politiques de votre organisation.

Plages d’entrée et de sortie des groupes de sécurité et des pare-feu

Dans le fichier modules/vpc/main.tf, nous trouvons un autre problème courant : les accès entrants sont configurés de manière probablement trop permissive.

Comme pour les identifiants codés en dur, ce problème survient souvent pendant le développement ou le dépannage, puis est accidentellement ajouté au système de gestion de versions avec d’autres modifications. Dans cet exemple, il est très peu probable que quiconque souhaite réellement ouvrir le port 22 à l’ensemble d’Internet, ce qui pourrait être le cas ici. Il est essentiel de restreindre le trafic entrant et sortant de vos réseaux et de n’autoriser que les plages d’adresses IP qui en ont absolument besoin.

Rotation des clés

Pour notre dernier exemple, examinons le fichier modules/pki/main.tf, dans lequel une clé est configurée sans rotation.

C’est un autre cas où le comportement par défaut n’est souvent pas le plus adapté au renforcement de la sécurité. Bien entendu, cette recommandation suppose que votre organisation ne dispose pas d’un processus distinct de rotation des clés. Mais si vous utilisez le service de gestion des clés du fournisseur de cloud, il y a de fortes chances que lui confier cette tâche soit le meilleur choix.

Quel est le niveau de sécurité de vos projets IaC ?

Maintenant que vous avez vu quelques exemples de problèmes qui peuvent facilement se glisser dans du code IaC, êtes-vous certain que le vôtre est sûr ? N’oubliez pas : la sécurité ne doit pas être une réflexion de dernière minute. Vous pouvez dès maintenant lancer ces mêmes vérifications, ainsi que d’autres portant sur différents fournisseurs de cloud et Kubernetes, sur votre dépôt, gratuitement, et détecter les problèmes avant leur déploiement ou leur exploitation.

Créez un compte Snyk gratuit et suivez les instructions pour créer un projet à partir de votre dépôt. En quelques minutes, vous obtiendrez des conseils concrets pour résoudre les problèmes détectés.