Share via


Vue d’ensemble de la protection des données ASP.NET Core

ASP.NET Core fournit une API de chiffrement pour protéger les données, y compris la gestion et la rotation des clés.

Souvent, les applications web doivent stocker des données sensibles. L’API de protection des données Windows (DPAPI) n’est pas destinée à être utilisée dans les applications web.

La pile de protection des données ASP.NET Core a été conçue pour :

  • Fournir une solution intégrée pour la plupart des scénarios Web.
  • Résoudre de nombreuses faiblesses du système de chiffrement précédent.
  • Remplacer l’élément <machineKey> dans ASP.NET 1.x - 4.x.

Énoncé du problème

J’ai besoin de conserver les informations approuvées pour la récupération ultérieure, mais je ne fais pas confiance au mécanisme de persistance. En termes web, cela peut être écrit ainsi : Je dois faire aller-retour à l’état approuvé via un client non approuvé.

L’authenticité, l’intégrité et l’inviolabilité sont requises. L’exemple canonique de ceci est un jeton d’authentification cookie ou de porteur. Le serveur génère un jeton Je suis Groot et je dispose d’autorisations xyz et le transmet au client. Le client représente ce jeton au serveur, mais le serveur a besoin d’une certaine assurance que le client n’a pas falsifié le jeton.

La confidentialité est une exigence. Étant donné que l’état persistant est approuvé par le serveur, cet état peut contenir des informations qui ne doivent pas être divulguées à un client non approuvé. Par exemple :

  • Chemin d'accès de fichier.
  • Une autorisation.
  • Un descripteur ou autre référence indirecte.
  • Des données spécifiques au serveur.

L’isolation est une condition requise. Étant donné que les applications modernes sont formées de composants, les composants individuels souhaitent tirer parti de ce système sans tenir compte des autres composants du système. Prenons l’exemple d’un composant de jeton du porteur utilisant cette pile. Il doit fonctionner sans interférence, par exemple à partir d’un mécanisme anti-CSRF utilisant également la même pile.

Certaines hypothèses courantes peuvent limiter l’étendue des exigences :

  • Tous les services qui fonctionnent dans le système de chiffrement sont également approuvés.
  • Les données n’ont pas besoin d’être générées ou consommées en dehors des services sous notre contrôle direct.
  • Les opérations doivent être rapides, car chaque requête adressée au service web peut passer par le système de chiffrement une ou plusieurs fois. La vitesse requise rend le chiffrement symétrique idéal. Le chiffrement asymétrique n’est pas utilisé tant qu’il n’est pas nécessaire.

Philosophie de conception

La protection des données ASP.NET Core est une pile de protection des données facile à utiliser. Elle est basée sur les principes suivants :

  • Facilité de configuration. Le système s’efforce d’atteindre aucune configuration. Dans les situations où les développeurs doivent configurer un aspect spécifique, tel que le référentiel de clés, ces configurations spécifiques ne sont pas difficiles.
  • Proposez une API de base destinée aux consommateurs. Les API doivent être faciles à utiliser correctement et difficiles à utiliser incorrectement.
  • Les développeurs ne doivent pas avoir à apprendre les principes clés de gestion. Le système gère la sélection de l’algorithme et la durée de vie des clés pour le compte du développeur. Le développeur n’a pas accès au matériau de clé brute.
  • Les clés sont protégées au repos autant que possible. Le système trouve un mécanisme de protection par défaut approprié et l’applique automatiquement.

Les API de protection des données ne sont pas principalement destinées à la persistance indéfinie des charges utiles confidentielles. D’autres technologies, telles que Windows CNG DPAPI et Azure Rights Management, sont plus adaptées au scénario de stockage indéfini. Elles disposent de fonctionnalités de gestion des clés fortes. Cela dit, les API de protection des données ASP.NET Core peuvent être utilisées pour la protection à long terme de données confidentielles.

Audience

Le système de protection des données fournit des API qui ciblent trois audiences principales :

  1. Les API de consommateur cible les développeurs d’applications et d’infrastructure.

    Je ne veux pas en savoir plus sur le fonctionnement de la pile ni sur la façon dont elle est configurée. Je souhaite simplement effectuer des opérations avec une probabilité élevée d’utiliser les API avec succès.

  2. Les API de configuration ciblent les développeurs d’applications et les administrateurs système.

    Je dois indiquer au système de protection des données que mon environnement nécessite des chemins ou des paramètres autres que les paramètres par défaut.

  3. Les API d’extensibilité ciblent les développeurs chargés de l’implémentation de la stratégie personnalisée. L’utilisation de ces API est limitée à des situations rares et aux développeurs ayant une expérience de sécurité.

    Je dois remplacer un composant entier dans le système, car j’ai des exigences comportementales vraiment uniques. Je suis prêt à apprendre des parties rarement utilisées de la surface de l’API afin de créer un plug-in qui répond à mes besoins.

Disposition de package

La pile de protection des données se compose de cinq packages :

Ressources supplémentaires

ASP.NET Core fournit une API de chiffrement pour protéger les données, y compris la gestion et la rotation des clés.

Souvent, les applications web doivent stocker des données sensibles. L’API de protection des données Windows (DPAPI) n’est pas destinée à être utilisée dans les applications web.

La pile de protection des données ASP.NET Core a été conçue pour :

  • Fournir une solution intégrée pour la plupart des scénarios Web.
  • Résoudre de nombreuses faiblesses du système de chiffrement précédent.
  • Remplacer l’élément <machineKey> dans ASP.NET 1.x - 4.x.

Énoncé du problème

J’ai besoin de conserver les informations approuvées pour la récupération ultérieure, mais je ne fais pas confiance au mécanisme de persistance. En termes web, cela peut être écrit ainsi : Je dois faire aller-retour à l’état approuvé via un client non approuvé.

L’authenticité, l’intégrité et l’inviolabilité sont requises. L’exemple canonique de ceci est un jeton d’authentification cookie ou de porteur. Le serveur génère un jeton Je suis Groot et je dispose d’autorisations xyz et le transmet au client. Le client représente ce jeton au serveur, mais le serveur a besoin d’une certaine assurance que le client n’a pas falsifié le jeton.

La confidentialité est une exigence. Étant donné que l’état persistant est approuvé par le serveur, cet état peut contenir des informations qui ne doivent pas être divulguées à un client non approuvé. Par exemple :

  • Chemin d'accès de fichier.
  • Une autorisation.
  • Un descripteur ou autre référence indirecte.
  • Des données spécifiques au serveur.

L’isolation est une condition requise. Étant donné que les applications modernes sont formées de composants, les composants individuels souhaitent tirer parti de ce système sans tenir compte des autres composants du système. Prenons l’exemple d’un composant de jeton du porteur utilisant cette pile. Il doit fonctionner sans interférence, par exemple à partir d’un mécanisme anti-CSRF utilisant également la même pile.

Certaines hypothèses courantes peuvent limiter l’étendue des exigences :

  • Tous les services qui fonctionnent dans le système de chiffrement sont également approuvés.
  • Les données n’ont pas besoin d’être générées ou consommées en dehors des services sous notre contrôle direct.
  • Les opérations doivent être rapides, car chaque requête adressée au service web peut passer par le système de chiffrement une ou plusieurs fois. La vitesse requise rend le chiffrement symétrique idéal. Le chiffrement asymétrique n’est pas utilisé tant qu’il n’est pas nécessaire.

Philosophie de conception

La protection des données ASP.NET Core est une pile de protection des données facile à utiliser. Elle est basée sur les principes suivants :

  • Facilité de configuration. Le système s’efforce d’atteindre aucune configuration. Dans les situations où les développeurs doivent configurer un aspect spécifique, tel que le référentiel de clés, ces configurations spécifiques ne sont pas difficiles.
  • Proposez une API de base destinée aux consommateurs. Les API doivent être faciles à utiliser correctement et difficiles à utiliser incorrectement.
  • Les développeurs ne doivent pas avoir à apprendre les principes clés de gestion. Le système gère la sélection de l’algorithme et la durée de vie des clés pour le compte du développeur. Le développeur n’a pas accès au matériau de clé brute.
  • Les clés sont protégées au repos autant que possible. Le système trouve un mécanisme de protection par défaut approprié et l’applique automatiquement.

Les API de protection des données ne sont pas principalement destinées à la persistance indéfinie des charges utiles confidentielles. D’autres technologies, telles que Windows CNG DPAPI et Azure Rights Management, sont plus adaptées au scénario de stockage indéfini. Elles disposent de fonctionnalités de gestion des clés fortes. Cela dit, les API de protection des données ASP.NET Core peuvent être utilisées pour la protection à long terme de données confidentielles.

Audience

Le système de protection des données fournit des API qui ciblent trois audiences principales :

  1. Les API de consommateur cible les développeurs d’applications et d’infrastructure.

    Je ne veux pas en savoir plus sur le fonctionnement de la pile ni sur la façon dont elle est configurée. Je souhaite simplement effectuer des opérations avec une probabilité élevée d’utiliser les API avec succès.

  2. Les API de configuration ciblent les développeurs d’applications et les administrateurs système.

    Je dois indiquer au système de protection des données que mon environnement nécessite des chemins ou des paramètres autres que les paramètres par défaut.

  3. Les API d’extensibilité ciblent les développeurs chargés de l’implémentation de la stratégie personnalisée. L’utilisation de ces API est limitée à des situations rares et aux développeurs ayant une expérience de sécurité.

    Je dois remplacer un composant entier dans le système, car j’ai des exigences comportementales vraiment uniques. Je suis prêt à apprendre des parties rarement utilisées de la surface de l’API afin de créer un plug-in qui répond à mes besoins.

Disposition de package

La pile de protection des données se compose de cinq packages :

Ressources supplémentaires