（来源：点击蓝字关注→ twt企业IT社区）

 导读 

在银行业强监管背景下，国家金融监督管理总局《银行保险机构数据安全管理办法》等法规明确要求日志需满足合规追溯需求，同时银行业涉及海量客户资金、敏感信息，审计日志是防范欺诈、应对监管审计、追溯安全事件的关键，基于这样的行业环境，审计日志必须包含哪些核心信息才能既满足监管要求，又适配银行柜面、网银、信贷等多业务场景？比如操作主体、交易流水、敏感数据访问记录等要素，是否有明确的必选范围？哪些信息缺失会导致日志失去审计价值，无法应对监管检查？

银行业审计日志一旦被篡改，可能引发资金安全风险、监管处罚甚至声誉危机，日志防篡改方面已有一些思考和尝试，比如引入哈希校验、加密存储等技术，部分核心系统采用本地持久化与校验结合的方式，也尝试对接集中式日志平台，但实际应用中仍有困惑：结合银行业分布式系统多、日志采集点分散的特点，技术层面还有哪些更可靠的防篡改实现手段？在管理层面需配套哪些更完善的管理制度，才能辅助确保日志不可篡改，形成“技术+管理”的闭环？

本文来自几位同行及专家的探讨，除上述问题外，还结合银行隐私计算平台建设背景，探讨了联合建模全流程中，哪些环节必须记录审计日志，以及如何在保护隐私的前提下生成可审计的报告。

· 来自企业IT应用趋势项目创新联盟 ·银行隐私计算平台选型与联合建模实践课题

日志内容应包含哪些信息？如何确保审计日志不可篡改？

◉ 陈耀斌 金融企业 DBA：

一、审计日志必须包含核心内容

数据库审计日志需全覆盖访问、操作、变更全链路，必备字段包含：

一是基础身份信息，含操作用户账号、登录 IP、终端设备标识、操作时间戳，精准定位责任人与来源。

二是操作行为信息，涵盖登录登出、DDL 建删改表、DML 增删改查、权限授权回收、数据批量导出、高危删除及配置变更等行为类型。

三是对象与结果信息，记录操作涉及库名、表名、字段、数据范围，同时标注操作执行成功或失败状态。

四是运维管理信息，包含会话 ID、事务编号、运维工单编号、审批流水号，实现操作与审批链路关联溯源。

二、审计日志不可篡改保障措施

第一，独立隔离存储。审计日志不落地业务数据库本地，单独归档至专属日志服务器、对象存储或 NAS，与业务系统权限物理隔离，运维人员无删除、修改权限。

第二，权限严格管控。实行三权分立，划分业务运维、审计管理员、安全管理员角色，仅审计账号可读不可写、不可删，禁止普通用户接触审计日志文件。

第三，实时同步与固化。日志生成后实时同步至异地归档存储，采用写后不可改存储策略，同时启用日志哈希校验，每笔日志生成指纹值，随时比对校验完整性。

第四，全生命周期留痕。设定合规留存周期，到期仅允许自动归档封存，禁止手动清理；所有日志查阅、导出操作二次留痕，形成审计闭环。

第五，技术加固防护。启用日志加密传输与存储，部分高合规场景采用区块链存证、WORM 一次写入多次读取机制，从技术层面杜绝日志篡改、覆盖与恶意删除，满足等保及行业监管溯源要求。

◉ 达芬奇 某银行 科技岗：

1.日志内容应包含哪些信息？

根据监管要求， 日志至少应包含：日志唯一编号、操作时间、操作人标识、操作内容、操作对象。

在实际操作中，往往难以简单而精确地描述“操作内容”与“操作对象”。例如，当某次操作为大规模数据查询时，若将原始数据（即使经过脱敏）完整记录为“操作对象”，将导致日志文件体积过大，难以存储与管理。

针对这一问题，可采用记录数据库操作语句及其参数的方式，来替代直接记录操作内容与操作对象。在日后审计或追溯时，可依据操作时间恢复对应的数据库备份，再通过执行所记录的语句与参数，复现当时的操作场景与查询结果。

2.如何确保审计日志不可篡改？

可采用区块链技术存证审计日志。一是通过集中的日志平台收集各个信息系统的日志，集中存储、管理和分析。二是通过区块链技术，把日志的哈希值记录在区块链上。区块链的链式结构和共识算法保证了，记录一旦被写入，修改或删除该记录将面临数学上的不可能，从而维持了审计日志的不可篡改性。

◉ 董生 某金融机构 数据架构师：

日志信息记录5元组外，上文中以SQL代替其他信息记录，包括操作的请求体，授权体，个人认为是比较难以覆盖的。相反的，审计日志如果直接以原始数据完整记录存储，可能提供更多的信息。 另外区块链技术能保证修改的不可抵赖性。不能保障重要数据的机密性。

>>>

扩展探讨

联合建模全流程中，哪些环节必须记录审计日志？

◉ lovenetwork 某城商行 技术管理：

做为银行科技的一员，需要从联合建模的落地维护和应对监管审查的角度，对建模流程的全过程进行管理，并且需要详细记录日志。 一是能够支撑责任界定二是出现故障问题时能够将过程原。

1.任务发起与授权环境

谁发起的、绑定的业务需要把业务审批流和数据授权协议数字化，并记录。

2.合作方互相认证环境

任务启动后，强制交换并记录合作方的数字证书、运行环境度量值，比如TEE的远程证明报告。运行环境中判定为为高风险的事件。

3.样本对齐计算环境

求交过程，记录算法、耗时、通信量；对求交结果记录交集大小和结果的哈希承诺，双方用私钥签名

4.联合计算执行环境

模型训练和推理的每一轮迭代需记录轮次、损失值、梯度的哈希值，以及通信的收发方和密文大小。

5.模型资产管理阶段

任何涉及模型或模型分片的加载、导出、下载指令，无论操作成功还是被拦截，都必须完整留痕，包括操作人、时间、目标路径。这是保护银行核心数字资产，尤其是自研高价值模型不被窃取的关键。

6.结果消费与决策

日志要串联“隐私计算请求ID”和“行内业务流水号”，记录入模变量和模型分值。这样才能在客户异议时，回溯完整决策过程。

7.数据处理与销毁阶段

建模任务到期或终止后，对清理动作日志进行记录。要记录各节点应清理的资源清单与实际操作结果，并可由安全管理员发起复核，确认数据确已销毁。这是我们满足“数据最小化”合规要求的关键证明。

反洗钱报告需包含交易链路详情，如何在保护隐私的前提下生成可审计的报告？能否向监管机构提供零知识证明？

◉ lovenetwork 某城商行 技术管理：

监管本质上需要的不是把客户数据全量推送过去，而是“你是否按规定完成了筛查”这个结论。

守住客户隐私底线，满足监管合规要求：在各个环节通过审计日志全线贯通，每一次规则命中、每一轮联合计算都生成带有数字签名的密码学存证，确保事后不可篡改。报告采用分层设计加密机制：统计汇总信息明文报送，涉及到的交易链路提供密码学保障。监管部门在可以凭通过密码学加密保障的值验证报告的完整性，如后续需要明细数据再通过密钥解锁明细，整个过程要留痕、可追溯可审计。

零知识证明，目前学术论证和技术方案落地是可行的但需要认识到，能否投入生产，监管层面是否认可，个人感觉还是需要走一段路，监管层面的沟通认可是必须要做的一项工作，目前监管都在推各种监管沙盒项目，值得我们同业者去尝试。持续跟踪零知识证明的标准化进展和监管动态，是我们目前要做的工作。