如何配置所有权链实现用户仅查询REPORTING架构视图不访问基表

这是个典型的SQL Server所有权链场景问题，我帮你拆解原因和对应的解决方案：

问题根源：所有权链断裂 #

SQL Server的所有权链规则是：当视图和它引用的底层表（或其他对象）属于同一个所有者时，SQL Server只会检查用户对视图的权限，不会验证用户对底层表的权限。但如果视图和底层表的所有者不同，所有权链就会断裂，这时候SQL Server会要求用户必须拥有底层表的直接权限，这就是你遇到报错的原因。

你之前把视图所有权改成dbo后，引用dbo表的视图能正常工作（同所有者，链生效），但引用其他架构（归ApplicationAdmin所有）的表时，视图所有者（dbo）和表所有者（ApplicationAdmin）不一致，链就断了，所以报错。

解决方案1：统一对象所有权（最简单直接） #

核心思路是让REPORTING架构下的所有视图，和它们引用的所有底层表，归同一个所有者所有，这样所有权链就能完整生效。

步骤： #

1. 把REPORTING架构的所有权改为ApplicationAdmin（因为其他被引用的架构都归他所有）：

ALTER AUTHORIZATION ON SCHEMA::reporting TO ApplicationAdmin;

2. 对于被视图引用的dbo架构下的表，把它们的所有权也改为ApplicationAdmin（让表和视图所有者一致）：

-- 替换XXX为实际表名，每个被引用的dbo表执行一次
ALTER AUTHORIZATION ON dbo.XXX TO ApplicationAdmin;

如果你能接受修改整个dbo架构的所有权（影响所有dbo对象），也可以直接执行：

ALTER AUTHORIZATION ON SCHEMA::dbo TO ApplicationAdmin;

完成后，reporting_usr只要拥有REPORTING架构的SELECT权限，就能正常查询所有视图，完全不需要访问底层表的权限。

解决方案2：模块签名（无需修改所有权，更灵活） #

如果不想改动现有对象的所有权，模块签名是更安全灵活的方案。它通过给视图添加数字签名，让SQL Server在执行视图时临时赋予签名对应的权限，用户本身不需要底层表的权限。

步骤： #

1. 在数据库中创建用于签名的证书：

CREATE CERTIFICATE cert_ReportingViews
   WITH SUBJECT = 'Certificate for signing reporting views';

2. 基于证书创建一个无登录权限的数据库用户：

CREATE USER user_ReportingSigner
   FROM CERTIFICATE cert_ReportingViews;

3. 给这个签名用户授予所有底层表的SELECT权限：

-- 授予对dbo架构的SELECT权限
GRANT SELECT ON SCHEMA::dbo TO user_ReportingSigner;

-- 授予对其他被引用架构的SELECT权限，替换OtherSchema为实际架构名
GRANT SELECT ON SCHEMA::OtherSchema TO user_ReportingSigner;

4. 用证书给每个REPORTING架构的视图签名：

-- 替换vCounters为实际视图名，每个视图执行一次
ADD SIGNATURE TO reporting.vCounters
   BY CERTIFICATE cert_ReportingViews;

现在reporting_usr查询视图时，SQL Server会临时使用user_ReportingSigner的权限访问底层表，但用户本身无法直接访问这些表，完美实现你的需求。

解决方案3：EXECUTE AS（需谨慎使用） #

可以在视图中指定EXECUTE AS OWNER，让视图以所有者的身份执行。只要所有者拥有底层表的权限，用户就能查询视图，但这种方法有安全风险——如果所有者是高权限用户（比如dbo），可能被用来执行越权操作。

步骤： #

1. 确保视图所有者（比如ApplicationAdmin）拥有所有底层表的SELECT权限。

2. 修改现有视图添加EXECUTE AS OWNER：

ALTER VIEW reporting.vCounters
WITH EXECUTE AS OWNER
AS
-- 原视图的查询语句
SELECT ... FROM dbo.XXX JOIN OtherSchema.YYY ON ...;

或者创建新视图时直接指定：

CREATE VIEW reporting.vCounters
WITH EXECUTE AS OWNER
AS
SELECT ... FROM dbo.XXX JOIN OtherSchema.YYY ON ...;

推荐方案 #

优先选择解决方案1（统一所有权），它最简单直观，没有额外的维护成本；如果无法修改现有对象的所有权，就选解决方案2（模块签名），这是SQL Server官方推荐的安全方案，不会引入不必要的权限风险。

内容的提问来源于stack exchange，提问作者sniegoman