开放银行通过 API（应用程序接口）与 TSP（第三方服务提供商）等技术将银行服务与产品直接嵌入合作平台，实现了银行与第三方之间的数据信息共享与融合。开放银行模式实现银行传统线下金融业务数字化，通过和业态合作拓展业务可以让银行获取 场景数据，实现穿透式管理，更好地帮助银行精准构建用户画像，提供细致的金融服务。
在此汇总的开放银行落地实践案例，基于数据合规要求，说明其中的数据保护要点，以期望为开放银行的数据保护方案、流程提供易于参考和实践的指引。
一、数据访问控制安全平台
案例关键字：数据访问控制；基于属性(ABAC)的上下文模型
案例提供方：中国建设银行
（一）合规概况介绍
在数据使用方面，为满足数据使用的“最小化”原则，建成全行企业级的数据安全访问控制平台，提供业务过程中细粒度的数据安全访问控制，着力于解决个人信息保护与业务场景相融合的难题。
（二）背景
中国建设银行在进行数字化转型过程中，明确数据是企业重要的战略资产，是驱动线上业务快速发展、完成战略转型的核心力量。而伴随着数据的高度集中，广泛使用，数据泄露风险也日益加剧，而传统数据安全更偏向 IT 与技术手段，难以满足需要与具体业务场景融合的个人信息保护需求，存在以下痛点：
- 一是个人信息查询问题的涉及面极广，几乎涉及到了企业所有业务系统中的每一项业务、每一支交易接口；
- 二是发起个人信息查询业务的场景极其复杂。通常访问控制策略需要对业务场景，访问者的身份属性，访问的环境属性，以及所访问的数据属性进行判断，根据属性信息动态的执行访问控制，才是将访问控制落实到具体业务，且最小化内部人员数据权限的有效数据安全措施。
传统的解决方案，数据权限与访问控制策略逻辑只能由每一个业务系统的开发人员硬编码到业务系统代码中，需要企业投入大量时间成本、人力成本和资金成本对现有系统功能改造。如果未来新的业务功能涉及个人信息查询问题，或者监管要求的调整，必然增加额外的资源投入，延缓新业务功能的发布速度。同时，业务逻辑中混入的数据访问控制策略代码难以维护与灵活调整，很难应对未来的政策要求。
随着相关数据安全法规和制度逐渐完善，监管要求日趋严格，数据安全防范需求尤为紧迫，亟需通过相关信息系统和技术框架体系的建设，规范员工数据使用行为，保护客户隐私。为此，建行于 2020 年启动了数据访问控制安全平台项目，经过近两年的落地验证，已建成全行企业级的数据安全访问控制平台，为数百个系统提供了业务过程中细粒度的数据安全访问控制，充分保护了客户的金融个人信息，着力于解决个人信息保护与业务场景相融合的难题，从业务系统数据资产梳理、到由业务需求出发制定访问控制策略、再到自动同步个人信息查询业务相关属性数据执行访问控制，平台为个人信息保护的每个关键环节提供了良好的技术支持，至此个人信息保护得以落实，数据安全治理得以完善，很好的适配了相关法规对个人信息保护的各项要求。
（三）方案
1. 解决思路
图 5 系统整体架构
要根除个人信息查询管理混乱的问题，建设易于实施、可持续使用、为企业降本增效的数据访问控制安全平台，以下是能触达目标的三个关键步骤：
（1）全局掌握业务过程中涉及个人信息查询的数据接口
应用系统的 API 接口是个人信息输出的重要关口，将数据访问控制点设在应用接口返回用户数据时，是实现数据访问控制的最理想途径。应用 API 接口都由什么业务在调用，每个接口都在输出些什么类型的数据，接口输出的数据是否包含个人敏感信息， 厘清这些信息，是建立企业级 API 数据访问控制关键的一步。
（2）整体评估业务过程中个人信息的访问控制策略
业务办理过程中的个人信息保护不能简单地一刀切。如果对所有个人信息都进行脱敏屏蔽，将导致很多需要核实个人信息的业务无法办理。企业需要在不影响业务正常执行的前提下，最小化用户对个人信息的查询权限，解决查询权限混乱与查询业务操作不规范的问题。
（3）通过平台实现数据访问控制统一管理
全面的数据接口测绘与数据风险评估是解决个人信息查询问题的必要过程，但要真正解决个人信息查询的数据安全问题，最终必需要在每一支交易中实现访问控制。
2. 解决方案
图 6 数据访问控制安全平台解决方案
（1）全面盘点应用 API 资产，并赋予 API 业务属性
要建立企业级数据访问控制平台，在应用接口返回用户数据时实现访问控制，需要先对企业应用数据接口进行全面的数据资产治理，梳理清楚应用系统所有的 API 接口， 接口数据包含的字段，以及数据的个人敏感信息情况，才能有的放矢，将访问控制落实到具体业务接口的具体敏感数据字段。
（2）构建基于属性（ABAC）的访问控制上下文模型，自动同步访问控制所需的属性数据
基于属性(ABAC)的上下文模型是从发起访问的用户、账号、应用，被访问的数据、应用、接口，以及访问发生时环境的属性出发，构建由访问主体，访问客体，访问环境属性组成的结构模型。接口数据访问发生时，系统自动同步“运行时”上下文属性数据，并与策略条件设置的值或范围进行匹配，执行与条件相符的输出。在整个接口数据访问控制闭环里， ABAC 构建的是一种动态数据访问控制模型，基于属性和环境条件授予访问权限，具有即时生效的特点，策略改变/属性改变后访问控制的结果即时生效，这种特性为应用系统提供了更大的灵活性，同时平台提供低代码窗口扩展上下文模型属性，管理员可根据业务需求自定义属性类型，扩展属性与内置属性共同构建更加完善的上下文模型，满足各种应用不同业务的访问控制需求。
（3）可视化制定多层级影响范围的访问控制策略
平台以访问控制上下文模型和 ABAC 策略方法为基础，为用户提供可视化，低代码的访问控制策略编辑工具。用户可通过拖拉拽的方式将策略元素放置到策略编辑栏中，并以流程编排模式编辑访问控制执行逻辑，可使用上下文中的任意属性，组合各种逻 辑作为访问控制条件，为各个逻辑分支配置或保留、或脱敏、或移除的数据输出结果。
（4）从业务需求出发的接口数据整体评估
业务是数据的直接使用方，什么数据是在办理业务时需要看到的，什么数据是高度敏感不可完全显示的，以及哪些数据是业务不需要的多余数据，业务人员对这些信息的掌握最为准确。平台提供从业务出发对接口数据访问控制需求进行评估的通道，评估人员可通过接口数据模型，对已识别的敏感数据字段进行业务评估。策略配置人员参考评估结果，制定准确、有效的访问控制策略。
（四）成效及价值
1. 技术成效
通过构建企业级平台，系统性解决业务过程中的数据访问安全问题是数据安全领域的一个难题。与传统的数据安全相比较，其复杂程度高、未知问题多、不具参考性，往往解决了一个难题，另外一个难题又接踵而至。解决此难题，需要全面的技术创新， 在平台建设过程中两项具有代表性的技术创新过程如下：
（1）运行时交易报文的动态结构测绘：业务过程中的数据由应用系统运行时产生，它们不像数据库中存储的数据，看得见摸得着。要对运行时数据进行安全访问控制，就必须先准确测绘出每一支交易的报文结构、字段分级分类、补充所需的各种元数据。面对此项挑战，通过埋点技术手段采集运行时数据，结合人工智能技术识别数据字段的分级分类，创新了分支特征算法、分支识别算法、分支合并算法等专门用于交易接口业务分支测绘的一系列算法。
（2）访问控制执行方式与 SDK：业务办理过程中的数据访问控制技术与普通的数据脱敏技术不是一个概念，这里通过两个显著特性说明其技术创新性：
- 一是普通的数据脱敏只需要提供数据脱敏算法与一些数据批处理能力，而业务办理过程中的访问控制需 要由整个业务上下文决定：是否对某个字段进行脱敏需要根据正在执行什么业务，访 问者的岗位、角色、所属机构，被访问的是什么数据，访问发生的时间、客户端所属 的网络环境等要素进行综合判决。
- 二是访问控制的执行点需要嵌入到应用系统的业务逻辑中，这里又面临了多重技术挑战：SDK 的集成不能对现有应用产生较大的侵入性，集成需要快速、简便；SDK 需要能够动态收集判决所需的业务上下文信息；SDK 需要有极高的执行性能、稳定性与容错能力，以建设银行自身的实践为例，访问控制 SDK 集成在建设银行日均交易量数亿的业务系统中，每一笔交易数百上千个字段，全部都经过了访问控制引擎。访问控制 SDK 无论在策略解析、策略缓存、报文解析、访问控制执行等各环节上均采用了多种创新技术，在不增加计算硬件资源的条件下提供了全行业务过程中的数据安全访问控制服务。
2. 业务成效
经过近两年的落地验证，中国建设银行已建成全行企业级的数据安全访问控制平台，统一访问控制策略，为行内员工渠道上数百个系统提供了业务过程中细粒度的数据安全访问控制，日均处理交易请求近 3 亿条，充分保护了客户的金融个人信息安全。
二、基于责任链的开放银行数据保护及合规实践
案例关键字：责任链模型；数据保护
案例提供方：中国农业银行
（一）合规概况介绍
数据收集合规方面，开放银行在提供用户信息相关服务时，若涉及收集用户信息将以签署授权协议的方式获取用户授权；数据共享使用方面，第三方在调用获取、使用、变更客户信息、账户、资金等接口时，需先取得客户明示同意，同时开放银行依据最少够用原则，采用了报文非必要字段过滤及关键字脱敏的方式；数据传输合规方面，通道层基于 TLS1.2 及以上版本安全通道进行通信，应用层支持标准国际国密算法加密，为保证与第三方之间数据传输的完整性与不可抵赖性，采用数字签名技术，为合作方应用一对一颁发证书，后续通过证书来验证第三方合法身份；数据存储合规方面，平台不存储业务类数据，业务数据从后台关联系统获取，技术类数据则入库大数据平台永久保存，对于交易日志，在完成去标识化处理后上送运维平台展示，并依据标准脱敏规则，对邮箱、身份证号、手机号等信息进行脱敏处理。
（二）背景
开放银行作为金融机构开放数据的载体，通过与第三方机构合作，实现了银行与第三方间数据服务的开放共享，将银行服务嵌入到用户生活的方方面面。在数据的共享和流转过程中，如何保障数据安全和用户隐私则显得尤为重要。为此，农业银行开放银行提出了一种基于责任链模型的开放银行数据保护解决方案。该方案基于 ZuulFilter 责任链模式构建了开放银行认证授权及数据保护体系，由一系列紧密配合工作的 Filter 按照预设的 FilterOrder 实现，Filter 间不直接通信，通过 RequestContext 共享状态。
（三）方案
1. 开放银行数据保护责任链模型
图 10 开放银行数据保护责任链模型
开放银行数据保护责任链模型主要包括三部分：Pre Filters、Error Filters 和 Post Filters。Error Filters 和 Post Filters 分别负责进行统一异常处理和事后流水记录，Pre Filters 是模型的重点，包含了一系列的数据处理节点，上图重点列出了一部分。
其中，报文转换节点用于校验合作方报文格式是否符合 HTTP 规范以及是否满足开放银行标准；鉴权节点用于鉴别合作方是否具有开放银行接口访问权限；签名验签节点通过验证合作方数字证书的有效性以确认合作方身份真实性；加解密节点在应用层面采用密钥加密手段保护数据安全；后台调用节点负责链接我行多样的开放金融产品服务；输出过滤节点可根据实际需求过滤掉报文中的非必要字段，保证了信息的最小集输出原则；关键字脱敏节点可按预设脱敏规则对响应报文的敏感信息进行脱敏处理，保护用户隐私；组装响应报文节点在完成前面所有节点处理后将组装后的响应数据共享给合作方。
责任链模型中各个处理节点形成了先后的层级关系，但各个节点间互不影响，耦合度较低，仅通过 RequestContext 共享状态。Pre Filters 执行过程中失败则会由 Error Filters 接手处理，执行完毕后进入 Post Filters 记录流水日志。只有链条上所有节点均正常执行完毕后，才会视为请求处理成功。
（四）成效及价值
（1） 技术成效
本案例中所提出的开放银行数据保护责任链模型包含了一系列的安全控制节点，有效保障了数据安全和用户隐私，符合目前数据安全相关政策要求。同时，在数据的收集、使用、传输和存储阶段，提出了对应的解决方案。责任链模型中众多的安全节点，犹如一道道关卡，在数据的生命周期管理中，起到了较好的保护作用，从而实现了同第 三方机构之间便捷、高效、安全的数据共享。
（2） 业务成效
本模型已广泛应用在农业银行开放银行的开放服务中，包括但不限于电子账户、数字钱包等产品，涉及社保、教育、出行等多方面领域。截至 2022 年底，已在 400 余个总分行接口、2500 余个合作方应用中得到了可靠的实践。
本文摘编自中国银联技术管理委员会发布的《开放银行数据保护与合规实践案例报告》，全文下载：
开放银行数据保护与合规实践案例报告
更多标准、白皮书、报告等高质量纯净资料下载，在文末扫码关注官方微信公众号“idtzed”，进入公众号菜单“治库”，或按自动回复发送引号内关键词。
一条评论