Хранилище параметров против зашифрованных переменных среды для лямбда-выражения

Недавно я готовился к специальному экзамену по безопасности, и у меня возник вопрос: выбрать между использованием хранилища параметров для хранения секретного URL-адреса подключения к базе данных, который может содержать пароли, или использования зашифрованных переменных среды KMS в лямбда-выражении.

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

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

Но до тех пор, почему SSM предпочтительнее использования переменных среды с шифрованием KMS, учитывая повышенную стоимость и задержку? (Это то, что я видел рекомендованными на практических экзаменах)


aws-lambda aws-kms aws-parameter-store
person Derrops    schedule 30.10.2020    source источник

Ответы (3)


arrow_upward
3
arrow_downward

В этой статье есть полезные моменты:

  • Трудно делиться конфигурациями между проектами
  • Трудно реализовать детальный контроль доступа
  • [SSM Parameter Store] записывает историю изменений.

Так что, как правило, использование SSM было бы более гибкой архитектурой. Тем не менее, если эти преимущества действительно не применимы к вам, вы все равно можете использовать переменные среды и уменьшить задержку, как вы указали. Дело не столько в том, что один ошибается, сколько в том, что другой, как правило, считается более продуманным подходом. Но в конкретных случаях могут потребоваться другие реализации.

В этой статье упоминается повышенная безопасность.

Хотя этот подход [с использованием переменных среды] прост и понятен, он имеет значительные недостатки в плане безопасности - секреты в среде существуют в виде открытого текста. Любой другой процесс, библиотека или зависимость, работающая внутри процесса, имеет доступ к среде, которая уже использовалась несколько раз.

Безопасность является важным фактором, и большинство вещей, которые делаются для повышения безопасности, приводят к задержкам или затратам на обработку по сравнению с менее безопасными альтернативами.

Некоторые другие мысли для рассмотрения:

person Shawn    schedule 03.11.2020

arrow_upward
1
arrow_downward

Самая большая причина, которая приходит на ум, - это возможность потреблять ваши токены / секреты несвязанным образом, что позволяет другим сервисам использовать те же токены. Например, если у вас есть две лямбды, обе из которых должны вызывать внешнюю службу с одним и тем же токеном API, вам нужно обновить только одно место. Если вы этого не сделали и скажем, токен был повернут, вам нужно будет перенастроить каждую лямбду, чтобы использовать новый токен, вместо того, чтобы делать одно обновление SSM.

person LostJon    schedule 30.10.2020
comment
Это хороший момент, я не думал об этом, в большинстве случаев у меня обычно есть только одна лямбда, но было бы более неудобно, если бы многие лямбды имели одни и те же секреты. - person Derrops; 03.11.2020

arrow_upward
1
arrow_downward

Подробная безопасность и преимущества единого источника достоверности SSM по сравнению с обычными переменными env были упомянуты выше как преимущества.

Чтобы избежать такого недостатка, как задержка, в этой статье представлены текущие рекомендации по ее устранению при чтении параметров из SSM:

https://aws.amazon.com/blogs/compute/sharing-secrets-with-aws-lambda-using-aws-systems-manager-parameter-store/

В основном, что вам нужно сделать, это прочитать env vars один раз во всем мире. Последующие вызовы одной и той же лямбды уже имеют к ним доступ, поэтому дополнительных циклов обращения к SSM не требуется.

person Augusto Samamé Barrientos    schedule 09.03.2021
comment
Наконец, функция выполнялась в течение 65 мс, из которых 63,5 мс было вызовом GetParametersByPath для хранилища параметров. - Иногда у меня лямбда-выражения короче 10 мс. Это не хорошо. - person Derrops; 09.03.2021