Asegurar las claves de cifrado de datos simétricas (AES) almacenadas en el HSM en la memoria del servidor

7

Mi proyecto requiere que cifre los datos confidenciales del usuario mediante el cifrado de datos simétricos (AES). Guardaré la clave AES (DEK) en un servicio de administración de claves basado en HSM (es decir, Azure Key Vault / AWS KMS) y recuperaré la clave para cifrar / descifrar datos en mi servidor Nodejs.

He buscado en las redes internas las mejores prácticas, sin embargo, los detalles y las explicaciones parecen ir tan lejos en cuanto a si las claves deben almacenarse en la base de datos, de forma rígida o externa (es decir, HSM, KMS, env var, etc. ...).

No he podido encontrar una aclaración suficiente sobre lo siguiente:

1) ¿Debo crear una clave de cifrado de datos AES diferente para cada usuario? Si es así, ¿cuál es el razonamiento detrás de esto? ¿Otra capa más de complejidad?

2) ¿Cuál es la mejor manera de proteger la clave contra ataques, como cuando el servidor es hackeado y rastreado / monitoreado?

3) ¿Es una mejor práctica recuperar la clave al iniciar el servidor, luego almacenar la clave en la memoria del servidor, O recuperar la clave cada vez que el servidor necesita cifrar datos para el usuario?

Gracias de antemano.

    
pregunta ryd3r 25.01.2016 - 13:55
fuente

2 respuestas

7

Has hecho varias preguntas aquí, así que voy a proporcionarte varias respuestas y un par de aclaraciones.

  

Estaré almacenando la clave AES (DEK) en un servicio de administración de claves basado en HSM (es decir, Azure Key Vault / AWS KMS) y recuperaré la clave para cifrar / descifrar datos en mi servidor Nodejs.

Esto no es generalmente lo que quieres hacer. Si está utilizando un HSM, el objetivo es que la clave permanezca dentro del HSM, y nunca se vaya. Una forma común de lograr esto es almacenar una clave de cifrado de clave (KEK) en el HSM, y la (s) clave (s) de cifrado de datos cifrados en otro lugar. En el caso de Azure Key Vault, estos podrían ser secretos recuperables. Estoy seguro de que Amazon tiene algo similar. Luego, cuando necesita usar un DEK, lo pasa al HSM, donde se descifra con el KEK y luego se lo devuelve.

  

1) ¿Debo crear una clave de cifrado de datos AES diferente para cada usuario? Si es así, ¿cuál es el razonamiento detrás de esto? ¿Otra capa más de complejidad?

Sí. La razón es que si una clave está comprometida, todos los datos no lo están, solo los datos cifrados con esta clave. (Los datos para un cliente, en otras palabras). Además, elimina la capacidad de muchas fallas de la aplicación (fuera de las fallas específicamente relacionadas con la recuperación de claves) para permitir que un cliente acceda accidentalmente a los datos de otro cliente.

  

2) ¿Cuál es la mejor manera de proteger la clave contra ataques, como cuando el servidor es hackeado y rastreado / monitoreado?

Asegure sus servidores. Y siga el resto de los consejos aquí, como solo exponer las teclas cuando sea necesario.

  

3) ¿Es una mejor práctica recuperar la clave al iniciar el servidor, luego almacenar la clave en la memoria del servidor, O recuperar la clave cada vez que el servidor necesita cifrar datos para el usuario?

Es mejor exponer las claves durante el tiempo mínimo requerido para realizar las operaciones de cifrado o descifrado que necesitan realizar. Recuperarlos cada vez que se inicia el servidor ciertamente suena excesivo. Depende de su criterio, ya sea que tenga más sentido para usted recuperarlos, cuando un usuario inicie sesión o espere a que se realice una operación de cifrado real. De nuevo, cuanto más pequeña sea la ventana, mejor, dentro de lo razonable.

    
respondido por el Xander 26.01.2016 - 02:30
fuente
0

técnicamente, cuando la clave está en un HSM, en primer lugar no debería poder salir tan rápido.

si es posible, requiere que el HSM requiera una autenticación especial para lanzar explícitamente las claves.

un HSM no es solo para el almacenamiento seguro de las claves, sino que también pueden realizar operaciones de cifrado como la firma, la eliminación o el cifrado, etc.

por lo tanto, dependiendo de si su HSM le permite hacerlo o no, configure un "nivel de usuario básico" que solo puede funcionar con la clave y un "nivel administrativo", que en realidad tiene acceso a la clave.

De esa manera, el servidor no podrá ver la clave en primer lugar y el HSM actuará como una caja negra.

    
respondido por el My1 25.01.2016 - 14:02
fuente

Lea otras preguntas en las etiquetas