В AWS Lambda, где я могу безопасно хранить учетные данные API?

У меня есть функция лямбда, настроенная через шлюз API, которая, как предполагается, попадает в внешний API через Node (например: Twilio). Однако я не хочу хранить учетные данные для функций прямо в лямбда-функции. Есть ли лучшее место для их установки?

Ответ 1

Пока я еще не сделал этого, вы должны использовать AWS KMS для шифрования/дешифрования ключей API из функции, предоставляя доступ к роли Lambda к ключам KMS.

Ответ 2

Функциональность для этого была, вероятно, добавлена в Lambda после публикации этого вопроса.

Документация AWS рекомендует использовать переменные среды для хранения конфиденциальной информации. Они шифруются (по умолчанию) с использованием ключа AWS (aws/lambda), когда вы создаете функцию Lambda с помощью консоли AWS Lambda.

Он использует AWS KMS и позволяет либо: использовать ключ, определенный AWS, либо выбрать свой собственный ключ KMS (выбрав "Включить помощники шифрования" ); вам нужно заранее создать ключ.

От AWS DOC 1...

"Когда вы создаете или обновляете функции Lambda, использующие переменные среды, AWS Lambda шифрует их с помощью службы управления ключами AWS. Когда вы вызываете функцию Lambda, эти значения дешифруются и становятся доступными для кода Lambda.

При создании или обновлении функций Lambda, использующих переменные среды в регионе, автоматически создается служебный ключ по умолчанию в AWMS KMS. Этот ключ используется для шифрования переменных среды. Однако, если вы хотите использовать помощники шифрования и использовать KMS для шифрования переменных среды после создания вашей функции Lambda, вы должны создать свой собственный ключ AWS KMS и выбрать его вместо стандартного ключа. Клавиша по умолчанию выдаст ошибки при выборе. "

Ключ по умолчанию, конечно, "дает ошибки при выборе", что заставляет меня задаться вопросом, почему они вообще попали в раскрывающееся меню.

Источники:

Ответ 3

Любая служба хранения или служба баз данных на AWS сможет решить вашу проблему здесь. Вопрос в том, что вы уже используете в своей текущей функции AWS Lambda? Исходя из этого, и следующие соображения:

Если вам это нужно быстро, а стоимость не является проблемой, используйте Amazon DynamoDB
Если вам это нужно быстро и разумно, используйте Amazon ElastiCache (Redis или Memcache)
Если вы уже используете некоторую реляционную базу данных, используйте Amazon RDS
Если вы ничего не используете и не нуждаетесь в нем быстро, используйте Amazon S3

В любом случае вам необходимо создать некоторую политику безопасности (роль IAM или политику корзины S3), чтобы разрешить эксклюзивный доступ между Lambda и вашим выбором хранилища/базы данных.

Примечание: Поддержка Amazon VPC для AWS Lambda не за горами, поэтому любое решение, которое вы выбираете, убедитесь, что оно в том же VPC с вашим Лямбда-функция (подробнее см. https://connect.awswebcasts.com/vpclambdafeb2016/event/event_info.html)

Ответ 4

Я предполагаю, что вы не имеете в виду учетные данные AWS, а скорее внешние учетные данные API?

Я не знаю, что это отличное место, но я нашел сообщения на форумах AWS, где люди вводят учетные данные на S3.

Это не ваш конкретный прецедент, но посмотрите этот форум.

https://forums.aws.amazon.com/thread.jspa?messageID=686261

Если вы поместите учетные данные на S3, просто убедитесь, что вы его правильно защищаете. Подумайте о том, чтобы сделать его доступным только для определенной роли IAM, которая назначается только этой лямбда-функции.