API 接口安全审计怎么做：日志留什么、怎么溯源

接口安全审计要回答的不是「有没有日志」，而是「这条日志能不能定到人、定到数据、定到时间」。有日志但查不出人，等于没有审计。监管对这件事有明确要求。《银行保险机构数据安全管理办法》（金规〔2024〕24 号）第二十八条要求对敏感级及以上数据严格实施授权管理，并对数据访问行为实施审计。金融行业标准 JR/T 0185—2020 则把接口审计的具体要求写在安全审计一节里。本文就围绕这几条，讲清接口审计到底要留什么、怎么用。

什么是 API 接口安全审计

它是指对应用程序接口的访问行为做完整记录、完整性保护与可追溯分析的一套机制，目的是在发生数据争议或安全事件时，能够还原「谁在什么时间、通过哪个接口、访问了哪些数据」。这里有两个词要分清。「记录」是把事实存下来，「审计」是能把事实还原成证据链。很多机构做到了前者，停在后者之前。标准层面还有一个概念要区分：接口审计与代码审计不是一回事。对接口做代码安全专项审计，那是在开发阶段审代码本身的安全缺陷；本节讨论的访问审计是在运行阶段审调用行为。两者对象不同，不能互相替代。

标准要求做三件事

我们把接口审计的要求拆成三条，对商业银行与应用方分别提出。

第一件，完整记录访问日志。 标准要求商业银行完整记录接口访问日志，日志记录至少包括该标准第 7.3.3 节所述的内容。同时，依据商业服务需求和风险控制要求，遵循最少够用原则适当保留应用方上送报文。这一条里有两个动作：记日志、留报文。日志记的是「谁在什么时候调了哪个接口」，报文留的是「这次调用送出去和拿回来的具体内容」。多数机构只做了前一个。

第二件，日志完整性保护。 标准要求对日志记录做完整性保护，确保日志不被篡改、删除、覆盖。这一条常被当成运维细节，实际是审计能否成立的前提。日志可以被改，审计结论就没有证明力。

第三件，可查询。 标准对应用方提出要求：应提供查询用户相关登录、授权、交易等历史操作日志的功能。对商业银行一侧，则通过日志记录与留存要求对应。三条合起来，构成接口审计的最小合规基线。

只有网关日志为什么不够

多数银行的接口日志来自 API 网关。网关日志能回答「哪个应用标识调了哪个路径、返回了什么状态码」，这对排障够用，对数据审计不够。

差距集中在三点。

人无法定位。 网关日志记录的是应用标识，一个应用标识背后可能是几十个操作人员。要定位到具体是谁，需要把接口调用与应用侧的用户身份关联起来，这层信息不在网关日志里。

内容无法还原。 状态码 200 只说明调用成功，不说明返回了什么。要判断「这次调用是否取走了不该取的客户信息」，必须看响应内容。

路径无法串联。 数据在系统里往往经过多个接口流转：先查列表、再查详情、最后导出。单个接口的日志看不出这是一次完整的取数行为，只有按数据对象把多次调用串起来，才能看清数据去了哪。

一条合格的审计记录要含哪些要素

把上面三点合起来，一条能用于审计的记录至少要含五类要素。

操作主体。 自然人身份、所属机构、应用账号、客户端 IP。自然人身份是核心——没有它，审计止步于「某个应用调过」。

访问对象。 接口端点、所属业务系统、请求参数。端点要精确到具体路径，不是笼统的「订单服务」。

数据内容。 这次调用涉及的敏感数据类型与内容值。类型用于统计与告警，内容值用于事后取证。两者用途不同，留存策略也不同。

时间。 请求时间要精确到足以还原操作序列，时区统一。

结果。 是否成功、返回记录条数、是否被策略拦截。被拦截的记录同样要留，它反映的是攻击尝试或越权企图。

这五类要素齐了，一条记录才能同时支撑合规检查与事件调查两种场景。

溯源取证的三个台阶

有了记录，下一步是能不能查。溯源能力大致分三个台阶，多数机构停在第一阶。

第一阶：查到调用。 给定一个接口和时间段，能列出这段时间内所有调用记录。这是最基础的查询能力，网关日志就能做。

第二阶：查到数据。 给定一个敏感数据值，比如某个身份证号，能查出它被哪些调用取走过。这一步要求日志留存了数据内容，且内容可检索。能做到这一阶的机构不多，难点不在存储，在于日志里原本就没有内容。

第三阶：查到流向。 给定一个数据对象，能还原它从哪个接口进入、经过哪些系统、最终流向哪里。这一步需要跨接口、跨系统关联，依赖的是统一的数据标识与人员标识。

三个台阶之间是能力跃迁，不是量的积累。第一阶到第二阶要解决「记不记内容」，第二阶到第三阶要解决「标识统不统一」。

留多久、怎么防篡改

标准对留存期给了明确下限，不是一句「按需确定」。9.3.4 要求应用方留存与接口集成相关的应用系统、网络设备、主机设备、安全产品日志，且不少于 6 个月；10.1.1 要求商业银行系统日志保存期限不少于 1 年，交易日志按国家会计准则要求保存。12.3 里「依据商业服务需求和风险控制要求，遵循最少够用原则」这句，限定的是应用方上送报文的保留范围，不是日志留存时长——这两件事常被混成一件事。

在下限之上取多久，通常由三个因素决定：监管检查的追溯期、内部事件调查的常见周期、存储成本。三者取交集。

防篡改这一条是硬要求。技术上常见做法是日志写入后不可修改、按周期做哈希校验、日志与业务数据分离存储。要点在于日志的写入权限与业务系统的运维权限分开——审计日志如果由被审计对象自己管，完整性就难以保证。

落到工具上需要什么

接口审计对工具的要求，与做接口防护不完全一样。防护关注「拦不拦得住」，审计关注「说不说得清」。

在这类场景的落点，是把访问日志从「接口级」下沉到「数据级」——日志里不只有路径和状态码，还有这次调用碰到了哪些敏感数据、涉及哪个自然人。在接口审计这一侧，平台可通过流量旁路采集接口访问数据，识别请求与响应中的敏感字段并标注类型，按需留存敏感数据内容值与原始报文，支持按具体数据值做深度检索，同时将接口调用与应用账号、自然人身份关联，形成可追溯的访问轨迹。与传统网关日志相比，一体化数据安全平台的差别在于日志里的数据对象是可检索的，而不是一段文本。

结语

接口审计的门槛不在存储，在关联。日志再全，关联不上自然人、关联不上数据内容、关联不上流转路径，就只是一堆文本。据原点安全在金融机构的实践，这项工作最容易被低估的是「统一标识」——接口标识、应用账号、自然人身份三者若各自编码，日志存得再多也串不起来。先统一标识，再谈留存策略与检索能力，顺序不能反。