Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Conseil / Astuce
Ce contenu est un extrait du livre électronique 'Architecture des microservices .NET pour les applications .NET conteneurisées', disponible sur .NET Docs ou en tant que PDF téléchargeable gratuitement, lisible hors ligne.
Pour vous connecter avec des ressources protégées et d’autres services, ASP.NET applications Principales doivent généralement utiliser des chaînes de connexion, des mots de passe ou d’autres informations d’identification contenant des informations sensibles. Ces informations sensibles sont appelées secrets. Il est recommandé de ne pas inclure de secrets dans le code source et de ne pas stocker les secrets 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 séparer les secrets pour accéder aux ressources de développement et de préproduction de ceux utilisés pour accéder aux ressources de production, car différentes personnes auront besoin d’accéder à ces différents ensembles de secrets. Pour stocker les secrets utilisés pendant le développement, les approches courantes sont de stocker des secrets dans des variables d’environnement ou à l’aide de l’outil Core Secret Manager ASP.NET. Pour un stockage plus sécurisé dans les environnements de production, les microservices peuvent stocker des secrets dans un coffre de clés Azure.
Stocker des secrets dans des variables d’environnement
Pour empêcher les secrets du code source, les développeurs doivent définir des secrets basés sur des chaînes en tant que variables d’environnement sur leurs ordinateurs de développement. Lorsque vous utilisez des variables d’environnement pour stocker des secrets avec des noms hiérarchiques, tels que ceux imbriqués dans les sections de configuration, vous devez nommer les variables pour inclure la hiérarchie complète de ses sections, délimitées par des deux-points (:)).
Par exemple, définir une variable d'environnement Logging:LogLevel:Default à une valeur Debug équivaut à une valeur de configuration provenant du fichier JSON suivant :
{
"Logging": {
"LogLevel": {
"Default": "Debug"
}
}
}
Pour accéder à ces valeurs à partir des variables d’environnement, l’application doit simplement utiliser AddEnvironmentVariables sur son ConfigurationBuilder lors de la construction d'un objet IConfigurationRoot.
Remarque
Les variables d’environnement sont généralement stockées sous forme de texte brut. Par conséquent, si l’ordinateur ou le processus avec les variables d’environnement est compromis, les valeurs des variables d’environnement sont visibles.
Stocker des secrets avec le gestionnaire de secrets principal ASP.NET
L'outil Secret Manager d'ASP.NET Core offre une autre méthode pour garder les secrets en dehors du code source pendant le développement. Pour utiliser l’outil Secret Manager, installez le package Microsoft.Extensions.Configuration.UserSecrets dans votre fichier projet. Une fois cette dépendance présente et restaurée, la dotnet user-secrets commande peut être utilisée pour définir la valeur des secrets à partir de la ligne de commande. Ces secrets seront stockés dans un fichier JSON dans le répertoire de profil de l’utilisateur (les détails varient selon le système d’exploitation), loin du code source.
Les secrets définis par l’outil Gestionnaire de secrets sont organisés par la UserSecretsId propriété du projet qui utilise les secrets. Par conséquent, vous devez être sûr de 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 affecté par Visual Studio, mais la chaîne réelle n’est pas importante tant qu’elle est unique dans votre ordinateur.
<PropertyGroup>
<UserSecretsId>UniqueIdentifyingString</UserSecretsId>
</PropertyGroup>
L’utilisation des secrets stockés avec Secret Manager dans une application est effectuée en appelant AddUserSecrets<T> l’instance ConfigurationBuilder pour inclure des secrets pour l’application dans sa configuration. Le paramètre T générique doit être un type de l’assembly auquel l’UserSecretId a été appliqué. En règle générale, l’utilisation AddUserSecrets<Startup> est correcte.
Le AddUserSecrets<Startup>() est inclus dans les options par défaut de l’environnement de développement avec la méthode CreateDefaultBuilder dans Program.cs.