Nuestro equipo utiliza las funciones de AWS Lambda y API Gateway para facilitar las conexiones a las API de banca abierta dentro de Europa. ( PSD2 ).
Nuestras Lambda están escritas en NodeJS.
PSD2 requiere Mutual TLS, lo cual está bien y tenemos todo correctamente implementado y funcionando en un entorno sandbox.
Una solicitud de ejemplo se vería así:
{ 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 }El problema que tenemos actualmente es que no estamos seguros de dónde almacenar de forma segura nuestros certificados. Por el momento, solo los estamos almacenando en una carpeta de activos en nuestra base de código, esto no es lo ideal y nos gustaría sacarlos de nuestra base de código por razones obvias.
Hemos estado buscando en AWS ACM . Sin embargo, no está claro cómo recuperaríamos una ruta a los certificados (después de cargarlos) para usarla en la solicitud anterior.
Entonces, mi pregunta es , ¿cómo usaríamos AWS para almacenar de forma segura nuestros certificados de tal manera que podamos usarlos en una solicitud HTTPS?
No puede recuperar certificados de ACM; de hecho, estos se adjuntan a los recursos de AWS únicamente, como CloudFront, ELB y API Gateway.
Para recuperar los contenidos hay un par de soluciones.
El primero es almacenar esto en un almacén de credenciales/secretos, AWS proporciona esta funcionalidad en el servicio de administración de secretos . Además, puede almacenar una SecureString en el almacén de parámetros del administrador de sistemas .
Alternativamente, podría usar una solución de terceros como HashiCorp Vault .
Con este enfoque, si necesita que el archivo exista en el disco, deberá almacenar la salida en el almacenamiento de archivos tmp.
Si estos enfoques no funcionan para usted, puede utilizar AWS EFS . Una adición reciente ha agregado soporte para permitir que Lambdas tenga un montaje NFS adjunto para compartir almacenamiento.
Creo que, en última instancia, está buscando una solución como AWS KMS o CloudHSM , que le permita almacenar de forma segura sus claves privadas y realizar funciones criptográficas en lugar de revelar las claves para "uso externo". Esta es la forma más segura, ya que ni siquiera usted podrá ver las claves (aunque CloudHSM en realidad permite cargar/descargar claves).
Como el módulo TLS de Node.js se basa en OpenSSL y CloudHSM viene con un motor de openssl listo para usar que podrá usar para Mutual TLS. Las opciones privateKeyEngine , privateKeyIdentifier , publicKeyEngine y publicKeyIdentifier de tls.createSecureContext se usarán para eso.
Para AWS KMS (que es una solución mucho más rentable) hay un motor openssl de código abierto escrito en Rust .
Dicho esto, no estoy seguro de si puede usar motores OpenSSL personalizados en Lambda o si el motor CloudHSM está incluido en el entorno Node.js de Lambda (lo que sería muy lógico). Por lo tanto, también puede optar por "descargar" la conectividad TLS mutua a un "microservicio" que se ejecuta fuera de Lambda. Fuimos de esta manera e implementamos un intermediario muy simple que "proxy" llamadas mTLS utilizando claves privadas almacenadas de forma segura.