DPAPI en realidad funciona a través de 2 llamadas a funciones bastante simples: CryptProtectData y CryptUnprotectData .
Para resumir una larga historia, CryptProtectData tiene dos modos de operación: Usuario o sistema. Si utiliza el modo de usuario (predeterminado), los datos se cifran utilizando los datos de inicio de sesión del usuario actual. Esto significa que solo puede llamar con éxito a CryptUnprotectData en los mismos datos desde el mismo contexto de usuario desde el que llamó a CryptProtectData. (En el modo "sistema", cualquier proceso que se ejecute en esa misma máquina puede descifrar los datos pero no de otro sistema: no es demasiado bueno cuando los datos están en una base de datos).
Esto significa que, si inicialmente cifró sus datos en la base de datos del servidor SQL usando una cuenta de usuario AD específica, está permanentemente limitado a usar este usuario para acceder a ella. (Esto podría considerarse un defecto o una característica según la aplicación).
¿Qué significa para ti? Bueno, a menos que pueda cambiar la forma en que funciona la aplicación o que esté dispuesto a restablecer los datos cifrados por completo, no puede cambiar la identidad utilizada por el proceso de la aplicación web.
Sin embargo, la buena noticia es que esto no tiene por qué ser inseguro: si su aplicación web es una aplicación ASP.NET y utiliza cadenas de conexión almacenadas en el archivo web.config de manera estándar, puede protegerlas usando el DAPI también, pero esta vez con un delegado al sistema. Microsoft tiene una explicación bastante larga sobre cómo hacerlo .
Finalmente, siempre existe la forma habitual de resolver este tipo de problemas: póngase en contacto con los desarrolladores de aplicaciones: son los que le pueden decir exactamente qué es compatible y cómo. Si es necesario, ellos son los que también pueden realizar los cambios necesarios en su sistema para alcanzar los objetivos de seguridad que ha establecido.
Editar: Hay un elemento adicional que debe tener en cuenta en su caso: al usar DAPI, la clave maestra utilizada para el cifrado es almacenado en el perfil de usuario .
Esto significa que, cuando está utilizando una cuenta de usuario virtual (como las creadas para usted cuando ejecuta una aplicación web en AppPoolidentity ), DAPI en realidad no se conservará ni se volverá a cargar ya que no se ha creado un perfil real y experimentará el problema que describe: IISreset hace que la aplicación pierda su clave de cifrado principal porque no puede persistir.
Para resolver eso, puedes cambiar para cambiar a NetworkService identity para tu grupo de aplicaciones web. Perderá la segregación de usuario proporcionada por la cuenta virtual pero, más allá de eso, debería funcionar de la misma manera. Microsoft también sugiere que verifique la propiedad "LoadUserProfile" del grupo de aplicaciones web pero tengo dudas de que cambiarlo resolverá tu problema por sí solo: pruébalo, pero supongo que también tendrás que usar NetworkService .