Comment Netflix gère la sécurité de ses conteneurs
Implémenter une sécurité en profondeur dans une architecture en microservices est tout sauf une sinécure. Car le déploiement de certificats TLS associés aux conteneurs se heurte à des difficultés techniques. Netflix explique comment il les a résolues.
Dans les architectures en conteneurs, aussi appelées architectures en micro-services, la sécurisation des échanges apparaît comme un des défis principaux qui se posent aux DSI. Raison de plus pour prêter une attention particulière au billet de blog que publient les équipes techniques de Netflix, billet qui détaille comment le site de streaming sécurise les échanges entre les centaines d’applications qu’il fait tourner sous forme de micro-services. « Un de nos objectifs, afin d’implémenter une sécurité en profondeur, est de mettre en place des communications chiffrées et authentifiées entre tous nos services à chaque fois que c’est possible, que ces échanges voyagent ou non sur l’Internet public », écrit Ian Haken, un chercheur en sécurité travaillant pour Netflix. Un principe synonyme d’utilisation extensive de TLS.
Plusieurs questions techniques découlent toutefois de cet impératif. D’abord, dans un environnement Cloud capable de s’adapter automatiquement à la demande – ce qu’on appelle l’autoscaling -, il faut être en mesure de certifier tout nouvel environnement créé (voir à ce sujet cette vidéo YouTube, dans laquelle le même Ian Haken décrit la solution retenue par le site de streaming, solution qui repose sur un régime d’autorisations fournies par le prestataire Cloud, ici AWS). Ensuite, se pose le problème de la fourniture des certificats à proprement parler. Or, comme le note Ian Haken, les règles de sécurité interdisent aux autorités de certification publiques d’émettre des certificats pour des classes d’adresses IP privées, famille à laquelle appartiennent les applications de Netflix n’ayant pas d’existence sur l’Internet public.
Name Constraints restreint la portée des certificats
La solution ? Mettre en place sa propre autorité de certification (CA). « Mais nous étions hésitants vis-à-vis de cette solution », reprend le technicien. Tout simplement parce qu’elle implique à priori de forcer les navigateurs des utilisateurs à accepter les certificats non émis par des autorités publiques. Un risque important, selon Ian Haken. « Forcer nos utilisateurs à faire confiance à une autorité privée signifie qu’il faut s’assurer que cette autorité ne sert qu’à certifier des services internes et qu’elle ne sera pas détournée dans le cadre d’une attaque de type Man-in-the-middle […]. Non seulement un assaillant pourrait compromettre nos canaux de trafic interne, mais toutes les communications de nos employés seraient exposés, y compris depuis leur domicile. » D’où la solution de contournement mise en place par les équipes de Netflix : une extension de TLS appelée Name Constraints.
Cette extention permet de créer des listes blanches des IP et domaines qu’une autorité et ses sous-autorités (à qui la première délègue ses pouvoirs d’émission) sont autorisées à certifier. Un outil tout indiqué dans le cadre de l’inclusion d’une autorité de certification interne dans la zone de confiance des navigateurs. « Nous pouvons ainsi limiter les sites web qui peuvent être vérifiés en utilisant cette racine, même si la CA ou l’un de ses intermédiaires sont mal utilisés », précise l’ingénieur.
Netflix teste en profondeur
Si, sur le papier, la solution semble adaptée, Netflix n’en reste pas là. « Avant de nous reposer sur cette solution pour protéger nos utilisateurs, nous voulions nous assurer que les navigateurs implémentaient réellement la vérification de Name Constraints et qu’ils effectuaient cette opération correctement », écrit Ian Haken. Pour ce faire, Netflix a lancé une série de tests. Concluants quand il s’est agi de détecter un site signé avec un certificat violant les règles de l’extension. Les quatre browsers, Chrome, Firefox, Edge, and Safari, passant alors l’épreuve avec succès. « Toutefois, à mesure que nous étendions notre batterie de tests, nous avons rapidement commencé à perdre confiance », raconte le chercheur en sécurité. En cause notamment : la capacité, en créant des certificats très proches des modèles légitimes, à bypasser les sécurités de Name Constraints (exception faite de Firefox).
Dans son billet de blog, Netflix explique avoir travaillé avec les éditeurs pour résoudre la plupart des problèmes rencontrés lors de cette batterie de tests. Google (pour Chrome) et Oracle (pour Java) s’étant montrés particulièrement réceptifs, assure Ian Haken. Les entreprises qui déploient des architectures en microservices et souhaitent adopter une solution similaire à celle de Netflix (CA interne et emploi de Name Constraints) pourront, de toute façon, se faire leur propre opinion sur le sujet : le site de streaming a placé sa batterie de tests en Open Source, sous l’appellation BetterTLS.
A lire aussi :
31 bonnes pratiques pour sécuriser les conteneurs Docker
Netflix dit adieu au datacenter et vive AWS
Netflix révise sa politique Open Source avec Docker
