很多国内企业，尤其是金融、医疗、政务这些强监管行业，数据完整性是一个绕不开的硬指标。
Azure SQL 和 SQL Server 2022+ 有个功能叫 Ledger（分类账），本质上就是在数据库里内置了一套区块链防篡改机制——每笔事务都会被哈希加密并链接成链，形成一个不可篡改的数据轨迹。这个底层的技术原理和区块链是一样的，只不过它直接跑在你的数据库引擎里，不需要额外引入一条外部链。
但最近我观察到一个挺普遍的现象：
很多团队表建了、Ledger 开了，却从来不跑验证——这等于白干。
📌 先搞清楚两个概念
数据库摘要（Database Digest）
Ledger 开启后，SQL Server 会把所有 Ledger 表的事务用密码学哈希串起来，像区块链一样形成一个个「区块」。最新区块的哈希值就叫 数据库摘要。
你可以把摘要导出到外部不可变存储（Azure Immutable Blob 或 Azure Confidential Ledger），作为一份独立于数据库本身的完整证明。
Ledger 验证（Ledger Verification）
验证过程其实就是把当前 Ledger 表的状态跟之前存储的摘要做比对——重新算一遍哈希链，确认中间没有被篡改过。
一行 T-SQL 就能跑：
DECLARE @digest_locations NVARCHAR(MAX) = (
SELECT * FROM sys.database_ledger_digest_locations
FOR JSON AUTO, INCLUDE_NULL_VALUES
);
BEGIN TRY
EXEC sys.sp_verify_database_ledger_from_digest_storage @digest_locations;
SELECT 'Ledger 验证通过 ✅' AS Result;
END TRY
BEGIN CATCH
THROW;
END CATCH
跑通就说明数据没问题，跑不通就说明有人动过手脚——或者摘要存储本身出了问题。
⚠️ 不开验证会怎样？
很多团队有个误区：「我 Ledger 表建了，数据应该就安全了吧？」
不是这样。Ledger 只是提供了防篡改的能力，验证才是确认没被篡改的动作。
不开验证 = 三个致命风险：
- 篡改静默发生：有人（或某个脚本）改了你 Ledger 表里的数据，你不会收到任何告警
- 合规审计翻车：等保、数据安全法中关于「数据完整性」的要求，不是你说「我开了 Ledger」就能糊弄过去的，审计要的是验证记录
- 虚假安全感：就像装了监控但从不去看回放，真出事的时候才发现什么都没记录下来
🎯 为什么要定期跑验证？
| 好处 | 说明 | |------|------| | 数据完整性确认 | 用密码学手段证明数据没被动过 | | 审计就绪 | 验证结果本身就是审计证据，直接交 | | 早期发现 | 异常越早发现，追溯和修复成本越低 |
对于国内用户来说还有一个实际价值：在等保测评和行业合规检查中，定期 Ledger 验证的日志可以直接作为数据完整性控制项的证据，比你自己写一堆运维文档管用得多。
🔧 实操建议
如果你已经在用 Ledger，或者正准备上：
- 把验证脚本加到日常巡检里，比如每天跑一次，跟备份检查放一起
- 摘要存储尽量用外部不可变存储，不要跟数据库放在同一个实例上
- 验证结果要持久化记录（写个日志表），方便审计时追溯
- 如果用的是 Azure SQL，摘要建议放 Azure Immutable Blob 或 Azure Confidential Ledger。如果用本地 SQL Server，可以放 Azure Blob Storage 或其他不可变文件存储
💡 国内云对比：阿里云 RDS 和腾讯云 CDB 目前都没有内置 Ledger 这样的区块链防篡改能力。如果你有强合规需求，Azure SQL Ledger + 验证这套方案是目前云数据库里最成熟的选项之一。
一句话总结：Ledger 是工具，验证才是结果。 别让你的合规工作做一半。
📎 原文：https://techcommunity.microsoft.com/t5/azure-sql-blog/why-ledger-verification-is-non-negotiable/ba-p/4485290
📅 发布日期：2026-01-13
