SQL Server 2022 中不能在视图上直接启用动态数据屏蔽（DDM），因为 DDM 是列级策略，必须作用于基础表的物理列；但可先在基础表敏感列启用 DDM，再通过视图封装逻辑、过滤行或精简字段，实现双层防护。
直接回答：SQL Server 2022 中不能在视图上直接启用动态数据屏蔽（DDM），因为 DDM 是列级策略，必须作用于基础表的物理列；但你可以把 DDM 和视图组合使用——让视图封装逻辑、隐藏敏感字段，再对底层表列启用 DDM，双层防护更可靠。
为什么不能在视图上设置 DYNAMIC DATA MASKING
SQL Server 的 ADD MASKED WITH 语法只接受基础表（sys.tables）中的列，不支持视图列。执行类似 ALTER VIEW ... ALTER COLUMN name ADD MASKED WITH (FUNCTION = 'default()') 会报错 Msg 102, Level 15, State 1: Incorrect syntax near 'MASKED'。这是因为视图列没有存储引擎层面的元数据支撑 DDM 的运行时拦截机制——DDM 依赖 sys.masked_columns 系统视图，而它只映射到物理表列。
常见错误现象：
- 试图对视图列执行
ALTER VIEW ... ALTER COLUMN ... ADD MASKED→ 语法错误 - 在视图定义中用
CASE WHEN IS_MEMBER('role')=1 THEN col ELSE '***' END模拟屏蔽 → 绕过权限检查，且无法审计、不可靠 - 误以为创建带
WITH ENCRYPTION的视图能隐藏数据 → 加密的是视图定义本身，不影响查询结果
正确组合方式：先在基础表启用 DDM，再用视图控制暴露范围
真正有效的做法是分两步走：先在源表敏感列上配置 DDM，再建视图过滤行或精简字段。这样既利用 DDM 的内核级拦截（连 SELECT * 都生效），又通过视图实现行级裁剪和语义封装。
实操建议：
- 对身份证号列启用默认屏蔽：
ALTER TABLE customers ALTER COLUMN id_card ADD MASKED WITH (FUNCTION = 'default()') - 对手机号用自定义函数：
ALTER TABLE customers ALTER COLUMN phone ADD MASKED WITH (FUNCTION = 'partial(1,"****",2)') - 创建视图时显式排除高敏列（如
ssn），或仅 SELECT 已屏蔽的列：CREATE VIEW v_customer_lite AS SELECT id, name, phone, email FROM customers WHERE status = 'active' - 确保目标用户无
UNMASK权限：REVOKE UNMASK ON customers.id_card TO [app_user]
注意：如果视图 JOIN 多张表，且其中一张表有 DDM 列，该列在视图查询结果中依然受屏蔽——DDM 是“粘性”的，不会因视图而失效。
UNMASK 权限与角色管理容易被忽略的细节
DDM 不是靠用户角色自动开关的，而是由显式的 UNMASK 权限控制。即使你把用户加入 db_datareader，只要没授 UNMASK，他们看到的就是屏蔽后的内容。
关键点：
-
UNMASK是数据库级权限，不能按列授予，只能对整张表或整个数据库授予：GRANT UNMASK ON customers TO [analyst_role] - 拥有
CONTROL或ALTER表权限的用户自动获得UNMASK，这点常被低估——比如开发人员有ALTER权限，就等于绕过所有 DDM - 视图所有者（
OWNER）在查询视图时，仍受 DDM 限制，除非显式被授予UNMASK - SQL Server 2022 中，
UNMASK权限不继承自 Windows 组或 Microsoft Entra 组，必须显式 GRANT
最易踩的坑是：以为建了视图就安全了，结果忘了给敏感列加 DDM，或者误给运维账号开了 CONTROL 权限——那 DDM 形同虚设。真实场景里，DDM 和视图不是二选一，而是互补：视图管“看哪些”，DDM 管“看到什么样子”。
