本质上不是同一回事吗？优点/缺点是什么？
最佳实践如何提高SQL Server实例的安全性？
这是否仅适用于生产实例或我们的内部开发实例？
#1 楼
您在这里有几个不同的问题，所以我将把它们逐个删除：”“我读到，最好的做法是不要让用户直接使用sa登录，而要使用Windows身份验证“
您在这里混合了两件事：SA的概念，以及SQL身份验证和Windows身份验证的概念。
SQL身份验证是一个用户名和密码列表，存储在每个SQL Server中。它存储在SQL中的事实是第一个问题。如果需要更改登录名的密码，则必须在每台服务器上进行更改（或在不同的服务器上维护不同的密码）。使用Windows身份验证，您可以集中禁用登录，更改密码，设置策略等。
如果选择使用SQL身份验证，则SA只是一种SQL身份验证登录。这是默认的管理员用户名，就像Windows身份验证中的“管理员”一样。它在该实例上具有本地超级大国，但在所有实例上没有全局超级大国。无论您选择哪种身份验证方法，理想情况下都希望遵循最小特权原则：仅授予人们完成工作所需的最低限度的权利，而不再需要其他任何事情。只需登录-他们就是可以让您被炒鱿鱼的人。如果他们意外删除了数据库或禁用了备份作业，则不会被解雇，因为默认情况下，SQL不会跟踪谁做了什么。您是将要被解雇的人，因为它将要发生，而且您将无法说出是谁做的。
“最佳实践如何提高我的安全性SQL Server实例？“
您想做两件事：
阻止人们破坏服务器
当他们破坏服务器时，能够准确地确定是谁做的
第一个是通过最小特权原则完成的：只给人们所需的权限，仅此而已。
第二个通过给每个人提供自己的登录名，而不允许共享登录名来实现（例如让所有人都使用相同的用户名/密码），并且最好是审核登录信息。您可能不会马上做最后一部分，因为这很痛苦，但是让我们先进行准备，以便在有人删除数据库并且老板想知道原因之后再添加审计。
我知道您在想什么：“但是我们正在为应用程序编码，该应用程序需要登录。”是的，给应用程序提供自己的登录名，开发人员需要知道该密码，但是该登录名应被剥夺权限，以至于没有人愿意使用它。例如，它可能仅需要处于db_datareader和db_datawriter角色中，仅此而已。这样，它可以插入，更新，删除和选择数据，但不必更改架构，添加索引，更改存储过程等。
”这仅适用于生产实例或内部实例。开发实例吗？”
我认为它也同样适用于开发实例，因为我通常担心人们会破坏事情。人们只是喜欢破坏开发中的服务器。当然，当需要捆绑更改列表以迁移到生产环境时，我需要知道特定索引对于该应用程序是否确实至关重要，或者某些头脑只是运行数据库调整顾问并告诉其应用所有更改。适当的权限有助于减轻痛苦。
评论
由于链接的服务器，ntfs等，一个实例上的SA可以在所有实例上赋予上帝权利
– gbn
11年8月8日在12:08
@gbn-我不确定我会遵循。你能指出一些例子吗？我能理解您是否在谈论较差的配置（例如所有服务器共享同一服务帐户），但是当服务器在不同服务帐户下运行时，我不清楚您是如何实现的。
–布伦特·奥扎（Brent Ozar）
11年8月8日在17:33
在大型组织中，标准版本将使用相同的域帐户。即使他们不同，他们也将是同一AD组的成员（当然，可能要受地区限制），因此拥有相同的权利。我在全球大型组织（投资银行）都见过
– gbn
2011年8月8日在17:46
好的，那是另一个问题。在我所见过的大多数安全组织中，通常的做法是将每个服务器置于自己的服务帐户下。这也是我的SQL Server安装清单在线的一部分。当然，如果您忽略了这一基本的明显步骤，那么您的安全性就会降低-但是有什么意义呢？
–布伦特·奥扎（Brent Ozar）
2011年8月9日14:35
#2 楼
实际上，如果您阅读此白皮书：SQL Server职责分离白皮书它将告诉您，没有人应该在其帐户上使用sysadmin特权。应该为您的日常访问帐户提供最小访问权限，而不是显式的sysadmin权限。给定他们CONTROL SERVER实际上接近sysadmin，然后允许您在不需要它们的地方仍然拒绝/撤销访问。如果要求您满足任何IT合规性标准，则向任何人授予sysadmin权限将成为一个问题。大多数标准要求最少使用sysadmin角色。
我禁用并重命名“ sa”帐户，就像在OS上使用内置管理员帐户一样。仅在紧急情况下使用。
通常，开发人员通常可以完全使用其开发环境。然后，当他们的程序移至生产前实例时，他们的访问权限应为最小或无。就像在生产中一样。那是一个完美的世界。但是，如果您不属于这种情况，并且您的开发人员拥有的特权超出了他们所需要的权利，那么我会从他们的帐户中审核这笔费用。我会在一定程度上捕获他们所做的一切。因此，如果在生产服务器上出现问题时，您可以回头确切地了解他们的工作。
评论
+1000白皮书很棒。我从中学到了很多。
–乔恩·西格尔（Jon Seigel）
2011年8月8日23:16
#3 楼
如果您受外部法规控制或标准（SOX，PCI等）的约束，那么您审计将失败
开发人员应仅在网络SQL Server上拥有db_owner以便进行开发。
如果服务帐户是本地管理员，那么您的开发人员也可以完全控制服务器。
没有任何好处。
评论
有一个好处，那就是其他好处：便利。每个人都非常容易使用sa（可能使用“ password”作为密码），这就是为什么它继续作为一种实践。
–万事通
2015年1月20日在16:44
#4 楼
sa = sysadmin使用sa登录使用户可以执行以下所有操作：
-删除和创建数据库
-修改数据库中的对象
-删除并创建登录名
-更改密码
-删除所有数据
授予Windows帐户sysadmin特权可以完成相同的操作。
列表继续，但这应该为您提供一些充分的理由，让从未允许过非管理员使用sa。
您应该创建一个Windows或SQL帐户，并拥有获取应用程序所需的最低限度特权去工作。 （即登录，访问存储过程和视图）
#5 楼
最佳做法是输入一些强密码，然后忘记它。#6 楼
我现在有两个选择，一个为什么不应该拥有一个弱的SA帐户。如果您的SA密码弱/空，那么一个邪恶的人（将其翻译成“友好的同事”）可以：启用xp_cmdshell系统过程，并使用Sql Server服务的特权帐户，损坏您的本地信箱（创建/删除文件..）。 SA的低安全性实际上并没有说明实例设置，但是可能暗示服务用户可能会遵循不良做法（例如成为admin :-)）；
在实例上启用邮件并快速转发小型垃圾邮件有趣的脚本（可能会给您的互联网提供商或同事带来一些麻烦。..取决于邮件的发送位置;-)）；
我不会指出明显的问题它可以删除数据库，登录信息等等的事实。优点/缺点是什么？
不一定：例如-在便携式计算机上的SQL Server实例上，Windows身份验证和SQL身份验证之间的区别意味着，从理论上讲，外部攻击者只能使用SQL帐户，因为Windows身份验证不能在您自己的域帐户之外使用。用户可以在您正在喝咖啡的购物中心里扫描附近的笔记本电脑，并且可能会看到您已安装并启动了SQL实例，并可以尝试免费获得一些乐趣。并不是说它经常发生……而是可能的：-)。
最佳实践如何提高我的SQL Server实例的安全性？ ..减少了可能发生的不利影响的可能性（例如：进行体育锻炼的最佳实践将减少您像我这样的机会。.沙发土豆）否则会发生的可能性。
这仅适用于生产实例，还是我们的内部开发实例？
假设我建议至少在生产中实施安全最佳实践（经过测试并根据您环境的需求进行修改）。但是，如果在开发中您还使用生产数据（敏感..etc），则说明您必须同时更改开发实践。
评论
-1这个问题确实询问了为什么支持Windows集成身份验证并避免使用SQL Server身份验证，而根本无法完成BUT而不是“为什么不应该拥有弱的SA帐户”？
–完全安全
13年11月14日在22:01
@Fulproof：我理解您在说什么，感谢您的反馈。我对弱SA帐户的解释是公司中每个人都使用弱密码/无密码的SA帐户。但是问题很老，我不完全记得所有细节。我的头衔是主要问题-为什么允许所有人使用sa登录名是一种不好的做法？
–玛丽安
13年11月15日在9:22
#7 楼
为了解决您的最后一个问题，我们在所有开发数据库上都使用了SA帐户（密码为“ sa”！）。但是，请务必注意，我们不存储数据，我们不会生成数据。我们的数据库仅用于C / C ++应用程序的数据存储。这些开发数据库仅包含测试数据，并且经常创建，删除，修改等。\
同样重要的是，所有开发数据库都安装在开发计算机上。 （至少每个开发人员一个副本！）因此，如果某人搞砸了整个安装，那么他们只会搞砸自己，而没有一个就搞砸了。
当您想要一个需要确保您的数据库，表和数据实际上是一致且安全的，那么您需要一个不错的，可靠的SA密码。如果您不采取任何措施，那么任何人和所有人都可以完全访问您的数据，并且可以完全破坏您的数据库。仍然没有找到维持强大的SA帐户的可靠理由。
评论
例如，使用sa时，他们可以启用XP_cmdshell，然后要求将其放入产品中。正如我回答的那样，它可以在所有服务器上授予权限。 Dbo和Partial Sa（创建数据库）等：没问题
– gbn
11年8月21日在15:23
在不生成或存储客户数据的开发环境中（数据库的所有副本都是测试副本，仅用于开发和部署的环境），我看不出这确实是一个问题。如果潜在的错误代码可能会影响生产数据库，那么可以，我可以看到收紧情况。
–理查德
11年8月22日在1:28
#8 楼
任何提供的默认SQL Server系统安全性参数都应修改。建议不要使用混合模式（同时启用Windows和SQL Server身份验证）进行身份验证。相反，请仅切换到Windows身份验证-这将强制执行Windows密码策略-检查密码长度，有效期和历史记录。 Windows密码策略与SQL Server身份验证不同的功能是登录锁定-在多次连续失败的登录尝试之后，登录被锁定并且无法进一步使用，SQL Server身份验证没有提供检测暴力攻击尝试的任何方法，更糟糕的是，SQL Server甚至针对处理大量快速登录尝试进行了优化。因此，如果在特定的SQL Server系统中必须进行SQL Server身份验证，则强烈建议禁用SA登录
评论
我问这一半是规范的参考资料，因为我无法通过Google找到任何内容（可以在我没有涉及的方面进行自由编辑），而另一半则是获得弹药以说服管理层认为进行此更改是一件好事（tm）。这是给每个人一份房主钥匙副本的一种好习惯。 ;）
更不用说，“ sa”是SQL Server的公共登录名，因此使其很容易成为目标。完全没有猜测。我见过公司将名称从“ sa”更改为其他名称。即使只是很小的级别，也使网络入侵者更难掌握某些东西。
您的应用程序不需要它。请告诉我们您为什么认为他们这样做。
好问题。如果只有其他数据库专业人员停下来并问同样的问题，那么安全漏洞就会少很多。