《商业银行应用程序接口安全管理规范》学习笔记

关键字:API、安全、银行、Commercial bank application programming interface secure management、JR/T 0185—2020

国际标准号:35.240.40

金融类型: 研发测试运维及管理

勘误,或者有不同意见和想法,或者需要交流的,可以给我们发邮件:support@polaristech.io,或者加微信13700113993

概述

2020年2月13日,人行正式发布了《商业银行应用程序接口安全管理规范》,在开放银行建设如火如荼的背景下,这个规范的出台具有很强的指导意义,为以银行为主的金融体系的API化、互联互通、金融数字化,提供了最基础的安全指导和推荐性的技术规范。作为国内第一份行业性的API安全规范,这个规范除了指导商业银行,实际上也可以给其他行业作为技术参考,比如保险、证券、类金融、物联网等。作为从业者和供应侧参与者,我们对这个规范做一些基本的学习,一方面自己学习并且树立符合规范的安全意识,一方面为其他参与者提供一个相对浓缩的、可以快速阅读的参考材料。

规范原文参考这里:http://www.cfstc.org/bzgk/gk/view/bzxq.jsp?i_id=1857

该标准属于“推荐性行业标准

概念

围绕API,除了常见的概念,该标准里引入了一个新的名词:U_API_ID。这个ID是银行根据编码规则,生成的API编号。这个编号规则是:

  1. 编码为ASCII码,长度24字节
  2. 固定值:2个字节固定值“OP”。注:这里从文档看不出是零P,还是大写的“欧”P,推测是"欧P"
  3. 银行编号:6个字节,根据JR/T 0124-2014,金融机构的编码的前6个字节
  4. 接口级别:2个自己,标识接口安全级别类型:00为保留,01为A1安全级别,02为A2安全级别。注:这里没有定义是否可以使用其他字符,以及可能的含义
  5. 服务类别:6个字节
    1. 前2个字节为服务类型:00保留,01账户服务,02支付服务,03投资理财,04信贷,05信用卡,06行业服务,07国际业务,08科技服务,其他目前没有使用。其中06行业服务,指商业银行通过商业银行API向其他行业提供金融服务
    2. 后4个字节标识在前两个自己的分类中,细分的服务类型,优先使用数字编号0000-9999,其中0000为保留
  6. 顺序码编码:6个字节,同一商业银行机构、同一接口类型、同一服务类别下,多个商业银行API的顺序码,优先使用数字编码000000-999999
  7. 保留位:2个字节,默认00

理解:银行在开放自己的API时候,需要参考这个编号规则和分类依据,为自己的API编号。由于多数系统内部的API编号都是UUID类型的,所以一般需要一个U_API_ID到UUID的对应关系记录

分解

这里我们沿用《规范》中的章节编号,对条目进行编号,方便后续的内容讨论

首先我们用思维导图把规范中的信息分解和整理如下:

商业银行API安全规范-思维导图

解读--综述

首先我们用关键字尽可能精简的概括一下这个规范的内容:

  • 两个级别:API应该分为两个安全级别,A1和A2。A1为涉及账户和资金、交易类(买卖),A2为产商品类查询等。A1安全等级高于A2
  • 两个方式:访问API有两个方式,一个是直接访问,一个是通过SDK访问
  • 三个参与方:规范涉及到三方:1:商业银行,为API生产者;2:“应用程序方(App方)”,也就是API的消费方;3:消费者
  • 六个维度:设计、部署、集成、运维、生命周期、制度及管理

如下为针对规范细节的逐条解读和学习笔记。

这里我们以一个假设场景为例做详细的讨论:XYZ公司访问ABC银行的API,“张三”是个人用户,在ABC银行存款,还在ABC买了一些理财产品。XYZ也为张三提供一些服务,其中有些服务是“代理”ABC银行的。这里XYZ公司对应就是规范中提到的“应用方(App方)”,ABC银行就是规范中提到的“商业银行”,张三是“金融消费者”

在如下的学习笔记中,我们把在实践中常见的一些方法、操作和情况,但是在规范中并没有提到的,用下划线标识出来,比如:通常,我们除了约束Token的有效时间,还会约束特定Token的使用次数

6.接口类型和安全级别

6.1接口类型

接口类型这里定义了两个类型,一个是B2B,企业访问银行的API,比如一个银行访问另一个银行接口;一个是B2C,就是个人用户访问银行的接口

在整个规范里并没有明确定义第三种情况:张三在XYZ公司的APP或者H5页面中,直接访问ABC银行的API。如果是页面,这看起来是一次跨站调用,但是在实际中这种方式很常见,比如在APP中调用第三方的数据,没有必要经过自己的服务一次。API的目的之一就是构建开放体系,如何处理用户直接访问第三方API,是个新的话题。我们通常把访问模式分成4种

  1. B->B。XYZ公司访问ABC银行的API
  2. C->B。张三访问ABC银行的API
  3. C->X。张三访问XYZ公司的API
  4. C->X->B。张三访问XYZ公司的API,XYZ再通过B->B的方式访问ABC银行的API

6.1.1 B2B:服务对服务

从整个规范的描述来看,这一版的规范对于B2B的API处理非常详尽,估计这也是整个行业下一个阶段的发展的重点。相比较而言,B2B的连接在安全方面更可控,比如访问控制中,加入基于来源IP地址的访问控制机制

6.1.1.1 直接访问

这种是工作中B2B中最常见的访问方式

6.1.1.2 通过SDK访问

SDK的使用一般有两种目的,一个是封装协议细节,一个是封装一系列操作用以简化调用。所以规范中提到这个,应该是针对私有API的;对于开放API,一般不会做封装,既没有必要,也会增加维护难度。更常见的做法是提供API使用的示例程序或者代码片段

6.1.2 B2C:服务对移动端

这里的移动端,是指XYZ公司的App

6.1.2.1 直接访问

App里直接访问银行API的,属于上边讨论的C->B和C->X->B模式

6.1.2.2 通过SDK访问

和上边的讨论一样,如果是私有API,一般会采用SDK封装模式;开放API一般不采用SDK方式

这个规范中,并没有太多对SDK本身的约束性内容。在实际工作中,有些SDK存在过度获取移动终端权限的问题,造成隐私泄露等;并且SDK出现漏洞后,需要重新打包和发布App更新,带来管理复杂度和不安全的因素,导致SDK在合规环境里使用并不广泛。SDK的监管是一个和API监管同样重要的话题

6.2安全级别

规范中根据业务的场景情况,给出了两个安全级别。在实际使用当中,除了业务API,大多数的API系统还有一些支撑型API,比如查询某个API请求是否已经被处理(而不是业务是否被处理),或者一些通知类型(Notification)的接口,或者是web hook;随着API广泛使用,这些支撑型API会越来越多,并且会被集成到双方的自动化流程当中。我们建议API平台的建设者关注这类API的安全问题。在Flomesh产品中,我们也在逐渐丰富和完善这类接口。通常我们把这种*支撑型API的安全级别处理成和规范中A2一样

6.2.1 A1: 产品和服务信息查询(只读)

可以认为A1类型为非关键信息的只读操作

6.2.1.1 产品/服务列表
6.2.1.2 产品/服务详情

这两类信息(产商品及服务列表和详情),在Flomesh的产品中,包含了3种处理场景:

  1. 匿名用户可以访问的信息。比如公开的API
  2. 登陆的C端用户可以访问的信息。比如VIP用户的API列表
  3. 特定的B端用户可以访问的信息。比如针对某个行业,某个客户群体的API

6.2.2 A2: 资金交易与账户信息查询

6.2.2.1 资金交易类
  • 支付
  • 转账
  • 金融服务/产品购买
6.2.2.2 账户信息查询类

这两类可以概括成“交易类”和“敏感信息类”。所以我们判断一个API是哪个类型,首先看是否涉及交易(是否涉及),如果涉及,就是A2类;然后看是否涉及敏感信息,尤其是用户信息,如果涉及,就是A2类。其他的都是A1类。但是如上述讨论,我们把非业务、用于维护平台间互通的支撑型API也按照A2等级来处理

7.安全设计

7.1 设计基本要求

这章描述的“设计”,是指设计和实现API本身;而不是指“设计API平台”

这些设计相关要求,在落地过程中,可以落地到代码管理、运维管理等多个环节

  • 7.1.1 国密

这里明确要求了“算法、技术和产品”应该符合国密要求。不过国密也涉及很多标准,具体什么样的API采用什么样加密算法,并没有进一步描述 在实际工作中,我们通常对需要加密和签名的环节,采用至少1024位的非对称加密算法,随着计算机技术发展,一般认为1024位的RSA加密是可以被破解的,所以采用2048的更常见;或者如该规范建议的采用国密算法,比如SM2

SM2加密和计算摘要的速度要快于RSA1024,而且强度也高于RSA1024

  • 7.1.2 编码规范

目前看,针对API接口的编码规范,和其他的编码规范相比并没有特殊的要求

  • 7.1.3 开发培训

由于目前并没有“验证”或者“考核”机制,开发培训可能会流于形式;不过对于有条件的,最好还是明确有培训加测试,也就是“持证上岗”

  • 7.1.4 第三方组件的安全性

这个要求实际上非常重要。现在大多数的程序,都基于一些第三方的库、框架做开发(比如使用fastjson),而这些第三方程序在出现漏洞时候,需要及时的获取信息并且升级库。不仅仅是API的开发,整个应用开发领域,这个都是一个很重要的话题。现在一些编译工具和打包工具可以做扫描,也有工具可以做静态扫描。建议引入这样的系统定期对API实现的代码做扫描

  • 7.1.5 代码审计

常规编码要求

  • 7.1.6 代码和API的版本及流程

代码版本管理容易理解。规范明确要求了API版本的管理和流程的管理。在实际工作中,我们经常在这个基础上实现“配置的版本化”,“发布的流程化”。可以参考Flomesh实现的API生命周期(lifecycle)管理

  • 7.1.7 异常和调试信息的保密

这个是一个常被忽略的安全细节。当发生错误的时候,需要尽可能少的暴露API所运行平台的软硬件信息,包括品牌、版本等。这个就要求API服务方很好的捕获和处理异常和错误。 这个问题在SDK中更为常见;不过如上讨论,开放API已经很少使用SDK。

7.2 接口安全设计

7.2.1 身份验证要求

这部分身份验证的,规范里分成了两个部分:一个是访问接口的认证,也就是认证调用方程序;一个是认证终端客户,人机交互的认证。目前我们还不太清楚和理解“人机交互”认证的业务场景。一种可能是:比如当需要支付时候,但是这个认证一般是在支付软件完成的,比如由某个App打开和跳转到支付软件,然后支付软件完成人机验证。这个过程中,人是和银行的App直接交互的,并不是和第三方App交互。所以不是很理解这里定义的人机交互部分规范的定义

7.2.1.1 接口身份认证

这里接口身份指的是API调用方的身份确认。通常而言,基于HTTP的API领域常见的认证有BASIC认证、AKey认证(AKey就是API Key)、HMAC认证、JWT认证,以及如上几种的衍生版,比如PASETO。单纯的Token,比如sessionID,在API领域并不常见

在发起API调用之前,或者调用的时候,都需要首先确认调用方“是谁”,以及是否“有权限”访问这个API,也就是认证和授权过程。规范里明确了不可以采用单一信息验证(比如sessionID就是单一信息),至少要有两个因素:其中一个是APP_ID,另一个可以是“密码”、或者证书、或者密钥、或者组合。所以这条规范可以理解成:一定要有APP_ID,和另外一个因素

这里,规范里并没有提到一种情况,就是完全开放的API,不需要身份验证和访问控制的。这是一种常见的API形态,比如天气预报查询、股市查询等。现实中,即使是这类的允许匿名访问的完全开放的API,我们也尝试去给访问者设定一个尽可能唯一的标识,可以认为是“设备指纹”的一个形态;这样做的目的一方面是确保API在防护的时候可以综合多种信息,一方面可以根据特征对访问进行控制,比如限流。另外,尽可能控制这种完全开放API的存在和数量:比如某种价格查询,对于匿名的请求,提供临时令牌,然后很快过期。按照ZTN(Zero Trust Network)的思路,“有效的控制首先要消灭匿名”

  • 认证要素
    • APP_ID+APP_SECRET
    • APP_ID+数字证书
    • APP_ID+公私钥对
    • 如上三种组合

这里明确了使用APP_ID外加一种信息做身份验证的模式。不过在规范里,并没有定义这个APP_ID的规格,包括长度以及字符设定等。在实际工作中,一般我们也会制定APP_ID的规则,通常是一个UUID,或者UUID拼接人可读的APP编码。通过保证APP_ID的长度和随机性,来提高猜测APP_ID的难度,进而规避碰撞类攻击。其中人可读的部分主要是为了日常工作分析问题(trouble shooting)和查找数据方便,主要规则是编码和长度,比如采用ASCII编码等

  • A2级接口应该用双向认证

规范中明确了A2等级认证需要双向认证。不过这里并没有明确采用链路层的双向认证,还是消息层面的双向认证;通常大家通论的都是链路层双向认证,这里就认为是指Mutual SSL。虽然多数API的实现都很注重服务方对请求方的认证,但是实际中请求方对服务方的认证同样重要,规范很好的约束和强调了这种重要性。实际工作当中,一般对于B2B,普遍的采用的是链路层双向认证结合源IP地址白名单机制;消息层面做签名和机密信息的加密

7.2.1.2 用户身份认证
  • 7.2.1.2.1 API应该设计用户身份认证
  • 7.2.1.2.2 用户身份验证在银行端执行
  • 7.2.1.2.3 A2级别接口采用双因子认证登录

规范中的这个部分描述的比较简单。这里明确了涉及用户参与的关键性操作,比如用户购买银行产品、订购银行服务,银行需要直接验证用户身份。这个在网银等很常见,但是在API模式下,这个事情比较容易混淆。这里有两种情况:一种是用户直接和银行API交互,这个时候,本质上还是验证的API调用方身份;另一种是用户使用App访问XYZ的App,App访问XYZ的后台,XYZ后台再访问ABC银行接口,这一种是XYZ的App去验证用户身份,没有办法做到“在银行端验证”。相对而言,更常见的操作是“跳转”,就是需要验证用户身份时候,XYZ的App把用户跳转和打开ABC的App,在ABC的App中完成验证。这个操作本质上和API关系不大。

用户验证需要采用双因子认证,这个很通用,比如在转账时候要求获取和输入短信验证码。同样,这个和API关系也不大。目前看,API也有多次操作的模式,比如App首先请求一个接口,这个接口回调App方的一个接口,然后App再获取这个回调传过去的随机数做比对,这个本质也是双因子

目前看,在API模式下,确认API调用方身份和可靠和可行的;但是验证终端用户的身份比较困难,简单的手段难于满足实际需要,太复杂了用户体验也比较难做。可能比较可行的办法是国家或者管理机构实现一个统一的个人身份认证系统,类似当前的公安人脸识别,或者是征信系统接口,然后在交易时候去用统一身份认证;另一个办法就是使用已有的“实名认证”的系统做身份认证,比如通过有支付牌照的第四方提供认证,比如通过微信的认证,但是这样信息进一步经过第四方(微信),信息安全管理更加复杂。

这个话题让我想起2000年初电信增值业务野蛮发展的那段时间,运营商、SP、CP,各种角色在技术手段和规则并不清晰甚至并不有效的情况下,发展了短信接口,最后结果是终端用户谈“增值业务”而“色变”。回顾那段历史,可能最好的办法还是:在有中间角色的情况下,采购和订购关系还是由终端用户和运营商直接确认,而不是通过中间机构来处理。

7.2.2 接口交互安全

要求校验版本和参数格式

这里提出需要验证版本和参数。也就是API在处理前,需要做Validation。在实际中,可能Validation是个开销不小的操作,但是确实可以有效保护API的实现,所以这个开销是值得的

数据完整性;A2要求采用数字签名

几乎所有的API都要求数据完整性,一般常用的办法就是计算报文或者特定字段和信息的摘要,然后签名。最常用的办法就是采用HMAC。需要注意的是HMAC可以设定对哪些字段计算Hash,做一致性校验。好的实践是对关键的header信息和整个消息做校验

个人金融信息,如支付
  • 7.2.2.3.1 要求人输入
    • 替换输入框
    • 自定义软键盘
    • 防键盘窃听
    • 防截屏

这一部分实际是对App的要求,应该说并不是API的要求

  • 7.2.2.3.2 要求信息加密,或者信道加密,且保证完整性
    • 账号
    • 卡号
    • 卡有效期
    • 姓名
    • 证件号码
    • 手机号码

这里明确了列出的信息必须做加密和完整性检查(比如用HMAC计算这些字段的Hash)。规范中明确了信息加密或者字段加密,实践中,几乎所有API请求在互联网上都是通过加密信道(比如HTTPS)传输的,也就是满足这个要求的。所以采用HTTPS+HMAC,就是满足这条规范的要求了

  • 7.2.2.3.3 A2类只读查询
    • 产品持有份额
    • 用户积分
    • 可用API直连
    • 应该加密
    • 应该完整
    • 查询结果本地不得保存

这条明确了A2类的哪些数据需要加密,并且需要验证一致性。因为是只读类的,所以生成Hash和签名,是API服务端做,而验证是在调用方。这和常见的加密和验签方向是反过来的,需要注意。

另外这条强调了本地不得保存,这里的本地应该包括App里、App方的服务器。不过实际中这个情况很难审查和核实

  • 7.2.2.4 交易结束后清除临时数据
    • 临时文件
    • 内存

这条应该包括了App中和App方的服务器上两者。不过可能在执行中比较难于检查

7.3 服务安全设计

7.3.1 授权管理

  • 最小授权原则
  • 服务变更应该对应调整权限

这里描述了权限的规则,但是并没有描述如何度量和检验。实际中,API的权限是非常繁琐和细节的一个事情,对于复杂权限和访问控制管理,我们推荐参考UMA类似的访问控制模型(图片来自Keycloak文档): UMA访问控制

这里同时指定了当服务变更时候,需要重新调整权限。实践中,除了服务变更时以外,API管理系统应该具备仿真功能(仿真指模拟特定用户或者特定角色来访问某个资源),并且定期的检查权限设定是否符合预期。这有些类似开发中的回归测试

7.3.2 攻击防护

  • 7.3.2.1 API和SDK具备“常见防攻击能力”

虽然这条并没有太明确的指定“如何”防“哪一类”攻击,但是如果没有防护能力是不可以的。所以常见的比如防SQL注入,应该是基本“满足”规范

  • 7.3.2.2 移动SDK具备防逆向能力

    • 反汇编
    • 反字符串分析
    • 反导入导出函数识别
    • 反配置文件分析
  • 7.3.2.3 移动SDK反动态调试

    • 防动态挂接调试器
    • 防动态跟踪
    • 防篡改文件
    • 防动态修改内存

7.3.3 安全监控

  • 7.3.3.1 完整记录接口访问日志

  • 7.3.3.2 日志内容

    • 交易流水号
    • 应用唯一标识
    • 接口唯一标识
    • 调用耗时
    • 时间戳
    • 返回结果(包括成功失败状态)
  • 7.3.3.3 隐私保护(部分屏蔽)

    • 支付账号及等效信息
    • 个人金融信息

7.3.4 密钥管理

  • 7.3.4.1 加密和签名密钥分离
  • 7.3.4.2 私钥和App_Secret,明文不可以写入代码和配置文件
  • 7.3.4.3 密钥要求有效期管理,定期更新

8. 安全部署

8.1 API服务层功能

  • 8.1.1 流量控制

    • API区
  • 8.1.2 监控分析

    • API区
  • 8.1.3 认证鉴权

    • API区
    • 业务区
  • 8.1.4 报文交换

    • API区
    • 业务区
  • 8.1.5 服务组合

    • API区
    • 业务区

8.2 API区隔离

  • 8.2.1 与业务区隔离

    • 防火墙
    • IPS
  • 8.2.2 与互联网隔离

    • 防火墙
    • IPS

8.3 遵循标准

  • 8.3.1 符合JR/T 0071安全控制措施
  • 8.3.2等保二级以上

9. 安全集成

9.1 App方核准

  • 9.1.1 App方准入

    • 9.1.1.1 接入需要做审核,签订协议

    • 9.1.1.2 准入审核

      • 9.1.1.2.1 服务客群
      • 9.1.1.2.2 服务场景
      • 9.1.1.2.3 市场份额
      • 9.1.1.2.3 运营能力
      • 9.1.1.2.4 风控能力
    • 9.1.1.3 评估重点

      • 9.1.1.3.1 技术能力
      • 9.1.1.3.2 管理水平
      • 9.1.1.3.3 用户信息保护能力
      • 9.1.1.3.4 安全防护能力
      • 9.11.3.5 信息安全建设水平
    • 9.1.1.4 API接口合作协议

      • 9.1.1.4.1 合作业务场景
      • 9.1.1.4.2 接口应用范围
      • 9.1.1.4.3 交易量预测
      • 9.1.1.4.4 API集成模式
      • 9.1.1.4.5 不可访问未授权信息
      • 9.1.1.4.6 用户信息安全保障责任
      • 9.1.1.4.7 交易安全保障责任
  • 9.1.2 App方身份核验

    • 9.1.2.1 App方提交材料

      • 运营资质
      • 法人信息材料
      • 主要开发人员个人信息(身份证)
    • 9.1.2.2 核验内容

      • 有效性
      • 完整性
      • 真实性
      • 合规性

9.2 接入安全控制

  • 9.2.1 身份认证

    • 9.2.1.1 App方身份声明

      • App_ID

      • App_Secret

      • 数字证书或者公私钥对

      • App_Secret和公私钥对的组合

      • 银行应该对App方公钥进行登记

      • 银行应该对App_ID进行统一管理,并基于此

        • 身份认证
        • 状态校验
        • 权限控制
    • 9.2.1.2 银行方认证

      • 9.2.1.2.1 App_ID + App_Secret
      • 9.2.1.2.2 App_ID + 数字证书
      • 9.2.1.2.3 App_ID + 公私钥对
      • 9.2.1.2.4 如上的组合
      • 9.2.1.2.5 A2类API,需要采用除了9.2.1.2.1 之外的方式
      • 9.2.1.2.6 应该设置会话有效期或者令牌有效期
      • 9.2.1.2.7 银行应该可以主动屏蔽令牌,以应对应急处理
  • 9.2.2 安全传输

    • 9.2.2.1 A1类应该保证数据完整性,必要时采用数字签名
    • 9.2.2.2 A2类应该采用数字签名保障完整性
    • 9.2.2.3 应该采用TLS1.2以上版本做链路加密

9.3 运行安全

  • 9.3.1 用户身份认证

    • 9.3.1.1 认证应该在银行完成
    • 9.3.1.2 用户输入的信息不应该保存在App方
    • 9.3.1.3 银行应该最小时间原则维护会话有效期
  • 9.3.2 权限控制

    • 9.3.2.1 银行应该对API做权限控制

    • 9.3.2.2 权限控制的依据

      • App方
      • App_ID
      • API
      • 用户
      • 最小授权
    • 9.3.2.3 App需要用户明示同意,且授权有有效期

      • 操作:获取、使用、变更
      • 用户信息
      • 账户
      • 资金
    • 9.3.2.4 银行应该控制API调用有效期

      • 单次调用
      • 阶段性调用
      • 协议有效期内
    • 9.3.2.5 银行应该为用户提供关闭API能力

      • 通过网点
      • 通过电子银行
  • 9.3.3 数据安全:App方应该

    • 9.3.3.1 校验数据的完整性,对于不完整数据要停止处理

    • 9.3.3.2 数据机密性保护

      • 不应该采集和存储个人金融信息或支付敏感信息

      • 需要输入支付敏感信息的

        • 采用银行SDK
        • 报文加密
        • 完整性
        • 机密性
        • 本地不留存
      • 抗抵赖性

        • 使用数字签名
        • A2类数据
      • 删除与销毁(合作终止后)

        • 删除通过API获取的银行数据
        • 删除通过API获取的银行用户数据
      • 灾备与审计

        • 和API相关的数据
        • 备份
        • 灾备
        • 配合主管部门反洗钱、反欺诈
  • 9.3.4 App方安全能力

    • 9.3.4.1 应该符合国家网络安全法

      • 安全设计
      • 安全建设
      • 安全保护
    • 9.3.4.2 应该遵守银行的安全要求

    • 9.4.3.3 应该保留相关设备的日志

      • 应用系统
      • 网络设备
      • 主机设备
      • 安全生产日志
      • 存储满足国家要求
      • 日志存留至少6个月
    • 9.4.3.4 应该防止接口滥用

  • 9.3.5 App方接口能力

    • 9.3.5.1 App方应该正确合理使用API

    • 9.3.5.2 密钥及证书管理

      • 加密存储
      • 防止丢失或泄露
      • 遵守银行方的规定
    • 9.3.5.3 SDK管理与使用

      • 不得反编译
      • 不得篡改
      • 不得二次封装
    • 9.3.5.4 缺陷处理

      • 应该及时处理
      • 应该通知银行方
      • 不得泄露给银行外的第三方
    • 9.3.5.5 漏洞处理

      • 禁止利用漏洞
      • 禁止网络攻击
      • 禁止信息窃取
      • 禁止交易欺诈

9.4 应用方退出

  • 9.4.1 银行方

    • 制定退出方案和流程
    • 保障账户安全
    • 保障资金安全
    • 保障信息安全
    • 履行用户告知义务
    • 认证信息作废、归档、保存待查
  • 9.4.2 App方

    • 妥善处理用户信息
    • 遵照银行要求
    • 妥善处理银行业务有关资料
    • 按照协议承担保密责任

10. 安全运维

10.1 安全检测

  • 10.1.1 运维检测

    • 银行应该建立API运维平台,纳入统一监控平台

    • 应该监控API相关服务器状态

    • 应该监控API状态

      • 耗时
      • 交易量
      • 成功率
      • 告警机制
    • 日志

      • 交易日志应该按照国家会计准则保存
      • 系统日志保存期应该不少于1年
  • 10.1.2 异常检测

    • 10.1.2.1 银行方应该具备

      • 流量监控

      • 故障隔离

      • 黑名单控制

      • 流量控制

        • 最大并发数

        • 单位时间最大交易量

        • 控制措施

          • 告警
          • 暂停
          • 拒绝
      • 发现和监测

        • 未授权
        • 冒用
        • 及时发现及时处理
      • 故障检测和恢复能力

      • App方黑名单管理

    • 10.1.2.2 App方应该具备

      • 调用程序有熔断机制

        • 根据交易失败笔数
        • 根据API失败笔数
      • 熔断措施

        • 拒绝交易
        • 暂停服务调用
      • 调用异常告警机制

10.2 风险控制

  • 10.2.1 服务风险控制

    • 10.2.1.1 银行应该建立App方信息更新和复审机制

      • 基本信息
      • 运营能力
      • 风控能力
    • 10.2.1.2 银行应该定期评估App方运营情况

      • 基于日志
      • 监控
      • 必要时进行限流
      • 及时通知App方
    • 10.2.1.3 银行应该评估App方风险承受能力,和能力挂钩

      • 账户关联
      • 服务类型
      • 交易额度
  • 10.2.2 交易流程控制

    • 10.2.2.1 身份认证服务应该识别是否经过本人认证

    • 10.2.2.2 应该识别交易是否由本人(或授权)发起,应该核实本人意愿

      • 账户查询
      • 资金交易
      • 金融产品
      • 服务申请
    • 10.2.2.3 高风险金融服务

      • 提示用户安全风险
      • 履行用户告知义务
  • 10.2.3 交易风险监控

    • 10.2.3.1 应该将API纳入风险监控范围

    • 10.2.3.2 应该实时监控

      • App方资金活动
      • 用户账户资金活动
    • 10.2.3.2 资金交易应该满足行业监管要求

      • 反洗钱
      • 反欺诈
    • 10.2.3.3 应该对大额、异常资金收付逐笔

      • 监控
      • 核查
      • 及时预警
      • 及时控制
    • 10.2.3.4 应该对监控到的风险交易

      • 及时分析
      • 及时处置

10.3 变更控制

  • 10.3.1 当API变更时,银行应该

    • 及时评估影响
    • 及时告知App方
    • 制定变更方案
    • 制定应急预案
    • 按需发布
    • 充分履行用户告知义务
  • 10.3.2 App方在使用发生重大变更时

    • 重大变更

      • 可能影响银行业务连续性
      • 可能影响银行安全性
      • API集成方案发生修改
      • 交易量预期发生变化
    • App方应该

      • 制定应急预案
      • 制定变更方案
      • 评估风险
      • 及时告知银行
      • 及时充分履行用户告知义务
    • 银行方应该

      • 评估风险
      • 评估影响
      • 采取措施

10.4 运维巡检

  • 10.4.1 巡检内容

    • 接口代码安全审计
    • 渗透测试
    • 及时处理安全漏洞
    • 控制安全风险
  • 10.4.2 银行应该对App方

    • 安全集成情况进行检查
  • 10.4.3 App方应该

    • 对API接口程序进行巡检
    • 定期评估
    • 及时处理安全漏洞
    • 确保调用真实有效

10.5 事件处理

  • 10.5.1 银行方应该

    • 制定应急处理方案
    • 及时处理异常
    • 及时处理告警
    • 及时处理生产事件
    • 协调App方配合事件调查

11. 服务终止与系统下线

11.1 服务终止前

  • 11.1.1 通知相关方
  • 11.1.2 提交“统一识别码”注销申请

11.2 应用方

  • 11.2.1 数据归档
  • 11.2.2 数据删除或销毁
  • 11.2.3 个人金融信息保护
  • 11.2.4 用户资金与账户安全
  • 11.2.5 消费者权益保护
  • 11.2.6 履行用户告知义务

11.3 系统方

  • 11.3.1 接口下线要在“服务确认终止”后执行
  • 11.3.2 设置挡板,明示服务终止

11.4 接口下线后

  • 11.4.1 数据归档
  • 11.4.2 保留期限遵守国家规定

12. 安全管理

12.1 安全制度

  • 12.1.1 把API管理纳入现行管理体系

  • 12.1.2 API全生命周期做安全管理

  • 12.1.3 API采用统一格式识别码,并注册和登记

  • 12.1.4 信息公告

    • 官网
    • 其他渠道
    • 及时更新
  • 12.1.5 全生命周期的管理制度和控制措施

    • 验证制度和措施的有效性
    • 确保API的一致性和连贯性
    • 保障API效率和安全性
  • 12.1.6 开发手册

    • "应该"提供开发手册
    • 安全集成要求
    • 测试环境的使用

12.2 安全应用责任

  • 12.2.1 银行和应用方合同与协议

    • 12.2.1.1app需要收集消费者个人金融信息

      • 直接获得金融消费者的“明示同意”
      • 遵循“最少够用原则”
      • 不可以“不明示”
      • 需要说明信息收集是“App行为”,与银行无关
    • 12.2.1.2 明确App与银行的安全责任

    • 12.2.1.3 App方不可以

      • 转移数据
      • 转移“能力”
      • 共享
      • 分包
    • 12.2.1.4 协议有效期

      • 一旦签订协议,无论关系是否续存,都需要保护用户信息

12.3 安全审计

  • 12.3.1 银行方

    • 12.3.1.1 应该完整记录API访问日志
    • 12.3.2 根据需求和风控要求,“最少够用”的适当保留App方请求报文
    • 12.3.3 保证日志完整,不被篡改、删除、覆盖
  • 12.3.2 App方

    • 12.3.2.1 应该完整记录API访问日志

    • 12.3.2.2 保证日志完整,不被篡改、删除、覆盖

    • 12.3.2.3 应该提供查询

      • API登录
      • API授权
      • API交易
      • 各种操作