我正在使用EXEC sp_configure 'clr enabled', 1
但是,我正在与其他几个开发人员和他们的项目共享我的数据库服务器。我隐约听到他们可能会security issues启用此功能。
有谁知道这些问题可能是什么? CLR可以安全地在SQL Server上使用吗?
答案 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模块,从而打开了创建自定义模块和组件的非常重要的可能性。数据类型,但它也会在您的服务器上打开一个重要的攻击面区域。
需要进一步考虑:
服务器上的其他设置,包括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程序集”。