Utilisation de DPAPI/ProtectedData dans un environnement de batterie de serveurs Web avec le magasin d'utilisateurs

Je me demandais si quelqu'un avait utilisé avec succès DPAPI avec un magasin d'utilisateur dans un environnement de ferme Web?

Parce que notre application est une application ASP.NET 1.1 à 2.0 récemment convertie, nous utilisons un wrapper personnalisé qui appelle directement les méthodes CryptUnprotect . Mais cela devrait être la même chose que la méthode ProtectedData </​​code> disponible dans le framework 2.0.

Parce que nous fonctionnons dans un environnement de ferme Web, nous ne pouvons pas garantir que la machine qui a fait le chiffrement sera celle qui le décryptera. (Aussi parce que les pannes de machine ne devraient pas détruire nos données cryptées).

Nous avons donc un composant qui fonctionne dans un service sous un compte d'utilisateur particulier sur chacune de nos boîtes Web. Cet utilisateur est configuré pour avoir un profil itinérant, conformément à la recommandation.

Le problème que nous avons est que les informations cryptées sur une machine ne peuvent pas être décryptées sur une autre, cela échoue avec l'erreur win32:

'La clé n'est pas valide pour une utilisation dans un état spécifié'.

Je suppose que c'est parce que j'ai fait une erreur en faisant fonctionner le service de cryptage en tant qu'utilisateur sur plusieurs machines, maintenant l'utilisateur connecté sur plus d'une machine en même temps.

Si tel est le problème, comment les autres utilisateurs utilisent DPAPI avec le magasin d'utilisateurs dans un environnement de batterie de serveurs Web?

3
Salut, avez-vous eu la réponse à cela? J'ai le même problème.
ajouté l'auteur user6535, source

3 Réponses

Dans un environnement de batterie de serveurs Web, plutôt que d'utiliser DPAPI pour crypter/décrypter vos données directement, vous l'utiliseriez plutôt pour crypter la clé que vous utiliserez plus tard pour déchiffrer vos données protégées.

Vous "installerez" la clé sur chaque serveur dans le cadre du processus de déploiement. Le script d'installation doit s'exécuter sous l'identité de l'AppPool et peut stocker la clé cryptée dans un fichier app.config ou dans le registre.

Les données chiffrées pourraient elles-mêmes être stockées dans un référentiel central/une base de données, de sorte que tous les serveurs de la batterie puissent y accéder. Pour déchiffrer les données, l'application Web récupère la clé chiffrée à l'endroit où elle a été installée, utilise DPAPI pour la déchiffrer, puis utilise le résultat pour déchiffrer les données provenant du référentiel central.

L'inconvénient est que la clé cleartext peut exister sur le disque local pendant une courte période au cours du processus d'installation initial, où elle pourrait être exposée au personnel des opérations. Vous pouvez ajouter une couche supplémentaire de chiffrement, par exemple avec la machineKey web.config, si cela vous préoccupe.

8
ajouté
C'est malheureux, car l'un des avantages de DPAPI est qu'il expire automatiquement la clé principale tous les 3 mois, mais est capable de déchiffrer des données précédemment cryptées. msdn.microsoft.com/en-us/library/ms995355.aspx Quote: "Cette expiration empêche un attaquant de compromettre une seule MasterKey et d'accéder à toutes les données protégées d'un utilisateur." En utilisant votre propre clé si elle est compromise, toutes vos données sont exposées.
ajouté l'auteur ToddK, source
C'est un peu obsolète, mais je crois que vous serez toujours capable de "voir" la clé même si elle est contenue dans le web.config et cryptée en utilisant aspnet_regiis . Votre approche est ce que la plupart des gens recherchent car il n'y a pas de mécanisme similaire prêt à l'emploi dans ASP.NET ou la BCL.
ajouté l'auteur CodeMonkeyKing, source

Je viens de voir ça. Il existe un moyen de faire en sorte que cela fonctionne, et de s'assurer que les machines de la batterie se trouvent dans un domaine et d'utiliser un compte de domaine pour chiffrer et déchiffrer les données (ex: exécuter l'application sous le compte de domaine)

Vous ne pouvez pas utiliser DPAPI comme vous le souhaitez avec les comptes locaux, car le contenu de la clé n'est pas échangé entre les serveurs.

J'espère que cela pourra aider!

2
ajouté

The Microsoft poster is wrong. http://support.microsoft.com/default.aspx?scid=kb;en-us;309408#6

«Pour que DPAPI fonctionne correctement lorsqu'il utilise des profils itinérants, l'utilisateur de domaine doit uniquement être connecté à un seul ordinateur du domaine.Si l'utilisateur souhaite se connecter à un autre ordinateur appartenant au domaine, l'utilisateur doit se déconnecter le premier ordinateur avant que l'utilisateur se connecte au deuxième ordinateur Si l'utilisateur est connecté à plusieurs ordinateurs en même temps, il est probable que DPAPI ne sera pas en mesure de décrypter les données cryptées existantes correctement. "

Il semble que DPAPI ne fonctionnera pas dans un environnement de ferme. Je pense que c'est une grosse erreur de la part de Microsoft et que DPAPI est presque inutile pour la plupart des applications d'entreprise.

1
ajouté