Palantir 的权限模型：为什么政府敢把机密数据交给它
对大多数企业来说，数据安全是一个合规问题——罚款、声誉损失、客户流失。
Coomia发布于 2025年6月13日28 分钟阅读
分享本文Twitter / X
Palantir 的权限模型：为什么政府敢把机密数据交给它
“系列：S1 Palantir 解密 · 第 11 篇 | 难度：入门 | 阅读时间：15 分钟
#TL;DR
- Palantir 的安全模型源于军事情报分区体系（TS/SCI），将"需要知道"原则（Need-to-Know）嵌入平台底层——不是事后加上的访问控制，而是从第一行代码就设计为安全优先的架构。
- Palantir 同时实现了 RBAC（基于角色）、ABAC（基于属性）和 PBAC（基于策略）三种访问控制模型，支持行级、列级、单元格级的细粒度权限控制和动态数据脱敏。
- coomia-dip 通过 PolicyEngineService 实现了三模型评估、6 种脱敏模式（全掩码/部分掩码/哈希/范围/泛化/置空）、7 级数据分类（A1-D）和查询重写透明访问控制。
#引言：当"数据泄露"意味着人命
对大多数企业来说，数据安全是一个合规问题——罚款、声誉损失、客户流失。
但对 Palantir 的核心客户来说，数据安全是生死攸关的：
Code
Palantir 客户的数据安全级别：
┌─────────────────────────────────────────────────────┐
│ 美国国防部 (DoD) │
│ - 处理 TS/SCI 级别情报（最高机密/敏感分区信息） │
│ - 泄露后果：特工身份暴露、军事行动失败、人员伤亡 │
│ │
│ 中央情报局 (CIA) │
│ - 处理人力情报源信息 │
│ - 泄露后果：线人被杀、情报网络瓦解 │
│ │
│ 英国 GCHQ │
│ - 处理信号情报和通信监控数据 │
│ - 泄露后果：监控能力暴露、国家安全受损 │
│ │
│ NHS（英国国家医疗服务体系） │
│ - 处理 6500 万人的医疗记录 │
│ - 泄露后果：患者隐私侵犯、法律诉讼 │
│ │
│ 摩根大通 │
│ - 处理交易数据和客户金融信息 │
│ - 泄露后果：监管处罚、市场操纵风险 │
└─────────────────────────────────────────────────────┘
这些客户不会接受"我们尽力了"。他们需要的是数学上可证明的安全保证。
这就是 Palantir 安全模型的设计起点——不是为了通过合规审计，而是为了保护生命。
#一、军事信息分区：Palantir 安全模型的起源
#1.1 TS/SCI 分类体系
美国政府的信息分类体系是 Palantir 安全模型的直接灵感来源：
Code
美国政府信息分类等级：
┌────────────────────────────────────────────────┐
│ TOP SECRET / SCI │
│ (最高机密 / 敏感分区信息) │
│ - 泄露会造成"异常严重"的国家安全损害 │
│ - 需要特殊安全许可 + 需要知道 │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ SCI 分区 (Compartments) │ │
│ │ │ │
│ │ ┌────────┐ ┌────────┐ ┌────────┐ │ │
│ │ │ HCS │ │ SI │ │ TK │ │ │
│ │ │人力情报 │ │信号情报 │ │天基情报 │ │ │
│ │ │来源 │ │ │ │ │ │ │
│ │ └────────┘ └────────┘ └────────┘ │ │
│ │ │ │
│ │ 即使有 TS 权限，没有对应分区许可 │ │
│ │ 也不能访问该分区的数据 │ │
│ └──────────────────────────────────────────┘ │
├────────────────────────────────────────────────┤
│ SECRET (秘密) │
│ - 泄露会造成"严重"的国家安全损害 │
├────────────────────────────────────────────────┤
│ CONFIDENTIAL (机密) │
│ - 泄露会造成国家安全损害 │
├────────────────────────────────────────────────┤
│ UNCLASSIFIED (非密) │
│ - 公开信息 │
└────────────────────────────────────────────────┘
#1.2 "需要知道"原则
军事安全的核心不只是"你有没有权限"，而是"你是否需要知道"：
Code
传统权限模型： 军事安全模型：
问题：你有权限吗？ 问题 1：你的安全等级够吗？
│ │
├─ 是 → 允许访问 ├─ 否 → 拒绝
└─ 否 → 拒绝 └─ 是 → 问题 2：
你有对应分区许可吗？
│
├─ 否 → 拒绝
└─ 是 → 问题 3：
你需要知道这个信息吗？
│
├─ 否 → 拒绝
└─ 是 → 允许访问
即使你是将军（最高权限），
如果你不在这个任务中，你也看不到任务相关的情报。
Palantir 将这个三层检查模型直接嵌入了平台：
Code
Palantir 的三层访问检查：
┌──────────────────────────────────────────┐
│ Layer 1: 身份认证 (Authentication) │
│ "你是谁？" │
│ - SSO / SAML / OAuth 2.0 │
│ - MFA (多因素认证) │
│ - PKI 证书 (军事环境) │
└──────────────────┬───────────────────────┘
│ 通过
▼
┌──────────────────────────────────────────┐
│ Layer 2: 授权 (Authorization) │
│ "你有权限吗？" │
│ - RBAC: 角色检查 │
│ - ABAC: 属性检查 │
│ - PBAC: 策略检查 │
└──────────────────┬───────────────────────┘
│ 通过
▼
┌──────────────────────────────────────────┐
│ Layer 3: 数据级控制 (Data-Level Control) │
│ "你能看到哪些数据？" │
│ - 行级过滤: 只看到自己部门的数据 │
│ - 列级控制: 敏感列被隐藏 │
│ - 动态脱敏: 部分数据被模糊处理 │
└──────────────────────────────────────────┘
#二、RBAC + ABAC + PBAC：三重模型协同
#2.1 RBAC——基于角色的访问控制
RBAC 是最基础的权限层——根据用户的角色决定能做什么：
Code
RBAC 角色层次示例：
┌──────────┐
│ 平台管理员 │
│ (全局权限) │
└────┬─────┘
│
┌──────────┼──────────┐
│ │ │
┌─────┴────┐ ┌──┴───────┐ ┌┴─────────┐
│ 数据管理员 │ │ 业务管理员 │ │ 安全管理员 │
│ (数据配置) │ │ (业务操作) │ │ (权限配置) │
└─────┬────┘ └──┬───────┘ └┬─────────┘
│ │ │
┌─────┼───┐ ┌─┴──┐ ┌─┴──┐
│ │ │ │ │ │ │
┌─┴─┐┌─┴┐┌─┴┐ ┌┴─┐┌─┴┐ ┌┴─┐┌─┴┐
│分析││编││查│ │操││查│ │审││配│
│师 ││辑││看│ │作││看│ │计││置│
│ ││者││者│ │员││员│ │员││员│
└───┘└──┘└──┘ └──┘└──┘ └──┘└──┘
RBAC 权限矩阵示例：
| 角色 | 读取数据 | 修改数据 | 执行 Action | 管理权限 | 查看审计 |
|---|---|---|---|---|---|
| 查看者 | 本部门 | - | - | - | - |
| 分析师 | 全局 | - | - | - | - |
| 操作员 | 本部门 | 本部门 | 本部门 | - | - |
| 编辑者 | 全局 | 全局 | 全局 | - | - |
| 业务管理员 | 全局 | 全局 | 全局 | 本部门 | 本部门 |
| 安全管理员 | 全局 | - | - | 全局 | 全局 |
| 平台管理员 | 全局 | 全局 | 全局 | 全局 | 全局 |
#2.2 ABAC——基于属性的访问控制
RBAC 告诉我们"你能做什么"，ABAC 告诉我们"在什么条件下能做"：
Code
ABAC 策略示例：
Policy: "区域数据访问"
┌─────────────────────────────────────────────┐
│ Subject Attributes (主体属性): │
│ - user.department = "华东区" │
│ - user.clearance_level >= "SECRET" │
│ - user.employment_status = "ACTIVE" │
│ │
│ Resource Attributes (资源属性): │
│ - data.region = "华东区" │
│ - data.classification <= "SECRET" │
│ │
│ Environment Attributes (环境属性): │
│ - time.current BETWEEN 08:00 AND 22:00 │
│ - network.type = "INTERNAL" │
│ - device.compliant = true │
│ │
│ Action: READ │
│ │
│ Decision: PERMIT │
│ Condition: user.department == data.region │
│ AND user.clearance >= data.class │
│ AND network.type == "INTERNAL" │
└─────────────────────────────────────────────┘
ABAC 的强大之处在于它可以表达极其精细的访问条件：
| 场景 | RBAC 能做吗？ | ABAC 策略 |
|---|---|---|
| 只看本区域数据 | 需要为每个区域创建角色 | user.region == data.region |
| 工作时间才能访问 | 做不到 | time BETWEEN 08:00 AND 22:00 |
| 只能在内网访问 | 做不到 | network.type == "INTERNAL" |
| 合同期内才能看 | 做不到 | contract.end_date > now() |
| 高密级需要双人 | 做不到 | data.class >= SECRET AND approvers.count >= 2 |
#2.3 PBAC——基于策略的访问控制
PBAC 是最高层的策略抽象——定义组织级的安全策略：
Code
PBAC 策略层次：
┌────────────────────────────────────────────┐
│ 组织级策略 (Organizational Policy) │
│ │
│ Policy 1: "数据主权" │
│ - 中国区客户数据不能出境 │
│ - 欧盟数据遵守 GDPR │
│ │
│ Policy 2: "最小权限" │
│ - 所有权限默认拒绝 │
│ - 明确授予才能访问 │
│ │
│ Policy 3: "职责分离" │
│ - 创建者不能审批自己创建的内容 │
│ - 数据管理员不能修改审计日志 │
│ │
│ Policy 4: "时间衰减" │
│ - 临时权限自动过期 │
│ - 离职员工权限立即撤销 │
└────────────────────────────────────────────┘
三种模型的协同关系：
Code
访问请求到达时的评估流程：
请求: 用户 A 要读取订单 #12345
┌──────────┐
│ RBAC 检查 │ → 用户 A 的角色是"采购员"，有读取权限 → 通过
└─────┬────┘
│
▼
┌──────────┐
│ ABAC 检查 │ → 采购员只能看本部门数据
│ │ 订单 #12345 属于"华东采购部"
│ │ 用户 A 属于"华东采购部" → 通过
└─────┬────┘
│
▼
┌──────────┐
│ PBAC 检查 │ → 组织策略：内网环境才能访问采购数据
│ │ 当前网络：内网 → 通过
│ │
│ │ → 组织策略：工作时间访问
│ │ 当前时间：14:30 → 通过
└─────┬────┘
│
▼
允许访问（但可能需要数据脱敏）
#三、动态数据脱敏
#3.1 为什么需要"动态"脱敏？
传统的数据脱敏是静态的——创建一个脱敏后的数据副本。问题是：
Code
静态脱敏的问题：
原始数据库:
┌──────────┬───────────┬────────────┬──────────┐
│ 客户姓名 │ 身份证号 │ 手机号 │ 年收入 │
├──────────┼───────────┼────────────┼──────────┤
│ 张三 │ 310...1234│ 138...5678 │ ¥500,000 │
└──────────┴───────────┴────────────┴──────────┘
│
│ 创建脱敏副本
▼
脱敏副本:
┌──────────┬───────────┬────────────┬──────────┐
│ 客户姓名 │ 身份证号 │ 手机号 │ 年收入 │
├──────────┼───────────┼────────────┼──────────┤
│ 张* │ 310***1234│ 138****5678│ ¥500,000 │
└──────────┴───────────┴────────────┴──────────┘
问题 1：需要维护两份数据，同步困难
问题 2：所有人看到相同的脱敏结果——不够灵活
问题 3：数据分析时脱敏数据往往无法使用
Palantir 的动态脱敏是实时的、基于角色的——同一份数据，不同人看到不同的结果：
Code
动态脱敏——同一数据，不同视图：
原始数据（只有一份）:
┌──────────┬───────────────┬────────────┬──────────┐
│ 客户姓名 │ 身份证号 │ 手机号 │ 年收入 │
├──────────┼───────────────┼────────────┼──────────┤
│ 张三 │ 310105199001│ 13812345678│ ¥500,000 │
│ │ 011234 │ │ │
└──────────┴───────────────┴────────────┴──────────┘
客服人员看到: 风控分析师看到:
┌──────┬──────┬────────┬────┐ ┌──────┬───────────┬────────┬──────────┐
│ 张* │ **** │ 138****│ ** │ │ 张三 │ 3101**0123│ 138****│ ¥500,000 │
│ │ **** │ **5678 │ ** │ │ │ 4 │ **5678 │ │
└──────┴──────┴────────┴────┘ └──────┴───────────┴────────┴──────────┘
(只看到姓和手机后四位) (看到更多，但身份证中间脱敏)
合规审计员看到: 系统管理员看到:
┌──────┬───────────┬────────────┬──────────┐ 全部原文
│ 张三 │ 310105****│ 13812345678│ ¥500,000 │ (有完整权限)
│ │ **1234 │ │ │
└──────┴───────────┴────────────┴──────────┘
(身份证部分脱敏)
#3.2 六种脱敏模式
| 模式 | 效果 | 适用场景 | 示例 |
|---|---|---|---|
| 全掩码 (Full) | 完全替换 | 无权查看 | 张三 → *** |
| 部分掩码 (Partial) | 保留部分字符 | 需要核对身份 | 13812345678 → 138****5678 |
| 哈希 (Hash) | 不可逆转换 | 数据关联分析 | 张三 → a7b3c9 |
| 范围 (Range) | 显示范围而非精确值 | 统计分析 | ¥523,000 → ¥500K-600K |
| 泛化 (Generalization) | 降低精度 | 趋势分析 | 1990-03-15 → 1990年代 |
| 置空 (Null) | 返回空值 | 完全隐藏 | 张三 → null |
#3.3 脱敏规则配置
Python
# 脱敏策略配置示例
masking_policy = {
"object_type": "Customer",
"rules": [
{
"property": "id_card_number",
"rules_by_role": {
"customer_service": {
"mode": "full",
"reason": "客服无需查看身份证号"
},
"risk_analyst": {
"mode": "partial",
"keep_first": 4,
"keep_last": 4,
"mask_char": "*",
"reason": "风控需要前后四位核对"
},
"compliance_officer": {
"mode": "partial",
"keep_first": 6,
"keep_last": 4,
"mask_char": "*",
"reason": "合规需要地区信息"
},
"admin": {
"mode": "none",
"reason": "管理员完整权限",
"requires_mfa": True
}
}
},
{
"property": "phone_number",
"default_mode": "partial",
"keep_first": 3,
"keep_last": 4,
"mask_char": "*"
},
{
"property": "annual_income",
"rules_by_role": {
"customer_service": {"mode": "null"},
"risk_analyst": {"mode": "range", "step": 100000},
"default": {"mode": "null"}
}
}
]
}
#四、行级和列级安全
#4.1 列级安全（Column-Level Security）
不同角色看到不同的列：
Code
Employee 数据表：
管理员视图 (所有列可见):
┌──────┬──────┬────────┬──────┬──────┬────────┐
│ 工号 │ 姓名 │ 部门 │ 职位 │ 薪资 │ 绩效评分│
├──────┼──────┼────────┼──────┼──────┼────────┤
│ E001 │ 张三 │ 技术部 │ 高工 │ 35000│ A │
│ E002 │ 李四 │ 销售部 │ 经理 │ 42000│ B+ │
└──────┴──────┴────────┴──────┴──────┴────────┘
部门经理视图 (薪资列隐藏):
┌──────┬──────┬────────┬──────┬────────┐
│ 工号 │ 姓名 │ 部门 │ 职位 │ 绩效评分│
├──────┼──────┼────────┼──────┼────────┤
│ E001 │ 张三 │ 技术部 │ 高工 │ A │
│ E002 │ 李四 │ 销售部 │ 经理 │ B+ │
└──────┴──────┴────────┴──────┴────────┘
普通员工视图 (只看到基本信息):
┌──────┬──────┬────────┬──────┐
│ 工号 │ 姓名 │ 部门 │ 职位 │
├──────┼──────┼────────┼──────┤
│ E001 │ 张三 │ 技术部 │ 高工 │
│ E002 │ 李四 │ 销售部 │ 经理 │
└──────┴──────┴────────┴──────┘
#4.2 行级安全（Row-Level Security）
不同角色看到不同的行：
Code
订单数据表：
全局管理员看到所有数据 (1,247 行):
┌────────┬────────┬──────────┬──────────┐
│ 订单号 │ 区域 │ 客户 │ 金额 │
├────────┼────────┼──────────┼──────────┤
│ PO-001 │ 华东 │ 客户 A │ ¥52,000 │
│ PO-002 │ 华北 │ 客户 B │ ¥18,000 │
│ PO-003 │ 华东 │ 客户 C │ ¥31,000 │
│ PO-004 │ 华南 │ 客户 D │ ¥67,000 │
│ ... │ ... │ ... │ ... │
└────────┴────────┴──────────┴──────────┘
华东区经理只看到华东数据 (423 行):
┌────────┬────────┬──────────┬──────────┐
│ 订单号 │ 区域 │ 客户 │ 金额 │
├────────┼────────┼──────────┼──────────┤
│ PO-001 │ 华东 │ 客户 A │ ¥52,000 │
│ PO-003 │ 华东 │ 客户 C │ ¥31,000 │
│ ... │ ... │ ... │ ... │
└────────┴────────┴──────────┴──────────┘
关键：用户完全不知道其他区域的数据存在！
#4.3 行列交叉的精细控制
真实场景中，行级和列级安全往往需要组合：
Code
组合效果：华东区客服人员
行过滤: region = "华东"
列过滤: 隐藏 [薪资, 绩效]
动态脱敏: 手机号部分掩码
结果：
┌────────┬──────┬────────┬────────────┐
│ 客户名 │ 区域 │ 等级 │ 手机号 │
├────────┼──────┼────────┼────────────┤
│ 张三 │ 华东 │ VIP │ 138****5678│
│ 王五 │ 华东 │ 普通 │ 159****2345│
└────────┴──────┴────────┴────────────┘
三层安全措施同时生效：
1. 行过滤 → 只看到华东客户
2. 列过滤 → 看不到敏感列
3. 动态脱敏 → 手机号部分隐藏
#五、数据分类和标签体系
#5.1 为什么需要数据分类？
不同敏感度的数据需要不同级别的保护：
Code
数据分类层次：
┌─────────────────────────────────────────────┐
│ Level 4: 最高机密 (Top Secret) │
│ - 军事行动计划 │
│ - 核心算法源码 │
│ - 尚未公开的并购信息 │
│ 保护要求: 加密存储 + 审批访问 + 全程审计 │
├─────────────────────────────────────────────┤
│ Level 3: 机密 (Confidential) │
│ - 客户个人信息 (PII) │
│ - 财务报表（未发布） │
│ - 员工薪资信息 │
│ 保护要求: 加密存储 + 角色控制 + 访问审计 │
├─────────────────────────────────────────────┤
│ Level 2: 内部 (Internal) │
│ - 内部操作流程 │
│ - 会议记录 │
│ - 项目计划 │
│ 保护要求: 内网访问 + 基本角色控制 │
├─────────────────────────────────────────────┤
│ Level 1: 公开 (Public) │
│ - 产品手册 │
│ - 公司官网内容 │
│ - 已发布的财报 │
│ 保护要求: 无特殊要求 │
└─────────────────────────────────────────────┘
#5.2 自动分类标签
Palantir 支持自动为数据打标签：
Code
自动分类规则引擎：
数据写入
│
▼
┌──────────────────────────────────┐
│ 分类规则引擎 │
│ │
│ Rule 1: 正则匹配 │
│ - 身份证号模式 → PII 标签 │
│ - 手机号模式 → PII 标签 │
│ - 银行卡号模式 → FINANCIAL 标签 │
│ │
│ Rule 2: 列名匹配 │
│ - *password* → CREDENTIAL │
│ - *salary* → COMPENSATION │
│ - *ssn* → PII │
│ │
│ Rule 3: 数据源标记 │
│ - 来自 HR 系统 → INTERNAL │
│ - 来自 CRM → CUSTOMER_DATA │
│ - 来自政府接口 → GOVERNMENT │
│ │
│ Rule 4: 机器学习分类 │
│ - NLP 识别敏感文本内容 │
│ - 模式识别异常数据格式 │
└──────────────────────────────────┘
│
▼
数据自动标记: [PII, FINANCIAL, Level-3]
#六、审计链路——谁看了什么
#6.1 全链路审计
Palantir 记录的不仅是"谁改了什么"，还有"谁看了什么"：
Code
审计事件类型：
┌──────────────────────────────────────────────┐
│ 数据访问审计 (Read Audit) │
│ │
│ 时间: 2026-03-24 14:30:52 │
│ 用户: zhang.wei@company.com │
│ 操作: SEARCH │
│ 对象类型: Customer │
│ 查询条件: region="华东" AND level="VIP" │
│ 返回行数: 47 │
│ 访问列: [name, phone, level] │
│ 脱敏应用: phone → partial_mask │
│ 来源 IP: 10.0.12.47 │
│ 设备 ID: DEV-A3B7C9 │
│ 会话时长: 12min │
└──────────────────────────────────────────────┘
┌──────────────────────────────────────────────┐
│ 数据导出审计 (Export Audit) │
│ │
│ 时间: 2026-03-24 15:12:08 │
│ 用户: li.si@company.com │
│ 操作: EXPORT_CSV │
│ 对象类型: Order │
│ 导出行数: 1,247 │
│ 包含列: [order_id, customer, amount, status] │
│ 脱敏状态: amount → range_mask │
│ 审批状态: 已获 manager 审批 │
│ 文件哈希: sha256:a7b3c9... │
│ 水印标记: 已嵌入用户身份水印 │
└──────────────────────────────────────────────┘
#6.2 异常行为检测
Code
异常检测规则：
正常模式 (基线):
- 张三每天查询约 50 次客户数据
- 访问时间: 09:00 - 18:00
- 主要访问华东区数据
告警触发:
┌──────────────────────────────────────┐
│ ALERT: 异常数据访问模式 │
│ │
│ 用户: zhang.wei │
│ 异常: 凌晨 3:00 批量下载客户数据 │
│ 详情: │
│ - 时间: 03:17 (非正常工作时间) │
│ - 查询量: 2,847 次 (正常 50 次/天) │
│ - 区域: 全国 (正常只看华东) │
│ - 操作: EXPORT (非常规操作) │
│ │
│ 风险等级: HIGH │
│ 自动响应: │
│ - 暂停用户访问权限 │
│ - 通知安全管理员 │
│ - 保存完整操作记录 │
└──────────────────────────────────────┘
#七、气隙部署安全
#7.1 什么是气隙部署？
军事和高安全环境要求系统完全与互联网隔离：
Code
气隙部署架构：
┌─────────────────────────────────┐
│ 互联网 │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ 公共云 │ │ SaaS 服务│ │
│ └──────────┘ └──────────┘ │
└─────────────────────────────────┘
╳ 物理隔离 (Air Gap) ╳
╳ 没有任何网络连接 ╳
┌─────────────────────────────────┐
│ 安全内网环境 │
│ │
│ ┌──────────────────────────┐ │
│ │ Palantir Foundry │ │
│ │ (完全独立部署) │ │
│ │ │ │
│ │ - 所有服务本地运行 │ │
│ │ - 数据从不离开内网 │ │
│ │ - 更新通过物理介质 │ │
│ │ - 独立 PKI 证书体系 │ │
│ └──────────────────────────┘ │
│ │
│ 物理安全: │
│ - 机房生物识别门禁 │
│ - 24/7 监控 │
│ - 电磁屏蔽 (TEMPEST) │
└─────────────────────────────────┘
#7.2 合规认证
Palantir 持有的安全认证：
| 认证 | 级别 | 含义 |
|---|---|---|
| FedRAMP | High | 可处理美国联邦政府最敏感的非密数据 |
| IL2 | CUI | 受控非密信息 |
| IL4 | Secret | 秘密级军事信息 |
| IL5 | Mission-Critical | 关键任务系统 |
| IL6 | Top Secret | 最高机密级别 |
| SOC 2 Type II | - | 安全控制独立审计 |
| ISO 27001 | - | 信息安全管理体系 |
Code
IL 级别对应的部署要求：
IL2: 商业云 (AWS GovCloud)
IL4: 政府专用云 (隔离区域)
IL5: 国防部专用基础设施
IL6: 独立气隙环境 (物理隔离)
Palantir 是极少数能同时满足 IL2-IL6 的软件平台。
#八、coomia-dip 的安全实现
#8.1 PolicyEngineService——三模型评估
coomia-dip 的 PolicyEngineService 实现了 RBAC + ABAC + PBAC 的统一评估：
Code
coomia-dip PolicyEngineService 架构：
访问请求
│
▼
┌──────────────────────────────────────────────┐
│ PolicyEngineService │
│ │
│ ┌────────────────────────────────────────┐ │
│ │ 1. RBAC Evaluator │ │
│ │ - 加载用户角色 │ │
│ │ - 匹配角色权限矩阵 │ │
│ │ - 结果: PERMIT / DENY / INDETERMINATE│ │
│ └──────────────┬─────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────────┐ │
│ │ 2. ABAC Evaluator │ │
│ │ - 收集主体属性 (用户) │ │
│ │ - 收集资源属性 (数据) │ │
│ │ - 收集环境属性 (时间/网络) │ │
│ │ - 评估属性匹配规则 │ │
│ │ - 结果: PERMIT / DENY / INDETERMINATE│ │
│ └──────────────┬─────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────────┐ │
│ │ 3. PBAC Evaluator │ │
│ │ - 加载组织级策略 │ │
│ │ - 检查数据主权约束 │ │
│ │ - 检查职责分离约束 │ │
│ │ - 检查时间/合规约束 │ │
│ │ - 结果: PERMIT / DENY / INDETERMINATE│ │
│ └──────────────┬─────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────────┐ │
│ │ Decision Combiner │ │
│ │ - 组合策略: DENY_OVERRIDES │ │
│ │ - 任何一个 DENY → 最终 DENY │ │
│ │ - 全部 PERMIT → 最终 PERMIT │ │
│ │ - 有 INDETERMINATE → 默认 DENY │ │
│ └────────────────────────────────────────┘ │
└──────────────────────────────────────────────┘
#8.2 六种脱敏模式实现
Python
# coomia-dip 脱敏引擎代码示例
from ontology_sdk.security import MaskingEngine, MaskingMode
engine = MaskingEngine()
# 全掩码
engine.mask("张三", MaskingMode.FULL)
# 结果: "***"
# 部分掩码
engine.mask("13812345678", MaskingMode.PARTIAL,
keep_first=3, keep_last=4)
# 结果: "138****5678"
# 哈希
engine.mask("张三", MaskingMode.HASH, algorithm="sha256")
# 结果: "a7b3c9d2"
# 范围
engine.mask(523000, MaskingMode.RANGE, step=100000)
# 结果: "500000-600000"
# 泛化
engine.mask("1990-03-15", MaskingMode.GENERALIZATION,
level="decade")
# 结果: "1990s"
# 置空
engine.mask("sensitive_data", MaskingMode.NULL)
# 结果: None
#8.3 7 级数据分类（A1-D）
coomia-dip 实现了 7 级数据分类体系：
Code
coomia-dip 数据分类体系：
┌─────┬──────────────┬──────────────────────────────┐
│ 级别 │ 标识 │ 说明 │
├─────┼──────────────┼──────────────────────────────┤
│ A1 │ TOP_SECRET │ 最高机密 - 泄露造成灾难性损害 │
│ A2 │ SECRET │ 机密 - 泄露造成严重损害 │
│ A3 │ CONFIDENTIAL │ 秘密 - 泄露造成显著损害 │
│ B1 │ RESTRICTED │ 受限 - 仅授权人员可访问 │
│ B2 │ INTERNAL │ 内部 - 仅组织内部可访问 │
│ C │ SENSITIVE │ 敏感 - 需要基本保护 │
│ D │ PUBLIC │ 公开 - 无访问限制 │
└─────┴──────────────┴──────────────────────────────┘
每个级别的保护要求：
A1: 加密存储 + 加密传输 + 双人审批 + 全程审计
+ 气隙环境 + 访问时间窗口限制
A2: 加密存储 + 加密传输 + 审批访问 + 全程审计
A3: 加密存储 + 加密传输 + 角色控制 + 访问审计
B1: 加密存储 + 角色控制 + 访问审计
B2: 角色控制 + 基本审计
C: 基本认证 + 操作日志
D: 无特殊要求
#8.4 查询重写——透明的访问控制
coomia-dip 最强大的安全特性之一是查询重写——用户的查询在执行前被自动注入安全过滤条件：
Code
查询重写示例：
用户原始查询:
SELECT * FROM orders WHERE amount > 10000
用户上下文:
role: regional_manager
region: "华东"
clearance: B1
查询重写引擎处理:
┌──────────────────────────────────────────┐
│ 1. 行级安全注入: │
│ WHERE region = '华东' │
│ │
│ 2. 列级安全过滤: │
│ 移除 [internal_notes, margin] 列 │
│ │
│ 3. 分类级别过滤: │
│ WHERE classification_level <= 'B1' │
│ │
│ 4. 脱敏函数注入: │
│ customer_phone → MASK(customer_phone, │
│ 'partial', 3, 4) │
└──────────────────────────────────────────┘
最终执行的查询:
SELECT order_id, region, customer_name,
MASK(customer_phone, 'partial', 3, 4)
as customer_phone,
amount, status
FROM orders
WHERE amount > 10000
AND region = '华东'
AND classification_level <= 'B1'
用户完全感知不到安全过滤的存在——
他以为自己查询了所有数据，实际上只看到了被允许看的部分。
Python
# coomia-dip 查询重写 SDK 示例
from ontology_sdk import OntoPlatform
platform = OntoPlatform(endpoint="grpc://localhost:9090")
# 用户代码 —— 不需要关心安全过滤
orders = platform.objects.search("Order") \
.filter(amount__gt=10000) \
.select("order_id", "customer_name",
"customer_phone", "amount") \
.all()
# 在底层，SDK 自动:
# 1. 检查用户权限
# 2. 注入行级过滤 (只返回用户有权限的行)
# 3. 过滤列 (移除无权限的列)
# 4. 应用脱敏 (对敏感字段脱敏)
# 5. 记录审计日志
# 开发者不需要写任何安全代码
# 安全是平台的责任，不是应用的责任
#九、安全设计哲学：为什么这种模型有效
#9.1 "安全即架构"而非"安全即插件"
Code
传统方法: 安全是事后加上的
┌──────────┐
│ 应用代码 │ ← 先开发功能
└────┬─────┘
│ 然后加上
▼
┌──────────┐
│ 安全中间件│ ← 容易被绕过
└────┬─────┘
│
▼
┌──────────┐
│ 数据库 │ ← 直接访问 = 绕过安全
└──────────┘
Palantir / coomia-dip 方法: 安全是架构的一部分
┌────────────────────────────────────────┐
│ Ontology Layer │
│ ┌──────────────────────────────────┐ │
│ │ 每次数据访问都经过安全引擎 │ │
│ │ │ │
│ │ Object → Permission → Masking │ │
│ │ ↓ ↓ ↓ │ │
│ │ Storage RBAC/ABAC Dynamic │ │
│ │ /PBAC Transform │ │
│ └──────────────────────────────────┘ │
│ │
│ 没有"绕过"的路径 — Ontology 是唯一 │
│ 的数据访问通道 │
└────────────────────────────────────────┘
#9.2 零信任原则
| 原则 | 实现方式 |
|---|---|
| 永不信任，始终验证 | 每次请求都重新评估权限 |
| 最小权限 | 默认拒绝，显式授权 |
| 假设已被入侵 | 全链路加密 + 审计 |
| 纵深防御 | RBAC + ABAC + PBAC 多层检查 |
| 持续监控 | 实时异常检测 + 自动响应 |
#Key Takeaways
-
Palantir 的安全模型源于军事情报分区体系，这不是营销噱头而是真实的设计起源——"需要知道"原则、分区隔离、多因素认证这些军事级概念被直接嵌入平台架构。RBAC + ABAC + PBAC 三模型协同确保了从角色、属性到组织策略的全维度访问控制。
-
动态数据脱敏和查询重写是 Palantir 安全模型最优雅的实现——同一份数据，不同角色看到不同的视图，而开发者不需要在应用代码中编写任何安全逻辑。安全是平台的责任，不是应用的责任。这彻底消除了"开发者忘记加权限检查"的风险。
-
coomia-dip 通过 PolicyEngineService 实现了三模型统一评估，6 种脱敏模式覆盖所有场景，7 级数据分类（A1-D）提供了从公开到最高机密的完整分级——查询重写机制让安全控制对应用层完全透明，任何通过 Ontology 访问数据的操作都自动受到安全引擎的保护。
#下篇预告
“第 13 篇：Palantir 的 Apollo 部署引擎——让软件自己管理自己
安全的软件如果不能可靠部署，安全就是空谈。Apollo 是 Palantir 的持续部署引擎，它管理着全球数百个 Foundry 实例的部署——从五角大楼的气隙环境到商业云。下一篇我们将解析 Apollo 如何实现零宕机部署、自动回滚和跨环境一致性。
#palantir #security #rbac #abac #access-control #data-masking #audit #coomia-dip #fedramp