“

系列：S6 平台工程 · 第 1 篇 | 难度：高级 | 阅读时间：18 分钟

三层权限模型总览：RBAC+ABAC+ReBAC 统一设计

#TL;DR

coomia-dip 的权限系统采用三层统一模型：RBAC 管理"谁能做什么"，ABAC 管理"在什么条件下能做"，ReBAC 管理"基于什么关系能做"。三层模型通过 PolicyEngineService 统一编排，支持 8 种策略运算符，并通过查询重写实现零侵入的数据访问控制。本文从架构设计、数据模型、策略评估流程到生产实践，完整解析这一企业级权限体系。

#1. 为什么需要三层权限模型

#1.1 单一模型的局限

在传统企业应用中，RBAC（基于角色的访问控制）是最常见的权限模型。然而，随着数据平台的演进，单一 RBAC 模型面临诸多挑战：

粒度不足：RBAC 只能控制到"角色-资源"级别，无法根据数据属性（如数据分类等级、地理区域）进行细粒度控制
关系盲区：RBAC 无法表达"用户 A 是项目 X 的负责人，因此可以访问项目 X 下的所有数据"这类基于关系的授权
策略爆炸：当需要为不同部门、不同数据级别、不同时间段设置不同权限时，角色数量会指数级增长

#1.2 三层模型的互补设计

coomia-dip 选择了三层互补的权限模型，每一层解决特定的授权问题：

Code

+--------------------------------------------------+
|              PolicyEngineService                  |
|         (统一策略评估引擎, 8 种运算符)              |
+--------------------------------------------------+
         |              |              |
    +--------+    +---------+    +---------+
    |  RBAC  |    |  ABAC   |    |  ReBAC  |
    | 角色层  |    |  属性层  |    |  关系层  |
    +--------+    +---------+    +---------+
    |        |    |         |    |         |
    | 角色   |    | 主体属性 |    | 对象关系 |
    | 权限   |    | 资源属性 |    | 关系元组 |
    | 资源   |    | 环境属性 |    | 关系遍历 |
    +--------+    +---------+    +---------+

层次	回答的问题	典型场景
RBAC	谁能做什么？	管理员可以创建 Ontology
ABAC	在什么条件下能做？	仅在工作时间、从内网、对非机密数据
ReBAC	基于什么关系能做？	项目负责人可以访问项目下所有数据集

#1.3 对标 Palantir Foundry

Palantir Foundry 的权限系统同样采用多层设计，但其实现是闭源的。coomia-dip 通过开源方式实现了等价的能力：

能力	Palantir Foundry	coomia-dip
基于角色的控制	Multipass + 项目角色	RBAC 层
基于属性的控制	Marking + 分类	ABAC 层
基于关系的控制	项目成员关系	ReBAC 层 (Zanzibar 风格)
查询重写	内置但不透明	零侵入查询重写
数据脱敏	内置	6 种脱敏模式
数据分类	多层分类	7 级分类 (A1-D)

#2. PolicyEngineService 架构

#2.1 服务定位

PolicyEngineService 是 Control Layer（Control Layer）中的核心安全服务，负责统一编排三层权限模型的策略评估。它位于 Spring Boot 3.x 应用中，通过 gRPC 提供内部服务调用。

Code

+-------------------------------------------------------------+
|                      Control Layer: Control Layer                  |
|                                                              |
|  +-------------------+  +------------------+  +----------+  |
|  | PolicyEngine      |  | Classification   |  | DataMask |  |
|  | Service           |  | Service          |  | Service  |  |
|  |                   |  |                  |  |          |  |
|  | - evaluatePolicy  |  | - classify       |  | - mask   |  |
|  | - checkAccess     |  | - getLevel       |  | - unmask |  |
|  | - rewriteQuery    |  | - autoClassify   |  |          |  |
|  +-------------------+  +------------------+  +----------+  |
|           |                      |                  |        |
|  +----------------------------------------------------+     |
|  |              Policy Decision Point (PDP)            |     |
|  |  8 种运算符: eq, ne, gt, lt, in, contains,         |     |
|  |              matches, between                       |     |
|  +----------------------------------------------------+     |
+-------------------------------------------------------------+

#2.2 八种策略运算符

PolicyEngineService 支持 8 种策略运算符，覆盖了企业级权限管理的所有比较需求：

Code

+----------+--------------+-----------------------------------+
| 运算符   | 类型         | 说明                              |
+----------+--------------+-----------------------------------+
| eq       | 相等比较     | 属性值精确匹配                    |
| ne       | 不等比较     | 属性值不匹配                      |
| gt       | 大于比较     | 数值/日期大于                     |
| lt       | 小于比较     | 数值/日期小于                     |
| in       | 集合包含     | 属性值在给定集合中                |
| contains | 包含检查     | 字符串/集合包含子元素             |
| matches  | 正则匹配     | 属性值匹配正则表达式              |
| between  | 范围比较     | 属性值在区间 [min, max] 内        |
+----------+--------------+-----------------------------------+

#2.3 策略评估流程

一个完整的策略评估流程如下：

Code

请求到达
    |
    v
+-------------------+
| 1. 身份识别       |   从 JWT/mTLS 提取主体信息
|    (Subject)      |
+-------------------+
    |
    v
+-------------------+
| 2. RBAC 检查      |   查询角色-权限映射
|    (快速路径)      |   命中 -> 直接放行/拒绝
+-------------------+
    |
    v (需要细粒度控制)
+-------------------+
| 3. ABAC 评估      |   收集主体/资源/环境属性
|    (属性匹配)      |   8 种运算符评估策略表达式
+-------------------+
    |
    v (需要关系检查)
+-------------------+
| 4. ReBAC 检查     |   遍历关系图
|    (关系遍历)      |   检查主体与资源的关系路径
+-------------------+
    |
    v
+-------------------+
| 5. 策略决定       |   合并三层结果
|    (Decision)      |   DENY > ALLOW > NOT_APPLICABLE
+-------------------+
    |
    v
+-------------------+
| 6. 义务执行       |   触发脱敏、审计等附加动作
|    (Obligations)   |
+-------------------+

#2.4 策略合并语义

三层模型的结果通过以下语义合并：

Java

public enum PolicyDecision {
    ALLOW,           // 明确允许
    DENY,            // 明确拒绝
    NOT_APPLICABLE   // 不涉及
}

// 合并规则: DENY-overrides
// 任何一层返回 DENY -> 最终 DENY
// 至少一层返回 ALLOW 且无 DENY -> 最终 ALLOW
// 全部 NOT_APPLICABLE -> 最终 DENY (默认拒绝)

这是经典的 DENY-overrides 合并策略，确保安全性优先。

#3. 数据模型设计

#3.1 核心实体关系

Code

+-------------+     +---------------+     +-------------+
|   Subject   |---->|   RoleBinding  |---->|    Role     |
| (主体)       |     | (角色绑定)      |     | (角色)      |
+-------------+     +---------------+     +-------------+
                                               |
                                               v
                                          +-------------+
                                          | Permission  |
                                          | (权限)       |
                                          +-------------+
                                               |
                                               v
+-------------+     +---------------+     +-------------+
|  Resource   |<----|  PolicyRule    |---->| Condition   |
| (资源)       |     | (策略规则)      |     | (条件)      |
+-------------+     +---------------+     +-------------+
                                               |
                                               v
+-------------+                           +-------------+
| Relation    |                           |  Operator   |
| Tuple       |                           | (运算符)     |
| (关系元组)   |                           +-------------+
+-------------+

#3.2 gRPC 接口定义

PolicyEngineService 的核心 gRPC 接口：

PROTOBUF

syntax = "proto3";

package com.onto.control.policy;

service PolicyEngineService {
    // 评估访问策略
    rpc EvaluatePolicy(PolicyEvaluationRequest)
        returns (PolicyEvaluationResponse);

    // 批量检查访问权限
    rpc BatchCheckAccess(BatchAccessCheckRequest)
        returns (BatchAccessCheckResponse);

    // 查询重写（零侵入数据过滤）
    rpc RewriteQuery(QueryRewriteRequest)
        returns (QueryRewriteResponse);

    // 获取主体的有效权限
    rpc GetEffectivePermissions(EffectivePermissionsRequest)
        returns (EffectivePermissionsResponse);
}

message PolicyEvaluationRequest {
    Subject subject = 1;           // 主体信息
    string action = 2;             // 操作类型
    Resource resource = 3;         // 资源信息
    EnvironmentContext env = 4;    // 环境上下文
}

message PolicyEvaluationResponse {
    Decision decision = 1;         // ALLOW / DENY
    repeated Obligation obligations = 2;  // 附加义务
    string reason = 3;             // 决策原因
    int64 evaluation_time_ms = 4;  // 评估耗时
}

message Subject {
    string id = 1;
    string type = 2;               // USER, SERVICE, GROUP
    map<string, string> attributes = 3;
    repeated string roles = 4;
}

message Resource {
    string id = 1;
    string type = 2;               // ONTOLOGY, DATASET, OBJECT, FIELD
    map<string, string> attributes = 3;
    string classification = 4;     // 数据分类级别
}

#4. 三层模型的协同工作

#4.1 场景一：数据分析师查看客户数据

考虑以下场景：一个数据分析师需要查看客户数据集中的电话号码字段。

Code

主体: analyst_001 (角色: DATA_ANALYST)
操作: READ
资源: customer_dataset.phone_number (分类: B2-内部敏感)

评估过程:
---------------------------------------------------------
[RBAC] DATA_ANALYST 角色有 READ 权限?     -> ALLOW
[ABAC] 当前是否工作时间?                    -> ALLOW (09:00-18:00)
[ABAC] 数据分类 B2 <= 用户安全级别 B3?      -> ALLOW
[ABAC] 请求来源是否内网?                    -> ALLOW (10.0.x.x)
[ReBAC] 用户是否为该数据集所属项目的成员?     -> ALLOW

最终决策: ALLOW
义务: 对 phone_number 字段执行 PARTIAL_MASK 脱敏
---------------------------------------------------------

#4.2 场景二：外部合作方查看销售报告

Code

主体: partner_vendor_01 (角色: EXTERNAL_PARTNER)
操作: READ
资源: sales_report_2024 (分类: B1-内部一般)

评估过程:
---------------------------------------------------------
[RBAC] EXTERNAL_PARTNER 角色有 READ 权限?  -> ALLOW (受限)
[ABAC] 当前是否在合同有效期内?              -> ALLOW
[ABAC] 数据分类 B1 <= 外部可见级别 A2?      -> DENY !!!
[ReBAC] 外部合作方与报告有协作关系?          -> ALLOW

最终决策: DENY (ABAC 层拒绝, DENY-overrides)
原因: 数据分类级别超出外部合作方的安全级别
---------------------------------------------------------

#4.3 场景三：项目经理跨项目访问

Code

主体: pm_zhang (角色: PROJECT_MANAGER)
操作: READ
资源: project_alpha/model_config (分类: C1-机密)

评估过程:
---------------------------------------------------------
[RBAC] PROJECT_MANAGER 角色有 READ 权限?   -> ALLOW
[ABAC] C1 机密数据需要特殊审批?             -> NOT_APPLICABLE
[ReBAC] pm_zhang 是 project_alpha 的成员?   -> 检查关系图...
        pm_zhang -> member_of -> project_beta  (是 beta 成员)
        pm_zhang -> member_of -> project_alpha (不是 alpha 成员)
        => DENY

最终决策: DENY (ReBAC 层拒绝)
原因: 主体不是目标项目的成员
---------------------------------------------------------

#5. 性能优化设计

#5.1 多级缓存架构

权限评估是高频操作，coomia-dip 采用多级缓存优化：

Code

+-------------------+     +-------------------+     +-------------------+
|    L1: 本地缓存    |     |    L2: Redis      |     |    L3: 数据库     |
|    (Caffeine)      |     |    (集群)          |     |    (PostgreSQL)   |
|                   |     |                   |     |                   |
|  TTL: 30s         |     |  TTL: 5min        |     |  持久化存储       |
|  容量: 10K 条目    |     |  容量: 100K 条目   |     |                   |
|  命中率: ~85%      |     |  命中率: ~12%      |     |  命中率: ~3%      |
+-------------------+     +-------------------+     +-------------------+
         |                        |                         |
         +------------------------+-------------------------+
                              |
                     缓存失效策略:
                     - 角色变更 -> 清除相关主体缓存
                     - 策略变更 -> 清除所有策略缓存
                     - 关系变更 -> 清除关系路径缓存

#5.2 RBAC 快速路径

对于纯 RBAC 的场景（无需 ABAC/ReBAC），PolicyEngineService 提供快速路径优化：

Java

public PolicyDecision evaluateFastPath(Subject subject, String action,
                                        Resource resource) {
    // 快速路径：直接查 RBAC 缓存
    Set<Permission> permissions = rbacCache.getPermissions(subject.getRoles());
    for (Permission perm : permissions) {
        if (perm.matches(action, resource.getType())) {
            // 检查是否需要进入 ABAC/ReBAC
            if (!perm.hasConditions() && !perm.requiresRelationCheck()) {
                return PolicyDecision.ALLOW;  // 快速放行
            }
        }
    }
    // 回退到完整评估
    return evaluateFullPath(subject, action, resource);
}

快速路径可以在 < 1ms 内完成评估，覆盖约 70% 的请求。

#5.3 性能基准

场景	平均延迟	P99 延迟	吞吐量
RBAC 快速路径	0.3ms	1.2ms	50K QPS
RBAC + ABAC	2.1ms	8.5ms	15K QPS
RBAC + ABAC + ReBAC	5.8ms	22ms	5K QPS
查询重写	3.2ms	15ms	10K QPS
批量检查 (100 资源)	12ms	45ms	2K QPS

#6. 与其他服务的集成

#6.1 集成架构

Code

+-------------------+     +-------------------+
| API Gateway       |---->| PolicyEngine      |
| (59 REST 端点)     |     | Service           |
+-------------------+     +---+-----+-----+---+
                            |     |     |
              +-------------+     |     +-------------+
              |                   |                   |
              v                   v                   v
+-------------------+  +-------------------+  +-------------------+
| Classification    |  | AuditService      |  | DataMask          |
| Service           |  | (13 事件类型)      |  | Service           |
| (7 级分类)         |  | (3 Kafka topics)  |  | (6 种脱敏模式)     |
+-------------------+  +-------------------+  +-------------------+

#6.2 审计集成

每次策略评估都会产生审计事件：

Java

AuditEvent policyAudit = AuditEvent.builder()
    .eventType(AuditEventType.POLICY_EVALUATION)
    .subject(request.getSubject().getId())
    .action(request.getAction())
    .resource(request.getResource().getId())
    .decision(response.getDecision().name())
    .reason(response.getReason())
    .evaluationTimeMs(response.getEvaluationTimeMs())
    .timestamp(Instant.now())
    .build();

auditService.publishAsync(policyAudit);  // 异步发布到 Kafka

#6.3 SDK 集成

Python SDK 通过 OntoPlatform facade 提供简洁的权限检查接口：

Python

from ontology_sdk import OntoPlatform

platform = OntoPlatform(endpoint="grpc://control-Layer:9090")

# 检查访问权限
result = await platform.policy.check_access(
    subject_id="analyst_001",
    action="READ",
    resource_id="customer_dataset",
    resource_type="DATASET"
)

if result.allowed:
    data = await platform.ontology.query("Customer", limit=100)
    # 数据已自动脱敏（根据策略义务）
else:
    print(f"Access denied: {result.reason}")

#7. 策略管理与治理

#7.1 策略生命周期

Code

+--------+     +---------+     +--------+     +--------+
| 草稿   |---->| 审批中   |---->| 活跃   |---->| 归档   |
| DRAFT  |     | PENDING |     | ACTIVE |     | ARCHIVED|
+--------+     +---------+     +--------+     +--------+
    ^                              |
    |                              v
    +------- 需要修改 <------ +---------+
                              | 废弃    |
                              | DEPRECATED|
                              +---------+

#7.2 策略版本控制

所有策略变更都经过版本控制，支持回滚：

YAML

policy:
  id: "POL-DATASET-READ-001"
  version: 3
  name: "数据集读取策略"
  description: "控制数据集的读取权限"
  status: ACTIVE
  effective_from: "2026-01-01T00:00:00Z"
  rules:
    - effect: ALLOW
      subjects:
        roles: [DATA_ANALYST, DATA_ENGINEER]
      actions: [READ, EXPORT]
      resources:
        types: [DATASET]
      conditions:
        - attribute: "resource.classification"
          operator: "lt"
          value: "C1"
        - attribute: "environment.time"
          operator: "between"
          value: ["09:00", "18:00"]
      obligations:
        - type: MASK
          params:
            fields: ["phone", "email", "id_card"]
            mode: PARTIAL_MASK

#7.3 策略冲突检测

当新策略可能与现有策略冲突时，系统会自动检测并报警：

Code

新策略: "允许 DATA_ANALYST 读取所有 DATASET"
现有策略: "拒绝任何人读取 classification >= C1 的 DATASET"

冲突检测结果:
  类型: POTENTIAL_CONFLICT
  影响范围: classification >= C1 的数据集
  建议: 新策略应添加 classification < C1 的条件
  当前行为: DENY-overrides 保证安全 (现有策略优先)

#8. 生产部署建议

#8.1 高可用部署

Code

                     +-------------------+
                     |   Load Balancer   |
                     +-------------------+
                        |      |      |
              +---------+      |      +---------+
              |                |                |
    +---------v-----+ +-------v-------+ +------v--------+
    | PolicyEngine  | | PolicyEngine  | | PolicyEngine  |
    | Instance 1    | | Instance 2    | | Instance 3    |
    +---------------+ +---------------+ +---------------+
              |                |                |
              +-------+--------+--------+-------+
                      |                 |
              +-------v-------+ +------v--------+
              |   Redis       | |  PostgreSQL   |
              |   Cluster     | |  (Primary +   |
              |   (3 nodes)   | |   2 Replicas) |
              +---------------+ +---------------+

#8.2 监控指标

指标	阈值	告警级别
策略评估延迟 P99	> 50ms	WARNING
策略评估延迟 P99	> 200ms	CRITICAL
缓存命中率	< 70%	WARNING
策略评估 DENY 比率	> 30%	INFO
策略变更频率	> 10/min	WARNING

#8.3 容量规划

Code

估算公式:
  QPS = 活跃用户数 x 平均操作频率 x 策略评估次数/操作

示例:
  1000 活跃用户 x 10 操作/分钟 x 2 评估/操作 = 333 QPS

推荐配置:
  < 500 QPS:  2 实例, 2 CPU, 4GB RAM
  < 2000 QPS: 3 实例, 4 CPU, 8GB RAM
  < 10000 QPS: 5 实例, 8 CPU, 16GB RAM

#9. 与主流方案的对比

特性	coomia-dip	Open Policy Agent	Casbin	Keycloak
RBAC	原生支持	需策略编写	原生支持	原生支持
ABAC	原生支持	原生支持	有限支持	有限支持
ReBAC	原生支持	需定制	不支持	不支持
查询重写	原生支持	不支持	不支持	不支持
数据脱敏	6 种模式	不支持	不支持	不支持
数据分类	7 级分类	不支持	不支持	不支持
gRPC 集成	原生	需适配器	嵌入式	REST
审计追踪	13 事件类型	决策日志	无	有限

#10. 未来演进方向

#10.1 近期规划

策略即代码 (Policy as Code)：支持 Git 管理策略版本，CI/CD 自动部署
策略仿真 (Policy Simulation)：在不影响生产的情况下测试策略变更的影响
跨平台联邦权限：支持多个 coomia-dip 实例之间的权限联邦

#10.2 长期愿景

AI 驱动的策略推荐：基于访问模式自动推荐权限策略
零信任网络集成：与 Service Mesh (Istio) 的深度集成
合规自动化：自动生成等保三级 / GDPR 合规报告

#Key Takeaways

三层互补：RBAC 负责粗粒度角色控制，ABAC 负责属性条件细化，ReBAC 负责关系图谱授权，三者协同覆盖所有企业级授权场景
DENY-overrides：安全性优先的策略合并语义，任何一层的拒绝都是最终的
快速路径优化：70% 的请求走 RBAC 快速路径，延迟 < 1ms
零侵入查询重写：业务代码无需感知权限逻辑，查询自动根据策略重写
完整审计：每次策略评估都产生审计事件，确保合规可追溯
与 Palantir 对标：开源实现等价于 Foundry 的 Multipass + Marking + 项目成员关系的全部能力

#Next Article

下一篇 S6-02: RBAC 实现：角色、权限、资源的建模与授权将深入讲解 RBAC 层的完整实现，包括角色继承、权限模型、资源层级，以及与 Spring Security 的集成方式。

Tags: #权限模型 #RBAC #ABAC #ReBAC #PolicyEngine #访问控制 #coomia-dip #平台工程 #安全架构 #Palantir