金融服务作为一种基础服务，存在于“无形”又无处不在，商业银行纷纷与互联网巨头及政府机构合作，借助金融科技云和特色金融服务的能力输出，嵌入场景生态，促进金融服务开放。2020年2月13日，中国人民银行发布《商业银行应用程序接口安全管理规范》（JR/T0185—2020）（以下简称《规范》）金融行业标准，促进开放银行服务模式安全稳健发展，指导银行业金融机构和集成接口服务的应用方落实网络安全责任。《规范》首先定义了商业银行应用程序接口的类型与安全级别，然后提出了应用程序接口安全体系，包括安全设计、安全部署、安全集成、安全运维、服务终止与系统下线、安全管理等维度。本文主要围绕《规范》中的安全设计内容谈谈认识和理解，供大家参考。
商业银行应用程序接口逻辑结构
商业银行为增加金融生态黏性，依托API技术，为合作伙伴提供用以互联的应用程序接口，输出自身金融服务与信息技术能力。开放的应用程序接口根据开放的范围和对象差异，可分为内部API、企业定制API与外部API三种类型。《规范》所述应用程序接口即为外部API，用户或应用方的连接方式包括API直连和SDK间接连接两种。SDK主要功能为降低接入复杂度，同时保证接入的安全性，主要用于涉及资金交易与账户信息查询类服务接入。应用方可根据服务安全风险等级选择相应的接入方式。
商业银行应用程序接口服务的逻辑结构如图1所示，包括应用程序接口、应用程序接口服务层和银行业务系统三个部分。用户或应用方通过应用程序接口提交服务请求，并通过商业银行应用程序接口服务层调用银行业务系统以获得商业银行业务服务。商业银行应用程序接口服务层将用户或应用方请求转发至银行业务系统处理，并反馈处理结果，其功能包括认证鉴权、流量控制、监控分析、报文交换、服务组合等功能，但不涉及具体业务逻辑处理，主要用以实现对商业银行应用程序接口、用户和应用方的管理。
图1商业银行应用程序接口逻辑结构
商业银行应用程序接口安全设计
开放银行服务模式在增加金融机构获客场景和提升金融服务黏性的同时，其开放性也扩大了商业银行受攻击范围，增加了网络安全风险隐患。例如应用方可能会访问或获取商业银行内部数据和客户信息，增加了商业银行数据泄露风险。甚至可能因应用方平台系统的安全漏洞或缺陷，导致应用程序接口的非法访问或服务超负荷等安全隐患，最终导致商业银行声誉风险和监管合规风险。本文依据《规范》“安全设计”内容要求，就如何防范网络安全风险，设计安全可靠接口进行探讨，包括设计基本要求、接口安全设计和服务安全设计三个部分。
1.设计基本要求
“设计基本要求”是商业银行应用程序接口安全设计的基础，贯穿接口安全设计和服务安全设计的始终。主要从密码技术的安全应用和应用系统安全性保证两方面提出基础要求，应用系统安全性保证又分为自主开发应用安全保证和第三方组件安全保证。
其一，密码技术的安全应用。应用系统安全性的核心机制在于密码技术的安全应用，因此《规范》中明确规定密码算法、技术及产品的使用，应符合国家密码管理部门及行业主管部门要求，防范因密码技术产品本身缺陷导致的安全风险。
其二，应用系统安全性保证。确保应用系统安全需要在开发过程中加强事中控制，既要保证自主开发部分安全可控，也要防范第三方组件安全风险。针对自主开发部分，企业内部安全开发标准和规范的落地实施，是保障商业银行应用程序接口安全性的必要条件，因此《规范》规定了安全设计的基本要求，如制定安全编码规范、进行安全编码培训、开展代码安全审计、制定版本管理与控制规程、防范信息泄露等。针对非商业银行开发的第三方组件安全风险，要求商业银行进行安全性验证，并持续关注相关平台的信息披露和更新情况，适时更新相关组件。
2.接口安全设计
开放银行服务模式通过开放API接口嵌入跨境、运动等场景生态，输出金融服务能力。从业务服务维度看，对于涉及资金交易与用户敏感信息服务的API接口，承受较高的网络安全风险，相反则风险较低。因此《规范》将商业银行应用程序接口分为两类，一类是安全级别较高的A2级接口，例如实现支付、转账、金融产品与服务购买等功能的接口，以及实现查询客户账户余额、交易历史、付款时间以及金融产品和服务持有情况等功能的接口，另一类是安全级别较低的A1级接口，用于实现金融产品和服务信息的查询，不涉及用户个人敏感信息。进而《规范》从技术维度细化安全要求，并重点规范A2级接口的安全设计要求。
API接口的安全设计，主要考虑身份识别和认证、数据安全交互和敏感信息保护等三方面内容。
第一，身份识别和认证，主要考虑如何识别和认证接口调用方的真实身份，以解决谁在用以及是否根据授权进行合法使用的问题。在对A2级别接口应用方身份进行认证时，要求使用数字证书或公私钥对的方式进行双向身份认证，以确保应用方身份合法并根据授权范围使用API接口。同时商业银行还应对使用开放银行服务的用户身份进行认证，履行客户资金和信息保护义务，对于A2级别接口中的资金交易类服务，用户登录身份认证应至少使用双因子认证的方式来保护账户财产安全。
第二，数据安全交互，主要考虑如何有效校验和审核通过API接口交互的数据，以解决数据污染，系统安全运行问题。商业银行应用程序接口应对双方系统间连通有效性进行验证，如接口版本、参数格式等，并对数据的完整性进行保护，以确保应用系统按照规划设计运行。对于A2级别的接口，商业银行和应用方均应使用数字签名来保证交互数据的完整性和不可抵赖性，以确保用户办理业务数据的真实性、有效性和安全性。
第三，敏感信息保护，主要是规划敏感信息使用、交互及存储规则，以满足客户敏感信息保护要求，解决敏感信息泄露等问题。相关要求可从两个维度来理解，一是交易过程中，对于登录口令、支付密码类敏感信息，应采取自定义软键盘、防键盘窃听、防截屏等安全防护措施，确保用户口令不被恶意软件盗取；对于账号、卡号、卡有效期、姓名、证件号码、手机号码等敏感信息，在传输过程中应使用集成在SDK中的加密组件进行加密，或对相关报文进行整体加密处理，确保数据传输过程安全；对于应用方客户信息获取需求，确需商业银行提供的，如账号、卡号、姓名等用户敏感信息应脱敏或去标识化处理；因清分与清算、差错对账等需求，确需将卡号等支付账号传输至应用方时，应使用加密通道进行传输，并保证信息的完整性等要求；二是交易认证结束后，商业银行需及时清除用户支付敏感信息，防范攻击者通过读取临时文件、内存数据等方式获得全部或部分用户信息。
3.服务安全设计
开放银行服务模式既要采取有效措施防范潜在网络安全威胁，做好安全防护能力建设，抵御已知网络攻击手段，也要充分考虑用户和应用方差异化服务需求，满足商业银行安全管理和安全运维需求。《规范》中针对该部分主要从权限管理、密码密钥安全使用和管理、接口日志管理等三方面提出要求。
其一，权限管理。针对应用方差异化服务需求，服务安全设计需遵循最小化授权原则，配置灵活易用的接口权限控制策略，以满足商业银行对接口权限的授权及管理需求，当应用方服务需求变更时，能够根据需求评估结果及时调整开放给应用方的接口范围及使用周期等权限。
其二，密码密钥的安全使用和管理。安全管理的核心问题在于密码密钥的安全使用和管理，《规范》针对商业银行应用程序接口使用授权和控制的关键要素，即数字证书或公私钥对等的使用进行规范，一是建议加密和签名分配不同的密钥，且分离存储。二是禁止将密钥编写在应用程序代码或本地配置文件中，防止因代码泄露造成的安全隐患。三是要求依据应用程序接口安全等级设置不同的密钥有效期，并定期更新密钥。
其三，接口日志管理。针对系统安全运维需求，商业银行可通过在接口访问日志中记录交易流水号、应用唯一标识、接口唯一标识、调用耗时、时间戳、返回结果等信息，支持对接口使用情况的监控，从而实现监测指标预警，保障服务安全稳定运行。针对应用方运维监控需求，规范中明确规定因清分清算、差错对账等业务需要，接口日志中应以部分屏蔽的方式记录支付账号或其等效信息，除此之外的个人金融信息不应在应用方接口日志中进行记录。
（本文作者就职于中国银行软件中心）
———END———
限 时 特 惠： 本站每日持续更新海量各大内部创业教程，永久会员只需109元，全站资源免费下载 点击查看详情
站 长 微 信： nanadh666
