Partager via

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

  • Article

Par Rick Anderson

Gestion des clés

L’application tente de détecter son environnement opérationnel et de gérer indépendamment la configuration de la clé.

  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 rest.
    • Le dossier DataProtection-Keys fournit le porte-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 entre des emplacements de déploiement, par exemple en échangeant Intermédiaire avec Production ou en utilisant des tests A/B, toute application utilisant la protection des données seront en incapacité de déchiffrer les données stockées à l’aide du porte-clés à l’intérieur de l’emplacement précédent. Cela entraîne la déconnexion des utilisateurs d’une application qui utilise l’authentification standard des cookie ASP.NET Core, car elle utilise la protection des données pour protéger ses cookies. Si vous souhaitez avoir des porte-clés indépendants de l’emplacement, utilisez un fournisseur de porte-clés externe, tel que Stockage Blob Azure, Azure Key Vault, un magasin SQL ou un 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 rest à 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 qui est dans une liste de contrôle d'accès uniquement pour le compte de processus de travail. Les clés sont chiffrées au rest à l’aide de DPAPI.

  4. Si aucune de ces conditions ne correspond, 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 est toujours en contrôle total et peut remplacer comment et où les clés sont stockées. Les trois premières options ci-dessus doivent fournir de bonnes valeurs par défaut pour la plupart des applications similaires à la façon dont les routines de génération automatique ASP.NET< machineKey> fonctionnaient dans le passé. L’option de secours finale est le seul scénario qui oblige le développeur à spécifier la configuration à l’avance s’il souhaite la persistance des clés, mais cette solution de secours ne se produit que dans de rares situations.

Lors de l’hébergement dans un conteneur Docker, les clés doivent être conservées dans un dossier avec 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 que Azure Key Vault ou Redis. Un fournisseur externe est également utile dans les scénarios de batterie de serveurs web si les applications n’ont pas accès à un volume de réseau partagé (pour plus d’informations, consultez PersistKeysToFileSystem).

Avertissement

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

Durée de vie de la clé

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 définit la nouvelle clé 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 Gestion des clés.

Algorithmes par défaut

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

Supprimer des clés

La suppression d’une clé rend ses données protégées définitivement inaccessibles. Pour atténuer ce risque, nous vous recommandons de ne pas supprimer les clés. Compte tenu de leur petite taille, l’accumulation de clés a généralement un impact minimal. Dans des cas exceptionnels, tels que des services extrêmement longs, les clés peuvent être supprimées. Supprimez uniquement des clés :

  • qui sont anciennes (ne sont plus utilisées).
  • lorsque vous pouvez accepter le risque de perdre des 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 indépendamment la configuration de la clé.

  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 rest.
    • Le dossier DataProtection-Keys fournit le porte-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 entre des emplacements de déploiement, par exemple en échangeant Intermédiaire avec Production ou en utilisant des tests A/B, toute application utilisant la protection des données seront en incapacité de déchiffrer les données stockées à l’aide du porte-clés à l’intérieur de l’emplacement précédent. Cela entraîne la déconnexion des utilisateurs d’une application qui utilise l’authentification standard des cookie ASP.NET Core, car elle utilise la protection des données pour protéger ses cookies. Si vous souhaitez avoir des porte-clés indépendants de l’emplacement, utilisez un fournisseur de porte-clés externe, tel que Stockage Blob Azure, Azure Key Vault, un magasin SQL ou un 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 rest à 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 qui est dans une liste de contrôle d'accès uniquement pour le compte de processus de travail. Les clés sont chiffrées au rest à l’aide de DPAPI.

  4. Si aucune de ces conditions ne correspond, 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 est toujours en contrôle total et peut remplacer comment et où les clés sont stockées. Les trois premières options ci-dessus doivent fournir de bonnes valeurs par défaut pour la plupart des applications similaires à la façon dont les routines de génération automatique ASP.NET< machineKey> fonctionnaient dans le passé. L’option de secours finale est le seul scénario qui oblige le développeur à spécifier la configuration à l’avance s’il souhaite la persistance des clés, mais cette solution de secours ne se produit que dans de rares situations.

Lors de l’hébergement dans un conteneur Docker, les clés doivent être conservées dans un dossier avec 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 que Azure Key Vault ou Redis. Un fournisseur externe est également utile dans les scénarios de batterie de serveurs web si les applications n’ont pas accès à un volume de réseau partagé (pour plus d’informations, consultez PersistKeysToFileSystem).

Avertissement

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

Durée de vie de la clé

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 définit la nouvelle clé 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 Gestion des clés.

Algorithmes par défaut

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

Ressources supplémentaires