Remarque
L’accès à cette page requiert une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page requiert une autorisation. Vous pouvez essayer de modifier des répertoires.
Le système de protection des données utilise un mécanisme de découverte par défaut pour déterminer comment les clés de chiffrement doivent être chiffrées au repos. Le développeur peut remplacer le mécanisme de découverte et spécifier manuellement la façon dont les clés doivent être chiffrées au repos.
Warning
Si vous spécifiez un emplacement de persistance de clé explicite, le système de protection des données annule le chiffrement de clé par défaut au repos. Par conséquent, les clés ne sont plus chiffrées au repos. Nous vous recommandons de spécifier un mécanisme de chiffrement de clé explicite pour les déploiements en production. Les options de mécanisme de chiffrement au repos sont décrites dans cette rubrique.
Azure Key Vault
Pour plus d’informations, consultez Configurer la protection des données ASP.NET Core.
Windows DPAPI
S’applique uniquement aux déploiements Windows.
Lorsque Windows DPAPI est utilisé, le matériel de clé est chiffré avec CryptProtectData avant d’être conservé dans le stockage. DPAPI est un mécanisme de chiffrement approprié pour les données qui ne sont jamais lues en dehors de la machine actuelle (bien qu’il soit possible de sauvegarder ces clés dans Active Directory). Pour configurer le chiffrement de clé DPAPI au repos, appelez l’une des méthodes d’extension ProtectKeysWithDpapi) :
// Only the local user account can decrypt the keys
services.AddDataProtection()
.ProtectKeysWithDpapi();
Si ProtectKeysWithDpapi est appelé sans paramètre, seul le compte d’utilisateur Windows actuel peut déchiffrer le trousseau de clés persistant. Vous pouvez éventuellement spécifier que tout compte d’utilisateur sur la machine (et pas seulement le compte d’utilisateur actuel) peut déchiffrer le trousseau de clés :
// All user accounts on the machine can decrypt the keys
services.AddDataProtection()
.ProtectKeysWithDpapi(protectToLocalMachine: true);
Certificat X.509
Si l’application est répartie sur plusieurs ordinateurs, il peut être pratique de distribuer un certificat X.509 partagé (.pfx format) sur les ordinateurs et de configurer les applications hébergées pour utiliser le certificat pour le chiffrement des clés au repos.
Dans l’exemple suivant, l’empreinte numérique du certificat est passée à ProtectKeysWithCertificate:
services.AddDataProtection()
.ProtectKeysWithCertificate("{CERTIFICATE THUMBPRINT}");
Dans l’exemple suivant, un X509Certificate2 est passé à ProtectKeysWithCertificate:
var cert = new X509Certificate2(...);
services.AddDataProtection()
.ProtectKeysWithCertificate(cert);
Pour créer le certificat, utilisez l’une des approches suivantes ou tout autre outil ou service en ligne approprié :
-
dotnet dev-certscommande -
New-SelfSignedCertificateCommande PowerShell - Azure Key Vault
- MakeCert sous Windows
- OpenSSL
Pour plus d’informations, consultez Générer des certificats auto-signés avec l’interface CLI .NET.
En raison des limitations du framework .NET, seuls les certificats avec clés privées CAPI sont pris en charge. Veuillez consulter le contenu ci-dessous pour connaître les solutions de contournement possibles à ces limitations.
Windows DPAPI-NG
Ce mécanisme est disponible uniquement sur Windows 8/Windows Server 2012 ou version ultérieure.
À partir de Windows 8, le système d’exploitation Windows prend en charge DPAPI-NG (également appelé CNG DPAPI). Pour plus d’informations, consultez À propos de CNG DPAPI.
Le principal est codé en tant que règle de descripteur de protection. Dans l’exemple suivant qui appelle ProtectKeysWithDpapiNG, seul l’utilisateur joint au domaine avec le SID spécifié peut déchiffrer le trousseau de clés :
public void ConfigureServices(IServiceCollection services)
{
// Uses the descriptor rule "SID=S-1-5-21-..."
services.AddDataProtection()
.ProtectKeysWithDpapiNG("SID=S-1-5-21-...",
flags: DpapiNGProtectionDescriptorFlags.None);
}
Il existe également une surcharge sans paramètre de ProtectKeysWithDpapiNG. Utilisez cette méthode pratique pour spécifier la règle « SID={CURRENT_ACCOUNT_SID} », où CURRENT_ACCOUNT_SID est le SID du compte utilisateur Windows actuel :
public void ConfigureServices(IServiceCollection services)
{
// Use the descriptor rule "SID={current account SID}"
services.AddDataProtection()
.ProtectKeysWithDpapiNG();
}
Dans ce scénario, le contrôleur de domaine AD est chargé de distribuer les clés de chiffrement utilisées par les opérations DPAPI-NG. L’utilisateur cible peut déchiffrer la charge utile chiffrée à partir de n’importe quel ordinateur joint à un domaine (à condition que le processus s’exécute sous son identité).
Chiffrement basé sur un certificat avec Windows DPAPI-NG
Si l’application s’exécute sous Windows 8.1/Windows Server 2012 R2 ou version ultérieure, vous pouvez utiliser Windows DPAPI-NG pour effectuer un chiffrement basé sur un certificat. Utilisez la chaîne de descripteur de règle « CERTIFICATE=HashId :{CERTIFICATE THUMBPRINT} », où l’espace {CERTIFICATE THUMBPRINT} réservé est l’empreinte SHA1 encodée en hexadécimal du certificat :
public void ConfigureServices(IServiceCollection services)
{
services.AddDataProtection()
.ProtectKeysWithDpapiNG("CERTIFICATE=HashId:{CERTIFICATE THUMBPRINT}",
flags: DpapiNGProtectionDescriptorFlags.None);
}
Toute application pointant vers ce référentiel doit s’exécuter sous Windows 8.1/Windows Server 2012 R2 ou version ultérieure pour déchiffrer les clés.
Chiffrement de clé personnalisé
Si les mécanismes intégrés ne sont pas adaptés, le développeur peut spécifier son propre mécanisme de chiffrement de clé en fournissant un fichier IXmlEncryptor personnalisé.