Ce n’est qu’un début !
Bonjour à toi, lecteur intrépide ! Si tu es prêt à te lancer dans l’aventure de la conteneurisation, je te propose de t’accompagner pour une partie cruciale de ta quête : la sécurité.
Que tu sois débutant ou expérimenté, tu trouveras dans cette série d’articles des éléments qui te seront précieux.
Lecteur : « Attends ! Il vient de dire une série d’articles ? »
Oui en effet, comme l’idée est de maintenir un format d’article court, mais accessible aux néophytes, cet article est une introduction à une série plus technique et pratique sur le thème de la sécurité des conteneurs. Parmi les thèmes que nous aborderons dans les articles à venir, nous retrouverons :
- Comment éviter le « supply chain poisonning » sur Docker
- Des techniques d’analyse et de patch de CVE
- Monitoring et détection d’intrusion sur conteneurs
- Un retour d’expérience sur l’utilisation de l’outil Aquasecurity
- Utilisation de docker en « rootless », mise en place et limites
Dans leur utilisation en conditions « réelles », les conteneurs sont utilisés de concert avec des orchestrateurs. Cependant, nous n’aborderons que la question de la sécurité des conteneurs dans cette série d’articles (une autre série dédiée aux orchestrateurs, notamment Kubernetes, sera rédigée ultérieurement).
Sans plus attendre, voici comment est découpé cet article : une première partie servira à rappeler des notions simples sur ce qu’est la conteneurisation, dans une seconde partie, nous analyserons les sources d’attaque.
Conteneur kézako ?
Je suppose que si tu as décidé de t’intéresser à la sécurité des conteneurs, tu as déjà quelques notions, mais je vais tout de même prendre le temps de faire un point rapide sur la question.
La conteneurisation est une technologie qui a été développée pour d’une part isoler et contrôler l’environnement d’exécution d’une application (ou d’une pile applicative, car l’avantage de la conteneurisation est de permettre la mise en place de microservice et ainsi de segmenter les applications) et d’autre part pour permettre d’avoir un déploiement agnostique, stable et invariant de ces éléments.
Pour rentrer un peu plus dans les détails, un conteneur est une instance en cours d’exécution qui est basée sur une image. L’image est un élément construit au préalable, qui est immuable (pour y apporter une modification, il faut la reconstruire).
Comme un conteneur est une instance en cours d’exécution, il est possible d’y apporter des modifications, mais les bonnes pratiques déconseillent de faire une telle chose (cela permet de détecter plus facilement la dérive des conteneurs). Il est possible de lancer plusieurs conteneurs à partir d’une même image et chaque instance évoluera de manière indépendante après leur lancement (les modifications au sein d’un conteneur ne seront pas par défaut propagées aux autres).
De plus, suite à l’arrêt d’un conteneur, tout son contenu sera « perdu » ce qui pose certaines problématiques de persistance des données (il existe tout de même des solutions). Il faut donc garder à l’esprit qu’un conteneur est une instance jetable, qui n’a pas pour vocation d’avoir une longue durée de vie.
Attention cependant, car il ne faut pas confondre conteneur et machine virtuelle. En effet, la conteneurisation repose sur des procédés de virtualisation différents. Ainsi, on parle de virtualisation de système d’exploitation dans le cas des conteneurs, là où les machines virtuelles sont des virtualisations de machine (comprenant donc l’émulation des éléments de Hardware). Cette différence illustrée ci-dessous est cruciale, car elle explique les différences de performance entre VM et conteneur (qui sont donc plus légers et moins gourmands en ressource).
Comprendre les surfaces d’attaque
Il faut dans un premier temps comprendre comment abuser du système pour pouvoir s’en protéger. Il faut retenir que les objectifs des hackers peuvent être multiples (économique, politique, ludique), mais dans la plupart des cas le schéma pour une attaque sur des conteneurs est proche de celle d’un SI :
- Un accès initial au conteneur qui passe soit par une faille de l’application ou du service y étant hébergé, soit par l’exploitation d’une dépendance, soit grâce à du « supply chain poisonning »[1]
- Gagner un maximum de privilèges sur le système
- Explorer l’unité accessible par le réseau pour tenter de collecter un maximum d’informations sur les autres services sur le réseau et les infecter au possible
- Trouver un moyen pour rester de manière persistante sur les éléments infectés (chose contre laquelle une bonne utilisation des conteneurs est censée prémunir)
Dans la figure ci-dessous, j’ai regroupé les différentes techniques utilisables par un pirate pour tirer parti d’une application conteneurisée.
Pour pallier ces risques, il existe plusieurs outils d’analyse à mettre en place lors des différentes phases de vie d’une application conteneurisée.
Ces derniers sont regroupés dans le schéma ci-dessous. Les 5 types d’analyse (SAST, IAST, DAST, SCA et RASP) seront abordés dans les articles à venir, qui nous permettront d’avoir des ateliers pratiques avec des outils adaptés.
Conclusion
Les sources d’attaques sont multiples, mais nous pouvons nous en protéger !
Les conséquences de telles attaques peuvent être plus ou moins graves, allant du vol de ressources de calcul, à la perte de disponibilité de l’application en passant par du vol ou de la destruction de données. Ces éléments ont tous un impact fort sur une entreprise, il est donc essentiel de les prévenir.
L’étape suivante de notre aventure est d’aborder les différentes méthodes pour aboutir à un niveau de sécurité qui correspondra à vos attentes. J’espère que cette introduction vous aura permis d’avoir une idée plus claire des points d’attaques et ainsi que des grandes lignes à suivre pour sécuriser un déploiement. À très bientôt, avec un article plus pratique sur « Comment éviter le supply chain poisonning ?».
par Cédric PAOLI, Consultant Cybersécurité
[1] Il est également possible de passer la machine hôte, mais si vos attaquants en sont à ce stade vous avez une faille de sécurité beaucoup plus importante à patcher que les conteneurs.
