En quoi consiste la sécurité de l'Infrastructure as Code (IaC) ?

• L'Infrastructure as Code (IaC) est une méthode permettant de déployer et de gérer une infrastructure cloud via du code, plutôt que par une configuration manuelle.
• La sécurité IaC vous aide à détecter et à remédier aux mauvaises configurations dans le cloud avant que vos applications ne soient mises en production.
• Les dérives de configuration peuvent créer des vulnérabilités si l'infrastructure cloud en production ne correspond pas aux modèles de l'entreprise.
• Le recours à une Policy as Code (PaC) permet d'assurer automatiquement la sécurité et la conformité tout au long du cycle de vie du développement logiciel (SDLC).
• En adoptant une approche de sécurité « Shift-Left », vous pouvez intégrer l'analyse IaC au sein du pipeline CI/CD, ce qui permet de réduire les coûts liés à la remédiation.
• Les solutions modernes de gestion de l'exposition relieront les informations de sécurité IaC aux risques, aux chemins d'attaque, aux identités et aux assets cloud.

Une seule mauvaise configuration dans un modèle d'infrastructure peut se propager à des milliers de ressources cloud en quelques secondes. C'est précisément ce risque fondamental que la sécurité de l'Infrastructure as Code (IaC) vise à contrer.

L'IaC vous permet de définir et de déployer des serveurs, des solutions de stockage, des réseaux et des paramètres de sécurité à l'aide de fichiers de configuration lisibles par la machine, plutôt que par une configuration manuelle. Des outils tels que Terraform, CloudFormation, Kubernetes et Ansible permettent de déployer une infrastructure cloud plus rapidement et de manière plus cohérente.

Cela vous garantit cohérence, évolutivité, reproductibilité et rapidité. Le déploiement d'une infrastructure ne prend plus que quelques minutes, et non plus plusieurs jours.

Cependant, cette rapidité qui rend l'IaC si précieuse est aussi ce qui en fait un outil risqué. Une erreur dans une seule configuration IaC peut facilement se propager à des centaines, voire des milliers d'instances cloud en quelques secondes. 

Une politique IAM trop permissive, un bucket de stockage exposé ou un paramètre de chiffrement manquant peuvent passer de l'environnement de développement à celui de production sans que personne ne s'en aperçoive.

La sécurité IaC consiste à détecter ces mauvaises configurations avant qu'elles ne soient exploitables, en effectuant des scans sur les modèles, en appliquant des politiques et en assurant une visibilité sur l'ensemble des environnements cloud.

C'est souvent une simple erreur de configuration qui est à l'origine de nombreux incidents de sécurité cloud parmi les plus graves que l'on observe aujourd'hui.

L'un des risques les plus courants concerne une mauvaise configuration de stockage cloud, des autorisations réseau et des politiques IAM qui se retrouvent directement intégrées dans les modèles d'infrastructure. Une fois que ces modèles sont mis en production, chaque déploiement présente la même vulnérabilité.

La permissivité par défaut est un autre problème courant. Votre équipe de développement se concentre généralement davantage sur la rapidité lors des tests et peut négliger de renforcer les autorisations lors du déploiement en production. Les autorisations excessives accordées lors des tests peuvent persister tout au long du cycle de vie du déploiement.

Le fait de coder en dur des informations d'authentification et des secrets directement dans les fichiers de configuration constitue un autre problème récurrent. Les informations d'authentification, clés API et jetons d'accès codés en dur permettent aux attaquants d'obtenir un accès non autorisé dès lors qu'ils ont accès au répertoire ou au pipeline de déploiement.

Les modules tiers et les bibliothèques de code réutilisables sont largement utilisés dans le cadre du développement logiciel. Si ces outils accélèrent les processus de développement, ils comportent souvent des risques hérités, tels que des dépendances non sécurisées et des configurations obsolètes.

Les lacunes en matière de chiffrement créent également des risques de mauvaise configuration cloud. En l'absence de paramètres de chiffrement (pour les données au repos, en transit ou dans les sauvegardes), les données critiques sont exposées, ce qui entraîne des problèmes de conformité au regard de cadres tels que PCI-DSS, le RGPD, HIPAA, la directive PSD2, SOC 2, les benchmarks CIS et NIST.

Enfin, des configurations inadaptées en matière de journalisation et de surveillance peuvent vous priver de la visibilité dont vous avez besoin après le déploiement et vous empêcher d'identifier les activités suspectes ou d'enquêter correctement sur les incidents.

On parle de dérive de configuration lorsque l'infrastructure en production commence à s'écarter de son modèle IaC initial et approuvé.

Même si une infrastructure est conforme au départ, elle peut connaître une accumulation de modifications au fil du temps. Vos ingénieurs appliquent des correctifs d'urgence dans la console cloud, et les administrateurs créent des exceptions temporaires aux politiques. 

Les équipes modifient temporairement les autorisations, mais oublient de les révoquer par la suite.

Ces modifications manuelles entraînent des divergences entre le modèle approuvé et l'environnement de production réel.

Il en résulte une base de référence de moins en moins fiable. La configuration définie dans un modèle IaC peut différer de la configuration réelle dans l'infrastructure de production. 

Il se peut que certains ports soient ouverts, que les contrôles d'accès soient laxistes, que la journalisation soit désactivée ou que des services fonctionnent sans aucune documentation ni autorisation.

Une dérive de configuration se manifeste rarement sous la forme d'un événement unique et catastrophique. Au contraire, il s'agit plutôt d'une accumulation au fil du temps. Chaque changement peut sembler anodin en soi, cependant l'exposition cumulée augmente progressivement au fil des mois ou des années.

Ce défi s'apparente à la dérive des modèles dans les systèmes d'IA. Les performances se dégradent progressivement et par paliers, sans qu'il n'y ait un point de défaillance unique évident. Et le jour où le problème devient évident, il est possible que le risque soit déjà trop important.

Les évaluations de sécurité traditionnelles, réalisées à un moment donné, ne permettent pas de détecter les dérives, car elles ne fournissent qu'une vue instantanée à un instant précis. La surveillance en temps réel est bien plus efficace, car elle détecte les écarts dès qu'ils se produisent et déclenche une alerte lorsque l'infrastructure s'écarte des valeurs de référence établies.

Si vous envisagez de mettre en place une évaluation et une gestion de l'exposition, la dérive de configuration est un facteur essentiel à prendre en compte pour prévenir la défaillance de vos contrôles de sécurité existants.

La Policy as Code (PaC) transforme la gouvernance manuelle de la sécurité en une capacité automatisée et évolutive.

Plutôt que de s'appuyer sur des contrôles de routine ou sur une validation humaine, la PaC vous permet de définir des exigences en matière de sécurité et de conformité sous forme de politiques lisibles par la machine que vos systèmes peuvent appliquer automatiquement.

Ces politiques s'appliquent tout au long du cycle de vie complet de l'infrastructure.

Les développeurs reçoivent des retours d'informations via des vérifications de pré-validation dans l'IDE avant que tout code n'entre dans le contrôle de la source. Les contrôles de configuration dans les pipelines CI/CD permettent de vérifier les configurations avant la fusion et le déploiement. Les systèmes de surveillance en continu vérifient la validité des configurations après leur déploiement.

L'application des règles de sécurité est ainsi avancée au plus près de l'écriture du code. Vous détectez les problèmes pendant que les développeurs construisent l'infrastructure cloud, et non après le provisionnement des ressources cloud par votre équipe.

La Policy as Code garantit également la cohérence dans les environnements multicloud. Que votre environnement soit hébergé sur AWS, Azure ou Google Cloud, vous appliquez vos politiques de sécurité sans avoir à effectuer de vérifications manuelles supplémentaires.

Il en va de même pour la conformité. À chaque fois qu'une politique est appliquée, elle génère une piste d'audit indiquant les contrôles qui ont été appliqués, les membres de votre équipe qui les ont mis en œuvre et si l'infrastructure a passé avec succès les tests de validation. Les exigences de conformité prises en charge par la PaC comprennent les normes SOC 2, les benchmarks CIS, les normes NIST, la norme PCI-DSS, le RGPD, la directive PSD2 et la loi HIPAA.

Mais surtout, la PaC permet d'identifier et de contrôler les dérives de configuration à grande échelle. Sans automatisation, il devient beaucoup plus difficile d'assurer la gouvernance dans des environnements cloud dynamiques.

Plus on détecte tôt les problèmes de sécurité liés à l'infrastructure, plus il est facile et moins coûteux de les résoudre.

Lorsqu'une mauvaise configuration se retrouve en environnement de production, sa remédiation nécessite souvent des tests supplémentaires, la mise en œuvre de processus de gestion des changements, des interruptions de service et une coordination entre plusieurs équipes. Les coûts augmentent considérablement à mesure que les problèmes progressent dans le cycle de développement logiciel (SDLC).

La sécurité « Shift-Left » répond à ce défi en intégrant directement l'analyse IaC dans le pipeline CI/CD.

Au lieu d'attendre que les équipes de sécurité procèdent à une vérification après le déploiement, les développeurs reçoivent des retours d'informations immédiats pendant la phase de développement. Ils corrigent les failles de sécurité avant que le code ne soit intégré aux branches de production.

Cette approche permet à la sécurité de passer d'une simple fonction d'audit en aval à une composante pleinement intégrée à vos processus de développement.

Les cadres de sécurité DevSecOps modernes doivent intégrer l'analyse de l'Infrastructure as Code, ainsi que les tests statiques de sécurité des applications (SAST) et les tests dynamiques de la sécurité des applications (DAST), afin de dresser un tableau continu de la sécurité couvrant à la fois les logiciels, l'infrastructure et les pipelines de déploiement.

À mesure que les entreprises accélèrent leur transition vers le cloud, la frontière entre la sécurité des applications et celle de l'infrastructure s'estompe de plus en plus. L'infrastructure est le moteur des applications et, le plus souvent, elle se présente sous la forme de code. Pour assurer une gestion efficace de l'exposition, vous devez disposer d'une visibilité complète sur ces deux types de sécurité.

Les assistants de programmation basés sur l'IA et l'IA agentique transforment la manière dont les équipes de développement construisent leur infrastructure.

De plus en plus d'ingénieurs logiciels se tournent vers l'automatisation basée sur l'IA pour créer des modèles Terraform, des configurations Kubernetes, des scripts de déploiement dans le cloud et d'autres composants d'infrastructure. 

Ces outils améliorent l'efficacité, mais ils créent également de nouvelles vulnérabilités.

L'IA est capable de générer du code d'infrastructure en quelques secondes, mais sa sécurité n'est aucunement garantie. Un modèle peut fonctionner parfaitement, mais il peut néanmoins exposer des données stockées, accorder des autorisations excessives, ne pas appliquer de chiffrement ou laisser des services accessibles depuis Internet. 

Lorsque vous vous fiez à un résultat sans l'avoir correctement vérifié, ces problèmes peuvent rapidement se retrouver en production.

Les équipes de sécurité sont également de plus en plus souvent confrontées au Shadow IaC. L'utilisation d'outils d'IA pour créer et réaliser le déploiement d'infrastructures en dehors des workflows approuvés entraîne la mise en place d'environnements dont vous ignorez peut-être l'existence.

Ce qui distingue l'IA, c'est sa rapidité. Une mauvaise configuration ne nécessite plus des mois de modifications manuelles pour se propager dans tout un environnement. Un modèle généré par IA comportant une erreur peut être copié et réutilisé dans des centaines de ressources avant même que vous ne vous rendiez compte du problème.

Le même principe s'applique à la mise en œuvre des mesures de sécurité. Le score VPR (Vulnerability Priority Rating) de Tenable, basé sur l'IA, permet de réduire de 60 % à 1,6 % le nombre de CVE classées comme présentant un risque « critique » ou « élevé » par leur score CVSS, le pourcentage de 1,6 % représentant les CVE ayant un risque réel pour l'entreprise.

Dans le cadre des environnements IaC, ce type de priorisation permet à votre équipe de ne plus se perdre dans le tri des alertes sans importance et de se concentrer sur les mauvaises configurations susceptibles d'être réellement exploitées.

Les praticiens de la sécurité ont recours à des solutions de gestion de la posture de sécurité du cloud basées sur l'IA, à des pratiques de Policy as Code et à des outils de validation automatisés pour gérer ces menaces.

Les garde-fous d'IA sensibles au contexte garantissent le respect des règles du principe du moindre privilège, des types de ressources autorisés, des conventions de dénomination, des politiques de chiffrement et des politiques d'entreprise, et ce directement au sein des workflows des développeurs. Cela permet d'avoir des valeurs par défaut sécurisées comme chemin de moindre résistance.

L'IA agentique rend ces contrôles encore plus importants. 

Les systèmes autonomes provisionnent des infrastructures, modifient les environnements cloud et exécutent des workflows sans qu'une personne n'ait à approuver chaque étape. Cela signifie que vos équipes doivent intégrer la gouvernance aux processus de développement et de déploiement dès le départ, et non pas l'ajouter a posteriori.

À mesure que les modèles d'IA frontier acquièrent la capacité de déployer des infrastructures et d'exécuter des opérations cloud de manière autonome, vos politiques de gouvernance peuvent prendre du retard plus rapidement que n'importe quel processus manuel ne pourrait le compenser.

La politique de gouvernance doit s'adapter à des systèmes qui agissent sans attendre une autorisation humaine.

Les capacités d'IA qui créent le risque à grande échelle peuvent également servir à appliquer la sécurité de manière évolutive. La différence est de savoir si vos politiques de sécurité sont intégrées au processus de développement dès le départ, ou ajoutées a posteriori.

Pour gouverner une infrastructure cloud à la vitesse machine, vos politiques de sécurité doivent être intégrées au processus dès le départ. Tenable aborde la sécurité IaC dans le cadre d'une stratégie plus large de gestion de l'exposition.

Tenable One Cloud Exposure analyse les modèles IaC avant leur déploiement, identifiant ainsi les mauvaises configurations dans Terraform, CloudFormation, Kubernetes, Ansible et d'autres formats courants.

Tenable One Cloud Exposure surveille en permanence les environnements cloud actifs par rapport à des bases de référence approuvées, détectant ainsi la moindre dérive de configuration dès son apparition. Le score VPR (Vulnerability Priority Rating) de Tenable, basé sur l'IA, réduit ensuite les 60 % de CVE classées comme présentant un risque « critique » ou « élevé » par leur score CVSS au 1,6 % de CVE représentant un risque réel pour l'entreprise.

La Policy as Code s'étend à AWS, Azure et Google Cloud, ce qui vous permet de maintenir une conformité cohérente sans avoir recours à des cycles de vérification manuels.

Tenable One établit un lien entre chaque mauvaise configuration IaC et les vecteurs d'attaque, les identités et les assets qui y sont associés. Votre équipe identifie les expositions qui nécessitent une intervention immédiate et celles qui peuvent attendre.

La plateforme va au-delà des détections individuelles. Au lieu de simplement signaler une mauvaise configuration cloud, Tenable cartographie la manière dont cette exposition se connecte à des chemins d'attaque plus larges, aux identités, aux autorisations et à vos assets critiques.

Ce contexte revêt plus d'importance que jamais alors que vous adoptez des workflows de développement basés sur l'IA et gérez des environnements cloud en pleine croissance. Vous devez pouvoir déterminer quelles expositions représentent un risque réel pour votre entreprise et lesquelles exigent une réponse et une remédiation immédiates.

La plateforme de gestion de l'exposition Tenable One vous permet de corréler les détections IaC avec les données sur les vulnérabilités, les informations relatives aux assets cloud, les analyses d'exposition des identités et l'Attack Path Analysis (Analyse du chemin d'attaque) afin d'obtenir une vue d'ensemble plus complète de votre risque. 

Lorsque votre équipe de sécurité a besoin d'une évaluation de l'exposition reliant les détections à l'impact réel sur les activités, Tenable One vous offre la vue unifiée depuis laquelle agir.

Tenable prend également en charge l'intégration DevSecOps via des API et l'intégration dans les pipelines CI/CD, ce qui permet à la validation de la sécurité de s'intégrer de manière transparente à vos workflows de développement modernes.

La plupart des mauvaises configurations IaC ne sont pas des attaques sophistiquées. Ce sont des oublis. Il peut s'agir d'un paramètre trop laxiste hérité d'une phase de test, d'informations d'authentification codées en dur non supprimées ou encore d'un modèle copié avant que quiconque ne l'ait vérifié. Pris isolément, chacun de ces oublis est minime. Cependant, après des centaines de déploiements, ils finissent par constituer la surface d'attaque.

Repérez-les dans les modèles. Et non au fil d'un rapport d'incident. C'est précisément pour cette raison que Tenable One a été conçu.

L'Infrastructure as Code, tant pour les praticiens de la sécurité débutants que pour les plus expérimentés, peut soulever une multitude de questions en fonction de votre approche en matière de sécurité, de votre pile technologique et de vos capacités. Quel que soit votre niveau d'expérience en matière d'opérations de sécurité, il peut être judicieux de passer en revue certaines des questions les plus fréquemment posées, afin de vous aider à mieux appréhender les principes fondamentaux.

Qu'est-ce que l'Infrastructure as Code (IaC) ? 

L'Infrastructure as Code est une pratique consistant à gérer et à provisionner une infrastructure informatique (serveurs, réseaux, bases de données, équilibreurs de charge, etc.) à l'aide de fichiers de configuration lisibles par la machine, plutôt qu'en cliquant manuellement dans des consoles ou en exécutant des commandes ponctuelles. Parmi les exemples courants, on peut citer Terraform, CloudFormation, les manifestes Kubernetes et Ansible.

Quels sont les risques de sécurité les plus courants liés à l'IaC ? 

La plupart des problèmes de sécurité IaC découlent de mauvaises configurations. Des autorisations excessives, des espaces de stockage exposés, des informations d'authentification codées en dur, l'absence de chiffrement et des modules tiers non sécurisés peuvent tous se retrouver en production si personne ne les détecte suffisamment tôt.

Qu'est-ce que la dérive de configuration dans une infrastructure cloud ? 

On parle de dérive de configuration lorsqu'un environnement cloud évolue au fil du temps et ne correspond plus au modèle IaC à partir duquel il a été créé. Les mises à jour manuelles, les corrections rapides et les modifications ponctuelles en sont généralement la cause.

En quoi la dérive de configuration peut-elle entraîner des vulnérabilités de sécurité ? 

La dérive est un problème car les configurations approuvées ne reflètent plus la réalité. Vous pouvez penser qu'un système est configuré d'une certaine manière, alors qu'en réalité, son fonctionnement en production est très différent, ce qui crée des expositions que vous n'aviez pas prévues et dont vous n'avez pas connaissance.

Qu'est-ce que la Policy as Code (PaC) ? 

Le concept de Policy as Code consiste à mettre en œuvre des politiques de sécurité et de conformité sous une forme lisible par la machine, que vos systèmes appliqueront automatiquement au sein de l'infrastructure.

En quoi la Policy as Code diffère-t-elle de l'audit de conformité traditionnel ? 

Les audits sont effectués à intervalles réguliers et impliquent généralement une inspection manuelle. La Policy as Code, en revanche, valide l'infrastructure en continu.

Quels sont les formats et outils IaC pris en charge par Tenable ? 

Tenable One Cloud Exposure prend en charge Terraform, CloudFormation, les fichiers Kubernetes, Ansible et d'autres outils IaC courants.

Comment l'approche de sécurité « Shift-Left » s'applique-t-elle à l'IaC ? 

L'approche de sécurité « Shift-Left » permet d'intégrer l'analyse IaC dès les premières étapes du cycle de développement logiciel, ce qui permet à votre équipe de détecter les mauvaises configurations avant qu'elles n'atteignent l'environnement de production.

Les mauvaises configurations IaC peuvent-elles entraîner des violations de données ? 

En effet, une mauvaise configuration des paramètres de stockage, des comptes dotés de privilèges excessifs, l'absence de contrôles de sécurité et des ports ouverts peuvent tous conduire à des accès non autorisés et à des violations de données potentielles.

Comment Tenable détecte-t-il les dérives de configuration dans les environnements en production ? 

Tenable analyse en continu les assets cloud actifs, identifie les écarts entre ces assets et les configurations de référence approuvées, et alerte sur les vulnérabilités de sécurité potentielles.