理想情况下，访问 SQL Server 的用户或应用程序应该使用一组正确识别他们的凭据，并且已根据需要分配了对 SQL Server 和/或数据库的适当访问级别以执行他们需要的操作去表演。

SQL 身份验证是一种遗留身份验证机制，在正确配置的环境中根本不应该启用它。 Microsoft 不建议这样做，并且从安全的角度来看，用户或应用程序的身份与身份验证上下文之间的关联非常糟糕。

解决了，您当然是正确的，应用程序不应该在服务器或域管理员帐户的上下文中访问数据库。Web 应用程序应在具有执行 Web 应用程序功能所需权限的帐户下运行（包括对其运行所需的数据库的适当访问权限），仅此而已。

归根结底，这不是 AD auth vs SQL auth 的问题，而是限制使用帐户的使用（或缺乏），或违反最小权限原则。他们没有使用 SQL 身份验证这一事实不是问题，实际上是正确的设计。另一方面，AD 帐户拥有过多特权这一事实正如您所注意到的，这是一个严重的问题，应该加以解决。

使用 SQL Server 的 Active Directory 具有许多优点，这使其成为推荐的方法。SQL DBA 通常希望仅在 Windows 集成身份验证 (WIA) 模式下使用数据库（而不是支持 SQL 身份验证的“混合模式”），因为它：

• 使用 AD 时，帐户身份验证是集中的。您对环境中存在的所有帐户有一个概览。如果帐户被盗用，您只需撤销一次：在 AD 中。使用 SQL 身份验证，您必须登录到每个 SQL Server 并将其删除。
• 使用 AD 时，密码轮换（如有必要）是集中式的。使用 SQL 身份验证，您必须登录并更改每个目标的密码（这通常意味着您不会这样做）。
• 使用 AD 时，密码存储在单个中央存储库中。使用 SQL 身份验证，它们存储在 SQL 数据库本身中。强化 AD 通常比强化 SQL Server 简单得多，因为针对 SQL Server 的攻击向量通常更大（是的，这是特定于案例的）。
• 使用 AD 时，身份验证更安全（使用 Kerberos）。这使得任何对手都更难尝试获取密码，并且更不容易受到中间人 (MITM) 攻击。与密码不同的是，Kerberos 票证不能针对其他服务重复使用：每个票证都特定于一个服务（在这种情况下，针对单个 SQL Server 服务）。针对其他服务进行身份验证需要获取新票证。
• 使用 WIA 时，管理访问 SQL Server 的帐户通常只需要授予运行时（服务）帐户（运行应用程序服务器的帐户）的权限。无需像使用 SQL 身份验证那样创建其他帐户。这也集中了影响分析：如果 IIS 服务器受到威胁，只需撤销该 IIS 服务帐户以降低风险。使用 SQL 身份验证，您需要在配置中查找该 IIS 服务器使用的 SQL 身份验证帐户。
• 使用 WIA 时，您的应用程序服务器不需要为它们的连接存储用户 ID 和密码。同样，这减少了受损系统的影响。
• 使用 WIA 时，可以禁用远程登录。这对于 SQL Authenticated 帐户是不可能的。

在授予用户访问数据库的权限时，需要考虑一些在可用性和安全性方面的优缺点。在这里，我们有两个选项用于对用户进行身份验证和授予权限。第一种是授予每个人 sa（系统管理员）帐户访问权限，然后通过保留可以根据需要授予或拒绝权限的用户列表手动限制权限。这也称为 SQL 身份验证方法。此方法存在重大安全漏洞，如下所示。第二个更好的选择是让 Active Directory (AD) 处理所有必要的身份验证和授权，也称为 Windows 身份验证。

使用 SQL 选项的主要安全问题是它违反了最小权限 (POLP) 原则，即只给用户他们需要的绝对必要的权限，而不是更多。通过使用 sa 帐户，您会出现严重的安全漏洞。违反 POLP 是因为当应用程序使用 sa 帐户时，它们可以访问整个数据库服务器。另一方面，Windows 身份验证遵循 POLP，仅授予对服务器上一个数据库的访问权限。

第二个问题是应用程序的每个实例都不需要拥有管理员密码。这意味着任何应用程序都是整个服务器的潜在攻击点。Windows 仅使用 Windows 凭据登录到 SQL Server。Windows 密码存储在存储库中，而不是 SQL 数据库实例本身，并且身份验证在 Windows 内部进行，而无需在应用程序上存储密码。

使用 SQL 方法产生的第三个安全问题涉及密码。如 Microsoft 网站和各种安全论坛上所述，SQL 方法不强制更改密码或加密，而是通过网络以明文形式发送。并且 SQL 方法在尝试失败后不会锁定，因此允许长时间尝试闯入。然而，Active Directory 使用 Kerberos 协议来加密密码，同时还采用密码更改系统并在尝试失败后锁定。

效率上也有缺点。由于您将要求用户每次想要访问数据库时都输入凭据，因此用户可能会忘记他们的凭据。

如果某个用户被删除，您将不得不从应用程序的每个实例中删除他的凭据。如果必须更新 sa 管理员密码，则必须更新 SQL 服务器的每个实例。这是耗时且不安全的，它留下了被解雇的用户保留对 SQL Server 的访问权限的可能性。使用 Windows 方法，这些问题都不会出现。一切都由 AD 集中和处理。

使用 SQL 方法的唯一优点在于它的灵活性。您可以从任何操作系统和网络访问它，甚至可以远程访问。一些较旧的遗留系统以及一些基于 Web 的应用程序可能只支持 sa 访问。

AD 方法还提供了节省时间的工具，例如组，以便更轻松地添加和删除用户，以及用户跟踪能力。

即使您设法纠正了 SQL 方法中的这些安全漏洞，您也将重新发明轮子。考虑到 Windows 身份验证提供的安全优势，包括密码策略和遵循 POLP，它是比 SQL 身份验证更好的选择。因此，强烈建议使用 Windows 身份验证选项。