Windows身份验证和网络服务帐户作为db_owner

Question

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

---

感谢StingyJack，

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

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

Answer 1

使用NETWORK SERVICE作为db_owner可能适用于很多环境。

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

具体风险如下：

• 在NETWORK SERVICE环境下运行的一个写得不好的应用程序可以允许未经授权访问NETWORK SERVICE可以访问的所有其他数据。您可以通过为所有应用程序创建单独的帐户来降低此风险。
• db_owner可能比应用程序真正需要的访问权限更多，这意味着如果您受到攻击，滥用/利用的可能性会更大。您可以通过选择要授予的常识权限来减少这一点。尽管如此，把它放得太远，你的回报会减少，支持也会更多。

Answer 2

是的，应用程序（及其任何用户）可能会执行dbo可以对数据库执行的任何操作。 DROP TABLE，SELECT * FROM PASSWORDS等

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

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

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

Answer 3

作为网络服务（domain \ machine $）登录数据库将非常困难（除非你是网络服务器上的服务，否则我可能不知道，但可能会有一些l 33t haxor）。

没有密码，没有密码，权利非常有限（除非是“本地系统”）。

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

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

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

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