SQL Server触发器无法防止未授权登录，因其仅在已认证会话执行DML时运行；真正拦截应在连接建立前使用ON ALL SERVER LOGON触发器。
SQL Server 中的触发器无法防止未授权登录——它根本不是为这个目的设计的。登录控制发生在连接建立阶段，而触发器只在已成功登录、且执行 DML/DDL 语句时才可能运行。想靠触发器“拦住非法用户”，等于在门锁坏了之后给屋里装摄像头。
为什么 AFTER INSERT/UPDATE 触发器对未授权登录完全无效
触发器只响应已通过身份认证的会话发起的合法 DML 操作。如果一个账号连 LOGIN 都没建成功，或者登录后没被授予 CONNECT TO DATABASE 权限，它连执行 INSERT 的机会都没有，更不会走到触发器这步。
- 常见误解：以为在表上建个
FOR INSERT触发器就能“过滤非法来源”。实际只要账号能连库、有INSERT权限，触发器就照常运行；反之，没权限的账号连语句都提交不过去，报错是Msg 229, Level 14（拒绝了对对象的 INSERT 权限），根本不会进触发器 -
ORIGINAL_LOGIN()和CURRENT_USER在触发器里只能告诉你“谁在操作”，不能帮你拒绝一个本不该存在的登录 - 攻击者若已拿到高权限账号（如
db_owner），他可以直接REVOKE INSERT ON users FROM public再自己GRANT给新账号——触发器对此毫无感知
真正该拦截未授权登录的位置：服务器级登录触发器 + 网络层控制
限制谁可以连进来，必须在连接建立前完成。SQL Server 提供的是登录触发器（ON LOGON），不是 DML 触发器。
- 登录触发器在每次
LOGIN事件发生时触发，早于任何数据库上下文初始化，可用于检查 IP、程序名、时间窗口等 - 示例：只允许来自特定子网且
PROGRAM_NAME()包含MyAppService的连接：CREATE TRIGGER tr_block_untrusted_logins<br>ON ALL SERVER<br>FOR LOGON<br>AS<br>BEGIN<br> IF EVENTDATA().value('(/EVENT_INSTANCE/ClientHost)[1]', 'varchar(16)') NOT LIKE '10.10.%'<br> OR PROGRAM_NAME() NOT LIKE '%MyAppService%'<br> ROLLBACK;<br>END; - 必须用
ON ALL SERVER作用域，且需CONTROL SERVER权限创建；启用后，不满足条件的连接会在握手阶段直接断开，不会产生会话 - 注意：登录触发器本身不能查用户表（如
SELECT * FROM mydb.dbo.whitelist），因为此时数据库上下文未确定；白名单逻辑应硬编码或用SERVERPROPERTY('MachineName')等静态值判断
误用触发器防登录会引入严重风险
把安全边界错误地放在 DML 层，反而制造出虚假安全感，掩盖真实漏洞。
- 在
AFTER UPDATE里写IF ORIGINAL_LOGIN() = 'sa' RAISERROR(...)—— 这毫无意义。sa是合法账号，你真正该做的是禁用sa、改密码、并确保没人用它连生产库 - 试图在触发器里调用
sp_executesql去查 AD 组成员或调外部 API 验证身份：会极大拖慢所有 DML 性能，且一旦网络超时或服务不可用，整个事务卡死 - 依赖
HOST_NAME()或APP_NAME()做判断：容器化部署下这些值高度泛化（如sqlserver-01），无法区分具体应用实例 - 最危险的是：把登录控制逻辑和业务逻辑混在一个触发器里，导致审计日志无法分离“谁连进来了”和“谁改了数据”
真正的防护链是线性的：网络防火墙 → SQL Server 登录认证 → 数据库级权限（GRANT/REVOKE）→ 表级行级安全（RLS）→ 最后才是 DML 触发器做业务校验。跳过前面任意一环，单靠触发器就是拿胶带补弹孔。
