使用集成安全性（SSPI）访问Web应用程序的SQL Server更好吗？

在将Web应用程序（.net）部署到生产环境时，使用集成安全性更好还是更重要？

在我看来，如果黑客破坏了Web服务器，那将不会很重要，因为他们可以轻松地模拟计算机。

有什么想法吗？

我说只有两个有效的理由使用SQL身份验证：

1. 您是从域外部进行连接，因此集成了身份验证。
2. 您正在运行TPC-C基准测试，每个周期都很重要。SQL身份验证快一点。

对于您提出的方案（Web服务器主机已完全受损），没有什么可以保护您的。黑客至少可以在DB服务器上做Web服务器可以做的所有事情。我想说，在这种情况下，纵深防御可以使您最大程度地减少损失：将Web服务器使用的帐户的数据库权限减少到绝对所需的最低限度，仅此而已。其次，请确保如果Web服务器主机受到威胁，则不能将其用于提升高于Web服务器帐户的特权（即，在WWW主机上没有其他服务使用在数据库上具有比WWW帐户更高的特权的凭据）。这些是基本的安全原则，与所使用的身份验证方案无关。

尽管sql auth与Windows auth在您的方案中都没有明显的优势，但还需要考虑其他问题：

1. 集中执行策略：您可以在一个地方设置密码策略，包括密码有效期和有效期，帐户终止等。
2. 控制模仿和信任委派。在信任委派链中使用sql auth后，所有赌注都将关闭，因为这不是真正的“委托”，因此不再受您的策略强加的限制
3. 审核：您的LSA甚至看不到sql auth，因此可以轻松绕过整个审核基础结构。您需要明确添加SQL产生的有关sql auth事件的记录，但由于事件在事件日志中具有不同的来源，提供者和架构，因此混合了苹果和橘子

最后一点：TDS协议以明文形式在流量上公开sql auth密码，但是通常可以通过请求对流量进行SSL加密来缓解这种情况。

那么，为什么您仍然看到仍然在web.config中以明文形式存储密码的sql auth WWW主机？这些是糟糕的开发人员/管理员，请不要成为其中之一。

msdn.microsoft.com/zh-CN/library/aa378326(VS.85).aspx

technet.microsoft.com/zh-CN/library/ms189067.aspx

如果不使用SSPI，则会将用户名和密码硬编码到源文件中。

如果您要将用户名和密码硬编码到源文件中，则所有员工都可以访问它。

这是相对不安全的。心怀不满的前雇员可能会恶意使用这些信息。访客可能会在屏幕上的某处看到代码。否则源代码可能会无意间泛滥成灾。

SSPI的优点是密码永远不会存储在明文的任何位置。

到目前为止，其他答案还不错，但是我将提出另一个答案：管理。

迟早，您可能最终会使用多个SQL Server。管理您的应用程序和多个SQL Server之间的SQL身份验证会有些麻烦，尤其是在遇到安全问题时。如果您一次更改Windows身份验证密码，则它会在所有服务器上立即更改。如果您需要轮换您的SQL身份验证密码，那么会更麻烦-甚至根本不做。那是安全隐患。

我不确定这里是否100％，但是我认为要点是SQL身份验证不安全，因此最好使用Windows身份验证。根据应用程序的设置方式，您还可以使用Windows身份验证将适当的凭据以加密形式存储在计算机上。我认为使用SQL身份验证确实不可能。您可以对其进行混淆，但最终必须明确。

而且，仅因为黑客可以进入服务器并不意味着游戏就结束了。黑客可能会获得对非特权进程的控制权，但不能在服务器上执行任何其他操作。因此，重要的是不要以管理员或系统身份运行所有程序，而要使用最低特权服务帐户。

最好的办法是限制如果/当他们闯入Web服务器时可以做什么。这意味着仅授予应用程序运行所需的SQL权限。授予应用程序DBO权限要容易得多，但是如果成功攻击Web服务器，则使DB更加容易受到攻击。

首先，我将假设您正在谈论内部专用网络上的内部Web服务器。

让我们从模拟机器开始。如果应用程序池标识为“网络服务”，并且.NET应用程序中没有模拟，则是，Web应用程序将使用计算机的计算机帐户连接到后端SQL Server。这意味着您已授予访问该机器帐户的权限。微软的CRM就是这样工作的。

但是，如果您指定了身份，则该用户帐户将需要访问SQL Server。没错，如果攻击者破坏了Web服务器，则它们实际上具有与身份帐户相同的访问权限，但事实是，使用SQL Server登录不会改变这里的内容。一旦获得访问权限，就可以修改Web应用程序以执行我想要做的事情，并且它将在后端SQL Server上最大限度地提高安全性。

现在，为什么要使用SSPI。首先，您没有使用基于SQL Server的登录名。这意味着Active Directory是安全性的唯一来源。这意味着您具有确定无效访问权限的常规审核方法。其次，这意味着除非有其他应用程序需要它，否则您可以使SQL Server处于仅Windows身份验证模式。这意味着不允许SQL Server登录。这意味着对sa的任何攻击都在开始之前就已停止。最后，它使恢复更加容易。如果您使用基于SQL Server的登录名，则需要提取具有SID和加密密码的登录名。如果您将基于Windows的用户帐户用作“服务帐户”，则在转到新的SQL Server时，通过创建登录名，

问题是哪个“更好”？这很难回答，因为它依赖于提问者的上下文，价值观和优先级。

就个人而言，我喜欢SQL身份验证。

• AD是运行，支持和管理服务帐户的另一件事。
• 广告需要在您的托管环境中可用。
• AD将使其难以迁移到云或混合云。
• 使用AD可以轻松地将服务帐户添加到组织中其他部分的管理员不应属于的组中。
• SSPI不会绕过加密连接字符串的问题，因为您应该在配置中加密SQL主机名。
• SQL身份验证很简单，只是文本配置，易于部署。
• 设置应用程序池标识是另一件事，它可以自动化然后在每个环境的那些自动化脚本中隐藏用户名和密码。
• 使用两个连接字符串，可以轻松使用滚动密码，因此您可以在不停机的情况下更新密码。

最后一点：您对连接管理器类进行编码以尝试每个连接字符串，这样就可以在第一个输入配置中更改密码，将更改推出，然后它将故障转移到第二个连接，然后在MSQL上更新密码并且第一个将再次使用。需要进行最后的配置更改，以将第二个密码设置为与第一个相同，以备下次使用。

如果用户不会直接（通过其他客户端工具，例如SQL Server Management Studio）直接操作数据库，则通常只为该应用程序创建一个SQL登录名，然后为其授予所需的访问权限。那时，用户在网络应用程序界面允许的范围内受到限制。