Les conteneurs ont révolutionné le processus de développement, agissant comme la pierre angulaire des initiatives DevOps, mais les conteneurs présentent des risques de sécurité complexes qui ne sont pas toujours évidents. Les organisations qui n’atténuent pas ces risques sont vulnérables aux attaques.

Dans cet article, nous décrivons comment les conteneurs ont contribué au développement agile, quels risques de sécurité uniques les conteneurs apportent dans l’image – et ce que les organisations peuvent faire pour sécuriser les charges de travail conteneurisées, allant au-delà de DevOps pour atteindre DevSecOps.

Pourquoi les conteneurs se sont-ils répandus si vite ?

Les conteneurs sont, à bien des égards, l’évolution de la virtualisation. L’objectif était d’accélérer le processus de développement, en créant une voie plus agile du développement aux tests et à la mise en œuvre – une méthode plus légère que l’utilisation de machines virtuelles complètes, de toute façon.

Au cœur de ce problème se trouve la compatibilité des applications, car les applications nécessitent certaines versions de bibliothèques, ce qui pourrait entrer en conflit avec les exigences d’autres applications. Les conteneurs ont résolu ce problème et se sont bien reliés aux processus de développement et à l’infrastructure de gestion qui pilote ces processus.

Les conteneurs font leur travail en faisant passer la virtualisation au niveau supérieur. La virtualisation fait abstraction de la couche matérielle, tandis que les conteneurs font abstraction de la couche du système d’exploitation, virtualisant essentiellement le rôle du système d’exploitation. La conteneurisation fonctionne en empaquetant les applications dans des « conteneurs » qui incluent toutes les bibliothèques nécessaires pour faire fonctionner une application, tout en gardant les applications ignorantes les unes des autres car chaque application pense qu’elle a le système d’exploitation pour elle-même.

Fonctionnellement, les conteneurs sont assez simples – un conteneur est juste un fichier texte avec une description indiquant quels composants doivent être inclus dans une instance. Cette simplicité et la nature plus légère d’un conteneur facilitent l’utilisation des outils d’automatisation (orchestration) pour le déploiement tout au long du cycle de développement.

DevOps pour la victoire… mais la sécurité compte aussi

Les conteneurs ont le pouvoir d’augmenter considérablement l’efficacité du développement – agissant comme les clés qui déverrouillent DevOps. C’est probablement l’une des principales raisons pour lesquelles les conteneurs se sont répandus si largement, Gartner estimant que d’ici 2023, 70 % des organisations exécuteront des charges de travail conteneurisées.

Le processus de développement, de test et de déploiement d’applications était auparavant rempli d’obstacles, avec un va-et-vient constant entre les développeurs et les équipes chargées de l’infrastructure. Aujourd’hui, grâce aux conteneurs, les développeurs peuvent créer et tester dans un environnement qui fonctionne et expédier simplement le code fini avec une spécification qui définit cet environnement.

Du côté opérationnel, les équipes se contentent d’exécuter cette spécification pour créer un environnement correspondant prêt à l’emploi. « Oui, mais ça marche sur ma machine… » n’a jamais aidé à résoudre le problème – mais aujourd’hui, c’est une expression que les développeurs n’ont plus besoin d’utiliser car il n’y a pas de problèmes environnementaux à déboguer.

Donc, oui, DevOps signifie développement rapide. Mais il manque un élément : la sécurité. C’est pourquoi nous entendons de plus en plus parler de DevSecOps à mesure qu’il évolue à partir de DevOps, car les développeurs ont remarqué que le modèle DevOps seul ne répond pas suffisamment aux problèmes de sécurité.

Les conteneurs présentent plusieurs risques de sécurité

Les conteneurs simplifient le processus de développement mais introduisent de la complexité dans l’image de la sécurité. Lorsque vous emballez étroitement un environnement d’exploitation entier dans un conteneur uniquement pour le distribuer largement, vous augmentez également la surface d’attaque et ouvrez la porte à différents vecteurs d’attaque. Toutes les bibliothèques vulnérables fournies avec le conteneur propageront ces vulnérabilités sur d’innombrables charges de travail.

Il existe plusieurs risques. L’une est une « attaque de la chaîne d’approvisionnement » où 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 équipes chargées des efforts de développement doivent évaluer l’application qu’elles développent et chaque bibliothèque intégrée en tant que dépendance par la configuration du conteneur.

Les risques pour la sécurité des conteneurs impliquent également les outils qui activent les conteneurs – des Dockers aux outils d’orchestration tels que Kubernetes, car ces outils doivent être surveillés et protégés. Vous ne devriez pas, par exemple, autoriser les administrateurs système à exécuter des conteneurs Docker en tant que root. De même, vous devez surveiller de près vos registres de conteneurs pour vous assurer qu’ils ne sont pas compromis.

La sécurité du noyau au cœur de la sécurité des conteneurs

Certains des risques de sécurité liés aux conteneurs sont moins visibles que d’autres. Chaque conteneur a besoin d’accéder à un noyau – après tout, les conteneurs ne sont qu’un type d’isolation de processus avancé. Mais il est facile de passer à côté du fait que tous les conteneurs reposent sur le même noyau – peu importe que les applications à l’intérieur des conteneurs soient séparées les unes des autres.

Le noyau que les applications d’un conteneur voient est le même que le noyau sur lequel l’hôte s’appuie pour fonctionner. Cela pose quelques problèmes. Si le noyau de l’hôte qui prend en charge le conteneur est vulnérable à un exploit, cette vulnérabilité peut être exploitée en lançant une attaque à partir d’une application à l’intérieur d’un conteneur.

Ainsi, le fait que le noyau soit partagé par tous les conteneurs sur l’hôte signifie qu’un noyau défectueux doit être corrigé rapidement, sinon tous les conteneurs peuvent être rapidement affectés par la vulnérabilité.

Encore une fois, il s’agit de patcher

La mise à jour du noyau de l’hôte est donc une étape importante pour garantir des opérations de conteneur sûres et sécurisées. Et ce n’est pas seulement le noyau qui a besoin d’être corrigé, les correctifs doivent être appliqués aux bibliothèques extraites par un conteneur. Mais, comme nous le savons, appliquer systématiquement des correctifs est plus facile à dire qu’à faire. C’est probablement pourquoi une étude a révélé que 75 % des conteneurs analysés contenaient une vulnérabilité classé comme critique ou à haut risque.

Ces vulnérabilités peuvent conduire, par exemple, à des attaques par évasion où un attaquant s’appuie sur une bibliothèque défectueuse dans un conteneur pour pouvoir exécuter du code en dehors du conteneur. En violant un conteneur, l’attaquant peut éventuellement atteindre sa cible, qu’il s’agisse du système hôte ou d’une application dans un autre conteneur.

Dans le contexte des conteneurs, la maintenance de bibliothèques sécurisées peut être un vrai casse-tête – quelqu’un doit suivre les nouvelles vulnérabilités ainsi que ce qui a été corrigé et ce qui ne l’a pas été. Le processus est laborieux, mais il nécessite également des compétences spécialisées, ce que votre organisation devrait acquérir si elle ne les possède pas déjà.

Compte tenu de la valeur des correctifs réguliers et cohérents, ces raisons ne devraient pas être suffisantes pour provoquer le type de routines de correctifs aléatoires que nous voyons, mais – en particulier lorsque l’on pense au noyau du système d’exploitation – la perturbation des redémarrages requis et les Le besoin de maintenir des fenêtres de temps d’arrêt peut retarder considérablement l’application des correctifs. Correctif du noyau en direct permet d’atténuer ce problème, mais il n’est pas encore déployé par toutes les organisations.

Incluez toujours des objectifs de sécurité dans vos opérations de conteneur

Il est courant que les technologies de pointe introduisent de nouvelles complications en matière de sécurité des informations. Les nouveaux outils conduisent généralement à de nouveaux exploits. C’est également vrai pour les conteneurs et même 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 œil sur les risques posés par les conteneurs.

Éduquer vos développeurs et administrateurs système sur les failles courantes de la sécurité des conteneurs et les meilleures pratiques qui atténuent ces failles est un début. Patcher est un autre aspect important. Comme toujours, mettre en place les bonnes mesures pour atténuer les failles de cybersécurité aidera à protéger votre organisation et permettra à votre équipe de bénéficier de cette technologie de pointe sans souffrir de nuits blanches.