Compartir vía

Administración y duración de las claves de protección de datos en ASP.NET Core

  • Artículo

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.

  1. Si la aplicación está alojada en Azure Apps, las claves se guardan 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 rest.
    • 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 usa la autenticación de cookie estándar de ASP.NET Core, ya que usa la protección de datos para proteger sus cookies. 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.

  2. 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 rest mediante DPAPI.

    También se debe habilitar el atributo setProfileEnvironment del grupo de aplicaciones. El valor predeterminado de setProfileEnvironment es true. En algunos escenarios (por ejemplo, SO Windows), setProfileEnvironment está establecido en false. Si las claves no se almacenan en el directorio del perfil de usuario como se esperaba:

    1. Vaya a la carpeta %windir%/system32/inetsrv/config.
    2. Abra el archivo applicationHost.config.
    3. Busque el elemento <system.applicationHost><applicationPools><applicationPoolDefaults><processModel> .
    4. Confirme que el atributo setProfileEnvironment no está presente, que adopta de forma predeterminada el valor true, o establezca explícitamente el valor del atributo en true.

  3. 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 rest con DPAPI.

  4. 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 rest. La protección en rest 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.

Eliminar claves.

Eliminar una clave hace que sus datos protegidos sean permanentemente inaccesibles. Para mitigar ese riesgo, se recomienda no eliminar claves. La acumulación resultante de claves generalmente tiene un impacto mínimo porque son pequeñas. En casos excepcionales, como servicios de ejecución extremadamente prolongada, se pueden eliminar las claves. Solo elimina claves:

  • Que sean antiguos (ya no están en uso).
  • Cuando puedas aceptar el riesgo de pérdida de datos a cambio de ahorrar en almacenamiento.

Recomendamos que las claves de protección de datos no se eliminen.

using Microsoft.AspNetCore.DataProtection.KeyManagement;

var services = new ServiceCollection();
services.AddDataProtection();

var serviceProvider = services.BuildServiceProvider();

var keyManager = serviceProvider.GetService<IKeyManager>();

if (keyManager is IDeletableKeyManager deletableKeyManager)
{
    var utcNow = DateTimeOffset.UtcNow;
    var yearAgo = utcNow.AddYears(-1);

    if (!deletableKeyManager.DeleteKeys(key => key.ExpirationDate < yearAgo))
    {
        Console.WriteLine("Failed to delete keys.");
    }
    else
    {
        Console.WriteLine("Old keys deleted successfully.");
    }
}
else
{
    Console.WriteLine("Key manager does not support deletion.");
}

Recursos adicionales

Administración de claves

La aplicación intenta detectar su entorno operativo y controlar la configuración de claves por sí misma.

  1. Si la aplicación está alojada en Azure Apps, las claves se guardan 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 rest.
    • 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 usa la autenticación de cookie estándar de ASP.NET Core, ya que usa la protección de datos para proteger sus cookies. 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.

  2. 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 rest mediante DPAPI.

    También se debe habilitar el atributo setProfileEnvironment del grupo de aplicaciones. El valor predeterminado de setProfileEnvironment es true. En algunos escenarios (por ejemplo, SO Windows), setProfileEnvironment está establecido en false. Si las claves no se almacenan en el directorio del perfil de usuario como se esperaba:

    1. Vaya a la carpeta %windir%/system32/inetsrv/config.
    2. Abra el archivo applicationHost.config.
    3. Busque el elemento <system.applicationHost><applicationPools><applicationPoolDefaults><processModel> .
    4. Confirme que el atributo setProfileEnvironment no está presente, que adopta de forma predeterminada el valor true, o establezca explícitamente el valor del atributo en true.

  3. 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 rest con DPAPI.

  4. 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 rest. La protección en rest 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