Incontestablement, Docker s’adresse à trois grands profils de clients : les early adopters, les utilisateurs qui découvrent cet environnement et ceux qui ne l’ont pas encore utilisé. Pour autant, quel que soit son niveau de maturité, la sécurité reste toujours un obstacle à franchir.

Mais comment faire ?

Concrètement, lorsque l’on utilise des « containers », la sécurité traditionnelle ne suffit pas. On ne sécurise pas une infrastructure « containérisée » comme on sécurise son infrastructure virtualisée. Il est donc important de bien comprendre les enjeux de la sécurité dans une infrastructure « containérisée », ainsi que les risques associés pour les intégrer efficacement dans sa politique de sécurité.

Pourquoi les containers nécessitent une sécurité différente ?

Plus de composants

Dans une infrastructure virtualisée, les flux sont plus au moins maitrisés. Dans une infrastructure « containérisée », cela se complique au regard des architectures complexes type « microservices », où le code est éclaté sur différents composants. Pour les équipes sécurité, il faut donc s’adapter à cette multitude de flux.

Automatisation à prendre en compte

Avec les containers, les notions d’automatisation, de déploiement massif et de portabilité sont fondamentales. Il sera donc important de contrôler et valider la chaine d’intégration.

Durée de vie courte des containers

En comparaison avec les machines virtuelles, un container a une durée de vie plus courte. Les équipes de développement vont donc constamment recréer des containers. Suivre ces changements est alors un véritable challenge pour les équipes sécurité.

Quels changements au niveau des risques ?

Les risques sont pratiquement identiques à ceux des infrastructures virtualisées ou classiques. Cependant, certains points sont intéressants à préciser :

-Risques sur les configurations par défaut

Garder les configurations par défaut amène un risque important dans une infrastructure conteneurisée.

-Le top ten owasp reste valable

Avec les containers, on utilise toujours les mêmes protocoles de communication : les attaques applicatives classiques sont donc courantes.

-Brèches au niveau du code

C’est un risque classique. Avec un code mal développé ou une mauvaise librairie, les brèches existent dans les containers et les attaques sont possibles.

-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é ne vont pas détecter ce scan, et le pirate pourra facilement passer d’un container à l’autre.

Comment faire pour sécuriser ses opérations sur Docker ?

Il faut commencer bien évidemment par former l’équipe de sécurité à la culture devops et aux architectures micro-services. Ensuite, voici quelques bonnes pratiques à mettre en place :

-Créer une partition physique séparée pour Docker

-Maintenir le système et les images à jour

-Éviter le stockage de secrets au sein d’une image

-Ne pas utiliser n’importe quel registre

-Contrôler les communications entre containers

-Définir des politiques sécurisées de communication au sein de l’infrastructure

-Gérer les droits d’accès au registre avec un mécanisme de gestion de rôle

Installer des outils dédiés aux containers pour vérifier le niveau de sécurité global afin d’identifier les vulnérabilités.

-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

Enfin, l’aspect organisationnel est également incontournable : le passage en mode DevOps et l’orchestration du déploiement d’un conteneur ont leur propre mode de fonctionnement et impliquent de nouvelles méthodologies : les équipes développement, opérationnelles et sécurité doivent alors savoir travailler ensemble.

Les vertus 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 pour que les problèmes potentiels soient résolus avant que le code ne soit déployé. Cela a en effet un impact important sur la sécurité : les équipes sécurité se concentrent alors sur la sécurité au niveau système et peu au niveau de l’application. Ainsi, la sécurité est optimisée dès la conception de l’application.