Partager via

Gestion et durée de vie des clés de protection des données dans ASP.NET Core

Par Rick Anderson

Gestion des clés

L’application tente de détecter son environnement opérationnel et de gérer seule la configuration des clés.

  1. Si l’application est hébergée dans Azure Apps, les clés sont conservées dans le dossier %HOME%\ASP.NET\DataProtection-Keys. Ce dossier est alimenté par le stockage réseau et synchronisé sur tous les ordinateurs hébergeant l’application.

    • Les clés ne sont pas protégées au repos.
    • Le dossier DataProtection-Keys fournit le trousseau de clés à toutes les instances d’une application dans un seul emplacement de déploiement.
    • Les emplacements de déploiement distincts, tels que Préproduction et Production, ne partagent pas de porte-clés. Lorsque vous échangez des emplacements de déploiement, par exemple en passant de Staging à Production ou en utilisant des tests A/B, toute application utilisant la protection des données ne pourra pas déchiffrer les données stockées à l’aide du trousseau de clés de l’emplacement précédent. Cela entraîne la déconnexion des utilisateurs d’une application qui utilise l’authentification ASP.NET Core cookie standard, car celle-ci utilise la protection des données pour protéger ses cookies. Si vous souhaitez disposer de trousseaux de clés indépendants de l’emplacement, utilisez un fournisseur de trousseaux de clés externe, tel qu’Azure Blob Storage, Azure Key Vault, un magasin SQL ou le cache Redis.

  2. Si le profil utilisateur est disponible, les clés sont conservées dans le dossier %LOCALAPPDATA%\ASP.NET\DataProtection-Keys. Si le système d’exploitation est Windows, les clés sont chiffrées au repos à l’aide de DPAPI.

    L’attribut setProfileEnvironment du pool d’applications doit également être activé. La valeur par défaut de setProfileEnvironment est true. Dans certains scénarios (par exemple pour le système d’exploitation Windows), setProfileEnvironment est défini sur false. Si les clés ne sont pas stockées dans le répertoire de profil utilisateur comme prévu :

    1. Accédez au dossier %windir%/system32/inetsrv/config.
    2. Ouvrez le fichier applicationHost.config.
    3. Recherchez l’élément <system.applicationHost><applicationPools><applicationPoolDefaults><processModel>.
    4. Confirmez que l’attribut setProfileEnvironment n’est pas présent, ce qui implique que la valeur par défaut est true, ou définissez de manière explicite la valeur de l’attribut sur true.

  3. Si l’application est hébergée dans IIS, les clés sont conservées dans le registre HKLM dans une clé de registre spéciale dont l’accès est limité par ACL au compte du processus Worker. Les clés sont chiffrées au repos à l’aide de DPAPI.

  4. Si aucune de ces conditions n’est remplie, les clés ne sont pas conservées en dehors du processus actuel. Lorsque le processus s’arrête, toutes les clés générées sont perdues.

Le développeur garde toujours le contrôle total et peut remplacer le mode et l’emplacement de stockage des clés. Les trois premières options ci-dessus devraient constituer de bonnes valeurs par défaut pour la plupart des applications, de manière similaire au fonctionnement des routines de génération automatique de clés <machineKey> ASP.NET dans le passé. La dernière option, qui sert de solution de secours, est le seul scénario qui nécessite que le développeur spécifie la configuration à l’avance s’il souhaite que les clés soient conservées, mais cette solution de secours n’est utilisée que dans de rares cas.

Lors de l’hébergement dans un conteneur Docker, les clés doivent être conservées dans un dossier qui est un volume Docker (un volume partagé ou un volume monté sur l’hôte qui persiste au-delà de la durée de vie du conteneur) ou dans un fournisseur externe, tel qu’Azure Key Vault ou Redis. Un fournisseur externe est également utile dans les scénarios de ferme Web si les applications ne peuvent pas accéder à un volume réseau partagé (voir PersistKeysToFileSystem pour plus d’informations).

Warning

Si le développeur remplace les règles décrites ci-dessus et pointe le système de protection des données dans un référentiel de clés spécifique, le chiffrement automatique des clés au repos est désactivé. La protection au repos peut être réactivée via configuration .

Durée de vie des clés

Les clés ont une durée de vie de 90 jours par défaut. Lorsqu’une clé expire, l’application génère automatiquement une nouvelle clé et la définit comme clé active. Tant que les clés mises hors service restent dans le système, votre application peut déchiffrer toutes les données protégées par celles-ci. Pour plus d’informations, consultez la section Gestion des clés.

Algorithmes par défaut

L’algorithme de protection de la charge utile utilisé par défaut est AES-256-CBC pour la confidentialité et HMACSHA256 pour l’authenticité. Une clé principale de 512 bits, changée tous les 90 jours, est utilisée pour dériver les deux sous-clés utilisées pour ces algorithmes sur une base par charge utile. Pour plus d’informations, consultez la section Dérivation des sous-clés.

Supprimer des clés

La suppression d’une clé rend les données protégées définitivement inaccessibles. Pour atténuer ce risque, nous vous recommandons de ne pas supprimer les clés. L’accumulation de clés qui en résulte a généralement un impact minimal, car elles sont petites. Dans des cas exceptionnels, tels que des services extrêmement longs, les clés peuvent être supprimées. Supprimez uniquement les clés :

  • Qui sont anciennes (qui ne sont plus utilisées).
  • Lorsque vous pouvez accepter le risque de perte de données en échange d’économies de stockage.

Nous vous recommandons de ne pas supprimer les clés de protection des données.

using Microsoft.AspNetCore.DataProtection.KeyManagement;

var services = new ServiceCollection();
services.AddDataProtection();

var serviceProvider = services.BuildServiceProvider();

var keyManager = serviceProvider.GetService<IKeyManager>();

if (keyManager is IDeletableKeyManager deletableKeyManager)
{
    var utcNow = DateTimeOffset.UtcNow;
    var yearAgo = utcNow.AddYears(-1);

    if (!deletableKeyManager.DeleteKeys(key => key.ExpirationDate < yearAgo))
    {
        Console.WriteLine("Failed to delete keys.");
    }
    else
    {
        Console.WriteLine("Old keys deleted successfully.");
    }
}
else
{
    Console.WriteLine("Key manager does not support deletion.");
}

Ressources supplémentaires

Gestion des clés

L’application tente de détecter son environnement opérationnel et de gérer seule la configuration des clés.

  1. Si l’application est hébergée dans Azure Apps, les clés sont conservées dans le dossier %HOME%\ASP.NET\DataProtection-Keys. Ce dossier est alimenté par le stockage réseau et synchronisé sur tous les ordinateurs hébergeant l’application.

    • Les clés ne sont pas protégées au repos.
    • Le dossier DataProtection-Keys fournit le trousseau de clés à toutes les instances d’une application dans un seul emplacement de déploiement.
    • Les emplacements de déploiement distincts, tels que Préproduction et Production, ne partagent pas de porte-clés. Lorsque vous échangez des emplacements de déploiement, par exemple en passant de Staging à Production ou en utilisant des tests A/B, toute application utilisant la protection des données ne pourra pas déchiffrer les données stockées à l’aide du trousseau de clés de l’emplacement précédent. Cela entraîne la déconnexion des utilisateurs d’une application qui utilise l’authentification ASP.NET Core cookie standard, car celle-ci utilise la protection des données pour protéger ses cookies. Si vous souhaitez disposer de trousseaux de clés indépendants de l’emplacement, utilisez un fournisseur de trousseaux de clés externe, tel qu’Azure Blob Storage, Azure Key Vault, un magasin SQL ou le cache Redis.

  2. Si le profil utilisateur est disponible, les clés sont conservées dans le dossier %LOCALAPPDATA%\ASP.NET\DataProtection-Keys. Si le système d’exploitation est Windows, les clés sont chiffrées au repos à l’aide de DPAPI.

    L’attribut setProfileEnvironment du pool d’applications doit également être activé. La valeur par défaut de setProfileEnvironment est true. Dans certains scénarios (par exemple pour le système d’exploitation Windows), setProfileEnvironment est défini sur false. Si les clés ne sont pas stockées dans le répertoire de profil utilisateur comme prévu :

    1. Accédez au dossier %windir%/system32/inetsrv/config.
    2. Ouvrez le fichier applicationHost.config.
    3. Recherchez l’élément <system.applicationHost><applicationPools><applicationPoolDefaults><processModel>.
    4. Confirmez que l’attribut setProfileEnvironment n’est pas présent, ce qui implique que la valeur par défaut est true, ou définissez de manière explicite la valeur de l’attribut sur true.

  3. Si l’application est hébergée dans IIS, les clés sont conservées dans le registre HKLM dans une clé de registre spéciale dont l’accès est limité par ACL au compte du processus Worker. Les clés sont chiffrées au repos à l’aide de DPAPI.

  4. Si aucune de ces conditions n’est remplie, les clés ne sont pas conservées en dehors du processus actuel. Lorsque le processus s’arrête, toutes les clés générées sont perdues.

Le développeur garde toujours le contrôle total et peut remplacer le mode et l’emplacement de stockage des clés. Les trois premières options ci-dessus devraient constituer de bonnes valeurs par défaut pour la plupart des applications, de manière similaire au fonctionnement des routines de génération automatique de clés <machineKey> ASP.NET dans le passé. La dernière option, qui sert de solution de secours, est le seul scénario qui nécessite que le développeur spécifie la configuration à l’avance s’il souhaite que les clés soient conservées, mais cette solution de secours n’est utilisée que dans de rares cas.

Lors de l’hébergement dans un conteneur Docker, les clés doivent être conservées dans un dossier qui est un volume Docker (un volume partagé ou un volume monté sur l’hôte qui persiste au-delà de la durée de vie du conteneur) ou dans un fournisseur externe, tel qu’Azure Key Vault ou Redis. Un fournisseur externe est également utile dans les scénarios de ferme Web si les applications ne peuvent pas accéder à un volume réseau partagé (voir PersistKeysToFileSystem pour plus d’informations).

Warning

Si le développeur remplace les règles décrites ci-dessus et pointe le système de protection des données dans un référentiel de clés spécifique, le chiffrement automatique des clés au repos est désactivé. La protection au repos peut être réactivée via configuration .

Durée de vie des clés

Les clés ont une durée de vie de 90 jours par défaut. Lorsqu’une clé expire, l’application génère automatiquement une nouvelle clé et la définit comme clé active. Tant que les clés mises hors service restent dans le système, votre application peut déchiffrer toutes les données protégées par celles-ci. Pour plus d’informations, consultez la section Gestion des clés.

Algorithmes par défaut

L’algorithme de protection de la charge utile utilisé par défaut est AES-256-CBC pour la confidentialité et HMACSHA256 pour l’authenticité. Une clé principale de 512 bits, changée tous les 90 jours, est utilisée pour dériver les deux sous-clés utilisées pour ces algorithmes sur une base par charge utile. Pour plus d’informations, consultez la section Dérivation des sous-clés.

Ressources supplémentaires

  • Last updated on