2016-02-09 2 views
18

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

+0

не вы говорите о полномочиях АМС – helloV

+2

нет, не AWS? учетные данные (например, Twilio API) –

+0

Почему вы не хотите хранить учетные данные в функции? Разве это не безопасно? –

ответ

1

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

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

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

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

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

2

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

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

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

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

5

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

+0

Да, KMS - отличный способ хранить зашифрованные данные. – Jurgen

+0

KMS кажется хорошим подходом. Просто не знаю, сколько это замедлит время обработки лямбда. – Nick

4

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

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

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

С AWS DOC 1 ...

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

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

ключ по умолчанию, конечно же,„ошибки при избранных“- что заставляет меня задаться вопросом, почему они поставили его в раскрывающемся меню на всех

Источники:

 Смежные вопросы

  • Нет связанных вопросов^_^