Mejores prácticas para AWS CloudHSM - AWS CloudHSM

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Mejores prácticas para AWS CloudHSM

Siga las prácticas recomendadas de este tema para usar AWS CloudHSM de manera eficaz.

Administración de clústeres

Siga las prácticas recomendadas de esta sección al crear el AWS CloudHSM clúster, acceder a él y administrarlo.

Escale su clúster para gestionar los picos de tráfico.

Existen varios factores que pueden influir en el rendimiento máximo que puede gestionar su clúster, tales como el tamaño de la instancia de cliente, el tamaño del clúster, la topografía de la red y las operaciones criptográficas que necesite para su caso de uso.

Como punto de partida, consulte el tema AWS CloudHSM Rendimiento para obtener más información sobre las estimaciones de rendimiento en los tamaños y configuraciones de clúster más comunes. Le recomendamos que realice una prueba de carga de su clúster con la carga máxima prevista para determinar si su arquitectura actual es resiliente y tiene la escala adecuada.

Diseñe su clúster para conseguir una alta disponibilidad.

Añada redundancia para tener en cuenta el mantenimiento: AWS puede sustituir su HSM para un mantenimiento programado o si detecta un problema. Como regla general, el tamaño del clúster debe tener una redundancia de, al menos, +1. Por ejemplo, si necesita dos HSM para que su servicio funcione en las horas punta, el tamaño ideal de su clúster será de tres. Si sigue las prácticas de disponibilidad recomendadas, estas sustituciones de HSM no deberían afectar a su servicio. Sin embargo, es posible que las operaciones en curso en el HSM sustituido fallen. En tal caso, deberán realizarse de nuevo.

Distribuya sus HSM en distintas zonas de disponibilidad: considere cómo funcionará su servicio si se produce una interrupción en la zona de disponibilidad. AWS recomienda que distribuya sus HSM en tantas zonas de disponibilidad como sea posible. En el caso de un clúster con tres HSM, debería distribuir los HSM en tres zonas de disponibilidad. En función de su sistema, es posible que necesite redundancia adicional.

Tenga, al menos, tres HSM para garantizar la durabilidad de las claves recién generadas.

En el caso de las aplicaciones que requieren la durabilidad de las claves recién generadas, le recomendamos al menos tres instancias de HSM distribuidas en todas las zonas de disponibilidad de una región.

Acceso seguro a su clúster

Use subredes privadas para limitar el acceso a su instancia: lance sus HSM e instancias de cliente en las subredes privadas de su VPC. Esto limita el acceso a sus HSM desde el exterior.

Utilice puntos de enlace de VPC para acceder a las API: el plano de AWS CloudHSM datos se diseñó para funcionar sin necesidad de acceder a Internet o a las API de AWS. Si tu instancia de cliente requiere acceso a la AWS CloudHSM API, puedes usar los puntos de enlace de la VPC para acceder a la API sin requerir acceso a Internet en tu instancia de cliente. Para obtener más información, consulte AWS CloudHSM y puntos finales de VPC.

Reconfigura el SSL para proteger la comunicación entre el cliente y el servidor: AWS CloudHSM usa TLS para establecer una conexión con tu HSM. Una vez inicializado el clúster, puede sustituir la clave y el certificado TLS predeterminados que se usan para establecer la conexión TLS externa. Para obtener más información, consulte Mejore la seguridad de su servidor web con la descarga de SSL/TLS en AWS CloudHSM.

Reduzca los costos escalando en función de sus necesidades.

Su uso de AWS CloudHSM no conlleva costos iniciales. Usted paga una tarifa por hora por cada HSM que lance hasta que cancele el HSM. Si su servicio no requiere un uso continuo AWS CloudHSM, puede reducir los costos reduciendo (eliminando) sus HSM a cero cuando no los necesite. Cuando vuelva a necesitar los HSM, podrá restaurarlos a partir de una copia de seguridad. Si, por ejemplo, tiene una carga de trabajo que requiere que firme el código una vez al mes, concretamente el último día del mes, puede escalar su clúster antes, reducirlo verticalmente eliminando los HSM una vez finalizado el trabajo y, a continuación, restaurar el clúster para realizar de nuevo las operaciones de firma a finales del mes siguiente.

AWS CloudHSM realiza automáticamente copias de seguridad periódicas de los HSM del clúster. Cuando añada un nuevo HSM más adelante, AWS CloudHSM restaurará la última copia de seguridad en el nuevo HSM para que pueda reanudar su uso desde el mismo lugar en el que lo dejó. Para calcular los costes de su AWS CloudHSM arquitectura, consulte AWS CloudHSM los precios.

Recursos relacionados:

Administración de usuarios de HMS

Siga las prácticas recomendadas de esta sección para gestionar de forma eficaz los usuarios de su AWS CloudHSM clúster. Los usuarios de HSM son distintos de los usuarios de IAM. Los usuarios y las entidades de IAM que tengan una política basada en identidad con los permisos adecuados pueden crear HSM interactuando con los recursos a través de la API de AWS. Una vez creado el HSM, deberá introducir las credenciales de usuario de HSM para autenticar las operaciones del mismo. Para consultar una guía detallada de los usuarios de HSM, acceda a Administrar usuarios de HSM en AWS CloudHSM.

Proteja las credenciales de sus usuarios de HSM.

Es imprescindible que mantenga las credenciales de sus usuarios de HSM protegidas de forma segura, ya que los usuarios de HSM son las entidades que pueden acceder al mismo y realizar operaciones criptográficas y de gestión. AWS CloudHSM no tiene acceso a sus credenciales de usuario de HSM, y no podrá ayudarle si las pierde.

Tenga, al menos, dos administradores para evitar bloqueos.

Para evitar posibles bloqueos de acceso a su clúster, le recomendamos que tenga, al menos, dos administradores, por si se extravía una contraseña de administrador. En caso de que esto suceda, el otro administrador podrá restablecer la contraseña.

nota

Los administradores de SDK 5 de cliente son lo mismo que los responsables de criptografía (CO) en SDK 3 de cliente.

Habilite el cuórum para todas las operaciones de gestión de usuarios.

El cuórum le permite definir el número mínimo de administradores que deben aprobar una operación de gestión de usuarios para que se pueda llevar a cabo dicha operación. Debido a los privilegios que tienen los administradores, le recomendamos que habilite el cuórum para todas las operaciones de gestión de usuarios. Esta medida puede limitar las posibles repercusiones en caso de que una de sus contraseñas de administrador se vea comprometida. Para obtener más información, consulte Administración de cuórum.

Cree varios usuarios de criptografía con permisos limitados.

Al separar las responsabilidades de los usuarios de criptografía, ninguno de ellos puede controlar por completo el sistema. Por esta razón, le recomendamos que cree varios usuarios de criptografía con permisos limitados. Por lo general, deberá asignar responsabilidades y acciones claramente diferenciadas a los usuarios de criptografía. Por ejemplo, uno se encargará de generar y compartir claves con otros usuarios para que estos las usen en su aplicación.

Recursos relacionados:

Administración de claves HSM

Siga las prácticas recomendadas de esta sección para gestionar claves en AWS CloudHSM.

Elija el tipo de clave correcto.

Cuando use una clave de sesión, sus transacciones por segundo (TPS) se limitarán a un HSM donde exista la clave. Los HSM adicionales en el clúster no aumentarán el rendimiento de solicitudes de esa clave. Si usa una clave de token para la misma aplicación, se equilibrará la carga de sus solicitudes entre todos los HSM disponibles en su clúster. Para obtener más información, consulte Ajustes clave de sincronización y durabilidad en AWS CloudHSM.

Gestione los límites de almacenamiento de claves.

El número máximo de claves de sesión y de token que se pueden almacenar a la vez en un HSM es limitado. Para obtener información sobre los límites de almacenamiento de claves, consulte AWS CloudHSM cuotas. Si su aplicación requiere una cantidad superior al límite, puede emplear una o varias de las siguientes estrategias para gestionar las claves de forma eficaz:

Use un empaquetado fiable para almacenar las claves en un almacén de datos externo: si emplea un encapsulado de claves fiable, puede superar el límite de almacenamiento de claves guardándolas todas en un almacén de datos externo. Cuando tenga que usar una clave, puede desencapsularla en el HSM como clave de sesión, usarla para la operación requerida y, a continuación, descartar la clave de sesión. Los datos de la clave original permanecerán almacenados de forma segura en su almacén de datos para usarla siempre que la necesite. El uso de claves fiables maximiza su protección.

Distribuya las claves entre los clústeres: otra estrategia para superar el límite de almacenamiento de claves consiste en almacenar las claves en múltiples clústeres. Con este método, deberá mapear las claves almacenadas en cada clúster. Utilice este mapeo para dirigir las solicitudes de sus clientes al clúster con la clave requerida. Para saber cómo conectarse a varios clústeres desde una misma aplicación de cliente, consulte los siguientes temas:

Gestionar y proteger el empaquetado de claves.

Las claves pueden marcarse como extraíbles o no extraíbles mediante el atributo EXTRACTABLE. De forma predeterminada, las claves de HSM se marcan como extraíbles.

Las claves extraíbles son aquellas que se pueden exportar desde el HSM mediante encapsulado de claves. Las claves empaquetadas se cifran, y se deben desencapsular con la misma clave de encapsulado para poder utilizarlas. Las claves no extraíbles no se pueden exportar desde el HSM bajo ninguna circunstancia. No es posible convertir una clave no extraíble en extraíble. Por ello, es importante que considere la necesidad de que sus claves sean o no extraíbles para definir el correspondiente atributo en consecuencia.

Si necesita empaquetar claves en su aplicación, deberá emplear un encapsulado de claves fiable, que permita limitar la capacidad de los usuarios de HSM. Así, estos solo podrán encapsular y desencapsular las claves que un administrador haya marcado explícitamente como de confianza. Para obtener más información, consulte los temas sobre encapsulado de claves de confianza en Administrar claves en AWS CloudHSM.

Recursos relacionados

Integración de aplicaciones

Siga las prácticas recomendadas de esta sección para optimizar la forma en que la aplicación se integra con el AWS CloudHSM clúster.

Inicie su SDK de cliente.

Debe iniciar su SDK de cliente antes de conectarlo a su clúster. Al iniciar las direcciones IP en el clúster, le recomendamos que use el parámetro --cluster-id siempre que sea posible. Este método rellena la configuración con todas las direcciones IP de HSM de su clúster sin necesidad de supervisar cada dirección individual. De este modo, se añade una mayor resiliencia a la inicialización de la aplicación en caso de que un HSM se encuentre en mantenimiento o se produzca una interrupción en la zona de disponibilidad. Para obtener más información, consulte Proceso de arranque del SDK de cliente.

Autentíquese para realizar operaciones.

En AWS CloudHSM, debe autenticarse en el clúster antes de poder realizar la mayoría de las operaciones, como las operaciones criptográficas.

Autenticación con la CLI de CloudHSM: puede autenticarse con la CLI de CloudHSM usando el modo de comando único o bien el modo interactivo. Ejecute el comando login para autenticarse en modo interactivo. Para autenticarse en modo de comando único, debe configurar las variables de entorno CLOUDHSM_ROLE y CLOUDHSM_PIN. Para obtener más información al respecto, consulte Modo de comando único. AWS CloudHSM recomienda almacenar de forma segura sus credenciales de HSM cuando no las use su aplicación.

Autenticarse con PKCS #11: en PKCS #11, inicia sesión con la API C_Login después de abrir una sesión con C_. OpenSession Solo necesita ejecutar un C_Login por ranura (clúster). Una vez que haya iniciado sesión correctamente, podrá abrir sesiones adicionales con C_ OpenSession sin necesidad de realizar operaciones de inicio de sesión adicionales. Para ver ejemplos de autenticación en PKCS #11, consulte Ejemplos de código para la biblioteca PKCS #11.

Autenticarse con JCE: el proveedor de AWS CloudHSM JCE admite el inicio de sesión tanto implícito como explícito. El método que más le convenga del caso de uso. Siempre que sea posible, recomendamos usar el inicio de sesión implícito, ya que el SDK gestionará automáticamente la autenticación si la aplicación se desconecta de su clúster y necesita volver a autenticarse. El inicio de sesión implícito también le permite proporcionar credenciales a su aplicación cuando use una integración que no le permita controlar el código de la aplicación. Para obtener más información sobre los métodos de inicio de sesión, consulte Proporcione las credenciales al proveedor de JCE..

Autenticación con OpenSSL: con el motor dinámico de OpenSSL, las credenciales se proporcionan a través de variables de entorno. AWS CloudHSM recomienda almacenar de forma segura sus credenciales de HSM cuando la aplicación no las utilice. Si es posible, debe configurar su entorno para recuperar y configurar sistemáticamente estas variables de entorno sin necesidad de introducirlas manualmente. Para obtener más información sobre la autenticación con OpenSSL, consulte Instalación del motor dinámico de OpenSSL.

Gestione eficazmente las claves de su aplicación.

Use los atributos de clave para controlar lo que pueden hacer las claves: al generar una clave, use los atributos de clave para definir un conjunto de permisos que permitan o denieguen a esa clave realizar tipos específicos de operaciones. Recomendamos que las claves se generen con la cantidad mínima de atributos necesarios para completar la tarea. Por ejemplo, una clave AES que se usa para el cifrado no debería tener permisos para encapsular claves fuera del HSM. Para obtener más información, consulte nuestras páginas de atributos de los siguientes SDK de cliente:

Cuando sea posible, almacene en caché los objetos de clave para minimizar la latencia: las operaciones de búsqueda de claves consultarán todos los HSM del clúster. Esta operación es costosa, y no escala según el número de HSM de su clúster.

  • Con PKCS #11, puede usar la API de C_FindObjects para encontrar claves.

  • Con JCE, las claves se encuentran mediante. KeyStore

Para obtener un rendimiento óptimo, se AWS recomienda utilizar los comandos de búsqueda de teclas (como findKey ykey list) solo una vez durante el inicio de la aplicación y almacenar en caché el objeto clave devuelto en la memoria de la aplicación. Si necesita este objeto de clave más adelante, podrá recuperarlo de la memoria caché en lugar de consultarlo en cada operación, lo que aumentará considerablemente el rendimiento.

Emplee subprocesamiento múltiple.

AWS CloudHSM admite aplicaciones con varios subprocesos, pero hay ciertas cosas que se deben tener en cuenta con las aplicaciones con varios subprocesos.

Con PKCS #11, deberá inicializar la biblioteca PKCS #11 (llamando a C_Initialize) una sola vez. Debe asignar a cada proceso su propia sesión (C_OpenSession). No es recomendable usar la misma sesión en múltiples procesos.

Con JCE, el AWS CloudHSM proveedor debe inicializarse solo una vez. No comparta instancias de objetos SPI entre procesos. Por ejemplo, Cipher, Signature, Digest, Mac KeyFactory o KeyGenerator los objetos solo deben utilizarse en el contexto de su propio hilo.

Gestione los errores de limitación.

Es posible que se produzcan errores de limitación del HSM en las siguientes circunstancias:

  • El clúster no está escalado correctamente para gestionar los picos de tráfico.

  • El tamaño del clúster no tiene una redundancia de +1 durante los eventos de mantenimiento.

  • Las interrupciones en la zona de disponibilidad reducen el número de HSM disponibles en el clúster.

Consulte Limitación de HSM para obtener más información sobre la mejor manera de gestionar este escenario.

Para asegurarse de que su clúster tiene el tamaño adecuado y no se agotará, le AWS recomienda que realice una prueba de carga en su entorno con los picos de tráfico esperados.

Integre los reintentos en las operaciones del clúster.

AWS puede reemplazar su HSM por motivos operativos o de mantenimiento. Para que su aplicación sea resistente a estas situaciones, le AWS recomienda implementar una lógica de reintentos del lado del cliente en todas las operaciones que se enruten a su clúster. Es de esperar que los posteriores reintentos de las operaciones fallidas debido a las sustituciones se realicen correctamente.

Implemente estrategias de recuperación de desastres.

Puede que sea necesario desviar el tráfico de todo un clúster o región en respuesta a un evento. En las siguientes secciones se describen varias estrategias para ello.

Use el emparejamiento de VPC para acceder a su clúster desde otra cuenta o región: puede utilizar el emparejamiento de VPC para acceder a su AWS CloudHSM clúster desde otra cuenta o región. Para obtener más información sobre la configuración, consulte ¿Qué es una conexión de emparejamiento de VPC? en la Guía de emparejamiento de VPC de Amazon. Una vez haya establecido las conexiones de emparejamiento y configurado los grupos de seguridad de forma adecuada, podrá comunicarse con las direcciones IP de los HSM de la misma manera que lo haría normalmente.

Conéctese a varios clústeres desde la misma aplicación: el proveedor JCE, la biblioteca PKCS #11 y la CLI de CloudHSM en Client SDK 5 admiten la conexión a varios clústeres desde la misma aplicación. Por ejemplo, puede tener dos clústeres activos, cada uno en una región distinta. Su aplicación puede conectarse a ambos a la vez y equilibrar la carga entre los dos como parte de su operativa normal. Si su aplicación no usa SDK 5 de cliente (el SDK más reciente), no podrá conectarse a varios clústeres desde una misma aplicación. Como alternativa, puede mantener otro clúster en funcionamiento y, en caso de que se produzca una interrupción regional, transferir el tráfico al otro clúster para minimizar el tiempo de inactividad. Consulte las páginas correspondientes para obtener más información:

Restaure un clúster a partir de una copia de seguridad: puede crear un clúster nuevo a partir de una copia de seguridad de un clúster existente. Para obtener más información, consulte Administración de AWS CloudHSM copias de seguridad.

Supervisión

En esta sección se describen varios mecanismos con los que puede supervisar el clúster y la aplicación. Para obtener información adicional sobre la supervisión, consulte Monitorización AWS CloudHSM.

Supervisión de registros de clientes

SDK de cliente genera registros que usted puede supervisar. Para obtener más información sobre los registros de cliente, consulte Trabajo con los registros de SDK de cliente.

En plataformas diseñadas para ser efímeras, como Amazon ECS AWS Lambda, recopilar los registros de los clientes a partir de un archivo puede resultar difícil. En estas situaciones, se recomienda configurar el registro de SDK de cliente para generar los registros en la consola. La mayoría de los servicios recopilarán automáticamente este resultado y lo publicarán en Amazon CloudWatch Logs para que lo guardes y lo veas.

Si utiliza una integración de terceros además del SDK de AWS CloudHSM cliente, asegúrese de configurar ese paquete de software para que registre también su salida en la consola. Este paquete puede capturar el resultado del SDK del AWS CloudHSM cliente y, de lo contrario, escribirlo en su propio archivo de registro.

Consulte Herramienta de configuración de SDK 5 de cliente para obtener más información sobre cómo configurar las opciones de registro en su aplicación.

Monitoreo de registros de auditoría

AWS CloudHSM publica registros de auditoría en tu CloudWatch cuenta de Amazon. Los registros de auditoría provienen del HSM, y supervisan determinadas operaciones con fines de auditoría.

Puede usar los registros de auditoría para supervisar cualquier comando de administración invocado en su HSM. Por ejemplo, puede activar una alarma cuando detecte que se está realizando una operación de administración inesperada.

Consulte Cómo funciona el registro de auditoría de HSM para obtener más detalles.

Supervise AWS CloudTrail

AWS CloudHSM está integrado con AWS CloudTrail un servicio que proporciona un registro de las acciones realizadas por un usuario, un rol o un AWS servicio en AWS CloudHSM. AWS CloudTrail captura todas las llamadas a la API AWS CloudHSM como eventos. Las llamadas capturadas incluyen llamadas desde la AWS CloudHSM consola y llamadas en código a las operaciones de la AWS CloudHSM API.

Puede utilizarla AWS CloudTrail para auditar cualquier llamada a la API que se realice en el plano de AWS CloudHSM control para asegurarse de que no se esté produciendo ninguna actividad no deseada en su cuenta.

Para obtener más información, consulte Trabajar con AWS CloudTrail y AWS CloudHSM.

Supervisa CloudWatch las métricas de Amazon

Puedes usar CloudWatch las métricas de Amazon para monitorear tu AWS CloudHSM clúster en tiempo real. Las métricas se pueden agrupar por región, por ID de clúster y por ID de HSM.

Con CloudWatch las métricas de Amazon, puedes configurar CloudWatch las alarmas de Amazon para que te avisen de cualquier posible problema que pueda surgir y que pueda afectar a tu servicio. Recomendamos configurar alarmas para supervisar los siguientes aspectos:

  • Aproximación al límite de claves de un HSM

  • Aproximación al límite de número de sesiones de HSM en un HSM

  • Aproximación al límite de número de usuarios de HSM en un HSM

  • Diferencias en el recuento de claves o usuarios del HSM para identificar problemas de sincronización

  • Los HSM en mal estado pueden escalar el clúster hasta que AWS CloudHSM puedan resolver el problema

Para obtener más información, consulte Trabajar con Amazon CloudWatch Logs y AWS CloudHSM Audit Logs.