Fonctionne comme un service (plus sécurisé)
Il existe plusieurs approches modernes de l'architecture et du développement application qui prennent essentiellement la forme de « rendre les choses plus petites et donc plus efficaces ».
Les microservices et la fonction en tant que service (FaaS) reposent tous deux sur la notion de code hautement ciblé. Or, s’il est vrai que la plupart des organisations ne décomposent pas les applications en centaines de microservices ou en milliers de fonctions, elles se tournent vers cette conception. C'est souvent parce que cela facilite le développement Agile, car une équipe relativement petite peut concevoir, développer, puis affiner un service beaucoup plus rapidement qu'une grande application monolithique. Après tout, il est beaucoup plus facile d’écrire et de tester quelque chose qui comporte 1 000 lignes de code qu’une application plus volumineuse comportant 100 000 lignes de code.
Mais il existe un autre avantage intéressant des microservices et du FaaS qui n’est pas autant vanté qu’il le devrait : la sécurité.
Il existe de nombreuses discussions sur Internet - et j'en ai lu un nombre important - qui tentent de déterminer la densité de défauts et de vulnérabilités « moyenne du secteur ». Vous trouverez une large gamme d'estimations, certaines basées sur des analyses réelles de code source, et d'autres basées sur des chiffres autodéclarés. La NASA, par exemple, a fièrement vanté sa densité de défauts extrêmement faible comme l’une des raisons du succès du programme de navette spatiale. Il existe également des rapports basés sur des données collectées objectivement par des sociétés de sécurité comme WhiteHat, mais ses chiffres se concentrent sur les vulnérabilités par application et pas nécessairement par lignes de code.
Il n’y a pas de véritable consensus sur la densité des défauts et des vulnérabilités, si ce n’est que oui, il y en a une.
Il va toutefois de soi que moins vous écrivez de lignes de code, moins vous risquez d’introduire de défauts et de vulnérabilités. Tout aussi important, moins vous avez de lignes de code à parcourir pour trouver une vulnérabilité ou un défaut, plus vite vous le trouverez et, on le suppose, le corrigerez.
L’une des raisons pour lesquelles cela est vrai est la portée. Si mon microservice ou ma fonction se concentre sur la codification d’un aspect de la logique métier, sa mise en œuvre nécessite moins de logique et moins de bibliothèques. Cette portée plus restreinte signifie moins de risques d’introduire des erreurs de logique ou des vulnérabilités dans les bibliothèques (tierces ou autres) nécessaires à la mise en œuvre de cette logique supplémentaire. Chaque fois que vous devez inclure un autre composant ou faire appel à un autre service, vous introduisez des risques de défauts et de vulnérabilités.
Moins d’interfaces avec la fonction ou le microservice contribuent également à un code plus sécurisé. Chaque interface (un point d’entrée comme un appel d’API) introduit la possibilité d’une vulnérabilité car vous gérez la saisie de l’utilisateur. Et les saisies des utilisateurs, comme nous le savons tous, doivent toujours être traitées comme suspectes et potentiellement malveillantes .
Et si les microservices réduisent le potentiel de vulnérabilités et de défauts, alors réduire encore davantage la portée d’une fonction devrait encore diminuer cette possibilité.
Cela ne veut pas dire que les microservices et FaaS sont intrinsèquement plus sûrs que leurs homologues à trois niveaux et monolithiques. Un code bâclé est un code bâclé, peu importe le nombre de lignes qu'il occupe. Mais il est vrai que les deux architectures se prêtent à des pratiques de développement et de livraison qui peuvent conduire à un code plus sécurisé.
Garder à l'esprit les avantages en matière de sécurité lorsque vous évaluez ou implémentez des microservices et/ou FaaS peut réellement aider à empêcher le gonflement du code et à se défendre contre l'introduction de vulnérabilités.