La sécurité des fonctions Lambda

Introduction

Lors des chapitres précédents, nous avons développé une application relativement complexe, qui implémente un flux de traitement mettant en œuvre une API REST, des composants événementiels, des files d’attente et des bases de données. Mais ce faisant, nous avons ignoré un des principes essentiels de toute application, et à plus forte raison de toute application cloud : la sécurité.

En effet, les fonctions Lambda présentées étaient sans protection aucune et accessibles à tout utilisateur ayant un compte AWS. Si on peut accepter qu’un tel scénario ne pose pas de problèmes lorsqu’il s’agit d’implémenter et tester quelques cas d’école simplifiés, dès l’instant où il s’agit d’une application qui expose des containers S3 pour y stocker des données sensibles, des files d’attente contenant des ordres de paiement, des bases de données avec des données bancaires confidentielles, il est hors de question de laisser libre accès à ces ressources critiques. C’est pourquoi, dans ce chapitre, nous allons examiner la sécurité proposée par l’infrastructure AWS et nous allons protéger nos API et nos fonctions Lambda de manière à y restreindre l’accès...

Court rappel de la sécurité IAM

IAM (Identity Access Management) est le composant central dans le paysage de l’infrastructure AWS responsable de la sécurité des services, de l’authentification et de l’autorisation. Ce composant est transversal et, par conséquent, n’est pas spécifique à certains services AWS, comme le service Lambda qui est l’objet de notre ouvrage. À ce titre, si un court rappel des notions fondamentales de la sécurité AWS peut s’avérer utile avant que nous ne rentrions dans le vif du sujet, l’étude exhaustive du service IAM est largement en dehors de la portée de ce livre.

L’authentification en environnement serverless

Une des premières questions que les gens posent lorsqu’il est question de l’authentification en environnement serverless est de savoir comment il est possible de conduire un processus d’authentification sans aucun serveur ? Pour répondre à cette question, nous allons devoir répondre d’abord à une question subsidiaire : dans le cas d’une architecture distribuée comme celle de l’application qu’on vient de développer, il existe des fonctionnalités transversales, comme la sécurité, la journalisation, le monitoring, etc., qui ne peuvent pas être implémentées au niveau de chaque composant, mais qui doivent être centralisées. Quel serait donc le service ou le composant qui devrait idéalement implémenter toutes ces fonctionnalités transverses, afin de garantir leur cohérence à travers l’ensemble des autres services et composants qui composent notre application ?

Tout d’abord, force est de constater qu’il serait très difficile d’implémenter les fonctionnalités transverses au niveau de chaque service, ce qui ferait évidemment qu’elles ne seraient plus transverses. Si on considère la question dans la perspective de l’activité quotidienne d’une équipe de développement, les développeurs doivent pouvoir se concentrer sur les détails fonctionnels spécifiques de leur user stories définies dans le backlog. Quant à la sécurité, la journalisation, etc., ces fonctionnalités doivent être prises en charge par la fondation d’architecture, qu’elle soit un framework ou un service tiers, etc.

Un second argument au service de la centralisation des fonctionnalités transverses est le fait que leur implémentation représente un véritable challenge. L’implémenter au niveau de chaque composant serait particulièrement pénible et pousser la responsabilité de leur implémentation au niveau individuel serait irresponsable, car cela augmenterait dramatiquement les risques que la qualité du code de l’ensemble de l’application ne soit pas de niveau industriel. 

Enfin, un troisième...