访问控制策略基础：ACL、RBAC、ABAC 等概念

说到访问控制，我做了不少项目，从几十人的小系统到上万用户的平台都接触过。说白了，就是决定“谁”能对“什么资源”做“什么操作”。很多新手觉得这很简单，但一旦规模上来，策略乱成一团，你就知道厉害了。嗯，咱们今天就把 ACL、RBAC、ABAC 这三个主流模型彻底捋清楚。

1.1 访问控制的三要素

不管用哪种模型，核心都离不开三个东西：

• 主体（Subject）：谁发起的请求？用户、程序、服务账号都算。
• 客体（Object）：要访问的资源是什么？文件、数据库、API 端点。
• 操作（Operation）：你想干嘛？读、写、执行、删除。

你想想看，任何访问控制策略最终都是把这三者组合起来，然后决定“允许”还是“拒绝”。

1.2 ACL – 访问控制列表

ACL 是最直接的方式。每个资源挂一个列表，里面写着哪些主体能做什么操作。我见过一个老系统的 ACL 条目超过了一万条，维护起来简直噩梦。

举个例子，Linux 文件权限就是典型的 ACL：

# 文件 test.txt 的 ACL
user:rw-   # 所有者有读写权限
group:r--  # 所属组有读权限
other:---  # 其他人无权限

优点很明显：直观、细粒度。缺点也是致命的：当用户数或资源数膨胀，ACL 条目呈指数增长。我曾经在一个项目里接手过 ACL 表，光查一个用户的所有权限就得 JOIN 十几张表，性能一塌糊涂。

1.3 RBAC – 基于角色的访问控制

RBAC 的思想是：不要直接给用户赋权，而是定义角色，再把角色分配给用户。用户拥有角色，角色拥有权限。这样权限管理就从“多对多”变成了“用户到角色、角色到权限”两个一对多，清晰得多。

要素	说明
用户	系统使用者
角色	权限的集合，如“管理员”、“审计员”
权限	对资源可执行的操作
会话	用户激活角色的临时上下文

我习惯用 RBAC 来管理企业内部系统。比如把“查看工资”的权限赋给“HR角色”，然后所有 HR 员工自动拥有。新员工入职只需分配角色，不用一条条配权限。

看一下 RBAC 的权限配置样例（JSON 格式）：

{
  "roles": {
    "admin": { "permissions": ["user:*", "report:*"] },
    "editor": { "permissions": ["article:create", "article:edit"] }
  },
  "users": {
    "张三": { "roles": ["admin"] },
    "李四": { "roles": ["editor"] }
  }
}

1.4 ABAC – 基于属性的访问控制

ABAC 更灵活，它不依赖固定的角色或列表，而是根据属性动态计算是否放行。属性可以来自主体（部门、职级）、资源（机密级别）、环境（时间、地点）。

我记得有一次给金融系统做权限设计，需求是“风控人员只能在工作时间访问客户数据，而且数据级别不能超过‘高’”。这种用 RBAC 很难表达，但 ABAC 一条策略就搞定了。

属性类别通常有：

• 主体属性：部门、安全等级、地理位置
• 资源属性：分类、所属项目、创建时间
• 环境属性：当前时间、IP 段、网络类型

一个简化的 ABAC 策略示例（类 XACML 语法）：

Rule "风控时段限制"
  Target
    subject.department == "风控"
    resource.classification <= "high"
  Condition
    currentTime >= "09:00" AND currentTime <= "18:00"
  Effect: Permit

ABAC 的优点是表达能力极强，适合动态、多变的场景。但缺点也很明显：策略引擎复杂，每次请求都要计算大量属性，性能开销比 ACL 和 RBAC 大。而且策略的编写和调试难度高，没点功底容易写出逻辑漏洞。

1.5 三种模型对比

维度	ACL	RBAC	ABAC
管理粒度	细（资源级）	中等（角色级）	极细（属性级）
维护成本	高（条目膨胀）	较低（角色复用）	高（策略复杂度）
灵活性	低	中	高
适用场景	文件系统、网络设备	企业应用、SaaS	金融、医疗、动态合规

我个人建议：新手先从 RBAC 入手，理解权限的“角色化”思维；等遇到灵活性瓶颈时，再去研究 ABAC。不要一开始就想搞“大而全”，容易陷入过度设计。