3、权限隔离核心原则：最小权限原则、职责分离（SoD）、默认拒绝策略、数据与密钥的租户级隔离

在多租户签名链路中，权限隔离是防止租户间越权访问、数据泄露和密钥滥用的第一道防线。本章围绕四个核心原则展开，它们共同构成了权限隔离的“四梁八柱”。

3.1 最小权限原则（Principle of Least Privilege）

最小权限原则要求任何主体（用户、服务、进程）仅被授予完成其任务所必需的最小权限集合，且权限仅在任务生命周期内有效。在多租户签名链路中，这意味着：

• 签名服务进程：仅能访问当前租户的密钥存储路径，不能遍历其他租户的密钥目录。
• API 调用者：仅能调用其租户范围内的签名/验签接口，不能调用管理类接口（如密钥轮换、租户配置）。
• 审计日志读取：运维人员仅能读取与其职责相关的日志，不能查看签名请求的明文载荷。

3.2 职责分离（Separation of Duties, SoD）

职责分离通过将关键操作拆分为多个独立步骤，并由不同角色执行，以防止单点滥用。在签名链路中，SoD 主要体现为：

3.3 默认拒绝策略（Default Deny）

默认拒绝策略要求：除非显式授予权限，否则所有访问请求默认被拒绝。这与“白名单”机制一致，能有效防止因配置遗漏导致的越权。在多租户签名链路中，默认拒绝策略的落地包括：

• 网络层：服务网格（如 Istio）的 AuthorizationPolicy 默认拒绝所有入站流量，仅放行携带有效 JWT 且来源 IP 在白名单内的请求。
• 应用层：签名 API 端点默认返回 403 Forbidden，除非请求中携带的租户 ID 与签名密钥的租户归属一致。
• 数据层：密钥存储（如 HashiCorp Vault）的路径策略默认拒绝所有读/写操作，仅对绑定特定角色的 开放。

# 示例：Istio AuthorizationPolicy 实现默认拒绝 + 显式放行
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: signing-service-policy
  namespace: tenant-a
spec:
  selector:
    matchLabels:
      app: signing-service
  action: DENY  # 默认拒绝所有请求
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/tenant-a/sa/signing-sa"]
    to:
    - operation:
        methods: ["POST"]
        paths: ["/sign"]

3.4 数据与密钥的租户级隔离

这是多租户签名链路中最具挑战性的原则。它要求每个租户的签名密钥、签名请求数据、签名结果和审计日志在存储、传输和计算过程中严格隔离。常见的隔离模式包括：

• 物理隔离：每个租户使用独立的硬件安全模块（HSM）分区或独立的密钥管理实例。安全性最高，但成本也最高。
• 逻辑隔离：共享同一密钥管理基础设施，但通过租户 ID 作为路径前缀或标签进行隔离。例如，Vault 中密钥路径为 secret/tenant-a/signing-key 和 secret/tenant-b/signing-key。
• 加密隔离：使用租户专属的加密密钥对存储数据进行加密，即使存储层被突破，也无法解密其他租户的数据。

3.5 原则间的协同与冲突处理

四个原则并非孤立存在，它们在实际落地中需要协同工作，也可能产生冲突。例如：

• 最小权限 vs. 职责分离：最小权限要求权限尽可能小，但 SoD 要求拆分操作给不同角色，可能导致单个角色的权限过小以至于无法完成工作。此时需要引入“临时提权”机制（如 Just-In-Time 访问），并配合审计。
• 默认拒绝 vs. 租户级隔离：默认拒绝策略在租户级隔离中表现为“拒绝跨租户访问”。但签名链路中可能存在跨租户的签名验证需求（如联盟链场景），此时需要显式创建跨租户的信任策略。
• 租户级隔离 vs. 运维效率：严格的物理隔离会大幅增加运维成本。建议采用“分层隔离”策略：核心密钥使用物理隔离，签名请求数据使用逻辑隔离，审计日志使用加密隔离。