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

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. La API de protección de datos de Windows (DPAPI) no está pensada para su uso en aplicaciones web.

La pila de protección de datos de ASP.NET Core se diseñó para:

  • Proporcionar una solución integrada para la mayoría de los escenarios web.
  • Solucionar muchas de las deficiencias del sistema de cifrado anterior.
  • Actuar como reemplazo del elemento <machineKey> en ASP.NET 1.x - 4.x.

Declaración del problema

Necesito conservar información de confianza para recuperarla posteriormente, 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.

La autenticidad, la integridad y la protección contra alteraciones son un requisito. 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 envía al cliente. El cliente presenta ese token al servidor, pero el servidor necesita algún tipo de garantía de que el cliente no ha falsificado el token.

La confidencialidad es un requisito. Dado que el servidor confía en el estado persistente, este estado podría contener información que no se debe revelar a un cliente que no es de confianza. Por ejemplo:

  • Una ruta de acceso de archivo.
  • Un permiso.
  • Un manipulador u otra referencia indirecta.
  • Datos específicos del servidor.

El aislamiento es obligatorio. Dado que las aplicaciones modernas están componentes, los componentes individuales quieren aprovechar este sistema sin tener en cuenta otros componentes del sistema. Por ejemplo, considere un componente de token de portador que usa esta pila. Debe funcionar sin interferencias, por ejemplo, desde un mecanismo contra la CSRF que también usa la misma pila.

Algunas suposiciones comunes pueden restringir el ámbito de los requisitos:

  • Se confía en la misma medida en todos los servicios que funcionan en el sistema criptográfico.
  • Los datos no necesitan generarse ni consumirse fuera de los servicios bajo nuestro control directo.
  • Las operaciones deben ser rápidas, ya que cada solicitud al servicio web puede pasar por el sistema criptográfico una o varias veces. El requisito de velocidad hace que la criptografía simétrica sea ideal. La criptografía asimétrica no se usa si no se requiere.

Filosofía de diseño

La protección de datos de ASP.NET Core es una pila de protección de datos fácil de usar. Se basan en los siguientes principios:

  • Facilidad de configuración. El sistema busca una configuración mínima. En situaciones en las que los desarrolladores necesiten configurar un aspecto específico, como el repositorio de claves, esas configuraciones específicas son sencillas.
  • Ofrezca una API básica orientada al consumidor. Las API son fáciles de usar correctamente y difíciles de usar incorrectamente.
  • Los desarrolladores no tienen que aprender los principios clave de administración. El sistema controla la selección del algoritmo y la duración de la clave en nombre del desarrollador. El desarrollador no tiene acceso al material de clave sin procesar.
  • Las claves se protegen en reposo tanto como sea posible. El sistema determina un mecanismo de protección predeterminado adecuado y lo aplica automáticamente.

Las API de protección de datos 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. Tienen funcionalidades de administración de claves correspondientemente sólidas. Dicho esto, las API de protección de datos de ASP.NET Core se pueden usar para la protección a largo plazo de datos confidenciales.

Audiencia

El sistema de protección de datos proporciona API destinadas a tres audiencias principales:

  1. Las API de consumidor están dirigidas a 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 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 limita a situaciones poco frecuentes y a desarrolladores con experiencia en 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 satisfaga mis requisitos.

Diseño del paquete

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

Recursos adicionales

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. La API de protección de datos de Windows (DPAPI) no está pensada para su uso en aplicaciones web.

La pila de protección de datos de ASP.NET Core se diseñó para:

  • Proporcionar una solución integrada para la mayoría de los escenarios web.
  • Solucionar muchas de las deficiencias del sistema de cifrado anterior.
  • Actuar como reemplazo del elemento <machineKey> en ASP.NET 1.x - 4.x.

Declaración del problema

Necesito conservar información de confianza para recuperarla posteriormente, 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.

La autenticidad, la integridad y la protección contra alteraciones son un requisito. 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 envía al cliente. El cliente presenta ese token al servidor, pero el servidor necesita algún tipo de garantía de que el cliente no ha falsificado el token.

La confidencialidad es un requisito. Dado que el servidor confía en el estado persistente, este estado podría contener información que no se debe revelar a un cliente que no es de confianza. Por ejemplo:

  • Una ruta de acceso de archivo.
  • Un permiso.
  • Un manipulador u otra referencia indirecta.
  • Datos específicos del servidor.

El aislamiento es obligatorio. Dado que las aplicaciones modernas están componentes, los componentes individuales quieren aprovechar este sistema sin tener en cuenta otros componentes del sistema. Por ejemplo, considere un componente de token de portador que usa esta pila. Debe funcionar sin interferencias, por ejemplo, desde un mecanismo contra la CSRF que también usa la misma pila.

Algunas suposiciones comunes pueden restringir el ámbito de los requisitos:

  • Se confía en la misma medida en todos los servicios que funcionan en el sistema criptográfico.
  • Los datos no necesitan generarse ni consumirse fuera de los servicios bajo nuestro control directo.
  • Las operaciones deben ser rápidas, ya que cada solicitud al servicio web puede pasar por el sistema criptográfico una o varias veces. El requisito de velocidad hace que la criptografía simétrica sea ideal. La criptografía asimétrica no se usa si no se requiere.

Filosofía de diseño

La protección de datos de ASP.NET Core es una pila de protección de datos fácil de usar. Se basan en los siguientes principios:

  • Facilidad de configuración. El sistema busca una configuración mínima. En situaciones en las que los desarrolladores necesiten configurar un aspecto específico, como el repositorio de claves, esas configuraciones específicas son sencillas.
  • Ofrezca una API básica orientada al consumidor. Las API son fáciles de usar correctamente y difíciles de usar incorrectamente.
  • Los desarrolladores no tienen que aprender los principios clave de administración. El sistema controla la selección del algoritmo y la duración de la clave en nombre del desarrollador. El desarrollador no tiene acceso al material de clave sin procesar.
  • Las claves se protegen en reposo tanto como sea posible. El sistema determina un mecanismo de protección predeterminado adecuado y lo aplica automáticamente.

Las API de protección de datos 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. Tienen funcionalidades de administración de claves correspondientemente sólidas. Dicho esto, las API de protección de datos de ASP.NET Core se pueden usar para la protección a largo plazo de datos confidenciales.

Audiencia

El sistema de protección de datos proporciona API destinadas a tres audiencias principales:

  1. Las API de consumidor están dirigidas a 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 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 limita a situaciones poco frecuentes y a desarrolladores con experiencia en 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 satisfaga mis requisitos.

Diseño del paquete

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

Recursos adicionales