Dans une architecture microservices, il ne s’agit plus d’assurer la protection d’une ou deux applications monolithiques, mais celle de dizaines de petits services qui peuvent tous interagir les uns avec les autres de plusieurs manières. Qui plus est, il faut protéger ces services des agressions extérieures, mais aussi d’une mauvaise utilisation en interne, qu’elle soit volontaire ou non. Les applications monolithiques du passé étaient lourdes et rigides, et les architectures orientées services qui leur ont succédé avaient leur propre complexité. Le remplacement de ces piles par des applications souples déployées via des conteneurs facilement interchangeables semblait être une bonne option, ce qui est le cas. Mais le modèle rompt aussi avec des pratiques bien rodées, dont un grand nombre concerne la sécurité. Comme l’a expliqué Éric Knorr (rédacteur en chef d'Infoworld) dans un débat sur le bon usage de l’architecture microservices, ces changements majeurs impliquent que les développeurs doivent désormais assumer des responsabilités autrefois assurées par les opérationnels.

La sécurité dans et entre les microservices tombe dans cette catégorie. Une bonne question serait de savoir qui, des dev ou des ops, a la meilleure compréhension de la sécurité. Mais il ne faut pas oublier que les développeurs produisent les API qui gèrent l’interaction des services entre eux et avec le monde extérieur. Autrement dit, une grande partie du fardeau de la sécurité leur incombe. Pour les ops, la sécurisation des microservices ne prend pas en compte les outils utilisés. Owen Garrett, chef de produits chez Nginx, a indiqué qu’« une grande partie de la technologie développée pour gérer les applications web traditionnelles ne s’applique pas directement aux applications microservices. Cela inclut la sécurité, pas seulement les pare-feu d'applications, mais aussi les identifiants de processus internes ».

Front end et back end

Une autre raison pour laquelle la sécurité des microservices est plus complexe : Il y a beaucoup plus d’éléments exposés aux attaques. Comme l'a expliqué Owen Garrett, « la surface d'attaque d'une application microservices est beaucoup plus grande que celle d’une application monolithique traditionnelle ». Dans ce dernier cas, « la surface d'attaque est très linéaire : le trafic arrive d’abord à l'équilibreur de charge, puis au web (couche de présentation), ensuite à l'application et aux données ». Mais dans le cas de l’architecture microservices, le chef de produits de Nginx fait remarquer que le flux est totalement différent : « De façon générale, il faut exposer un grand nombre de services différents pour que les applications externes y répondent directement, d’où une surface d'attaque beaucoup plus importante ». Comme l’a également expliqué Kelsey Hightower, chef de produit et promoteur en chef de CoreOS, « si l’on casse l’application en petits services, il est nécessaire d’avoir une solution d'authentification/autorisation plus robuste entre chaque service. Beaucoup d’entreprises savent mettre en œuvre ce niveau de sécurité entre les utilisateurs et leurs produits, mais elles auraient du mal à le reproduire pour les microservices ».

Il faut encore sécuriser l'accès aux données. Jonah Kowall, vice-président du développement des marchés chez AppDynamics, s’est intéressé à la façon dont Netflix stockait ses données. La plateforme est un utilisateur influent de microservices. « Netflix recommande de garder le stockage des données dans chaque service autonome », a-t-il déclaré par téléphone à nos confrères de JavaWorld. Cette pratique réduit les interdépendances entre services, mais elle augmente le nombre de magasins de données. Au lieu de résider dans un seul référentiel central (comme la base de données relationnelle d'une application monolithique traditionnelle), dans l’architecture microservices les données sont hautement distribuées. Elles sont même réparties entre plusieurs types de magasins de données (Cassandra et Riak, dans le cas de Netflix). « Cette question devient donc un problème majeur de sécurité, puisqu’il n’y a plus de solution centralisée pour voir s’il se passe des choses indésirables », fait encore remarquer Jonah Kowall. Ce mode de fonctionnement « pose beaucoup de questions sur la source qui sert de référence pour valider la conformité, ou pour valider toute sorte de valeur ou de règle que vous essayez de mettre en œuvre pour contrôler la sécurité ».

L’importance du contenu

Les défis posés par les technologies de serveur de base de données relationnelle s’appliquent aux microservices eux-mêmes. Parce que ces microservices peuvent être composés de manière indépendante les uns des autres, les développeurs prennent souvent la liberté de choisir des langages, des frameworks, des middlewares différents, et ainsi de suite. Si bien que le contexte de sécurité de chaque microservices peut être radicalement différent. Comme le dit Owen Garrett, « les problèmes sont aggravés par le fait que chaque microservice est développé indépendamment des autres, avec son propre langage et son propre framework de développement, sans tenir éventuellement compte de normes universelles en matière de sécurité ».

Les microservices reposant sur des conteneurs, la question devient encore plus problématique quand on réalise que les conteneurs ont la mauvaise réputation d'être opaques. Certaines solutions arrivent sur le marché, comme celle de Twistlock, lequel commercialise un système de sécurité qui doit permettre aux développeurs à avoir une meilleure prise sur ce qui se passe à l'intérieur des conteneurs. Mais il ne faut pas s’attendre à voir émerger une solution unique et cohérente tant que le monde du conteneur ne fixera pas ses propres normes. De meilleures pratiques existent pour les créateurs de microservices, y compris ceux qui essayent de résoudre les problèmes de sécurité. À ce jour, la liste des meilleures pratiques est sans doute celle établie par Graham Lea, y compris pour la sécurité. Cette liste est longue et probablement intimidante, mais elle témoigne de la difficulté qu’il y a à sécuriser correctement les microservices, et pas toujours pour des raisons techniques. En fin de compte, celui qui développe quelque chose d’entièrement nouveau avec l’architecture microservices est un peu livré à lui-même, mais c’est sans doute ce qui se passe avec toute technologie de pointe.