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

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

5 голосов
/ 13 июля 2020

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

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

PSD2 требует взаимного TLS, что нормально, и у нас все правильно реализовано и работает в песочнице environment.

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

{
  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 АКМ . Однако неясно, как мы могли бы получить путь к сертификатам (после их загрузки), чтобы использовать его в запросе выше.

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

Ответы [ 2 ]

3 голосов
/ 13 июля 2020

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

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

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

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

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

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

1 голос
/ 14 июля 2020

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

As 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 с использованием надежно хранимых закрытых ключей.

...