金融级审计需金仓MongoDB兼容模式，原生MongoDB不满足等保三级要求；金仓通过内核拦截记录client_ip、app_name、sql_text及字段快照，支持SM4加密与SIEM对接，但需确保协议层上下文完整。
金融级交易场景下，MongoDB 的事务本身不自动产生合规所需的审计流水，必须额外配置和落库——这不是功能缺陷，而是设计定位决定的。
mongo shell 或 driver 执行的 transaction 不写审计日志
MongoDB 社区版默认关闭审计功能，即使你用 session.startTransaction() + commitTransaction() 包裹了资金扣减逻辑，只要没显式启用审计模块，所有操作在数据库层面就“不留痕”。企业版虽提供 auditLog 配置项，但只记录连接、认证、DDL 类事件，默认不捕获 DML 内容（如 { $set: { balance: 999 } } 这种字段级变更）。
- 审计日志需单独开启：启动时加
--auditDestination file --auditFormat JSON --auditPath /data/audit.log - 即使开了，原生日志也不含原始语句、执行上下文（如调用方 IP、应用名）、事务内具体修改字段值
- 等保三级明确要求“操作可还原、行为可定责”，仅靠 MongoDB 原生审计无法满足
金仓数据库 MongoDB 兼容模式下，audit_log 表才真正覆盖事务操作
当切换到金仓数据库（KingbaseES）的 MongoDB 兼容模式后，事务操作会统一经过内核层审计拦截点。所有通过 mongodb:// 协议发起的 updateOne()、findAndModify() 等请求，在提交前就被解析为内部 SQL 操作，并触发 sys_audit_log 记录：
- 每条记录含
client_ip、app_name、sql_text（还原后的 UPDATE/INSERT 语句）、old_value和new_value（字段级变更快照） - 审计开关由 DBA 统一控制，无需每个应用单独配置；且开启后性能损耗稳定在 3% 以内（实测数据）
- 日志直接存入系统表，可被 SIEM 工具直连查询，也支持国密 SM4 加密转储
混合部署时，审计链路容易断在协议转换层
如果前端用 PyMongo 连接金仓，但中间套了自研 proxy 或旧版连接池，可能把 startTransaction 请求拆成多个独立命令转发，导致事务上下文丢失，审计日志里只看到零散的 insert/update，看不出它们属于同一笔交易。
- 务必确认客户端驱动版本 ≥ PyMongo 4.3（支持 OP_MSG 协议），避免降级到已废弃的
OP_QUERY - 禁用任何对
session对象做 clone、detach 或跨线程复用的操作 - 验证方法：在事务中执行一次
db.audit_test.insertOne({x:1})，再查sys_audit_log是否有对应transaction_id字段
真正难的不是开启审计，而是在高并发事务流中确保每条记录带完整上下文、不丢不乱、不可篡改——这需要协议层、语法层、存储层三者协同，不是换一个驱动就能解决的事。
