触发器不能直接拦截权限检查失败，只能捕获已获授权的显式操作（如DROP/ALTER）；防越权需结合DENY语句、LOGON触发器校验角色成员、CONTEXT_INFO区分场景等多层控制。
不能靠触发器直接拦截角色越权操作——它不响应权限检查失败，只响应事件发生。 想用触发器“防止越权”，必须把目标转成可捕获的显式行为，比如 DROP TABLE、TRUNCATE TABLE 或登录动作，而不是“用户有没有权限”这个判断本身。
DDL 触发器只能拦 DROP/ALTER/CREATE，拦不住权限拒绝后的报错
SQL Server 的 DDL 触发器（如 FOR DROP_TABLE）在语句**执行前或执行后**触发，但它不介入权限校验流程。如果用户没权限执行 DROP TABLE，SQL Server 会在触发器运行前就报错 ERROR 3701 并中止，触发器根本不会执行。
- 真正能被 DDL 触发器捕获的，是那些**权限足够但你不希望发生的操作**，比如开发账号删生产表
- 权限不足导致的拒绝（如
SELECT denied）完全绕过触发器，无法感知 - 想防越权，得先确保用户有基础权限（比如
db_datareader），再用触发器封具体动作
用 LOGON 触发器限制特定角色成员的登录来源
角色本身不直接出现在 ORIGINAL_LOGIN() 或 CURRENT_USER() 中，但你可以查 sys.database_role_members 判断登录名是否属于某角色——前提是触发器在 ON ALL SERVER 级别，并且有足够权限读取系统视图。
- 必须用
EXECUTE AS 'sa'或其他高权限主体创建，否则SELECT FROM sys.database_role_members会因权限不足失败 - 不能直接写
IF IS_ROLEMEMBER('db_owner') = 1—— 这个函数在 LOGON 触发器上下文中不可靠，返回总是 0 - 正确做法：用
EVENTDATA().value('(/EVENT_INSTANCE/LoginName)[1]', 'sysname')取登录名，再 JOIN 角色成员表校验 - 示例片段：
DECLARE @login sysname = EVENTDATA().value('(/EVENT_INSTANCE/LoginName)[1]', 'sysname'); IF EXISTS ( SELECT 1 FROM sys.database_role_members drm JOIN sys.database_principals dp ON drm.member_principal_id = dp.principal_id JOIN sys.database_principals rp ON drm.role_principal_id = rp.principal_id WHERE dp.name = @login AND rp.name = 'db_owner' ) AND (SELECT EVENTDATA().value('(/EVENT_INSTANCE/ClientHost)[1]', 'nvarchar(48)')) NOT IN ('10.0.1.5', '127.0.0.1') ROLLBACK;
DENY 优先级高于 GRANT，比触发器更直接有效
对角色做权限控制，首选不是触发器，而是 DENY 语句。它能覆盖继承权限，且生效即时、无盲区。
-
DENY ALTER ON OBJECT::dbo.orders TO db_owner无效——db_owner角色隐含CONTROL权限，DENY被忽略；必须先把用户从该角色移出 - 对自定义角色（如
app_developer）可用：DENY DROP ANY TABLE TO app_developer，这会阻止所有表的DROP -
DENY TRUNCATE ON SCHEMA::dbo TO app_developer在 SQL Server 2016+ 有效，但注意：TRUNCATE 需要目标表的ALTER权限，DENY ALTER 更通用 - 跨库无效：每个数据库都要单独执行
DENY，不能一次覆盖整个实例
触发器 + CONTEXT_INFO 是唯一能区分“同账号不同场景”的办法
当多个应用共用一个数据库账号时（比如所有后台服务都用 svc_app），仅靠登录名无法判断操作意图。这时必须靠应用层配合设置上下文标识，触发器才能精准拦截。
- 应用在执行高危操作前，先执行：
SET CONTEXT_INFO 0x5472756E636174654A6F62（十六进制字符串，代表 “TruncateJob”） - 触发器里用
CONTEXT_INFO()取值，比对后决定是否ROLLBACK - 不要依赖
APP_NAME()——它容易被客户端伪造，CONTEXT_INFO至少需要连接内权限，相对可控 - CONTEXT_INFO 是连接级变量，断连即清空，无需手动清理，但要注意长度上限 128 字节
真正难的不是写触发器，而是厘清“谁在什么场景下要做什么”——没有上下文信息，触发器只能粗暴封禁；没有权限层兜底，触发器就是单点防线。两者缺一不可。
