Stocker des secrets d’application en toute sécurité pendant le développement

Conseil

Ce contenu est un extrait du livre électronique « .NET Microservices Architecture for Containerized .NET Applications », disponible sur .NET Docs ou sous forme de PDF téléchargeable gratuitement et pouvant être lu hors ligne.

Télécharger le PDF

Pour se connecter à des ressources protégées et à d’autres services, les applications ASP.NET Core doivent généralement utiliser des chaînes de connexion, des mots de passe ou d’autres informations d’identification qui contiennent des informations sensibles. Ces informations sensibles sont appelées secrets. La bonne pratique consiste à ne pas inclure les secrets dans le code source, et à veiller à ne pas les stocker dans le contrôle de code source. Au lieu de cela, vous devez utiliser le modèle de configuration ASP.NET Core pour lire les secrets à partir d’emplacements plus sécurisés.

Vous devez distinguer les secrets destinés à accéder aux ressources de développement et de préproduction de ceux utilisés pour accéder aux ressources de production, car ce ne sont pas les mêmes personnes qui ont besoin d’accéder à ces différents jeux de secrets. Dans la pratique, les secrets utilisés en phase de développement sont généralement stockés dans des variables d’environnement ou avec l’outil Secret Manager d’ASP.NET Core. Pour un stockage plus sécurisé dans les environnements de production, les microservices peuvent stocker les secrets dans Azure Key Vault.

Stocker des secrets dans des variables d’environnement

Pour les développeurs, l’un des moyens de maintenir les secrets en dehors du code source est de définir des secrets basés sur des chaînes prenant la forme de variables d’environnement sur leurs machines de développement. Quand vous utilisez des variables d’environnement pour stocker des secrets avec des noms hiérarchisés (tels que ceux imbriqués dans des sections de configuration), vous devez nommer les variables de façon à inclure la hiérarchie complète de leurs sections, en les séparant de deux-points (:).

Par exemple, le fait d’affecter la valeur Debug à une variable d’environnement Logging:LogLevel:Default équivaudrait à une valeur de configuration du fichier JSON suivant :

{
    "Logging": {
        "LogLevel": {
            "Default": "Debug"
        }
    }
}

Pour accéder à ces valeurs à partir de variables d’environnement, l’application doit simplement appeler AddEnvironmentVariables sur son ConfigurationBuilder durant la construction d’un objet IConfigurationRoot.

Notes

Les variables d’environnement sont couramment stockées en texte clair. Ainsi, si la machine ou le processus comprenant les variables d’environnement est compromis, les valeurs des variables d’environnement sont visibles.

Stocker des secrets à l’aide de l’outil Secret Manager d’ASP.NET Core

L’outil Secret Manager d’ASP.NET Core offre un autre moyen de maintenir les secrets en dehors du code source pendant le développement. Pour utiliser l’outil Secret Manager, installez le package Microsoft.Extensions.Configuration.SecretManager dans votre fichier projet. Une fois cette dépendance présente et restaurée, vous pouvez utiliser la commande dotnet user-secrets pour définir la valeur des secrets à partir de la ligne de commande. Ces secrets sont alors stockés dans un fichier JSON dans le répertoire du profil de l’utilisateur (les détails varient selon le système d’exploitation), à l’écart du code source.

Les secrets définis par l’outil Secret Manager sont organisés par la propriété UserSecretsId du projet qui utilise les secrets. Par conséquent, veillez à définir la propriété UserSecretsId dans votre fichier projet, comme indiqué dans l’extrait de code ci-dessous. La valeur par défaut est un GUID assigné par Visual Studio, mais la chaîne réelle n’a pas d’importance tant qu’elle est unique sur votre ordinateur.

<PropertyGroup>
    <UserSecretsId>UniqueIdentifyingString</UserSecretsId>
</PropertyGroup>

Pour utiliser les secrets stockés avec Secret Manager dans une application, AddUserSecrets<T> est appelé au niveau de l’instance ConfigurationBuilder. Les secrets de l’application sont alors inclus dans sa configuration. Le paramètre générique T doit être un type de l’assembly auquel UserSecretId a été appliqué. Généralement, l’utilisation de AddUserSecrets<Startup> convient.

AddUserSecrets<Startup>() est inclus dans les options par défaut pour l’environnement de développement lors de l’utilisation de la méthode CreateDefaultBuilder dans Program.cs.

PrécédentSuivant