Uso de DPAPI/ProtectedData en un entorno de granja de servidores web con la tienda de usuario

Me preguntaba si alguien había utilizado DPAPI con éxito en una tienda de usuarios en un entorno de granja web.

Debido a que nuestra aplicación es una aplicación ASP.NET 1.1 a 2.0 recientemente convertida, estamos utilizando un contenedor personalizado que llama directamente a los métodos CryptUnprotect . Pero esto debería ser igual que el método ProtectedData </​​code> disponible en el marco 2.0.

Debido a que estamos operando en un ambiente de granja de servidores web, no podemos garantizar que la máquina que hizo el cifrado sea la que lo descifre. (También porque las fallas de la máquina no deberían destruir nuestros datos encriptados).

Entonces, lo que tenemos es un componente de servicio que se ejecuta en un servicio bajo una cuenta de usuario particular en cada uno de nuestros cuadros web. Este usuario está configurado para tener un perfil itinerante, según la recomendación.

El problema que tenemos es que la información cifrada en una máquina no se puede descifrar en otra, esto falla con el error win32:

'La clave no es válida para usar en el estado especificado'.

Sospecho que esto se debe a que cometí un error al ejecutar el servicio de cifrado como usuario en varias máquinas, lo que hace que el usuario inicie sesión en más de una máquina al mismo tiempo.

Si este es el problema, ¿cómo otros usan DPAPI con la Tienda de usuarios en un entorno de granja de servidores web?

3
Hola, ¿obtuviste la respuesta a esto? Estoy teniendo el mismo problema.
agregado el autor user6535, fuente

3 Respuestas

En un entorno de granja de servidores web, en lugar de utilizar DPAPI para cifrar/descifrar sus datos directamente, en su lugar, lo usaría para cifrar la clave que luego utilizará para descifrar sus datos protegidos.

Debería "instalar" la clave en cada servidor como parte del proceso de implementación. El script de instalación necesitaría ejecutarse bajo la identidad de la AppPool, y podría almacenar la clave encriptada en un archivo app.config o en el registro.

Los datos encriptados podrían almacenarse en un repositorio/base de datos central, de modo que todos los servidores de la granja puedan acceder a ellos. Para descifrar los datos, la aplicación web recuperaría la clave cifrada desde donde se instaló, utilizará DPAPI para descifrarla y luego utilizará el resultado para descifrar los datos que provienen del depósito central.

La desventaja es que la clave de texto claro puede existir en el disco local durante un breve período de tiempo durante el proceso de instalación inicial, donde podría estar expuesto al personal de operaciones. Puede agregar una capa adicional de cifrado, como con la máquina.config clave, si eso es una preocupación.

8
agregado
Esto es desafortunado, ya que una de las ventajas de DPAPI es que caduca automáticamente la clave maestra cada 3 meses, aunque puede descifrar datos previamente encriptados. msdn.microsoft.com/en-us/library/ms995355.aspx Cita: "Esta expiración evita que un atacante comprometa una sola MasterKey y acceda a todos los datos protegidos de un usuario". Usando su propia clave si está comprometida, todos sus datos quedan expuestos.
agregado el autor ToddK, fuente
Esto es un poco obsoleto, pero creo que aún podrá "ver" la clave incluso si está contenida en el archivo web.config y está encriptada usando aspnet_regiis . Su enfoque es lo que la mayoría de la gente está buscando, ya que no existe un mecanismo similar listo para usar en ASP.NET o BCL.
agregado el autor CodeMonkeyKing, fuente

Acabo de ver esto. Hay una manera de hacer que esto funcione, y eso es asegurarse de que las máquinas de la granja estén en un dominio y usar una cuenta de dominio para cifrar y descifrar los datos (es decir, ejecutar la aplicación bajo la cuenta de dominio)

No puede usar DPAPI de la manera que desee con cuentas locales porque el material clave no se intercambia entre servidores.

¡Espero que ayude!

2
agregado

The Microsoft poster is wrong. http://support.microsoft.com/default.aspx?scid=kb;en-us;309408#6

"Para que DPAPI funcione correctamente cuando utiliza perfiles de itinerancia, el usuario de dominio solo debe iniciar sesión en una sola computadora en el dominio. Si el usuario desea iniciar sesión en una computadora diferente que está en el dominio, el usuario debe cerrar la sesión la primera computadora antes de que el usuario inicie sesión en la segunda computadora. Si el usuario está conectado a varias computadoras al mismo tiempo, es probable que DPAPI no pueda descifrar los datos encriptados existentes correctamente ".

Parece que DPAPI no funcionará en una configuración de granja. Creo que esto es un gran descuido por parte de Microsoft y hace que DPAPI sea casi inútil para la mayoría de las aplicaciones empresariales.

1
agregado