岗位权限（RBAC）简单直观，但遇到复杂条件就力不从心。ABAC 用“属性”来描述谁、什么资源、什么环境，让权限判断更灵活。
“财务部的人可以看财务报表。”——这是最常见的权限规则。但现实往往更复杂：“财务部的人，在公司办公网内、使用受管电脑、工作时间，才可以导出报表。”这类规则，岗位权限就很难表达了。ABAC 正是为此而生。
先说常见的 RBAC
RBAC（基于角色的访问控制）：给用户分配角色，角色对应权限。
- 优点：直观、好管理，适合岗位清晰的场景；
- 局限：条件一多，就要不停地新增角色。比如“财务 + 外出 + 手机”也要一个角色，角色会越来越多，最终难以维护（常被称为“角色爆炸”）。
ABAC 是什么
ABAC（基于属性的访问控制），不只看“你是什么角色”，而是综合多种属性判断：
- 用户属性： 部门、岗位、职级、是否外包；
- 资源属性： 数据敏感级别、所属业务、所属部门；
- 环境属性： 时间、地点、网络环境、设备状态；
- 操作属性： 查看、下载、导出、修改。
策略用类似这样的语言表达：“当用户属于财务部，且资源是财务报表，且设备受管、网络可信时，允许查看；导出需要额外验证。”
RBAC 与 ABAC，怎么搭配
| 对比 | RBAC | ABAC |
|---|---|---|
| 判断依据 | 角色 | 多种属性的组合 |
| 灵活性 | 较低，条件多则角色激增 | 较高，可表达复杂条件 |
| 复杂度 | 简单直观 | 策略设计与维护要求更高 |
| 适合场景 | 岗位清晰、规则稳定 | 条件复杂、需要动态判断 |
实践中常见的做法是：以角色（RBAC）打底，在关键场景用属性（ABAC）加条件，兼顾易管理与灵活性。
落地时的几个提醒
- 属性要可靠： 属性数据不准确，判断就会失真，先把基础数据理顺；
- 策略从关键场景开始： 不必一开始就全面铺开；
- 规则要可解释、可测试： 避免策略互相冲突，让用户和管理员都能看懂；
- 记录判断过程： 便于事后核对为什么放行或拒绝。
这些属性从哪里来，也是个实际问题。在统一身份认证准入平台里，身份管理（账号管理、权限管理、组织架构）提供用户与组织属性，安全准入（终端识别、环境检测、访问控制、策略管理）提供设备与环境属性，再由统一策略引擎集中管理规则，访问日志与操作审计记录判断结果，思路上与“按多种属性动态判断”是一致的。
小结
- RBAC 看角色，简单直观；ABAC 看多种属性，更灵活。
- 常见做法：RBAC 打底，关键场景用 ABAC 加条件。
- 落地要保证属性可靠、从关键场景起步、策略可解释。