权限与账号系统 — 一次 check 背后的图遍历、隔离与不可抵赖Authorization & Account Systems: RBAC vs ABAC vs ReBAC, Multi-tenancy, Audit Log

问题场景 + 需求约束

设计一个 B2B SaaS 平台的授权系统（类似 Notion / GitHub / Figma）：组织结构是 Org → Team → Project → Resource 四层，权限层层继承——Org admin 能动一切，Project member 只能碰自己项目。表面只是「这个用户能不能读这个文档」，但它是每个 API 请求都要过的最热路径，错一次就是越权泄露，慢一点就拖垮整站。

把它当真实系统来定规模：

• 租户量：10 万 Org，单 Org 最大 5 万用户、百万级 resource。
• QPS：单次页面渲染要做 几十到上百次 check（列表页每行一次），全站峰值 授权检查 50 万 QPS+——比业务 QPS 高一个量级。
• 延迟 SLO：check p99 < 10ms（Zanzibar/Himeji 的真实指标就在这个量级），否则它会主导整个请求延迟。
• 正确性：拒绝默认（default deny）；权限撤销后必须快速生效（不能因为缓存让被踢出的人还能读）。
• 隔离：租户数据物理/逻辑隔离，单租户绝不可读到另一租户数据。
• 可审计：谁在何时改了谁的权限、访问了什么，要可追溯、不可篡改（合规：SOC2 / GDPR）。

本期讲四件事：用什么模型表达权限、层级继承怎么算得快、租户怎么隔离、审计日志怎么做到不可抵赖。

高层架构

graph TD
    APP["业务服务
API / 前端 BFF"]
    PDP["授权决策点 PDP
Check(user, perm, obj)?"]
    CACHE["权限缓存
分片+复制 · 内存过滤"]
    STORE["关系存储
relation tuples · Postgres/Spanner"]
    CDC["CDC / 失效流
binlog → Kafka"]
    AUDIT["审计日志
append-only · 哈希链"]
    APP -->|"1. check"| PDP
    PDP -->|"2. 命中"| CACHE
    CACHE -->|"3. miss 回源"| STORE
    STORE -->|"4. 变更"| CDC
    CDC -->|"5. 失效缓存"| CACHE
    APP -->|"6. 权限变更/敏感访问"| AUDIT

PDP（Policy Decision Point）是核心：业务代码不自己判断权限，而是统一问 PDP「这个 subject 对这个 object 有没有这个权限」。PDP 把判定逻辑（policy）和判定数据（谁属于哪个组、谁是谁的 owner）集中起来——授权逻辑下沉到数据层而非散落在每个微服务里，这是 Airbnb Himeji 和 Google Zanzibar 共同的中心化思路。缓存层分片+复制、内存中做关系过滤，miss 才回源；写路径用 CDC 把变更转成缓存失效事件。审计日志是旁路，独立链路，不在 check 热路径上。

关键技术点

① 授权模型：RBAC vs ABAC vs ReBAC — 用「角色」「属性」还是「关系」表达权限

一句话 trade-off：RBAC 简单但角色会爆炸；ABAC 灵活但难审计、难回答「谁能访问 X」；ReBAC（Zanzibar 式）天然表达层级与共享，但要自己建图遍历引擎。

【原理】 三种模型回答的是同一个问题、用不同的数据结构：

• RBAC：用户 → 角色 → 权限。「Alice 是 admin，admin 能 delete」。判定是查表。
• ABAC：基于属性的布尔表达式。「if user.dept == resource.dept && time < 18:00 then allow」。判定是求值一段策略（如 OPA/Rego、AWS IAM policy）。
• ReBAC：把权限建模成对象之间的关系元组 (object#relation@subject)，判定是在关系图上做可达性遍历。「doc:readme#viewer@user:alice」「doc:readme#viewer@group:eng#member」——viewer 可以是一个用户，也可以是「eng 组的所有成员」，于是层级与共享自然展开。这是 Google Zanzibar 的核心抽象。

【代码/伪代码】 ReBAC 的 check 本质是带"用户集重写"的递归图遍历：

# pseudo-code — Zanzibar 式 check：obj 上的 relation 是否包含 subject？
def check(obj, relation, subject) -> bool:
    for tuple in tuples(obj, relation):          # 读 (obj#relation@?)
        u = tuple.subject
        if u == subject:
            return True                          # 直接命中
        if u.is_userset():                       # 形如 group:eng#member
            if check(u.obj, u.relation, subject):# 递归展开 userset
                return True
    # userset rewrite：viewer 继承自 editor、owner，或父对象的 viewer
    for rule in rewrite_rules(obj.type, relation):   # 如 viewer = editor + parent.viewer
        if check_rewrite(obj, rule, subject):
            return True
    return False

关键在 rewrite_rules：viewer = self | editor | parent→viewer 让权限沿层级向下继承——无需为每个 resource 复制权限。

② 层级继承与 check 性能 — 深图遍历 vs 物化反向索引

一句话 trade-off：实时递归遍历写便宜读贵（深层级延迟尾巴长），物化展开读快但写放大、有失效一致性问题。

【原理】 Org→Team→Project→Doc 四层下，"Alice 能读这个 doc 吗"可能要从 doc 往上爬到 Org 再展开整个 group 树——一次 check 触发几十次元组读，深度和扇出决定尾延迟。两条优化路线：

• 实时遍历 + 缓存子结果：每个中间判定 check(group:eng, member, alice) 缓存复用；用 single-flight 合并并发回源。简单、写便宜，但冷缓存或深图时 p99 抖动。
• 物化反向索引：预先把"对象 → 所有有权访问的用户"或"用户 → 所有可访问对象"展开存好，check 退化成一次查表。Zanzibar 的 Leopard 索引就是为深/广的 group 嵌套预计算 flatten 后的成员集合。代价是写放大（一次组变更要更新海量物化行）和失效复杂度。

一致性陷阱：权限撤销必须及时生效，否则"刚被移出项目的人还能读 5 分钟"就是安全事故。Zanzibar 用 Zookie（一个携带时间戳的 token）保证"读权限时不早于某次写"，把外部一致性和缓存新鲜度绑定——这是它区别于普通缓存系统的关键。

# pseudo-code — 撤销快速生效：版本号 + CDC 失效，而非纯 TTL
def revoke(group, member):
    db.delete(tuple(group, "member", member))      # 1. 落库
    bump_version(group)                            # 2. 该对象权限版本 +1
    cdc.publish(InvalidateEvent(group))           # 3. binlog→Kafka→各缓存节点删 key
# 读侧：缓存条目带 version；check 时校验 version 未过期，否则回源

③ 多租户隔离 — 共享库行级 vs Schema 隔离 vs 独立库

一句话 trade-off：共享库省成本但"漏一个 WHERE 就跨租户泄露"；独立库最强隔离但运维/迁移成本随租户数线性爆炸。

【原理】 三档隔离强度对应三档成本：

主流 SaaS 默认共享库 + 行级（成本碾压），用 Postgres Row-Level Security (RLS) 把"漏 WHERE"从人为约束变成数据库强制约束：策略一旦建好，连接里设了 app.tenant_id，DB 自动给每条查询追加租户过滤——应用代码忘写也不会泄露。大客户（合规要求物理隔离）再单独切独立库，做混合分层。

-- Postgres RLS：把租户隔离下沉到数据库层
ALTER TABLE documents ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON documents
  USING (tenant_id = current_setting('app.tenant_id')::uuid);
-- 每个连接进入租户上下文时：
SET app.tenant_id = '...';   -- 之后所有 query 自动被过滤，应用层无需手写 WHERE

④ 审计日志 — append-only 与不可抵赖（tamper-evidence）

一句话 trade-off：审计要写在业务事务里才不丢，但又不能拖慢/污染业务库；要可信就得防篡改，但完全不可改与"可运维"是矛盾。

【原理】 审计日志和普通业务日志的根本区别：它是证据，要满足三点——完整（不丢事件）、不可篡改（事后改不了）、可追溯（who/what/when/from where）。

• 不丢：权限变更这类关键事件用 Outbox 模式（见 Day 7）——把审计记录和业务变更写在同一个事务里，再由 CDC 投递到审计存储，避免"业务成功但审计丢了"。
• 不可篡改：append-only + 哈希链——每条记录存 hash(prev_hash + payload)，任何人改中间一条，后面所有 hash 对不上，篡改即暴露。再周期性把链头 hash 锚定到外部（如 WORM 存储 / 公证），连"删整段"都防住。
• 不拖业务：审计走独立存储（追加优化的列存/对象存储），与 OLTP 库分离；查询是低频分析，不挤占业务热路径。

# pseudo-code — 哈希链审计，篡改可检测
def append_audit(event):
    prev = store.last()                  # 取上一条
    record = {
        "actor": event.actor, "action": event.action,
        "target": event.target, "ts": now(),
        "prev_hash": prev.hash,
    }
    record["hash"] = sha256(prev.hash + canonical_json(record))
    store.append(record)                 # append-only，永不 UPDATE/DELETE

def verify():                            # 巡检：重算每条 hash，断链即报警
    for r in store.scan():
        assert r["hash"] == sha256(r["prev_hash"] + canonical_json(strip_hash(r)))

扩展与优化

• 从内嵌到中心化 PDP：早期权限散在各服务 if user.role==...，规模大后抽出中心化授权服务（Zanzibar/Himeji/OpenFGA），统一模型、统一审计、统一缓存。
• 读写分离 + 反向索引：列表页"我能看哪些项目"用物化的 user→objects 反向索引，避免对每个对象逐个 check（N+1 授权）。
• 策略即代码：ABAC 用 OPA/Rego 把策略版本化、可测试、可灰度，避免线上手改规则。
• 缓存预热与降级：授权是最热路径，冷启动用历史热点预热；PDP 不可用时fail-closed（默认拒绝）而非 fail-open——可用性让位于安全。

常见陷阱 + 面试追问

• Fail-open vs fail-closed：授权服务挂了怎么办？答 fail-closed（拒绝）几乎总是对的——宁可拒绝合法请求，不可放行越权。但要权衡：核心读路径全拒会导致全站不可用，可对低敏感操作做有限降级。
• N+1 授权：列表 100 行做 100 次 check，p99 被放大。要批量 check（BatchCheck）或反向索引一次拿全集。面试常问"列表页权限过滤怎么做"。
• 撤销延迟：纯 TTL 缓存会让撤销延迟到 TTL 到期。必须 CDC/版本号主动失效——"踢人后多久生效"是经典追问。
• RLS 连接池泄露上下文：连接复用没 RESET tenant_id → 跨租户读。也别忘了 BYPASSRLS 角色和迁移脚本绕过策略。
• 用业务库当审计源：业务表能 UPDATE，就不是可信审计。审计必须 append-only + 防篡改 + 独立存储。
• 把权限写进 JWT 然后无法撤销：JWT 内嵌大量权限 claim 后，权限一变旧 token 还有效（见 Day 24）。授权决策应实时查 PDP，JWT 只携带身份。

深入资源

• Zanzibar: Google's Consistent, Global Authorization System — USENIX ATC 2019，ReBAC 的奠基论文（关系元组、userset rewrite、Zookie、Leopard 索引）。
• Himeji: a scalable centralized system for authorization at Airbnb — 工业界 Zanzibar 落地（缓存分片、CDC 失效、Aurora 存储）。
• OpenFGA · Authorization Concepts — RBAC / ABAC / ReBAC / Zanzibar 概念对比与可上手实现（Auth0/Okta，CNCF）。
• The data model behind Notion's flexibility — block 树 + parent 指针的权限继承设计。
• PostgreSQL · Row Security Policies — 多租户行级隔离的数据库原生实现。
• 《Designing Data-Intensive Applications》(Kleppmann) — 一致性与因果序章节，理解 Zookie 背后的外部一致性。

深入思考