权限模型#

Google Zanzibar 解决的核心问题是超大规模 + 宽松一致性的组合需求：

1. 全球一致性要求：YouTube、Google Drive 等产品的权限系统需要服务全球数十亿用户，权限数据需要在全球多个数据中心保持同步。Zanzibar 采用 Paxos 复制的 Slotted Leaf Node 结构，保证最终一致性。
2. 超低延迟要求：权限检查是热路径，Zanzibar 优化了 ZooKeeper 不擅长的「前缀匹配」场景，通过 Chandy-Misra-Gals 分布式复制实现毫秒级响应。
3. 复杂关系建模：Google 内部有大量「文件夹-文档-分享」的层级和关系型权限，Zanzibar 的 Namespace-Tuple-Object-Subject 四元组模型天然支持这种场景。
4. 一致性隔离：不同租户可以配置不同的 ZooKeeper 服务器，实现隔离。

开源方案（如 OPA）更适合中等规模场景，Google 的规模需求超出了通用开源方案的边界。

这是一个经典的权限设计问题。

审计员的权限设计：

1. 只读权限：审计员不应拥有任何写权限（创建/修改/删除）。
2. 分离审计数据：审计日志本身需要受保护，普通管理员不能删除或篡改日志。可使用独立存储，审计员有读取权限。
3. 最小知情原则：审计员通常只需要看到「谁在什么时间访问了什么资源」，不需要看到资源内容。

审计内容：

常见陷阱：

• 审计员角色混入写权限 → 审计记录可被篡改
• 审计日志存储在业务库 → 管理员可删除
• 审计员能看到数据内容 → 违反最小知情原则

答案是 绝对不能，这是多租户安全的核心要求。

多层隔离设计方案：

1. 租户标识作为强制属性：在 ABAC 策略中，tenant_id 应作为强制检查字段，任何权限决策必须包含租户隔离校验。
2. 数据隔离：
   • 方案 A：每个租户独立数据库（最强隔离，但成本高）
   • 方案 B：数据库行级隔离（通过 tenant_id 字段过滤）
   • 方案 C：Schema 隔离（PostgreSQL Schema）
3. 权限预检查：在 OPA/Casbin 策略中，第一条规则永远是 tenant_id 匹配：

package authz

default allow = false

allow {
    input.tenant_id == data.tenant_id
    input.user_id == data.user_id
    input.action == data.action
}

常见错误：

• 只在前端做租户隔离，后端 API 无验证（攻击者可绕过）
• 缓存 key 未包含 tenant_id（不同租户数据串读）
• 内部服务调用未传递 tenant_id（内部滥用）