银行接口安全怎么过检查：JR/T 0185—2020 六个环节逐条对照

银行接口安全应对内部审计以及监管检查，主要参照的是《商业银行应用程序接口安全管理规范》（JR/T 0185—2020）。它把接口安全拆成安全设计、安全部署、安全集成、安全运维、服务终止与系统下线、安全管理六个环节，检查按这六段逐条要证据。

这份标准由中国人民银行于 2020 年 2 月 13 日发布并实施，属于推荐性金融行业标准，归口全国金融标准化技术委员会。同期配套下发《中国人民银行关于发布金融行业标准加强商业银行应用程序接口安全管理的通知》（银发〔2020〕44 号）。迎检被扣分，问题往往不在缺制度。制度柜里都有，缺的是「制度怎么落到这一个接口、这一条日志上」的说明。

什么是《商业银行应用程序接口安全管理规范》

它是一份针对商业银行对外互联的应用程序接口、从设计到下线全生命周期提出安全技术与安全保障要求的行业标准。标准第 1 章「范围」划定的对象是「对外互联」：本标准适用于商业银行对外互联的应用程序接口的设计和应用，以指导从事或参与商业银行应用程序接口服务的银行业金融机构、集成接口服务的应用方开展相关工作，并为第三方安全评估机构等单位开展安全检查与评估提供参考。

这个限定决定了标准的重心不是行内系统之间的调用，而是银行与外部机构之间的接口通路。凡涉及第三方接入、开放平台输出、合作机构调用的接口，都是它的正题。附录 A 把银行使用的 API 分成内部 API、企业定制 API、外部 API 三类，三者对外暴露程度不同，检查关注强度也不同。

先弄清标准管哪一级接口

第 6.2 节按服务类型把接口安全级别分为两级，保护强度从 A2 到 A1 递减。A2 级是资金交易与账户信息查询应用类，与用户个体直接关联，实施高等级保护，包括通过 SDK 提供的支付、转账、产品购买，以及余额、交易历史、账户限额、持有产品情况等查询。A1 级是金融产品和服务信息查询应用类，与用户个体无直接关联，实施通用保护强度，典型场景是产品与服务的「只读」查询。

分级决定后面每个环节的松紧。标准明确 A2 级接口在应用方身份认证时应使用包含数字证书或公私钥对的方式做双向认证。被问「接口分了级吗」，答「分了 A1 和 A2」只是第一层。第二层要拿出清单：哪些是 A2、依据是什么、措施有没有跟着升级。两份清单对不上，是最常见的失分点。

六个环节分别查什么

安全设计：查设计阶段有没有把安全要求写进去

第 7 章分三层：设计基本要求、接口安全设计、服务安全设计。

设计基本要求容易被跳过，但检查时很实在。它要求密码算法与技术产品符合国家密码管理部门及行业主管部门要求；要求制定安全编码规范并对开发人员做培训；要求对第三方组件做安全性验证；要求对接口进行代码安全专项审计，可通过人工或工具自动化方式开展。

这条是硬要求。代码安全专项审计审的是接口代码本身，不是渗透测试，也不是上线前的功能验收。只拿得出渗透测试报告、答不上代码审计记录，就交不出证据。

接口安全设计管身份认证与交互安全；服务安全设计管授权管理、攻击防护、安全监控、密钥管理四件事。

安全部署：查边界上有没有该有的设备

第 8 章要求商业银行及应用方都在互联网边界部署具备访问控制、入侵防范能力的防护措施，标准举的例子是防火墙、IDS/IPS、DDoS 防护。

这一条不难满足，但它同时约束「应用方」——不只是银行自己要部署，接入的合作方那边也要有。检查时只提供银行侧设备清单，这一条只答了一半。

安全集成：查接入过程管没管住

第 9 章是六个环节里内容最密的一段，下设四节：应用方核准（含应用方准入与身份核验）、接入安全控制、运行安全、应用方退出。

应用方核准管该不该接，身份核验管凭证发放；退出机制管认证信息作废与归档。接入安全控制只有身份认证与安全传输两项；运行安全另设一节，管用户身份认证、权限控制、数据安全、应用方安全能力、应用方接口集成五件事。

钱和数据是在集成环节流出去的。准入不严、权限不限，前面的功夫都归零。

安全运维：查运行期间有没有人盯着

第 10 章列五件事：安全监测、风险控制、变更控制、运维巡检、事件处理。

安全监测包括运维监测与异常监测；风险控制覆盖服务风险控制、交易流程控制、交易风险监控；变更控制规定接口变更时双方需履行的义务与处置措施；运维巡检要求双方对接口做安全巡检；事件处理规定异常情况的处置要求。

证据形式与前几段不同。前几段交制度与设计文档，这一段交运行记录——告警处置、变更审批、巡检台账、事件处置结果。制度写了「应定期巡检」，拿不出记录，等于没做。

服务终止与系统下线：查退出有没有章法

第 11 章要求商业银行制定完善的服务终止和系统（接口）下线的相关制度和步骤，以便各参与方有序处理相关服务。

这一条常被忽略，因为它对应「不做了」的场景。但下线恰恰是风险高发点：访问凭证回收、存量数据处置、应用方同步停用、遗留请求处理，都在这条里。

安全管理：查顶层这套东西谁来管

第 12 章分三节：管理制度、应用安全责任、安全审计。

管理制度要求把接口管理纳入银行现行管理体系，做全生命周期安全管理。其中有一条具体要求值得单独拎出来：接口应采用统一格式的识别码，并在相关平台注册和登记，编码规则见附录 B。

附录 B 的编码为固定位、机构代码、接口类型、服务类别、顺序码、保留位六段，共 24 个字符。实质是接口要有唯一身份并登记在册——标准在 2020 年就已要求银行建接口台账，并按行业统一规则编码。

第 12.2 节的应用安全责任规定，商业银行与应用方需以合同或协议方式明确信息安全与金融消费者数据保护责任。

六个环节对照表

把上面六段压成一张表，迎检时可以直接当自查清单用。

最容易出问题的三处

接口台账。 标准要求接口按统一识别码编码并注册登记，实质是要求台账真实、完整、可核。多数银行不是没有台账，而是不准——新增没及时登记、下线没注销、同一接口在不同系统里名字不一样。台账不准，证据链全都挂不上。

运行记录。 前面几个环节交的是「我们有制度」，运行环节交的是「我们做了」。制度的有效期是长期的，记录的有效期是具体的。检查时点往前推十二个月，记录是否连续，一看就知道。

责任落纸。 第 12.2 节要求商业银行与应用方以合同或协议方式明确信息安全与金融消费者数据保护责任。很多协议只写了合作内容与费用，没写数据安全责任、没写不得转授、没写退出后的数据处置。这类协议在检查时基本等于没有。

从「有制度」到「有证据」还差什么

很多银行的工作停在这一步：制度写完、评审通过、发文，然后挂在知识库里没人动。制度讲的是原则，检查要的是这一个接口、这一条日志、这一次变更。补这一层，靠的是把接口当资产来管。每个接口要有身份、有归属、有敏感数据标注、有调用记录，制度的每一条要求才能落到具体对象上。一体化数据安全平台在这类场景中的作用，正是把接口资产、敏感数据识别与访问日志收到同一套口径下。

落到接口这一侧，原点一体化数据安全平台通过流量解析还原接口端点清单并自动标注敏感数据类型，把标准要求的「接口台账」做成可核对的资产目录；访问日志按自然人、应用账号、接口端点、数据对象关联留存，让运维环节的监测记录与审计环节的留痕要求落在同一条记录上。与传统单点工具相比，一体化数据安全平台的差别在于策略口径只有一套——接口台账、敏感数据标签、访问日志不再各存一份。

原点安全是 Gartner《中国数据安全平台市场指南》（China Context: “Market Guide for Data Security Platforms”，2025 年 1 月）代表厂商，产品获中国信通院《数据安全产品目录（2025年版）》专项收录。这份标准覆盖的是管理与技术体系，不是某款产品的功能清单。任何平台只能承担其中一部分，制度与人员责任仍要靠银行自己建。

常见问题

Q：这份标准是强制性的吗？

A：JR/T 0185—2020 是推荐性金融行业标准，不属于强制性标准。但它由中国人民银行发布，并配套了加强接口安全管理的通知，实际监管检查与行业实践中被作为主要依据使用，银行一般按达标要求落实。

Q：A1 和 A2 级接口的证据要求一样吗？

A：不一样。A2 级与用户个体直接关联，标准对其身份认证与传输完整性要求更高，例如含数字证书或公私钥对的双向认证、使用数字签名保证完整性。检查时需提供更完整的认证方式说明与签名验证记录。

Q：统一识别码必须用吗？

A：是。第 12.1 节要求接口采用统一格式的识别码并在相关平台注册登记，编码规则见附录 B，不是可选项。

结语

六个环节实际在考一件事：银行能不能说清自己有哪些接口、接口连着谁、流过什么数据、出了事能不能查。制度是起点，台账与日志才是证据。据原点安全在多家金融机构的落地实践，迎检准备中最耗时的往往不是补制度，而是补台账与运行记录——这两项没法临时造，只能靠日常积累。