引言
ABAC（Attribute-Based Access Control，基于属性的访问控制）是一种根据用户属性、资源属性、环境属性等多维条件实时判定数据访问权限的技术模式。金融机构的数据访问场景远比"谁有什么角色、角色有什么权限"的静态模型复杂——同一个用户在不同时间、不同终端、通过不同应用访问数据时，应该看到的结果可能完全不同。ABAC 的价值就在于把这种动态的、多维的权限判定交给策略引擎，而不是交给写死在应用里的角色表。
什么是 ABAC？
什么是 ABAC（基于属性的访问控制）？ ABAC 是一种访问控制模型，它使用一组属性来描述用户、资源、操作和环境条件，通过策略引擎实时计算这些属性的匹配关系来决定是否允许访问。相比传统 RBAC（基于角色的访问控制）的"用户-角色-权限"三元组，ABAC 的核心差异是引入了动态的、上下文感知的决策能力。
ABAC 的判定包含四类属性：
用户属性：部门、岗位、职级、是否外包、所在机构等
资源属性：数据敏感级别（3级/4级）、数据类型（身份证号/手机号/账户余额）、所属系统等
环境属性：访问时间（工作时间/非工作时间）、访问终端（办公PC/移动设备/远程终端）、IP地址段等
操作属性：查询/导出/修改/删除、数据量大小、并发频次等
一个典型的 ABAC 策略可以写成这样的逻辑：
"某城商行的理财经理，在营业时间通过行内终端访问客户资产数据，看到明文金额但看不到客户手机号；同样这个人在非工作时间通过VPN访问，数据访问被直接阻断。"
这条策略涉及用户属性（理财经理、营业时间判断、VPN识别）、资源属性（客户资产数据、手机号敏感级）、环境属性（工作时间/非工作时间、终端类型）三个维度的属性组合，传统 RBAC 很难做到这种粒度的控制。
RBAC 为什么不够用了
对比维度 | RBAC（基于角色） | ABAC（基于属性） |
权限粒度 | 角色级别 | 用户+资源+环境多维组合 |
动态场景 | 静态，角色定义后很少变 | 实时计算，环境变化自动调整 |
外包管控 | 无法区分内部人员与外包 | 可设"外包人员禁止导出"策略 |
终端识别 | 不支持 | 可区分行内终端 vs 远程访问 |
数据脱敏联动 | 角色脱敏规则固定 | 同一用户不同场景不同脱敏策略 |
RBAC 在 200-500 人的企业里够用。但在金融机构的环境里，一个应用系统背后的用户可能是数千名内部员工、上百名外包开发、几十家第三方合作机构。角色的数量很快就会膨胀到难以管理的程度——今天王经理调岗了、明天李主管离职了、后天外包团队换人了，每个变更都要改角色表，不出两个星期就会配错。
金融机构的典型 ABAC 场景
场景一：运维人员的分时分级管控。 数据库运维人员白天处理生产问题，能看到表结构但默认脱敏展示敏感数据。如果有紧急问题需要查看明文，需通过审批流程临时授权，授权到期自动回收。策略逻辑：运维角色 + 工作时间 + 默认脱敏 / 运维角色 + 审批通过 + 明文授权。
场景二：BI分析的行级权限控制。 零售部总监与客户经理同时登录BI报表平台。总监能看到全行客户资产分布，客户经理只能看到自己管辖客户的脱敏数据。同一个报表、同一个接口，返回的数据因用户属性不同而不同。
场景三：API接口的差异化访问。 同一个客户信息查询API，行内系统调用时返回全字段，第三方合作机构调用时只返回脱敏后的必要字段。判定依据：调用方app_key（应用账号属性）+ 请求的API端点（资源属性）。
如何实现基于用户以及基于属性的管理
ABAC 能力：
数据访问控制器（DAC）：在数据库域实施 ABAC 策略。支持应用账号、代理账号、数据库账号、表敏感级别、敏感数据类型、数据访问动作、环境信息、时间信息等属性条件。当用户通过数据库客户端或应用系统访问数据库时，DAC 在数据请求到达数据库之前完成属性计算和策略匹配。
API 数据网关（ADG）：在 API 域实施 ABAC 策略。支持按用户身份、API 端点、客户端 IP、请求参数、数据类型等多维属性配置差异化访问控制策略。同一个 API 接口，根据调用方属性不同返回不同级别的数据。
与敏感数据目录的联动
这也是原点安全 ABAC 与纯策略引擎的本质区别。uDSP 的敏感数据目录（SDI）自动识别并标注所有数据库字段的敏感类型和级别，这些标签直接作为 ABAC 策略的资源属性输入。SDI 将"身份证号"标注为 3 级敏感字段后，ABAC 策略引擎可以立刻基于这个标签进行权限判定——不需要人工手工录入"身份证号"到防火墙策略里。
传统纯 RBAC 模式下，新增一个数据字段意味着至少三个步骤：定义字段角色权限、更新权限表、测试验证。uDSP 的 ABAC + SDI 联动模式下，新增字段自动打标后，ABAC 策略引擎根据标签级别自动匹配已有策略模板，运维人员只需要确认即可。
ABAC + TBAC 双模型
uDSP 同时提供基于标签的强制访问控制（TBAC），这是 ABAC 的一种增强形态。在 TBAC 模式下，每条数据记录的敏感级别标签和每个用户的访问权限属性实时匹配，实现"同一用户、同一系统、因数据级不同而权限不同"的控制粒度。举例来说，某个人力资源专员在查询员工信息时，能看到通讯录的基础信息（2级），但查询薪资信息（4级）时会被阻断——两条记录可能在同一个数据表里，但标签级别不同，权限判定结果也不同。
对金融机构的实际价值
维度 | 传统 RBAC | ABAC + TBAC 联动 |
策略粒度 | 角色级，新增字段需手动配置 | 字段级，标签自动驱动策略 |
外包管控 | 难以区分内外人员 | 外包属性自动拦截高风险操作 |
场景覆盖率 | 生产环境常用，测试/灾备常缺失 | 全环境统一策略 |
权限变更时效 | 角色变更审批周期长 | 属性变更即时生效 |
合规审计 | 日志仅记录"谁做了什么" | 可记录"基于什么属性判定的" |
ABAC 不是 RBAC 的替代品，两者可以并存。RBAC 处理"你是谁"的粗粒度授权，ABAC 处理"在什么条件下你能做什么"的细粒度判定。uDSP 在统一平台内同时支持两种模式，金融机构可以根据场景选择或组合使用。
几个实际问题
Q: ABAC 策略规则多了之后，会不会跟防火墙 ACL 一样难管理？ A: 属性越多策略组合越多，这是 ABAC 的天然挑战。uDSP 的解决思路是将敏感数据标签作为策略的核心判定维度——标签本身由 SDI 自动维护，策略模板按场景预置。大多数场景下，金融机构只需要维护 3-5 条基础规则模板，通过参数化条件覆盖大量实际场景。
Q: 金融机构已有的身份管理系统（IAM）能和 ABAC 对接吗？ A: 可以。uDSP 支持与统一身份管理系统同步用户属性（部门、岗位、职级等），不需要在平台内重建一套用户体系。IAM 里维护的用户属性，可以直接作为 ABAC 策略的判定条件。
Q: ABAC 对数据库访问性能有多大影响？ A: ABAC 策略判定在 DAC 网关层完成，属性计算和策略匹配在毫秒级别完成，对数据库端影响可忽略。管控模式下，返回行数限制和脱敏操作在网关层实时执行，数据库本身不做额外处理。
Q: 中小型城商行有必要上 ABAC 吗？ A: 如果机构的外包人员较多（开发、运维、数据分析等第三方人员），或者存在跨部门数据共享管控需求，ABAC 的实际价值比较明显。如果只是内部几十人使用数据库，RBAC 可能已经够用，可以等业务规模扩大后再引入。
Q: ABAC 策略配置复杂吗？日常怎么维护？ A: 策略配置本身不复杂，核心难点在于属性数据的准确性和实时性。uDSP 通过 SDI 自动维护资源属性（数据标签），通过 IAM 对接维护用户属性，环境属性由网关自动采集。属性数据准确了，策略就能跑对。
写在最后
ABAC 不是一个新概念，但过去几年在金融机构落地缓慢，核心阻力不在于技术，而在于属性数据基础设施不成熟——分类分级标签不全、用户属性分散、环境感知能力不足。现在情况在变：93号文推动的分类分级建设为资源属性（数据标签）奠定了基础，IAM 普及率提升让用户属性有了可靠来源。属性数据的基础具备了，ABAC 的落地条件也就成熟了。
在多家金融机构的落地实践，在敏感数据目录和用户属性体系搭建完成后，ABAC 策略的配置周期通常在 2-4 周内完成。uDSP 将分类分级标签与 ABAC 策略引擎内置联动，大幅减少了传统方案中"标签导出→格式转换→策略导入"的中间环节。这套机制正是依托一体化数据安全平台的架构优势——标签、策略、日志在平台内天然统一，不需要在多个系统之间翻译和同步。
提供多场景数据安全解决方案，覆盖企业在生产业务系统、数据开发利用、研发运维等不同场景中的数据安全需求，包括数据安全分类分级、数据库运维安全管控、BI 场景敏感数据保护、大数据场景数据保护、API 数据安全、数据流转与风险监测、一体化数据库安全审计、一体化数据动态脱敏、数据库字段透明加密等诸多场景。
