在SQL Server 2014中优化程序集所需的权限

Question

由于IT设置权限太低，我有程序集无法执行。我需要设置什么权限来允许我的程序集运行？它是否必须是CONTROL？

Answer 1

如注释所示，您不执行任何CLR程序集。它们与文件系统隔离，并保持与SQL Server中的任何其他类型的对象一样。

事实上，这就是CLR对象如此巧妙的原因。它们作为任何其他函数，过程，表格存在，您希望操作。

现在，由于您在此论坛上发布了有关权限的信息，请从数据库管理员的角度理解CLR是自定义的，因此固有不安全。这很不安全，因为在一天结束时，您的专业知识和知识深度是一个限制因素，并且超出了SQL Server正常预期的操作范围。

CLR权限的最大因素取决于它是否需要来自SQL Server的外部资源。从安全角度来看，它是UNSAFE，期间。 CLR安全

注

• 三个因素有三个政策，确定您的安全级别：MACHINE，USER和HOST政策。

  确定授予程序集的权限是在三个不同的地方所定义的安全策略：

  计算机策略：这是在机上运行在其上安装SQL Server的所有托管代码影响的政策。

  用户策略：这是对由进程托管的托管代码有效的策略。对于SQL Server，用户策略特定于运行SQL Server服务的Windows帐户。

  主机策略：这是CLR主机（在本例中为SQL Server）设置的策略，对于在该主机中运行的托管代码有效。

  CLR Integration Code Access Security

  这些是分开的，更多的一个可能是，为什么你被剥夺了特权。

  • CLR CAS不再支持

  CLR在.NET Framework，它不再支持作为一个安全边界使用代码访问安全（CAS）。

  clr enabled configuration | Microsoft Docs

  • 可用选项

  1）请访问无论是对你的团队反正没有任何变化，忽略了如何安全性改变任何警告。

  2）确定CLR实际对系统有什么风险后请求访问。

  3）将您的CLR更改为在适当的安全级别下运行，同时仍支持CAS。

  4）请在这里你封装此对象的需求从正规，不合格的用户，从而满足适当的帐户运行，您无须经常帐户访问的替代品。

  • 解释和可能导致

  第一个选择就是懒惰的人做的。不要懒惰。从他们的角度做一些研究，学习和理解你需要的东西。无论如何，这也许是不可行的。

  第二个选择是基本上是这样的：阅读和了解什么文件说，这样你可以在你需要更有说服力。这对于你的开发团队来说肯定是他们阅读文档所必需的。请参阅帖子末尾的链接。

  第三种选择可能不是可行的，但也许是两个步骤后/谈话的DBA，你可能会确定CLR是反正制服。唯一的问题是，在SQL Server 2017之后，所有CLR代码将被视为UNSAFE，因为微软正在为通常的安全性提供支持。 因此，如果这不会造成阻塞问题，相应地计划。

  第四个选项意味着你能得到DBA使用的是从实际运行脚本的LOGIN/USER独立的服务帐户/合格用户。封装的优势在于获得您想要的，并且仍然保持您需要的高标准安全性。两个缺点取决于CLR和您的需求，以及DBA如何帮助您开发正确的代码。

  无论你是一位经验丰富的老将CLR还是一个新人，该文件是真正的了解你或不应该问你的最佳途径。

  来源

  • Overview of CLR Integration | Microsoft Docs

  • Introduction to SQL Server CLR Integration | Microsoft Docs

  必须阅读开发商

  • CLR Integration Security | Microsoft Docs

  • CLR Integration Code Access Security | Microsoft Docs