Editions ENI Livres | Vidéos | e-Formations
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.
Pour une présentation complète du service IAM, n’hésitez pas à consulter l’ouvrage intitulé AWS : Gérez votre infrastructure sur la plateforme cloud d’Amazon, du même auteur paru aux Éditions ENI en décembre 2019.
1. Utilisateurs, groupes et rôles
Pour utiliser les services AWS on a besoin d’accéder à son API. Ceci peut se faire, comme on l’a vu, via la console AWS, via AWS CLI ou via le SDK (Software Development Kit). Mais quelle que soit la manière par laquelle on y accède, AWS a besoin de savoir qui exactement se trouve à l’origine des appels et des requêtes. On parle là du processus d’authentification. AWS a aussi besoin de savoir si l’utilisateur à l’origine des différents appels et requêtes possède bien des droits d’accès suffisants aux ressources faisant l’objet de ces interactions. C’est le processus d’autorisation dont on parle là.
Pour réaliser ces processus d’authentification et d’autorisation, AWS utilise des accréditations pour signer les requêtes. Ces accréditations peuvent être temporaires, dans ce cas leur validité est limitée dans le temps et, par conséquent, elles doivent être régénérées.
Lors de la création d’un compte AWS, c’est un compte de type root qui est créé, c’est-à-dire un compte qui a un accès complet à toutes les ressources du compte, y compris...
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...
