Conteneurs - Isolement n'est pas synonyme de sécurité

La capacité sans précédent des technologies de conteneurisation pour supporter des logiciels rapides, résilients et évolutifs est désormais bien reconnue dans les départements informatiques. Pourtant, les conteneurs représentent également une nouvelle surface d'attaque pour les acteurs malveillants. Comprendre le panorama de la sécurité des conteneurs est donc devenu primordial pour protéger les opérations tout au long du cycle de vie du développement logiciel.

Que sont les conteneurs et quel problème résolvent-ils ?

Les conteneurs empruntent leur nom à l'industrie maritime : ils offrent un format standardisé pour emballer les logiciels et isoler leur environnement d'exécution du reste du système d'exploitation. Ils représentent une alternative plus légère aux machines virtuelles traditionnelles, car ils ne nécessitent pas l'intégration d'un système d'exploitation complet pour exécuter une application. Plus légers, ils créent également une abstraction de l'ensemble de l'application en tant que charge de travail uniformisée, mettant en œuvre une nouvelle séparation des intérêts.
 

C'est ce qui rend les conteneurs si utiles, car ces propriétés ouvrent la voie à un tout nouveau niveau d'automatisation pour les équipes opérationnelles. En effet, lorsqu'elle est correctement configurée, une infrastructure de conteneurs conduit non seulement à une fiabilité et une évolutivité accrues, mais aussi à une réduction des coûts opérationnels et de licence.

La plupart du temps, un conteneur peut être détruit et redéployé à tout moment sans conséquences graves grâce à la nature immuable de l'application déployée. Par analogie, on les compare souvent à du bétail, car ils sont dépourvus de toute identité ("état"), ce qui permet de les remplacer facilement en cas de défaillance, mais aussi d'augmenter ou de diminuer la charge de travail en réponse à des facteurs externes par exemple. 

Bien sûr, ce n'est pas obligatoire, car une certaine dose de persistance est toujours nécessaire. Les conteneurs qui ont besoin de maintenir un état, comme une base de données conteneurisée par exemple, nécessiteront par contre une attention particulière et des règles de gestion spéciales.

La couche d'abstraction introduite par les conteneurs est un avantage énorme en termes d'infrastructure : comme pour leurs homologues maritimes, les équipes opérationnelles ont un contrôle total sur l'allocation des ressources et n'ont pas besoin de tenir compte du type d'application qui va être exécutée, de la stack technique, ni du type d'architecture choisi côté logiciel. Avec la virtualisation, les processus de développement et de déploiement étaient beaucoup plus étroitement couplés parce que le matériel lui-même était virtualisé, ce qui signifie qu'il devait être similaire dans les deux environnements.

S'adapter au changement, souvent

Les conteneurs sont très liés aux philosophies DevOps et Agile. Leur utilisation en tant que blocs éphémères permet par exemple de construire, tester, et empaqueter du code source dans un environnement ad hoc qui sera détruit une fois chaque étape terminée. 

Cette cinématique est connue sous le nom de pipeline d'intégration continue et de livraison continue. Il s'agit d'un mécanisme très polyvalent qui peut être considéré comme l'épine dorsale de toute organisation agile moderne, en ce qui concerne les logiciels. 

De nos jours, il n'est pas rare de voir des centaines de pipelines fonctionner chaque jour pour une seule entreprise, où de nombreuses petites équipes travaillent chacune sur un seul composant du produit final, aussi fin qu'un seul point de terminaison SaaS par exemple. Sans la flexibilité des conteneurs, il serait inimaginable d'exécuter ce type d'intégration à l'échelle de l'entreprise sans que les équipes se battent pour obtenir des ressources (ou, plus pragmatiquement, pour publier leur correctif de dernière minute) dans la prochaine version.

Un autre exemple de la façon dont les conteneurs encouragent les petites améliorations itératives et l'innovation est celui des déploiements “blue green” : une fois les tests de régression validés, vous pouvez déployer automatiquement une nouvelle fonctionnalité devant des données de production réelles pour vérifier que les performances sont toujours bonnes, avant de publier cette fonctionnalité.

L'intégration fréquente du code source avait déjà été préconisée auparavant (comme l’Extreme programming), mais il est juste de dire que le DevOps a définitivement changé la donne en la matière en accélérant la mise sur le marché.  Les entreprises ont compris que l'adoption de ce système leur permettrait d'augmenter considérablement la vitesse de mise à jour de leurs produits et de livraison de nouvelles fonctionnalités, et d'en faire un avantage concurrentiel.

Il ne fait aucun doute que les conteneurs sont une technologie qui comble le fossé entre le développement et les opérations : les développeurs sont responsables de la création de programmes qui peuvent être exécutés dans ces conteneurs, tandis que les opérations sont responsables de la gestion et de la surveillance des charges de travail. La nouveauté, en fait, c’est que les deux sont maintenant la même personne, car qui serait mieux placé pour surveiller une application que la personne qui l'a codée?

Le problème : les conteneurs n'ont pas été conçus comme un dispositif de sécurité

Parmi les vendeurs, Docker est de loin le plus utilisé, au point qu'il est devenu synonyme de conteneurs. Adopté par les ingénieurs du monde entier, il fournit une interface aussi simple que possible, en faisant totalement abstraction des mécanismes Linux sous-jacents qui la supportent.

On pourrait dire que l'un des effets secondaires négatifs de son adoption massive a été l'éducation insuffisante sur ce que Docker n'est pas, surtout pour les personnes qui devront utiliser cet outil professionnellement au jour le jour.
 

En fait, le mot "conteneur" est souvent mal compris, car de nombreux développeurs ont tendance à associer le concept d'isolation à un faux sentiment de sécurité, croyant que cette technologie est intrinsèquement sûre. 

L'une des clés ici est de comprendre que les conteneurs n'ont pas de dimension de sécurisation par défaut. Au contraire, leur sécurité dépend entièrement de:

• l'infrastructure de support (OS et plateforme)
• leurs composants logiciels embarqués
• leur configuration d'exécution
   

L'idée que les conteneurs garantissent une couche de sécurité aux applications qui s'exécutent à l'intérieur est une idée fausse très répandue, en particulier chez les personnes moins familiarisées avec la sécurité opérationnelle. Cela peut même aboutir à ce que des conteneurs soient exposés sans configuration adéquate, permettant ainsi à un attaquant d'obtenir un accès et d'élever ses privilèges à l'intérieur de l'hôte.

Une étude récente d'Aqua security a révélé que "50% des nouvelles instances Docker mal configurées sont attaquées par des botnets dans les 56 minutes suivant leur mise en place." Si "la majorité des attaques étaient axées sur le minage de crypto-monnaies [...], 40 % d'entre elles impliquaient également des backdoors pour accéder à l'environnement et aux réseaux de la victime. Les portes dérobées étaient activées en déposant des logiciels malveillants dédiés ou en créant de nouveaux utilisateurs avec des privilèges root et des clés SSH pour un accès à distance."
 

Pire, chez GitGuardian nous avons récemment mené une étude sur les secrets qui sont publiquement accessibles dans les images Docker. Vous serez surpris de voir ce que nous avons trouvé en analysant le registre officiel Docker Hub. 
 

Pour ces raisons, la plupart des experts en sécurité plaident en faveur d'une meilleure éducation sur les défis de sécurité posés par les technologies liées au cloud computing comme les conteneurs, dans le cadre d'une migration DevSecOps. Ils poussent également à accélérer la cartographie des menaces, afin d'avoir une vision plus claire du paysage de sécurité entourant les conteneurs.

Des progrès vers une cartographie commune des menaces 

Suite à la demande croissante de la communauté de la sécurité, MITRE a publié en avril cette année (2021) une matrice ATT&CK couvrant les comportements des adversaires au niveau de l'orchestration et des conteneurs. Cet ajout à son catalogue bien connu s'explique par la nécessité d'avoir une vue d'ensemble de la façon dont les conteneurs sont ciblés dans les environnements d'entreprise.
 

Construite à partir de renseignements recueillis par le Center for Threat-Informed Defense, la matrice est le fruit de la collecte des expériences des professionnels de la sécurité et de la recherche de vulnérabilités concernant les conteneurs. Comme la décrivent ses auteurs, il s'agit de la première étape vers une cartographie collaborative de la surface d'attaque réelle exposée par les conteneurs, dans le contexte plus large de la sécurité du cloud.
 

Les données du Centre concordent avec les statistiques d'Aqua : "la plupart des comportements conduisent finalement à des activités de cryptomining, même lorsqu'il s'agit d'accéder à des secrets tels que des identifiants cloud." Néanmoins, le Centre note que "l'utilisation des conteneurs à des fins plus "traditionnelles", comme l'exfiltration ou la collecte de données sensibles, est publiquement sous-déclarée."
 

En tant que nouvelle brique de l'infrastructure informatique moderne, les conteneurs s'accompagnent de leur propre lot de défis. L'orchestration et le haut niveau d'automatisation sont de nouvelles couches activement ciblées pour obtenir un accès initial et dissimuler une activité malveillante. Le besoin d'un langage commun parlé par les développeurs, les équipes d'exploitation et de sécurité devient donc de plus en plus une nécessité.

Les bases de la sécurisation des conteneurs

La liste suivante est un rappel de certains des problèmes de sécurité les plus courants rencontrés dans les conteneurs : 

• Les conteneurs sont construits à partir d'images, dont la provenance doit être soumise à des politiques strictes et qui doivent être automatiquement et régulièrement scannées.
• Un conteneur privilégié est autorisé à faire tout ce que l'hôte peut faire. Il est essentiel de mettre en œuvre le principe du moindre privilège à chaque étape en configurant correctement les pipelines CI/CD, car les attaques de chaîne logistique sont de plus en plus courantes. Des capacités plus fines permettent de réduire la surface d'attaque.
• Les restrictions de communication entre conteneurs et l'isolation du réseau de l'hôte peuvent être assez difficiles à gérer, mais les conteneurs vivant sur le même réseau (comme la plupart des configurations par défaut) facilitent les mouvements latéraux.
• Les ressources telles que les processeurs, la mémoire, le nombre de processus lancés ou exécutés en parallèle dans un conteneur peuvent également être limitées. C'est une bonne chose pour prévenir les attaques telles que les fork bombs et l'injection de code à distance.
• Les conteneurs sont faciles à utiliser comme vecteur pour infiltrer l'hôte sous-jacent. Ce qui a été mentionné plus haut à propos de l'isolement du réseau hôte devrait être étendu autant que possible : espaces de noms d'utilisateurs et de processus isolés, systèmes de fichiers en lecture seule lorsque cela est possible.

Conclusion

Alors que de plus en plus d'équipes informatiques passent au DevOps, les conteneurs deviennent un élément essentiel de leur boîte à outils. Cette technologie a connu un taux d'adoption impressionnant ces dernières années, et ce gain de traction s'est accompagné, sans surprise, d'une recrudescence des problèmes de sécurité. En effet, les conteneurs et les technologies connexes comme l'orchestration représentent également un nouveau vecteur pour les attaquants, certaines erreurs de configuration courantes étant facilement exploitables. 

Pour y remédier, le secteur s'efforce de recueillir davantage de renseignements sur les comportements des adversaires. 

D'autre part, il est également nécessaire de sensibiliser les utilisateurs à ce que les conteneurs ne sont pas, c'est-à-dire des dispositifs de sécurité, afin de faire tomber le mythe selon lequel l'isolement des applications est synonyme de sécurité.