Как управлять сертификатами клиентов для взаимного TLS, который будет использоваться в AWS Lambda

Наша команда использует функции AWS Lambda и API Gateway для облегчения подключения к открытым банковским API в Европе. (PSD2).

Наши лямбды написаны на NodeJS.

PSD2 требует Mutual TLS, и это нормально, и у нас все правильно реализовано и работает в среде песочницы.

Пример запроса мог бы выглядеть примерно так:

{
  hostname: '[bank hostname]',
  path: '[bank api endpoint]',
  method: 'GET',
  headers: {
    accept: 'application/json',
    signature: 'XXX',
    date: 'XXX',
    digest: 'XXX',
    'x-request-id': 'XXX',
    'tpp-signature-certificate': '[PATH_TO_CERTIFICATE]',
    authorization: 'Bearer [accessToken]',
  },
  cert: fs.readFileSync('/var/task/certs/cert.crt'), // Buffer
  key: fs.readFileSync('/var/task/certs/private.key'), // Buffer
}

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

Мы смотрели на AWS ACM. Однако неясно, как мы получим путь к сертификатам (после их загрузки), чтобы использовать его в запросе выше.

Итак, у меня вопрос: как использовать AWS для безопасного хранения наших сертификатов таким образом, чтобы мы могли использовать их в запросах HTTPS?

Источник

2 ответа

Решение

Вы не можете получить сертификаты из ACM, на самом деле они прикреплены только к ресурсам AWS, таким как CloudFront, ELB и API Gateway.

Есть несколько решений для получения содержимого.

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

В качестве альтернативы вы можете использовать стороннее решение, такое как HashiCorp Vault.

При таком подходе, если вам нужно, чтобы файл существовал на диске, вам нужно будет сохранить вывод в хранилище файлов tmp.

Если эти подходы вам не подходят, вы можете использовать AWS EFS. В недавнем дополнении добавлена ​​поддержка, позволяющая Lambdas подключать монтирование NFS к общему хранилищу.

Источник

Я думаю, что в конечном итоге вы ищете такое решение, как AWS KMS или CloudHSM, которое позволило бы вам безопасно хранить ваши закрытые ключи и выполнять криптографические функции, а не раскрывать ключи для "внешнего использования". Это наиболее безопасный способ, поскольку даже вы не сможете увидеть ключи (хотя CloudHSM фактически позволяет загружать / скачивать ключи).

Поскольку модуль Node.js TLS основан на OpenSSL, а CloudHSM поставляется с готовым движком openssl, который вы сможете использовать для Mutual TLS. ПараметрыprivateKeyEngine, privateKeyIdentifier, publicKeyEngine а также publicKeyIdentifier из tls.createSecureContext должны использоваться для этого.

Для AWS KMS (что является гораздо более экономичным решением) существует движок openssl с открытым исходным кодом, написанный на Rust.

При этом я не уверен, можете ли вы использовать собственные движки openssl в Lambda или движок CloudHSM включен в среду Lambda Node.js (что было бы очень логично). Таким образом, вы также можете "разгрузить" взаимное подключение TLS к "микрослужбе", работающей вне Lambda. Мы пошли по этому пути и реализовали очень простой брокер, "проксирующий" вызовы mTLS с использованием надежно хранимых закрытых ключей.

Источник
Другие вопросы по тегам