为什么允许每个人都使用 sa 登录名是不好的做法?

Jon*_*gel 25 security sql-server

甚至 Microsoft也不鼓励使用 SQL Server 身份验证模式,但我们的应用程序需要它。

我读过最好的做法是不要让用户sa直接使用登录名,而是使用 Windows 身份验证并允许这些帐户(或帐户组)系统管理员权限。

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

Bre*_*zar 52

你在这里有几个不同的问题,所以我会单独解决它们:

“我读过最好的做法是不要让用户直接使用 sa 登录,而是使用 Windows 身份验证”

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

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

如果选择使用 SQL 身份验证,那么 SA 只是一种 SQL 身份验证登录。这是默认的管理员用户名,就像管理员在 Windows 身份验证中一样。它在一个实例上拥有本地超级大国,但在所有实例上都没有全球超级大国。

“...并允许这些帐户(或帐户组)系统管理员权限。”

无论您选择哪种身份验证方法,理想情况下您都希望遵循最小特权原则:授予人们完成工作所需的最低限度的权利,仅此而已。

不要认为他们只是登录 - 他们是可以让你被解雇的人。如果他们意外删除数据库或禁用您的备份作业,他们不会被解雇,因为默认情况下,SQL 不会跟踪谁做了什么。你是那个会被解雇的人,因为这会发生,而且你无法说出是谁干的。

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

你想做两件事:

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

第一个是用最小特权原则完成的:只给人们他们需要的权限,仅此而已。

第二个是通过为每个人提供自己的登录名来实现的,不允许共享登录名(例如让每个人使用相同的用户名/密码),理想情况下,审核登录名。你可能不会马上做最后一部分,因为这有点痛苦,但让我们先把这些部分放在适当的位置,这样你就可以在有人删除数据库并且你的老板想知道原因后添加审计。

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

“这仅适用于生产实例,还是也适用于我们的内部开发实例?”

我认为它同样适用于开发实例,因为我通常担心人们会破坏事物。人们只是喜欢在开发中破坏服务器。当然,当需要将更改列表打包以迁移到生产时,我需要知道特定索引是否真的对应用程序至关重要,或者是否某些笨蛋只是运行了 Database Tuning Advisor 并告诉它应用所有更改. 适当的权限有助于减轻这种痛苦。

  • 好吧,那是一个不同的问题。在我见过的大多数安全组织中,将每台服务器置于自己的服务帐户下是标准做法。这也是我在线 SQL Server 安装清单的一部分。当然,如果你忽略了这个基本的明显步骤,那么你的安全性就会降低——但有什么意义呢? (9认同)

小智 15

实际上,如果您阅读本白皮书:SQL Server 职责分离白皮书

它会告诉你没有人应该在他们的帐户上使用系统管理员权限。您的日常访问帐户应该被授予最低访问权限,而不是明确的系统管理员权限。给他们 CONTROL SERVER 实际上接近于 sysadmin 是什么,然后允许您在他们不需要的地方仍然拒绝/撤销访问。如果您需要满足任何 IT 合规性标准,则向任何人授予系统管理员权限就会成为一个问题。大多数标准要求最少使用 sysadmin 角色。

我禁用并重命名“sa”帐户,就像您在操作系统上使用内置管理员帐户所做的一样。只能在紧急情况下使用。

开发人员通常可以完全访问他们的开发环境。然后当他们的程序被移动到预生产实例时,他们的访问应该是最少的或没有;就像在生产中一样。那是一个完美的世界。但是,如果您不在其中,并且您的开发人员拥有比您认为他们需要的更高的特权,我会审计他们的帐户。我会在一定程度上捕捉他们所做的一切。因此,如果他们在您的生产服务器上出现问题,您可以返回并确切地找出他们做了什么。

  • +1000 那份白皮书很棒。我从中学到了很多。 (2认同)

gbn*_*gbn 8

如果您受到外部监管控制或标准(SOX、PCI 等)的约束,那么您

  • 将无法通过审核
  • 未通过您的每月 PCI 检查

开发人员应在网络 SQL Server 上拥有 db_owner 仅用于开发。

如果您的 SQL Server 都在网络上使用标准构建(即相同的服务帐户),那么 sa 合而为一地授予它们所有权限。

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

没有任何好处。


dat*_*god 6

sa = 系统管理员

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

授予 Windows 帐户 sysadmin 权限可完成相同的操作。

这个列表还在继续,但这应该给你一些很好的理由,永远不要让非管理员使用 sa。

您应该使用让应用程序运行所需的最低权限创建一个 Windows 或 SQL 帐户。(即登录、访问存储过程和视图)


gar*_*rik 5

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