SQL Server触发器+HASHBYTES无法真正防篡改，因其不阻止权限内修改、无来源验证、需配合权限控制/时间戳/版本字段才具审计价值。
SQL Server 的触发器本身无法真正防篡改，HASHBYTES 生成的校验码只是事后验证手段，且必须配合严格权限控制与时间戳/版本字段才能具备实际审计价值。
为什么不能只靠触发器+HASHBYTES 就算“防篡改”
触发器运行在数据库服务端，但执行权限仍属于当前会话用户。如果攻击者拥有 UPDATE 权限，就能绕过触发器逻辑（比如禁用触发器、用 DISABLE TRIGGER、或通过高权限账号直接修改表）；HASHBYTES 输出的是哈希值，不加密也不签名，无法验证来源——它只告诉你“数据后来被改了”，不告诉你“谁改的、何时改的、改前是什么”。
常见错误现象：UPDATE 后发现 signature 字段没更新，或所有记录的哈希值都一样——通常是因为触发器里漏写了 INSERTED 引用，或用了固定字符串而非行级拼接。
- 必须把待保护字段显式拼成字符串（如
CONCAT(ISNULL(col1,''), '|', ISNULL(col2,''))），不能直接HASHBYTES('SHA2_256', *) - NULL 值必须用
ISNULL()或COALESCE()统一转为空字符串，否则CONCAT(NULL, 'a')得到NULL，哈希结果不可控 - 触发器类型要匹配操作：对
UPDATE必须同时检查INSERTED和DELETED，但签名只需基于新值重算，旧值仅用于比对
INSTEAD OF UPDATE 触发器 + HASHBYTES 的正确写法
比起 AFTER UPDATE，INSTEAD OF 更适合介入校验——它能拦截非法修改，并在写入前强制重算签名。关键点在于：不允许用户直接写入 signature 字段，且必须验证原始哈希是否匹配（即“你声称没改，那旧哈希得对得上”）。
示例场景：表 orders 中 amount、status、updated_by 为敏感字段，需签名并阻止静默篡改：
CREATE TRIGGER tr_orders_prevent_tamper
ON orders
INSTEAD OF UPDATE
AS
BEGIN
IF UPDATE(signature)
THROW 50000, 'Direct update to signature column is forbidden.', 1;
<p>-- 检查旧记录哈希是否匹配（防覆盖式篡改）
IF EXISTS (
SELECT 1 FROM INSERTED i
INNER JOIN DELETED d ON i.id = d.id
WHERE HASHBYTES('SHA2_256', CONCAT(ISNULL(d.amount,''), '|', ISNULL(d.status,''), '|', ISNULL(d.updated_by,''))) != d.signature
)
THROW 50001, 'Row signature mismatch: possible tampering detected.', 1;</p><p>-- 安全写入：仅允许更新非签名字段，签名由触发器重算
UPDATE o
SET
amount = i.amount,
status = i.status,
updated_by = i.updated_by,
signature = HASHBYTES('SHA2_256', CONCAT(ISNULL(i.amount,''), '|', ISNULL(i.status,''), '|', ISNULL(i.updated_by,''))),
last_modified = GETUTCDATE()
FROM orders o
INNER JOIN INSERTED i ON o.id = i.id;
END;签名字段存储与查询验证的坑
HASHBYTES 返回 varbinary(8000)，不能直接存为 varchar——必须用 CONVERT(varchar(64), ..., 2) 转成十六进制字符串（SHA2_256 是 32 字节 → 64 字符 hex），否则存进去就是乱码或截断。
- 建表时签名字段建议定义为
CHAR(64)（定长，索引友好），而非varchar - 验证某条记录是否被改过？别手写哈希再比对，用
WHERE signature != HASHBYTES('SHA2_256', ...)——但注意：WHERE 子句中HASHBYTES的参数必须和触发器里完全一致（包括 NULL 处理、分隔符、字段顺序） - 性能影响：每行 UPDATE 都触发一次 SHA2_256 计算，千行批量更新时延迟明显；如需高频更新，考虑只对关键字段签名，或改用
HASHBYTES('MD5', ...)（不推荐生产，仅权衡性能时参考）
真正起作用的配套措施
没有这些，签名只是装饰：
- 撤掉普通用户对表的
UPDATE权限，只授予执行特定存储过程的权限（过程内封装签名逻辑） - 给表加
last_modified和modified_by字段，并在触发器中强制更新——哈希可包含时间戳，让“同一内容不同时间”的哈希也不同 - 定期跑校验脚本：
SELECT id FROM orders WHERE signature != HASHBYTES('SHA2_256', CONCAT(...))，结果写入审计表 - SQL Server 2016+ 可考虑开启SQL Server Audit，捕获谁在什么时间执行了哪些 DML，和签名日志交叉比对
最易被忽略的一点：HASHBYTES 不处理字符排序规则（collation）。如果字段是 Chinese_PRC_CI_AS，而你拼接时隐式转换成其他排序规则，哈希就会错——所有参与拼接的字段，COLLATE DATABASE_DEFAULT 最稳妥。
