CLR在SQL Server 2017上的严格安全性

Question

MSDN对这篇文章说:

CLR使用.NET Framework中的代码访问安全性(CAS),不再支持它作为安全边界.使用PERMISSION_SET = SAFE创建的CLR程序集可能能够访问外部系统资源,调用非托管代码以及获取sysadmin权限.从SQL Server 2017开始,引入了名为clr strict security的sp_configure选项,以增强CLR程序集的安全性.默认情况下启用clr严格安全性,并将SAFE和EXTERNAL_ACCESS程序集视为标记为UNSAFE.可以禁用clr strict security选项以实现向后兼容性,但不建议这样做.Microsoft建议所有程序集都由证书或非对称密钥签名,并且相应的登录名已在master数据库中被授予UNSAFE ASSEMBLY权限.

如何创建CLR程序集PERMISSION_SET = SAFE可以访问外部系统资源,调用非托管代码以及获取sysadmin权限？

为什么不再支持CAS作为安全边界？

据我所知,CLR组件不再安全,这是非常不幸的.

Answer 1

我知道这不是真正的解决方案，但您可以更改安全模式：

EXEC sp_configure 'show advanced options', 1
RECONFIGURE;
EXEC sp_configure 'clr strict security', 0;
RECONFIGURE;

对于想要继续工作的人来说，这是最简单的解决方案

Answer 2

使用PERMISSION_SET = SAFE创建的CLR程序集如何能够访问外部系统资源,调用非托管代码以及获取sysadmin权限？

这是由于.NET Framework中的安全性更改,从4.5版开始(我相信).

代码访问安全性基础知识的 MSDN文档指出:

.NET Framework提供了一种机制,用于对名为代码访问安全性(CAS)的同一应用程序中运行的不同代码实施不同级别的信任.不应将.NET Framework中的代码访问安全性用作基于代码源或其他身份方面强制实施安全边界的机制.我们正在更新我们的指南,以反映代码访问安全性和安全性 - 透明代码将不被支持作为具有部分受信任代码的安全边界,尤其是未知来源的代码.我们建议不要在不采用其他安全措施的情况下加载和执行未知来源的代码.

然后指向.NET Framework中的安全性更改页面,其中指出:

.NET Framework 4.5中对安全性的最重要更改是强大的命名.

然后指向增强型强命名的文档,其中指出:

强名称密钥由签名密钥和身份密钥组成.程序集使用签名密钥进行签名,并由身份密钥标识.在.NET Framework 4.5之前,这两个键是相同的.从.NET Framework 4.5开始,身份密钥与早期的.NET Framework版本保持一致,但签名密钥通过更强的哈希算法得到增强.此外,签名密钥使用身份密钥签名以创建反签名.

此外,安全编码指南的文档指出:

代码访问安全性和安全性 - 透明代码不支持作为具有部分受信任代码的安全边界.我们建议不要在没有采取替代安全措施的情况下加载和执行未知来源的代码......

因此,.NET的安全模型在几年前就已发生变化,但SQL Server(直到SQL Server 2017)已被允许继续使用旧的安全模型.似乎从SQL Server 2017开始,决定不再支持旧的安全模型.

我怀疑允许旧的安全模型是:

• 阻止SQL Server(至少与CLR相关的功能/组件)基于较新的.NET Framework版本,以及

• 负责突然删除SQLCLR作为Azure SQL数据库的支持功能(支持已于2014年末添加,随着v12的推出,但随后于2016年4月15日完全删除).

所以,是的,这有点糟透了.它意味着什么(至少目前)是需要首先创建一个证书或非对称密钥(用于签署任何要加载的程序集)[master],然后创建一个登录,然后授予UNSAFE ASSEMBLY该登录.这与加载EXTERNAL_ACCESS和UNSAFE装配时需要执行的事件序列相同,但不幸的是,现在甚至需要对程序集执行此操作SAFE.

目前没有以完全可移植的方式处理这种情况的机制(即不依赖于外部文件),并且在没有人工干预的情况下无法由Visual Studio/SSDT处理.这种情况已经有点了,但至少可以创建一个以完全可移植的方式处理它的设置(即完全包含在.sql脚本中):请参阅SQLCLR Stairway 7级:开发和安全性以获取详细信息(这是我写的一篇文章).

可以从十六进制字节(即FROM BINARY = 0x...)创建证书,但这不适用于Visual Studio(依赖于MSBuild)/ SSDT,因为使用证书需要使用signtool和MSBuild使用sn.

为了使其成为可行,Visual Studio/MSBuild/SSDT发布过程正常工作(这反过来意味着任何人都能够创建一个完全独立的.sql脚本,能够创建非对称密钥而不依赖于在外部文件中,CREATE ASYMMETRIC KEY需要增强该命令以允许从二进制字符串创建.我在Microsoft Connect上做了这个建议 - 允许非对称密钥从二进制十六进制字节字符串创建就像CREATE CERTIFICATE一样 - 所以请支持它:-).

或者(暂时,直到MS希望创建一个更好的方法,例如我的非对称密钥建议),您可以尝试我在以下博客文章中描述的两种技术中的任何一种(两者都完全使用SSDT):

• SQLCLR与SQL Server 2017,第2部分:"CLR严格安全性" - 解决方案1
• SQLCLR与SQL Server 2017,第3部分:"CLR严格安全性" - 解决方案2

作为最后的手段,您可以考虑以下方法:

1. TEMPORARILY将[master]数据库设置为TRUSTWORTHY ON
2. 在中创建程序集 [master]
3. 从程序集创建非对称密钥
4. 放下大会
5. 将[master]数据库设置为TRUSTWORTHY OFF
6. 从非对称密钥创建登录
7. 授予UNSAFE ASSEMBLY该登录权限

请注意,我并没有包含新的"可信大会"功能作为一个不错的选择.没有提到它的原因是它有更多的缺陷而不是好处,更不用说它首先是完全没有必要的,因为现有的功能已经处理了"可信组件"的情况.有关该内容的完整详细信息以及处理现有的未签名程序集的正确方法的演示,请参阅:SQLCLR与SQL Server 2017,第4部分:"受信任的程序集" - 失望.