Je travaille avec un groupe d'ingénieurs qui font du développement .NET 4 / MVC 3, utilisant Windows 7 Enterprise et IIS 7.5 localement, et se connectant à des bases de données de développement/test MSSQL 2008+. Les bases de données sont distantes mais toujours dans le même environnement Active Directory.
Notre configuration actuelle nécessite que nos environnements de développement locaux se connectent à SQL en tant que nos comptes individuels (par exemple, DOMAIN\Paul), et nous le faisons en définissant les informations d'identification du pool d'applications pour être les mêmes que celles que nous utilisons pour nous connecter à nos postes de travail. Sur le serveur de base de données, nous avons configuré un groupe (par exemple, DOMAIN\EngineerGroup) qui a les autorisations appropriées sur nos bases de données de développement/test. Cela semble fonctionner raisonnablement bien, à l'exception de l'inconvénient d'avoir à mettre à jour nos informations d'identification dans IIS chaque fois que nous changeons nos mots de passe. (Notre politique d'entreprise/groupe exige que nous changions régulièrement nos mots de passe.)
Je me demandais s'il y avait des risques de sécurité ou d'autres problèmes associés à l'utilisation du compte intégré ApplicationPoolIdentity. J'ai réussi à le faire fonctionner dans un environnement isolé en créant un nouveau compte SQL correspondant à DOMAIN\MYMACHINE$ et en lui accordant les mêmes autorisations que celles accordées à DOMAIN\EngineerGroup. Ma proposition est de créer un nouveau groupe Active Directory, par exemple DOMAIN\EngineerWorkstationGroup, dont les membres sont les postes de travail de chaque ingénieur (plutôt que le compte utilisateur de chaque ingénieur), et d'accorder les mêmes autorisations au nouveau groupe.
Idéalement, je recherche des articles ou des documents raisonnablement autorisés (probablement de Microsoft) qui détaillent comment ces comptes MACHINENAME$ sont sécurisés, en quoi ils peuvent différer des comptes utilisateurs, et quels risques supplémentaires (le cas échéant) leur utilisation nous exposerait. La meilleure source que j'ai trouvée jusqu'à présent est un article sur iis.net. J'ai essayé de nombreuses recherches et je n'ai pas vraiment trouvé autre chose qui discute des compromis liés à l'utilisation des différents types de comptes AD.
Merci d'avance !
P.S. Nous avons également envisagé d'utiliser un compte de domaine central (par exemple, créer un seul compte comme DOMAIN\EngineerAppPool et avoir tout le monde se connecter de IIS à SQL à partir de ce compte), mais je pense que cela rend l'audit et le profilage plus difficiles.
