JR T 0185—2020 《商业银行应用程序接口安全管理规范》.pdf

《JR T 0185—2020 《商业银行应用程序接口安全管理规范》.pdf》由会员分享，可在线阅读，更多相关《JR T 0185—2020 《商业银行应用程序接口安全管理规范》.pdf（22页珍藏版）》请在麦多课文档分享上搜索。

1、 ICS 35.240.40 A 11 JR 中华人民共和国 金融 行业标准 JR/T 0185 2020 商业银行应用程序接口安全管理规范 Commercial bank application programming interface secure management specification 2020 - 02 - 13 发布 2020 - 02 - 13 实施 中国人民银行 发布 JR/T 0185 2020 I 目 次 前言 . II 1 范围 . 1 2 规范性引用文件 . 1 3 术语和定义 . 1 4 缩略语 . 3 5 概述 . 3 6 接口类型与安全级别 . 4 7

2、安全设计 . 5 8 安全部署 . 7 9 安全集成 . 9 10 安全运维 . 11 11 服务终止与系统下线 . 13 12 安全管理 . 13 附录 A （规范性附录） 商业银行应用程序 接口关系示意 . 15 附录 B （规范性附录） 商业银行应用程序接口统一识别码编码规则 . 16 参考文献 . 18 JR/T 0185 2020 II 前 言 本标准按照 GB/T 1.1 2009给出的规则起草。 本标准由中国人民银行提出。 本 标准由全国金融标准化技术委员会 （ SAC/TC 180） 归口。 本标准起草单位： 中国人民银行 科技司 、中国金融电子化公司、中国银联股份有限公司、

3、中国工商 银行股份有限公司 、 中国农业银行股份有限公司 、 中国银行股份有限公司 、中国建设银行 股份有限公司 、 中国邮政储蓄银行 股份有限公司 、招商银行 股份有限公司 、 上海浦东发展银行股份有限公司 、中信银行 股份有限公司 、兴业银行 股份有限公司 、 中国民生银行股份有限公司 、 中国 光大银行 股份有限公司 、平 安银行 股份有限公司 、广发银行 股份有限公司 、北京银行 股份有限公司 、徽商银行 股份有限公司 、 山东 省 城市商业银行合作联盟有限公司 、齐鲁银行 股份有限公司 、 浙江 网商银行 股份有限公司 、 中信 百信银 行 股份有限公司 、山东省农村信用社 联合社

4、、北京中金国盛认证有限公司、 北京银联金卡科技有限公司 、 中金金融认证中心有限公司、中国外汇交易中心 。 本标准主要起草人：李伟、李兴锋、 曲维民、 程胜、郭栋、段力畑、郭晶莹、刘运、高强裔、陈聪、 蒋慧科、姜城、孟宪哲、卓越、文韬、孙垚、孔鹏志、赵思琪、白帆、李培钊、李屹秦、何伟 明、赵鹏、 耿丽、刘会明、李言平、蒋向超、王建华、张培承、刘伟伟、胡琳珑、贾海明、云婧、刘书洪、陈淼、 叶黎明、方绍全、 谢振哲、丘佳成、江泓、沈天乐、全成、刘嘉文、王效飞、伏开佐、杜守伟、左敏、 邓翔、丁芃、刘巍巍、涂鼎。 JR/T 0185 2020 1 商业银行应用程序接口安全管理规范 1 范围 本标准规定

5、了商业银行应用程序接口的类型与安全级别、安全设计、安全部署、安全集成、安全运 维、服务终止与系统下线、安全管理等 安全技术与安全保障 要求。 本标准适用于商业银行对外互联的应用程序接口的设计和应用，以指导从事或参与商业银行应用程 序接口服务的银行业金融机构、集成接口服务的应用方开展相关工作，并为第三方安全评估机构等单位 开展安全检查与评估工作提供参考（接口类型关系 详见附录 A）。其他类型应用程序接口的设计和应用 可参照本标准执行。 2 规范性引用文件 下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。 凡是不注日期的引用文件，其最新版本（包括所有的修改单

6、）适用于本文件。 GB/T 25069 信息安全技术 术语 JR/T 0071 金融行业信息系统信息安全等级保护实施指引 JR/T 0124 2014 金融机构编码规范 3 术语 和 定义 GB/T 25069界定的以及下列术语和定义适用于本文件。 3.1 应用程序接口 application programming interface 一组预先定义好的功能，开发者可通过该功能（或功能的组合）便捷地访问相关服务，而无需关注 服务的设计与实现。 3.2 应用方 application agency 调用 商业银行应用程序接口 的机构。 3.3 应用程序接口唯一标识 application pro

7、gramming interface unique ID 由商业 银行 自行定义，用于区分 商业银行应用程序接口 功能的唯一标识。 3.4 应用程序接口统一识别码 uniform application programming interface ID 商业银行依据 行业主管部门发布的编码规则，生成的 商业银行应用程序接口 统一识别码。 注： 用于 标识 商业 银行机构代码、接口类型、服务类别、接口顺序号等内容 。 JR/T 0185 2020 2 3.5 应用软件开发工具包 software development kit 基于特定软件包、软件框架、硬件平台、操作系统等建立应用程序时所使用的

8、软件开发工具集合。 3.6 应用唯一标识 application unique ID 在应用方身份核验通过后，根据其调用的金融产品与服务类型，由商业银行为其授予的唯一标识。 注： 包括服务器端 应用标识与移动终端应用软件标识两种。 3.7 应用鉴别密文 application secret 应用合法性鉴别凭证，与应用唯一标识配套使用，以验证通 过 API 方式 接入的应用合法性，接入验 证通过后，即可完成系统对接， 调用应用程序接口或使用应用程序接口提 供的功能和数据。 3.8 移动金融客户端应用软件 financial mobile application software 在移动终端上为用

9、户提供金融 交易 服务的应用软件。 注： 包括但不限于可执行文件、组件等。 3.9 个人金融信息 personal financial information 金融机构通过 提供金融产品和服务 或其他渠道获取、加工和保存的个人信息。 注 1： 包括账户信息、鉴别信息、金融交易信息、个人身份信息、财产信息、 借贷 信息及其他反应特定个人某些情 况的信息。 注 2： 改写 GB/T 35273 2017，定义 3.1。 3.10 支付敏感信息 payment sensitive information 支付信息中涉及支付主体隐私和身份识别的重要信息。 注： 包括但不限于银行卡磁道或芯片信息、卡片验

10、证码、卡片有效期、银行卡密码、网络支付交易密码 等。 3.11 支付账号 payment account 具有金融交易功能的银行账户、非银行支付机构支付账户的编码及银行卡卡号。 JR/T 0149 2016，定义 3.1 3.12 明示同意 explicit consent 个人 金融 信息主体通过书面声明或主动做出肯定性动作，对其个人 金融 信息进行特定处理做出明确 授权的行为。 注： 肯定性动作包括个人信息主体主动作出声明（电子或纸质形式）、主动勾选、主动点击“同意”“注册”“发 送”“拨打”等。 JR/T 0185 2020 3 GB/T 35273 2017，定义 3.6 4 缩略语

11、下列缩略语适用于本文件。 API：应用程序接口（ Application Programming Interface ） API_ID：接口唯一标识 （ Application Programming Interface unique ID） App_ID：应用唯一标识（ Application unique ID ） App_Secret：应用鉴别密文（ Application Secret ） DDoS：分布式拒绝服务攻击（ Distributed Denial of Service） U_API_ID ：应用程序接口统一识别码（ Uniform Application Programmi

12、ng Interface ID） SDK：应用软件开发工具包（ Software Development Kit） SSL：安全套接层协议（ Secure Sockets Layer） TLS：安全传输层协议（ Transport Layer Security） MAC：消息鉴别码（ Message Authentication Code） 5 概述 商业银行应用程序接口服务是一种依托 API 技术实 现 内部与 外 部互联的金融服务模式。商业银行通 过为合作伙伴提供用以互联的应用程序接口，输出自身金融服务能力与信息 技术能力，为增加金融生态 黏性提供有益补充。外部机构能够通过互联网渠道，调用

13、商业银行应用程序接口（外部 API，详见附录 A），获取商业银行提供的各类服务，其逻辑结构见图 1。 商业银行应用程序接口服务的参与方主要包括用户、应用方以及商业银行，商业银行通过 API 直接 连接 或 SDK 间接连接 方式向应用方和用户提供应用程序接口服务，实现商业银行服务的对外输出。 用户发起商业银行应用程序接口应用请求，并接收由应用方或商业银行返回的处理结果。 应用方负责接收并处理用户请求，通过应用程序接口向商业银行提交相关请求、接收返回结果， 依 照流程进行服务请求处理或反馈用户。 商业银行构建商业银行应用程序接口、应用程序接口服务层和银行业务系统以提供商业银行应用程 序接口服务。

14、商业银行应用程序接口服务层将应用方请求转发至银行业务系统处理，并将处理结果反馈 应用方或用户，包含认证鉴权、流量控制、监控分析、报文交换、服务组合等功能，不涉及具体业务逻 辑处理，实现对商业银行应用程序接口和应用方的管理。 JR/T 0185 2020 4 图 1 商业银行应用程序接口逻辑结构图 6 接口 类型与安全级别 6.1 接口类型 商业银行应用程序接口按照应用集成方式，分为服务端对服务端集成方式与移动终端对服务 端集成 方式两种。 对于服务端对服务端集成方式，主要包含两种实现形式： 应用方服务端直接调用商业银行应用程序接口（如 REST、 SOAP 协议） 。 应用方服务端使用商业银行

15、提供的服务端 SDK，间接访问商业银行应用程序接口。 其中，服务端 SDK 主要实现商业银行通用接入算法的封装，为降低应用方接入开发难度，一般此类 SDK 不包含业务逻辑。 对于移动终端对服务端集成方式，主要包含两种实现形式： 应用方移动终端应用软件直接调用商业银行应用程序接口 。 应用方移动终端应用软件使用商业银行提供的移动终端应用 SDK，间接访问商业银 行应用程序 接口。 其中，应用方移动终端应用软件直接调用商业银行应用程序接口的方式，主要以与用户个体无直接 关联的金融服务为主，如提供商业银行公开信息查询、公开服务查询等。 移动终端应用 SDK 除封装商业银行通用接入算法外，还可封装业务

16、逻辑、个人金融信息安全保护（例 如密码数据的安全加固）等功能。 在移动终端对服务端模式下， 对于 仅使用 H5（超文本标记语言 版本 5.0）技术，提供银行 金融 产品 和服务访问链接的 情况 ，由于 H5 页面本身 并未直接调用（或封装）商业银行应用程序接口，不将其单 JR/T 0185 2020 5 独 列为 商业银行应用程序接口的一种 类型 。 6.2 安全级别 按照服务类型将商业银行应用程序接口安全级别划分为两级，安全保护要求从 A2 至 A1 递减： A2：资金交易与账户信息查询应用类，此类金融产品和服务与用户个体直接关联，实施高等级 安全保护强度，此类商业银行应用程序接口包括但不限

17、于： 商业银行通过 SDK，提供资金交易类服务，如支付、转账以及金融产品与服务购买 等 ； 商业银行通过 SDK，提供用户账户信息查询类服务，如账户余额、交易历史、账户限额、 付款时间、金融产品和服务持有情况等； 对于上述服务，若确需使用 API 直接连接 方式进行服务 调用 ，商业银行应对接入风险进行 评估，并制定专门的接口与应用方进行对接，实施高等级的安全保护强度要求。 A1：金融产品和服务信息查询应用类，此类金融产品和服务与用户个体并无直接关联，实施通 用的安全保护强度，此类商业银行应用程序接口包括但不限于：商业银行提供银行金融产品和 服务的详细信息的“只读”查询服务。 7 安全设计 7

18、.1 设计基本要求 商业银行应用程序接口安全设计基本要求 如下 ： 使用的密码 算法、 技术 及 产品 应符合国家密码管理部门及行业主管部门要求 。 应制定安全编码规范 。 应对开发人员进行安全编码培训，并依照安全编码规范进行开发 。 开发中如需使用第三 方应用组件，应对组件进行安全性验证，并持续关注相关平台的 信息 披露 和更新 情况 ，适时更新相关组件 。 应对商业银行应用程序接口进行代码安全专项审计，审计工作可通过人工或工具自动化方式开 展 。 应制定源代码和商业银行应用程序接口版本 管理与控制规程，规范源代码和商业银行应用程序 接口版本管理， 并就接口废止、变更等情况与应用方保持信息同

19、步 。 商业银行向应用方提供的 异常 与调试信息，不应泄漏服务器、中间件、数据库等软硬件信息或 内部网络信息 。 7.2 接口安全设计 7.2.1 身份认证安全 a) 接口身份认证 安全要求 如下 ： 1) 对于应用方身份认证应使用的验证 要素包括： App_ID、 App_Secret。 App_ID、数字证书 。 App_ID、公私钥对 。 上述三种方案的组合。 2) 对于 A2 级别接口 、 应用方身份认证时，应使用包含数字证书或公私钥对的方式进行双向 身份认证 。 b) 用户身份认证安全要求 如下 ： JR/T 0185 2020 6 1) 商业银行应结合金融服务场景，对不同安全级别的

20、商业银行应用程序接口设计不同级别的 用户身份认证机制 。 2) 用户身份认证应在商业银行执行，对于 A2 级别 接口 中的 资 金交易类服务，用户登录身份 认证应至少使用双因子认证的方式来保护账户财产安全。 7.2.2 接口交互安全 商业银行应用程序接口交互安全 要求 如下 ： 商业银行应用程序接口应对 连通 有效性进行验证，如接口版本、参数格式等要素是否与平台设 计保持一致 。 应对通过商业银行应用程序接口进行交互的数据进行完整性保护，对于 A2 级别的接口，商业 银行和应用方应使用数字签名来保证数据的完整性和不可抵赖性 。 对于支付敏感信息等个人金融信息，应采取以下措施进行安全交互： 登录

21、口令、支付密码等支付敏感信息在数据交互过程中应使用包括但不限于替换输入框原 文 、 自定义软键盘 、 防键盘窃听、防截屏等安全防护措施，保证无法获取支付敏感信息明 文； 账号、卡号、卡有效期、姓名、证件号 码 、 手机号码等个人金融信息在传输过 程中 应 使用 集成在 SDK 中的加密组件进行加密， 或 对相关报文进行整体加密处理； 若确需使用商业银 行应用程序接口将账号、卡号、姓名向应用方进行反馈，应脱敏或去标识化处理，因清分 与清算、差错对账等需求，确需将卡号等支付账号传输至应用方时，应使用加密通道进行 传输，并采取措施保证信息的完整性； 对于金融产品持有份额、用户积分等 A2 类只读信息

22、查询，可使用 API 直接连接 方式进行 查询请求对接，应采取加密等措施保证查询信息的完整性与保密性，查询结果在应用方本 地不得保存。 应在 交易 认证结束后及时清除用 户支付敏感信息，防范攻击者通过读取临时文件、内存数据等 方式获得全部或部分用户信息。 7.3 服务安全设计 7.3.1 授权管理 商业银行应根据不同应用方的服务需求，按照最小授权原则，对其相应接口权限进行授权管理，当 服务需求变更时，需及时评估和调整接口权限。 7.3.2 攻击防护 服务安全设计应具备以下攻击防护能力： API 和 SDK 应对常见的网络攻击具有安全防护能力 。 移动终端应用 SDK 应具备静态逆向分析防护能力

23、，防范攻击者通过静态反汇编、字符串分析、 导入导出函数识别、配置文件分析等手段获得有关 SDK 实现方式的技术细节 。 移动终端应用 SDK 宜具备动态调试防护能力，包括但不限于：具有防范攻击者通过挂接动态调 试器、动态跟踪程序的方式控制程序行为的能力；具有防范攻击者通过篡改文件、动态修改内 存代码等方式控制程序行为的能力。 7.3.3 安全监控 安全监控安全要求 如下 ： JR/T 0185 2020 7 商业银行应对接口使用情况进行监控，完整记录接口访问日志。 日志应满足以下要求： 商业银行相关日志应至少包括交易流水号、应用唯一标识、接口唯一标识、调用耗时、时 间戳、返回结果（成功或失败）

24、等； 因清分清算、差错对账等业务需要，应用方接口日志中应以部分屏蔽的方式记录支付账号 （或其等效信息），除此之外 的个人金融信息不应在应用方接口日志中进行记录。 7.3.4 密钥管理 密钥管理安全要求 如下 ： 加密和签名宜分配不同的密钥，且相互分离 。 不应以编码的方式将私钥明文（或密文）编写在商业银行应用程序相关代码中， App_Secret 或私钥不应存储于商业银行与应用方本地配置文件中，防止因代码泄露引发密钥泄露 。 应依据商业银行应用程序接口等级设置不同的密钥有效期，并对密钥进行定期更新。 8 安全 部署 商业银行与应用方应遵循商业银行应用程序接口网络部署逻辑结构示意图，见图 2，进

25、行商业银行 应用程序接口的安全部署。商业银行及应用方都应在互 联网边界部署如防火墙、 IDS/IPS、 DDoS防护等 具备访问控制、入侵防范相关安全防护能力的网络安全防护措施。 JR/T 0185 2020 8 互联网 / 移动互联网 商业银行应用程序接 口服务层 网络安全防护措施 A P I 业务处理转接服务 应用总线 业务系统 1 业务系统 2 业务系统 3 业务系统 . 核心内部系统 . . . . . . 报文交换 流量控制 监控分析 服务组合 . 认证鉴权 银行业务层 网络安全防护措施 . 认证鉴权 . . 报文交换 服务组合 应用端 通信网络 网络安全防护措施 服务端对 服务端集

26、成 S D K 间接连接直接连接 移动终端 对服务端 集成 S D K 间接连接直接连接 A P I 业务处理转接服务 图 2 商业银行应用程序接口网络部署示意图 商业银行应用程序接口服务层应部署流量控制、监控分析、认证鉴权、报文交换、服务组合等服务， 其中认证鉴权、报文交换、服务组合等服务也可部署在银行业务层。商业银行应用程序接口服务层与银 行业务层之间应部署如防火墙等具备相关访问控制、入侵防范安全防护能力的网络安全防护措施。 应用方服务器应部署在应用方互联网 接入安全防护设备之后的逻辑隔离区域，通过互联网、移动互 联网网络访问商业银行应用程序接口相关应用服务。 商业银行的安全控制要求依据

27、JR/T 0071 部署相应级别的安全控制措施。应用方部署商业银行应用 程序接口有关安全控制措施，应符合国家网络安全等级保护有关标准二级及以上安全要求。 JR/T 0185 2020 9 9 安全 集成 9.1 应用方 核准 9.1.1 应用方准入 商业银行 应对申请接入 商业银行应用程序接口 的应用方进行审核 ， 并制 定 和签署 相关 合作协议 ： 应对应用方开展准入审核 ,如从服务客群、服务场景、市场份额、运营能力、风控能力等方面 对意向应用方进行考察 。 应在应用方申请接入时全面审慎地考察、评估应用方的技术能力和管理水平，将用户信息保护 能力作为重要评价指标，必要时应对应用方的安全保护

28、能力进行技术评估，评估的范围包括但 不限于应用方信息安全建设水平等内容 。 应制定商业银行应用程序接口合作协议，对合作业务场景、接口应用范围与交易量预期、应用 程序接口集成模式、不可 访问未授权的信息、用户信息安全保障责任、交易安全保障责任等条 款与应用方进行约定 。 不应通过开放应用程序接口的方式变相开展跨机构清算业务。 9.1.2 应用方身份核验 商业银行在应用方接入注册与审批阶段，应通过线上或线 下手段，对应用方身份进行核验和管理： 应用方应按照 商业 银行要求，提交必要的身份核验资料，包括运营资质、法人信息材料、主要 应用开发人员的个人信息身份材料等 。 应对应用方提交资料的有效性、完

29、整性、真实性进行审核， 对应用方身份进行合规性核验 。 9.2 接入 安全控制 9.2.1 身份认证 商业银行与应用方之间的身份认证要求 如下 ： a) 应用方身份声明： 1) 应用方 准入审核 通过后，商业银行配置唯一标识 App_ID 及与之相匹配的应用鉴别密文 App_Secret、数字证书 （或公私钥对） 或应用鉴别密文 App_Secret 与数字证书 （或公私 钥对） 的组合。 对于采用公私钥对方式认证的 情况 ，商业银行应对应用方上传的公钥进行 登记 。 2) 商业银行应对应用唯一标识 App_ID 进行存储与统一管理，并根据应用唯一标识 App_ID 进行应用身份认证、状态校验

30、和权限控制等。 b) 应用方身份认证： 1) 应用方在请求商业银行应用程序接口时，商业银行应对应用方身份进行认证，认证方式包 括但不限于以下任意一种方式： 基于应用唯一标识 App_ID 和应用鉴别密文 App_Secret 对应用方身份进行认证 。 基于应用唯一标识 App_ID 和数字证书方式对应用方进行身份认证 。 基于应用唯一标识 App_ID 和公私钥对方式对应用方进行身份认证 。 基于应用唯一标识 App_ID 与应用鉴别密文 App_Secret、数字证书（或公私钥对）的 组合，对应用方进行身份认证。 2) 对于 A2 类，应用方身份认证应使用 1）中 第二条 至 第四 条给出的

31、任意一种方式进行双向 身份认证 。 JR/T 0185 2020 10 3) 商业银行应对商业银行应用程序接口连接时间进行限制（如设置接口会话或令牌有效期）， 依据业务必须的最小时间设计有效期，避免长期有效连接 。 4) 商业银行应具备对商业银行应用程序接口主动断开连接（如主动失效令牌）的功能，具备 发现恶意连接可主动处理的能力。 9.2.2 安全传输 商 业银行与应用方之间使用互联网方式进行数据传输应符合下列安全要求： 对于 A1 类应采用 MAC 校验等手段，保证商业银行与应用方之间数据传输的完整性，必要时可 使用数字签名技术 。 对于 A2 类应采用数字签名等手段，保证商业银行与应用方之

32、间数据传输的完整性与不可抵赖 性 。 应采用 SSL/TLS 等安全通道连接进行通信，宜使用 TLS 1.2 及以上版本。 9.3 运行安全 9.3.1 用户身份认证 商业 银行对用户身份的认证要求 如下 ： 用户身份认证应在商业银行完成，若用户个人金融信息或支付敏感信息确需在应用方输入，应 用方不应以任何方式在本地留存相关 信息 。 商业银行应对应用方上送的用户相关信息进行核验 。 商业银行应结合具体场景，依据业务必须的最小时间设计用户会话有效期，用户长期处于无业 务操作时，应结束会话。 9.3.2 权限控制 商业 银行应对接口权限进行有效控制 ，包括： 商业银行应用程序接口权限控制应满足以

33、下安全要求： 商业银行应按应用方、应用唯一标识 App_ID、接口、用户等维度， 依据 最小 授权 原则进 行授权，对于未授权的资源禁止访问； 对于获取、使用、变更用户信息、账户、资金等接口，应用方调用接口时，应首先取得用 户明示同意，其内容应包含授权有效期； 商 业 银行 应对 API 的调用有效期进行控制（如单次有效、阶段性有效、协议期限内有效）。 商业银行应为用户提供关闭商业银行应用程序接口相关服务的 申请 渠道，如电子银行或营业网 点等。 9.3.3 数据安全 应用方在数据安全保护方面 的 安全要求 如下 ： 数据完整性保护：应对数据完整性进行校验，并在检测到完整性错误时采取必要的恢复

34、措施（或 停止执行请求） 。 数据机密性保护： 不应采集、存储用户个人金融信息或支付敏感信息； 对于需要用户输入支付敏感信息或身份鉴别信息的场景，应用方仅可作为信息的采集与传 输通道，应部署商业银行 SDK、采取报文加 密等措施，保证采集与传输信息的机密性与完 整性，支付敏感信息与身份鉴别信息在应用方不得 留存 。 JR/T 0185 2020 11 数据抗抵赖性保护：应使用数字签名等技术确保 A2 类数据的不可抵赖性 。 数据删除与销毁：在合作终止后，应依据与商业银行约定的方式删除（或销毁）通过商业银行 应用程序接口获取的商业银行及其用户的相关数据 。 应针对接口处理的数据，建立数据备份管理

35、机制和应急灾备机制，并纳入机构灾备体系。 在合 作终止后，应依据行业主管部门有关要求，履行反洗钱、反欺诈等义务。 9.3.4 应用方安全能力 应用方在安全能力方面 的 要求 如下 ： 应符合国家网络安全等级保 护相应要求，进行安全设计、安全建设、安全保护 。 应遵循商业银行的安全设计要求，使用商业银行提供的安全接口，并依据用户手册和安全规范 进行集成 。 应留存与商业银行应用程序接口集成相关的应用系统、网络设备、主机设备、安全产品日志， 日志保留期应满足国家与行业主管部门要求，日志留存应不少于 6 个月 。 应通过技术手段与管理措施等，防止接口滥用。 9.3.5 应用方接口集成 应用方在接口集

36、成方面 的 要求 如下 ： 应用方应根据商业银行提供的用户手册以及商业银行授权其使用的服务类型，正确合理使用 API。 应用方密钥存储应采取加密等方式进行安全 防护，防范密钥丢失或泄露，应用方应按照商业银 行提供的用户手册，妥善使用和保管相关密钥、数字证书 。 如商业银行提供封装了商业银行应用程序接口调用的 SDK，则应用方需使用商业银行提供的 SDK 进行 API 调用，应用方不得对 商业 银行提供的 SDK 进行反编译、篡改或二次封装 。 若应用方发现商业银行应用程序接口存在安全缺陷，应采取补救措施并及时通知商业银行。应 用方未经商业银行许可，不得将缺陷细节透露给任何其他第三方 。 禁止应

37、用方利用商业银行应用程序接口漏洞，进行网络攻击、信息窃取或交易欺诈等非法操作。 9.4 应用方 退出 应用方退 出时，商业银行应制定有序、可行的应用方退出机制，保障账户、资金、信息安全，充分 履行用户告知义务 。 应用方退出后， 商业银行应对认证信息 （如 App_Secret、公私钥对等） 进行作废处 理，归档并保存待查。 应用方应按照商业银行的要求，妥善处理其通过商业银行应用程序接口获取的用户信息与商业银行 业务有关资料，并在双方协定的期限内承担后续的保密责任。 10 安全运维 10.1 安全监测 10.1.1 运维监测 运维监测 的 要求 如下 ： 商业银行应建立商业银行应用程序接口运维

38、监测平台，或将商业银行应用程序接口运维监测纳 入 商业 银行统一监测平台并重点监测。 运维监测应具备以下监测能力： JR/T 0185 2020 12 监控商业银行应用程序接口相关服务器运行状态并建立告警机制； 监控商业银行应用程序接口服务状态（包括耗时、交易量、成功率等参数）并建立告警机 制； 商业银行交易日志应按照国家会计准则要求予以保存，系统日志保存期限不少于 1 年。 应用方应对其集成商业银行应用程序接口运行状态进行监测，发现异常应及时处置。 10.1.2 异常监测 异常监测 的 要求 如下 ： 商业银行应具备流量监控、故障隔离、黑名单控制等商业银行应用程序接口调用控制能力： 应具备商

39、业银行应用程序接口调用流量控制能力，控制规则包括最大允许商业银 行应用程 序接口调用并发数、单位时间最大交易调用量等，控制措施包括告警、暂停、拒绝等； 应建立未授权和冒用商业银行应用程序接口的监测机制，发现问题及时处置； 应具备故障监测和恢复能力； 应具备应用方黑名单管理能力 。 应用方应具备故障识别与隔离能力： 调用商业银行应用程序接口应设计熔断机制，熔断规则包括设置失败笔数阈值、商业银行 应用程序接口调用失败阈值等，熔断措施包括拒绝交易、暂停服务调用等； 调用商业银行应用程序接口应建立异常告警处理机制 。 10.2 风险控制 10.2.1 服务风险控制 商业银行实施服务风险控制 的 要求

40、如下 ： 应建立 应用方信息（如运营能力、风控能力等）更新和复审机制 。 应根据应用方调用商业银行应用程序接口的业务日志等信息，定期评估其金融交易业务的运营 情况，并在协议框架内对异常的业务调用进行监控，必要时进行业务限流，并及时通知应用方 进行事件调查 。 应评估应用方的风险承受能力，确保用户与应用方相关的账户关联、服务类型、交易额度等与 其风险承受能力相匹配。 10.2.2 交易流程控制 交易流程控制 的 要求 如下 ： 身份认证服务等授权类服务应充分识别是否经过用户本人授权 。 账户查询、资金交易、金融产品及服务申请类交易，应充分识别交易是否由用户本人 发起（或 本人授权发起），核实用户

41、本人意愿 。 资金类等高风险金融服务，应提示用户相关的安全风险，充分履行用户告知义务。 10.2.3 交易风险监控 商业银行交易风险监控 的 要求 如下 ： 应将商业银行应用程序接口纳入银行风险监控范围，对应用方和用户账户资金活动情况进行实 时监控 。 资金交易应满足行业监管部门对反洗钱、反欺诈方面的相关要求 。 对大额、异常的资金收付应逐笔监测与核查 ， 及时预警、及时控制 。 JR/T 0185 2020 13 对监控到的风险交易 应 进行及时分析与处置。 10.3 变更控制 接口变更 的 要求 如下 ： 商业银行应用程序接口发生变更时，应及时评估影响并告知应用方 ，制定变更方案和应急预案

42、， 按需进行接口变更发布，并充分履行用户告知义务 。 应用方对商业银行应用程序接口的使用发生重大变更时，如其交易量预期发生变化、对 商业银 行应用程序接口集成方案进行修改等可能对 商业 银行系统安全性、业务连续性等造成重大影响 的有关事项，应制定变更方案和应急预案，评估变更带来的风险，并及时告知 商业 银行，同时 充分履行用户告知义务 。 应用方使用商业银行应用程序接口发生重大变更时，商业银行应对其变更进行风险和影响评 估，并采取相应的处置措施。 10.4 运维巡检 商业银行应定期对商业银行应用程序接口进 行安全巡检，包括： 应对商业银行应用程序接口进行源代码安全审计、渗透测试等技术检查，及时

43、处理安全漏洞， 有效控制安全风险 。 应对应用方的商业银行应用程序接口安全集成情况进行检查。 应用方应定期对商业银行应用程序接口进行安全巡检，包括：应定期对其调用商业银行应用程序接 口的应用系统进行安全评估，及时处理安全漏洞，确保调用的真实有效。 10.5 事件处理 商业银行应制定应急处理方案，对运维过程中监测到的异常情况及时告警和处置，及时处理生产事 件，并协调应用方配合事件调查。 11 服务终止 与系统下线 商业银行应制定完善的服务终止和系统 （接口） 下线的相关制度和步骤，以便各参与方有序处理相 关服务： 服务终止 前 ，商业银行应将服务终止有关事项提前告知相关方，并向相关平台提交有关接

44、口的 统一识别码注销申请 。 商业银行应与应用方就服务终止后相关数据归档、数据删除（或销毁）、个人金融信息保护、 用户资金和账户安全、消费者权益保护等问题充分达成一致，明确相关责任，并充分履行用户 告知义务 。 系统 （接口） 下线应在相关服务确认终止之后执行，在下线之前应设置挡板（如服务终止提示 信息），明示应用方服务已终止 。 商业银行在系统 （接口） 下线之后应将有关数据进行归档处理， 数据保留期限应按照国家与行 业主管部门、 商业 银行相关规定与规则执行。 12 安全 管理 12.1 管理 制度 JR/T 0185 2020 14 商业银行 管理制度要求如下： 应将商业银行应用程序接口的管理纳入 商业 银行现 行 管理体系中，对商业银行应用程序接口进 行全生命周期的安全管理 。 应用程序接口应采用统一格式的识别码，并在相关平台进行注册和登记，编码规则详见附录 B。 应建立信息公告制度，通过官方网站等公开渠道发布其商业银行应用程序接口内容，并及时更 新 。 应建立覆盖商业银行应用程序接口全生命周期的应用安全管理制度与控制措施，并对管理制度 与控制措施的有效性进行验证，以 确保商业银行应用程序接口的一致性和连贯性，保障商业银 行应用程序接口效率及安全性 。 应提供开发手册以指导应用方安全集成商业银行应用程序接口，开发手册包括但不限于安全集