Dans AWS Lambda, où puis-je stocker en toute sécurité les informations d'identification de l'API?
J'ai une fonction lambda configurée via la passerelle API qui est censée atteindre une API externe via Node (ex: Twilio). Je ne veux pas stocker les informations d'identification des fonctions directement dans le fonction lambda. Y a-t-il un meilleur endroit pour les régler?
La fonctionnalité pour ce faire a probablement été ajoutée à Lambda après la publication de cette question.
La documentation AWS recommande d'utiliser les variables d'environnement pour stocker des informations sensibles. Ils sont chiffrés (par défaut) à l'aide de la clé déterminée par AWS (aws/lambda) lorsque vous créez une fonction Lambda à l'aide de la console AWS Lambda.
Il exploite AWS KMS et vous permet soit: d'utiliser la clé déterminée par AWS, soit de sélectionner votre propre clé KMS (en sélectionnant Activer les assistants de chiffrement); vous devez avoir créé la clé à l'avance.
Depuis AWS DOC 1 ...
"Lorsque vous créez ou mettez à jour des fonctions Lambda qui utilisent des variables d'environnement, AWS Lambda les chiffre à l'aide du service de gestion de clés AWS. Lorsque votre fonction Lambda est invoquée, ces valeurs sont déchiffrées et mises à la disposition du code Lambda.
La première fois que vous créez ou mettez à jour des fonctions Lambda qui utilisent des variables d'environnement dans une région, une clé de service par défaut est créée automatiquement pour vous dans AWS KMS. Cette clé est utilisée pour crypter les variables d'environnement. Cependant, si vous souhaitez utiliser des assistants de chiffrement et utiliser KMS pour chiffrer les variables d'environnement après la création de votre fonction Lambda, vous devez créer votre propre clé AWS KMS et la choisir à la place de la clé par défaut. La clé par défaut donnera des erreurs lorsqu'elle sera choisie. "
La clé par défaut "donne certainement des erreurs lorsqu'elle est choisie" - ce qui me fait me demander pourquoi ils l'ont mis dans la liste déroulante.
Sources:
Même si je ne l'ai pas encore fait moi-même, vous devriez pouvoir utiliser AWS KMS pour chiffrer/déchiffrer les clés d'API à partir de la fonction, accordant au rôle Lambda l'accès aux clés KMS.
Tout service de stockage ou service de base de données sur AWS sera en mesure de résoudre votre problème ici. La question est de savoir ce que vous utilisez déjà dans votre fonction AWS Lambda actuelle? Sur cette base, et les considérations suivantes:
- Si vous en avez besoin rapidement et que le coût n'est pas un problème, utilisez Amazon DynamoDB
- Si vous en avez besoin rapidement et faites attention au coût, utilisez Amazon ElastiCache (Redis ou Memcache)
- Si vous utilisez déjà une base de données relationnelle, utilisez Amazon RDS
- Si vous n'utilisez rien et n'en avez pas besoin rapidement, utilisez Amazon S
Dans tous les cas, vous devez créer une politique de sécurité (rôle IAM ou politique de compartiment S3) pour permettre un accès exclusif entre Lambda et votre choix de stockage/base de données.
Remarque: Amazon VPC la prise en charge d'AWS Lambda est proche, donc toute solution que vous choisissez, assurez-vous qu'elle se trouve dans le même VPC avec votre fonction Lambda (en savoir plus sur https: // connect .awswebcasts.com/vpclambdafeb2016/event/event_info.html )
Je suppose que vous ne faites pas référence aux informations d'identification AWS, mais plutôt aux informations d'identification de l'API externe?
Je ne sais pas que c'est un excellent endroit, mais j'ai trouvé des messages sur les forums AWS où les gens mettent des informations d'identification sur S3.
Ce n'est pas votre cas d'utilisation spécifique, mais consultez ce fil de discussion.
https://forums.aws.Amazon.com/thread.jspa?messageID=686261
Si vous mettez les informations d'identification sur S3, assurez-vous simplement de les sécuriser correctement. Envisagez de le rendre disponible uniquement pour un rôle IAM spécifique qui est uniquement affecté à cette fonction Lambda.