Mat*_*att 6 security sql-server sql-server-2008-r2
我将域帐户用于 SQL Server 服务帐户。有时，当我有多个在逻辑上或主题上相关的服务器时，我会为所有服务器上的服务帐户使用相同的域帐户集。每个服务器上的用户帐户权限可能不同，但通常有很多重叠。
我的问题的要点是：有权访问一个实例而不是另一个实例的用户可以利用共享服务帐户来访问另一台服务器吗？
这是我试图解决的具体情况：
迄今为止，我从未特别质疑安全隐患，因为这些服务器具有共同的用途和用户群，即使特定的用户权限可能不同。
现在，我们要添加第三个实例，我们称之为 org-sql-rpt。这个主题与其他主题非常契合，但有一个关键区别：我们将允许外部合作伙伴（即不是我们组织的员工）访问此服务器，如下所示：
鉴于此，我是否应该担心将域帐户重用作此新实例的服务帐户？此人是否有任何风险可以使用他们在 org-sql-rpt 上的合法凭据来访问 org-sql-1 或 org-sql-2？（即可以通过使用不同的服务帐户凭据来减轻任何风险？）
还是出于其他原因，这只是一个普遍的坏主意？
编辑
新实例将托管数据库、集成和报告服务（至少目前是这样）。没有分析服务。
外部用户将拥有提升的数据库权限，但没有明确的实例权限。例如，他们将无法创建登录名、作业或报告。
风险缓解将指示为每台机器上的每个服务创建一个单独的帐户。根据微软自己的建议，创建必要帐户所需的工作水平极低，但不这样做会带来的未知风险非常高。
Microsoft 最佳实践建议为所有服务使用单独的服务帐户。
有关详细信息，请参阅http://msdn.microsoft.com/en-us/library/ms144228.aspx#isolated_services。
要点是：
隔离服务
隔离服务可降低一项被破坏的服务可能被用来破坏其他服务的风险。要隔离服务，请考虑以下准则：
在单独的 Windows 帐户下运行单独的 SQL Server 服务。尽可能为每个 SQL Server 服务使用单独的、低权限的 Windows 或本地用户帐户。有关详细信息，请参阅配置 Windows 服务帐户和权限。
还有一个关于保护 SQL Server 的知识库，其中提到了如何正确配置服务帐户：
http://support.microsoft.com/kb/2160720
选择服务帐户时，请考虑最小权限原则。服务帐户应该拥有完成其工作所需的权限，并且没有更多权限。您还需要考虑帐户隔离；服务帐户不仅应彼此不同，而且不应被同一服务器上的任何其他服务使用。不要向 SQL Server 服务帐户或服务组授予其他权限。权限将通过组成员资格授予或直接授予服务 SID，其中支持服务 SID。有关更多详细信息，请参阅联机丛书主题设置 Windows 服务帐户。
Technet 在http://technet.microsoft.com/en-us/library/ms143504.aspx上有一篇题为“配置 Windows 服务帐户和权限”的文章，其中说：
安全说明：始终使用尽可能低的用户权限运行 SQL Server 服务。尽可能使用 MSA 或虚拟帐户。当 MSA 和虚拟帐户不可用时，请使用特定的低权限用户帐户或域帐户而不是 SQL Server 服务的共享帐户。为不同的 SQL Server 服务使用不同的帐户。不要向 SQL Server 服务帐户或服务组授予其他权限。权限将通过组成员资格授予或直接授予服务 SID，其中支持服务 SID。
上段中的“MSA”指的是“托管服务帐户”，它是 Windows 7 或 Windows Server 2008 R2 及更高版本上安装的默认值。托管服务帐户实际上对每台机器都是唯一的。
顺便说一句，在配置多个服务器以在同一服务帐户下运行时，我考虑的一个问题是帐户锁定。如果您对所有 SQL Server 使用单个服务帐户，并且该服务帐户被锁定，则您的所有服务器都可能受到影响。如果每个服务有一个帐户，则最多一台服务器会受到锁定的影响。
小智 5
我们将允许外部合作伙伴（即不是我们组织的员工）访问此服务器，如下所示：
他们的凭据将拥有（属于 db_owner）几个数据库。
与多个实例上的服务帐户相同的一个问题是，外部实体可以很容易地提升其权限。鉴于外部实体在 dbo 中，因此存在可能被黑客入侵并提升为系统管理员的风险。 DBO 上报
下一个问题，您有一个用户可能具有本地管理员访问权限（此处的持续时间无关紧要），他们可以轻松地将自己（无需登录 SQL 服务器）添加为系统管理员或更改 sa 密码，并且威胁从那里。这是一篇关于如何做到这一点的文章。
基于这些漏洞，我将为每个实例使用不同的服务帐户和密码。使该外部实体难以从一台服务器移动到另一台服务器。