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

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

我绝对相信，没有完善的，以业务人员为中心的原因，应用程序不应使用sa密码。这个问题的答案包括我针对IT讨论的很多理由

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

当我对此进行查询时，服务器团队与供应商进行了交谈，他们得到了一个令人担忧的答案：“这是什么问题？” 然后“好吧，我们可以看看加扰密码”

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

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

这取决于您的业务，但是在大多数情况下，最主要的是确保它不被视为IT问题。这是一个安全性问题，尽管您两个人在很大程度上重叠在一起，但如果您说“安全性”，您会比“只是为一般的IT内容抱怨”更容易听。

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

即使不理会客户提出的要求，如果您努力满足各种行业标准的安全标准，那么这种应用程序身份验证将再次面临审核失败的风险，因为这与最佳实践相去甚远，因此通常被认为是在“根本不应该做”列表上。向您的业务决策者清楚，安全性是应用程序的重要组成部分，并且该供应商似乎没有意识到（或至少适当关注），这一事实使您对他们可能还无法做到的事情感到怀疑。处理：了解数据库安全性最佳实践是（当然应该）工作的一部分，并且实施它并不困难。

还要指出，您（购买者）应向卖方指定合理的安全要求，而不是相反。这是您的数据，因此他们没有资格声明足够安全的内容。

从来没有应用程序需要具有SA访问。（除非其唯一目的是某种数据库管理。）

通常的规则是，永远不要授予任何登录（应用程序或个人登录）权限超过企业要求的登录权限。

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

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

供应商说他们可以加密码。那是BS。应用程序需要以明文形式访问密码才能使用，因此解密密码的密钥将在解密密码的旁边存储。另外，如前所述，真正的问题不是有人找到了该密码；这是因为通过一个漏洞使用此系统的人（滥用）将拥有对您所有数据库的完全访问权限，而从未看到密码。

需要SA的最可能原因是应用程序需要与SQL Agent进行交互。至少这是实现权利的较难功能之一，大多数人只是采用“使用SA”路线来解决它。需要“ SA”本身可能是由于供应商不知道如何检查sysadmin权限。

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

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

2. 不要安装软件。您作为专业人士不能承担该操作的责任，因此您不应安装它。为了给您一个比较，请水管工让煤气管线直接穿过壁炉而不是穿过壁炉，以节省一些管道/金钱。您可能会在笑这个图像，但我相信这是一个适当的比较-该软件迟早会吹散，可能会更快。而当它这样做的时候，它也可能使公司倒闭。

如果这一切都不能阻止“他们”需要此软件，那么我可以给您的最后一个建议是运行。如果数据发生问题，您将成为第一个负责任的人。因此，使用此应用程序后，您可能没有任何工作保障，因此请找到至少给您一些工作的雇主。

我看到两行攻击。

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

• 用户管理员访问权限。确保清楚地说明了需要sa访问的应用程序实际上可以授予sa在安装该应用程序的工作站上具有管理员权限的所有公司用户访问的情况。没有办法向sa运行应用程序的本地管理员隐藏密码，这是事实，并且没有任何“加扰”措施可以防止这种情况。如果他愿意，没有本地管理员无法获得的本地信任根。明确指出，拥有需要的应用程序sa等同于向sa运行该应用程序的所有用户授予特权。说明这意味着什么，用户可以有效地做什么：

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

向决策者明确表明，接受此应用程序意味着要向具有管理员访问权限的每个员工提供运行上述应用程序的所有特权。供应商将尝试通过调用某种“加密” sa应用程序密码的方式来捍卫自己的立场。这不容纳水。没有可以抵抗管理员攻击的加密方案。并明确指出，找到本地“隐藏”密码所需的技术技能完全不相关。员工们不会自己做，他们中的一个会用谷歌搜索它并发现易于使用的脚本来完成它。

首先，sa密码存储明文吗？您应该用钱包投票。认为可以接受的人必须倒闭。

这是一种可以帮助您解释问题的方法：员工Alice需要访问第一层。您是给她整个建筑物的主钥匙还是仅仅是一楼的钥匙？答：您只给她一楼的钥匙。为什么？因为它减少了意外或故意损坏的机会。如果爱丽丝不能首先到达第二层的服务器室，那么她将永远不会在那做任何坏事。

这是最低特权原则。

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

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

从技术角度来看，应用程序没有理由需要SA权限。可能发生的情况是，应用程序的开发人员可能会检查其登录名是否具有sysadmin权限，如果没有，则仅引发错误消息。这样，他们可以声称该应用程序需要SA权限。

如果您必须拥有此应用程序，则可以在没有其他任何东西的单独实例上运行它。

也许您的供应商正在请求/请求“ sa”，因为他们在其应用程序中的某个地方正在使用XP_CMDSHELL。（不要让我开始对XP_CMDSHELL的无限制访问可能造成的损害。可以说这不仅可能打开您的数据，还可能打开主机，还可能打开网络上的任何其他内容，以便像管理员一样进行访问）

如果有合法需要，您可以通过代理帐户授予受限访问权限。参见例如BOL：http : //msdn.microsoft.com/en-us/library/ms175046.aspx

任何应用都不应要求SA帐户和密码才能运行。

但是，我已经安装了IT服务管理产品，在安装过程中，您可以选择提供SA帐户凭据，以允许安装程序创建数据库并将帐户附加到数据库以供软件使用。SA帐户凭据未保存在应用程序或安装程序日志中的任何位置。该软件还提供了在安装过程中使用预先创建的数据库的选项。

因此，我只想确认是否需要SA帐户才能安装或运行此IT服务管理软件。

如果是安装：创建一个临时的“ sa”帐户-执行安装-并删除该帐户。

如果操作：避免使用类似鼠疫的软件。（或设置一个仅容纳该数据库的独立SQL服务器。）

任何提供的默认SQL Server系统安全性参数都应修改。建议不要使用混合模式（同时启用Windows和SQL Server身份验证）进行身份验证。相反，仅切换到Windows身份验证-这将强制执行Windows密码策略-检查密码长度，有效期和历史记录。Windows密码策略与SQL Server身份验证不同的功能是登录锁定–在连续多次失败的登录尝试之后，登录被锁定并且无法进一步使用

另一方面，SQL Server身份验证没有提供检测暴力攻击尝试的任何方法，更糟糕的是，SQL Server甚至针对处理大量快速登录尝试进行了优化。因此，如果在特定的SQL Server系统中必须进行SQL Server身份验证，则强烈建议禁用SA登录