对于专用服务器，将连接字符串存储在web.config还是machine.config中更好？每种方法的优缺点是什么？
谢谢
编辑：我担心安全问题，所以问题是哪种方法更安全。
在machine.config中存储连接字符串与在web.config中存储连接字符串的区别
9
- Waleed Eissa
2
无论在哪个位置，您都应该考虑加密它（尽管如果您正在使用可信连接，我不会太担心）。现在有一个非常方便的工具可以做到这一点，网址是http://somewebguy.wordpress.com/2009/07/16/encrypt-your-web-config-please/。 - blowdart
链接已失效，请访问http://hugoware.net/blog/encrypt-your-web-config-please。 - Chris J
7个回答
10
我更喜欢将连接字符串保存在 machine.config 中。
因为在 DEV、QA 和 PROD 环境中，我的连接字符串是不同的。如果我将它们保存在 web.config 中，我就不能安全地清除目标目录并上传新代码了。否则，我就必须记得部署除了 web.config 之外的所有内容，这会在 web.config 的其他部分发生更改时创建问题。
这取决于你的情况，但当涉及到一些复杂的内容时，将错误的连接字符串放入错误的环境中的风险太大了。我们曾经遇到过测试命中错误的数据库，因为连接字符串被无意间移动了。Machine.config 用于机器特定项目-因此名称如此。它永远不会从一台机器移动到另一台机器。
所以在我的 machine.config 文件中，我有多个连接字符串，例如 blogConnString、forumConnString、projectxConnString 等。我认为这不是混合设置不同站点，而是将机器级别的设置保存在 machine.config 中。
关于安全性的担忧，我认为一旦它们在服务器上，它们就是同样安全的。但是，如果连接字符串在 web.config 中，它通常会出现在源代码控制中、开发人员的桌面上、备份文件中、安装计划、部署集等中。这使得我认为 web.config 不那么安全。
最后，另一种方法是将其保存在完全不同的配置文件中（比如 WebEnvironment.confg），然后在 web.config 中引用它。这个文件将位于一个目录下，这个目录在物理上不属于你的网站，但在虚拟上属于你的网站。更多细节请参见此处。
- JBrooks
8
1抱歉，我完全不同意这个观点。机器配置应该放在machine.config中，而不是应用程序配置中。数据库连接字符串是应用程序特定的，而不是机器特定的。 - OJ.
如果您现在安装Windows，将在machine.config中获取默认连接字符串-LocalSqlServer。 它是本地SQL Express的机器配置值。 我对我的博客，主要网站等进行了机器配置。 作为开发人员，这使得它变得非常容易。 - JBrooks
1我同意JBrooks的观点。在不同环境中更改的配置设置非常麻烦，当所有这些设置都在machine.config而不是单独的设置中时，管理环境就容易得多了。对我来说很有道理 - 在我们的演示服务器上，我总是想指向servicetest.example.com，在生产环境中，我总是想指向service.example.com。为什么我要为每个应用程序手动维护这些设置，并且还要在数十个项目中重复它们呢？ - lukevp
1@CraigTP 那么您会把诸如包括密码在内的生产连接字符串等敏感信息放入发布转换文件中，存储在源代码仓库中，以便每个开发人员都可以访问生产登录详细信息吗？ - hofnarwillie
2@CraigTP，非常好。我工作的公司有300名开发人员（其中几位是承包员工，通常在几周内来来去去），所以信任每个人并不像理想那样简单。这对您的客户和他们的用户安全是不负责任的。在英国，这将违反数据保护法（https://ico.org.uk/for-organisations/guide-to-data-protection/principle-7-security/）。 - hofnarwillie
显示剩余3条评论
10
我会始终选择 web.config，因为这是每个人都期待的地方。把连接字符串存储在不寻常的地方只会给那些必须维护网站的人更多的困难。
补充说明
基于其他信息表明 OP 关心安全问题，而不是一般原因，我添加了以下内容。
我仍然不会将连接字符串存储在 machine.config 中。如果您这样做，任何运行在该计算机上的 .NET 应用程序都可以访问您的连接字符串。
web.config 是受保护的文件。除非您进行错误配置，否则 IIS 不会默认提供它。
- Colin Mackay
12
2我的建议并没有提到维护者是谁。即使是你，我的建议仍然有效。保持简单。半年后你可能已经忘记了。 - Colin Mackay
@blowdart，有趣的观点。这似乎是考虑使用machine.config的一个好理由。 - Waleed Eissa
@Jeff S，实际上我正在使用MySQL，所以没有集成的安全性。 - Waleed Eissa
有没有办法将它存储在IIS中，以便所有网站都可以访问数据库（我只有一个Web服务器，上面有10个网站，我不希望程序员对web.config进行修改，即使他们这样做，我也不希望他们看到它）？ - Akash Kava
如果程序员在访问级别上可以访问服务器并查看web.config文件，那么他们能够查看/修改它的真正问题是什么？ 在我看来，要么您需要设置一个运营团队来维护web.config，要么就必须信任开发人员能够访问服务器。 - Colin Mackay
显示剩余7条评论
5
个人而言，我从不将连接字符串存储在machine.config文件中，只会存储在web.config文件中。
你说这是一台专用服务器，但这个服务器是为单个Web应用程序专用的吗？如果不是，那么现在你有一个单一的文件（machine.config），实际上正在共享多个（可能无关的）Web应用程序的配置数据。根据这些应用程序的数量，以及如果您需要将它们移动到另一台服务器，则使用machine.config可能会变得非常混乱。
即使服务器确实专用于单个Web应用程序，您也可能会在其他计算机上执行开发和测试。由于machine.config通常不是包含在ASP.NET Web应用程序项目的文件集中的文件，因此您可能必须费尽周折地将machine.config部署到各种dev/test/production机器，并确保其中的其他（非连接字符串）相关配置对于该机器是正确的。
在web.config中存储数据库连接字符串完全符合逻辑，并且几乎所有ASP.NET开发人员都会预期，即使您有多个应用程序将在完全相同的数据库服务器上使用完全相同的数据库。将此配置保存在每个应用程序的web.config中允许每个应用程序更加自包含，而不依赖于某些其他“外部”文件。
我通常将machine.config视为框架本身使用的内容，它属于一台机器，是特定于该机器的。我很少自己去触碰它。我将web.config视为您的Web应用程序项目的一部分，并且随着该项目的移动和部署到不同的计算机而“移动”。
此外，请不要忘记，machine.config中定义的许多内容可以通过在特定应用程序的web.config文件中重新定义某些配置元素来“覆盖”。
当然，有一些有效的原因需要编辑/更改machine.config文件（例如，在Web农场中的多个Web服务器可能需要同步machine.config中的加密/解密密钥），但是我不认为数据库连接字符串是这些有效原因之一。
你说这是一台专用服务器，但这个服务器是为单个Web应用程序专用的吗？如果不是，那么现在你有一个单一的文件（machine.config），实际上正在共享多个（可能无关的）Web应用程序的配置数据。根据这些应用程序的数量，以及如果您需要将它们移动到另一台服务器，则使用machine.config可能会变得非常混乱。
即使服务器确实专用于单个Web应用程序，您也可能会在其他计算机上执行开发和测试。由于machine.config通常不是包含在ASP.NET Web应用程序项目的文件集中的文件，因此您可能必须费尽周折地将machine.config部署到各种dev/test/production机器，并确保其中的其他（非连接字符串）相关配置对于该机器是正确的。
在web.config中存储数据库连接字符串完全符合逻辑，并且几乎所有ASP.NET开发人员都会预期，即使您有多个应用程序将在完全相同的数据库服务器上使用完全相同的数据库。将此配置保存在每个应用程序的web.config中允许每个应用程序更加自包含，而不依赖于某些其他“外部”文件。
我通常将machine.config视为框架本身使用的内容，它属于一台机器，是特定于该机器的。我很少自己去触碰它。我将web.config视为您的Web应用程序项目的一部分，并且随着该项目的移动和部署到不同的计算机而“移动”。
此外，请不要忘记，machine.config中定义的许多内容可以通过在特定应用程序的web.config文件中重新定义某些配置元素来“覆盖”。
当然，有一些有效的原因需要编辑/更改machine.config文件（例如，在Web农场中的多个Web服务器可能需要同步machine.config中的加密/解密密钥），但是我不认为数据库连接字符串是这些有效原因之一。
- CraigTP
3
感谢您详细的回答，顺便说一下，这是一个单一的Web应用程序。 - Waleed Eissa
Craig - 我理解你的观点，但我认为你忽略了维护使用 Web 或应用程序配置的大型应用程序集的现实情况。我们在一些服务器上有 25 多个项目，它们都包含相同的数据库连接字符串。为了将我们的 DB 服务器移动到新的主机名，我们将不得不手动更新所有项目中的所有连接字符串。而如果它们在机器配置中，我们可以在一个地方更改它们。 - lukevp
@lukevp 鉴于你的情况有些不同寻常，我可以理解希望将连接字符串存储在 machine.config 文件中，以避免在 25 个不同的 web.config 文件中重复相同的连接字符串。然而，我建议大多数在同一服务器上拥有 25 个应用程序的人可能会有许多不同的连接字符串，这些连接字符串在很大程度上是每个应用程序独特的。 - CraigTP
3
如果安全是您的首要关注点，请集中精力锁定数据库和用户权限。Web /机器.config之间的安全差异很小。 Colin的答案是正确的。我本来想投票或在那里发表评论，但我还没有勇气！
- Jerry
1
确实 - 安全是一个多层次的问题。你应该尽力锁定表面以下的部分，以及表面上的部分，以确保安全。 - Colin Mackay
1
这里有很多好的观点。JBrooks的环境最接近我的，但最终我不同意将连接字符串放在Machine.config中。
我同意OJ，但不是他所说的原因。正如JBrooks所说，连接字符串很可能在开发和生产环境中使用不同的凭据。例如，我们的内部网络开发数据库都具有相同的简单凭据，而我们的生产数据库则具有不同的凭据和复杂的密码。因此，有非常好的理由不将连接字符串放在Web/App.config文件中，而是放在目标服务器本地的文件中。我喜欢注册表，但我知道这完全不被支持。显然，Machine.config文件存在是为了提供解决方案。
不，我同意OJ的观点，因为 Machine.config 存在于 .Net 框架中，可以被 Microsoft 更改。但是 Microsoft 对我们生产服务器上的 connectionStrings.config 文件一无所知。该文件由 Web/App.config 文件加载，具体方式如下：
<connectionStrings configSource="path\to\connectionStrings.config"/>
blowdart 提到了加密的重要性 - 这总是一个好主意。但最终，完全保护数据库凭据的唯一方法是定期更改它们。
- sthames42
0
所有的观点都很好。在我的环境中，数据库是共享的，因此将其存储在 web.config 中会导致冗余。我们在这里使用标准的 SQL 数据库，每个人都可以访问。更喜欢使用单独的配置文件。这样可以实现标准化、安全性，并消除了在部署应用程序时需要更改 web.config 的需求。
- Clem
0
从安全角度考虑，您可以将连接字符串存储在自己的加密 .config 文件中，并让您的 web.config 文件引用它。
- MakkyNZ
2
1您可以只加密 web.config 文件的某些部分，而不需要创建一个全新的文件。 - Colin Mackay
1我通常发现如果它们在单独的文件中，管理起来会更容易。特别是当你有大量的连接字符串时。 - MakkyNZ
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接