Administración y duración de las claves de protección de datos en ASP.NET Core
Por Rick Anderson
Administración de claves
La aplicación intenta detectar su entorno operativo y controlar la configuración de claves por sí misma.
Si la aplicación se hospeda en Azure Apps, las claves se conservan en la carpeta %HOME%\ASP.NET\DataProtection-Keys . Esta carpeta está respaldada por el almacenamiento de red y se sincroniza en todas las máquinas que hospedan la aplicación.
- Las claves no están protegidas en reposo.
- La carpeta DataProtection-Keys suministra el llavero a todas las instancias de una aplicación en una única ranura de implementación.
- Las ranuras de implementación independientes, por ejemplo, almacenamiento provisional y producción, no comparten ningún anillo de clave. Cuando se intercambia entre ranuras de implementación, por ejemplo, el intercambio de ensayo a producción o el uso de pruebas A/B, cualquier aplicación que use Protección de datos no podrá descifrar los datos almacenados mediante el anillo de claves dentro de la ranura anterior. Esto hace que los usuarios inicien sesión en una aplicación que use la autenticación estándar ASP.NET Corecookie, ya que usa la protección de datos para proteger sus cookie. Si desea anillos de claves independientes de ranura, use un proveedor de anillos de claves externo, como Azure Blob Storage, Azure Key Vault, un almacén SQL o redis cache.
Si el perfil de usuario está disponible, las claves se conservan en la carpeta %LOCALAPPDATA%\ASP.NET\DataProtection-Keys . Si el sistema operativo es Windows, las claves se cifran en reposo mediante DPAPI.
También se debe habilitar el atributo setProfileEnvironment del grupo de aplicaciones. El valor predeterminado de
setProfileEnvironment
estrue
. En algunos escenarios (por ejemplo, SO Windows),setProfileEnvironment
está establecido enfalse
. Si las claves no se almacenan en el directorio del perfil de usuario como se esperaba:- Vaya a la carpeta %windir%/system32/inetsrv/config.
- Abra el archivo applicationHost.config.
- Busque el elemento
<system.applicationHost><applicationPools><applicationPoolDefaults><processModel>
. - Confirme que el atributo
setProfileEnvironment
no está presente, que adopta de forma predeterminada el valortrue
, o establezca explícitamente el valor del atributo entrue
.
Si la aplicación está hospedada en IIS, las claves se conservan en el registro HKLM en una clave del Registro especial que solo se acló en la cuenta de proceso de trabajo. Las claves se cifran en reposo con DPAPI.
Si ninguna de estas condiciones coincide, las claves no se conservan fuera del proceso actual. Cuando se cierra el proceso, se pierden todas las claves generadas.
El desarrollador siempre está en control total y puede invalidar cómo y dónde se almacenan las claves. Las tres primeras opciones anteriores deberían proporcionar buenos valores predeterminados para la mayoría de las aplicaciones, de forma similar a como lo hacen las rutinas autogeneradas de ASP.NET <machineKey> en el pasado. La opción final de reserva es el único escenario que requiere que el desarrollador especifique la configuración por adelantado si quieren persistencia clave, pero esta reserva solo se produce en situaciones poco frecuentes.
Al hospedar en un contenedor de Docker, las claves deben conservarse en una carpeta que sea un volumen de Docker (un volumen compartido o un volumen montado en host que persista más allá de la duración del contenedor) o en un proveedor externo, como Azure Key Vault o Redis. Un proveedor externo también es útil en escenarios de granja de servidores web si las aplicaciones no pueden acceder a un volumen de red compartido (consulte PersistKeysToFileSystem para obtener más información).
Advertencia
Si el desarrollador invalida las reglas descritas anteriormente y señala el sistema de protección de datos en un repositorio de claves específico, se deshabilita el cifrado automático de claves en reposo. La protección en reposo se puede volver a habilitar a través de la configuración.
Vigencia de clave
Las claves tienen una duración de 90 días de forma predeterminada. Cuando una clave expira, la aplicación genera automáticamente una nueva clave y establece la nueva clave como la clave activa. Siempre que las claves retiradas permanezcan en el sistema, la aplicación puede descifrar los datos protegidos con ellos. Más información en Gestión de claves.
Algoritmos predeterminados
El algoritmo de protección de carga predeterminado usado es AES-256-CBC para la confidencialidad y HMACSHA256 para la autenticidad. Se usa una clave maestra de 512 bits, modificada cada 90 días, para derivar las dos sub-claves usadas para estos algoritmos por carga. Consulte Derivación de subclaves para obtener más información.
Recursos adicionales
Administración de claves
La aplicación intenta detectar su entorno operativo y controlar la configuración de claves por sí misma.
Si la aplicación se hospeda en Azure Apps, las claves se conservan en la carpeta %HOME%\ASP.NET\DataProtection-Keys . Esta carpeta está respaldada por el almacenamiento de red y se sincroniza en todas las máquinas que hospedan la aplicación.
- Las claves no están protegidas en reposo.
- La carpeta DataProtection-Keys suministra el llavero a todas las instancias de una aplicación en una única ranura de implementación.
- Las ranuras de implementación independientes, por ejemplo, almacenamiento provisional y producción, no comparten ningún anillo de clave. Cuando se intercambia entre ranuras de implementación, por ejemplo, el intercambio de ensayo a producción o el uso de pruebas A/B, cualquier aplicación que use Protección de datos no podrá descifrar los datos almacenados mediante el anillo de claves dentro de la ranura anterior. Esto hace que los usuarios inicien sesión en una aplicación que use la autenticación estándar ASP.NET Corecookie, ya que usa la protección de datos para proteger sus cookie. Si desea anillos de claves independientes de ranura, use un proveedor de anillos de claves externo, como Azure Blob Storage, Azure Key Vault, un almacén SQL o redis cache.
Si el perfil de usuario está disponible, las claves se conservan en la carpeta %LOCALAPPDATA%\ASP.NET\DataProtection-Keys . Si el sistema operativo es Windows, las claves se cifran en reposo mediante DPAPI.
También se debe habilitar el atributo setProfileEnvironment del grupo de aplicaciones. El valor predeterminado de
setProfileEnvironment
estrue
. En algunos escenarios (por ejemplo, SO Windows),setProfileEnvironment
está establecido enfalse
. Si las claves no se almacenan en el directorio del perfil de usuario como se esperaba:- Vaya a la carpeta %windir%/system32/inetsrv/config.
- Abra el archivo applicationHost.config.
- Busque el elemento
<system.applicationHost><applicationPools><applicationPoolDefaults><processModel>
. - Confirme que el atributo
setProfileEnvironment
no está presente, que adopta de forma predeterminada el valortrue
, o establezca explícitamente el valor del atributo entrue
.
Si la aplicación está hospedada en IIS, las claves se conservan en el registro HKLM en una clave del Registro especial que solo se acló en la cuenta de proceso de trabajo. Las claves se cifran en reposo con DPAPI.
Si ninguna de estas condiciones coincide, las claves no se conservan fuera del proceso actual. Cuando se cierra el proceso, se pierden todas las claves generadas.
El desarrollador siempre está en control total y puede invalidar cómo y dónde se almacenan las claves. Las tres primeras opciones anteriores deberían proporcionar buenos valores predeterminados para la mayoría de las aplicaciones, de forma similar a como lo hacen las rutinas autogeneradas de ASP.NET <machineKey> en el pasado. La opción final de reserva es el único escenario que requiere que el desarrollador especifique la configuración por adelantado si quieren persistencia clave, pero esta reserva solo se produce en situaciones poco frecuentes.
Al hospedar en un contenedor de Docker, las claves deben conservarse en una carpeta que sea un volumen de Docker (un volumen compartido o un volumen montado en host que persista más allá de la duración del contenedor) o en un proveedor externo, como Azure Key Vault o Redis. Un proveedor externo también es útil en escenarios de granja de servidores web si las aplicaciones no pueden acceder a un volumen de red compartido (consulte PersistKeysToFileSystem para obtener más información).
Advertencia
Si el desarrollador invalida las reglas descritas anteriormente y señala el sistema de protección de datos en un repositorio de claves específico, se deshabilita el cifrado automático de claves en reposo. La protección en reposo se puede volver a habilitar a través de la configuración.
Vigencia de clave
Las claves tienen una duración de 90 días de forma predeterminada. Cuando una clave expira, la aplicación genera automáticamente una nueva clave y establece la nueva clave como la clave activa. Siempre que las claves retiradas permanezcan en el sistema, la aplicación puede descifrar los datos protegidos con ellos. Más información en Gestión de claves.
Algoritmos predeterminados
El algoritmo de protección de carga predeterminado usado es AES-256-CBC para la confidencialidad y HMACSHA256 para la autenticidad. Se usa una clave maestra de 512 bits, modificada cada 90 días, para derivar las dos sub-claves usadas para estos algoritmos por carga. Consulte Derivación de subclaves para obtener más información.