5

那里有许多商业产品，它们为您提供基于 Windows 的安装程序，用于配置您的应用程序和后端 SQL Server DB。通常，它会询问您是否要使用 Windows 或 SQL Server 身份验证连接到数据库。他们中的大多数人建议使用 Windows Auth，然后使用分配给 db_owner 数据库角色的网络服务帐户配置您的数据库。我知道 Windows 身份验证更安全，因为您不必在 web.config 中存储凭据并在向 SQL Server 进行身份验证时通过网络发送它们，但这是生产环境的安全配置，其中网络服务帐户是数据库所有者？我们应该注意哪些具体风险？

谢谢吝啬杰克，

我听到你在说什么，不过他们必须先以网络服务用户身份登录数据库。有没有简单的方法可以做到这一点？

我真正想弄清楚的是，是否存在与分配 db_owner 角色的默认网络服务帐户这一事实相关的任何固有风险。

4

3 回答 3

3

对于很多环境来说，使用 NETWORK SERVICE 作为 db_owner 可能是可以的。

如果您想获得更高程度的安全性，只需创建一个单独的 Windows 帐户，授予它在 SQL Server 中所需的最低访问权限，然后将应用程序更改为在这个新帐户的上下文下运行。

具体风险是：

  • 在 NETWORK SERVICE 环境下运行的一个编写不佳的应用程序可能允许未经授权访问 NETWORK SERVICE 有权访问的所有其他数据。您可以通过为所有应用程序创建单独的帐户来降低这种风险。
  • db_owner 的访问权限可能比应用程序真正需要的更多，这意味着如果您受到攻击，则更有可能被滥用/利用。您可以通过选择要授予的常识性特权来大大减少这种情况。但是，如果走得太远，您将获得收益递减和更多的支持头痛。
于 2008-11-25T02:34:47.790 回答
1

是的，应用程序（以及它的任何用户）可能会执行 dbo 可以对数据库执行的任何操作。删除表、从密码中选择 * 等。

如果您设置了针对 SQL 注入的预防措施并使用适当的应用程序层安全性编写了您的应用程序，那么使用带有 dbo 的 Windows Auth 可能会没问题。

如果您正在处理非常敏感的数据，不信任应用程序（还），或者希望尽可能安全，那么您将必须在数据库层实现安全性。

例如，用户 x 可以访问表视图 a 和 b 以及视图 c，而用户 y 只能访问视图 c。您的应用程序必须以适当的用户身份连接才能访问正确的对象。

于 2008-11-17T16:04:27.583 回答
1

作为网络服务（域\机器$）登录到数据库将非常困难（我不知道，但一些 l33t haxor 可能会），除非您是网络盒上的服务。

没有密码，它不是交互式的，并且权限非常有限（除非“本地系统”）。

主要问题是SQL注入攻击。这些适用于与数据库服务器的任何连接。

拥有 db_owner 的额外风险是 DROP TABLE，甚至是 DROP DATABASE 类型的攻击。如果没有 db_owner，它仍然很危险，例如“SELECT * FROM usertable WHERE 1=1”攻击。

不幸的是，您无法选择商业或第三方应用程序来使用存储过程、最少权限等。

不过，您可以在安装后减少权限。

于 2008-11-17T20:20:46.037 回答