xp_cmdshell 的安全风险

Question

在我们的其中一台生产服务器中，我们需要启用xp_cmdshell某些应用程序功能。

使用我们当前的安全措施，它在所有情况下都被禁用，只需要为一个特定的 SQL Server 启用。

1. 启用有多糟糕xp_cmdshell？
2. 担心真的是一件大事吗？
3. 可以采取什么具体措施来启用它并仍然限制其使用？

我们的应用程序团队创建了一个触发器，可以启动另一个发票流程，他们需要这样做xp_cmdshell。

Answer 1

根据Microsoft Docs for xp_cmdshell：

xp_cmdshell 代理帐号

当它由不是 sysadmin 固定服务器角色成员的用户调用时，xp_cmdshell 将使用存储在名为 ##xp_cmdshell_proxy_account## 的凭据中的帐户名和密码连接到 Windows。如果此代理凭据不存在，xp_cmdshell 将失败。

因此，如果您尝试以xp_cmdshell非 sysadmin 用户身份执行，假设您尚未配置代理帐户，它将失败。这意味着只有系统管理员才能运行它。你信任你的系统管理员吗？

一旦xp_cmdshell被启用，它产生的外壳具有同样的安全性用于运行SQL Server本身（或代理帐户，如果配置）的帐户。如果该帐户在本地计算机上具有完全权限，则由xp_cmdshell所创建的外壳将在本地计算机上具有完全权限。如果 SQL Server 服务帐户是域管理员（我永远不会建议），情况也是如此。遵循最小权限原则应该意味着 SQL Server 拥有运行所需的最低权限，并且xp_cmdshell将拥有相同的一组权限。

如果配置xp_cmdshell为使用代理帐户，然后由它衍生出的外壳将有权利即帐户，它可以被锁定。但是，任何系统管理员都可以修改代理帐户设置，因此确保限制谁拥有系统管理员权限非常重要。

您已经提到您的应用程序团队想要xp_cmdshell在触发器中使用。这将真正限制您系统的性能，您真的应该重新考虑该设计。例如，如果xp_cmdshell返回错误，则插入表将失败。如果调用xp_cmdshell需要几秒钟才能完成，则在此期间受插入影响的行将被锁定，并可能导致其他会话被阻塞。

正如@DanGuzman指出的那样，您应该改为使用服务代理队列来提供异步有保证的消息传递机制，该机制不会中断将行插入受影响的表。Service Broker 队列可由 SQL Server 外部的应用程序以响应迅速、可靠且可扩展的方式使用。