Dans un univers informatique de plus en plus multicloud ou hybride, les différentes architectures deviennent de plus en plus complexes à mesure que les organisations adoptent rapidement de nouvelles technologies telles que le serverless, les conteneurs ou le service mesh. Une enquête menée par la Cloud Native Computing Foundation (CNCF) à l'automne 2019 a révélé que 41% des organisations utilisent des technologies serverless et que 84% avaient des conteneurs en production. Le rapport d’Accurics sur l’état du DevSecOps au printemps 2020 montre que si un nombre important de failles dans le cloud sont liées à l'exposition des conteneurs AWS S3, des attaques impliquant d'autres technologies commencent à apparaître. L’attaque Kinsing ciblant les serveurs Docker est un exemple récent : des pirates ont pénétré dans des grappes de conteneurs via des API exposées accessibles sans mot de passe.
Une évolution vers le provisionnement de l'infrastructure en nuage par le biais de codes
Poussé par le besoin d'agilité et de fiabilité, une quantité importante d'infrastructures cloud est fournie et gérée comme du code comme Terraform, Kubernetes YAML, Dockerfile et OpenFaaS YAML. Les chercheurs d'Accurics ont déterminé que 24 % des modifications de configuration sont effectuées par du code, ce qui représente une adoption importante étant donné que ces technologies sont récentes.
Ce qui ressort également si le moment à partir duquel les entreprises commencent à gérer leur infrastructure en passant par le code. Les configurations sont modifiées directement sans passer par le biais du code au moment du déploiement initial du cloud dans l’entreprise. En revanche, les changements de configuration effectués par l'intermédiaire du code ont été répartis de manière égale dans le temps dès le moment où l'architecture est mise en place et tout au long de son cycle de vie.
Omniprésence des risques de sécurité dans l’infrastructure as code
La sécurisation de l'infrastructure cloud en production seule n'est pas efficace. Les chercheurs d'Accurics ont déterminé que seuls 4 % des problèmes signalés en production sont traités. Cela n'est pas surprenant selon l’éditeur car il est difficile de remonter jusqu'au développeur qui a mal configuré l'infrastructure en question et cela nécessite le redéploiement du cloud, une solution coûteuse.
L'étude a aussi révélé que des erreurs flagrantes sont commises lors du provisionnement et de la gestion des infrastructures via du code. Les risques de haute gravité tels que des accès par groupes de sécurité ouverts, des accès à privilèges trop permissifs ou des services de stockage exposés dans le cloud constituent 67 % des problèmes rencontrés. Cette situation est particulièrement inquiétante, car ces types de risques sont souvent les plus exploités par les pirates pour pénétrer dans un cloud. Par exemple, lors de la brèche de 2019 à Capital One, où plus de 100 millions de clients ont été exposés, un attaquant s'est emparé d'un ensemble de clés d'accès AWS en exploitant une vulnérabilité du serveur.
Des bases de référence trop souvent modifiées
En étudiant le paysage des produits de sécurisation des infrastructures as code utilisés par les développeurs, les chercheurs d’Accurics ont conclu que les options sont bien limitées. Une poignée de projets open source existent pour mettre en place des garde-fous autour de Terraform mais ils ne sont utilisés que par 4% des répondants. De plus, 80 % des organisations utilisent plus d'un type d'infrastructure as code, certaines de manière ponctuelle, ce qui rend la mise en place d’une politique de gouvernance cohérente très difficile ente entre les différentes couches de l’architecture.
Enfin, dans 90% des cas, les bases de référence en termes de sécurité établie au départ ne restent pas longtemps en place. Dans une infrastructure as code, les utilisateurs ayant les privilèges nécessaires apportent des modifications directement à l'infrastructure cloud en production sans mettre à jour le code qui a été défini au départ. Si certains changements sont légitimes, d'autres peuvent introduire un risque. Un examen plus approfondi des données a révélé que les instances, les équilibreurs de charge des applications, les groupes de sécurité et les services de stockage dans le cloud représentent 77% des ressources dont la base de référence sécurisée était les plus modifiées. C’est, une fois encore, sur ce type de ressources que des erreurs de configuration ont été faite conduisant à la faille de Capital One.