访问控制基础：RBAC、ABAC、ACL 模型解析

日志集中了，权限却乱了。这是我在好几个多租户项目里遇到的通病——租户A的审计人员能看到租户B的敏感日志，只因为权限模型选错了。今天我把三种常用访问控制模型掰开揉碎讲清楚，尤其是它们在多租户日志场景下的适用性。

从 ACL 说起：最简单也最头疼

ACL（访问控制列表），说白了就是一张大表，记录“谁可以做什么”。每个资源都挂一个列表，里面写着用户和对应的权限。

举个日志例子：

日志文件: /var/log/tenantA/app.log
ACL:
  用户 Alice: read
  用户 Bob: read, write
  组 admins: read, delete

优点是直观，实现简单。但我以前用过 ACL 管理几百个租户、上万条日志文件，简直是灾难——每个新租户都要手动添加条目，而且权限粒度太粗。你想让 Alice 只能看今天之前的日志，ACL 根本做不到。

RBAC：角色出场，管理效率飞升

RBAC（基于角色的访问控制）是当前最主流的模型。核心思想：不直接给用户授权，而是先定义角色，再把角色赋给用户。

典型结构：

• 用户：某个运维工程师
• 角色：日志查看员、日志管理员、审计员
• 权限：查看日志、导出日志、删除日志

用户 → 角色 → 权限，三层映射。多租户场景下，我们还可以在角色上加“范围”限制，比如“日志查看员(租户A)”和“日志查看员(租户B)”本质不同。

我在之前的一个 SaaS 日志审计产品里，直接内置了 RBAC。客户只需要建部门、建角色，然后把人拖进去，权限就自动生效了。但 RBAC 有个硬伤：当权限维度特别多时，角色数量会爆炸。比如既要按日志类型分、又要按时间段分、还要按操作类型分，角色组合可能成百上千。

ABAC：灵活的终极方案，但别滥用

ABAC（基于属性的访问控制）不依赖固定角色，而是用属性来做动态判断。属性分三类：

属性类别	举例
主体属性	用户所属租户、部门、安全等级
客体属性	日志级别、日志来源IP、数据敏感级别
环境属性	访问时间、网络位置、设备状态

策略引擎根据属性组合来计算权限。写成代码大概像这样：

策略:
  IF 用户.tenant == 日志.tenant
  AND 日志.level IN ('info','warn')
  AND 当前时间 BETWEEN '09:00' AND '18:00'
  THEN 允许 read

你看，一周内日志的变化就能通过一条策略覆盖，不用建新角色。我处理过一个跨国企业案例：他们的合规要求是“欧洲租户的日志只能由欧洲IP的审计员在办公时间查看”。用 ABAC 写三条属性就搞定了，如果用 RBAC 得建多少个角色？数都数不过来。

三种模型怎么选？一张表看清

维度	ACL	RBAC	ABAC
管理复杂度	低（小规模）	中（角色定义好后）	高（策略设计和维护）
权限粒度	粗	中（受限于角色）	细（属性级）
动态适应能力	差	一般（需新角色）	强（改策略即可）
多租户支持	弱（需大量条目）	中（角色+租户范围）	强（直接用租户属性）
性能	高（直接查表）	中（角色继承影响）	低（每次计算）
最佳实践场景	极低规模、静态权限	业务角色清晰、变更不频繁	属性多变、高安全合规要求

我的选择原则：不要迷恋单一模型

实际项目中，我几乎不会只用一种模型。我的做法是：

1. 用 RBAC 兜底：覆盖 80% 的常规权限，比如“日志管理员”可以管理自家租户的日志。
2. 用 ABAC 打补丁：处理那 20% 的特殊规则，比如“仅限工作日”、“仅限内网IP”。
3. ACL 仅用于直接操作：比如超级管理员手动分享一个临时链接，这种场景 ACL 反而比 RBAC 快。

你想想看，多租户日志访问控制不是单选题，而是组合拳。我参与过的一个金融级日志平台，核心策略引擎就是 RBAC + ABAC 混合架构——先用 RBAC 过滤掉 99% 的非法请求，只有命中的那 1% 才走 ABAC 精细计算。性能压力一下子就缓解了。

最后留个问题：如果哪天你收到需求“某审计员只能查看租户A昨天之前、级别为warn的日志，且只能看正文的前1000字符”，你会用哪种模型组合？思考一下，答案会在后面的章节里一一展开。