Pratiquer la conteneurisation en toute sécurité
Tout le monde sait que Kubernetes a remporté la guerre des conteneurs. Mais ce que Kubernetes a gagné, c’est la guerre des environnements d’exécution des conteneurs. Vous voyez, la guerre des images de conteneurs a été gagnée par Docker. Cela peut être constaté dans la statistique selon laquelle plus d'un milliard de conteneurs Docker sont téléchargés toutes les deux semaines selon le rapport sur l'état de la sécurité open source 2019 . Docker Hub est devenu pour l’entreprise ce que l’AppStore d’Apple et Google Play sont pour les consommateurs.
Les images de conteneurs couvrent toute la gamme des systèmes d'exploitation de base aux piles d'applications, des bases de données aux intergiciels en passant par les moteurs d'application prenant en charge Node.js, Python et Go. Ils incluent même des intégrations d’écosystèmes pour les services d’application .
Si vous faites partie de la majorité des organisations déployant des conteneurs, vous déployez probablement des images Docker dans un environnement Kubernetes.
Et si vous faites cela , vous déployez probablement également des images de conteneurs vulnérables. L'étude susmentionnée de Snyk a révélé que « chacune des dix images Docker par défaut les plus populaires contient au moins 30 bibliothèques système vulnérables ». Il est courant, poursuit le rapport, « que les bibliothèques système soient disponibles dans de nombreuses images Docker, car celles-ci s'appuient sur une image parent qui utilise généralement une distribution Linux comme base ».
Nous avons donc un grand nombre d’images vulnérables téléchargées en permanence par des organisations. Selon Snyk, le nombre de vulnérabilités augmente régulièrement dans les trois principales distributions Linux.
Il n'est donc pas surprenant que l'étude 2019 de Tripwire sur l'état de la sécurité des conteneurs ait révélé qu'un pourcentage stupéfiant de 60 % des répondants avaient été victimes d'un incident de sécurité lié à un conteneur au cours des douze derniers mois. Pour près d'une personne sur cinq (17 %), cela est probablement dû au fait que l'organisation était consciente des vulnérabilités, mais les a quand même déployées. Et ce malgré les conclusions de Snyk selon lesquelles pour 44 % des images Docker contenant des vulnérabilités connues, il existait des images de base plus récentes et plus sécurisées. En d’autres termes, le simple fait de récupérer une image à jour aurait atténué le risque. 22 % supplémentaires de ces images présentant des vulnérabilités auraient pu être traitées simplement en reconstruisant l’image.
Vraiment. Je ne peux pas inventer ça.
Une grande partie de l'attention portée au « déplacement de la sécurité vers la gauche » porte autant sur le déploiement de services d'application de sécurité appropriés (défense BOT, pare-feu d'applications Web, contrôle d'identité et d'accès) que sur l'intégration de pratiques sécurisées dans le cycle de vie de développement et de livraison. Ces pratiques incluent l’analyse du code et des conteneurs à la recherche de vulnérabilités connues , puis leur traitement .
Cette priorité était destinée aux 17 % d’entre vous qui connaissaient les vulnérabilités d’une image de conteneur mais qui l’ont déployée sans y remédier.
Nous pouvons faire mieux que cela. Oui, la vitesse est importante, mais la vitesse sans sécurité est dangereuse, non seulement pour l'organisation, mais aussi pour les clients qui utilisent en fin de compte les applications que vous vous dépêchez de sortir.
Si vous ne pratiquez pas encore la conteneurisation sécurisée, pensez à mettre en pratique ces étapes :
- Évaluer l'utilisation. De nombreuses organisations ne sont pas conscientes de l’ampleur de leur consommation de sources/images ouvertes et tierces. Comprendre cela est une première étape importante. Vous ne pouvez pas corriger les vulnérabilités d’un logiciel que vous utilisez sans même le savoir.
- Standardiser. Essayez de trouver un terrain d’entente entre les applications et les opérations et de standardiser le moins d’images/composants de conteneur possible. Cela permettra de répartir la charge de sécurité au sein de l’organisation et, en fin de compte, d’améliorer la sécurité pour tous.
- Révisions de codes sécurisées. Si vous incluez des composants ou des scripts tiers (et c'est presque certainement le cas), examinez-les et livrez-les/construisez-les à partir d'un référentiel privé.
- Audits de conteneurs sécurisés. Si vous utilisez des images tierces, vérifiez et certifiez leur sécurité, puis livrez-les à partir d’un référentiel privé.
- Abonnez-vous aux chaînes de sécurité. Si vous vous appuyez sur une image ou un code source, recherchez et abonnez-vous aux canaux par lesquels ils communiquent les vulnérabilités potentielles. Après tout, savoir c’est déjà la moitié de la bataille.