ASP.NET Core Protección de datos

Las aplicaciones web a menudo necesitan almacenar datos confidenciales para la seguridad. Windows proporciona una API de protección de datos (DPAPI) para aplicaciones de escritorio, pero Windows DPAPI no está pensada para su uso en aplicaciones web. La ASP.NET Core de protección de datos proporciona una API criptográfica sencilla y fácil de usar que un desarrollador puede usar para proteger los datos, incluida la administración y rotación de claves.

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

Declaración del problema

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

El ejemplo canónico de esto es un token de cookie autenticación o portador. El servidor genera un token "I am Groot and have xyz permissions" (Soy Groot y tengo permisos xyz) y lo entrega al cliente. En alguna fecha futura, el cliente volverá a 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 es decir, integridad, prueba de alteraciones).

Puesto que el servidor confía en el estado persistente, se prevé que este estado puede contener información específica del entorno operativo. Podría tratarse de una ruta de acceso de archivo, un permiso, un identificador u otra referencia indirecta o algún otro dato específico del servidor. Por lo general, esta información no debe revelarse a un cliente que no sea de confianza. Por lo tanto, el segundo requisito: confidencialidad.

Por último, dado que las aplicaciones modernas tienen 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 podría estar usando la misma pila. Por lo tanto, el requisito final: aislamiento.

Podemos proporcionar restricciones adicionales 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 no es necesario generar ni consumir los datos fuera de los servicios bajo nuestro control directo. Además, es necesario que las operaciones sean lo más rápidas posible, ya que cada solicitud al servicio web podría pasar por el sistema criptográfico una o varias veces. Esto hace que la criptografía simétrica sea ideal para nuestro escenario y se puede descartar la criptografía asimétrica hasta que sea necesario.

Filosofía de diseño

Comenzamos identificando problemas con la pila existente. Una vez que lo hicimos, hemos encuestado el panorama de las soluciones existentes y hemos concluido que ninguna solución existente tenía las funcionalidades 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 al terreno en ejecución. En situaciones en las que los desarrolladores necesitan configurar un aspecto específico (como el repositorio de claves), se debe tener en cuenta para que esas configuraciones específicas sean 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 aprender los principios clave de administración. El sistema debe controlar la selección de algoritmos y la duración de la clave en nombre del desarrollador. Lo ideal es que el desarrollador nunca tenga acceso al material de la clave sin procesar.

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

Con estos principios en mente, hemos desarrollado una pila de protección de datos sencilla y fácil de usar.

Las ASP.NET CORE de protección de datos no están diseñadas 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 sólidas correspondientes. Dicho esto, no hay nada que prohíba que un desarrollador use las API ASP.NET Core protección de datos 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 tienen como destino tres audiencias principales;

  1. La información general sobre las API de consumidor está dirigida a desarrolladores de aplicaciones y marcos.

    "No quiero obtener información sobre cómo funciona la pila ni 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 están destinadas a desarrolladores de aplicaciones y administradores del sistema.

    "Tengo que decir al sistema de protección de datos que mi entorno requiere rutas de acceso o configuración no predeterminadas".

  3. Las API de extensibilidad están dirigidas a desarrolladores que se encargan de implementar directivas personalizadas. El uso de estas API se limitaría a situaciones poco frecuentes y desarrolladores experimentados y con conocimientos de seguridad.

    "Tengo que reemplazar un componente completo dentro del sistema porque tengo requisitos de comportamiento realmente únicos. Estoy dispuesto a aprender partes de la superficie de API que se usan con frecuencia 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

Hospedaje de ASP.NET Core en una granja de servidores web