为什么允许所有人都使用sa登录名是一种不好的做法？

甚至Microsoft 都不鼓励使用SQL Server身份验证模式，但是我们的应用程序要求使用它。

我已经读到，最好的做法是不让用户sa直接使用登录名，而是使用Windows身份验证并允许这些帐户（或帐户组）具有sysadmin特权。

• 这根本不是一回事吗？优点/缺点是什么？
• 最佳实践如何提高SQL Server实例的安全性？
• 这仅适用于生产实例还是我们的内部开发实例？

您在这里有几个不同的问题，所以我将逐个列出它们：

“我已经读到，最好的做法是不让用户直接使用sa登录名，而是使用Windows身份验证”

您在这里混合了两件事：SA的概念以及SQL身份验证和Windows身份验证的概念。

SQL身份验证是存储在每个SQL Server中的用户名和密码的列表。它存储在SQL中的事实是第一个问题。如果需要更改登录名的密码，则必须在每台服务器上进行更改（或在不同的服务器上维护不同的密码）。使用Windows身份验证，您可以集中禁用登录，更改密码，设置策略等。

如果选择使用SQL身份验证，则SA只是一个SQL身份验证登录名。这是默认的管理员用户名，就像Windows身份验证中的“管理员”一样。它在一个实例上具有本地超级大国，但在所有实例上没有全局超级大国。

“ ...并允许这些帐户（或帐户组）具有sysadmin特权。”

无论选择哪种身份验证方法，理想情况下都希望遵循最小特权原则：仅授予人们完成工作所需的最低限度的权利，而不再做其他任何事情。

不要将它们视为登录名，而是可以让您被炒鱿鱼的人。如果他们意外删除了数据库或禁用了备份作业，则不会被解雇，因为默认情况下，SQL不会跟踪谁做了什么。您是会被解雇的人，因为它将要发生，而且您将无法说出是谁做的。

“最佳实践如何提高我的SQL Server实例的安全性？”

您想做两件事：

1. 阻止人们破坏服务器
2. 当他们确实破坏服务器时，能够准确地确定是谁做的

第一个是通过最小特权原则完成的：仅向人们提供所需的权限，仅此而已。

第二个是通过为每个人提供自己的登录名，不允许共享登录名（例如让每个人都使用相同的用户名/密码）以及理想地审核登录名来实现的。您可能不会马上做最后一部分，因为这很痛苦，但是让我们先进行准备，以便在有人删除数据库并且老板想知道原因之后再添加审核。

我知道您在想什么：“但是我们正在编码应用程序，并且该应用程序需要登录。” 是的，给应用程序提供自己的登录名，开发人员需要知道该密码，但是该登录名应被剥夺权限，以至于没有人愿意使用它。例如，它可能仅需要处于db_datareader和db_datawriter角色中，仅此而已。这样，它可以插入，更新，删除和选择数据，但不必更改架构，添加索引，更改存储过程等。

“这只适用于生产实例还是我们的内部开发实例？”

我认为它同样适用于开发实例，因为我通常担心人们会破坏事情。人们只是喜欢破坏开发中的服务器。当然，当需要捆绑更改列表以迁移到生产环境时，我需要知道特定索引对于应用程序是否确实至关重要，或者某些头脑只是运行数据库调整顾问并告诉其应用所有更改。适当的权限有助于减轻这种痛苦。

实际上，如果您阅读此白皮书：SQL Server职责分离白皮书

它会告诉您，没有人应该在其帐户上使用sysadmin特权。应该为您的每日访问帐户授予最小访问权限，而不是显式的sysadmin权限。给他们，CONTROL SERVER实际上接近sysadmin，然后允许您在不需要它们的地方仍然进行DENY / REVOKE访问。如果要求您满足任何IT合规性标准，则向任何人授予sysadmin权限将成为一个问题。大多数标准要求最少使用sysadmin角色。

我禁用并重命名“ sa”帐户，就像使用OS上的内置管理员帐户一样。仅用于紧急情况。

通常，开发人员可以完全访问其开发环境。然后，当他们的程序移至生产前实例时，他们的访问权限应为最小或无。就像在生产中一样。那是一个完美的世界。但是，如果您不属于这种情况，并且您的开发人员拥有比他们所需要的特权更高的特权，那么我会从他们的帐户中审计这笔费用。我会在一定程度上捕获他们所做的一切。因此，如果在生产服务器上出现问题时，您可以回头确切地了解他们的工作。

如果您受制于外部法规控制或标准（SOX，PCI等），则您

• 审核失败
• 您的每月PCI检查失败

开发人员应仅在网络SQL Server上具有db_owner以便进行开发。

如果您的SQL Server全部都在具有标准内部版本（即相同的服务帐户）的网络上，则可以对它们全部授予权限。

如果服务帐户是本地管理员，那么您的开发人员也可以完全控制服务器。

没有任何好处。

sa =系统管理员

使用sa登录可以使用户执行以下所有操作：-删除和创建数据库-修改数据库中的对象-删除和创建登录名-更改密码-删除所有数据

授予Windows帐户sysadmin特权可以完成同样的事情。

清单还在继续，但这应该为您提供一些充分的理由，让从未允许过非管理员使用sa。

您应该使用使应用程序正常运行所需的最低特权创建Windows或SQL帐户。（即登录，访问存储过程和视图）

最佳做法是输入一些强密码，然后忘记它。

我现在有两个选择，一个为什么不应该拥有一个弱的SA帐户。如果您的SA密码弱/空，那么一个邪恶的人（将其翻译为“友好的同事”）可以：

• 启用xp_cmdshell系统过程，并使用Sql Server服务帐户的特权，损坏本地盒（创建/删除文件。）。对SA的低安全性实际上并不能说明实例设置，但是可能意味着服务用户可能会遵循不良做法（例如成为admin :-)）；

• 在您的实例上启用邮件并快速转发一个小型垃圾邮件有趣的脚本（这可能会给您与Internet提供商或您的同事造成一些麻烦。..取决于邮件的发送位置;-)）；

我不会指出明显的事实，它可以删除数据库，登录名等。

• 这根本不是一回事吗？优点/缺点是什么？

• 不一定：例如-在便携式计算机上的SQL Server实例上，Windows身份验证和SQL身份验证之间的差异意味着，理论上，外部攻击者只能使用一个SQL帐户，因为Windows身份验证不能在您自己的域之外使用帐户。用户可以在您正在喝咖啡的购物中心里扫描附近的笔记本电脑，并且可能会看到您已安装并启动了SQL实例，并可以尝试免费获得一些乐趣。不是说它可能经常发生...而是一种可能性:-)。

• 最佳实践如何提高SQL Server实例的安全性？

• 当这个世界上的每一个最佳实践都在履行自己的职责时，它就会减少可能发生的不利影响的可能性（例如：进行体育锻炼的最佳实践会减少您像我这样的机会。

• 这仅适用于生产实例还是我们的内部开发实例？

• 假设我建议至少在生产中实施安全最佳实践（经过测试并根据您环境的需要进行修改）。但是，如果在开发中还使用生产数据（敏感..etc），则说明您必须同时更改开发实践。

为了解决您的最后一个问题，我们在所有开发数据库上都使用了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登录