Après le déploiement en production, les événements S3 dans les environnements de développement ont commencé à invoquer les fonctions Lambda de production, provoquant des exécutions indésirables. L'équipe doit arrêter les invocations inter-environnements et suivre les meilleures pratiques de sécurité. Quelle solution répond à ces exigences ?

La bonne réponse est de déplacer le développement et la production dans des comptes AWS distincts et d'ajouter une politique de ressource à chaque Lambda qui autorise les invocations uniquement à partir des compartiments S3 du même compte. Cette approche est une bonne pratique de sécurité qui garantit une isolation complète entre les environnements. Les politiques de ressources Lambda sont le mécanisme approprié pour contrôler les sources d'invocation. Mettre à jour le rôle d'exécution Lambda de production pour autoriser la lecture uniquement du compartiment S3 de production est incorrect car le rôle d'exécution contrôle les permissions que la fonction Lambda a pour interagir avec d'autres services, et non qui peut l'invoquer. Ajouter une politique de ressource à la fonction Lambda de production qui autorise l'invocation uniquement à partir du compartiment S3 de production est une bonne étape, mais ne résout pas la séparation des environnements. Les invocations inter-environnements pourraient toujours se produire si les environnements sont dans le même compte. Déplacer le développement et la production dans des comptes AWS distincts, et mettre à jour chaque rôle d'exécution Lambda pour autoriser la lecture uniquement du compartiment S3 dans le même compte est incorrect pour la même raison que la première option : le rôle d'exécution ne contrôle pas les invocations.