|
2020年2月13日,中国人民银行发布《商业银行应用程序接口安全管理规范》(JR/T 0185—2020)(下称“标准”)金融行业标准。标准规定了商业银行应用程序接口的类型与安全级别、安全设计、安全部署、安全集成、安全运维、服务终止与系统下线、安全管理等安全技术与安全保障要求。
近几年来,开放银行成为银行业颇受关注的一大热点,而在开放银行的讨论中,由于缺乏统一的管理标准,安全问题一直备受争议,标准的发布,从应用程序接口安全管理的角度,为开放银行健康发展提供了一定的支持。
标准对于应用程序接口的界定是怎样的呢?
商业银行应用程序接口服务是一种依托API技术实现内部与外部互联的金融服务模式。商业银行通过为合作伙伴提供用以互联的应用程序接口,输出自身金融服务能力与信息技术能力,为增加金融生态粘性提供有益补充。
标准称,商业银行使用的API类型可分为内部API、企业定制API与外部API三种类型。
内部API指银行内部系统间的API,促进了业务系统间的信息互通,仅供银行内部使用。
企业定制API指银行与特定合作伙伴之间定制集成,目标是支持特定的业务流程或产品的API,甚至使用专用网络进行通信。
外部API指银行广泛地向应用方提供标准接口,供外部合作伙伴使用的API。外部机构可以通过互联网渠道,调用外部API,获取商业银行提供的各类服务。
标准所述应用程序接口为外部API。
商业银行应用程序接口服务的3个参与方
标准指出,商业银行应用程序接口服务的参与方有用户、应用方及商业银行,并界定了各方在商业银行应用程序接口服务中扮演怎样的角色,应承担怎样的责任。
用户发起商业银行应用程序接口应用请求,并接收应用方和商业银行返回的处理结果。
应用方负责接收并处理用户请求,通过应用程序接口向商业银行提交相关请求、接收返还结果,依照流程进行服务请求处理或反馈用户。
商业银行通过API直接连接或用SDK间接连接的方式向应用方和用户提供应用程序接口服务,实现商业银行服务的对外输出。
商业银行构建商业银行应用程序接口、应用程序接口服务层和银行业务系统以提供商业银行应用程序接口服务。商业银行应用程序接口服务层将应用方请求转发至银行业务系统处理,并将处理结果反馈应用方或用户,包含认证鉴权、流量控制、监控分析、报文交换、服务组合等功能,不涉及具体业务逻辑处理,实现对商业银行应用程序接口和应用方的管理。
标准对商业银行应用程序接口服务的接口设计、应用部署、安全集成、运维监测及系统下线等全生命周期过程提出安全技术与安全管理要求,对各个过程均提出了安全要求。
在标准提及的3个参与方中,商业银行作为服务提供者,应用方作为第三方,两者共同为用户服务。那么,在全生命周期的各个阶段,标准对于商业银行及应用方的安全要求分别是怎样的?
标准对商业银行的安全要求
移动支付网整理了标准中与商业银行相关的条款,可以看出,标准对商业银行的要求贯穿接口的整个生命周期,涵盖接口设计、应用方接入、接口调用时的监测、系统(接口)下线各个相关场景。
标准按照服务类型将商业银行应用程序接口安全级别分为两级,安全保护要求从A2至A1递减:
A2:资金交易与账户信息查询应用类,此类金融产品和服务与用户个体直接关联,实施高等级安全保护强度,此类商业银行应用程序接口包括但不限于:
商业银行通过SDK,提供资金交易类服务,如支付、转账以及金融产品与服务购买等;
商业银行通过SDK,提供用户账户信息查询类服务,如账户余额、交易历史、账户限额、付款时间、金融产品和服务持有情况等;
对于上述服务,若确需使用API直接连接方式进行服务调用,商业银行应对接入风险评估,并制定专门的接口和应用方进行对接,实施高等级的安全保护强度要求。
A1:金融产品和服务信息查询应用类,此类金融产品和服务与用户个体并无直接关联,实施通用的安全保护强度,此类商业银行应用程序接口包括但不限于:商业银行提供银行金融产品和服务的详细信息的“只读”查询服务。
标准对应用方的安全要求
与标准对商业银行的要求相比,标准对应用方的要求涉及的生命周期阶段相对较少,主要集中在接口调用时的安全问题和风险监测上,应用方一方面需要对用户负责,做好安全运维工作,另一方面,商业银行具有限制调用时长等接口调控能力,应用方调用接口行为的合规性就尤为重要。
颇值得一提的是,标准提出,应用程序接口采用统一格式的识别码,并在相关平台进行注册和登记,“实名制”应用程序接口已经在路上。
可以想见,对应用程序接口的安全规范只是第一步,开放银行的监管探索仍是进行时,需要行业各方共同关注。
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作! |
|