Les améliorations de l’analyse Snyk IaC couvrent Azure et AWS en infrastructure as code

Récemment, j’ai écrit sur l’Infrastructure as Code (IaC) et sur la façon dont l’analyse IaC de Snyk permet de détecter les problèmes dans vos modèles avant leur déploiement. Notre équipe d’ingénierie continue d’élargir la couverture de nos règles d’analyse IaC afin de mieux protéger vos plateformes contre les vulnérabilités et les problèmes de configuration.

Dans cet article, nous passons en revue l’outil d’analyse IaC, présentons ses dernières nouveautés — notamment la prise en charge de l’infrastructure as code sur Azure, GCP et AWS — et expliquons comment vos équipes peuvent l’intégrer activement aux efforts DevSecOps de votre entreprise.

Pourquoi analyser l’IaC ?

Les modèles IaC définissent l’état souhaité de vos applications dans différents environnements de déploiement. J’aime les considérer, avec d’autres artefacts comme les fichiers Dockerfile, comme des guides d’exécution automatisés qui rassemblent tout le savoir-faire et les rituels associés aux déploiements manuels, puis les transforment en étapes standardisées et reproductibles, pouvant être examinées et testées avant leur exécution. Ils permettent également d’appliquer à votre code d’infrastructure des principes du développement logiciel, comme les revues de code et les approbations. Les outils d’analyse de Snyk effectuent une revue automatisée qui compare vos modèles IaC aux règles et bonnes pratiques que nous avons sélectionnées, puis génèrent un rapport détaillant les problèmes détectés et proposant des solutions.

La plupart des problèmes liés à l’IaC ne sont pas des « vulnérabilités », du moins pas au sens classique du terme. En général, les utilisateurs de l’IaC ne craignent pas qu’une vulnérabilité zero-day affecte soudainement leurs définitions IaC ; ils se préoccupent davantage du respect des règles et des normes définies par les équipes de sécurité et d’architecture. En pratique, cela signifie qu’il faut généralement tester le code au fil de ses modifications, ce qui s’intègre bien aux tests exécutés dans les pipelines lors d’un push ou d’une pull request.

Kubernetes peut toutefois contrecarrer les plans les mieux établis. Prenons par exemple la vulnérabilité d’attaque de l’homme du milieu du service Kubernetes, qui s’est révélée exploitable dans toutes les versions de Kubernetes. Désignée sous le nom de CVE-2020-8554, elle a été rendue publique le 8 décembre 2020 et, au moment où j’écris cet article, aucun correctif n’est encore disponible pour cette vulnérabilité. Pour les utilisateurs qui avaient activé la surveillance Snyk IaC, une règle mise à jour a rapidement été ajoutée. Ils ont alors commencé à recevoir automatiquement des alertes grâce à l’analyse continue de Snyk sur GitHub, même sans avoir lancé eux-mêmes une analyse.

Le rapport des problèmes de l’analyse Snyk IaC signale un risque potentiel lié à la CVE-2020-8554.

Si vous découvrez l’IaC et le fonctionnement de l’analyse Snyk, consultez cet article sur les outils d’Infrastructure as Code pour en savoir plus.

Nouveautés de l’analyse de sécurité de l’infrastructure as code

Au départ, Snyk IaC analysait les ressources Kubernetes, Helm Charts et Terraform AWS. Depuis son lancement, les ingénieurs Snyk ont continuellement ajouté de nouvelles règles et élargi la couverture de l’analyse. Parmi les améliorations récentes, citons :

Infrastructure as code Terraform pour AWS

Plus de 100 règles couvrant notamment :

• les contrôles d’accès et la journalisation de S3

• divers contrôles concernant les données sensibles (par exemple, les secrets codés en dur et les paramètres faibles) dans Lambda, EC2 et EKS

• la détection de l’absence de chiffrement au repos pour divers services

• les mauvaises pratiques en matière de privilèges IAM

Infrastructure as code Terraform pour Azure

La prise en charge d’Azure inclut désormais :

• les bonnes pratiques de journalisation

• les bonnes pratiques pour les services d’application

• les problèmes liés à SSL et aux alertes dans MYSQL

• divers problèmes PostgreSQL, notamment :

  • SSL

  • la limitation des connexions

  • la journalisation

• les problèmes d’accès et de chiffrement des comptes de stockage

Google Cloud Platform (GCP)

Les ressources GCP suivantes sont également prises en charge :

• l’affectation des utilisateurs IAM

• les problèmes liés à Kubernetes sur GCP

Kubernetes

La couverture des ressources Kubernetes et Helm continue de s’étoffer grâce à de nouvelles règles. Plus précisément :

• les contrôles des conteneurs, notamment :

  • les ports SSH exposés

  • les montages de périphériques hôtes

  • l’absence de sondes de vivacité

  • etc.

• les services dotés d’une adresse IP externe (analyse de CVE-2020-8554 mentionnée plus haut)

• les contrôles PSP, comme :

  • les montages de volumes trop permissifs

  • Seccomp

  • les problèmes liés à AppArmor

  • l’autorisation du GID root dans les processus des conteneurs

Analyser votre propre code IaC en toute simplicité

Chez Snyk, nous avons à cœur de rendre la sécurité simple d’utilisation. Nous sommes convaincus qu’en donnant aux développeurs des outils adaptés à leurs workflows, nous leur permettons d’agir concrètement pour éliminer les vulnérabilités et les problèmes de sécurité dès leur origine.

Commencez dès maintenant à analyser vos modèles IaC en créant un compte gratuit sur Snyk.io.

Pour en savoir plus sur les nouveautés de Snyk cette année, consultez l’article récemment publié par mes collègues Jim Armstrong et Daniel Berman, qui revient sur les fonctionnalités cloud native et les annonces de Snyk en 2020.

Faisons de 2021 l’année la plus sûre à ce jour !