Encryption de la connectionStrings dans un Web.Config via la clé NetFrameworkConfigurationKey dans un scénario de Web Farm IIS

Une des mesures les plus recommandées lors d'audit de sécurité d'applications web, est l'encryption de la section connectionStrings dans le fichier Web.Config. Si cette opération s'avère relativement simple dans un environnement avec un seul serveur IIS, cela peut se compliquer lorsque l'on parle de Web Farm avec réplication de données entre différents serveurs. Si vous choisissez d'encrypter cette section avec la clé par défaut qui se nomme NetFrameworkConfigurationKey sur un serveur donné, tout devrait bien se passer. Par contre, si le fichier Web.Config encrypté est ensuite répliqué sur un ensemble de serveurs d'une ferme, il va y avoir un souci.

Il faut savoir que la clé NetFrameworkConfigurationKey est composée de deux parties :

1. Un ID unique identifiant cette clé : d6d986f09a1ee04e24c949879fdb506c
2. Le GUID de la machine : 11cb3f60-488c-4a71-ad45-def6f31e5d62

Ce qui donne par exemple : d6d986f09a1ee04e24c949879fdb506c_11cb3f60-488c-4a71-ad45-def6f31e5d62. Vous pouvez trouver cette clé dans le répertoire C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys. Si vous vérifiez sur différent serveurs IIS vous verrez que le GUID est différent à chaque fois. Par conséquent, si un fichier Web.Config est encrypté avec la clé d'un serveur 1, il ne pourra pas être décrypté avec la clé du serveur 2 étant donné que cette dernière ne correspond pas.

Pour éviter ce problème, voici la démarche à suivre. Le scénario détaillé consiste en un serveur Primaire à partir duquel l'ensemble des fichiers seront répliqués via l'Application Provisioning sur un ou plusieurs serveur(s) Secondaire(s) (ce qui inclut le fichier Web.Config). Si vous n'utilisez pas d'Application Provisioning mais que vous souhaitez pouvoir copier/coller un Web.Config encrypté, ce scénario fonctionnera également mais vous devrez faire le copier/coller vous-même lorsque l'Application Provisioning est sensé entrer en action.

Remarque : Je recommande de tester cette procédure dans un premier temps sans suivre les étapes qui consistent à supprimer les clés "NetFrameworkConfigurationKey" des serveurs Primaire & Secondaire. Si la procédure sans suppression fonctionne sans problème, vous pourrez la dérouler entièrement pour obtenir une configuration propre au niveau des clés.

 

Sur le serveur Primaire :

• Ouvrir un CMD en mode administrateur
  • Remarque : il faut impérativement faire un clic droit > Ouvrir en tant qu'Administrateur même si le CMD s'ouvre par défaut en Administrateur
    Si vous ne l'ouvrez pas explicitement en Administrateur les privilèges ne sont pas corrects pour exécuter les commandes.
• Naviguer vers le répertoire "C:\Windows\Microsoft.NET\Framework64\v2.0.50727"
• Exécuter la commande suivante pour supprimer les clés "NetFrameworkConfigurationKey" existantes :
  • aspnet_regiis.exe -pz "NetFrameworkConfigurationKey"
• Exécuter la commande suivante pour créer une clé "NetFrameworkConfigurationKey" avec la clé privée exportable :
  • aspnet_regiis.exe -pc "NetFrameworkConfigurationKey" -exp
• Exécuter la commande suivante pour exporter la clé dans un fichier XML nommé key.xml en incluant la clé privée :
  • aspnet_regiis.exe -px "NetFrameworkConfigurationKey" key.xml -pri
• Si l'identité de l'Application Pool n'est pas ApplicationPoolIdentity, exécutez la commande suivante pour donner les droits d'accès à cette clé au compte utilisé en tant qu'identité de l'Application Pool :
  • aspnet_regiis -pa "NetFrameworkConfigurationKey" "Domain\ApplicationPooIdentityName"

 

Sur le serveur Secondaire :

• Ouvrir un CMD en mode administrateur
  • Remarque : il faut impérativement faire un clic droit > Ouvrir en tant qu'Administrateur même si le CMD s'ouvre par défaut en Administrateur
• Naviguer vers le répertoire "C:\Windows\Microsoft.NET\Framework64\v2.0.50727"
• Exécuter la commande suivante pour supprimer les clés "NetFrameworkConfigurationKey" existantes :
  • aspnet_regiis.exe -pz "NetFrameworkConfigurationKey"
• Copier le fichier key.xml du serveur Primaire vers le Secondaire dans le répertoire "C:\windows\Microsoft.NET\Framework64\v2.0.50727" :
• Exécuter la commande suivante pour importer la clé "NetFrameworkConfigurationKey" :
  • aspnet_regiis.exe -pi "NetFrameworkConfigurationKey" key.xml
• Si l'identité de l'Application Pool n'est pas ApplicationPoolIdentity, exécutez la commande suivante pour donner les droits d'accès à cette clé au compte utilisé en tant qu'identité de l'Appplication Pool :

  • aspnet_regiis -pa "NetFrameworkConfigurationKey" "Domain\ApplicationPooIdentityName"

     

Sur le serveur Primaire :

• Exécuter la commande suivante pour encrypter la section connectionStrings du Web.Config situé dans le répertoire "C:\inetpub\wwwroot" (chemin à remplacer en fonction de vos besoins) :
  • aspnet_regiis.exe -pef "connectionStrings" "C:\inetpub\wwwroot"

A cette étape, le fichier Web.Config encrypté sera transféré sur le serveur Secondaire via l'Application Provisioning (à faire vous-même si vous n'avez pas mis en place d'Application Provisioning). Etant donné que les clés sont bien positionnées, il ne devrait pas y avoir de problème pour décrypter le Web.Config. Mais nous allons le vérifier.

Sur le serveur Secondaire :

• Copier le fichier Web.Config encrypté dans un autre répertoire : C:\test par exemple
  • Remarque : Il est préférable de positionner le fichier Web.Config dans un répertoire qui n'est pas soumis à l'Application Provisioning pour éviter qu'il soit remplacé par la version encryptée du serveur Primaire pendant ce test
• Exécuter la commande suivante pour décrypter la section connectionStrings du Web.Config situé dans le répertoire "C:\test" :
  • aspnet_regiis.exe -pdf "connectionStrings" "C:\test"

Si cela fonctionne, c'est que toute la procédure s'est déroulée sans problème.

 

En espérant que cet article vous soit utile…
@ Bientôt
Sylvain Lecerf et L'équipe de support IIS Microsoft France