零信任架构落地实践

“内网可信"这个假设在混合办公、多云部署与供应链攻击面前已经彻底破产。零信任不是买一套产品，而是把安全模型从**“信任网络位置”改成“每次访问都验证身份与上下文”**。本文按落地顺序拆解：身份体系、持续验证、微隔离、工作负载身份，以及最难的一步——如何在遗留系统上分阶段推进。

1. 从边界防御到零信任

1.1 传统边界模型的失效

传统模型把网络切成"可信内网"与"不可信外网”，一旦进入内网就默认可信。这个假设在三种场景下同时崩塌：

攻击者一旦突破边界，就能在内网横向移动——因为横向流量几乎没有认证。零信任正是冲着这个"横向移动"来的。

1.2 零信任的核心原则

NIST SP 800-207 给出的定义可以浓缩为三条可执行原则：

1. 永不默认信任：任何访问请求，无论来自内网还是外网，都必须经过身份与策略校验。
2. 最小权限：只授予完成当前任务所必需的最小访问范围与最短有效时间。
3. 假设已被入侵：按"攻击者已在内部"设计检测、隔离与响应能力。

注意这三条都是架构原则，不是产品功能。落地时它们分别对应身份体系、微隔离与可观测性。与 安全架构设计 中的纵深防御相比，零信任更强调每次访问的动态判定而非静态的多层防护。

2. 身份即边界与持续验证

2.1 身份体系：从"网络位置"到"身份"

零信任的第一步是把访问控制的基准从 IP 换成身份。完整的身份谱系包含三类主体：

用户身份（Human Identity）
  └─ SSO / OIDC / MFA  →  谁在访问

设备身份（Device Identity）
  └─ 证书 / TPM / MDM   →  用什么设备访问

工作负载身份（Workload Identity）
  └─ SPIFFE / mTLS      →  哪个服务在访问

三者缺一不可：只验用户不验设备，被盗凭证可以在任意设备使用；只验设备不验工作负载，一个被攻陷的 Pod 就能冒充任意服务。

2.2 持续验证与风险评分

零信任的关键词是持续。一次登录通过不等于一直可信——会话期间的上下文变化（换了 IP、换了设备、行为异常）应当触发重新验证。

# 策略引擎的输入：每个请求都重新计算风险分
request_context:
  subject:
    user_id: u-10086
    mfa_level: totp          # 认证强度
    session_age_min: 45
  device:
    device_id: d-abc
    compliant: true          # 是否满足合规基线（补丁/加密/EDR）
    managed: true
  resource:
    service: payment-api
    sensitivity: high
  network:
    source_ip: 203.0.113.7
    geo: SG
    unusual_geo: true        # 与历史常用地不符
  behavior:
    request_rate_1m: 340
    unusual_time: false

decision:
  risk_score: 72             # 0~100
  action: step_up            # allow / step_up / deny
  reason: "unusual_geo + high_sensitivity"

风险评分而非二元判定是零信任与"防火墙白名单"的本质区别：同样的身份，在常用地访问低敏资源是 allow，在异常地域访问高敏资源就要 step_up（要求二次认证）甚至 deny。

2.3 短周期凭证

长期有效的凭证是横向移动的燃料。零信任要求凭证短、窄、可撤销：

# Vault 动态数据库凭证：每次连接申请一个临时账号
vault read database/creds/readonly-role
# Key                Value
# lease_id           database/creds/readonly-role/8f3a...
# lease_duration     1h
# username           v-token-readonly-9f2a1b
# password           A1a-3xK9mZq7...

凭证有效期 1 小时、到期自动失效、泄露窗口极小。踩坑点：动态凭证要求应用能处理"连接被回收"，长连接池必须配 max_connection_lifetime，否则凭证过期后连接报错。

3. 微隔离与最小权限

3.1 微隔离的三个层次

微隔离（Micro-segmentation）把"内网"切成许多需要显式授权的微小区域。按粒度分为三层：

多数团队的做法是L3/L4 打底 + L4/L7 精细化：用 NetworkPolicy 保证默认拒绝，用服务网格（详见 服务网格与 Istio ）做基于身份的授权。

3.2 从"默认拒绝"开始

微隔离的正确起点是默认拒绝，然后按需放行：

# 1) 默认拒绝所有入站
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny-ingress, namespace: payment }
spec:
  podSelector: {}
  policyTypes: ["Ingress"]
---
# 2) 只放行来自网关的流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: allow-from-gateway, namespace: payment }
spec:
  podSelector: { matchLabels: { app: payment-api } }
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - namespaceSelector: { matchLabels: { tier: gateway } }
      ports: [{ protocol: TCP, port: 8080 }]

踩坑点：直接从"全放行"跳到"默认拒绝"，会让大量隐式依赖立刻断链。正确做法是先用流量观测生成候选策略，再切默认拒绝。

3.3 策略从观测中生成

不要凭架构图手写策略——真实的调用关系往往与文档不符。先用 eBPF 或服务网格采集一段时间的东西向流量，生成候选白名单：

# 采集 7 天流量后生成候选策略（伪代码输出）
$ flow-analyzer --ns payment --days 7 --format policy
service: payment-api
  ingress_from:
    - api-gateway (tier=gateway)    : 8080   # 命中 12,480,331 次
    - order-worker (tier=app)       : 8080   # 命中     4,120 次
  egress_to:
    - payment-db (tier=data)        : 5432   # 命中  8,901,222 次
    - risk-engine (tier=app)        : 8443   # 命中    220,455 次

生成的候选策略要人工复核后再上线：低频调用可能是定时任务、也可能是攻击探测，必须逐条确认。复核后的策略即为最小权限基线。

3.4 最小权限的持续收敛

最小权限不是一次配置，而是持续收敛的过程：

• 权限回收：定期扫描"90 天未使用"的权限并自动告警，超期未说明即回收。
• 权限申请流程化：临时权限带 TTL，到期自动失效，避免"临时变永久"。
• 权限变更可审计：每次授权、回收、越权尝试都进审计日志。

4. 设备与工作负载身份

4.1 设备身份与合规基线

设备身份解决"这个请求来自哪台设备、这台设备是否可信"。落地要点：

• 设备证书：每台设备签发唯一证书（优先硬件 TPM 存储私钥），作为设备身份凭证。
• 合规基线：磁盘加密、补丁级别、EDR 在线、屏幕锁——任一不满足即降低信任等级。
• 持续评估：不是登录时查一次，而是会话期间持续上报状态，状态恶化立即降级。

# 设备合规策略（部分）
device_policy:
  require:
    disk_encrypted: true
    os_patch_max_age_days: 30
    edr_running: true
    screen_lock_max_min: 5
  on_violation:
    high_sensitivity_resource: deny
    normal_resource: allow_with_reauth

4.2 工作负载身份：SPIFFE 与 mTLS

服务间通信不能靠"IP 白名单"，因为 Pod 的 IP 随时在变。SPIFFE 为每个工作负载分配一个可验证的身份（SVID），用短周期证书承载：

spiffe://acme.internal/ns/payment/sa/payment-api
        └─ 信任域    └─ 命名空间  └─ 服务账号

服务网格可以自动完成 SVID 签发与轮换，应用侧只需发起普通 gRPC/HTTP 调用，mTLS 由 Sidecar 透明处理：

# Istio：基于工作负载身份授权，只允许 order 服务调用 payment
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payment-api-authz
  namespace: payment
spec:
  selector:
    matchLabels: { app: payment-api }
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/order/sa/order-service"]
      to:
        - operation:
            methods: ["POST"]
            paths: ["/v1/payments"]

关键收益：即使攻击者拿到了某个 Pod 的 IP，也无法冒充 order-service 的身份——因为 SVID 私钥无法复制，且证书几分钟就轮换一次。

5. 迁移路线与遗留系统兼容

5.1 分阶段迁移

零信任不可能一次性切换。推荐四阶段路线，每阶段都有独立价值：

先做可见性再谈隔离：没有流量数据就写策略，等于蒙眼做手术。阶段 1 只读采集，零风险却收益巨大。

5.2 遗留系统兼容

最难的是那些不支持 mTLS、无法改造的老系统。三种折中方案：

方案一：代理包裹（推荐）

在遗留系统前面放一个能理解 mTLS 的代理，由代理完成身份验证后转发明文给老系统：

新服务 ──mTLS──→ [sidecar 代理] ──明文──→ 遗留系统（仅监听 localhost）

代理与遗留系统同机部署，老系统只监听 127.0.0.1，外部无法绕过代理直连。这样零信任边界前移到了代理，遗留系统本身无需改动。

方案二：身份网关

对完全无法部署代理的系统（如商业闭源软件），在它前面放一个身份网关做集中认证与审计，接受"最后一跳是明文"的折中，但要求网络层强隔离。

方案三：绞杀者替换

对既无法代理又无法网关化的系统，用 绞杀者模式 逐步替换——先在旁边建新实现，按功能切流，最终下线老系统。

5.3 兼容期的信任降级

迁移期间必然存在"半零信任"状态。关键是显式标注并收敛：

# 遗留系统登记表：每个未纳管系统都要有负责人与下线期限
legacy_exceptions:
  - system: legacy-billing
    reason: "商业闭源，无法部署代理"
    compensating_control: "独立 VLAN + 网关认证 + 全量审计"
    owner: billing-team
    target_date: 2026-12-31

零信任的例外必须像技术债一样被登记、跟踪与偿还，其中身份与访问管理的细节可进一步参考 身份与访问管理中的零信任实践 。

这些例外应当持续下降，并有看板跟踪。例外清单变成永久清单，就等于零信任项目失败。

6. 踩坑清单

7. 总结

零信任落地的核心不是产品选型，而是把信任决策从"网络位置"迁移到"身份 + 上下文"，并让这个决策每次访问都重新执行。推进顺序建议：

1. 可见性先行：采集流量、盘点资产、梳理身份，零风险起步。
2. 身份化打底：用户 SSO、设备证书、工作负载 SVID，三者齐备。
3. 微隔离收敛：观测生成策略 → 人工复核 → 默认拒绝 → 持续回收权限。
4. 持续验证闭环：风险评分驱动 allow/step_up/deny，异常即时响应。

遗留系统不是零信任的敌人，只要用代理包裹、身份网关或绞杀者替换给出明确路径，并把兼容例外纳入带期限的管理，迁移就能稳步推进而不是半途而废。