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

Question

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

我的问题是：这种方法是否存在任何安全问题？到目前为止，从连接字符串中删除了DB凭据，我们应该/可能采用哪种更好（更简单或更简单）的方法？

Answer 1

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

1. 您可以准确控制谁可以通过NT组和权限访问数据库，这意味着您知道谁具体访问数据库。使用sql身份验证的访问池仅受谁知道密码的限制。鉴于n个人知道密码，跟踪谁在某个时间点做了什么是特别棘手的（但并非不可能）。

2. 只有您的系统管理员需要知道访问数据库的nt身份的密码;实际上，只有知道用户名

才能完成大部分配置

3. 与SQL Server登录相比，可以更轻松地在域级别跟踪登录和访问。

它不会给你的是：

1. 能够确保开发人员无法查看生产数据 - 编写应用程序的人可以轻松地包含一些诊断程序来选择数据

2. 确保生产数据仅保留在生产环境中 - 任何制作生产数据库备份的人（比如将其恢复到UAT环境进行测试）都可以轻松暴露生产数据。

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

您正在使用的IIS版本使这变得更加复杂。

Answer 2

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

但有一个警告：如果你对开发人员的限制很多，那么它将减缓他们的变化速度。由于世界其他地方确实在继续前进，这通常会随着应用程序成为一个死亡的传统包而结束。如果你计划成长，改善或扩展，这是危险的。

Answer 3

使用应用程序池的标识可能非常复杂，请考虑trust and delegation问题。 使用加密的更好选项可以是securing connection strings。