Parce que l'ère du cloud impose des capacités d’extension et de déploiement rapide des infrastructures pour répondre à des besoins organisationnels en évolution constante, la configuration de serveurs et de nœuds est entièrement automatisée. Appelé « Infrastructure-As-Code », « Infrastructure gérée par le code » (IaC) ou automatisation continue de la configuration (CCA), ce processus passe par des fichiers de définition lisibles par la machine, les templates. Or, d’après l’analyse effectuée par des chercheurs de Palo Alto Networks sur les modèles IaC collectés dans les référentiels GitHub et ailleurs, environ 200 000 fichiers de ce type contenaient des options de configuration non sécurisées.

L’usage de ces modèles peut entraîner de graves vulnérabilités qui mettent en danger l'infrastructure cloud déployée par IaC et les données qu'elle contient. « C’est exactement comme si l’on oubliait de verrouiller son véhicule ou de fermer une fenêtre : un attaquant peut utiliser ces configurations erronées pour contourner les défenses », ont déclaré les chercheurs. « Ce nombre élevé explique pourquoi, dans un précédent rapport, nous avons constaté que 65 % des incidents dans le cloud étaient dus à des erreurs de configuration des clients. Si les templates IaC ne sont pas sécurisés dès le départ, les environnements cloud sont des cibles de choix pour les attaquants ».

Des problèmes courants déjà identifiés

Il existe de multiples frameworks et technologies « Infra-As-Code ». Mais d’après l’inventaire réalisé par les chercheurs de Palo Alto Networks, les plus répandus sont Kubernetes YAML (39%), Terraform de HashiCorp (37%) et AWS CloudFormation (24%). Parmi eux, 42 % des templates CloudFormation, 22 % des templates Terraform et 9 % des fichiers de configuration Kubernetes YAML identifiés présentaient une vulnérabilité. L'analyse des chercheurs de Palo Alto Networks suggère que la moitié des déploiements d'infrastructure utilisant les modèles AWS CloudFormation sont basés sur une configuration non sécurisée. Une extrapolation de ces résultats par type de service AWS montre que Elastic Compute Cloud (EC2), Relational Database Service (RDS), Simple Storage Service (S3) ou Elastic Container Service (ECS) sont impactés.

Par exemple, plus de 10 % des buckets Storage S3 définis par templates ont été exposés publiquement. Dans le passé, ces espaces de stockage S3 mal sécurisés ont subi de nombreuses violations de données, révélées publiquement. Les chercheurs ont également constaté dans les templates de CloudFormation l’absence courante de chiffrement et de logging pour les bases de données, importants pour protéger les données et mener des enquêtes sur des accès non autorisés éventuels. La moitié des modèles n’avait pas activé de logging S3 et une autre moitié n’avait pas activé de chiffrement S3 côté serveur. Les chercheurs ont retrouvé une situation similaire avec le service d'entreposage de données Redshift d'Amazon. 11% des fichiers de configuration créaient des instances Redshift exposées publiquement, 43% des fichiers n’activaient pas le cryptage et 45% d’entre eux n’activaient pas le logging. Les templates Terraform, qui supportent plusieurs fournisseurs et plusieurs technologies cloud, ne sont pas mieux lotis. Environ 66 % des buckets S3 configurés par Terraform n’activaient pas le logging, 26 % des instances AWS EC2 configurées par les templates Terraform exposaient le SSH (port 22) à Internet et 17 % des groupes AWS Security Groups définis par template autorisaient par défaut tout le trafic entrant.

D’autres erreurs courantes de configuration ont été trouvées dans les templates Terraform :

- Les mots de passe AWS Identity and Access Management (IAM) ne répondaient pas aux normes minimales de l'industrie (40%)

- Les conteneurs n’avaient pas de limitation de ressources CPU ou mémoire (64%)

- Les groupes Azure Network Security Groups (NSG) avaient des SSH exposés (51%)

- Dans Google Cloud Platform Storage, le logging n’était pas activé (58%)

- Dans Azure Storage, Secure Transfer n’était pas activé (97%).

Les fichiers YAML de Kubernetes affichaient la plus faible incidence de configurations non sécurisées, mais celles qui l'étaient étaient significatives. Parmi les fichiers YAML non sécurisés trouvés par les chercheurs, 26% avaient des configurations Kubernetes qui fonctionnaient en tant que root ou avec des comptes avec privilèges. « Les configurations autorisant l’usage des conteneurs en mode root donnent aux attaquants la possibilité de contrôler à peu près n'importe quelle fonction au niveau du conteneur », ont déclaré les chercheurs de Palo Alto. « Cette faiblesse facilite également l'exécution d’attaques par échappement du conteneur, exposant ainsi le système hôte à d'autres menaces potentielles. Les équipes de sécurité et de DevOps doivent s'assurer que les conteneurs ne fonctionnent pas avec des comptes root ou des comptes avec privilèges ».

Une répercussion sur les déploiements réels

Les erreurs de configuration des templates IaC et leur prévalence - l'absence de cryptage des bases de données et de logging ou des services exposés publiquement – reflètent bien les problèmes constatés par les chercheurs de Palo Alto Networks dans les déploiements réels d'infrastructures cloud, problèmes dont ils avaient déjà fait état dans des rapports précédents :

- 76% des entreprises autorisent l'accès public au port 22 (SSH)

- 69% des entreprises autorisent l'accès public au port 3389 (RDP)

- 64% d’entre elles n'activent pas de logging pour leur stockage de données

- 62% n’activent pas le cryptage pour le stockage des données

- 47% des entreprises n'utilisent pas le traçage pour les fonctions sans serveur

Ces résultats suggèrent que l’usage de templates « Infrastructure-As-Code » dans les processus automatisés de déploiement d'infrastructures, sans vérification préalable pour identifier les configurations non sécurisées ou d'autres vulnérabilités, contribue aux faiblesses du cloud observées dans les déploiements réels. Les cybercriminels ciblent souvent les infrastructures cloud pour déployer des malwares de cryptomining et exploiter la puissance de calcul payée par les victimes. Cependant, certains groupes ne se limitent pas au minage de cryptomonnaie et utilisent les nœuds clouds piratés à d'autres fins malveillantes.

« Il est évident que les erreurs de configuration par défaut contenues dans les templates de configuration IaC faibles ou mal sécurisés sont mises à profit par les attaquants. Ils contournent les pares-feux, les groupes de sécurité ou les politiques Virtual Private Cloud (VPC). Ces erreurs exposent inutilement l'environnement cloud d'une entreprise à des attaques », ont déclaré les chercheurs de Palo Alto. « La sécurité « shift-left » consiste à sécuriser l’environnement le plus en amont possible du processus de développement pour en limiter les impacts ultérieurs. Les entreprises qui appliquent systématiquement ces pratiques et ces procédures dites « shift-left » dans leurs déploiements cloud peuvent rapidement devancer leurs concurrents. Une entreprise a tout intérêt à travailler avec les équipes DevOps pour intégrer ses normes de sécurité dans les modèles IaC. C'est une situation gagnant-gagnant pour le DevOps et la sécurité ».