Les conteneurs ont r\u00e9volutionn\u00e9 le processus de d\u00e9veloppement, agissant comme la pierre angulaire des initiatives DevOps, mais les conteneurs pr\u00e9sentent des risques de s\u00e9curit\u00e9 complexes qui ne sont pas toujours \u00e9vidents. Les organisations qui n’att\u00e9nuent pas ces risques sont vuln\u00e9rables aux attaques. <\/p>\n
Dans cet article, nous d\u00e9crivons comment les conteneurs ont contribu\u00e9 au d\u00e9veloppement agile, quels risques de s\u00e9curit\u00e9 uniques les conteneurs apportent dans l’image – et ce que les organisations peuvent faire pour s\u00e9curiser les charges de travail conteneuris\u00e9es, allant au-del\u00e0 de DevOps pour atteindre DevSecOps<\/em>.<\/p>\n Les conteneurs sont, \u00e0 bien des \u00e9gards, l’\u00e9volution de la virtualisation. L’objectif \u00e9tait d’acc\u00e9l\u00e9rer le processus de d\u00e9veloppement, en cr\u00e9ant une voie plus agile du d\u00e9veloppement aux tests et \u00e0 la mise en \u0153uvre – une m\u00e9thode plus l\u00e9g\u00e8re que l’utilisation de machines virtuelles compl\u00e8tes, de toute fa\u00e7on.<\/p>\n Au c\u0153ur de ce probl\u00e8me se trouve la compatibilit\u00e9 des applications, car les applications n\u00e9cessitent certaines versions de biblioth\u00e8ques, ce qui pourrait entrer en conflit avec les exigences d’autres applications. Les conteneurs ont r\u00e9solu ce probl\u00e8me et se sont bien reli\u00e9s aux processus de d\u00e9veloppement et \u00e0 l’infrastructure de gestion qui pilote ces processus.<\/p>\n Les conteneurs font leur travail en faisant passer la virtualisation au niveau sup\u00e9rieur. La virtualisation fait abstraction de la couche mat\u00e9rielle, tandis que les conteneurs font abstraction de la couche du syst\u00e8me d’exploitation, virtualisant essentiellement le r\u00f4le du syst\u00e8me d’exploitation. La conteneurisation fonctionne en empaquetant les applications dans des “conteneurs” qui incluent toutes les biblioth\u00e8ques n\u00e9cessaires pour faire fonctionner une application, tout en gardant les applications ignorantes les unes des autres car chaque application pense qu’elle a le syst\u00e8me d’exploitation pour elle-m\u00eame.<\/p>\n Fonctionnellement, les conteneurs sont assez simples – un conteneur est juste un fichier texte avec une description indiquant quels composants doivent \u00eatre inclus dans une instance. Cette simplicit\u00e9 et la nature plus l\u00e9g\u00e8re d’un conteneur facilitent l’utilisation des outils d’automatisation (orchestration) pour le d\u00e9ploiement tout au long du cycle de d\u00e9veloppement.<\/p>\n Les conteneurs ont le pouvoir d’augmenter consid\u00e9rablement l’efficacit\u00e9 du d\u00e9veloppement – agissant comme les cl\u00e9s qui d\u00e9verrouillent DevOps. C’est probablement l’une des principales raisons pour lesquelles les conteneurs se sont r\u00e9pandus si largement, Gartner estimant que d’ici 2023, 70\u00a0% des organisations ex\u00e9cuteront des charges de travail conteneuris\u00e9es<\/a>. <\/p>\n Le processus de d\u00e9veloppement, de test et de d\u00e9ploiement d’applications \u00e9tait auparavant rempli d’obstacles, avec un va-et-vient constant entre les d\u00e9veloppeurs et les \u00e9quipes charg\u00e9es de l’infrastructure. Aujourd’hui, gr\u00e2ce aux conteneurs, les d\u00e9veloppeurs peuvent cr\u00e9er et tester dans un environnement qui fonctionne et exp\u00e9dier simplement le code fini avec une sp\u00e9cification qui d\u00e9finit cet environnement.<\/p>\n Du c\u00f4t\u00e9 op\u00e9rationnel, les \u00e9quipes se contentent d’ex\u00e9cuter cette sp\u00e9cification pour cr\u00e9er un environnement correspondant pr\u00eat \u00e0 l’emploi. “Oui, mais \u00e7a marche sur ma machine\u2026” n’a jamais aid\u00e9 \u00e0 r\u00e9soudre le probl\u00e8me – mais aujourd’hui, c’est une expression que les d\u00e9veloppeurs n’ont plus besoin d’utiliser car il n’y a pas de probl\u00e8mes environnementaux \u00e0 d\u00e9boguer.<\/p>\n Donc, oui, DevOps signifie d\u00e9veloppement rapide. Mais il manque un \u00e9l\u00e9ment : la s\u00e9curit\u00e9. C’est pourquoi nous entendons de plus en plus parler de DevSecOps \u00e0 mesure qu’il \u00e9volue \u00e0 partir de DevOps, car les d\u00e9veloppeurs ont remarqu\u00e9 que le mod\u00e8le DevOps seul ne r\u00e9pond pas suffisamment aux probl\u00e8mes de s\u00e9curit\u00e9.<\/p>\n Les conteneurs simplifient le processus de d\u00e9veloppement mais introduisent de la complexit\u00e9 dans l’image de la s\u00e9curit\u00e9. Lorsque vous emballez \u00e9troitement un environnement d’exploitation entier dans un conteneur uniquement pour le distribuer largement, vous augmentez \u00e9galement la surface d’attaque et ouvrez la porte \u00e0 diff\u00e9rents vecteurs d’attaque. Toutes les biblioth\u00e8ques vuln\u00e9rables fournies avec le conteneur propageront ces vuln\u00e9rabilit\u00e9s sur d’innombrables charges de travail.<\/p>\n Il existe plusieurs risques. L’une est une “attaque de la cha\u00eene d’approvisionnement” o\u00f9 un acteur malveillant monte une attaque non pas en jouant avec votre application, mais en modifiant l’un des packages ou composants fournis avec votre application. Ainsi, les \u00e9quipes charg\u00e9es des efforts de d\u00e9veloppement doivent \u00e9valuer l’application qu’elles d\u00e9veloppent et chaque biblioth\u00e8que int\u00e9gr\u00e9e en tant que d\u00e9pendance par la configuration du conteneur.<\/p>\n Les risques pour la s\u00e9curit\u00e9 des conteneurs impliquent \u00e9galement les outils qui activent les conteneurs – des Dockers aux outils d’orchestration tels que Kubernetes, car ces outils doivent \u00eatre surveill\u00e9s et prot\u00e9g\u00e9s. Vous ne devriez pas, par exemple, autoriser les administrateurs syst\u00e8me \u00e0 ex\u00e9cuter des conteneurs Docker en tant que root. De m\u00eame, vous devez surveiller de pr\u00e8s vos registres de conteneurs pour vous assurer qu’ils ne sont pas compromis.<\/p>\n Certains des risques de s\u00e9curit\u00e9 li\u00e9s aux conteneurs sont moins visibles que d’autres. Chaque conteneur a besoin d’acc\u00e9der \u00e0 un noyau – apr\u00e8s tout, les conteneurs ne sont qu’un type d’isolation de processus avanc\u00e9. Mais il est facile de passer \u00e0 c\u00f4t\u00e9 du fait que tous les conteneurs reposent sur le m\u00eame noyau \u2013 peu importe que les applications \u00e0 l’int\u00e9rieur des conteneurs soient s\u00e9par\u00e9es les unes des autres. <\/p>\n Le noyau que les applications d’un conteneur voient est le m\u00eame que le noyau sur lequel l’h\u00f4te s’appuie pour fonctionner. Cela pose quelques probl\u00e8mes. Si le noyau de l’h\u00f4te qui prend en charge le conteneur est vuln\u00e9rable \u00e0 un exploit, cette vuln\u00e9rabilit\u00e9 peut \u00eatre exploit\u00e9e en lan\u00e7ant une attaque \u00e0 partir d’une application \u00e0 l’int\u00e9rieur d’un conteneur.<\/p>\n Ainsi, le fait que le noyau soit partag\u00e9 par tous les conteneurs sur l’h\u00f4te signifie qu’un noyau d\u00e9fectueux doit \u00eatre corrig\u00e9 rapidement, sinon tous les conteneurs peuvent \u00eatre rapidement affect\u00e9s par la vuln\u00e9rabilit\u00e9.<\/p>\n La mise \u00e0 jour du noyau de l’h\u00f4te est donc une \u00e9tape importante pour garantir des op\u00e9rations de conteneur s\u00fbres et s\u00e9curis\u00e9es. Et ce n’est pas seulement le noyau qui a besoin d’\u00eatre corrig\u00e9, les correctifs doivent \u00eatre appliqu\u00e9s aux biblioth\u00e8ques extraites par un conteneur. Mais, comme nous le savons, appliquer syst\u00e9matiquement des correctifs est plus facile \u00e0 dire qu’\u00e0 faire. C’est probablement pourquoi une \u00e9tude a r\u00e9v\u00e9l\u00e9 que 75\u00a0% des conteneurs analys\u00e9s contenaient une vuln\u00e9rabilit\u00e9<\/a> class\u00e9 comme critique ou \u00e0 haut risque.<\/p>\n Ces vuln\u00e9rabilit\u00e9s peuvent conduire, par exemple, \u00e0 des attaques par \u00e9vasion o\u00f9 un attaquant s’appuie sur une biblioth\u00e8que d\u00e9fectueuse dans un conteneur pour pouvoir ex\u00e9cuter du code en dehors du conteneur. En violant un conteneur, l’attaquant peut \u00e9ventuellement atteindre sa cible, qu’il s’agisse du syst\u00e8me h\u00f4te ou d’une application dans un autre conteneur.<\/p>\n Dans le contexte des conteneurs, la maintenance de biblioth\u00e8ques s\u00e9curis\u00e9es peut \u00eatre un vrai casse-t\u00eate \u2013 quelqu’un doit suivre les nouvelles vuln\u00e9rabilit\u00e9s ainsi que ce qui a \u00e9t\u00e9 corrig\u00e9 et ce qui ne l’a pas \u00e9t\u00e9. Le processus est laborieux, mais il n\u00e9cessite \u00e9galement des comp\u00e9tences sp\u00e9cialis\u00e9es, ce que votre organisation devrait acqu\u00e9rir si elle ne les poss\u00e8de pas d\u00e9j\u00e0.<\/p>\n Compte tenu de la valeur des correctifs r\u00e9guliers et coh\u00e9rents, ces raisons ne devraient pas \u00eatre suffisantes pour provoquer le type de routines de correctifs al\u00e9atoires que nous voyons, mais – en particulier lorsque l’on pense au noyau du syst\u00e8me d’exploitation – la perturbation des red\u00e9marrages requis et les Le besoin de maintenir des fen\u00eatres de temps d’arr\u00eat peut retarder consid\u00e9rablement l’application des correctifs. Correctif du noyau en direct<\/a> permet d’att\u00e9nuer ce probl\u00e8me, mais il n’est pas encore d\u00e9ploy\u00e9 par toutes les organisations.<\/p>\n Il est courant que les technologies de pointe introduisent de nouvelles complications en mati\u00e8re de s\u00e9curit\u00e9 des informations. Les nouveaux outils conduisent g\u00e9n\u00e9ralement \u00e0 de nouveaux exploits. C’est \u00e9galement vrai pour les conteneurs et m\u00eame si cela ne compromet pas la valeur globale de l’utilisation des conteneurs dans vos charges de travail, cela signifie que vous devez garder un \u0153il sur les risques pos\u00e9s par les conteneurs.<\/p>\n \u00c9duquer vos d\u00e9veloppeurs et administrateurs syst\u00e8me sur les failles courantes de la s\u00e9curit\u00e9 des conteneurs et les meilleures pratiques qui att\u00e9nuent ces failles est un d\u00e9but. Patcher<\/a> est un autre aspect important. Comme toujours, mettre en place les bonnes mesures pour att\u00e9nuer les failles de cybers\u00e9curit\u00e9 aidera \u00e0 prot\u00e9ger votre organisation et permettra \u00e0 votre \u00e9quipe de b\u00e9n\u00e9ficier de cette technologie de pointe sans souffrir de nuits blanches.<\/p>\n <\/p>\n<\/div>\nPourquoi les conteneurs se sont-ils r\u00e9pandus si vite ?<\/h2>\n
DevOps pour la victoire\u2026 mais la s\u00e9curit\u00e9 compte aussi<\/h2>\n
Les conteneurs pr\u00e9sentent plusieurs risques de s\u00e9curit\u00e9<\/h2>\n
La s\u00e9curit\u00e9 du noyau au c\u0153ur de la s\u00e9curit\u00e9 des conteneurs<\/h2>\n
Encore une fois, il s’agit de patcher<\/h2>\n
Incluez toujours des objectifs de s\u00e9curit\u00e9 dans vos op\u00e9rations de conteneur<\/h2>\n