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

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

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

ICS35.240.40A11JR中华人民共和国金融行业标准JR/T01852020商业银行应用程序接口安全管理规范Commercialbankapplicationprogramminginterfacesecuremanagementspecification2020-02-13发布2020-02-13实施中国人民银行发布JR/T01852020I目次前言.II1范围.12规范性引用文件.13术语和定义.14缩略语.35概述.36接口类型与安全级别.47安全设计.58安全部署.79安全集成.910安全运维.1111服务终止与系统下线.1312安全管理.13附录A（规范性附录）商业银行应用程序接口关系示意.15附录B（规范性附录）商业银行应用程序接口统一识别码编码规则.16参考文献.18JR/T01852020II前言本标准按照GB/T1.12009给出的规则起草。

本标准由中国人民银行提出。

本标准由全国金融标准化技术委员会（SAC/TC180）归口。

本标准起草单位：

中国人民银行科技司、中国金融电子化公司、中国银联股份有限公司、中国工商银行股份有限公司、中国农业银行股份有限公司、中国银行股份有限公司、中国建设银行股份有限公司、中国邮政储蓄银行股份有限公司、招商银行股份有限公司、上海浦东发展银行股份有限公司、中信银行股份有限公司、兴业银行股份有限公司、中国民生银行股份有限公司、中国光大银行股份有限公司、平安银行股份有限公司、广发银行股份有限公司、北京银行股份有限公司、徽商银行股份有限公司、山东省城市商业银行合作联盟有限公司、齐鲁银行股份有限公司、浙江网商银行股份有限公司、中信百信银行股份有限公司、山东省农村信用社联合社、北京中金国盛认证有限公司、北京银联金卡科技有限公司、中金金融认证中心有限公司、中国外汇交易中心。

JR/T018520201商业银行应用程序接口安全管理规范1范围本标准规定了商业银行应用程序接口的类型与安全级别、安全设计、安全部署、安全集成、安全运维、服务终止与系统下线、安全管理等安全技术与安全保障要求。

本标准适用于商业银行对外互联的应用程序接口的设计和应用，以指导从事或参与商业银行应用程序接口服务的银行业金融机构、集成接口服务的应用方开展相关工作，并为第三方安全评估机构等单位开展安全检查与评估工作提供参考（接口类型关系详见附录A）。

其他类型应用程序接口的设计和应用可参照本标准执行。

2规范性引用文件下列文件对于本文件的应用是必不可少的。

凡是注日期的引用文件，仅注日期的版本适用于本文件。

凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。

GB/T25069信息安全技术术语JR/T0071金融行业信息系统信息安全等级保护实施指引JR/T01242014金融机构编码规范3术语和定义GB/T25069界定的以及下列术语和定义适用于本文件。

3.1应用程序接口applicationprogramminginterface一组预先定义好的功能，开发者可通过该功能（或功能的组合）便捷地访问相关服务，而无需关注服务的设计与实现。

3.2应用方applicationagency调用商业银行应用程序接口的机构。

3.3应用程序接口唯一标识applicationprogramminginterfaceuniqueID由商业银行自行定义，用于区分商业银行应用程序接口功能的唯一标识。

3.4应用程序接口统一识别码uniformapplicationprogramminginterfaceID商业银行依据行业主管部门发布的编码规则，生成的商业银行应用程序接口统一识别码。

注：

用于标识商业银行机构代码、接口类型、服务类别、接口顺序号等内容。

JR/T0185202023.5应用软件开发工具包softwaredevelopmentkit基于特定软件包、软件框架、硬件平台、操作系统等建立应用程序时所使用的软件开发工具集合。

3.6应用唯一标识applicationuniqueID在应用方身份核验通过后，根据其调用的金融产品与服务类型，由商业银行为其授予的唯一标识。

注：

包括服务器端应用标识与移动终端应用软件标识两种。

3.7应用鉴别密文applicationsecret应用合法性鉴别凭证，与应用唯一标识配套使用，以验证通过API方式接入的应用合法性，接入验证通过后，即可完成系统对接，调用应用程序接口或使用应用程序接口提供的功能和数据。

3.8移动金融客户端应用软件financialmobileapplicationsoftware在移动终端上为用户提供金融交易服务的应用软件。

注：

包括但不限于可执行文件、组件等。

3.9个人金融信息personalfinancialinformation金融机构通过提供金融产品和服务或其他渠道获取、加工和保存的个人信息。

注1：

包括账户信息、鉴别信息、金融交易信息、个人身份信息、财产信息、借贷信息及其他反应特定个人某些情况的信息。

注2：

改写GB/T352732017，定义3.1。

3.10支付敏感信息paymentsensitiveinformation支付信息中涉及支付主体隐私和身份识别的重要信息。

注：

包括但不限于银行卡磁道或芯片信息、卡片验证码、卡片有效期、银行卡密码、网络支付交易密码等。

3.11支付账号paymentaccount具有金融交易功能的银行账户、非银行支付机构支付账户的编码及银行卡卡号。

JR/T01492016，定义3.13.12明示同意explicitconsent个人金融信息主体通过书面声明或主动做出肯定性动作，对其个人金融信息进行特定处理做出明确授权的行为。

注：

肯定性动作包括个人信息主体主动作出声明（电子或纸质形式）、主动勾选、主动点击“同意”“注册”“发送”“拨打”等。

JR/T018520203GB/T352732017，定义3.64缩略语下列缩略语适用于本文件。

API：

应用程序接口（ApplicationProgrammingInterface）API_ID：

接口唯一标识（ApplicationProgrammingInterfaceuniqueID）App_ID：

应用唯一标识（ApplicationuniqueID）App_Secret：

应用鉴别密文（ApplicationSecret）DDoS：

分布式拒绝服务攻击（DistributedDenialofService）U_API_ID：

应用程序接口统一识别码（UniformApplicationProgrammingInterfaceID）SDK：

应用软件开发工具包（SoftwareDevelopmentKit）SSL：

安全套接层协议（SecureSocketsLayer）TLS：

安全传输层协议（TransportLayerSecurity）MAC：

消息鉴别码（MessageAuthenticationCode）5概述商业银行应用程序接口服务是一种依托API技术实现内部与外部互联的金融服务模式。

商业银行通过为合作伙伴提供用以互联的应用程序接口，输出自身金融服务能力与信息技术能力，为增加金融生态黏性提供有益补充。

外部机构能够通过互联网渠道，调用商业银行应用程序接口（外部API，详见附录A），获取商业银行提供的各类服务，其逻辑结构见图1。

商业银行应用程序接口服务的参与方主要包括用户、应用方以及商业银行，商业银行通过API直接连接或SDK间接连接方式向应用方和用户提供应用程序接口服务，实现商业银行服务的对外输出。

用户发起商业银行应用程序接口应用请求，并接收由应用方或商业银行返回的处理结果。

应用方负责接收并处理用户请求，通过应用程序接口向商业银行提交相关请求、接收返回结果，依照流程进行服务请求处理或反馈用户。

商业银行构建商业银行应用程序接口、应用程序接口服务层和银行业务系统以提供商业银行应用程序接口服务。

商业银行应用程序接口服务层将应用方请求转发至银行业务系统处理，并将处理结果反馈应用方或用户，包含认证鉴权、流量控制、监控分析、报文交换、服务组合等功能，不涉及具体业务逻辑处理，实现对商业银行应用程序接口和应用方的管理。

JR/T018520204图1商业银行应用程序接口逻辑结构图6接口类型与安全级别6.1接口类型商业银行应用程序接口按照应用集成方式，分为服务端对服务端集成方式与移动终端对服务端集成方式两种。

对于服务端对服务端集成方式，主要包含两种实现形式：

应用方服务端直接调用商业银行应用程序接口（如REST、SOAP协议）。

应用方服务端使用商业银行提供的服务端SDK，间接访问商业银行应用程序接口。

其中，服务端SDK主要实现商业银行通用接入算法的封装，为降低应用方接入开发难度，一般此类SDK不包含业务逻辑。

对于移动终端对服务端集成方式，主要包含两种实现形式：

应用方移动终端应用软件直接调用商业银行应用程序接口。

应用方移动终端应用软件使用商业银行提供的移动终端应用SDK，间接访问商业银行应用程序接口。

其中，应用方移动终端应用软件直接调用商业银行应用程序接口的方式，主要以与用户个体无直接关联的金融服务为主，如提供商业银行公开信息查询、公开服务查询等。

移动终端应用SDK除封装商业银行通用接入算法外，还可封装业务逻辑、个人金融信息安全保护（例如密码数据的安全加固）等功能。

在移动终端对服务端模式下，对于仅使用H5（超文本标记语言版本5.0）技术，提供银行金融产品和服务访问链接的情况，由于H5页面本身并未直接调用（或封装）商业银行应用程序接口，不将其单JR/T018520205独列为商业银行应用程序接口的一种类型。

6.2安全级别按照服务类型将商业银行应用程序接口安全级别划分为两级，安全保护要求从A2至A1递减：

A2：

资金交易与账户信息查询应用类，此类金融产品和服务与用户个体直接关联，实施高等级安全保护强度，此类商业银行应用程序接口包括但不限于：

商业银行通过SDK，提供资金交易类服务，如支付、转账以及金融产品与服务购买等；商业银行通过SDK，提供用户账户信息查询类服务，如账户余额、交易历史、账户限额、付款时间、金融产品和服务持有情况等；对于上述服务，若确需使用API直接连接方式进行服务调用，商业银行应对接入风险进行评估，并制定专门的接口与应用方进行对接，实施高等级的安全保护强度要求。

A1：

金融产品和服务信息查询应用类，此类金融产品和服务与用户个体并无直接关联，实施通用的安全保护强度，此类商业银行应用程序接口包括但不限于：

商业银行提供银行金融产品和服务的详细信息的“只读”查询服务。

7安全设计7.1设计基本要求商业银行应用程序接口安全设计基本要求如下：

使用的密码算法、技术及产品应符合国家密码管理部门及行业主管部门要求。

应制定安全编码规范。

应对开发人员进行安全编码培训，并依照安全编码规范进行开发。

开发中如需使用第三方应用组件，应对组件进行安全性验证，并持续关注相关平台的信息披露和更新情况，适时更新相关组件。

应对商业银行应用程序接口进行代码安全专项审计，审计工作可通过人工或工具自动化方式开展。

应制定源代码和商业银行应用程序接口版本管理与控制规程，规范源代码和商业银行应用程序接口版本管理，并就接口废止、变更等情况与应用方保持信息同步。

商业银行向应用方提供的异常与调试信息，不应泄漏服务器、中间件、数据库等软硬件信息或内部网络信息。

7.2接口安全设计7.2.1身份认证安全a）接口身份认证安全要求如下：

1）对于应用方身份认证应使用的验证要素包括：

App_ID、App_Secret。

App_ID、数字证书。

App_ID、公私钥对。

上述三种方案的组合。

2）对于A2级别接口、应用方身份认证时，应使用包含数字证书或公私钥对的方式进行双向身份认证。

b）用户身份认证安全要求如下：

JR/T0185202061）商业银行应结合金融服务场景，对不同安全级别的商业银行应用程序接口设计不同级别的用户身份认证机制。

2）用户身份认证应在商业银行执行，对于A2级别接口中的资金交易类服务，用户登录身份认证应至少使用双因子认证的方式来保护账户财产安全。

7.2.2接口交互安全商业银行应用程序接口交互安全要求如下：

商业银行应用程序接口应对连通有效性进行验证，如接口版本、参数格式等要素是否与平台设计保持一致。

应对通过商业银行应用程序接口进行交互的数据进行完整性保护，对于A2级别的接口，商业银行和应用方应使用数字签名来保证数据的完整性和不可抵赖性。

对于支付敏感信息等个人金融信息，应采取以下措施进行安全交互：

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

应在交易认证结束后及时清除用户支付敏感信息，防范攻击者通过读取临时文件、内存数据等方式获得全部或部分用户信息。

7.3服务安全设计7.3.1授权管理商业银行应根据不同应用方的服务需求，按照最小授权原则，对其相应接口权限进行授权管理，当服务需求变更时，需及时评估和调整接口权限。

7.3.2攻击防护服务安全设计应具备以下攻击防护能力：

API和SDK应对常见的网络攻击具有安全防护能力。

移动终端应用SDK应具备静态逆向分析防护能力，防范攻击者通过静态反汇编、字符串分析、导入导出函数识别、配置文件分析等手段获得有关SDK实现方式的技术细节。

移动终端应用SDK宜具备动态调试防护能力，包括但不限于：

具有防范攻击者通过挂接动态调试器、动态跟踪程序的方式控制程序行为的能力；具有防范攻击者通过篡改文件、动态修改内存代码等方式控制程序行为的能力。

7.3.3安全监控安全监控安全要求如下：

JR/T018520207商业银行应对接口使用情况进行监控，完整记录接口访问日志。

日志应满足以下要求：

商业银行相关日志应至少包括交易流水号、应用唯一标识、接口唯一标识、调用耗时、时间戳、返回结果（成功或失败）等；因清分清算、差错对账等业务需要，应用方接口日志中应以部分屏蔽的方式记录支付账号（或其等效信息），除此之外的个人金融信息不应在应用方接口日志中进行记录。

7.3.4密钥管理密钥管理安全要求如下：

加密和签名宜分配不同的密钥，且相互分离。

不应以编码的方式将私钥明文（或密文）编写在商业银行应用程序相关代码中，App_Secret或私钥不应存储于商业银行与应用方本地配置文件中，防止因代码泄露引发密钥泄露。

应依据商业银行应用程序接口等级设置不同的密钥有效期，并对密钥进行定期更新。

8安全部署商业银行与应用方应遵循商业银行应用程序接口网络部署逻辑结构示意图，见图2，进行商业银行应用程序接口的安全部署。

商业银行及应用方都应在互联网边界部署如防火墙、IDS/IPS、DDoS防护等具备访问控制、入侵防范相关安全防护能力的网络安全防护措施。

JR/T018520208互联网/移动互联网商业银行应用程序接口服务层网络安全防护措施API业务处理转接服务应用总线业务系统1业务系统2业务系统3业务系统.核心内部系统.报文交换流量控制监控分析服务组合.认证鉴权银行业务层网络安全防护措施.认证鉴权.报文交换服务组合应用端通信网络网络安全防护措施服务端对服务端集成SDK间接连接直接连接移动终端对服务端集成SDK间接连接直接连接API业务处理转接服务图2商业银行应用程序接口网络部署示意图商业银行应用程序接口服务层应部署流量控制、监控分析、认证鉴权、报文交换、服务组合等服务，其中认证鉴权、报文交换、服务组合等服务也可部署在银行业务层。

商业银行应用程序接口服务层与银行业务层之间应部署如防火墙等具备相关访问控制、入侵防范安全防护能力的网络安全防护措施。

应用方服务器应部署在应用方互联网接入安全防护设备之后的逻辑隔离区域，通过互联网、移动互联网网络访问商业银行应用程序接口相关应用服务。

商业银行的安全控制要求依据JR/T0071部署相应级别的安全控制措施。

应用方部署商业银行应用程序接口有关安全控制措施，应符合国家网络安全等级保护有关标准二级及以上安全要求。

JR/T0185202099安全集成9.1应用方核准9.1.1应用方准入商业银行应对申请接入商业银行应用程序接口的应用方进行审核，并制定和签署相关合作协议：

应对应用方开展准入审核,如从服务客群、服务场景、市场份额、运营能力、风控能力等方面对意向应用方进行考察。

应在应用方申请接入时全面审慎地考察、评估应用方的技术能力和管理水平，将用户信息保护能力作为重要评价指标，必要时应对应用方的安全保护能力进行技术评估，评估的范围包括但不限于应用方信息安全建设水平等内容。

应制定商业银行应用程序接口合作协议，对合作业务场景、接口应用范围与交易量预期、应用程序接口集成模式、不可访问未授权的信息、用户信息安全保障责任、交易安全保障责任等条款与应用方进行约定。

不应通过开放应用程序接口的方式变相开展跨机构清算业务。

9.1.2应用方身份核验商业银行在应用方接入注册与审批阶段，应通过线上或线下手段，对应用方身份进行核验和管理：

应用方应按照商业银行要求，提交必要的身份核验资料，包括运营资质、法人信息材料、主要应用开发人员的个人信息身份材料等。

应对应用方提交资料的有效性、完整性、真实性进行审核，对应用方身份进行合规性核验。

9.2接入安全控制9.2.1身份认证商业银行与应用方之间的身份认证要求如下：

a）应用方身份声明：

1）应用方准入审核通过后，商业银行配置唯一标识App_ID及与之相匹配的应用鉴别密文App_Secret、数字证书（或公私钥对）或应用鉴别密文App_Secret与数字证书（或公私钥对）的组合。

对于采用公私钥对方式认证的情况，商业银行应对应用方上传的公钥进行登记。

2）商业银行应对应用唯一标识App_ID进行存储与统一管理，并根据应用唯一标识App_ID进行应用身份认证、状态校验和权限控制等。

b）应用方身份认证：

1）应用方在请求商业银行应用程序接口时，商业银行应对应用方身份进行认证，认证方式包括但不限于以下任意一种方式：

基于应用唯一标识App_ID和应用鉴别密文App_Secret对应用方身份进行认证。

基于应用唯一标识App_ID和数字证书方式对应用方进行身份认证。

基于应用唯一标识App_ID和公私钥对方式对应用方进行身份认证。

基于应用唯一标识App_ID与应用鉴别密文App_Secret、数字证书（或公私钥对）的组合，对应用方进行身份认证。

2）对于A2类，应用方身份认证应使用1）中第二条至第四条给出的任意一种方式进行双向身份认证。

JR/T01852020103）商业银行应对商业银行应用程序接口连接时间进行限制（如设置接口会话或令牌有效期），依据业务必须的最小时间设计有效期，避免长期有效连接。

4）商业银行应具备对商业银行应用程序接口主动断开连接（如主动失效令牌）的功能，具备发现恶意连接可主动处理的能力。

9.2.2安全传输商业银行与应用方之间使用互联网方式进行数据传输应符合下列安全要求：

对于A1类应采用MAC校验等手段，保证商业银行与应用方之间数据传输的完整性，必要时可使用数字签名技术。

对于A2类应采用数字签名等手段，保证商业银行与应用方之间数据传输的完整性与不可抵赖性。

应采用SSL/TLS等安全通道连接进行通信，宜使用TLS1.2及以上版本。

9.3运行安全9.3.1用户身份认证商业银行对用户身份的认证要求如下：

用户身份认证应在商业银行完成，若用户个人金融信息或支付敏感信息确需在应用方输入，应用方不应以任何方式在本地留存相关信息。

商业银行应对应用方上送的用户相关信息进行核验。

商业银行应结合具体场景，依据业务必须的最小时间设计用户会话有效期，用户长期处于无业务操作时，应结束会话。

9.3.2权限控制商业银行应对接口权限进行有效控制，包括：

商业银行应用程序接口权限控制应满足以下安全要求：

商业银行应按应用方、应用唯一标识App_ID、接口、用户等维度，依据最小授权原则进行授权，对于未授权的资源禁止访问；对于获取、使用、变更用户信息、账户、资金等接口，应用方调用接口时，应首先取得用户明示同意，其内容应包含授权有效期；商业银行应对API的调用有效期进行控制（如单次有效、阶段性有效、协议期限内有效）。

商业银行应为用户提供关闭商业银行应用程序接口相关服务的申请渠道，如电子银行或营业网点等。

9.3.3数据安全应用方在数据安全保护方面的安全要求如下：

数据完整性保护：

应对数据完整性进行校验，并在检测到完整性错误时采取必要的恢复措施（或停止执行请求）。

数据机密性保护：

不应采集、存储用户个人金融信息或支付敏感信息；对于需要用户输入支付敏感信息或身份鉴别信息的场景，应用方仅可作为信息的采集与传输通道，应部署商业银行SDK、采取报文加密等措施，保证采集与传输信息的机密性与完整性，支付敏感信息与身份鉴别信息在应用方不得留存。

JR/T0185202011数据抗抵赖性保护：

应使用数字签名等技术确保A2类数据的不可抵赖性。

数据删除与销毁：

在合作终止后，应依据与商业银行约定的方式删除（或销毁）通过商业银行应用程序接口获取的商业银行及其用户的相关数据。

应针对接口处理的数据，建立数据备份管理机制和应急灾备机制，并纳入机构灾备体系。

在合作终止后，应依据行业主管部门有关要求，履行反洗钱、反欺诈等义务。

9.3.4应用方安全能力应用方在安全能力方面的要求如下：

应符合国家网络安全等级保护相应要求，进行安全设计、安全建设、安全保护。

应遵循商业银行的安全设计要求，使用商业银行提供的安全接口，并依据用户手册和安全规范进行集成。

应留存与商业银行应用程序接口集成相关的应用系统、网络设备、主机设备、安全产品日志，日志保留期应满足国家与行业主管部门要求，日志留存应不少于6个月。

应通过技术手段与管理措施等，防止接口滥用。

9.3.5应用方接口集成应用方在接口集成方面的要求如下：

应用方应根据商业银行提供的用户手册以及商业银行授权其使用的服务类型，正确合理使用API。

应用方密钥存储应采取加密等方式进行安全防护，防范密钥丢失或泄露，应用方应按照商业银行提供的用户手册，妥善使用和保管相关密钥、数字证书。

如商业银行提供封装了商业银行应用程序接口调用的SDK，则应用方需使用商业银行提供的SDK进行API调用，应用方不得对商业银行提供的SDK进行反编译、篡改或二次封装。

若应用方发现商业银行应用程序接口存在安全缺陷，应采取补救措施并及时通知商业银行。

应用方未经商业银行许可，不得将缺陷细节透露给任何其他第三方。

禁止应用方利用商业银行应用程序接口漏洞，进行网络攻击、信息窃取或交易欺诈等非法操作。

9.4应用方退出应用方退出时，商业银行应制定有序、可行的应用方退出机制，保障账户、资金、信息安全，充分履行用户告知义务。

应用方退出后，商业银行应