甚至微软也不鼓励使用 SQL Server 身份验证模式，但我们的应用程序需要它。
我读过最好不要让用户sa直接使用登录名，而是使用 Windows 身份验证并允许这些帐户（或帐户组）系统管理员权限。
- 这本质上不是一样的吗？有什么优点/缺点？
- 最佳实践如何提高我的 SQL Server 实例的安全性？
- 这是否仅适用于生产实例，或者也适用于我们的内部开发实例？
AskOverflow.Dev
您在这里有几个不同的问题，所以我将逐个解决：
“我读过最好不要让用户直接使用 sa 登录，而是使用 Windows 身份验证”
您在这里混合了两件事：SA 的概念，以及 SQL 身份验证和 Windows 身份验证的概念。
SQL 身份验证是存储在每个 SQL Server 中的用户名和密码列表。它存储在 SQL 中的事实是第一个问题。如果您需要更改登录密码，您必须在每台服务器上更改它（或在不同的服务器上维护不同的密码）。使用 Windows 身份验证，您可以集中禁用登录、更改密码、设置策略等。
如果选择使用 SQL 身份验证，那么 SA 只是一种 SQL 身份验证登录。这是默认的管理员用户名，就像管理员在 Windows 身份验证中一样。它在一个实例上具有本地超级大国，但在所有实例上都没有全球超级大国。
“......并允许这些帐户（或帐户组）系统管理员权限。”
无论您选择哪种身份验证方法，理想情况下，您都希望遵循最小特权原则：授予人们完成工作所需的最低限度的权利，仅此而已。
不要认为他们只是登录 - 他们是可以让你被解雇的人。如果他们意外删除了数据库或禁用了您的备份作业，他们不会被解雇，因为默认情况下，SQL 不会跟踪谁做了什么。你是那个会被解雇的人，因为它会发生，你不能说是谁干的。
“最佳实践如何提高我的 SQL Server 实例的安全性？”
你想做两件事：
第一个是通过最小权限原则完成的：只给人们他们需要的权限，仅此而已。
第二个是通过给每个人自己的登录名来完成的，不允许共享登录名（比如让每个人都使用相同的用户名/密码），理想情况下，审核登录名。您可能不会立即执行最后一部分，因为这有点痛苦，但是让我们先把这些部分放在适当的位置，这样您就可以在有人删除数据库并且您的老板想知道原因之后添加审计。
我知道你在想什么：“但我们正在编写应用程序，而该应用程序需要登录。” 是的，为应用程序提供自己的登录名，开发人员需要知道该密码，但该登录名应该被剥夺权限，以至于没有人愿意使用它。例如，它可能需要单独在 db_datareader 和 db_datawriter 角色中，仅此而已。这样它就可以插入、更新、删除和选择数据，但不一定要更改模式、添加索引、更改存储过程等。
“这是否仅适用于生产实例，或者也适用于我们的内部开发实例？”
我认为它同样适用于开发实例，因为我通常担心人们会破坏事物。人们只是喜欢在开发中破坏服务器。当然，当需要捆绑更改列表以迁移到生产环境时，我需要知道特定索引是否真的对应用程序至关重要，或者是否某些傻瓜只是运行了数据库优化顾问并告诉它应用所有更改. 适当的权限有助于减轻这种痛苦。
实际上，如果您阅读此白皮书：SQL Server 职责分离白皮书
它会告诉你没有人应该在他们的帐户上使用系统管理员权限。您的日常访问帐户应获得最低访问权限，而不是明确的系统管理员权限。鉴于他们，控制服务器实际上接近于系统管理员，然后允许您在他们不需要的地方仍然拒绝/撤销访问。如果您需要满足任何 IT 合规性标准，那么向任何人授予系统管理员权限就会成为一个问题。大多数标准要求最少使用 sysadmin 角色。
我禁用并重命名“sa”帐户，就像您使用操作系统上的内置管理员帐户一样。只能在紧急情况下使用。
开发人员通常可以完全访问他们的开发环境。然后，当他们的程序转移到预生产实例时，他们的访问权限应该是最小的或没有；就像它在生产中一样。那是一个完美的世界。但是，如果您不在其中，并且您的开发人员拥有比您认为他们需要的更高的特权，我会审核他们的帐户。我会在一定程度上捕捉到他们所做的一切和任何事情。因此，如果他们在您的生产服务器上出现问题，您可以返回并准确了解他们做了什么。
如果您受到外部监管控制或标准（SOX、PCI 等）的约束，那么您
开发人员应该在网络 SQL Server 上拥有 db_owner，仅用于开发。
如果您的 SQL Server 都使用标准构建（即相同的服务帐户）在网络上，那么 sa in one 将授予它们所有权限。
如果服务帐户是本地管理员，那么您的开发人员也可以完全控制服务器。
没有任何好处。
sa = 系统管理员
使用 sa 登录使用户能够执行以下所有操作： - 删除和创建数据库 - 修改数据库中的对象 - 删除和创建登录名 - 更改密码 - 删除所有数据
授予 Windows 帐户 sysadmin 权限可以完成同样的事情。
清单还在继续，但这应该给你一些很好的理由，让你永远不要让非管理员使用 sa。
您应该创建一个具有使应用程序运行所需的最低权限的 Windows 或 SQL 帐户。（即登录、访问存储过程和视图）
最好的做法是输入一些强密码并忘记它。
我现在有两个选择，为什么不应该有一个弱 SA 帐户。如果您的 SA 密码较弱/为空，则一个邪恶的人（将其翻译为“友好的同事”）可以：
启用 xp_cmdshell 系统过程，并使用 Sql Server 服务帐户的权限，损坏您的本地机器（创建/删除文件..）。SA 的低安全性实际上并不能说明实例设置，但可能意味着服务用户可能会遵循不良做法（例如成为管理员 :-)）；
在您的实例上启用邮件并快速转发一个小的垃圾邮件有趣脚本（这可能会给您的互联网提供商或您的同事带来一些麻烦......取决于邮件的去向;-)）；
我不会指出它可以删除数据库、登录...等的明显事实。
不一定：例如 - 在笔记本电脑的 SQL Server 实例上，Windows 身份验证和 SQL 身份验证之间的区别意味着，理论上，外部攻击者只能使用 SQL 帐户，因为 Windows 身份验证不能在您自己的域之外使用帐户。用户可以从您正在喝咖啡的商场扫描邻居的笔记本电脑，并且可能会看到您安装并启动了一个 SQL 实例，并且可以尝试免费获得一些乐趣。并不是说它会经常发生……而是有可能:-)。
最佳实践如何提高我的 SQL Server 实例的安全性？
正如这个世界上的每一个最佳实践都在发挥作用..减少了可能发生的不利影响（例如：进行体育锻炼的最佳实践将减少您像我一样的机会..沙发土豆），否则可能会发生。
这是否仅适用于生产实例，或者也适用于我们的内部开发实例？
解决您的最后一个问题，我们在所有开发数据库中使用 SA 帐户（密码为“sa”！）
但是，重要的是要注意我们不存储数据，也不生成数据。我们的数据库仅用于 C/C++ 应用程序的数据存储。这些开发数据库纯粹包含测试数据，并且经常被创建、删除、修改等。\
此外，同样重要的是，所有开发数据库都安装在开发机器上。（至少每个开发人员一份！）因此，如果有人搞砸了整个安装，他们只是搞砸了自己，没有其他人搞砸了。
当涉及到您想要确保您的数据库、表和数据实际上是一致和安全的环境时，您需要一个好的、可靠的 SA 密码。如果你让这个弱点，那么任何人和每个人都可以完全访问你的数据，并且可以完全破坏你的数据库。
对于一群拥有自己的纯粹包含测试数据的数据库副本的开发人员来说，我仍然没有找到一个可靠的论据来维护一个强大的 SA 帐户。
应修改任何提供的默认 SQL Server 系统安全参数。建议不要使用混合模式（同时启用 Windows 和 SQL Server 身份验证）进行身份验证。相反，只切换到 Windows 身份验证 - 这将强制执行 Windows 密码策略 - 检查密码长度、有效期和历史记录。Windows 密码策略与 SQL Server 身份验证不同的特点是登录锁定 - 在多次连续失败的登录尝试后，登录被锁定并且无法进一步使用
另一方面，SQL Server 身份验证没有提供任何检测暴力攻击尝试的方法，更糟糕的是，SQL Server 甚至针对处理大量快速登录尝试进行了优化。因此，如果在特定 SQL Server 系统中必须进行 SQL Server 身份验证，强烈建议禁用 SA 登录