安全问题 ASP.NET 集成身份验证答案

【问题标题】：Security Issues ASP.NET integrated Authentication安全问题 ASP.NET 集成身份验证
【发布时间】：2012-03-22 05:50:08
【问题描述】：

我们目前使用连接字符串来验证我们的数据库凭据。由于增长和合规性，开发人员不再被允许“查看”我们网站使用的数据库凭据。解决此问题的方法是使用集成身份验证。我们计划为每个应用程序池设置一个用户，然后允许该用户访问数据库。

我的问题是：这种方法是否存在任何安全问题？就从连接字符串中删除数据库凭据而言，我们应该/可以采取更好（更简单或更简单）的方法吗？

【问题讨论】：

【解决方案1】：

如果您的连接字符串存储在web.config 文件中，您可以为该文件创建一个开发人员无法看到的单独生产版本。这比使用应用程序池的集成身份验证更容易测试和设置。

但有一点警告：如果您对开发人员限制这么多，将会减慢他们的更改速度。由于世界其他地方确实在不断发展，这通常以应用程序成为一个死的遗留包而告终。如果您计划发展、改进或扩展，那将是危险的。

【讨论】：

一句话，Sarbox，我们别无选择，只能限制开发者访问。
Sarbanes–Oxley Act ?这将如何迫使您限制开发人员而不是系统管理员访问权限？
它强制分离关注点，开发人员不能拥有对数据库的管理员访问权限，也不能在那里部署自己的代码。至少根据 Ernst & Young 的说法。
这是一件好事，也是一件坏事——正如 Andomar 指出的那样，它会使发布周期变慢，并且阻碍开发人员访问生产系统会使解决问题和部署变得更加困难。另一方面，强大的部署实践和更好的诊断也是一件好事。这取决于，但如果您想要 SOX，那么这种职责分离通常是基本建议。
另外，根据经验，这通常是关于遵循安永等审计师提出的建议，因此您勾选所有框并声明您的应用程序“符合 SOX 标准”。它通常不会为最终用户带来功能上的好处（尽管它应该让人相信应用程序正在以合规和安全的方式与数据和其他系统进行交互）。

【解决方案2】：

使用应用程序池的身份设置起来可能相当复杂，请考虑trust and delegation 问题。更好的选择是securing connection strings 使用加密。

【讨论】：

【解决方案3】：

如果您需要保护和审核对生产数据库的访问，那么 Windows 身份验证是比 Sql 身份验证更好的选择，原因如下：

您可以通过 NT 组和权限精确控制谁可以访问数据库，这意味着您知道谁可以访问数据库。使用 sql 身份验证的访问池仅受谁知道密码的限制。鉴于 n 个知道密码的人，跟踪谁在某个时间点做了什么会比较棘手（但并非不可能）。
只有您的系统管理员需要知道 nt 身份的密码才能访问数据库；事实上，大部分配置只需要知道用户名就可以完成
与使用 SQL Server 登录相比，可以更轻松地在域级别跟踪登录和访问。

它不会给你的是：

这种方法的问题已经在其他帖子中讨论过；特别是对于 ASP.Net 应用程序，您必须考虑是否要使用模拟/委托（网络服务器可以充当访问它的 NT 用户）或受信任用户模型（在其中配置固定身份以访问某些资源）。

这会因您使用的 IIS 版本而变得更加复杂。

【讨论】：

应用程序池不是特定于用户的，而是特定于应用程序的。应用程序仍将使用单个帐户连接到数据库。要使用最终用户凭据登录，您必须模拟最终用户。模拟的一个副作用是连接池不再起作用。
您可以为作为“受信任用户”运行的应用程序创建一个单独的应用程序池，是的，但您还可以在执行任何操作时捕获访问站点的当前用户身份。关于连接池是正确的 - 但这只是因为它现在以模拟方式为每个用户实例化并且无法共享。 SOX 通常是要确保您知道谁在做什么，谁可以做什么，并阻止他们做他们不应该做的事情；顺便说一句，在我以前的工作中，任何使用 SQL Auth 的应用程序都未能通过 SOX 验证。