L’utilisation des conteneurs continue de progresser. Qu’il s’agisse d’applications sans serveur, d’applications cloud natives ou d’une volonté de moderniser les architectures monolithiques, les conteneurs deviennent rapidement la plateforme privilégiée pour déployer des applications.
Sysdig a récemment publié son rapport 2019 sur l’utilisation des conteneurs basé sur des données recueillies auprès des clients de ses services de cloud public et sur site. Ces données portaient sur plus de deux millions de conteneurs.
Outre la découverte vraiment enthousiasmante (si vous êtes comme moi) que 60 % de ces conteneurs exécutent NGINX, Sysdig a mis au jour des statistiques de sécurité assez préoccupantes.
Prenons ce chiffre : 54 % des conteneurs ont eu une durée de vie inférieure à cinq minutes. En 2018, ce n’était le cas que de 20 % d’entre eux.
Pourquoi est-ce préoccupant ? À cause de la sécurité, bien sûr. Si vous cherchez à sécuriser les accès (et vous devriez le faire) et à protéger l’application ou l’API exécutée dans ce conteneur, vous devez vous assurer que vos services de sécurité adaptent constamment leurs politiques à l’état actuel du cluster. Cela signifie que les politiques doivent s’appliquer aux conteneurs dès leur lancement et être supprimées lors de leur mise hors service. Tous ces changements entraînent une importante charge opérationnelle. Il est déjà suffisamment difficile de garantir la sécurité d’une application relativement statique. Il est encore bien plus difficile de le faire rapidement avec une application extrêmement volatile.
Si cela ne vous inquiète pas, considérez cette statistique : même si 60 % des images de conteneurs sont extraites de registres privés (bravo !), 52 % d’entre elles échouent aux analyses de sécurité. Cela signifie qu’elles présentaient des vulnérabilités connues d’un niveau de gravité élevé ou critique.
Pfff. Je ne peux même pas.
Il s’avère qu’un très grand nombre de personnes exécutent des conteneurs en tant que root (médiane par hôte : 21) ou en mode privilégié (médiane par hôte : 4). D’autres les exécutent sans restriction de privilèges (médiane par hôte : 28). C’est particulièrement frustrant, car Docker (le moteur d’exécution de conteneurs le plus répandu) applique par défaut un ensemble restreint de capacités. Cela signifie que quelqu’un a délibérément modifié les paramètres de sécurité par défaut. Une exécution sans restriction peut permettre une élévation de privilèges ou une évasion du conteneur (donnant ainsi accès au système).
Faisons maintenant une pause pour rappeler les principes fondamentaux de la sécurité des conteneurs :
- Verrouillez la porte. L’authentification n’est pas facultative. Veillez à exiger des identifiants robustes et à les renouveler régulièrement. Utilisez l’authentification à deux facteurs chaque fois que possible, en particulier pour les accès privilégiés aux consoles d’orchestration et aux infrastructures critiques.
- Cachez vos objets de valeur. Ne partagez pas par inadvertance des informations sensibles (telles que des clés et des identifiants) en clair dans un dépôt ou une source partagée facilement accessible.
- Filtrez vos appels. Toutes les requêtes ne sont pas légitimes, et certaines contiennent du code malveillant. Qu’il s’agisse d’une application ou d’un service d’infrastructure, inspectez et analysez le contenu afin de détecter toute intention malveillante. Pour optimiser les performances, combinez l’analyse avec la terminaison SSL/TLS afin de compenser la légère baisse de performances.
- Comblez les failles. Si vous savez qu’une image, un service, une charge de travail ou un autre composant présente une vulnérabilité, appliquez-lui un correctif. Cela vaut tout particulièrement pour les vulnérabilités affectant des composants provenant de sources externes, car elles constituent des cibles de choix. En effet, lorsqu’une vulnérabilité apparaît dans des applications ou des infrastructures largement déployées, comme Apache Struts, les possibilités d’attaque sont nombreuses et les efforts nécessaires pour la détecter et l’exploiter sont minimes.
Il est absolument essentiel, pour la sécurité des applications — et donc de l’entreprise — que les bonnes pratiques de sécurité des conteneurs soient réellement mises en pratique. Notre prochain rapport 2020 sur l’état des services applicatifs révèle que les applications cloud natives et les microservices représentent en moyenne 15 % du portefeuille d’applications d’une entreprise. Et ce, malgré des résultats faisant état d’importants retards dans le développement de nouvelles applications. Cela signifie que le nombre d’applications conteneurisées ne fera qu’augmenter. Et si nous ne parvenons pas à sécuriser une faible proportion des applications, comment pouvons-nous espérer passer à l’échelle pour en sécuriser une part importante ?
Adoptez de bonnes pratiques de conteneurisation.
Si vous souhaitez revoir les bases de la sécurité des conteneurs, consultez cette série qui s’appuie sur l’expertise de mon collègue de F5, Jordan Zebor :
- Principes fondamentaux de la sécurité des conteneurs : introduction
- Principes de base de la sécurité des conteneurs : pipeline
- Principes de base de la sécurité des conteneurs : orchestration
- Principes de base de la sécurité des conteneurs : charges de travail
- Principes de base de la sécurité des conteneurs : conclusion
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.