Azure SQL不支持SELECT触发器，审计读操作须用原生审核或应用层记录；BEFORE UPDATE可用INSTEAD OF替代实现脱敏与审计；审计表本身需按敏感数据严格防护。
触发器不能审计SELECT，别白费劲写 AFTER SELECT
直接在 AFTER SELECT 上建触发器会报错——Azure SQL Database（和所有主流SQL引擎一样）**根本不支持 SELECT 触发器**。你写的语句哪怕语法看着像，执行时必然触发 ERROR 1064 或类似解析失败提示。这不是权限或版本问题，是SQL标准层面的限制。
真正需要审计“谁查了身份证号”，必须放弃触发器捕获读操作这条路。可行方向只有两个：启用 Azure SQL 原生审核 + 敏感标签，或在应用层主动记录。触发器只能补位写操作（UPDATE/DELETE）或中间写入环节（比如脱敏后写入日志表）。
BEFORE UPDATE 触发器可拦截敏感字段修改并脱敏
如果你的目标是防止用户直接 UPDATE 身份证号、手机号等字段，可以用 BEFORE UPDATE 触发器做校验和替换：
- 检查
NEW.id_number是否符合格式（如正则匹配），不符合就RAISERROR中断 - 若允许更新但需脱敏，把
NEW.id_number替换为CONCAT(LEFT(NEW.id_number, 3), '****', RIGHT(NEW.id_number, 4)) - 同时 INSERT 一条审计记录到
audit_log表，包含USER_NAME()、HOST_NAME()、GETDATE()和原始值
注意：Azure SQL 不支持 MySQL 风格的 BEFORE 触发器，所以实际要用 INSTEAD OF UPDATE + 显式 UPDATE 逻辑；且必须确保触发器里不递归写入 audit_log（否则死循环）。
用触发器配合应用层实现“伪脱敏写入”审计闭环
当应用从源表查出明文数据、再写入脱敏中间表（如 users_anonymized）时，可在该中间表上建触发器，把来源信息补全进审计流：
- 应用执行：
INSERT INTO users_anonymized SELECT id, LEFT(phone, 3) + '****' FROM users WHERE id = 123 -
AFTER INSERT触发器读取CONTEXT_INFO()或临时表中由应用预设的@caller_session_id，关联到原始查询 - 触发器 INSERT 到
access_audit，字段含：table_name = 'users'、operation = 'SELECT+ANONYMIZE'、anonymized_columns = 'phone'、app_user = 'api-service-01'
这个模式绕开了 SELECT 审计盲区，但依赖应用层配合传上下文——没传就只剩空壳。Azure SQL 不支持 SESSION_CONTEXT 以外的轻量会话变量，所以推荐用 sp_set_session_context 在查询前设置键值对。
最易忽略的风险：审计表本身成了新敏感源
你花力气建的 audit_log 表，如果存着原始身份证号、IP、完整SQL文本，它自己就是高敏感表。但很多人忘了给它加防护：
- 没设行级安全策略（RLS），导致任意 db_datareader 都能查全部审计记录
- 没开动态数据掩码（DDM），
old_data字段里的明文身份证直接裸露 - 没限制访问路径，审计表被应用误当成业务表 JOIN 查询，拖慢性能还泄露
真正落地时，得把 audit_log 当成和 users 同等级别的敏感表来管：最小权限原则、字段级掩码、定期清理（不是靠 DELETE，而是用 TRUNCATE + 分区切换）。否则，审计系统反而成了攻击跳板。
