在SQL SERVER 2005上启用CLR是否存在任何安全问题?

时间:2011-03-30 15:57:00

标签: asp.net sql sql-server security

我正在使用EXEC sp_configure 'clr enabled', 1

在我的SQL服务器上启用CLR的想法

但是,我正在与其他几个开发人员和他们的项目共享我的数据库服务器。我隐约听到他们可能会security issues启用此功能。

有谁知道这些问题可能是什么? CLR可以安全地在SQL Server上使用吗?

3 个答案:

答案 0 :(得分:3)

不,SQLCLR代码在数据库中不能比在相同安全上下文下运行的等效T-SQL代码模块做更多的事情。

这是并且目前是所有SQL Server(尤其是2012年以后)中最无知的安全声明,它可以破坏与SCCM databases的UI连接,这是旗舰ETL部署模型SSISDB(需要CLR),因为第3个派对安全工具继承了CIS基准(主要是DBProtect),即使服务器没有运行2000,它也错误地标记了SQL Server整理系数2000,错误地指示DBA重建master并永远将他们的环境和应用程序瘫痪,如果没有人说话的话这一发现。 CLR不是安全风险,它允许通过RDP和文件系统权限缓解和SSIS代码管理在多个方面实现旗舰增强(后SQL Server 2012)的安全性。 SSISDB,可能会影响每90%的SQL Server商店,包括不依赖单一SAN的HA解决方案。

关于那些只是反对CLR的DBA的旁注,因为如果做得不好就很难排除故障" - 对于高级.NET开发人员代码进行故障排除主要不在DBA范围内,如果您雇佣了不好的DBA,他们也很难排除故障(请参阅上面的排序规则)。此外,大多数利用CLR的人正在为旗舰功能这样做,与编写CLR代码很少或没有关系(尽管script tasks in SSIS leverage this在某种程度上),并且与SSISDB和使用可用性组有更多关系跨SANs。不喜欢这种功能的DBA应该进入时间扭曲并且达到2008年的停滞模式。这是从全栈BI / DBA角度编写的,而不是来自有点近视的系统内部有利位置。

此外,Availability Groups utilize CLR,如果未启用CLR则会导致错误。更多信息也经过Technet

审核

可用性组和SSISDB都是现代SQL Server环境的旗舰功能。

目前,通过启用CLR并通过SSISDB部署SSIS包,可以缓解文件系统组织管理不善和混乱,获得继承的备份维护计划甚至TDE,并且实际上大大降低了RDP对SSIS包进行故障排除的需求。 / p>

询问您的DBA,他是否非常关心安全性,为什么要设置混合模式身份验证,SSMS或SSRS或Excel客户端没有SSL证书,未启用TDE,缺少审核甚至无法登录成功和登录失败。< / p>

http://www.codemag.com/article/0603031

要启用CLR,只需运行

sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'clr enabled', 1;
GO
RECONFIGURE;
GO

答案 1 :(得分:1)

我和Squillman在一起;不幸的是,答案并不像“是”或“否”那样简单。

在服务器上启用CLR可以在服务器上托管用户定义的CLR模块,从而打开了创建自定义模块和组件的非常重要的可能性。数据类型,但它也会在您的服务器上打开一个重要的攻击面区域。

需要进一步考虑:

  • 谁拥有数据库的特权?你相信其他所有人吗? 谁可能能够在您的SQL Server上创建程序集?如果 不,请注意他们将能够在您的服务器上托管CLR代码, 我不推荐的东西。
  • 服务器上的其他设置,包括DB和&amp ;;的所有权。该 数据库上值得信赖的位设置。以下文章有 关于这个主题的更多细节:
    https://blogs.msdn.microsoft.com/sqlsecurity/2007/12/03/the-trustworhy-bit-database-property-in-sql-server-2005/

  • .Net本身不是没有错误的。托管CLR代码要好得多 想法比托管扩展存储过程(XPs),总有一个 .Net框架内部存在安全漏洞的风险 这种情况通常是SQL中托管的安全CLR模块 服务器可能成为攻击媒介,以控制您的SQL 服务器进程。它不会经常发生,但你必须保持警惕 并在发生时采取相应行动。

我希望这有帮助,

-Raul Garcia

SQL安全

答案 2 :(得分:0)

由于SQL CLR was unceremoniously removed from Azure for security reasons和SQL Server 2017引入了一个默认启用的新选项CLR strict security,因此很明显存在潜在的安全问题,您不应该允许未查看的CLR代码待部署。

严格的安全链接状态

  

使用PERMISSION_SET = SAFE创建的CLR程序集可能能够访问   外部系统资源,调用非托管代码,并获取sysadmin   特权

上述关联帖子的评论之一提及

  

通过Windows Update运行的许多“.NET安全更新”都是这种情况   有人可以使用安全代码逃离.NET沙箱。非常   这些年来有很多这样的案例。

此外

SQL Server Guidance to protect against speculative execution side-channel vulnerabilities专门列出了“不受信任的SQL Server可扩展性机制”部分中的“SQL CLR程序集”。