Les conteneurs sont partout : comment les sécuriser ?
Les conteneurs sont de plus en plus nombreux chaque jour et semblent être partout, car les organisations sont impatientes de profiter des nombreux avantages qu’ils offrent, tels que le développement et le déploiement agiles d’applications sur toutes les plateformes.
Beaucoup pensent également que l’utilisation de conteneurs peut les aider à minimiser les contraintes de sécurité en raison de leur courte durée de vie. Est-ce vrai ou juste une autre idée fausse?
Bien que les conteneurs ne présentent pas d’insécurités inhérentes, ils sont souvent déployés de manière non sécurisée, ce qui entraîne de nombreux problèmes de sécurité.
Défis de sécurité lors du déploiement de conteneurs
Le nombre, la polyvalence et l’état éphémère des conteneurs déployés, ainsi que le fait que les conteneurs doivent communiquer avec d’autres entités, empêchent les organisations de posséder une visibilité adéquate du trafic inter-conteneurs.
Grâce à ce manque de visibilité, les conteneurs sont souvent oubliés, et les mesures de prévention des intrusions et les contrôles de sécurité deviennent inefficaces, augmentant la surface d’attaque et donc le risque global de l’entreprise. De plus, le manque de visibilité peut entraîner un manque de responsabilité, car les conteneurs traversent différents environnements, du développement à la production.
Un autre défi de sécurité lié aux conteneurs est la mauvaise gestion des vulnérabilités. Par exemple, lors du clonage d’images existantes pour créer de nouveaux conteneurs, leurs vulnérabilités seront également répliquées.
Cela met en évidence la nécessité pour la sécurité de faire partie intégrante de la stratégie organisationnelle des conteneurs. Sinon, des erreurs de configuration et des correctifs manquants peuvent être à l’origine du déploiement et de l’exécution d’images non autorisées dans des environnements de production, entraînant une surface d’attaque accrue et des attaques plus réussies.
Enfin, étant donné que les conteneurs utilisent un noyau de système d’exploitation partagé, une compromission du noyau du système d’exploitation hôte par un conteneur malveillant peut entraîner une perte d’accès à tout ou partie des conteneurs en cours d’exécution sur l’hôte, ainsi qu’à d’autres hôtes potentiels sur le réseau.
Comment sécuriser vos conteneurs
Peut-être que la meilleure pratique pour sécuriser votre environnement conteneurisé est de reconnaître la nécessité de le faire. Hormis ce concept fondamental, il y a quelques bons conseils à suivre pour sécuriser efficacement vos conteneurs.
Avoir une visibilité sur vos conteneurs
Avant de déployer un conteneur, assurez-vous de bien comprendre ses dépendances et ce qu’il contient. Pour vous assurer que vos images de conteneurs sont impeccables, vous devez gagner en visibilité à chaque étape, du développement à la production.
Ne pas faire confiance au logiciel d’un conteneur est un excellent point de départ. Vous devez le vérifier très attentivement pour comprendre "d’où ils viennent, comment ils ont été produits et leurs sources correspondantes", comme l’a souligné Dirk Hohndel, vice-président de VMware, lors de l’ Open Source Leadership Summit 2019.
En un mot, vérifiez le contenu de vos conteneurs avant de les déployer et n’exécutez jamais un conteneur avec un logiciel inconnu ou obsolète. Ce n’est pas parce qu’une image de conteneur prétend contenir les programmes et les bibliothèques les plus récents et les plus performants qu’elle le fait réellement.
Une façon d’atténuer ce problème consiste à utiliser des applications qui peuvent vous aider à nettoyer vos conteneurs. Bien que je n’aime pas réinventer la roue, la meilleure approche est peut-être d’arrêter d’utiliser les images de conteneurs d’autres personnes.
Si vous, tout comme Hercules, prenez la route plus difficile de Virtue et commencez à créer vos propres images de conteneurs, vous aurez une bien meilleure compréhension de ce qui se passe dans les conteneurs, ce qui a des avantages au-delà de la sécurité.
Contrôler l’accès root
La plupart des conteneurs sont construits avec un accès root par défaut. Cependant, il s’agit d’une pratique discutable. Bien qu’il soit plus facile pour les développeurs d’exécuter des conteneurs en tant que root, l’accès root présente d’énormes risques.
Il existe plusieurs approches pour traiter ce problème. Une façon consiste à vérifier une politique d’entreprise selon laquelle aucun conteneur n’est jamais autorisé à s’exécuter en tant que racine. Une autre façon consiste à appliquer le principe du moindre privilège. Vous pouvez spécifier un utilisateur non root dans le Dockerfile, lorsque vous créez une image de conteneur, pour exécuter le conteneur en tant qu’utilisateur spécifique avec l’accès système minimum requis.
Enfin, vous pouvez également utiliser l’espace de noms d’utilisateur lors de l’exécution de processus de conteneur privilégiés pour aider les conteneurs sécurisés. Avec cette méthode, l’UID pour exécuter ces processus dans le conteneur est zéro (qui est la racine), mais à l’extérieur du conteneur, l’UID est le 1000 non privilégié.
Vérifier l’exécution du conteneur
Le SP 800-190 «Application Container Security Guide» du National Institute of Standards and Technology (NIST) indique que les environnements d’exécution des conteneurs sont également vulnérables aux attaques. Bien qu’il ne s’agisse pas d’une faille de sécurité courante, le NIST souligne que les vulnérabilités de sécurité d’exécution des conteneurs peuvent être « particulièrement dangereuses » si elles autorisent des scénarios dans lesquels des logiciels malveillants peuvent attaquer des ressources dans d’autres conteneurs et le système d’exploitation hôte lui-même.
Un attaquant peut également être en mesure d’exploiter des vulnérabilités pour compromettre le logiciel d’exécution lui-même, puis modifier ce logiciel afin qu’il permette à l’attaquant d’accéder à d’autres conteneurs, de surveiller les communications de conteneur à conteneur, etc.
Les problèmes de sécurité sont beaucoup plus fréquents avec les configurations d’exécution. Les runtimes de conteneur exposent généralement de nombreuses options configurables. Leur configuration incorrecte peut réduire la sécurité relative du système.
Par exemple, sur les hôtes de conteneur Linux, l’ensemble des appels système autorisés est souvent limité par défaut à ceux requis pour un fonctionnement sûr des conteneurs. Si cette liste est élargie, cela peut exposer les conteneurs et le système d’exploitation hôte à un risque accru d’un conteneur compromis.
De même, si un conteneur est exécuté en mode privilégié, il a accès à tous les périphériques de l’hôte, ce qui lui permet d’agir essentiellement dans le cadre du système d’exploitation hôte et d’avoir un impact sur tous les autres conteneurs qui y sont exécutés.
Un autre exemple de configuration d’exécution non sécurisée consiste à autoriser les conteneurs à monter des répertoires sensibles sur l’hôte. Si un conteneur compromis peut apporter des modifications à ces chemins, il peut être utilisé pour élever les privilèges et attaquer l’hôte lui-même ainsi que d’autres conteneurs exécutés sur l’hôte.
Renforcer le système d’exploitation
Le NIST recommande également d’ exécuter un système d’exploitation spécifique au conteneur, car les menaces sont généralement plus minimes, car les systèmes d’exploitation sont spécifiquement conçus pour héberger des conteneurs et ont d’autres services et fonctionnalités désactivés.
De plus, comme ces systèmes d’exploitation optimisés sont conçus spécifiquement pour héberger des conteneurs, ils comportent généralement des systèmes de fichiers en lecture seule et utilisent d’autres pratiques de renforcement par défaut. Dans la mesure du possible, les organisations doivent utiliser ces systèmes d’exploitation minimalistes pour réduire leurs surfaces d’attaque et atténuer les risques typiques et les activités de renforcement associés aux systèmes d’exploitation à usage général.
Les organisations qui ne peuvent pas utiliser un système d’exploitation spécifique au conteneur doivent suivre les instructions du NIST SP 800-123, Guide to General Server Security pour réduire autant que possible la surface d’attaque de leurs hôtes.
Par exemple, les hôtes qui exécutent des conteneurs ne doivent exécuter que des conteneurs et non d’autres applications, comme un serveur Web ou une base de données, en dehors des conteneurs. Le système d’exploitation hôte ne doit pas exécuter de services système inutiles, tels qu’un spouleur d’impression, qui augmentent sa surface d’attaque.
Enfin, les hôtes doivent être analysés en permanence pour détecter les vulnérabilités et les mises à jour doivent être appliquées rapidement, non seulement à l’exécution du conteneur, mais également aux composants de niveau inférieur tels que le noyau sur lequel les conteneurs s’appuient pour un fonctionnement sécurisé et compartimenté.
La sécurité des conteneurs est une priorité absolue
Avec de plus en plus d’entreprises adoptant et déployant des conteneurs, leur sécurité devient une priorité commerciale majeure. Selon un récent sondage, 94 % des personnes interrogées ont subi un incident de sécurité dans leurs environnements de conteneurs. Cela ne fait que souligner à quel point il est important d’obtenir des droits de sécurité sur les conteneurs pour protéger votre entreprise et vos clients.