江苏东海农村商业银行应用程序接口安全管理规范

Q/DHNSH

江苏东海农村商业银行股份有限公司企业标准

Q/DHNSH00004—2024

2024-9-30发布2024-10-01实施

江苏东海农村商业银行股份有限公司发布

江苏东海农村商业银行应用程序接口安全管理规范

JiangsuDonghairuralcommercialbankapplicationprograminterfacesecuritymanagementspecification

江苏东海农村商业银行股份有限公司

接口开放平台安全管理规范

1.范围

本标准规定了江苏东海农村商业银行股份有限公司接口开放平台接口安全管理规范，明确了接口开放的相关工作，确立了接口开放的范围和实现的功能，包括接入方式、身份认证、数据存储、系统部署、安全监控、变更控制、运维巡检、管理制度部分，并为第三方安全评估机构等单位开展安全检查与评估工作提供参考。

本标准适用于江苏东海农村商业银行股份有限公司对外提供接口服务的安全设计和应用，指导集成接口服务的应用方开展相关工作。其中各项技术要求将随企业的技术进步及产品的改进而修改。

2.规范性引用文件

GB/T25069信息安全技术术语

JR/T0124—2014金融机构编码规范

GB/T35273-2017信息安全技术个人信息安全规范

JR/T0071-2020金融行业信息系统信息安全等级保护实施指引

GM/T0002-2012SM4分组密码算法

JR/T0171—2019个人金融信息保护技术规范

GBT22239-2019信息安全技术网络安全等级保护基本要求

3.术语和定义

3.1应用程序接口applicationprogramminginterface

一组预先定义好的功能，开发者可通过该功能(或功能的组合)便捷地访问相关服务，而无需关注服务的设计与实现。

3.2应用方applicationagency

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

3.3应用程序接口唯一标识applicationprogramminginterfaceuniqueID

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

3.4应用程序接口统一识别码uniformapplicationprogramminginterfaceID

商业银行依据行业主管部门发布的编码规则，生成的商业银行应用程序接口统一识别码。注:用于标识商业银行机构代码、接口类型、服务类别、接口顺序号等内容。

3.5应用唯一标识applicationuniqueID

在应用方身份核验通过后，根据其调用的金融产品与服务类型，由商业银行为其授予的唯一标识。注:包括服务器端应用标识与移动终端应用软件标识两种。

3.6应用软件开发工具包softwaredevelopmentkit

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

3.7应用鉴别密文applicationsecret

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

3.8个人金融信息personalfinancialinformation

金融机构通过提供金融产品和服务或其他渠道获取、加工和保存的个人信息。注1:包括账户信息、鉴别信息、金融交易信息、个人身份信息、财产信息、借贷信息及其他反应特定个人某些情况的信息。

3.9支付敏感信息paymentsensitiveinformation

支付信息中涉及支付主体隐私和身份识别的重要信息。注:包括但不限于银行卡磁道或芯片信息、卡片验证码、卡片有效期、银行卡密码、网络支付交易密码等。

3.10支付账号paymentaccount

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

4.接口类型与安全级别

4.1接口类型

我行应用程序接口按照应用集成方式，分为服务端对服务端集成方式与移动终端对服务端集成方式两种。

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

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

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

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

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

——应用方移动终端应用软件直接调用我行应用程序接口。

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

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

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

4.2安全级别

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

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

我行通过SDK，提供资金交易类服务，如支付、转账以及金融产品与服务购买等；

我行通过SDK，提供用户账户信息查询类服务，如账户余额、交易历史、账户限额、付款时间、金融产品和服务持有情况等；

对于上述服务，若确需使用API直接连接方式进行服务调用，我行应对接入风险进行评估，并制定专门的接口与应用方进行对接，实施高等级的安全保护强度要求。

——A1：金融产品和服务信息查询应用类，此类金融产品和服务与用户个体并无直接关联，实施通用的安全保护强度，此类应用程序接口包括但不限于：提供银行金融产品和服务的详细信息的“只读”查询服务。

5.技术要求

5.1接入要求

应用方接入我行接口开放平台提供的应用程序接口应符合下列规定：

1)接口使用申请应符合《我行信息系统软件接口开放管理办法》中“一事一报专项评议”的规定。

2)应用方接入系统应符合国家法律法规、监管及省联社要求，履行报备程序。

3)服务方开放评议与管理工作组应在十五个工作日内形成应用方接入的评议意见。

4)应用方服务端应采用直接调用服务方服务的调用方式。

5)应用方应采用基于TCP/IP协议的SOCKET短连接与服务方服务进行通信。

5.2安全认证

我行接口开放平台提供的应用程序接口均实施人行A2级高等级安全要求，双向身份认证应符合下列规定：

1)应用方请求报文应按照服务方提供的报文规范进行赋值和组装。报文体应遵循标准XML报文格式规范，报文采用UTF-8编码格式。

2)报文交互采用统一的报文结构，报文结构组成格式如下：

报文长度 报文体

----报文长度：定长编码，长度8字节的10进制ASCII码字符串；指示报文体的总长度值，不足8字节长度的左补0；如报文体长度为1234字节，则表示为00001234；

----报文体：报文体包括发送方向接口系统提出调用申请的请求数据或接口系统反馈给发送方的结果数据。由于不同接口包含各自的业务字段，所以不同报文体的长度是不同的，即报文体长度不固定；报文体明文采用XML格式组装信息，并需要对报文体进行全报文加签和加密，加签和加密方法采用带签名的数字信息。

----报文格式要求：报文中只包含报文格式所定义的定值和本次业务所需的业务字段。报文体中定义的标签不得随意增删。如果标签内数值为空，标签必须保留。

3)应用方请求报文头中公共请求参数必须包含以下字段，用于应用方访问控制及身份验证，详见表1。

tag 说明 数据类型 用法 备注

templatecode 模板代码 char（6） M 固定填写000129

transcode 交易码 char（6） M 应用程序接口统一识别码，固定填写PUBINC

channelcode 渠道代码 char（3） M 默认007，若有交易涉及收单,税银,贷记卡接口请与接口平台确认

channeldate 外围日期 char(8) M 外围渠道时间，格式：YYMMDD

channeltime 外围时间 char(8) M 外围渠道时间，格式：hhmmss

channelseq 外围流水 varchar(20) M 默认长度20，农信银收单接口不超过12位

zoneno 法人号 Char(3) M 三位法人号，必输勿忘

brno 机构码 char(9) M 自行确定业务归属机构，长度9位

tellerno 柜员号 char(12) M 无特殊需求用B 柜员brno+B+(01~99具体请与业务确认）

terminalno 终端号 varchar(12) M 同柜员号

areacode 地区编码 char（4） M 地区码

itemno 项目号 char(6) M 项目编号，值由接口平台在联调测试时分配

subitemno 子项目号 varchar（2） M 子项目号，无特殊情况默认输入00

tradeno 交易码 varchar（20） M 应用程序接口唯一标识，必送

chkdate 清算日期 char(8) M 账务类交易清算日期

YYYYMMDD

表1

4)应用方请求报文和服务方响应的应用鉴别密文的加密算法应符合GM/T0002-2012《SM4分组密码算法》的规定。

5)服务方应用程序接口应通过校验数字签名、应用程序接口统一识别码、法人号、应用程序接口唯一标识、项目编号、应用方服务器IP白名单多重方式认证方式保证数据的完整性和不可抵赖性。

6)数字证书的密钥应通过签名服务器与应用系统物理隔离，并设置密钥有效期，对密钥进行定期更新。

7)服务方应通过配置的唯一标识与数字证书的组合核验应用方身份，进行双向身份验证，通过后完成系统对接。

8)对于未经双向身份认证的访问请求，服务方应用程序接口应以拒绝访问。

5.3数据安全

我行接口开放平台应完整记录接口访问日志，日志信息应符合下列规定：

1)服务方应用程序接口日志应以日期YYYYMMDD格式为文件名，每日建立日志文件夹，在日期文件夹内以应用程序接口唯一标识为文件名，分别建立各交易日志目录，交易日志目录下建立和存储当日每一笔交易的完整信息。

2)服务方应用程序接口日志应记录完整的访问信息，包括流水号、应用唯一标识、接口唯一标识、调用耗时、时间戳、返回结果（成功或失败）。

3)服务方应用程序接口应对日志应记录进行完整保护，确保日志不删除、不篡改、不覆盖、定期备份，具备安全审计的能力。

4)服务方交易日志保留3天，超过3天的日志进行压缩存储，超过一年的日志，应备份至磁带库，存储期限应符合国家会计准则要求，所有日志保存期限为3年。

5)应用方日志包括个人金融信息、支付账号和支付敏感信息的记录应符合JR/T0171—2019《个人金融信息保护技术规范》。

5.4系统部署

我行接口开放平台的系统部署应符合GBT22239-2019信息安全技术网络安全等级保护基本要求中的第三级安全要求。系统逻辑图详见图1

图1

5.5安全监控

服务方应用程序接口应具备统一监测平台进行安全监控的能力，安全监控能力应符合下列规定：

1)监控服务器的状态，包括基本信息、服务器数量、运行状态、CPU使用率、内存使用率、磁盘使用率、进程状态等指标。

2)监控服务的状态，包括当日交易总笔数、当前及历史的TPS、平均调用时长、响应率、成功率、交易调用方身份等信息。

3)流量控制应可调整调用方并发数、单位时间最大交易调用量，调用有效期(如单次有效、阶段性有效、协议期限内有效)，控制措施为对超限的请求进行友好拒绝。流量控制的逻辑详见图2。

图2

4)监控信息异常应发告警短信和提醒邮件至事件处理人员。

5.6密钥管理

密钥管理安全要求如下：

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

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

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

5.7变更控制

服务方应用程序接口变更应符合《银行业金融机构重要信息系统投产及变更管理办法》（银监办发[2009]437号）。接口服务内容有变化时，应制定变更方案和应急预案，并及时通过发文、通知等方式告知应用方。

5.8运维巡检

我行接口开放平台日常运维、事件处理应符合《商业银行业务连续性监管指引》（银监发[2011]104号）。

5.9管理制度

我行接口开放平台应符合行内《我行信息系统软件接口开放管理办法》。管理制度应符合下列规定：

1)对应用程序接口应进行全生命周期的管理，保障应用程序接口效率及安全性。

2)所有接口信息应公开发布或更新在行内接口管理平台网站上。

3)所有公告信息应公开发布或更新在行内接口管理平台网站上。

4)开发手册包含集成要求、集成示例、测试环境信息等应发布或更新在行内接口管理平台网站上。

6.安全部署

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

我行应用程序接口服务层应部署流量控制、监控分析、认证鉴权、报文交换、服务组合等服务，其中认证鉴权、报文交换、服务组合等服务也可部署在银行业务层。我行应用程序接口服务层与银行业务层之间应部署如防火墙等具备相关访问控制、入侵防范安全防护能力的网络安全防护措施。

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

我行的安全控制要求依据JR/T0071部署相应级别的安全控制措施。应用方部署我行应用程序接口有关安全控制措施，应符合国家网络安全等级保护有关标准二级及以上安全要求。

7.安全运维

7.1安全监测

7.1.1运维监测

运维监测的要求如下：

——我行应建立应用程序接口运维监测平台，或将我行应用程序接口运维监测纳入统一监测平台并重点监测。

——运维监测应具备以下监测能力：

a)监控我行应用程序接口相关服务器运行状态并建立告警机制；

b)监控我行应用程序接口服务状态（包括耗时、交易量、成功率等参数）并建立告警机制；

c)我行交易日志应按照国家会计准则要求予以保存，系统日志保存期限不少于1年。

——应用方应对其集成应用程序接口运行状态进行监测，发现异常应及时处置。

7.1.2异常监测

异常监测的要求如下：

——我行应具备流量监控、故障隔离、黑名单控制等应用程序接口调用控制能力：

a)应具备应用程序接口调用流量控制能力，控制规则包括最大允许我行应用程序接口调用并发数、单位时间最大交易调用量等，控制措施包括告警、暂停、拒绝等；

b)应建立未授权和冒用我行应用程序接口的监测机制，发现问题及时处置；

c)应具备故障监测和恢复能力；

d)应具备应用方黑名单管理能力。

——应用方应具备故障识别与隔离能力：

a)调用我行应用程序接口应设计熔断机制，熔断规则包括设置失败笔数阈值、我行应用程序接口调用失败阈值等，熔断措施包括拒绝交易、暂停服务调用等；

b)调用我行应用程序接口应建立异常告警处理机制。

7.2风险控制

7.2.1服务风险控制

我行实施服务风险控制的要求如下：

——应建立应用方信息（如运营能力、风控能力等）更新和复审机制。

——应根据应用方调用应用程序接口的业务日志等信息，定期评估其金融交易业务的运营情况，并在协议框架内对异常的业务调用进行监控，必要时进行业务限流，并及时通知应用方进行事件调查。

——应评估应用方的风险承受能力，确保用户与应用方相关的账户关联、服务类型、交易额度等与其风险承受能力相匹配。

7.2.2交易流程控制

交易流程控制的要求如下：

——身份认证服务等授权类服务应充分识别是否经过用户本人授权。

——账户查询、资金交易、金融产品及服务申请类交易，应充分识别交易是否由用户本人发起（或本人授权发起），核实用户本人意愿。

——资金类等高风险金融服务，应提示用户相关的安全风险，充分履行用户告知义务。

7.2.3交易风险监控

我行交易风险监控的要求如下：

——应将我行应用程序接口纳入银行风险监控范围，对应用方和用户账户资金活动情况进行实时监控。

——资金交易应满足行业监管部门对反洗钱、反欺诈方面的相关要求。

——对大额、异常的资金收付应逐笔监测与核查，及时预警、及时控制。

——对监控到的风险交易应进行及时分析与处置。

7.3变更控制

接口变更的要求如下：

——我行应用程序接口发生变更时，应及时评估影响并告知应用方，制定变更方案和应急预案，按需进行接口变更发布，并充分履行用户告知义务。

——应用方对我行应用程序接口的使用发生重大变更时，如其交易量预期发生变化、对我行应用程序接口集成方案进行修改等可能对我行系统安全性、业务连续性等造成重大影响的有关事项，应制定变更方案和应急预案，评估变更带来的风险，并及时告知我行，同时充分履行用户告知义务。

——应用方使用我行应用程序接口发生重大变更时，我行应对其变更进行风险和影响评估，并采取相应的处置措施。

7.4运维巡检

我行应定期对应用程序接口进行安全巡检，包括：

——应对应用程序接口进行源代码安全审计、渗透测试等技术检查，及时处理安全漏洞有效控制安全风险。

——应对应用方的应用程序接口安全集成情况进行检查。

应用方应定期对我行应用程序接口进行安全巡检，包括：应定期对其调用我行应用程序接口的应用系统进行安全评估，及时处理安全漏洞，确保调用的真实有效。

7.5事件处理

我行应制定应急处理方案，对运维过程中监测到的异常情况及时告警和处置，及时处理生产事件，并协调应用方配合事件调查。

8.安全管理

8.1管理制度

我行管理制度要求如下：

——应将我行应用程序接口的管理纳入我行现行管理体系中，对我行应用程序接口进行全生命周期的安全管理。

——应建立信息公告制度，通过官方网站等公开渠道发布我行应用程序接口内容，并及时更新。

——应建立覆盖我行应用程序接口全生命周期的应用安全管理制度与控制措施，并对管理制度与控制措施的有效性进行验证，以确保我行应用程序接口的一致性和连贯性，保障我行应用程序接口效率及安全性。

——应提供开发手册以指导应用方安全集成我行应用程序接口，开发手册包括但不限于安全集成要求、集成示例，以及测试环境的使用等。

——应用方严格按照我行接口管理办法，做好接口的日常管理工作。

8.2应用安全责任

我行与应用方应以合同或协议的方式，明确规定我行应用程序接口的信息安全与金融消费者数据保护等方面的安全责任，包括但不限于：

——应用方若出于自身服务需求收集金融消费者个人金融信息，应：

直接获得金融消费者的明示同意，并依据最少够用原则进行信息收集，不应以使用我行应用程序接口为理由不履行明示同意等个人金融信息保护义务；

向金融消费者说明个人信息收集方并非我行，也与我行服务无关。

——明确我行与应用方的信息安全责任。

——应用方不应将通过我行应用程序接口获得的金融服务能力与数据以任何方式转移、共享或分包给其他第三方。

——无论合作关系是否续存，应用方应依据与我行的协议约定，履行用户信息保密责任。

8.3安全审计

我行应具备以下安全审计能力：

——应完整记录我行应用程序接口访问日志，日志记录应至少包括7.3.3所述日志内容。

——依据商业服务需求和风险控制要求，遵循最少够用原则适当保留应用方上送报文（全部或部分信息）。

——应对日志记录进行完整性保护，确保日志不被篡改、删除、覆盖。应用方应具备以下安全审计能力：

——应完整记录我行应用程序接口访问日志，日志记录应符合7.3.3所述日志要求。

——应对日志记录进行完整性保护，确保日志不被篡改、删除、覆盖。

——应提供查询应用方用户我行应用程序接口相关登录、授权、交易等历史操作日志功能。

9.检验规则

按JR/T0185—2020商业银行应用程序接口安全管理规范规定执行。