Kev*_*inP 8 security sql-server sql-clr
我的数据库目前被隔离在它自己的实例和 VM 中。我的客户正在淘汰该服务器,我需要将数据库迁移到新环境。我的数据库使用 CLR,所以新环境需要启用它。
客户建议使用现有服务器和现有 SQLServer 2014 标准实例托管来自其他软件供应商的数据库。我担心会产生一种“你破坏它,你买了它”的责任,因为我不能保证其他数据库或其前端的安全策略。我不想做会带来重大风险的事情。
我不时遇到与其他客户类似的情况。我是一名数据库开发人员。我偶尔会为我的中小型企业客户提供与我自己的产品相关的 DBA 服务,但我绝不是一名熟练的 DBA。每个客户都有不同的预算、优先级、IT 人员和安全策略,但通常他们都没有 IT/DBA 可以理解和/或在此详细级别进行称职的风险评估。
在共享实例上启用 CLR 会如何影响其他 DB 的安全性?(我不是在询问数据库级别的权限集级别,只是启用 CLR 本身)。我需要充分了解风险(如果有的话),以便能够建议“最佳实践”和特定于客户的“足够安全”的替代方案。
Sol*_*zky 10
鉴于我们正在处理一个共享实例,假设“客户”数据库的登录名都没有特权或已被授予权限,应该是安全sysadmin
的CONTROL SERVER
。
在这种情况下,启用 SQLCLR不应该有任何安全风险,不管很多人似乎声称什么。启用实例级别的“启用 CLR”选项仅允许具有加载程序集的适当权限的登录名,并允许任何有权访问这些程序集中的对象的人使用已加载的程序集。
如果用户无法加载程序集,则程序集中不存在未知代码的风险,因为不会有任何程序集。然后,如果一个用户(例如您自己)被授予CREATE ASSEMBLY
权限(这应该结合使用证书来处理程序集安全性),那么只有您可以加载程序集。
当然,对于SQL Server 2005至16年,并为SQL Server 2017新的具有“CLR严格的安全”实例级别的配置选项DIS体健,数据库所有者(即dbo
用户)和任何用户在db_owner
固定的数据库角色可以创建SAFE
程序集,但这些不是安全风险。当然,它们可能会带来性能风险,但对于草率的数据建模、T-SQL、触发器等也是如此。如果各个供应商都没有dbo
针对他们的数据库,那么这不是问题。如果供应商dbo
针对他们各自的数据库并且希望阻止他们创建SAFE
程序集,那么为CREATE ASSEMBLY
语句并发出 aROLLBACK
如果用户不是您和/或它不在您的数据库中执行。
如果某人是sysadmin
实例级角色的成员,或被授予CONTROL SERVER
实例级权限,则他们也可以加载程序集。但是,这是大多数与“安全”相关的建议遗漏的内容:禁用“启用 CLR”并不能保护sysadmin
具有CONTROL SERVER
权限的人,因为他们有权启用“启用 CLR”选项(并启用xp_cmdshell
等并执行他们想要什么)!
启用此选项没有固有风险,因为启用它不会授予任何人加载构成安全风险的程序集的权限(在 SQL Server 2005 - 2016 中,角色dbo
用户db_owner
可以加载SAFE
程序集)。并且,一旦加载,程序集被标记为EXTERNAL_ACCESS
或UNSAFE
需要额外的安全性(即证书/强命名,不是 TRUSTWORTHY
),以便执行它们的代码。而且,从 SQL Server 2017 开始,默认情况下,所有程序集都需要额外的安全性才能首先加载。并且,额外的安全性(用于程序集的操作)需要sysadmin
级别权限:
TRUSTWORTHY ON
的不幸情况下,拥有该数据库的登录名需要具有EXTERNAL ACCESS ASSEMBLY
或UNSAFE ASSEMBLY
权限(对于启用了“CLR 严格安全性”的 SQL Server 2017+ - 默认 - 它必须是UNSAFE ASSEMBLY
),这只能是由系统管理员授予(如果拥有的登录名是 ,则这些权限显然是隐含的sysadmin
)。希望供应商数据库永远不会TRUSTWORTHY
启用。[master]
数据库中创建证书或非对称密钥,然后需要从中创建登录名,然后需要授予该登录名EXTERNAL ACCESS ASSEMBLY
或UNSAFE ASSEMBLY
权限(对于 SQL Server 2017+ 具有“CLR 严格安全性”) " 已启用 — 默认值 — 必须是UNSAFE ASSEMBLY
)。有关处理 SQLCLR 安全性的一些示例,请参阅:
话虽如此,正如大卫·布朗 (David Browne) 在对此答案的评论中指出的那样:
另一个重点是关于各种数据库的利益相关者之间可能存在的信任。在企业环境中,每个人都应该值得信赖和合作。在第 3 方托管环境中,您必须假设相邻工作负载的所有者是一个完全不受信任甚至恶意的参与者。许多不完全安全的事情在防火墙后面和朋友之间是足够安全的。