Qu’est-ce que la sécurité des containers ?
La sécurité des containers consiste à sécuriser les containers contre les logiciels malveillants, les fuites de données et les autres menaces à toutes les étapes du cycle de vie des containers. Depuis la création de votre image de container jusqu’à son chargement dans un registre, en passant par son déploiement dans un environnement de production, vous devez mettre en œuvre des outils et des processus pour garantir que le container est sécurisé contre les menaces potentielles.
Cet article présente tout ce que vous devez savoir sur la gestion de la sécurité des containers tout au long de leur cycle de vie.
Menaces courantes à la sécurité des containers
Pour comprendre la sécurité des containers, il faut d’abord comprendre les menaces de sécurité qui peuvent avoir un impact sur les containers.
Ces menaces sont si plurielles qu’il est impossible de toutes les détailler ici. Toutefois, les types les plus courants de menaces pour la sécurité des containers sont les suivants :
Logiciels malveillants et containers
Les logiciels malveillants se présentent sous la forme de code malveillant et sont déployés dans un container. Ce code peut se faufiler dans les containers à plusieurs étapes du cycle de vie du container. Un cybercriminel qui compromet votre environnement CI/CD pourrait insérer un logiciel malveillant dans les dépôts de code source qui sont ensuite utilisés pour créer des images de containers, par exemple. Des attaquants peuvent également s’introduire dans le registre de vos containers et remplacer vos images par des images corrompues contenant des logiciels malveillants. Un troisième type d’attaque par des logiciels malveillants dans des containers consiste à inciter les utilisateurs à télécharger des images de containers malveillantes à partir de sources externes.
Dans tous les cas, les logiciels malveillants qui ne sont pas détectés avant le lancement d’un container pénètrent dans votre environnement d’exécution, ce qui peut entraîner un certain nombre de problèmes de sécurité, comme la collecte de données sensibles d’une application ou la perturbation d’autres containers.
Privilèges de containers insécurisés
En règle générale, les containers doivent fonctionner en mode non privilégié, ce qui signifie qu’ils n’ont accès à aucune ressource en dehors de l’environnement en containers qu’ils contrôlent directement. Les communications entre containers doivent également être limitées, sauf si les containers ont une raison de communiquer entre eux (ce qui serait le cas si, par exemple, vous exécutez un container sidecar qui collecte les journaux d’un container d’application).
Lorsque les containers sont autorisés à fonctionner avec plus de privilèges qu’ils ne l’exigent strictement, il en résulte des risques pour la sécurité. Les privilèges non sécurisés sont généralement dus à des configurations problématiques de l’orchestrateur de containers. Par exemple, les containers orchestrés par Kubernetes peuvent avoir plus de privilèges qu’ils ne devraient si les contextes de sécurité et les politiques réseau de Kubernetes ne sont pas correctement définis.
Containers avec données sensibles
Les containers ne sont pas destinés à être utilisés pour stocker des données. Mais parfois, les organisations commettent l’erreur de stocker des informations sensibles dans les images des containers. Par exemple, Vine a vu tout son code source compromis lorsque quelqu’un a découvert un registre de containers que Vine pensait privé, mais qui était accessible au public, et qui s’est avéré héberger des images contenant le code source. Pour rendre à César ce qui est à César, cela s’est produit relativement tôt dans l’ère des containers, lorsque les meilleures pratiques entourant la gestion des images de containers n’étaient pas encore bien établies. On peut comprendre qu’une telle erreur se soit produite.
Gestion de la sécurité tout au long du cycle de vie des containers
Pour éviter de tels risques, les entreprises doivent mettre en place des contrôles de sécurité qui protègent les containers à toutes les étapes de leur cycle de vie. Voici un aperçu de chaque étape et des types de menaces que les équipes doivent gérer dans chacune d’elles.
Le pipeline de développement
Le cycle de vie des containers commence par le pipeline de développement, d’où provient le code qui sera ensuite intégré aux containers.
Comme indiqué plus haut, les cybercriminels qui compromettent les outils de développement peuvent insérer du code malveillant dans les référentiels de sources, ce qui conduit à une attaque dite de la chaîne d’approvisionnement des logiciels. Si les développeurs n’interceptent pas le code malveillant avant de l’utiliser pour construire des images, le code peut descendre le long du pipeline et atteindre les environnements de production.
La mise en place de contrôles d’accès aux outils de développement et l’application du principe du moindre privilège permettent de prévenir ce risque. Il en va de même pour la recherche de logiciels malveillants dans le code source avant de le construire et de l’expédier.
Images des containers
Une image de container est un fichier qui contient le code nécessaire à l’exécution d’un container. L’image n’est pas le container lui-même, mais plutôt un modèle sur lequel un container en cours d’exécution sera basé. Ainsi, si le contenu d’une image de container comprend des logiciels malveillants ou des données sensibles, les containers créés à partir de cette image ne seront pas sécurisés.
Comme indiqué plus haut, vous devez analyser votre code source interne pour vous assurer que les logiciels malveillants ne s’introduisent pas dans vos images de containers.
Toutefois, comme les images de containers comprennent souvent des ressources importées de sources tierces, l’analyse de votre propre code ne suffit pas. Vous devez également analyser l’ensemble de l’image du container à l’aide d’un scanner de container, qui évaluera le contenu de l’image et signalera tout composant connu comme étant non sécurisé. L’analyse d’images ne peut pas détecter tous les types de menaces (plus précisément, les logiciels malveillants personnalisés qui n’ont pas encore été enregistrés dans les bases de données de vulnérabilités peuvent échapper à la détection), mais elle vous alertera sur la majorité des menaces connues.
Registres de containers
Une fois les images de containers créées, elles sont généralement stockées dans un registre de containers, à partir duquel les utilisateurs peuvent les télécharger.
Il existe quelques bonnes pratiques à suivre pour assurer la sécurité du registre. Tout d’abord, vous devez appliquer des contrôles d’accès pour vous assurer que seuls les utilisateurs autorisés peuvent accéder aux images de votre registre. Cela permet d’éviter les fuites de données accidentelles qui peuvent se produire si les images contiennent des applications ou des données privées.
Deuxièmement, vérifiez à deux fois et régulièrement les registres afin de savoir quelles images ils contiennent. Les images périmées qui contiennent des versions obsolètes d’une application doivent être supprimées afin de réduire vos risques d’être attaqué.
Enfin, lorsque vous travaillez avec des images de containers provenant de registres tiers, assurez-vous que vous faites confiance à la source. La moitié des images de Docker Hub, le registre public de containers le plus fréquenté, comptent au moins une vulnérabilité de sécurité. Et parfois, les cybercriminels téléchargent délibérément des images malveillantes dont les noms (comme mysqlimage ou nginxapp) sont conçus pour attirer les utilisateurs peu méfiants. Évitez d’extraire des images d’un registre public non officiel et veillez à analyser toutes les images, quelle que soit la confiance que vous accordez à l’organisation qui les a créées.
Environnement d’exécution du container
La dernière étape du cycle de vie du container est l’exécution. Les containers sont alors déployés dans un environnement réel à l’aide d’images de containers téléchargées à partir d’un registre.
La sécurité d’exécution est l’un des aspects les plus complexes de la sécurité des containers, car elle implique de multiples pièces mobiles, qui peuvent varier en fonction du type de pile d’applications en containers que vous utilisez. Dans la plupart des cas, cependant, la sécurité d’exécution est basée sur la sécurisation :
- Le moteur d’exécution du container : il s’agit du processus sur le serveur qui exécute réellement les containers. Vous devez vous assurer que votre logiciel d’exécution est à jour et corrigé contre les failles de sécurité connues.
- L’orchestrateur : l’orchestrateur de containers déploie et gère les containers. La plupart des orchestrateurs offrent une variété d’outils pour aider à restreindre les privilèges des containers et réduire les risques de sécurité, mais vous devriez également utiliser des outils de surveillance et d’analyse tiers pour aider à détecter les problèmes de sécurité au niveau de l’orchestrateur.
- Les nœuds : les nœuds sont les serveurs qui hébergent les containers. Vous devez sécuriser le système d’exploitation du nœud, les comptes d’utilisateur, les configurations réseau et d’autres ressources afin de garantir qu’une brèche au niveau du nœud ne permette pas aux cybercriminels d’avoir un impact sur votre environnement de containers.
Sécurité continue des containers
Le cycle de vie d’un container est un processus circulaire et continu. Une fois que les containers d’une application donnée ont été déployés dans un environnement d’exécution, le cycle recommence lorsque l’application est mise à jour, ce qui entraîne l’introduction d’un nouvel ensemble de containers dans le pipeline. Chaque nouveau container pourrait contenir de nouveaux risques.
Ainsi, la sécurité des containers n’est jamais une opération ponctuelle. Vous devez continuellement surveiller les risques tout au long du cycle de vie des containers, tout en mettant à jour vos outils de surveillance, vos bases de données de vulnérabilités et vos configurations pour vous assurer que vous continuez à respecter les meilleures pratiques en matière de sécurité des containers à mesure que votre environnement évolue.