zhu difeng - Fotolia
Conteneurs : des risques spécifiques à prendre en compte
Le recours aux conteneurs peut paraître si simple qu’il est aisé de négliger certains risques spécifiques, et bien réels. Un chantier de plus pour les responsables de la gestion du risque et de la sécurité.
En donnant la possibilité d’isoler des applications ou de simple micro-services dans des caissons virtuels, les conteneurs ont donné une cure de jouvence aux architectures applicatives en place. Mais ce n’est pas un hasard si des jeunes pousses comme Twistlock se penchent sur la question de leur sécurisation : des risques spécifiques sont associés aux conteneurs, en plus de risques plus classiques. Dans un note d’information à ses clients, Gartner ne manque d’ailleurs pas de les souligner.
Neil MacDonald, analyste au sein du cabinet, rappelle ainsi que les conteneurs s’appuient sur un modèle de systèmes d’exploitation partagé. Dès lors, « une attaque sur une vulnérabilité du système d’exploitation hôte peut entraîner la compromission de tous les conteneurs ». S’assurer que le système d’exploitation et son noyau sont bien à jour de correctifs apparaît donc essentiel, de même qu’en assurer la protection localement. Et cela vaut aussi pour les composants embarqués directement dans les conteneurs.
Mais les agents de sécurité traditionnels, déployés en local sur l’hôte, ne sont pas forcément suffisants : ils « ne comprennent pas les conteneurs et n’ont pas le contexte pour mettre en application différentes politiques sur différents conteneurs sur le même hôte ». En outre, les échanges entre conteneurs d’un même hôte peuvent ne pas être visibles aux systèmes de prévention et de détection des intrusions (IPS/IDS) si les configurations réseau ne sont pas spécifiquement adaptées.
Neil MacDonald recommande ainsi le recours à un système d’exploitation aussi léger et durci que possible, comme CoreOS, Red Hat Atomic Host, VMware Photon OS, Ubuntu Core ou encore Microsoft Nano Server. L’analyse conseille également, sous Linux, d’exécuter les conteneurs sans privilèges pour que l’accès à la racine ne soit pas possible en dehors du conteneur.
L’analyste recommande aussi d’analyser les conteneurs au cours de leur développement « pour détecter les problèmes de configuration et de vulnérabilité » avant le transfert dans l’environnement de production, ainsi que de contrôler les processus s’exécutant dans les conteneurs par listes blanches. Docker a, dans ce sens, lancé un outil d'analyse de conteneur début 2016. Il n'est pas le seul ; on peut également regarder du côté de DockerScan, de Clair, de Docker Bench for Security, de Black Duck Hub, ou encore de la plateforme Aqua, notamment. Fin 2015, Toni de la Fuente, architecte sécurité sénior chez Alfresco, présentait un tour d'horizon de solutions, sur son blog.
Surtout, Neil MacDonald appelle à « faire pression » sur les fournisseurs de solutions de sécurité pour qu’ils offrent une prise en charge « explicite » des conteneurs et, plus généralement, des « chaînes d’outils d’intégration et de livraison en continu », notamment pour la gestion des identités et des accès (IAM), les pare-feu, ou encore les systèmes de recherche de vulnérabilités. Et si cela vaut pour faire appliquer les politiques de sécurité, cela vaut aussi pour la mise à disposition des API nécessaires à l’intégration des outils de sécurité dans la chaîne de développement continu.
Enfin, Neil MacDonald suggère de répartir les conteneurs par hôtes en fonction du niveau de confiance et de criticité des traitements concernés, et mettre en place des mécanismes d’isolation par niveaux de confiance - en s’appuyant sur une segmentation physique ou sur la virtualisation.
