SQL Server / Windows集成安全性对任何事情都有好处吗？

Question

Windows用户权限与任何SQL Server GRANT集之间的区别似乎是不相关的概念。通常情况下，它似乎实际上是用数据库角色的伪登录实现的;但是这并没有有效地映射回Windows权限。假设单一登录身份验证，为什么不尽量使用最简单的数据库角色？

编辑：
到目前为止，我们已经获得了您不需要在应用程序中存储密码的单一好处;但这似乎更像是一个微不足道的有益结果而不是设计目标;还有很多其他更直接的方法可以实现这一目标，而不是将两个宇宙的整个安全设备紧密结合在一起。

再次编辑：
除了单一登录和SD维护组的能力之外，没有其他任何人可以提出建议，从而复制SQL Server中已存在的组（基于相同的用户登录）的功能吗？

小组问题有几个缺陷，包括假设AD经理被认为同样有资格维持两者;它排除了任何不属于AD的网络连接（从而将您锁定为MS技术。）

并且以最佳实践术语来说，你已经建立了系统的耦合，这通常被认为是一件坏事。

Answer 1

其中许多已经说过或类似于之前的答案......使用AD集成：

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

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

c）当开发人员离开我的小组时，我们不必更改所有数据库密码（即如果您关心数据安全性......）

d）根据进行更改的用户，可以轻松进行自定义日志记录。还有其他方法可以做到这一点，但我只是在懒惰。

e）与IIS身份验证集成。如果你已经在使用IE＆amp;您的Intranet的IIS，这只会让生活变得更轻松。

注意：有更多的理由不使用它，我从未在目前的位置之前使用它。这里所有内容都已在AD中排成一列......这是我用过数据库安全的最简单的时间。

Answer 2

使用集成安全性时，您的应用不需要知道任何事情或处理任何有关安全性的事情，如果用户已经登录到您的域，他们也不需要登录您的应用（假设您'我正确设置了假冒行为。）

最大的优势是必须使用AD组作为SQL Server中的登录。通过这种方式，您可以访问“帐户”组中的所有人访问一组sprocs，表等，并且“Managers”组中的每个人都可以访问不同的集合，所有这些都使用AD。您的系统管理员无需跳转到Management Studio即可授予用户对您的应用的访问权限。

Answer 3

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

使用Windows身份验证可以充分利用Windows集成安全性的强大功能，您可以根据需要添加自己的内容。这是一个已经成熟的系统，已经过数百万次的测试，让您免于承担自己的错误并在以后发现/解决它们的努力（以及客户的成本）。

然后很多人不断扫描Windows身份验证过程，检查它是否存在漏洞，探索绕过它的方法等等。当漏洞被公开披露并修复它时，您的应用程序就会“免费” “增强安全性。

在我目前的工作中，我们将AD组作为SQL登录，因此我们根据AD组的成员资格分配SQL权限。所以sys工程组的所有成员都有一些权限，DBA有其他人，普通用户，其他人，监督者等等。添加新用户或更改他们的权限是一件简单的事情，只在AD完成一次，他们立即得到他们应该在数据库中获得的权限。

发布修改：

在“重新发明轮子”上稍微扩展一下：对于AD帐户，我可以拒绝登录特定机器的权利 - 或者将其锁定在每台机器上，除了一两个。我可以阻止他们同时登录2个以上的工作站。我可以强迫他们在一段时间后更改密码，并强制执行一些最小限度的密码。还有一些其他技巧，所有这些都可以提高我系统的安全性。

对于SQL S.用户，你没有这个。我看到人们试图用复杂的SQL工作或者一种家庭酿造的守护进程来强制执行它们，我认为这是重新发明已经发明的轮子。

然后您无法阻止用户SA（或特权用户）从任何计算机登录。我曾被告知一个聪明的方法来阻止对SQL S的暴力攻击，它通过Internet打开远程登录端口 - 该网站的管理员实施了一个每半小时更改一次SA密码的工作。如果是SQL + Windows，他们可能只是说他们希望管理员只能从某些盒子登录，或者直接使用Windows身份验证，从而迫使任何人先通过VPN。

Answer 4

由于其他人都讨论过Windows身份验证的好处，我想我会扮演Devil的倡导者......

允许帐户'Joe User'访问服务器意味着不仅可以连接您的应用程序，还可以通过任何其他方式（SQL工具，Excel，恶意软件等）进行连接。

使用SQL身份验证，您的应用程序可以作为特定用户运行，然后该应用程序可以处理数据库访问。因此，当“Joe User”运行您的应用程序时，该应用程序具有SQL访问权限......但“Joe User”本身没有，这意味着上述应用程序将无法隐式访问数据库。

Answer 5

是的当然，如果您将应用程序级数据访问层作为服务运行，则可以使用集成安全性使用应用程序“服务帐户”与数据库进行通信以登录服务器...然后您不要; t必须将用户密码存储在应用程序配置文件中，并且每次与数据库建立新连接时都不会通过网络传递密码

Answer 6

集成安全性仅对Intranet应用程序非常有用。我见过的伪登录主要用于互联网Web应用程序。

无论如何，这不仅仅是在您的应用程序中存储密码，因为希望您无论如何都要腌制和散列密码。还有：

1. 用户无需登录，这是一个大问题，如果您全天都在使用Web应用程序，或者在具有多个内部Web应用程序的地方工作。

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

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

4. 访问内部Web服务时，用户模拟是一种更安全的方法。 （例如，互联网网站访问内部网web服务）

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

6. [编辑]您还了解数据库对象中的用户。因此，您可以只有一个视图返回与它们关联的行。 （除非您为每个应用程序用户创建一个新的SQLServer用户，这是不可能的，并且为每个应用程序用户创建一个新的SQLServer用户也是不合理的）

集成安全性不适合所有事情，但对于企业来说，有很多增值。

Answer 7

SQL登录：通过网络模糊的明文密码

使用NTLM进行Windows集成登录：通过线路传递哈希

使用Kerberos进行Windows集成登录：正确的安全身份验证。

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

Answer 8

根据我的经验，通过SQL身份验证连接时，大多数应用程序对数据库运行的查询响应时间明显加快。消除因不断要求AD进行安全验证而发生的延迟。

性能方面的SQL身份验证＆gt;＆gt; windows集成安全性。

Answer 9

我认为如果使用得当，集成安全性会很好。由于某些原因，我无法理解，我工作过的很多公司都没有充分利用AD，SQL权限和IIS安全模型。

如果您必须设计SQL Server权限系统，并且要求将其集成到AD中，那么您可能会想出一些非常类似的东西。 IMHO。

我喜欢将用户分组到AD组，然后使用各种权限在SQL Server中创建组登录。人们不应仅仅因为他们拥有连接数据库的工具而拥有更多的数据访问权限。无论数据如何连接，它们都应对数据具有相同的权限。

根据IIS配置的建议，访客用户（如匿名网络用户）应该位于自己的AD组中。只允许该组访问他们应该在数据库中访问的内容，有一天可以将数据从灾难中保存下来。很难读取源代码以查明数据是否受到保护，更容易调查数据库权限和安全配置。

此外，非集成安全性很糟糕，因为密码总是被分发，放入配置文件等。

Answer 10

忽略授权表/ etc方面的东西，登录方面的东西非常有用，因为你的应用程序可以使用windows身份验证连接到SQL服务器，这意味着

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

任何时候将密码放在纯文本文件中，都存在安全风险。避免这很好。

Answer 11

数据库可能具有细粒度的访问权限，每个用户都有许多不同的设置。不仅有一个用户可以访问应用程序，而且所有数据都是安全的。

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

Answer 12

集成安全性为用户访问IMO提供了更大的灵活性。例如，如果我的组织想要限制开发人员组可以访问服务器的时间，那么集成安全性是我最好的选择。

但它并不适合所有事情。

[编辑]它也非常适合记录访问。如果我必须为一个大型组织中的每个新开发人员创建一个SQL登录...它可能会停止发生并且登录会被共享，那么我就永远不会有信心指责那个丢掉一个人的傻瓜表

Answer 13

如果使用sql server身份验证，密码信息将作为明文发送到网络中。集成安全性没有这个问题。

Answer 14

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