Le scénario actuel

Stocker les paramètres contenant des informations sensibles et utiliser des fichiers tels que appsettings.json est une pratique répandue. Il y aura cependant des moments où des mécanismes externes devront être utilisés pour rendre difficile l'accès de ces définitions à tout utilisateur (qui les obtiendrait rapidement en lisant simplement un fichier).

Compte tenu du développement de projets Web ASP.NET Core, comment protéger les secrets de nos applications de manière simple et efficace?

Une bonne réponse à cette question est L’Azure Key Vault, une solution de stockage de configurations sensibles proposée par Azure. Avec l'intégration à Azure Active Directory, la manipulation (lecture, écriture) des secrets définis dans Key Vault s'effectue en accordant un accès préalable à une application.

Dans ce nouvel article, je démontrerai l'utilisation de Azure Key Vault dans une API REST créée avec ASP.NET Core 2.2.

Vous devez déjà connaître l’AKV ou quand même l’avoir déjà utilisé dans vos projets. La différence c’est que en tant que développeur vous ne voyez pas l’architecture cloud et les paramètres de sécurité qu’on utilise. Par défaut, c’était une habitude de mettre en place le firewall avec les IPs Classe Affaires, mais ça ne fonctionne pas pour les applications web Azure. Pourquoi? Quand on parle de PaaS – Platform as a Service – la gestion de l’infrastructure c’est du fournisseur. Donc, les IPs de sortie de vos applications sont multiples et peuvent changer à chaque restart du Site Web, deploy ou parce que le fournisseur a changé les containers dans le data Center.

Dans ce concept, comment on peut ajouter les IPs et être sûr que l’application pourrait fonctionner sans arrêter?  La réponse est : on ne peut pas.

C’est pour ça qu’on commence à parler des VNETs. Les VNETs nous donnent la sécurité qui nous manque. Elle agira comme un firewall dont elle bloquera l’accès externe mais aussi créera un backbone entre votre application et votre service. Ça c’est parfait, non!?

 
content.png
Sample scenário
 

Dans notre cas, on aura un Web Site et un AKV, mais juste le site web pourrait accéder l’AKV grâce à notre VNET comme l’image ci-dessous :

 
content (1).png
AKV sécure
 

Le problème commence avec le processus utilisé actuellement dans nos projets. La DLL Microsoft.Azure.KeyVault que probablement vous utilisez pour accéder l’AKV fait référence à la DLL Microsoft.Rest.ClientRuntime. Ça veut dire que pour prendre les secrets dans l’AKV, il fera une requête HTTP.

Dans ce moment-là vous devrez se poser la question : mais le site web, il est autorisé à accéder l’AKV, non? Donc, ça ira!  PAS ENCORE…

Le site web pourrait accéder à l’AKV en utilisant la VNET qui est intégrée, cependant les requêtes http sortent par les IPs publics d’Azure, ce qui fait que notre appel à l’AKV entre comme un appel quelconque http public. Alors, il sera bloqué.

 

Azure App Configuration

Ça fait quelques mois que Microsoft a publié son nouveau service : Azure App Configuration

Azure App Configuration offre un service de gestion centralisée des paramètres d’application et des indicateurs de fonctionnalités. Les programmes modernes, en particulier les programmes qui s’exécutent dans le cloud, ont généralement de nombreux composants qui sont par nature distribués. La répartition des paramètres de configuration sur tous ces composants peut rendre les erreurs difficiles à corriger pendant le déploiement d’une application. Utilisez App Configuration pour stocker tous les paramètres de votre application et sécuriser leur accès dans un même endroit. Mais ça on s’en reparlera dans un prochain article.

Pour l’instant c’est important de le connaître parce que grâce à ce service que Microsoft a créé, on peut alors utiliser un Middleware pour travailler avec les configurations dynamiques. Vous pouvez lire plus ici.

L’avantage de cette approche, c’est qu’on pourra ajouter l’AKV dynamiquement en ajoutant quelques lignes de code. Voici l’exemple au-dessous :

 

 
content (2).png
program.cs
 

C’est tout!

 

Avec ça vous allez ajouter un appsettings.json dynamique et avec tous les secrets dans votre AKV.

Pour accéder quelque secret, il faut juste utiliser l’injection de dépendance de votre config file . Voici un exemple :

 

 
content (3).png
 

Ici on a aussi une autre opportunité d’apprentissage : La hiérarchie dans AKV.

Savez-vous qu’il y a un symbole pour créer la hiérarchie? C’est le « -- ». Donc, pour créer notre connection string dans l’AKV, il faut faire comme ça :

 

ConnectionStrings--MyConnectionString

 

C’est le « – » (tiret deux fois) qui ira créer une valeur comme ça :

 

 
content (4).png
appsettings.json dynamique
 

Simple, non?

 

* C’est important de créer le nom Connection Strings avec un « S » parce que le méthode config.GetConnectionString ira chercher dans le appsettings dynamique le paramètre comme ça!

 

Donc, quelle est la différence entre les deux méthodes? (Avec la classe qu’on avait et maintenant)

Surtout la sécurité, parce qu’avec ça, la configuration utilisera la VNET pour aller chercher les secrets dans l’AKV et non pas une requête HTTP, mais aussi cela facilite la maintenance du code et le dynamisme de nos paramètres.

 

On aimera écouter tes avis !

 

Merci et à la prochaine !

Comments


Comments are closed