La conteneurisation permet d’aller beaucoup plus vite dans la livraison d’applications et de nouvelles fonctionnalités, et de plus en plus d’entreprises adoptent aujourd’hui cette technologie pour gagner en flexibilité et en agilité. Mais cette réactivité et cette capacité d’adaptation ne sont pas sans contrepartie, notamment en termes de cybersécurité.

Voici pourquoi les fonctions de sécurité natives des conteneurs ne suffisent pas à lutter contre les nouvelles vulnérabilités et vecteurs de menaces.

Les limites des sandbox : l’isolation n’est pas parfaite.

Contrairement aux machines virtuelles, les conteneurs utilisent le système d’exploitation de leur hôte, ce qui leur confère rapidité, flexibilité et évolutivité. Ils ne disposent toutefois pas d'un véritable bac à sable. Si un attaquant exploite une vulnérabilité du système d'exploitation hôte, tous les conteneurs le partageant peuvent être compromis.

La surface d’attaque est plus étendue.

Les couches d’orchestration des conteneurs peuvent comporter des vulnérabilités. En exploitant de mauvaises configurations, par exemple si trop d’accès à privilèges ont été accordés, un attaquant pourrait prendre le contrôle de l'ensemble d’un parc de conteneurs.

La complexité des plans de contrôle des conteneurs et l'utilisation intensive d'API au niveau de la couche service peuvent par ailleurs exposer l’architecture interne des applications. De plus, dans les architectures de microservices, le fait que les applications soient ainsi ventilées multiplie un petit nombre de workloads par 10 ou par 100. Tous ces éléments élargissent la surface d'attaque.

Les images des conteneurs sont vulnérables.

La plupart du temps, les conteneurs sont construits à partir d'images stockées dans des référentiels accessibles au public comme GitHub. Les images créées ont généralement des dépendances à d'autres images et bibliothèques dans le référentiel. Une vulnérabilité dans l'un des codes source peut rapidement s’étendre à (potentiellement) des milliers d'autres conteneurs.

Lors de l'utilisation d'images provenant d’un référentiel public, à moins qu’elles ne soient signées et que le code soit validé, un attaquant peut également exécuter sa propre image malveillante. Cela met en danger à la fois l'hôte et les données.

De nouveaux vecteurs d’attaque émergent.

Les pods Kubernetes exécutant un ou plusieurs conteneurs utilisent des adresses IP uniques pour la connectivité. Les attaquants peuvent exploiter ces adresses IP comme des portes d'entrée pour lancer des attaques depuis des réseaux externes ou en interne (via le phishing par exemple). La mise en liste blanche des adresses IP ne suffit pas à contrer ces attaques, surtout lorsque des adresses IP de confiance sont utilisées.

Un conteneur mal configuré est un autre vecteur d'attaque pour explorer les vulnérabilités d'exécution. Avec des informations d'identification de conteneur compromises, comme une clé API ou un nom d'utilisateur/mot de passe, un attaquant peut même s'introduire dans la base de données et les services cloud.

Qui dit charges de travail éphémères, dit ressources éphémères.

Les ressources des conteneurs sont constamment détruites et recréées. Il est courant de recycler les serveurs, les adresses IP, les firewalls, les lecteurs, ou encore les réseaux superposés pour en optimiser l'utilisation. Or, les contrôles de sécurité périmétriques et basés sur les adresses IP sont inefficaces lorsque les ressources sont éphémères. Les enquêtes sont également impossibles lorsque les journaux disparaissent après la suppression des conteneurs.

Les contrôles basés sur des règles ne peuvent pas sécuriser les conteneurs.

Ils ne peuvent en effet pas suivre l'évolution rapide de l'infrastructure des conteneurs. En outre, pour modifier une règle de firewall, l'équipe informatique peut devoir attendre plusieurs jours l'ouverture d'une fenêtre de tir. Il est pratiquement impossible de sécuriser une infrastructure de conteneurs hyperdynamique à l'aide de contrôles traditionnels. De plus, les outils traditionnels ne disposent pas du contexte des conteneurs pour traiter les problèmes de sécurité qui leur sont spécifiques.

Pour toutes ces raisons, les conteneurs nécessitent d’adopter une nouvelle approche de la sécurité. Les entreprises doivent se tourner vers des solutions spécifiquement conçues pour assurer la sécurité des conteneurs, tout au long du cycle de vie des applications – de leur développement à leur exécution –, à tous les niveaux du conteneur – de la couche d'application à celles d'exécution et d'orchestration –, et de manière entièrement automatisée.

Elles vont devoir rechercher des solutions leur permettant, avant toute chose, de découvrir chaque conteneur dans le cloud. Ce n’est qu’avec cette visibilité qu’il sera possible de les sécuriser. Puis, elles devront veiller à opter pour une solution capable de surveiller en permanence les communications, les lancements et les autres comportements d'exécution dans le cloud, et d’utiliser le machine learning non supervisé pour détecter en temps réel les comportements anormaux, avec le minimum de fausses alertes. Il ne s’agit pas seulement de détecter les activités qui ne suivent pas les règles, mais de signaler les comportements qui sont anormaux même lorsqu’ils sont conformes aux règles. Idéalement, ces alertes devront permettre de remonter rapidement à l’origine d’une attaque ou d’un comportement anormal – par exemple, un serveur API ouvert – avec des éléments consignés au niveau des processus pour que les pistes d’audit persistent même après la suppression d’un conteneur. Cela garantit ainsi une traçabilité malgré la nature éphémère des conteneurs.

Selon Gartner, d'ici 2022, 75 % des entreprises devraient exécuter des applications conteneurisées, contre seulement 30 % en 2019. Cette croissance explosive souligne l'importance de sécuriser les conteneurs avec une solution complète. De la détection automatisée des menaces à la conformité, cette approche globale de la sécurité des conteneurs est la seule à permettre de ne rien laisser sans protection.