Introducción a la protección de datos de ASP.NET Core

La protección de datos ASP.NET Core proporciona una API criptográfica para proteger los datos, incluida la administración y la rotación de claves.

A menudo, las aplicaciones web necesitan almacenar datos confidenciales de seguridad. Windows proporciona una API de protección de datos, DPAPI, pero Windows DPAPI no está pensado para su uso en aplicaciones web.

La pila de protección de datos de ASP.NET Core está diseñada para servir como reemplazo a largo plazo del elemento <machineKey> en ASP.NET 1.x - 4.x. Se diseñó para abordar muchas de las deficiencias de la antigua pila criptográfica, al tiempo que proporciona una solución lista para usar para la mayoría de los casos de uso que es probable que se encuentren las aplicaciones modernas.

Declaración del problema

La declaración general del problema puede indicarse concisamente en una sola frase: necesito conservar información de confianza para la recuperación posterior, pero no confío en el mecanismo de persistencia. En términos web, esto podría escribirse como "Necesito el estado de confianza de ida y vuelta a través de un cliente que no es de confianza".

El ejemplo canónico de este es un token de autenticación cookie o portador. El servidor genera un token "Soy Groot y tengo permisos xyz" y lo entrega al cliente. En una fecha futura, el cliente presentará ese token al servidor, pero el servidor necesita algún tipo de garantía de que el cliente no ha falsificado el token. Por lo tanto, el primer requisito: autenticidad (también se conoce como integridad, corrección de alteraciones).

Dado que el servidor confía en el estado persistente, se prevé que este estado puede contener información específica del entorno operativo. Esto podría estar en forma de una ruta de acceso de archivo, un permiso, un identificador u otra referencia indirecta, o algún otro fragmento de datos específicos del servidor. Por lo general, dicha información no debe revelarse a un cliente que no es de confianza. Por lo tanto, el segundo requisito: confidencialidad.

Por último, dado que las aplicaciones modernas están componentes, lo que hemos visto es que los componentes individuales querrán aprovechar este sistema sin tener en cuenta otros componentes del sistema. Por ejemplo, si un componente de token de portador usa esta pila, debe funcionar sin interferencias de un mecanismo anti-CSRF que también pueda usar la misma pila. Por lo tanto, el requisito final: aislamiento.

Podemos proporcionar más restricciones para restringir el ámbito de nuestros requisitos. Se supone que todos los servicios que funcionan dentro del sistema criptográfico son igualmente de confianza y que los datos no necesitan generarse o consumirse fuera de los servicios bajo nuestro control directo. Además, necesitamos que las operaciones sean lo más rápidas posible, ya que cada solicitud al servicio web puede pasar por el sistema criptográfico una o varias veces. Esto hace que la criptografía simétrica sea ideal para nuestro escenario y podemos descontar la criptografía asimétrica hasta que sea necesario.

Filosofía de diseño

Comenzamos mediante la identificación de problemas con la pila existente. Una vez que lo tuvimos, hemos buscado el panorama de las soluciones existentes y concluimos que ninguna solución existente tenía las capacidades que buscamos. A continuación, diseñamos una solución basada en varios principios rectores.

  • El sistema debe ofrecer simplicidad de configuración. Idealmente, el sistema sería de configuración cero y los desarrolladores podrían llegar a la marcha. En situaciones en las que los desarrolladores necesiten configurar un aspecto específico (como el repositorio de claves), se debe tener en cuenta que esas configuraciones específicas son sencillas.

  • Ofrezca una API sencilla orientada al consumidor. Las API deben ser fáciles de usar correctamente y difíciles de usar incorrectamente.

  • Los desarrolladores no deben tener que aprender los principios clave de administración. El sistema debe controlar la selección del algoritmo y la duración de la clave en nombre del desarrollador. Lo ideal es que el desarrollador nunca tenga acceso al material de clave sin procesar.

  • Las claves deben protegerse en reposo siempre que sea posible. El sistema debe averiguar un mecanismo de protección predeterminado adecuado y aplicarlo automáticamente.

Teniendo en cuenta estos principios hemos desarrollado una pila de protección de datos sencilla y fácil de usar .

Las API de protección de datos de ASP.NET Core no están pensadas principalmente para la persistencia indefinida de cargas confidenciales. Otras tecnologías como Windows CNG DPAPI y Azure Rights Management son más adecuadas para el escenario de almacenamiento indefinido y tienen funcionalidades de administración de claves correspondientemente sólidas. Dicho esto, no hay nada que impida que un desarrollador use las API de protección de datos de ASP.NET Core para la protección a largo plazo de datos confidenciales.

Público

El sistema de protección de datos se divide en cinco paquetes principales. Varios aspectos de estas API se dirigen a tres audiencias principales;

  1. La introducción a las API de consumidor tiene como destino los desarrolladores de aplicaciones y marcos de trabajo.

    "No quiero obtener información sobre cómo funciona la pila o sobre cómo está configurada. Simplemente quiero realizar alguna operación de la manera más sencilla posible con una alta probabilidad de usar las API correctamente".

  2. Las API de configuración se dirigen a desarrolladores de aplicaciones y administradores del sistema.

    "Necesito indicar al sistema de protección de datos que mi entorno requiere rutas o configuraciones no predeterminadas".

  3. Las API de extensibilidad se dirigen a los desarrolladores a cargo de implementar la directiva personalizada. El uso de estas API se limitaría a situaciones poco frecuentes y a desarrolladores con reconocimiento de seguridad.

    "Necesito reemplazar un componente completo dentro del sistema porque tengo requisitos de comportamiento realmente únicos. Estoy dispuesto a aprender partes poco usadas de la superficie de API para crear un complemento que cumpla mis requisitos".

Diseño del paquete

La pila de protección de datos consta de cinco paquetes.

Recursos adicionales