通过启用 Ole Automation procedures 服务器配置选项来利用安全性的示例是什么？

Question

我需要在 SQL Server 上启用Ole 自动化过程服务器配置选项，但想知道这样做会带来哪些具体类型的安全风险？

启用此选项后如何利用安全性的示例是什么？

Answer 1

我不认为我会从剥削的角度来看待它。它非常类似于（如果不是相同的安全问题）xp_cmdshell。这些在启用后可以执行的内容方面是开放的，并且对于到达 SQL Server 外部的进程，它们使用运行 SQL Server 的服务帐户的安全上下文（尽管至少可以选择xp_cmdshell设置一个非用户的代理帐户sysadmin）。

但是，您需要处于sysadmin实例级角色才能执行sp_OA*过程（或获得显式许可），因此您至少可以将它的所有使用保留在使用模块签名来获取提升权限的EXECUTE存储过程的范围内。权限（是的，如果与用户关联的登录名位于角色中，则指定也有效，但模块签名更好）。WITH EXECUTE AS N'dbo'dbosysadmin

看看@kevinsky 的答案中的 CIS 引用（即“这些是扩展存储过程，允许 SQL Server 用户执行 SQL Server 外部的函数。 ”），除非我遗漏了一些东西，否则这似乎是夸大其词，或者可能是无知的，反应。如果启用它，所有用户都可以访问它，这肯定是一个大问题。但实际上，只有已经能够启用“OLE 自动化过程”的用户才可以使用存储过程。我并不是说如果不使用它就应该启用它，但这似乎并不是一个固有的安全风险。sp_OA*

我认为安全“问题”是，它允许开发人员创建的代码要么在网络或文件系统或操作系统级别上执行您可能不认可的操作，要么可能会产生意想不到的后果。

话虽这么说，如果您询问需要支持的遗留代码，那么虽然不理想，但它可能会起作用。但是，如果这是关于新开发，那么您不应该使用 OLE 自动化；您应该使用SQLCLR。与 OLE 自动化相比，SQLCLR 具有许多优点，包括（但不限于）：

• 更好的安全性：您可以将代码限制为仅限于 SQL Server 内部 ( SAFE) 或能够访问外部资源，但不能更改系统或执行异步工作等 ( EXTERNAL_ACCESS)
• 访问外部资源时能够模拟调用者的 Window 登录（不限于服务帐户）
• 更好的数据类型支持：OLE 自动化应该是 COM 接口，并且它不支持 MAX 类型、XML 以及任何更新的类型。
• 更好的内存管理