没有 SQL Server Management Studio 的 SQL Server 集成安全性

Posted 2023-02-16

【中文标题】没有 SQL Server Management Studio 的 SQL Server 集成安全性

【英文标题】：SQL Server integrated security without SQL Server Management Studio

【发布时间】：2012-07-26 05:07:10

【问题描述】：

我在 ASP.net 应用程序中使用集成安全性，IIS 和 SQL Server 都托管在同一台运行 Windows Server 2008 R2 的服务器上。

是否可以允许用户通过网络访问应用程序并登录用户，但不允许他们直接或通过 SQL Server Management Studio 访问数据库？

我正在尝试保护数据库访问，因为我的应用程序将部署在客户所在地的客户服务器上。

这是我当前正在使用的连接字符串

<add connectionString="Server=.\sqlexpress;Database=DB89akwA;Integrated Security=true" name="LocalSqlServer" providerName="System.Data.SqlClient" />

<add connectionString="Server=.\sqlexpress;Database=DB89akwA;Integrated Security=true" name="MainAppConnectionString" providerName="System.Data.SqlClient" />

这是我目前使用的两个连接字符串，一个用于 ASP.net 身份验证，第二个用于我的应用程序。这两个字符串是相同的，属于同一个数据库。

有什么建议吗？

【问题讨论】：

如果用户可以访问 SQL Server 数据库，那么无论他们使用什么工具，他（或她）都可以访问它。如果他们可以访问实际的数据表以便他们可以使用您的应用程序，那么他们还可以使用 MS-Access 或 Excel 连接到同一个数据库并获取（甚至可能操作）数据

单独的 ASP.NET 连接字符串（保持集成安全性），而对于 SQL Server 连接字符串（使用用户名和密码进行身份验证）......正如我的回答中已经提到的那样。谢谢

几种方式：（1）不使用SQL Server集成安全，所以你的用户没有直接访问权限；为您的 ASP.NET 应用程序使用对 SQL Server 具有必要权限的“应用程序”用户；这可以阻止“临时”黑客，但任何系统管理员都可以看到您的 SQL 连接字符串，包括 web.config 中的用户/密码。另外：使用数据库的权限——“普通”用户只能更改“普通”表（没有系统/查找表）；使用数据库约束和参照完整性（外键）来防止无效数据

(2) 如果您真的对安全性有疑虑，请构建您的解决方案，以便任何用户只能使用存储过程访问您的数据；在这种情况下，数据库上的任何用户只需要执行存储过程的权限 - 他直接对表没有权限，因此他无法对这些表执行任何操作。但是，如果您从一开始就没有这样做，这需要进行大规模的重新架构

【参考方案1】：

不可能“保护”在客户场所运行的数据库。客户端的工作人员可以从 ASP.Net 连接字符串中获取密码。域管理员可以始终获得对数据库的访问权限（有一篇实际的 MSDN 文章描述了该过程：Connect to SQL Server When System Administrators Are Locked Out）。

如果您想隐藏您认为数据库具有的知识产权，那么您唯一的解决方案是不在客户端部署数据库（例如使用 SQL Azure 等托管数据库）。

如果您只是想防止客户端干扰数据库，您可以在合同中规定。审计和检测干扰是可能的。

【讨论】：

感谢您的回答，该产品是定制的ERP系统，不仅仅是知识产权，我担心数据处理不当和未经授权的访问。在客户的组织中，人们共享密码是很常见的。我知道我可以解释他们不要做和其他合同条款，但只是想通过单独的用户凭据限制该访问来提高工作效率，而不是由员工中的其他人使用。 :(

您当然可以提高标准。你知道，锁不能阻止小偷，它们可以让人们诚实。查看Logon triggers，您可以编写一个简单地拒绝SSMS 访问的触发器，请参阅this example。当然安装Audit 并宣传它的存在，这将阻止大多数未经授权的访问尝试。

是的，我想我同意你的观点，因为@Athar 提出了一个替代方案，但根据我目前的设置，它不会起作用。所以我标记了你的答案，因为它直接回复了我的查询，而且 Athar 也很有帮助。

【参考方案2】：

是的，这是完全可能的。使用集成安全性登录到 ASP.NET 的人员无法使用相同的凭据登录到 SQL Server。两者完全断开。仅当 SQL Server 已设置为允许他们访问时才有可能。

我的建议是创建 SQL 登录名和用户，并且只允许他们访问 SQL Server。在你的应用程序中，当你创建连接字符串时，不要将集成安全设置为true，只让用户输入他的Sql用户名和密码来访问数据库。

【讨论】：

如果该人的凭据用于登录 SQL Server - 您如何防止他们使用其凭据访问 SQL Server（这显然允许他们连接到 SQL Server），例如MS-Access？

这就是我所说的，只有在 SQL Server 已设置为允许他们访问时才有可能。仔细阅读我的评论

但这正是 OP 在说什么，不是吗？他正在使用集成安全性（这意味着运行他的应用程序的用户也可以使用他们的 Windows 身份连接到 SQL Server）——如果他真的这样做了，那么没有办法阻止这些用户从使用 MS-Access 连接到 SQL Server ...

@AtharAnis 感谢 Athar，但正如 marc_s 所说，我问的是 SQL Server 集成安全性。但可以根据您的回答说，这让我想到了一个积极的选择，我可以使用凭据运行 SQL Server，即用户名和密码以及 ASP.Net 在集成安全模式下吗？我必须将 SQL Server 迁移到另一台机器吗？任何帮助或链接表示赞赏。

不，您不需要将 SQL 迁移到另一台机器 @Thr3e ，您可以将两者保持在同一台机器上。将 SQL 从 ASP.NET 中分离出来以提高安全性是一种很好的做法。特别是在像您客户的环境这样的环境中，这种方法是不可避免的。必须采用这种方法来增加另一层安全性。