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

Article
11/30/2023

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

Les applications web ont souvent besoin de stocker des données sensibles à la sécurité. Windows fournit une API de protection des données, DPAPI, mais Windows DPAPI n’est pas destiné à être utilisé dans les applications web.

La pile de protection des données ASP.NET Core est conçue pour remplacer à long terme l’élément <machineKey> dans ASP.NET 1.x - 4.x. Il a été conçu pour résoudre un grand nombre des défauts de l’ancienne pile de chiffrement tout en fournissant une solution prête à l’emploi pour la majorité des cas d’usage que les applications modernes sont susceptibles de rencontrer.

Définition du problème

L’instruction globale du problème peut être succinctement énoncée dans une seule phrase : je dois conserver les informations approuvées pour une récupération ultérieure, mais je n’approuve pas le mécanisme de persistance. En termes web, cela peut être écrit comme « Je dois aller-retour à l’état approuvé via un client non approuvé »

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 dispose d’autorisations xyz » et le remet au client. À une date ultérieure, le client présentera ce jeton au serveur, mais le serveur a besoin d’une certaine assurance que le client n’a pas falsifié le jeton. D’où la première exigence : l’authenticité (c’est-à-dire l’intégrité, l’inviolable).

Étant donné que l’état persistant est approuvé par le serveur, nous prévoyons que cet état peut contenir des informations spécifiques à l’environnement d’exploitation. Il peut s’agir d’un chemin d’accès de fichier, d’une autorisation, d’un handle ou d’une autre référence indirecte, ou d’une autre partie de données spécifiques au serveur. Ces informations ne doivent généralement pas être divulguées à un client non approuvé. D’où la deuxième exigence : la confidentialité.

Enfin, étant donné que les applications modernes sont en composants, ce que nous avons vu, c’est que des composants individuels souhaitent tirer parti de ce système sans tenir compte des autres composants du système. Par instance, si un composant de jeton de porteur utilise cette pile, il doit fonctionner sans interférence d’un mécanisme anti-CSRF qui peut également utiliser la même pile. Ainsi, la dernière exigence : l’isolation.

Nous pouvons fournir d’autres contraintes afin de limiter l’étendue de nos exigences. Nous partons du principe que tous les services opérant au sein du système de chiffrement sont également approuvés et que 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. En outre, nous exigeons que les opérations soient aussi rapides que possible, car chaque requête adressée au service web peut passer par le système de chiffrement une ou plusieurs fois. Cela rend le chiffrement symétrique idéal pour notre scénario, et nous pouvons écarter le chiffrement asymétrique jusqu’à ce qu’il soit nécessaire.

Philosophie de conception

Nous avons commencé par identifier les problèmes liés à la pile existante. Une fois que nous avons eu cela, nous avons étudié le paysage des solutions existantes et nous avons conclu qu’aucune solution existante n’avait les capacités que nous recherchions. Nous avons ensuite conçu une solution basée sur plusieurs principes directeurs.

Le système doit offrir une configuration simple. Dans l’idéal, le système serait sans configuration et les développeurs pourraient atteindre le terrain. Dans les situations où les développeurs doivent configurer un aspect spécifique (tel que le référentiel de clés), vous devez envisager de simplifier ces configurations spécifiques.
Proposez une API simple 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 doit gérer la sélection de l’algorithme et la durée de vie des clés pour le compte du développeur. Dans l’idéal, le développeur ne devrait même jamais avoir accès à la matière première.
Les clés doivent être protégées au repos lorsque cela est possible. Le système doit trouver un mécanisme de protection par défaut approprié et l’appliquer automatiquement.

Avec ces principes à l’esprit, nous avons développé une pile de protection des données simple et facile à utiliser.

Les API de protection des données ASP.NET Core 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 et disposent de fonctionnalités de gestion des clés fortes. Cela dit, rien n’empêche un développeur d’utiliser les API de protection des données ASP.NET Core pour la protection à long terme des données confidentielles.

Public visé

Le système de protection des données est divisé en cinq packages principaux. Différents aspects de ces API ciblent trois publics principaux ;

La vue d’ensemble des API grand public 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 une opération aussi simple que possible avec une probabilité élevée d’utiliser les API avec succès. »
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. »
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 serait limitée à de rares situations et à des développeurs expérimentés et sensibles à la 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.

Microsoft.AspNetCore.DataProtection.Abstractions contient les interfaces et IDataProtectionProvider pour créer des IDataProtector services de protection des données. Il contient également des méthodes d’extension utiles pour utiliser ces types (par exemple, IDataProtector.Protect). Si le système de protection des données est instancié ailleurs et que vous consommez l’API, référencez Microsoft.AspNetCore.DataProtection.Abstractions.
Microsoft.AspNetCore.DataProtection contient l’implémentation principale du système de protection des données, y compris les opérations de chiffrement principales, la gestion des clés, la configuration et l’extensibilité. Pour instancier le système de protection des données (par exemple, l’ajouter à un IServiceCollection) ou modifier ou étendre son comportement, référencez Microsoft.AspNetCore.DataProtection.
Microsoft.AspNetCore.DataProtection.Extensions contient des API supplémentaires que les développeurs peuvent trouver utiles, mais qui n’appartiennent pas au package principal. Par instance, ce package contient des méthodes de fabrique pour instancier le système de protection des données afin de stocker des clés à un emplacement sur le système de fichiers sans injection de dépendances (voir DataProtectionProvider). Il contient également des méthodes d’extension pour limiter la durée de vie des charges utiles protégées (voir ITimeLimitedDataProtector).
Microsoft.AspNetCore.DataProtection.SystemWeb peut être installé dans une application ASP.NET 4.x existante pour rediriger ses <machineKey> opérations vers l’utilisation de la nouvelle pile de protection des données ASP.NET Core. Pour plus d’informations, consultez Remplacer la ASP.NET machineKey dans ASP.NET Core.
Microsoft.AspNetCore.Cryptography.KeyDerivation fournit une implémentation de la routine de hachage de mot de passe PBKDF2 et peut être utilisé par les systèmes qui doivent gérer les mots de passe utilisateur en toute sécurité. Pour plus d’informations, consultez Mots de passe de hachage dans ASP.NET Core.