为什么应用程序不应该使用 sa 帐户

Question

我的第一个问题，请温柔点。我知道 sa 帐户可以完全控制 SQL Server 和所有数据库、用户、权限等。

我绝对相信应用程序不应该在没有完善的、以商务人士为中心的理由的情况下使用 sa 密码。这个问题的答案包括我对以 IT 为重点的讨论的很多推理

我被迫接受一个新的服务管理系统，除非它使用 sa 密码，否则它将无法工作。我从来没有时间弄清楚为什么在设置评估时，服务器团队试图安装它以使用我设置的固定角色，其中包含 db_creater 和我认为需要的其他权限。哪个失败了。然后我让服务器团队使用 sa 帐户安装，但在其数据库的 dbo 角色帐户下运行，但也失败了。脾气暴躁，我试图让它以 sysadmin 角色的帐户运行，但即便如此也失败了，并且没有有用的错误消息，使我能够在不花费比可用时间更多的时间的情况下弄清楚发生了什么。它仅适用于 sa 帐户和以明文形式存储在配置文件中的密码。

当我询问这个​​问题并且服务器团队与供应商交谈时，他们得到了令人担忧的答案：“这有什么问题？” 然后'好吧，我们可以看看加扰密码'加扰ffs

我知道有一些方法可以限制对文件的访问，但我认为这只是安全性的另一个弱点

无论如何，我的问题是，有人可以向我指出一些文档，我可以用它向企业解释为什么这是一件坏事并且应该是一个很大的不。我在一个领域工作，这意味着我需要认真对待安全问题，并且一直在努力让业务理解，最终可能会被超越，但我需要尝试。

Answer 1

这取决于您的业务，但在大多数情况下，最重要的是确保它不被视为 IT 问题。这是一个安全问题，虽然两者大量重叠，但如果您说“安全”而不是“抱怨一般 IT 内容”，那么业务人员更有可能倾听。

您是否与任何有安全要求的客户合作？这是一个很好的起点。如果我们运行具有 sa 级别访问权限的应用程序，或者即使不使用特权访问也无法正确保护其凭据的应用程序（我们强烈建议 Windows 集成，而不是尽可能存储用户/密码），并且我们受到安全保护审计，该审计将失败，我们将面临失去客户和/或不得不向我们集团的客户退款的风险（就我主要从事的产品而言，银行组织，集团的其他部分与警察和卫生部门打交道当局等）安全性是我们提供适合目的的一部分。业务人员会理解这种潜在威胁的严重性，即使他们通常只对 IT 建议付出口头上的代价。

即使忽略客户强加的要求，如果您努力满足各种行业标准安全标准，那么这种应用程序身份验证在审核时也会使您失败，因为它离最佳实践还很远，通常被认为是在“根本不应该做”的清单上。向您的业务决策者明确，安全性是应用程序的重要组成部分，而该供应商似乎没有意识到（或至少没有适当关注）这一事实使您怀疑他们可能无法做到的其他事情处理：了解数据库安全最佳实践是（嗯，应该是）他们工作的一部分，实施它并不困难。

还要指出您（购买者）应该向供应商规定合理的安全要求，而不是相反。这是您的数据，因此他们没有资格说明什么被认为足够安全。

Answer 2

没有应用程序需要具有 SA 访问权限 - 永远。（除非它的唯一目的是某种数据库管理。）

一般规则是永远不要向任何登录（应用程序或个人）授予比业务要求的登录权限更多的权限。

没有应用程序是完全安全的。大多数都有某种 SQL 注入或 XSS 漏洞。如果入侵者开始执行他/她选择的声明并具有“SA”访问权限，那么您的数据可能会发生很多事情，这些事情可能会立即杀死业务。（特别是如果数据需要被信任，因为它被执法部门使用。）询问利益相关者，如果有人能够故意更改甚至单个记录并且该信息被泄露，他们将不得不做什么。

现在，通过“SA”访问，不仅可以更改应用程序的数据库，还可以更改系统上的所有其他数据库。所以，问问你的利益相关者，如果你复制你所有的数据库并将其发送给报纸，他们会怎么做。因为如果心怀不满的员工发现存在此安全漏洞，则可能会发生这种情况。

供应商说他们可以打乱密码。那是BS。应用程序需要以明文形式访问密码才能使用它，因此解密密码的密钥将被存储在密码旁边。此外，如前所述，真正的问题不是有人找到了这个密码；正是通过漏洞（错误）使用此系统的人将获得对所有数据库的完全访问权限，而无需看到密码。

需要 SA 的最可能原因是应用程序需要与 SQL 代理交互。至少这是正确实现的更难的功能之一，大多数人只是采取“使用 SA”的路线来绕过它。要求“SA”本身可能是由于供应商不知道如何检查系统管理员权限。

您可以尝试两种解决方案：

1. 重命名 SA（无论如何都是安全最佳实践）并创建一个名为“SA”的具有受限权限的新帐户。（从未尝试过，但它应该可以工作）

2. 不要安装软件。您作为专业人士无法承担该操作的责任，因此您不应安装它。为了给您一个比较，请水管工将燃气管线直接穿过壁炉而不是在壁炉周围运行，以节省一些管道/金钱。你可能会嘲笑这张图片，但我相信这是一个恰当的比较——这个软件迟早会爆炸，可能更早。当它发生时，它也可能会使业务下降。

如果这一切都不能阻止“他们”需要这个软件，我能给你的最后一个建议就是运行。如果数据发生问题，您将首先承担责任。所以，有了这个应用程序，你可能没有任何工作保障，所以找一个至少给你一些的雇主。

Answer 3

我看到两行攻击这个。

• 合规。您的商店是否有任何有效的强制合规标准？仔细搜索其措辞，看看您是否发现任何与应用程序“要求”不兼容的内容。如果您发现任何阻止sa应用程序使用的东西，您就有一个防弹防水外壳，因为该应用程序会使您的企业承担责任等。

• 用户管理访问。确保您清楚地说明需要sa访问的应用程序实际上可以sa访问所有在安装该应用程序的工作站上具有管理员权限的企业用户。无法向sa运行应用程序的本地管理员隐藏密码，这是事实，再多的“加扰”也无法阻止这一点。如果本地管理员愿意，没有本地管理员无法访问的本地信任根。明确表示拥有一个需要的应用程序sa等同于sa为所有运行该应用程序的用户提供特权。解释这意味着什么，用户可以有效地做什么：

  • 能够读取服务器中的任何数据，不仅可以从该应用程序中读取数据，还可以从该服务器上托管的任何其他数据库中读取数据
  • 能够修改服务器上的任何数据，同样来自同一服务器上的任何其他数据库
  • 能够在修改后擦除他的任何行为痕迹
  • 能够更改任何审计和历史记录，使某些操作看起来是由不同的用户完成的
  • 能够使用 SQL Server 凭据升级对信任该服务器的任何其他资源的攻击。这可能意味着任何其他 SQL Server 以及其他资源，包括但不限于文件共享、Exchange 服务器等，因为 SQL Server 可以用作垫脚石。

向决策者明确表示，接受此应用程序意味着将所有对运行该应用程序的工作站具有管理员访问权限的员工都委托给上述所有权限。供应商将尝试通过调用某种或其他“加密”sa应用程序的密码来捍卫其立场。这不成立。没有任何加密方案可以抵御管理员的攻击。并明确指出，查找本地“隐藏”密码所需的技术技能完全无关紧要。员工不会自己做，他们中的一个人会用谷歌搜索并发现易于使用的脚本。

Answer 4

一、sa密码明文存储？你应该用你的钱包投票。谁认为这是可以接受的，就需要停业。

下面是一个可以帮助您解释问题的类比：员工 Alice 需要进入一楼。你给她的是整栋楼的万能钥匙还是一楼的钥匙？答案：你只给她一楼的钥匙。为什么？因为它减少了意外或故意损坏的机会。如果爱丽丝一开始就不能到二楼机房，那她就永远不会在那里做坏事。

这就是最小特权原则。

至于为什么应用程序需要使用 sa 帐户，这是一个 PerfMon 或扩展事件应该能够回答的问题。使用 T-SQL 模板创建 PerfMon 跟踪，可能按应用程序名称过滤。

在我的脑海里，还有另一个反对使用 sa 的论点：使用 sa 帐户要求 SQL Server 服务处于混合身份验证模式。仅 WINdows 身份验证更好，因为我们可以利用 Kerberos 的所有安全功能。