SQL Server/Windows集成安全性是否适用于任何情况?

其中许多都已经说过或与以前的答案相似…与AD集成:

a)我不必担心有权访问任何给定应用程序的用户,我可以将其传递给安全人员。

b)我可以根据已经存在的组逐表限制访问,并强制标准用户只能调用存储过程。

c)当开发人员离开我的团队时,我们不必更改所有数据库密码(即,如果您关心数据安全…)

d)很容易根据做出更改的用户进行自定义日志记录。还有其他方法可以做到这一点,但我只想懒惰。

e)与IIS身份验证集成。如果您已经在Intranet上使用IE&II,这只会让您的生活轻松许多。

注:不使用它的理由多得多,在我现在的职位之前,我从未使用过它。这里所有的东西都已经排在广告里了…这是我在数据库安全方面最简单的一次。

当使用集成安全性时,您的应用程序不需要知道任何有关安全性的信息或处理任何有关安全性的信息,而且,如果用户已经登录到您的域,他们也不需要登录到您的应用程序(假设您已正确设置了模拟)。

最大的好处是在SQL Server中使用一个AD组作为登录名。通过这种方式,您可以让“帐户”组中的每个人访问一组存储过程、表等,“管理者”组中的每个人都可以使用AD访问另一组。您的系统管理员不必跳到Management Studio来授予用户访问您的应用程序的权限。

我想基本上可以归结为“不重新发明轮子”,并利用“多眼”效应。

使用Windows身份验证,您可以利用Windows集成安全性的强大功能,如果愿意,您还可以在此基础上添加自己的内容。这是一个已经成熟的系统,已经测试了数百万次,省去了你犯错误和以后发现/解决错误的努力(以及你的客户的成本)。

然后,许多人不断地扫描Windows身份验证过程,检查它是否存在漏洞,探索绕过它的方法等。当一个漏洞被公开披露并为其创建修复程序时,您的应用程序刚刚获得了“免费”的安全增强。

在我目前的工作中,我们将AD组作为SQL登录,因此我们将基于成员资格向AD组分配SQL权限。因此,系统工程组的所有成员都有一些权限,DBA有其他的、普通的用户、其他的、主管等。添加新用户或更改他们的权限是一件简单的事情,在AD上只做一次,他们会立即获得他们应该在数据库中获得的权限。

后编辑 :

在“重新发明轮子”上扩展一点:对于一个广告帐户,我可以拒绝登录特定机器的权利——或者将其锁定在普通机器之外,节省一两个。我可以阻止他们同时登录两个以上的工作站。我可以强迫他们在一段时间后更改密码,再加上在密码中施加一些最小的强度。还有其他一些技巧,所有这些都可以提高系统的安全性。

有了SQL S.用户,您就什么都没有了。我见过有人试图用复杂的SQL作业或一种家庭brewn守护进程来强制执行它们,在我看来,这是在重塑一个已经发明的轮子。

然后您就不能停止用户sa(或特权用户)从任何计算机登录。有人告诉我一个聪明的方法来阻止针对SQL的暴力攻击。它的远程登录端口在Internet上打开-该站点的管理员执行了一项每半小时更改SA密码的工作。如果是SQL+Windows,他们可能会简单地说,他们希望管理员只从某个框中登录,或者直接使用Windows身份验证,从而迫使任何人先通过VPN。

既然其他人都讨论过Windows身份验证的好处,我想我会扮演魔鬼的拥护者…

允许帐户“joe user”访问服务器意味着不仅可以与您的应用程序连接,而且还可以通过任何其他方式(SQL工具、Excel、恶意软件等)进行连接。

通过SQL认证,您的应用程序可以作为特定用户运行,然后应用程序可以处理数据库访问。所以当“joe user”运行应用程序时,该应用程序具有SQL访问权限…但是“Joe用户”自己没有,这意味着前面提到的应用程序无法隐式访问数据库。

是的,当然,如果您的应用程序级数据访问层作为服务运行,那么您可以使用集成安全性与数据库进行对话,使用应用程序“服务帐户”登录到服务器…然后,您就不必将用户密码存储在应用程序配置文件中,也不必在与数据库建立的每个新连接中通过网络传递密码。

集成的安全性只对内部网应用程序有用。我看到的伪登录主要是针对Internet Web应用程序的。

不管怎样,这不仅仅是在你的应用程序中存储一个密码,因为希望你无论如何都可以对你的密码进行加盐和散列。还有:

1. 用户不必登录,这是一个大问题,如果你一整天都在一个独立的webapp,或者在一个有多个内部webapp的地方工作。

2. 用户管理是免费的,因为IT管理员只需要在Active Directory中编辑用户。

3. 用户名和角色名称在整个组织中是一致的。

4. 用户模拟是访问内部WebService时更安全的方法。(例如,Internet网站访问Intranet Web服务)

5. Web应用程序不需要对数据库做任何额外的用户授权,因为它是无缝处理的。

6. [编辑]您还知道数据库对象中的用户。因此,您可以让视图只返回与它们相关联的行。(除非为每个应用程序用户创建一个新的sqlserver用户,否则这是不可能的,并且为每个应用程序用户创建一个新的sqlserver用户也是不合理的)

集成安全并非适用于所有内容,但对于企业来说,它有很多附加值。

SQL登录:通过网络混淆明文密码

Windows与NTLM集成的登录:通过网络传递的哈希

与kerberos集成的Windows登录:正确的安全身份验证。

如果你关心安全,只有一个选择。

根据我的经验,当通过SQL身份验证连接时,针对大多数应用程序中的数据库运行的查询的响应时间明显更快。消除了持续请求AD进行安全验证时出现的延迟。

性能方面的SQL身份验证>>Windows集成安全性。

不考虑授权表/etc方面的内容,登录方面的内容非常有用,因为您的应用程序可以使用Windows身份验证连接到SQL Server,这意味着

您不必将数据库用户名和密码放在应用程序的某个文件中

任何时候在纯文本文件中输入密码,都存在安全风险。避免那样很好。

数据库可能有一个细粒度的访问,每个用户有许多不同的设置。这不仅是一个场景,其中您有一个用户可以访问应用程序,这就是所有数据安全性。

如果我们谈论的是团队开发,那么可能会有用户组授予对数据库的开发访问权。这个组中的每个用户都将是您的内部域的成员,并且拥有自己的密码,数据库管理员不应该管理这些密码,甚至知道这些密码允许访问数据库。

我认为如果使用得当,集成的安全性是好的。由于某些原因,我无法理解,我工作过的许多公司都不太使用AD、SQL权限和IIS安全模型。

如果您必须设计SQL Server权限系统,并且关键要求将其集成到AD中,那么您可能会想出非常相似的方法。恕我直言。

我喜欢将用户分组为广告组,然后在具有各种权限的SQL Server中创建组登录。人们不应该仅仅因为有工具连接到数据库就有更多的数据访问权。不管它们如何连接,它们对数据都应该具有相同的权限。

根据有关IIS配置的建议,来宾用户(如匿名Web用户)应该在自己的广告组中。如果只允许这个组访问数据库中他们应该访问的内容,有一天就可以保存灾难中的数据。很难读取源代码来确定数据是否受保护,更容易调查数据库权限和安全配置。

此外,非集成安全性也很差,因为密码总是被分发、放入配置文件等。

集成安全在用户访问IMO方面提供了更大的灵活性。例如,如果我的组织希望限制开发人员组访问服务器的时间,集成安全是我的最佳选择。

但这不适合所有的事情。

[编辑]同时,它也非常适合日志记录访问。如果我必须为一个大型组织中的每个新开发人员创建一个SQL登录……它可能会停止,并且登录信息会被共享,那么我就永远不会有信心将手指指向掉了一张表的指头。

如果使用SQL Server身份验证,密码信息将以明文形式通过网络发送,这一事实如何?集成安全没有这个问题。

对于将在广告环境中运行的企业应用程序,使用Windows集成安全性绝对是正确的方法。您不希望已经在环境中通过身份验证的用户仅为您的应用程序管理一组单独的凭据。注意我们正在谈论的 认证 …对于 授权 您仍将使用SQL Server的基于角色的安全性。