Contre les menaces contre la technologie de conteneurisation

L'utilisation de conteneurs pour le développement et le déploiement de logiciels est depuis longtemps devenue une pratique courante. De nombreux développeurs ont apprécié la possibilité de fournir facilement au programme un environnement standard indépendant de l'hôte sur lequel il s'exécute, de modifier rapidement les paramètres, d'ajouter ou de modifier certains composants dans le conteneur. Mais ce n'est qu'une petite partie de toutes les puces que la technologie de conteneurisation donne.



Comme toujours, le développement de la technologie et la croissance de sa popularité s'accompagnent de l'identification de diverses méthodes d'utilisation non standard, y compris les logiciels malveillants. Dans cet article, nous examinerons également les risques de sécurité du processus de développement associés à l'utilisation de conteneurs et expliquerons pourquoi les processus DevOps devraient être transformés en DevSecOps.

Pour commencer, pourquoi les conteneurs gagnent la sympathie des développeurs et comment l'utilisation de la conteneurisation change le développement dans son ensemble.

Chips


Légèreté

Comparés aux machines virtuelles et aux serveurs «à repasser», les conteneurs sont totalement peu exigeants en termes de ressources. Cela vous permet d'exécuter beaucoup plus de conteneurs sur une seule machine que de machines virtuelles. Un développeur peut même exécuter des composants d'application sur son ordinateur sous forme de microservices conteneurisés et il n'a pas à s'endormir en attendant une réponse du système. Du fait que les conteneurs partagent le cœur du système, leur démarrage et leur arrêt sont beaucoup plus rapides que le redémarrage de la machine virtuelle.

L'isolement

Malgré le partage du noyau, l'application dans le conteneur s'exécute indépendamment des autres parties du système et des applications. Cela signifie qu'une erreur dans l'application n'affectera qu'un conteneur spécifique.

L'utilisation de conteneurs pendant le développement vous permet de vous éloigner du conflit éternel des développeurs et des administrateurs système sur les privilèges. Le conteneur sépare en toute sécurité l'application du système, de sorte que le programmeur peut se permettre toutes les expériences sans craindre de détruire le système d'exploitation.

La portabilité

Chaque application s'exécute dans sa propre instance de conteneur avec ses propres fichiers de configuration. Cela élimine les maux de tête associés au déplacement de l'application entre les hôtes: tout le nécessaire pour le travail est stocké à l'intérieur du conteneur et transféré avec le reste des composants de l'application.

Référentiels de conteneurs

L'avènement de la norme Open Container Initiative a permis de créer des bibliothèques publiques d'images de conteneurs et de créer un écosystème puissant qui combine des moteurs de conteneurs, des plates-formes cloud et des outils pour gérer les conteneurs, les contrôles de sécurité et d'autres tâches.

Automatisation

L'utilisation de conteneurs vous permet de construire des chaînes entièrement automatisées d'intégration-déploiement continu d'applications (CI / CD), dans lesquelles la partie «manuelle» sera principalement l'écriture de code. Les tests, la vérification de la qualité du code, le conditionnement de l'application dans une image Docker, le placement de l'image sur le Docker Hub et son déploiement sur l'hôte pour exécution peuvent être effectués sans intervention humaine.

Menaces liées aux conteneurs


Bien entendu, avec tous ses avantages, les conteneurs présentent divers inconvénients. Par exemple, ce sont des problèmes avec les performances des applications gourmandes en ressources et la portabilité limitée des images conçues pour diverses architectures. Mais en plus des problèmes technologiques, les conteneurs ont des problèmes de sécurité.


Partage du noyau

Comme toujours, les inconvénients sont le revers des avantages. Le partage du noyau réduit la redondance des conteneurs par rapport aux machines virtuelles, mais le plus grand nombre de syscalls autorisés rend la barrière de sécurité plus fine et l'exploitation des vulnérabilités du noyau permet d'attaquer tous les conteneurs à la fois. Comment ne pas se souvenir des attaques sensationnelles de Spectre et Meltdown , qui vous permettent de lire la mémoire d'un autre processus ou noyau depuis l'espace utilisateur.

Dépôts publics

La présence de registres publics avec des images fournit une large sélection de «wrappers» pour les conteneurs, mais crée des menaces supplémentaires, car par défaut le serveur de registre est fiable. Si les cybercriminels parviennent à modifier des images de base avec des bibliothèques malveillantes, les modifications seront automatiquement distribuées à tous les serveurs qui mettent en cache cette image de base et tous les conteneurs utilisant la bibliothèque acquerront automatiquement des fonctionnalités malveillantes.

Des exemples



Ainsi, une bibliothèque malveillante suffit pour compromettre l'application. Bien sûr, les vulnérabilités et les fonctions malveillantes dans les bibliothèques populaires ne sont pas un problème de conteneurs en tant que tels, mais une technologie qui assure la propagation rapide des changements dans les images.

Recommandations


De toute évidence, le processus de développement moderne nécessite une nouvelle approche, une approche dans laquelle la sécurité sera intégrée dans la chaîne CI / CD, transformant DevOps en DevSecOps.



Selon Gartner, en 2019

  • plus de 70% des processus de développement d'entreprise comprendront une analyse automatisée de la vulnérabilité et de la configuration des composants open source et des packages commerciaux.
  • plus de 50% des processus CI / CD contiendront des contrôles de sécurité de code intégrés obligatoires;
  • plus de 60% des entreprises utiliseront le contrôle de version et les contrôles d'automatisation d'infrastructure dans leur développement.

Considérez certains des composants qui doivent être présents dans le processus afin que le mot «Sec» dans son nom ne soit pas une phrase vide.

Intégration des contrôles dans tous les processus

Un contrôle de sécurité doit être présent à toutes les étapes du processus de développement, de la création du code à sa conteneurisation et à son déploiement.

Automatisation des audits de sécurité

Il est nécessaire pour deux raisons:

  1. Cela réduira les erreurs d'administration et les erreurs de configuration.
  2. Les professionnels de la sécurité n'auront pas à vérifier manuellement le code et à modifier les paramètres.

API pour les fonctionnalités de sécurité

La mise en œuvre de telles fonctionnalités nécessite que le système de sécurité fournisse une API pour accéder à toutes les fonctionnalités. Les développeurs peuvent donc non seulement utiliser le système pour la vérification, mais également implémenter les appels appropriés dans le code.

Contrôle d'accès basé sur les rôles

Différents professionnels de la sécurité ont besoin de différents niveaux d'accès aux mécanismes de vérification, en fonction de leur rôle, car il est nécessaire que les développeurs ne soient pas en mesure de modifier les paramètres de sécurité, mais ne soient pas par la suite responsables des menaces pénétrées.

Compatibilité de l'API Docker Registry

Idéalement, la protection devrait prendre en charge la recherche d'images Docker dans tout registre prenant en charge l'API Docker Registry V2 pour garantir la compatibilité avec tous les registres courants.

Protection contre la migration

Pour les utilisateurs en entreprise, un moment dangereux est la transition d'une architecture monolithique à une architecture de microservices. Il est important que les fonctions de sécurité soient intégrées dans les processus d'intégration, assurant une protection en mode automatique.

Un exemple de solution de protection est le Deep Security Smart Check de Trend Micro, qui analyse automatiquement et en continu les images, identifie les vulnérabilités et les logiciels malveillants. Smart Check prend en charge les plates-formes de conteneurs Docker Trusted Registry, Amazon Elastic Container Registry, Azure Container Registry et Google Container Registry. De plus, Trend Micro s'intègre aux principaux systèmes SIEM et outils d'orchestration tels que Jenkins, Kubernetes, SumoLogic, Splunk.

Une caractéristique importante de Smart Check est sa conformité à toutes les exigences réglementaires en termes de vérification des vulnérabilités critiques et de journalisation des événements.

La mise en œuvre de la sécurité des conteneurs dans les processus DevOps aux premiers stades de développement avant le lancement des applications permettra le développement de logiciels plus fiables et productifs, ainsi que

  • Détectez les logiciels malveillants et les bibliothèques.
  • Identifiez les vulnérabilités.
  • Corrigez les erreurs avant de transférer les images vers des outils d'orchestration (par exemple Kubernetes).
  • Empêchez le code malveillant d'exécuter et de déployer des logiciels vulnérables.

Source: https://habr.com/ru/post/fr439986/


All Articles