【发布时间】：2020-04-09 13:40:17
【问题描述】：
我正在考虑在我的 SQL 服务器上启用 CLR，使用 EXEC sp_configure 'clr enabled', 1
但是，我与其他几个开发人员及其项目共享我的数据库服务器。我隐约听说他们可能是 security issues 启用此功能。
有谁知道这些问题可能是什么？在 SQL Server 上使用 CLR 是否安全？
【问题讨论】：
标签： asp.net sql sql-server security
【发布时间】：2020-04-09 13:40:17
【问题描述】：
不，SQLCLR 代码在数据库中不能做比在相同安全上下文下运行的等效 T-SQL 代码模块更多的事情。
这是所有 SQL Server（尤其是 2012 年以后）中最容易被误解的安全声明，它可能会破坏与旗舰 ETL 部署模型 SSISDB（需要 CLR）SCCM databases 的 UI 连接，因为第 3 方安全继承 CIS 基准（主要是 DBProtect）的工具，即使服务器没有运行 2000，它也会通过 2000 错误地标记 SQL Server 归类系数，错误地指示 DBA 重建 master，并且如果没有人对发现发表意见，则永远削弱他们的环境和应用程序区分大小写. CLR 不是安全风险，它允许通过 RDP 和文件系统权限缓解和 SSIS 代码管理（例如SSISDB，可能会影响每 90% 的 SQL Server 商店，包括构建为不依赖单个 SAN 的 HA 解决方案。
关于那些只是反对 CLR 的 DBA 的旁注，因为它可能“如果做得不好，就很难排除故障”——如果你雇佣了糟糕的 DBA，那么排除高级 .NET 开发人员代码的故障并不主要在 DBA 的权限范围内可能难以排除故障（通过整理见上文）。此外，大多数利用 CLR 的人都是为了旗舰功能而这样做的，与编写 CLR 代码几乎没有关系（尽管在一定程度上script tasks in SSIS leverage this），并且与 SSISDB 和跨 SAN 使用可用性组有更多关系.不喜欢此功能的 DBA 应该跳入时间扭曲并在 2008 年达到停滞模式。这是从全栈 BI/DBA 的角度编写的，而不是从有点短视的系统内部优势角度编写的。
此外，Availability Groups utilize CLR，如果未启用 CLR，则会导致错误。更多信息也可以在Technet上查看
可用性组和 SSISDB 都是现代 SQL Server 环境的旗舰功能。
目前，通过启用 CLR 并通过 SSISDB 部署 SSIS 包，您可以缓解文件系统组织管理不善和混乱，获得继承的备份维护计划甚至 TDE，并且实际上大大降低了 RDP 对 SSIS 包进行故障排除的需求。
询问您的 DBA 是否非常关心安全性，为什么要设置混合模式身份验证、SSMS 或 SSRS 或 Excel 客户端没有 SSL 证书、未启用 TDE、缺乏审核甚至记录成功和失败的登录。
http://www.codemag.com/article/0603031
要启用 CLR，只需运行
sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'clr enabled', 1;
GO
RECONFIGURE;
GO
【讨论】：
-
出于安全原因，SQL CLR 被毫不客气地从 Azure 中删除，并且 SQL Server 2017 引入了一个新选项 CLR 严格安全，该选项默认启用，因此很明显存在潜在的安全问题，您不应允许部署未经审查的 CLR 代码。
-
Azure 中的 SQL 代理也是如此 - 您的断言没有依据或引用。
-
你看过关于严格安全的文章吗？它指出
CLR assembly created with PERMISSION_SET = SAFE may be able to access external system resources, call unmanaged code, and acquire sysadmin privilege- 将权限升级到系统管理员是一个非常明显的安全问题，并且与您的回答中的断言相矛盾SQLCLR code can’t do anything more in a database than an equivalent T-SQL code module running under the same security context -
“在相同的安全上下文下运行” - 不，它没有。
我和 Squillman 一起做这个；不幸的是，答案并不像“是”或“否”那么简单。
在服务器上启用 CLR 可以在您的服务器上托管用户定义的 CLR 模块，这为创建自定义模块和数据类型提供了一系列重要的可能性，但它也在您的服务器上打开了一个重要的攻击面。
还有其他需要考虑的事项：
- 谁拥有数据库的特权？你信任所有其他人吗 可能能够在您的 SQL Server 上创建程序集的人？如果 不，请注意他们将能够在您的服务器上托管 CLR 代码， 我不推荐的东西。
服务器上的其他设置，包括 DB 的所有权和 数据库上的可信赖位设置。下面的文章有 有关此主题的更多详细信息：
https://blogs.msdn.microsoft.com/sqlsecurity/2007/12/03/the-trustworhy-bit-database-property-in-sql-server-2005/.Net 本身并非没有错误。虽然托管 CLR 代码要好得多 比托管扩展存储过程 (XP) 的想法，总有一个 .Net 框架本身存在安全漏洞的风险，在 在这种情况下，通常是托管在 SQL 中的安全 CLR 模块
服务器可能成为获取 SQL 控制权的攻击媒介
服务器进程。这种情况不会经常发生，但你必须时刻保持警惕 并在发生时采取相应措施。
希望对你有帮助，
-劳尔·加西亚
SQL 安全
【讨论】：
SQL CLR was unceremoniously removed from Azure for security reasons 和 SQL Server 2017 引入了一个默认启用的新选项 CLR strict security，因此很明显存在潜在的安全问题，您不应允许部署未经审查的 CLR 代码。
严格的安全链接状态
使用 PERMISSION_SET = SAFE 创建的 CLR 程序集可能能够访问 外部系统资源，调用非托管代码，获取系统管理员 特权
上面链接帖子中的一个 cmets 提到了
许多通过 Windows Update 运行的“.NET 安全更新”都是案例 有人可以使用安全代码逃离 .NET 沙箱。非常 多年来这样的案例很多。
还有
SQL Server Guidance to protect against speculative execution side-channel vulnerabilities 在“不受信任的 SQL Server 扩展性机制”部分中专门列出了“SQL CLR 程序集”。
【讨论】：