Select Page

Docker : pourquoi la sécu traditionnelle ne suffit pas (partie 2)

Docker : pourquoi la sécu traditionnelle ne suffit pas (partie 2)

Quand on en arrive à Docker, on rencontre trois profils de clients : celui, early adopter, qui a déjà commencé à déployer ; celui, en mode découverte, qui commence à tester avec quelques applications ; et celui qui est encore en phase de veille, et qui n’a pas encore abordé la containerisation en pratique. Mais quel que soit son niveau de maturité, la sécurité reste toujours un obstacle à affranchir, comment faire ? La plupart pense que leur politique menée jusque-là sera suffisante.

Sauf que non…Quand on en arrive aux containers, la sécurité traditionnelle ne suffit pas. On ne sécurise pas une infra containérisée comme on sécurise son infra virtualisée.

La bonne nouvelle c’est que les leaders du marché comme Docker restent très vigilants sur ce point. Les récentes fonctionnalités de Docker prennent de plus en plus en compte ces aspects.

Pour les équipes, il est cependant important de mieux comprendre les enjeux de la sécurité dans une infra containérisée, ainsi que mieux connaitre les risques, pour les intégrer dans la politique de sécurité globale de l’entreprise. C’est ce que nous allons décrire ci-après.

 

Pourquoi les containers méritent une sécurité adaptée ?

  • Plus de composants. Comme on l’a vu dans la partie 1 de cette série sur Docker, dans une infra containérisée, on a plus de composants. Dans une infra virtualisée, les flux sont plus au moins maitrisés. Dans une infra containérisée, ça se complique : on a affaire à des architecture complexe type « microservices »,  où le code est éclaté sur différents composants de l’infra : la gestion et le contrôle des flux devient extrêmement complexe. Pour les équipes sécurité, il faut donc s’adapter à cette multitude de flux.

 

  • Automatisation à prendre en compte. Avec les containers, il y a cette possibilité d’automatisation, de déploiement massif et portabilité. L’humain ne peut pas suivre la machine, et tout le temps gagné en automatisation va de nouveau être perdu dans la sécurité, qui elle ne peut pas être automatisée. L’humain aura pour rôle principal de contrôler et de valider toute la chaine d’intégration.

 

  • Durée de vie courte des containers. Il y a aussi cette nouvelle contrainte, en comparaison avec les machines virtuelles : un container a une durée de vie plus courte (1 à 2 jours). Les équipes de développement vont constamment recréer des containers et pour les équipes sécurité, c’est un challenge de réussir à suivre ces changements, modifier les règles quasiment en temps réel. Si un problème de sécurité survient sur un container, il ne sera pas patché mais détruit et une nouvelle image va être redéployée. Le container répond au problème de portabilité. Du coup, la sécurité doit aussi être portable et ne doit pas être liée à une infrastructure. Nouveaux challenges au niveau réseau. Avec une VM, on pouvait contrôler les communications avec des firewall. Aujourd’hui avec les containers, toute la sécurité est gérée au niveau de la machine. Plusieurs containers sur une même machine qui se « voient » entre eux. C’est interne à la machine et ne passe plus par le firewall périmétrique : ce dernier ne peut pas voir ce qui se passe et vérifier si c’est instable où s’il y a une attaque. On passe de microsegmentation à nanosegmentation.

Quels changements au niveau des risques ?

Les risques sont quasiment du même acabit que dans le cas des infrastructures virtualisées ou classiques. Cependant, certains points sont intéressants à préciser :

  • Risques sur les configs par défaut. Garder les configurations par défaut amène un risque important dans une infra conteneurisée. Il faudra donc intégrer des nouvelles fonctionnalités et des configurations personnalisées par environnement.
  • Le top ten owasp reste valable. Avec les containers, on utilise toujours les mêmes protocoles de communication : les attaques applicatives classiques restent toujours les mêmes.
  • Brèches au niveau du code. C’est un risque classique des attaques informatiques, avec un code mal développé ou une mauvaise librairie, les brèches existent aussi dans les containers et les attaques sont possibles. Le développeur et le référentiel de la mise à disposition des images sont des menaces potentielles.
  • Attaque réseau. Si un pirate prend la main sur un container, il pourra lancer un scan réseau et faire des déplacements latéraux. Comme il y a un manque de visibilité, les équipements de sécurité traditionnels ne vont pas détecter ce scan, et le pirate pourra facilement passer d’un container à l’autre.
  • Déni de service.Comme pour une attaque traditionnelle, elle peut mettre en difficulté la disponibilité des services d’infrastructures et applicatives, et le fait de mettre tous les œufs dans le panier augmente l’impact de l’attaque.

 

  • Container escape ou jailbreak. Il arrive que l’attaquant prenne la main sur un container en s’appuyant sur une faille web et fasse ce qu’on appelle un « container escape » : il s’échappe du container et va infecter l’host. Il peut s’appuyer sur un problème de vulnérabilité du noyau ou un défaut de configuration. Le pirate s’appuie sur ces failles et prendre la main sur l’infrastructure.

 

Que faire alors ?

Il faut commencer bien évidemment par former l’équipe de sécurité à la culture devops et aux architectures micro-services, pour bien comprendre la différence avec les autres types d’architectures. Ensuite, quelques bonnes pratiques sont à mettre en place pour bien savoir sécuriser les images, comme par exemple :

  • Créer une partition physique séparée pour Docker.
  • Maintenir le système et les images à jour et ne posséder que le strict minimum
  • Eviter le stockage de secrets au sein d’une image. Moins le conteneur possède d’outils, plus la compromission sera difficile
  • Ne pas utiliser n’importe quel registre
  • Contrôler les communications entre containers
  • S’assurer que les images ont été suffisamment testées et s’assurer qu’elles correspondent à ce qu’elles sont censées être
  • Définir des politiques sécurisées de communication et d’administration au sein de l’infrastructure
  • Vérifier les sources de construction des images utilisées par les conteneurs et assurer un suivi de leurs évolutions en appliquant une signature numérique interne.
  • Un scan de vulnérabilité de l’image doit être implémenté avant la validation de celle-ci en tant qu’image de confiance.
  • Gérer les droits d’accès au registre, ou mettre en place un mécanisme de contrôle d’accès et de gestion de rôle/profil des utilisateurs de la solution
  • Limiter les appels système
  • Installer des outils dédiés aux containers, pour vérifier le niveau de sécurité global afin d’identifier les vulnérabilités. Ces outils permettent d’industrialiser les procédures de sécurité.

 

Mais plus que technique, l’enjeu est aussi organisationnel : le passage en mode DevOps et l’orchestration du déploiement d’un conteneur a son propre mode de fonctionnement, et implique de nouvelles méthodologies : les équipes dev, ops, et secu doivent s’accorder entre eux.

Les bienfaits du shift-left.

L’idée du shift-Left est de rapprocher les considérations de qualité et de sécurité des applications du développeur, c’est-à-dire à la gauche de la chaine de développement, afin que les problèmes potentiels soient évités ou résolus plus tôt avant même que le code ne soit déployé. Une méthode qui peut amener un vrai retour sur investissement. Cela a en effet un impact important sur la sécurité : les équipes sécu en général se concentrent sur la sécurité au niveau système, et peu au niveau de l’application. Ainsi la sécurité est anticipée dès la conception de l’application.

About The Author

SCC

Recevez par mail les articles et actualités de Au coeur des InfrasJe m'inscris à la Newsletter