Tengo varios archivos de configuración y datos binarios que deben almacenarse encriptados en el disco. Solo el usuario que cifró debe poder descifrar la información. Hasta ahora, he utilizado con éxito DPAPI para cifrar y descifrar esta información.
Nuevo requisito: el sistema / estos datos ahora deben distribuirse en varias máquinas. Es básicamente un problema de implementación, pero un poco más complicado y automatizado. Ahora necesito poder descifrar datos en una máquina diferente a la que cifró los datos.
Por lo tanto, ya no puedo usar DPAPI fuera de la caja ya que los datos cifrados solo se pueden descifrar en la misma máquina. Sin embargo, me encantaría usar este principio de cifrado de usuario limpio, sin estar vinculado a una máquina.
Encontré este enlace pero es un poco excesivo y, en cualquier caso, no es como si hubiera Un producto que puedo usar.
Todos los clientes (bueno, todos son servidores de aplicaciones virtuales, pero en este escenario, llamémosles clientes) en este proyecto de alguna manera están conectados al servidor SQL. Por lo tanto, mi idea es usar SQL Server / SQLCLR como administrador de claves distribuido.
Por lo tanto, DPAPI se cambia para AES en cada cliente. La clave para AES local enc / dec se recupera al cifrar / descifrar desde el servidor SQL. En el servidor SQL, la clave AES se encripta utilizando DPAPI con SQLCLR, así que obtengo la misma funcionalidad que antes. Estoy pensando en una tabla básica con dos columnas que no son metadatos: usuario y la clave AES distribuida (encriptada). Obviamente, restringiré el acceso a esta base de datos / tabla solo a las cuentas de usuarios interesados.
-
¿Alguna falla de seguridad obvia en esta arquitectura? He descubierto que la clave AES tiene que estar "en claro" en la memoria en algún momento para poder asignarlo a la implementación del algoritmo .net, lo cual no es bueno.
-
¿Hay una mejor manera de lograr lo mismo? Tengo la sensación de que no puedo ser la primera persona en tener este problema y odiaría reinventar la rueda.