整体框架

安全设计--》安全部署--》安全集成--》安全运维--》服务终止/下线

 

 

 

01.接口类型与安全级别

1）接口类型划分为服务端对服务端集成方式与移动终端对服务端集成方式两种

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

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

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

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

 

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

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

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

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

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

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

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

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

（不建议使用API方式来做资金类的交易，API风险较高，最好将API封装成SDK）

 

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

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

 

ps:建立唯一的应用程序接口编号

 

 2）安全设计

2.1）设计基本要求

——使用的密码算法、技术及产品应符合国家密码管理部门及行业主管部门要求。
——应制定安全编码规范。
——应对开发人员进行安全编码培训，并依照安全编码规范进行开发。
——开发中如需使用第三方应用组件，应对组件进行安全性验证，并持续关注相关平台的信息披露和更新情况，适时更新相关组件。
——应对商业银行应用程序接口进行代码安全专项审计，审计工作可通过人工或工具自动化方式开展。
——应制定源代码和商业银行应用程序接口版本管理与控制规程，规范源代码和商业银行应用程序接口版本管理，并就接口废止、变更等情况与应用方保持信息同步。
——商业银行向应用方提供的异常与调试信息，不应泄漏服务器、中间件、数据库等软硬件信息或内部网络信息。

 

2.2）接口安全设计

2.2.1）身份认证安全

a）接口身份认证安全：

A1类接口需要

——App_ID、App_Secret。
——App_ID、数字证书。
——App_ID、公私钥对。
——上述三种方案的组合。

 

A2类接口需要

——App_ID、数字证书。
——App_ID、公私钥对。
——上述两种方案的组合。

 

b）用户身份认证安全：

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

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

 

2.2.2）接口交互安全

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

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

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

　　 登录口令、支付密码等支付敏感信息在数据交互过程中应使用包括但不限于替换输入框原文、自定义软键盘、防键盘窃听、防截屏等安全防护措施，保证无法获取支付敏感信息明文；

　　 账号、卡号、卡有效期、姓名、证件号码、手机号码等个人金融信息在传输过程中应使用集成在 SDK 中的加密组件进行加密，或对相关报文进行整体加密处理；若确需使用商业银行应用程序接口将账　　　　　　　           号、卡号、姓名向应用方进行反馈，应脱敏或去标识化处理，因清分与清算、差错对账等需求，确需将卡号等支付账号传输至应用方时，应使用加密通道进行传输，并采取措施保证信息的完整性；

　　 对于金融产品持有份额、用户积分等 A2 类只读信息查询，可使用 API 直接连接方式进行查询请求对接，应采取加密等措施保证查询信息的完整性与保密性，查询结果在应用方本地不得保存。

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

 

2.3）服务安全设计

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

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

　　——API 和 SDK 应对常见的网络攻击具有安全防护能力。
　　——移动终端应用 SDK 应具备静态逆向分析防护能力，防范攻击者通过静态反汇编、字符串分析、导入导出函数识别、配置文件分析等手段获得有关 SDK 实现方式的技术细节。
　　——移动终端应用 SDK 宜具备动态调试防护能力，包括但不限于：具有防范攻击者通过挂接动态调试器、动态跟踪程序的方式控制程序行为的能力；具有防范攻击者通过篡改文件、动态修改内存代码等方　　　　　　       式控制程序行为的能力。

（3）安全监控：

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

（4）秘钥管理：

　　——加密和签名宜分配不同的密钥，且相互分离。
　　——不应以编码的方式将私钥明文（或密文）编写在商业银行应用程序相关代码中，App_Secret或私钥不应存储于商业银行与应用方本地配置文件中，防止因代码泄露引发密钥泄露。
　　——应依据商业银行应用程序接口等级设置不同的密钥有效期，并对密钥进行定期更新。

 

3）安全部署

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

 

示意图如下：

 

 

 

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

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

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

 

4）安全集成

4.1）应用方核准

应用方准入：

商业银行应对申请接入商业银行应用程序接口的应用方进行审核，并制定和签署相关合作协议：

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

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

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

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

 

应用方身份核验：

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

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

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

 

4.2）接入安全

4.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）中第二条至第四条给出的任意一种方式进行双向 身份认证。（数字证书或者公私钥对）

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

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

4.2.2）安全传输

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

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

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

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

 

4.3）运行安全

4.3.1）用户身份认证

商业银行对用户身份的认证要求如下：

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

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

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

4.3.2）权限控制

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

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

　　 商业银行应按应用方、应用唯一标识 App_ID、接口、用户等维度，依据最小授权原则进 行授权，对于未授权的资源禁止访问；

　　 对于获取、使用、变更用户信息、账户、资金等接口，应用方调用接口时，应首先取得用户明示同意，其内容应包含授权有效期；

　　 商业银行应对 API 的调用有效期进行控制（如单次有效、阶段性有效、协议期限内有效）。

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

4.3.3）数据安全

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

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

——数据机密性保护：

　　 不应采集、存储用户个人金融信息或支付敏感信息；

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

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

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

——应针对接口处理的数据，建立数据备份管理机制和应急灾备机制，并纳入机构灾备体系。在合 作终止后，应依据行业主管部门有关要求，履行反洗钱、反欺诈等义务。

4.3.4）应用方安全能力

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

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

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

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

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

4.3.5）应用方接口集成

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

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

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

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

——若应用方发现商业银行应用程序接口存在安全缺陷，应采取补救措施并及时通知商业银行。应 用方未经商业银行许可，不得将缺陷细节透露给任何其他第三方。

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

 

4.4）应用方退出

　　应用方退出时，商业银行应制定有序、可行的应用方退出机制，保障账户、资金、信息安全，充分 履行用户告知义务。应用方退出后，商业银行应对认证信息（如App_Secret、公私钥对等）进行作废处 理，归档并保存待查。

　　应用方应按照商业银行的要求，妥善处理其通过商业银行应用程序接口获取的用户信息与商业银行 业务有关资料，并在双方协定的期限内承担后续的保密责任。

 

5）安全运维

5.1）安全监测

5.1.1）运维监测

运维监测的要求如下： ——商业银行应建立商业银行应用程序接口运维监测平台，或将商业银行应用程序接口运维监测纳入商业银行统一监测平台并重点监测。 ——运维监测应具备以下监测能力： 　　监控商业银行应用程序接口相关服务器运行状态并建立告警机制； 　　监控商业银行应用程序接口服务状态（包括耗时、交易量、成功率等参数）并建立告警机制； 　　商业银行交易日志应按照国家会计准则要求予以保存，系统日志保存期限不少于 1 年。 ——应用方应对其集成商业银行应用程序接口运行状态进行监测，发现异常应及时处置。   5.1.2）异常监测 异常监测的要求如下： ——商业银行应具备流量监控、故障隔离、黑名单控制等商业银行应用程序接口调用控制能力： 　　应具备商业银行应用程序接口调用流量控制能力，控制规则包括最大允许商业银行应用程序接口调用并发数、单位时间最大交易调用量等，控制措施包括告警、暂停、拒绝等； 　　应建立未授权和冒用商业银行应用程序接口的监测机制，发现问题及时处置； 　　应具备故障监测和恢复能力； 　　应具备应用方黑名单管理能力。 ——应用方应具备故障识别与隔离能力： 　　调用商业银行应用程序接口应设计熔断机制，熔断规则包括设置失败笔数阈值、商业银行应用程序接口调用失败阈值等，熔断措施包括拒绝交易、暂停服务调用等； 　　调用商业银行应用程序接口应建立异常告警处理机制。   5.2）风险控制 5.2.1）服务风险控制 商业银行实施服务风险控制的要求如下： ——应建立应用方信息（如运营能力、风控能力等）更新和复审机制。 ——应根据应用方调用商业银行应用程序接口的业务日志等信息，定期评估其金融交易业务的运营情况，并在协议框架内对异常的业务调用进行监控，必要时进行业务限流，并及时通知应用方进行事件调查。 ——应评估应用方的风险承受能力，确保用户与应用方相关的账户关联、服务类型、交易额度等与其风险承受能力相匹配。   5.2.2）交易流程控制 交易流程控制的要求如下： ——身份认证服务等授权类服务应充分识别是否经过用户本人授权。 ——账户查询、资金交易、金融产品及服务申请类交易，应充分识别交易是否由用户本人发起（或本人授权发起），核实用户本人意愿。 ——资金类等高风险金融服务，应提示用户相关的安全风险，充分履行用户告知义务。   5.2.3）交易风险监控 商业银行交易风险监控的要求如下： ——应将商业银行应用程序接口纳入银行风险监控范围，对应用方和用户账户资金活动情况进行实时监控。 ——资金交易应满足行业监管部门对反洗钱、反欺诈方面的相关要求。 ——对大额、异常的资金收付应逐笔监测与核查，及时预警、及时控制。 ——对监控到的风险交易应进行及时分析与处置。   5.3）变更控制 接口变更的要求如下： ——商业银行应用程序接口发生变更时，应及时评估影响并告知应用方，制定变更方案和应急预案，按需进行接口变更发布，并充分履行用户告知义务。 ——应用方对商业银行应用程序接口的使用发生重大变更时，如其交易量预期发生变化、对商业银行应用程序接口集成方案进行修改等可能对商业银行系统安全性、业务连续性等造成重大影响的有关事项，应制　　　　　　　　　　       定变更方案和应急预案，评估变更带来的风险，并及时告知商业银行，同时充分履行用户告知义务。 ——应用方使用商业银行应用程序接口发生重大变更时，商业银行应对其变更进行风险和影响评估，并采取相应的处置措施。   5.4）运维巡检 商业银行应定期对商业银行应用程序接口进行安全巡检，包括： ——应对商业银行应用程序接口进行源代码安全审计、渗透测试等技术检查，及时处理安全漏洞，有效控制安全风险。 ——应对应用方的商业银行应用程序接口安全集成情况进行检查。应用方应定期对商业银行应用程序接口进行安全巡检，包括：应定期对其调用商业银行应用程序接口的应用系统进行安全评估，及时处理安全漏洞，确保调用的真实有效。   5.5）事件处理 商业银行应制定应急处理方案，对运维过程中监测到的异常情况及时告警和处置，及时处理生产事件，并协调应用方配合事件调查。  

6）服务终止与系统下线

商业银行应制定完善的服务终止和系统（接口）下线的相关制度和步骤，以便各参与方有序处理相关服务： ——服务终止前，商业银行应将服务终止有关事项提前告知相关方，并向相关平台提交有关接口的统一识别码注销申请。 ——商业银行应与应用方就服务终止后相关数据归档、数据删除（或销毁）、个人金融信息保护、用户资金和账户安全、消费者权益保护等问题充分达成一致，明确相关责任，并充分履行用户告知义务。 ——系统（接口）下线应在相关服务确认终止之后执行，在下线之前应设置挡板（如服务终止提示信息），明示应用方服务已终止。 ——商业银行在系统（接口）下线之后应将有关数据进行归档处理，数据保留期限应按照国家与行业主管部门、商业银行相关规定与规则执行。  

7）安全管理

7.1）管理制度

商业银行管理制度要求如下： ——应将商业银行应用程序接口的管理纳入商业银行现行管理体系中，对商业银行应用程序接口进行全生命周期的安全管理。 ——应用程序接口应采用统一格式的识别码，并在相关平台进行注册和登记，编码规则详见附录 B。 ——应建立信息公告制度，通过官方网站等公开渠道发布其商业银行应用程序接口内容，并及时更新。 ——应建立覆盖商业银行应用程序接口全生命周期的应用安全管理制度与控制措施，并对管理制度与控制措施的有效性进行验证，以确保商业银行应用程序接口的一致性和连贯性，保障商业银行应用程序接口效率及安全性。 ——应提供开发手册以指导应用方安全集成商业银行应用程序接口，开发手册包括但不限于安全集成要求、集成示例，以及测试环境的使用等。   7.2）应用安全责任 商业银行与应用方应以合同或协议的方式，明确规定商业银行应用程序接口的信息安全与金融消费者数据保护等方面的安全责任，包括但不限于： ——应用方若出于自身服务需求收集金融消费者个人金融信息，应： 　　直接获得金融消费者的明示同意，并依据最少够用原则进行信息收集，不应以使用商业银行应用程序接口为理由不履行明示同意等个人金融信息保护义务； 　　向金融消费者说明个人信息收集方并非商业银行，也与商业银行服务无关。 ——明确商业银行与应用方的信息安全责任。 ——应用方不应将通过商业银行应用程序接口获得的金融服务能力与数据以任何方式转移、共享或分包给其他第三方。 ——无论合作关系是否续存，应用方应依据与商业银行的协议约定，履行用户信息保密责任。   7.3）安全审计 商业银行应具备以下安全审计能力： ——应完整记录商业银行应用程序接口访问日志，日志记录应至少包括 7.3.3 所述日志内容。 ——依据商业服务需求和风险控制要求，遵循最少够用原则适当保留应用方上送报文（全部或部分信息）。 ——应对日志记录进行完整性保护，确保日志不被篡改、删除、覆盖。 应用方应具备以下安全审计能力： ——应完整记录商业银行应用程序接口访问日志，日志记录应符合 7.3.3 所述日志要求。 ——应对日志记录进行完整性保护，确保日志不被篡改、删除、覆盖。 ——应提供查询应用方用户商业银行应用程序接口相关登录、授权、交易等历史操作日志功能。