Les conteneurs logiciels ne sont pas une solution miracle
Quelle est la vulnérabilité des conteneurs, derrière leurs nombreux avantages acquis en termes d'agilité, de proximité avec le cloud, et de facilité pour créer des architectures en micro-services ?
La sécurité reste le principal défi
Une erreur courante consiste à trop focaliser son attention sur le conteneur individuel, alors qu’en fait, il est également nécessaire d'examiner de près l'environnement d'exécution. Le conteneur lui-même a beau être sûr et bien sécurisé, cela est inutile s'il peut être compromis au niveau de la machine sur laquelle il tourne. Chaque système hébergeant une plateforme de conteneurs devrait être sécurisé au niveau de chaque couche. La sécurisation des conteneurs commence donc ainsi par le système d'exploitation et la partie réseau de leur hôte.
Un autre problème de sécurité potentiel se situe au niveau du processus de développement lui-même. Trop souvent, les équipes font l’hypothèse que les bibliothèques de code utilisées pour le développement sont sécurisées. Les environnements et frameworks de développement intègrent d'innombrables bibliothèques publiques et ressources externes lors de leur lancement. L'infrastructure dans son ensemble et l'interaction de différents conteneurs et structures cloud deviennent de plus en plus difficiles à appréhender du point de vue de la sécurité du système et donc plus vulnérables aux attaques et à l'exploitation des failles de sécurité. Les bibliothèques de fournisseurs tiers peuvent s'avérer particulièrement dangereuses. Leur intégration permet certes d'économiser des ressources de développement et donc du temps, mais peut aussi représenter un risque de sécurité important.
Il est donc opportun d'accorder une attention accrue à la sécurité des dépendances utilisées par l’application. Une option ici consiste à intégrer une base de données de vulnérabilités qui permet de signaler les vulnérabilités dès le stade de développement et de construction du code, ainsi que de continuer à surveiller les containers lors de leur fonctionnement, puisque de telles vulnérabilités peuvent survenir ultérieurement à la phase de développement. De cette manière, il est possible d'examiner si les failles de sécurité ont un quelconque effet, par exemple si elles sont sur des services exposés ou non, et prioriser ainsi les alertes. La sécurité du système (et donc de l'ensemble de l'entreprise) s’améliore lorsque le nombre de ressources impliquées est réduit au minimum.
En aucun cas des images de conteneurs externes ne doivent être incluses dans le processus de développement sans avoir été vérifiées au préalable. En effet, il existe deux risques potentiels. D'une part, cela affecte la base de code. Ce n'est pas parce qu'une image est mise à la disposition du public qu'elle a fait l'objet d'un contrôle approfondi par le fournisseur. Si cette image constitue ensuite la base de vos propres images utilisées en production, il est recommandé de vérifier qu'elle ne contient pas de logiciels malveillants ni de failles, de la même manière que vous le feriez pour un fichier ou un e-mail entrant.
Le deuxième risque se présente à la fois lors de l'utilisation d'images externes et lors de la conception de votre propre conteneur. Les droits d'accès et les privilèges du système doivent toujours être examinés et remis en question avec un esprit critique. Les autorisations inutiles dans l'environnement hôte peuvent escalader de telle sorte que non seulement le conteneur est compromis, mais l'ensemble du système hôte finit aussi par l’être. En général, l'attribution des droits dans un conteneur doit être aussi granulaire que possible. Idéalement, toutes les commandes, ainsi que celle à l'intérieur d'un conteneur ne sont exécutées que par des utilisateurs sans droits privilégiés.
Enfin, un vecteur d'attaque potentiel résulte d’un mauvais cloisonnement réseau des conteneurs. Seuls les canaux de communication absolument nécessaires doivent être ouverts. Il est important de porter un regard critique sur chaque interaction entre le conteneur, les réseaux, les processus ou même les supports de données externes. La question est toujours de savoir si chaque composant autorisé est réellement nécessaire au fonctionnement de l'application.
La nécessité d’un monitoring continu dans les environnements conteneurisés
D'une part, il y a l'aspect déjà évoqué de la sécurité. Il est bien connu que de nouvelles vulnérabilités sont découvertes (et exploitées) chaque jour. En d'autres termes, l'image qui a été construite hier à partir de composants ne présentant aucune faille de sécurité connue peut déjà être compromise aujourd'hui. Et au bout du compte, cela peut également mettre en danger l'ensemble du système s'il n'est pas correctement isolé. Il est donc nécessaire de surveiller en permanence les environnements conteneurisés à l'aide d'une solution de sécurité qui détecte et informe de manière fiable sur les anomalies et les activités malveillantes.
Le monitoring est exigeant dans la mesure où une « application » dans un environnement informatique moderne peut être constituée de nombreux conteneurs et composants externes. Un contrôle purement manuel n'est pas envisageable pour une équipe d'exploitation. C’est pourquoi il faut choisir une solution de sécurité et de monitoring capable d'identifier rapidement les conteneurs qui violent les directives de sécurité, sur la base d'une politique établie. Grâce aux méthodes de machine learning, il est possible de détecter certaines anomalies à un stade précoce. De cette manière, on peut éviter très en amont une attaque qui ne fait que commencer, voire la prévenir.
Une sécurisation et un monitoring sophistiqués des conteneurs empêchent efficacement le déploiement d'un conteneur présentant des failles de sécurité et permettent d’identifier les conteneurs utilisant des composants vulnérables.
Lors de l'achat d'une solution de monitoring, il est donc conseillé de faire converger les données d'infrastructure, de réseau, des applications et de sécurité informatique vers une plateforme centrale. Le monitoring de l'utilisation du système, l'analyse automatisée des vulnérabilités, la modélisation des menaces, par exemple sur la base du framework MITRE ATT&CK (base de connaissances sur les tactiques et techniques de l'adversaire, fondée sur des observations du monde réel, utilisée dans le monde entier), sont également prises en compte et présentées ici de manière centralisée, tout comme les informations sur l’état du système.
La séparation qui existe encore souvent entre le « Real User Monitoring » et « l’Application Performance Monitoring » devrait être surmontée et normalisée dans le cadre des environnements conteneurisés par l’utilisation des outils appropriés. Un prérequis important ici est que tous les membres de l'équipe puissent accéder aux mêmes informations afin de les examiner ensemble avec l'expertise du développement et de la sécurité.
Les gains en vitesse et agilité ne doivent pas se faire au détriment de la sécurité. Ils offrent au contraire des opportunités à saisir pour transformer le DevOps en DevSecOps afin de faire converger les équipes autour d’un outil commun regroupant et enrichissant les données de monitoring propres à chacune. Cette plateforme commune permet de sensibiliser toutes les équipes aux problèmes de la sécurité en constituant un pivot pour l’analyse et la résolution de problèmes de sécurité par chaque équipe.
La conteneurisation présente de nombreux avantages, si elle est utilisée judicieusement dans le cadre de la tâche à accomplir. Elle permet d'accroître l'efficacité et l'agilité grâce à son potentiel d'automatisation. Elle pose cependant des défis concrets en termes de sécurité du système et donc aussi de monitoring, qui doit être adapté de manière optimale à un tel environnement.