Pour un serveur dédié, est-il préférable de stocker la chaîne de connexion dans web.config ou machine.config? Quels sont les avantages et les inconvénients de chaque approche?
merci
Edit: Je suis préoccupé par la sécurité ici, la question concerne donc la question de savoir quelle approche est plus sécurisée.
7 Réponses :
Je vais toujours avec web.config au motif que c'est là que tout le monde s'attendrait à ce que ce soit. Il n'est pas question de donner à la personne qui doit conserver le site Web plus de difficulté en stockant des chaînes de connexion dans un endroit inhabituel.
additionnel
Sur la base des informations supplémentaires que l'OP est intéressé par l'aspect sécurité, plutôt que et en général, j'ai ajouté ce qui suit.
Je ne stockerais toujours pas les chaînes de connexion dans la machine.config. Si vous faites que toute application .NET exécutée sur la machine a accès à vos chaînes de connexion.
web.config est un fichier protégé. IIS ne le servira pas par défaut, sauf si vous faites quelque chose pour la confier à la configuration.
Je suis d'accord. Rester simple. Et pas seulement pour les autres, pour vous-même aussi.
En fait, je vais me maintenir le site moi-même que ce n'est pas un problème.
Ma recommandation ne fait aucune mention de qui est le responsable. Même si c'est vous, ma recommandation se tient toujours. Garder les choses simples. 6 mois sur la ligne que vous auriez peut-être oublié.
Je n'oublierai pas, promis :) .. Sérieusement, le point de la question est de savoir quelle approche est plus sécurisée et pourquoi. Il me semble que Machine.Config peut être un peu plus sécurisé que web.config. La sécurité est ma vraie préoccupation ici.
Ensuite, vous voudrez peut-être modifier votre question pour refléter que vous êtes plus intéressé par l'aspect sécurité.
Ce n'est pas tellement IIS / ASP.NET le servant (bien qu'il y ait une possibilité, il pourrait y avoir un bug) qui devrait être l'inquiétude, mais votre propre code. Les scripts pour servir des fichiers qui ne prennent pas en compte des chemins relatifs sont un moyen merveilleux d'accéder à web.config.
@blowdart, point intéressant. Cela semble être une bonne raison de considérer machine.config
@Waleed: Tout ce que j'ai lu ici indique Ne pas utiliser machine.config. C'est totalement non standard
J'ai également changé l'ID Le processus ASPnet est hébergé par un compte de domaine. Ensuite, utilisez la sécurité intégrée et donnez ce compte la sécurité minimale absolue dont il a besoin pour obtenir le travail (l'accordant que DBADM est mauvais).
@Jeff s, en fait, j'utilise mysql, donc aucune sécurité intégrée avec ça
Y a-t-il de toute façon il peut être stocké dans IIS? Pour que tous les sites Web puissent accéder à la base de données (je n'ai qu'un seul serveur Web avec 10 sites Web et je ne veux pas que les programmeurs apportent des modifications à web.config, ou même si elles le font, je ne les veux pas, alors le verra)
Si les programmeurs ont accès aux serveurs à un niveau pour leur permettre de voir le web.config alors quel est le problème réel de leur pouvoir le voir / le modifier? Il me semble que vous deviez soit configurer une équipe d'opérations pour maintenir le web.config ou faire confiance aux développeurs pour avoir accès au serveur.
I, personnellement, je ne stockerais jamais mes chaînes de connexion dans ma machine.Config uniquement dans le Web.config.
Vous dites que c'est un serveur dédié, mais ce serveur est dédié à une seule application Web?
Sinon, vous avez maintenant un seul fichier (machine.config) qui partageait efficacement les données de configuration pour plusieurs applications Web (probablement liées aux Nations Unies). En fonction du nombre de ces applications, et si vous avez besoin de les déplacer sur un autre serveur, à l'aide de la machine.Config pourrait devenir très désordonné.
Même si le serveur est dédié à une seule application Web, vous effectuerez probablement votre développement et tests sur d'autres machines. Puisque la machine.config n'est normalement pas un fichier inclus dans l'ensemble de fichiers d'un projet d'application Web ASP.NET, vous devrez probablement vous détourner de déployer la machine.Config vers chacun des différents dev / test. / Machines de production et assurez-vous que la configuration associée à une autre (chaîne de non-connexion) est correcte pour cette machine.
Utilisation du web.config Pour stocker les chaînes de connexion de base de données permet un sens parfaitement logique et est entièrement attendu par presque tous les développeurs ASP.NET, même si vous avez plusieurs applications qui utiliseront exactement la même base de données sur le même serveur de base de données. Garder cette configuration dans le Web.config de chaque application permet à chacune de ces applications d'être plus autonomes et de ne pas dépendre de l'autre autre fichier "extérieur".
Je vis généralement la machine.config et quelque chose que le cadre lui-même utilise et appartient à une machine et est spécifique à cette machine. Je vais très rarement et touchez-le moi-même. J'apprécie le web.config en tant que fichier qui fait partie intégrante de votre projet d'application Web et "se déplace" avec ce projet au fur et à mesure de son déploiement et est déployé sur différentes machines.
Aussi, n'oubliez pas que beaucoup de ce qui est défini dans la machine.Config peut être "remplacé" sur une base par application en redéfinissant certains éléments de configuration dans un fichier web.config d'une application spécifique.
Bien sûr, il y a quelques raisons valables de modifier / modifier votre fichier machine.Config (telle que plusieurs serveurs Web dans une ferme Web auront probablement besoin de choses comme des clés de cryptage / de déchiffrement dans la machine.config pour être synchronisée), Cependant, je ne crois pas que les chaînes de connexion de base de données sont l'une de ces raisons valables.
Merci pour votre réponse détaillée, c'est une seule application Web à la manière.
Craig - Je comprends votre point, mais je pense que vous êtes absent de la réalité de maintenir de grands ensembles d'applications utilisant Web ou app config. Nous avons plus de 25 projets sur certains de nos serveurs qui contiennent tous la même chaîne de connexion de base de données. Nous allons devoir mettre à jour manuellement toutes les chaînes de connexion dans tous les projets afin de déplacer notre serveur DB à un nouveau nom d'hôte. Alors que s'ils étaient dans la configuration de la machine, nous pourrions les changer en une seule place.
@Lukevp Pour votre situation donnée, qui est quelque peu inhabituelle, je peux comprendre envie de stocker la chaîne de connexion dans le fichier machine.config pour éviter de répéter exactement la même chaîne de connexion dans 25 fichiers Web.config différents. Je suggérerais cependant que la plupart des personnes qui disposent de 25 candidatures sur le même serveur auront probablement de nombreuses chaînes de connexion, largement propres à chaque application.
Sécurité Sage Vous pouvez envisager de stocker vos chaînes de connexion dans son propre fichier crypté .Config que votre fichier web.config aurait une référence à.
Vous pouvez crypter juste des sections du web.config. Vous n'avez pas à créer un tout nouveau fichier.
Je trouve généralement plus facile de gérer si elles sont dans un fichier séparé. surtout si vous avez des charges de chaînes de connexion.
Si la sécurité est votre principale préoccupation, concentrez-vous sur le verrouillage de la base de données et des autorisations de l'utilisateur. La différence de sécurité entre Web / machine .config est minimale. La réponse de Colin est correcte. J'aurais voté ou commenté là-bas mais je n'ai pas encore le moxie!
En effet - la sécurité est une bête multicouche. Vous devriez faire de votre mieux pour verrouiller les bits sous la surface ainsi que ce qui est à la surface juste pour être sûr.
Je préfère garder mes chaînes de connexion dans la machine.config.
Mes chaînes de connexion sont différentes entre les environnements de dev, qa et prod et si je les ai gardés dans le web.config, je ne pouvais pas souffler en toute sécurité mon répertoire cible et copier le nouveau code. Ou je devrais vous rappeler de tout déployer mais le web.config, cela crée des problèmes lorsque d'autres parties du changement Web.config.
Cela dépend de votre situation, mais lorsqu'il devient un peu compliqué, le risque d'avoir la fausse chaîne de connexion dans le mauvais environnement est trop grande. Nous avons en fait eu des situations où les tests frappaient les mauvaises bases de données car la chaîne de connexion a été déplacée par inadvertance. Machine.Config est utilisé pour les éléments spécifiques à la machine - donc le nom. Il n'est jamais déplacé de la machine à la machine.
Donc, dans ma machine.Config, j'ai plusieurs chaînes de connexion comme Blogconnstring, ForumConnstring, ProjectXConnschschschstring, etc. Je ne considère pas ce paramètre de mélange pour différents sites, je considère qu'il garde le réglage du niveau de la machine dans le MACHING.CONFIG.
Vous avez été inquiet pour la sécurité, je pense qu'une fois qu'ils sont sur la boîte, ils sont également sécurisés. Mais si la chaîne de connexion est dans le web.config, elle finit généralement dans le contrôle de la source, les bureaux de développeur, dans les fichiers de sauvegarde, dans les plans d'installation, les ensembles de déploiement, etc. Ceci fait le web.config Way Secure pour moi.
Enfin, une autre approche consiste à l'avoir dans un fichier de configuration totalement différent (dire Webenvironment.confg), qui est ensuite référencé dans votre web.config. Ce fichier serait assis dans un répertoire qui n'est pas physiquement sous votre site Web, mais est virtuellement sous votre site. Plus de détails sont ici.
Désolé, mais je suis totalement en désaccord avec cela. La configuration de la machine passe dans la machine.Config, pas la configuration de l'application. Les chaînes de connexion de base de données sont spécifiques à l'application, pas spécifiques à la machine.
Si vous installez Windows maintenant, vous obtiendrez une chaîne de connexion par défaut dans Machine.Config - LocalSqlServer. C'est la valeur de configuration de la machine pour le SQL Express local. J'ai la configuration de la machine pour mon blog, mon site Web principal, etc. En tant que développeur, cela le rend tellement facile.
À chacun il y a propre. Mais je ne vois pas "MS Fais-le donc ça va" comme une bonne justification. J'ai perdu le nombre de terribles exemples de code sur le site Web de MSDN. Ce n'est pas parce qu'ils l'ont créé, cela ne signifie pas que leurs suggestions sur la manière de l'utiliser sont les meilleures. Je ne crois pas non plus l'accent sur la «vie de la vie facile pour le développeur», mais à nouveau, c'est une préférence personnelle. Ce n'est pas à propos de moi, tout concerne le logiciel.
Je suis d'accord avec Jbrookes. Les paramètres de configuration qui changent entre environnements sont une douleur énorme et il est beaucoup plus facile de gérer les environnements lorsque tous ceux-ci sont dans la machine.Config au lieu des personnes individuelles. Cela a du sens pour moi - sur notre serveur de stockage, je veux toujours pointer sur serviceTest.example.com et sur la production, je veux toujours pointer sur service.example.com. Pourquoi souhaiterais-je maintenir manuellement ces paramètres pour chaque application et les avoir dupliqués sur des dizaines de projets?
@Lukevp C'est exactement ce que transforme web.config transforme sont pour.
@CRAIGTP de sorte que vous mettriez des informations sensibles telles que des chaînes de connexion de production (y compris le mot de passe) dans le fichier de transformation de la version dans votre référentiel de code source où chaque développeur a accès aux détails de la connexion de la production?
@HOFNARWILLIE FWIW, je ferais effectivement cela comme je (et l'organisation que je travaille pour) fait confiance aux développeurs avec de telles informations.
@CRAIGTP, c'est très gentil. La société dont je travaille a 300 développeurs (dont plusieurs sont des membres du personnel de l'entrepreneur qui viennent généralement dans quelques semaines), donc ce n'est pas aussi simple que de faire confiance à tout le monde, aussi idéal que cela pourrait être. Il serait irresponsable à vos clients et à la sécurité de leurs utilisateurs. Au Royaume-Uni, vous seriez en violation de la Loi sur la protection des données ( ico.org.uk/for-organisations/Guide-a-Data-Protection/... )
Il y a beaucoup de bons points, ici. L'environnement Jbrooks est le plus proche de la mienne, mais à la fin, je suis en désaccord avec la mise en place des chaînes de connexion dans la machine.config. < / p>
Je suis d'accord avec JO mais pas pour la raison qu'il cite, ici. Je voudrais souligner, comme Jbrooks a déclaré que les chaînes de connexion utilisent probablement des informations d'identification différentes dans les environnements de développement et de production. Nos bases de données de développement intranet, par exemple, ont tous les mêmes informations d'identification simples tandis que nos bases de données de production ont chacune des informations d'identification différentes avec des mots de passe complexes. Donc, il y a de très bonnes raisons pour ne pas mettre vos chaînes de connexion dans le fichier Web / App.config mais plutôt dans un fichier local sur le serveur cible. Je aime le registre, moi-même, mais je sais que ce n'est pas du tout pris en charge. De toute évidence, le fichier Machine.config est là pour fournir une solution.
Non, je suis d'accord avec JO car dans le Machine.config réside framework .Net et pourraient être modifiés par Microsoft. Mais Microsoft ne sait rien du blowdart fait le point sur le cryptage - toujours une bonne idée. Mais à la fin, la seule façon de protéger pleinement vos informations d'identification de base de données est de les changer périodiquement. connectionStrings.config sur nos serveurs de production. Ce fichier est chargé par les fichiers Web / App.config avec:
Tous les bons points. Dans mon environnement, les bases de données sont partagées afin de stocker une redondance des forces Web.config. Nous utilisons des bases de données SQL standard ici que tout le monde accède. Un fichier de configuration séparé est préféré. Cela permet de normaliser, de la sécurité et de l'élimination du besoin de modifier le web.config lorsqu'une application est déployée.
Dans l'un ou l'autre endroit, vous devriez envisager de le crypter (bien que vous utilisiez des connexions de confiance, je ne vous inquiéterais pas beaucoup). Il y a un outil plutôt pratique pour cela maintenant chez QuelquesWebGuyy. wordpress.com/2009/07/16/...
Lien dans le commentaire ci-dessus mort; Maintenant, à hugoware.net/blog/encypt-your-web-config-plez-vous-config-plusez < / a>