如何通过SQL视图实现行列级权限控制以保护敏感财务数据

视图本身不能实现真正的行列级权限控制，真正起作用的是GRANT、RLS和SQL SECURITY的组合；必须配合权限回收、策略启用与安全定义才能生效。

不能靠视图本身实现真正的行列级权限控制，它只是封装层；真正起作用的是 GRANT、RLS（行级安全策略）和 SQL SECURITY 设置的组合。单独建一个带 WHERE 和 CASE 的视图，不配权限回收或策略启用，等于没设防。

MySQL 中用视图做列脱敏但用户仍能查原表？

这是最常见的失效场景：你建了 user_safe_view 隐藏 salary，但忘了收回用户对 users 表的权限。

• 必须显式执行 REVOKE SELECT ON mydb.users FROM 'app_user'@'%'
• 只授视图权限：GRANT SELECT ON mydb.user_safe_view TO 'app_user'@'%'
• 创建视图时务必写 SQL SECURITY DEFINER（不是默认的 DEFINER，否则执行时按调用者权限检查，容易报 ERROR 1449）
• 若用 CASE WHEN role = 'HR' THEN salary ELSE NULL END 脱敏，确保 role 字段来自可信赖上下文（如关联权限表），而非前端传参

PostgreSQL 视图里写 CURRENT_USER 为什么查不到自己的数据？

因为视图定义是静态的，CURRENT_USER 在 CREATE VIEW 时就被求值为定义者（比如 postgres），不是查询时的登录用户。

• 正确做法是在基表上启用 RLS：ALTER TABLE payroll ENABLE ROW LEVEL SECURITY
• 再建策略：CREATE POLICY emp_salary_policy ON payroll FOR SELECT USING (employee_id = current_setting('app.user_id')::int)
• 视图只需投影字段：CREATE VIEW hr_payroll_vw AS SELECT id, name, department FROM payroll
• 连接后先 SET app.user_id = '123'，再查视图——策略自动生效

SQL Server 视图中用 USER_NAME() 做行过滤危险在哪？

USER_NAME() 返回数据库用户名，不是登录名；在 EXECUTE AS 或跨库场景下会错乱，甚至返回 NULL。

• 改用 ORIGINAL_LOGIN()（稳定返回实际登录名）或 SESSION_CONTEXT(N'user_id')（需应用层提前 sp_set_session_context 设置）
• 优先启用原生 RLS：CREATE SECURITY POLICY SalesFilter ADD FILTER PREDICATE Security.fn_securitypredicate(sales_rep_id) ON dbo.orders
• 函数里别写复杂逻辑（如递归查组织树），否则影响执行计划；策略谓词应尽量轻量、可下推
• 测试时用真实业务账号连接，避免用 sa 或 dbo 直连——权限行为会完全不同

最易被忽略的一点：视图定义里的函数（如 MD5(email)、SUBSTRING(phone, 1, 3)）会让对应字段失去索引能力。如果这个字段还要用于 WHERE 过滤，性能会断崖式下跌——脱敏和查询效率得分开设计，别挤在同一个视图里。