En 2021, l’économie numérique des données représente de l’ordre de 20% du budget de relance européen qui s’élève à 750 milliards d’euros.
Cette économie, basée sur les algorithmes des plateformes numériques et les données d’usage des industries, fonde son existence sur une gamme de technologies, dites cloud native. Ces technologies sont cloud natives parce qu’elles prennent naissance dans les infrastructures de services cloud qu’elles considèrent comme un prérequis. Portabilité, interopérabilité et partage des données sont les mots-clés des architectures techniques virtualisées portant ces services. Prenons un exemple d’actualité : la 5G. La capacité des opérateurs télécoms à déployer des plateformes numériques pour gérer leurs infrastructures réseaux virtualisées, les seules pertinentes pour les services 5G, est un enjeu stratégique.
Pour s’en convaincre, les livres blancs D’ERICSSON et de NOKIA et l’étude de cas RAKUTEN devraient convenir. Enfin, pour se sentir réellement impliqué, notons qu’un opérateur français des télécommunications souligne, en décembre 2020, dans son plan stratégique 2020-2025, l’importance cruciale de ces applications et infrastructures logicielles en microservices pour assurer son existence et sa compétitivité. Les technologies ne sont pas innovantes, mais incontournables, robustes et éprouvées. La Cloud Native Computing Foundation expose un riche catalogue en 2021 : GIT, HELM, ARGO, KUBERNETES, KUBE EDGE, HARBOR, FALCO.
La communauté de développeurs GitHub, créée en 2008, dispose de plus de 68 millions d’utilisateurs. Docker Hub, créé en 2013, propose une bibliothèque de plus de 100000 images de conteneurs. Un conteneur, rappelons-le, est une petite machine virtuelle complète, qui doit être branchée sur un système d’exploitation hôte pour fonctionner. Netflix, créé en 1997, dispose de plus de 600 services en production et déploie 100 fois par jour; Uber, créé en 2009, a plus de 1000 services et déploie plusieurs milliers de fois par semaine; WeChat, créé en 2011, a environ 3000 services en production et déploie 1000 fois par jour. Aujourd’hui l’agilité et les pratiques DevOps représentent l’ordinaire des ingénieurs. L’automatisation, l’Intelligence Artificielle, les analyses Big data aident au management des développements et à celui de ces infrastructures logicielles complexes pour lesquelles la cybersécurité est un pilier de la confiance.
Les risques techniques majeurs des conteneurs d’applications sont entièrement décrits, depuis 2017, par le National Institute of Standards and Technology, le NIST, une agence du département du Commerce des États-Unis dont le but est de promouvoir l’économie en développant des technologies, la métrologie et des standards de concert avec l’industrie. Le guide de la sécurité des conteneurs d’applications, qu’elle édite, documente les menaces prépondérantes. Il est devenu une référence obligatoire.
Les conteneurs d’applications font l’objet d’une gestion des risques classique :, il s’agit d’identifier, d’éliminer les risques inacceptables puis de gérer les risques résiduels de ces actifs. Les risques, par définition, concernent les répercussions des menaces et des opportunités, des imprévus, des incertitudes sur l’atteinte à la disponibilité, à l’intégrité, à la confidentialité des conteneurs. Ces objectifs de sécurité, nommés DIC, se conjuguent avec les objectifs d’usage de l’actif. En l’occurrence un conteneur vise à la portabilité, l’interopérabilité et au partage des données. L’application est constituée d’un ensemble de conteneurs qui portent chacun un microservice. Donc, la sécurité de l’application implique la sécurité de chaque conteneur, la sécurité des communications entre les conteneurs et la sécurité de l’infrastructure qui apporte les ressources pour alimenter et gérer les conteneurs. Le guide du NIST propose une liste de recommandations auxquelles se conformer. Il peut cependant exister d’autres risques majeurs de sécurité qui dépendent du contexte métier. Donc, la conformité au guide de sécurité et l’analyse des risques spécifiques se complètent.
Les 23 principaux risques NIST pour les conteneurs
Les risques de déploiements et de production
Nous nous concentrerons sur les risques de sécurité du déploiement continu des images (Docker Share-Run), stockées dans un registre externe d’images de base (Docker Hub) ou dans un registre interne d’images parentes (Mirantis/Docker Hub Enterprise, Harbor) vers un orchestrateur (Kubernetes). Ces risques sont abordés de façon à rester agnostique à l’égard des technologies. Les recommandations sont autant pertinentes pour IBM/RedHat Openshift que Docker Kubernetes Service (DKS), dans une optique de sécurisation du passage de la station de développement aux serveurs en production.
Remarque : les risques qui concernent l’intégration continue des images logicielles (Docker Build-Share), à partir d’ajouts ou de fusions de code sur la branche principale (Git push/merge) d’un dépôt de code source (GitHub) vers les registres précités ne sont pas abordés ici.
Risques sur les images
1-Vulnérabilités des images
Les composants d’une image (serveur web, serveur de base de données) peuvent manquer de mises à jour critiques de sécurité ou être obsolètes. Or les conteneurs ne sont pas mis à jour, mais détruits et redéployés à partir d’images à jour. Il y a un risque de générer des conteneurs avec des vulnérabilités.
2-Défauts de configuration des images
Une image mal configurée (privilège utilisateur abusif, SSH daemon inclus) peut augmenter les risques d’attaque, même si l’image est à jour.
3-Malware embarqué
Une image peut embarquer un malware car elle est souvent construite à partir d’une image-modèle qui peut être compromise. Elle pourrait servir à attaquer d’autres conteneurs ou des hôtes dans l’environnement de production.
4-Secret en clair embarqué
Une image, comme une application web, peut contenir des secrets (mot de passe, clé d’API). Toute personne ayant accès à l’image peut facilement l’analyser pour connaître ces secrets.
5-Image non approuvée
Une image non approuvée, contenant des logiciels non fiables peut être utilisée sous la pression de l’urgence, comme un dépannage, du fait de la portabilité et de la réutilisation facile des conteneurs. Le risque est d’introduire un logiciel malveillant, la fuite de données ou la présence de vulnérabilités.
Risques de registre
6-Connexions non sécurisées aux registres
En cas de connexion non sécurisée aux registres, le contenu des images est soumis aux mêmes risques de confidentialité que toute autre donnée transmise en clair.
7-Images périmées dans les registre
Au fil du temps, l’ensemble d’images stockées peut inclure de nombreuses versions vulnérables et obsolètes. La probabilité de déploiement accidentel d’une version connue-vulnérable augmente.
8-Restrictions d’authentification et d’autorisation insuffisantes
Les registres peuvent contenir des images utilisées pour exécuter des applications sensibles ou propriétaires ou pour accéder à des données sensibles. Or les registres sont considérés comme des sources fiables. Leur compromission peut engendrer celle des conteneurs et des hôtes en production.
Risques de l’orchestrateur
9-Accès administratif illimité
Si l’accès fourni aux utilisateurs et aux groupes n’est pas limité à leurs besoins spécifiques, un utilisateur malveillant ou imprudent peut affecter ou perturber le fonctionnement des conteneurs gérés par l’orchestrateur.
10-Accès non autorisé
Les orchestrateurs incluent souvent leur propre service d’annuaire d’authentification. Cela peut conduire à des pratiques de gestion de compte plus faibles et à des comptes « orphelins » dans l’orchestrateur. Or ces comptes sont souvent hautement privilégiés au sein de l’orchestrateur. Leur compromission peut conduire à des compromissions à l’échelle du système tout entier.
11-Trafic réseau inter-conteneurs mal séparé
Bien qu’un réseau chiffré inter-conteneurs offre de nombreux avantages opérationnels et de sécurité, il peut également créer un scénario de « cécité » de sécurité dans lequel les organisations sont incapables de surveiller efficacement le trafic. Si des applications de niveaux de sensibilité différents, comme un site Web public et une application de gestion de trésorerie interne, utilisent le même réseau virtuel inter-conteneurs, les applications internes sensibles peuvent être exposées à un plus grand risque d’attaque.
12-Mélange des niveaux de sensibilité lors de la répartition de charges
L’orchestrateur s’occupe de la mise à l’échelle et de la répartition des charges. Cela signifie que, par défaut, il peut placer des charges de niveaux de sensibilité différents sur le même hôte (un serveur Web public et une application qui traite des données financières sensibles). Dans le cas d’une vulnérabilité critique dans le serveur Web, cela peut exposer le conteneur traitant des données financières sensibles à un risque de compromission considérablement plus élevé.
13-Clusters de confiance
Il est crucial que le niveau de confiance des clusters soit maintenu sans quoi:
- des hôtes non autorisés peuvent rejoindre le cluster et exécuter des conteneurs;
- la compromission d’un seul hôte du cluster implique la compromission de l’ensemble du cluster, par exemple, si les mêmes paires de clés utilisées pour l’authentification sont partagées sur tous les nœuds;
- les communications, entre l’orchestrateur et une équipe DevOps, les administrateurs et les hôtes, peuvent ne pas être chiffrées ni authentifiées.
Risques liés aux conteneurs
14-Vulnérabilités dans le logiciel d’exécution
Les vulnérabilités au sein du logiciel d’exécution sont particulièrement dangereuses si elles permettent des scénarios de « fuite de conteneur » dans lesquels des logiciels malveillants peuvent attaquer des ressources dans d’autres conteneurs et le système d’exploitation hôte lui-même.
15-Accès réseau illimité à partir de conteneurs
Par défaut, dans la plupart des environnements d’exécution de conteneurs, les conteneurs individuels peuvent accéder les uns aux autres ainsi qu’au système d’exploitation hôte via le réseau. Si un conteneur est compromis et agit de manière malveillante, autoriser ce trafic réseau peut exposer d’autres ressources de l’environnement à des risques.
16-Configurations d’exécution de conteneur non sécurisées
Les environnements d’exécution des conteneurs offrent généralement de nombreuses options de configuration aux administrateurs. Leur définition incorrecte peut réduire la sécurité relative du système (modification des appels systèmes, montage de répertoires sensibles sur l’hôte).
17-Vulnérabilités de l’application
Les conteneurs peuvent toujours être compromis en raison de failles dans les applications qu’ils exécutent. Lorsqu’un conteneur est compromis, il peut être mal utilisé de nombreuses manières, par exemple en accordant un accès non autorisé à des informations sensibles ou en activant des attaques contre d’autres conteneurs ou le système d’exploitation hôte.
18-Conteneurs non fiables
Les conteneurs non fiables sont des conteneurs non prévus ou non autorisés dans un environnement. Cela peut être courant, en particulier dans les environnements de développement, où les développeurs d’applications peuvent lancer des conteneurs pour tester leur code. Si ces conteneurs ne sont pas soumis aux rigueurs de l’analyse des vulnérabilités et de la configuration appropriée, ils peuvent être plus vulnérables aux exploits. Les conteneurs non fiables présentent donc un risque supplémentaire pour l’organisation, en particulier lorsqu’ils persistent dans l’environnement sans que les équipes de développement et les administrateurs de sécurité ne soient informés.
Risques du système d’exploitation hôte
19- Grande surface d’attaque
Chaque système d’exploitation hôte a une surface d’attaque, qui regroupe tous les moyens par lesquels les attaquants peuvent tenter d’accéder aux vulnérabilités du système d’exploitation hôte et les exploiter. Plus la surface d’attaque est grande, meilleures sont les chances qu’un attaquant puisse trouver et accéder à une vulnérabilité, conduisant à une compromission du système d’exploitation hôte et des conteneurs qui s’exécutent dessus. Les systèmes d’exploitation hôtes non durcis et réduits à leur portion congrue représentent un risque supplémentaire.
20-Noyau partagé
Les systèmes d’exploitation spécifiques aux conteneurs ont une surface d’attaque beaucoup plus petite que celle des systèmes d’exploitation à usage général. Cependant, bien que les conteneurs fournissent une forte isolation des ressources au niveau logiciel, l’utilisation d’un noyau partagé entraîne invariablement une plus grande surface d’attaque inter-objets que celle observée avec les hyperviseurs, même pour les systèmes d’exploitation spécifiques aux conteneurs.
21- Vulnérabilités des composants du système d’exploitation hôte
Comme tout autre logiciel, ces composants peuvent présenter des vulnérabilités et, du fait de leur positionnement dans les couches basses, ils peuvent avoir un impact sur tous les conteneurs et applications qui s’exécutent sur les hôtes.
22-Droits d’accès utilisateur incorrects
Les organisations sont exposées à des risques lorsque les utilisateurs se connectent directement aux hôtes pour gérer les conteneurs, plutôt que de passer par une couche d’orchestration. La gestion directe permet des modifications importantes du système et de tous les conteneurs qui s’y trouvent, et peut potentiellement permettre à un utilisateur qui n’a besoin que de gérer les conteneurs d’une application spécifique d’avoir un impact sur de nombreux autres.
23-Falsification du système de fichiers du système d’exploitation hôte
Les configurations de conteneur non sécurisées peuvent exposer les volumes hôtes à un plus grand risque de falsification de fichiers. Par exemple, si un conteneur est autorisé à monter des répertoires sensibles sur le système d’exploitation hôte, ce conteneur peut alors modifier les fichiers de ces répertoires. Ces modifications peuvent avoir un impact sur la stabilité et la sécurité de l’hôte et de tous les autres conteneurs qui y sont exécutés.
Conclusion
Nous avons détaillé les 23 risques majeurs des conteneurs d’application du NIST, dans une culture DevOps pure player dont les technologies sont utilisées pour tirer parti de l’économie des données.
La sécurité des conteneurs apporte quelques réponses à la question : « Comment puis-je contribuer à rendre une plate-forme numérique comme Netflix plus sécurisée? ».
Quels sont les points clés ?
- Le premier point à retenir est le rôle crucial du registre interne des images dans la cybersécurité des conteneurs. Des solutions open source comme le registre Harbor et le scanner de vulnérabilité Falco sont disponibles pour traiter la construction des registres de confiance ;
- Le second point à retenir est qu’il n’existe pas de mise à jour de sécurité des conteneurs. En effet, un conteneur vulnérable est détruit. Une nouvelle version de l’image, qui lui correspond, est mise à jour puis stockée dans le registre des images. Un nouveau conteneur est alors généré ;
- Il est regrettable de constater que les configurations par défaut des composants du processus Share-Run ne proposent pas une sécurité acceptable. Donc, la ligne d’étiage des configurations de sécurité reste à constituer ;
- Les composants et les codes logiciels des images de conteneur proviennent d’une grande variété de dépôts non fiables ;
- La viabilité minimum d’une image, d’un conteneur, d’une infrastructure cloud native issus du processus DevOps Build-Share-Run doit impérativement inclure le traitement des risques de sécurité ;
Le dernier point nous montre que les notions de MVP ou minimum viable product et TTM ou time to market sont au cœur de la démarche agile, des pratiques DevOps et des applications en microservices. Il y a donc un changement de paradigme. Il est ainsi nécessaire d’expliquer comment un produit viable doit impérativement être sûr et sécurisé. Dans cette logique de communication sur les essentiels de la sécurité cloud native, nous préparerons d’autres articles sur des sujets tels que les bonnes pratiques de sécurisation des conteneurs, le Secure Access Service Edge, SASE et bien d’autres sujets marquants qui impliquent les savoir-faire Aubay.
