Palantir 权限模型深度解析：为什么政府敢把机密数据交给它

Palantir 客户的数据安全级别：

┌─────────────────────────────────────────────────────┐
│  美国国防部 (DoD)                                     │
│  - 处理 TS/SCI 级别情报（最高机密/敏感分区信息）         │
│  - 泄露后果：特工身份暴露、军事行动失败、人员伤亡          │
│                                                       │
│  中央情报局 (CIA)                                      │
│  - 处理人力情报源信息                                   │
│  - 泄露后果：线人被杀、情报网络瓦解                      │
│                                                       │
│  英国 GCHQ                                            │
│  - 处理信号情报和通信监控数据                            │
│  - 泄露后果：监控能力暴露、国家安全受损                   │
│                                                       │
│  NHS（英国国家医疗服务体系）                             │
│  - 处理 6500 万人的医疗记录                             │
│  - 泄露后果：患者隐私侵犯、法律诉讼                      │
│                                                       │
│  摩根大通                                              │
│  - 处理交易数据和客户金融信息                            │
│  - 泄露后果：监管处罚、市场操纵风险                      │
└─────────────────────────────────────────────────────┘

传统权限模型：               军事安全模型：

问题：你有权限吗？           问题 1：你的安全等级够吗？
  │                           │
  ├─ 是 → 允许访问            ├─ 否 → 拒绝
  └─ 否 → 拒绝               └─ 是 → 问题 2：
                                    你有对应分区许可吗？
                                      │
                                      ├─ 否 → 拒绝
                                      └─ 是 → 问题 3：
                                            你需要知道这个信息吗？
                                              │
                                              ├─ 否 → 拒绝
                                              └─ 是 → 允许访问

即使你是将军（最高权限），
如果你不在这个任务中，你也看不到任务相关的情报。

Palantir 的三层访问检查：

┌──────────────────────────────────────────┐
│  Layer 1: 身份认证 (Authentication)       │
│  "你是谁？"                              │
│  - SSO / SAML / OAuth 2.0               │
│  - MFA （多因素认证）                       │
│  - PKI 证书 （军事环境）                    │
└──────────────────┬───────────────────────┘
                   │ 通过
                   ▼
┌──────────────────────────────────────────┐
│  Layer 2: 授权 (Authorization)            │
│  "你有权限吗？"                           │
│  - RBAC: 角色检查                         │
│  - ABAC: 属性检查                         │
│  - PBAC: 策略检查                         │
└──────────────────┬───────────────────────┘
                   │ 通过
                   ▼
┌──────────────────────────────────────────┐
│  Layer 3: 数据级控制 (Data-Level Control) │
│  "你能看到哪些数据？"                     │
│  - 行级过滤： 只看到自己部门的数据           │
│  - 列级控制： 敏感列被隐藏                  │
│  - 动态脱敏： 部分数据被模糊处理             │
└──────────────────────────────────────────┘

组织级策略：

Policy 1: "数据主权"
- 中国区客户数据不能出境
- 欧盟数据遵守 GDPR

Policy 2: "最小权限"
- 所有权限默认拒绝
- 明确授予才能访问

Policy 3: "职责分离"
- 创建者不能审批自己创建的内容
- 数据管理员不能修改审计日志

Policy 4: "时间衰减"
- 临时权限自动过期
- 离职员工权限立即撤销

请求： 用户 A 要读取订单 #12345

┌──────────┐
│ RBAC 检查 │ → 用户 A 的角色是"采购员"，有读取权限 → 通过
└─────┬────┘
      │
      ▼
┌──────────┐
│ ABAC 检查 │ → 采购员只能看本部门数据
│          │   订单 #12345 属于"华东采购部"
│          │   用户 A 属于"华东采购部" → 通过
└─────┬────┘
      │
      ▼
┌──────────┐
│ PBAC 检查 │ → 组织策略：内网环境才能访问采购数据
│          │   当前网络：内网 → 通过
└─────┬────┘
      │
      ▼
   允许访问（但可能需要数据脱敏）

动态脱敏——同一数据，不同视图：

客服人员看到：                   风控分析师看到：
┌──────┬──────┬────────┬────┐  ┌──────┬───────────┬────────┬──────────┐
│ 张*  │ ****  │ 138****│ ** │  │ 张三  │ 3101**0123│ 138****│ ¥500,000 │
│     │ ****  │ **5678 │ ** │  │      │ 4         │ **5678 │          │
└──────┴──────┴────────┴────┘  └──────┴───────────┴────────┴──────────┘
 （只看到姓和手机后四位）           （看到更多，但身份证中间脱敏）

管理员视图 （所有列可见）:
┌──────┬──────┬────────┬──────┬──────┬────────┐
│ 工号  │ 姓名  │ 部门   │ 职位  │ 薪资  │ 绩效评分│
├──────┼──────┼────────┼──────┼──────┼────────┤
│ E001 │ 张三  │ 技术部  │ 高工  │ 35000│  A     │
└──────┴──────┴────────┴──────┴──────┴────────┘

普通员工视图 （只看到基本信息）:
┌──────┬──────┬────────┬──────┐
│ 工号  │ 姓名  │ 部门   │ 职位  │
├──────┼──────┼────────┼──────┤
│ E001 │ 张三  │ 技术部  │ 高工  │
└──────┴──────┴────────┴──────┘

全局管理员看到所有数据 (1,247 行）:
┌────────┬────────┬──────────┬──────────┐
│ 订单号  │ 区域    │ 客户     │ 金额     │
├────────┼────────┼──────────┼──────────┤
│ PO-001 │ 华东   │ 客户 A   │ ¥52,000  │
│ PO-002 │ 华北   │ 客户 B   │ ¥18,000  │
│ PO-003 │ 华东   │ 客户 C   │ ¥31,000  │
└────────┴────────┴──────────┴──────────┘

华东区经理只看到华东数据 (423 行）:
┌────────┬────────┬──────────┬──────────┐
│ 订单号  │ 区域    │ 客户     │ 金额     │
├────────┼────────┼──────────┼──────────┤
│ PO-001 │ 华东   │ 客户 A   │ ¥52,000  │
│ PO-003 │ 华东   │ 客户 C   │ ¥31,000  │
└────────┴────────┴──────────┴──────────┘

关键：用户完全不知道其他区域的数据存在！

组合效果：华东区客服人员

行过滤： region = "华东"
列过滤： 隐藏 [薪资， 绩效]
动态脱敏： 手机号部分掩码

结果：
┌────────┬──────┬────────┬────────────┐
│ 客户名  │ 区域  │ 等级   │ 手机号      │
├────────┼──────┼────────┼────────────┤
│ 张三   │ 华东  │ VIP    │ 138****5678│
│ 王五   │ 华东  │ 普通   │ 159****2345│
└────────┴──────┴────────┴────────────┘

三层安全措施同时生效：
1. 行过滤 → 只看到华东客户
2. 列过滤 → 看不到敏感列
3. 动态脱敏 → 手机号部分隐藏

用户原始查询：
  SELECT * FROM orders WHERE amount > 10000

查询重写引擎处理后：
  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'

用户完全感知不到安全过滤的存在——
他以为自己查询了所有数据，实际上只看到了被允许看的部分。

传统方法： 安全是事后加上的

┌──────────┐
│ 应用代码  │ <- 先开发功能
└────┬─────┘
     │ 然后加上
     ▼
┌──────────┐
│ 安全中间件│ <- 容易被绕过
└────┬─────┘
     │
     ▼
┌──────────┐
│ 数据库    │ <- 直接访问 = 绕过安全
└──────────┘

Palantir 方法： 安全是架构的一部分

┌────────────────────────────────────────┐
│              Ontology Layer            │
│  ┌──────────────────────────────────┐ │
│  │ 每次数据访问都经过安全引擎         │ │
│  │                                    │ │
│  │ Object → Permission → Masking     │ │
│  │   |         |          |          │ │
│  │ Storage   RBAC/ABAC  Dynamic      │ │
│  │           /PBAC      Transform    │ │
│  └──────────────────────────────────┘ │
│                                        │
│ 没有"绕过"的路径 — Ontology 是唯一      │
│ 的数据访问通道                          │
└────────────────────────────────────────┘