零信任（Zero Trust）

3 秒看懂

一句话：“永不信任，始终验证”（Never Trust, Always Verify）——不再因为你在公司内网就默认安全，每一次访问都必须经过身份验证、设备检查和最小权限授权。

**类比：**传统安全像小区门禁——进了大门后各家都不锁门；零信任像每道门都要刷卡+人脸识别+确认你有权限进这个房间。

3 分钟产业解释

为什么需要零信任？

传统网络安全遵循”城堡+护城河”模型（Perimeter-Based Security）：企业网络边界设防火墙，内部流量默认可信。这个模型在以下趋势下彻底失效：

零信任的核心转变：网络位置 ≠ 信任依据。无论流量来源是内网还是公网，都必须经过同等强度的验证。

谁提出的？

• 2010 年：Forrester Research 分析师 John Kindervag 首次提出”Zero Trust”概念
• 2020 年 8 月：NIST 发布 SP 800-207《Zero Trust Architecture》，成为事实上的技术框架标准
• 2021 年 5 月：美国白宫发布 Executive Order 14028，要求联邦机构采用零信任架构，标志着零信任从概念进入强制合规阶段
• 2021 年 9 月：CISA 发布零信任成熟度模型 v1.0（2023 年更新至 v2.0）

15 分钟专家深入

零信任不是单一产品，是架构范式

一个关键认知纠偏：零信任不是某个厂商的某个产品，而是一套架构设计原则。厂商提供的是实现这些原则的组件和平台。

NIST SP 800-207 定义的三大核心技术

1. 身份（Identity）——零信任的基石

┌─────────────────────────────────────────┐
│           Identity Provider (IdP)       │
│  (Okta / Azure AD / Ping / CyberArk)   │
├─────────────────────────────────────────┤
│  • 多因素认证 (MFA)                      │
│  • 持续认证 (Continuous Authentication)  │
│  • 基于风险的自适应认证                    │
│  • 身份治理与生命周期管理                  │
└──────────────┬──────────────────────────┘
               │ 身份断言 (SAML/OIDC Token)
               ▼
        ┌──────────────┐
        │  策略决策点   │
        │  (PDP/PE)    │
        └──────────────┘

身份不再只是”用户名+密码”，而是多维属性的实时评估：

• 你是谁（身份）
• 你在用什么设备（设备健康状态）
• 你在哪里（地理/IP 信誉）
• 你在做什么（行为分析）
• 现在是什么时间（上下文）

2. 网络微隔离（Micro-Segmentation）

传统网络:                         零信任网络:
┌──────────────────┐              ┌────┐ ┌────┐ ┌────┐
│                  │              │App1│ │App2│ │App3│
│  信任区 (扁平)    │              │ ██ │ │ ██ │ │ ██ │
│  东西向流量不检查  │              └─┬──┘ └─┬──┘ └─┬──┘
│                  │                │加密   │加密   │加密
└──────────────────┘              ┌─┴──────┴──────┴──┐
                                  │  策略网关/代理     │
                                  │  逐流验证授权      │
                                  └──────────────────┘

• 将网络从”大平面”切割成细粒度的安全区域，每个工作负载（Workload）都有独立的访问策略
• 东西向流量（服务器到服务器）同样需要验证和加密
• 实现方式：SDN、主机代理、服务网格（Service Mesh 如 Istio/Linkerd）

3. 持续评估与自适应访问（Continuous Evaluation）

零信任不是”登录时验证一次就够了”。策略引擎在整个会话过程中持续评估风险信号：

[会话开始] ──→ 初始认证+授权 ──→ 允许访问资源A
                    │
            [持续监控]
                    │
    ┌───────────────┼───────────────┐
    ▼               ▼               ▼
设备合规变化？   行为异常？      地理位置跳变？
(如关闭杀毒)  (如异常大量下载)  (5分钟前北京,现在东京)
    │               │               │
    ▼               ▼               ▼
  降级权限 / 要求重新认证 / 终止会话

零信任架构的核心逻辑组件（NIST 模型）

┌─────────────────────────────────────────────────────────┐
│                    Policy Engine (PE)                    │
│        决策大脑：基于策略+上下文决定允许/拒绝/降级        │
├─────────────────────────────────────────────────────────┤
│                    Policy Administrator (PA)             │
│        执行者：下发指令给 PEP，建立/终止会话通道          │
├─────────────────────────────────────────────────────────┤
│              Policy Enforcement Point (PEP)              │
│        门卫：在资源前拦截所有请求，只放行 PA 授权的流量   │
└─────────────────────────────────────────────────────────┘

  主体(用户/设备) ──→ [PEP] ──询问──→ [PE] ──指令──→ [PA] ──→ [PEP] 放行/拒绝
                                    ▲
                                    │
                              身份源 / 设备态势 /
                              威胁情报 / 行为分析

零信任的五大假设（NIST SP 800-207）

1. 网络始终是敌对的 —— 内网外网没有本质区别
2. 网络上/网络外的攻击始终存在 —— 威胁是常态
3. 网络位置不足以授予信任 —— 在公司 Wi-Fi ≠ 安全
4. 每个用户、设备、网络流都需要认证和授权 —— 无例外
5. 策略必须是动态的 —— 基于尽可能多的数据源实时计算

技术原理（深度）

零信任网络访问（ZTNA）的协议层实现

ZTNA 是零信任在网络访问层面的具体技术实现，主流方案有三类：

方案一：反向代理 / 云代理模式（主流）

用户终端                    云代理节点                   企业应用
┌──────┐    HTTPS/TLS     ┌──────────┐   mTLS/专线    ┌──────┐
│      │ ───────────────→ │ ZTNA GW  │ ────────────→ │      │
│      │    (加密隧道)     │ (如       │  (仅允许授权  │      │
│      │ ←─────────────── │  Zscaler/ │   的微流量)   │      │
│      │                  │  Cloudflare│               │      │
└──────┘                  │  Access)  │               └──────┘
                          └──────────┘
                              │
                    连接前验证:
                    ① 用户身份 (IdP)
                    ② 设备证书+合规状态
                    ③ 上下文风险评分

• 用户不直接连接应用，而是先连接到云代理节点
• 代理节点验证后才建立到后端应用的加密通道
• 应用完全隐藏，不对公网暴露端口/IP（Dark Cloud 效应）
• 代表厂商：Zscaler Private Access (ZPA)、Cloudflare Access、Palo Alto Prisma Access

方案二：SDP（Software-Defined Perimeter）模式

┌────────────┐     单包授权 (SPA)      ┌────────────┐
│ SDP 客户端  │ ──────────────────────→ │ SDP 控制器  │
│            │   (UDP, 含加密Token)     │            │
│            │ ←────────────────────── │ 验证后下发  │
│            │   (授权连接的SGW地址)     │ 连接策略    │
└──────┬─────┘                         └────────────┘
       │                                      │
       │    mTLS 接入                          │ 策略同步
       ▼                                      ▼
┌──────────────┐                      ┌──────────────┐
│ SDP 网关 (SGW)│ ──────→ ──────→    │ 后端应用      │
│ (单端口暴露)  │   最小权限隧道       │              │
└──────────────┘                      └──────────────┘

• 核心机制 SPA（Single Packet Authorization）：客户端发送一个加密的 UDP 包，只有合法包才能”敲开门”让网关开放端口
• 端口默认关闭（不是防火墙规则关闭，是内核层面不响应），端口扫描完全无效
• 代表厂商：Zscaler Private Access、Appgate、Perimeter 81、Akamai（原 Soha）

方案三：基于服务网格的零信任（云原生）

┌──────────────────────────────────────┐
│           Kubernetes Cluster          │
│                                      │
│  ┌──────┐  mTLS  ┌──────┐  mTLS     │
│  │Pod A │◄──────►│Pod B │◄──────►   │
│  │+Sidecar│      │+Sidecar│         │
│  │Proxy  │       │Proxy  │          │
│  └──────┘       └──────┘            │
│       ▲                              │
│       │ mTLS                         │
│  ┌──────┐                            │
│  │Pod C │                            │
│  │+Sidecar│                          │
│  │Proxy  │                           │
│  └──────┘                            │
└──────────────────────────────────────┘
         ▲
    Istio / Linkerd
    控制面下发 mTLS 策略
    + 细粒度 RBAC

• 每个 Pod 注入 Sidecar Proxy（Envoy），所有服务间通信强制 mTLS
• 通过控制面下发细粒度授权策略（如 Service A 只能调用 Service B 的 /api/v1/orders）
• 代表技术：Istio + Envoy、Linkerd、Cilium Service Mesh

设备信任评估的技术栈

零信任要求”设备可信”，这需要终端上部署的代理或 MDM 能力：

技术演进史

2004  ┃ Jericho Forum 提出"去边界化"（De-Perimeterization）概念
      ┃
2010  ┃ Forrester John Kindervag 正式命名 "Zero Trust"
      ┃ 核心主张：网络分段 + 逐流验证
      ┃
2014  ┃ Google BeyondCorp 发布
      ┃ ── 工程实现层面的里程碑：Google 内部将所有应用
      ┃    从 VPN 转向基于设备+身份的代理访问
      ┃
2017  ┃ Gartner CARTA 框架（Continuous Adaptive Risk
      ┃   and Trust Assessment）推动"持续评估"理念
      ┃
2018  ┃ Forrester 零信任扩展（ZTX）框架发布
      ┃ ── 从网络扩展到数据、工作负载、人员、设备、网络、可视化
      ┃
2019  ┃ SDP（Software-Defined Perimeter）被 CSA 采纳为标准
      ┃
2020  ┃ NIST SP 800-207 发布 ★ 里程碑
      ┃ ── 首个权威技术架构标准
      ┃
2021  ┃ 美国 EO 14028 签署 ★ 里程碑
      ┃ ── 联邦机构强制采用零信任
      ┃ CISA 发布零信任成熟度模型 v1.0
      ┃
2022  ┃ DoD（美国国防部）发布零信任战略
      ┃ ── 目标 2027 年前实现全面零信任
      ┃ OMB M-22-09 要求联邦机构零信任路线图
      ┃
2023  ┃ CISA 零信任成熟度模型 v2.0 更新
      ┃ ── 五大支柱：身份 / 设备 / 网络 / 应用与工作负载 / 数据
      ┃ 欧盟 NIS2 指令推动类似理念
      ┃
2024  ┃ 零信任与 AI 安全融合趋势
      ┃ ── AI 驱动的自适应策略 / LLM 应用的零信任接入控制
      ┃ 零信任从合规驱动转向实战驱动

技术路线对比

上下游

上游（零信任的依赖层）

┌─────────────────────────────────────────────────┐
│              身份基础设施 (IdP/IAM)               │
│  Okta / Microsoft Entra ID / Ping / CyberArk    │
├─────────────────────────────────────────────────┤
│              终端安全 (EDR/XDR)                   │
│  CrowdStrike / SentinelOne / Microsoft Defender  │
├─────────────────────────────────────────────────┤
│              证书与密钥管理 (PKI/KMS)             │
│  HashiCorp Vault / AWS KMS / Venafi              │
├─────────────────────────────────────────────────┤
│              网络基础设施 (加密传输)               │
│  TLS 1.3 / WireGuard / mTLS                     │
├─────────────────────────────────────────────────┤
│              云平台 (执行环境)                     │
│  AWS / Azure / GCP / 私有云 K8s                  │
└─────────────────────────────────────────────────┘

中游（零信任核心平台/方案层）

下游（零信任的落地行业/场景）

关键指标

衡量零信任成熟度的维度（参考 CISA 模型）

CISA 零信任成熟度模型的五大支柱

           ┌──────────┐
           │   身份   │
           │ Identity │
           └────┬─────┘
                │
    ┌───────────┼───────────┐
    │           │           │
┌───┴───┐ ┌────┴────┐ ┌────┴────┐
│ 设备  │ │  网络   │ │应用/负载│
│Device │ │Network  │ │  App   │
└───┬───┘ └────┬────┘ └────┬────┘
    │          │           │
    └──────────┼───────────┘
               │
          ┌────┴────┐
          │  数据   │
          │  Data   │
          └─────────┘

每个支柱分四个成熟度级别:
Traditional → Initial → Advanced → Optimal

供需与市场数据

注意：以下市场数据为多家分析机构估算，口径不一致时已标注来源。

市场规模

细分市场结构（定性判断）

• ZTNA/SASE 是增长最快的子领域（远程办公+云迁移双驱动）
• IAM/PAM 是成熟度最高的子领域（身份是零信任基石）
• 微隔离 在金融和政府渗透率较高，其他行业仍在早期
• 联邦/政府 是最大的单一客户群体（强制合规驱动）

关键驱动因素

• EO 14028 等政策合规要求（供给创造需求）
• 远程办公常态化（疫情后不可逆）
• 云支出持续增长（IDC 预测 2024 全球公有云支出超 $8000 亿）
• 勒索软件/供应链攻击事件倒逼

代表公司与资本映射

纯零信任 / 安全平台

中国零信任厂商

投资链条映射

[上游基建]          [中游平台]           [下游需求]
                                    
  IdP/IAM ────→    ZTNA/SASE ────→    联邦/政府
  (Okta)           (Zscaler,          (政策强制)
                    Cloudflare)
  EDR/XDR ────→    微隔离 ─────────→  金融
  (CrowdStrike)    (Illumio)          (合规驱动)
                                    
  PKI/证书 ────→   IAM/PAM ────────→  云原生企业
  (Venafi)         (CyberArk)         (架构天然适配)
                                    
  SD-WAN ──────→   SASE (融合) ────→  中小企业
  (Cisco,Fortinet) (Cato,Netskope)    (All-in-One)

投资逻辑

看多逻辑

1. 政策强制 + 合规刚需：EO 14028 + CISA 成熟度模型 + DoD 战略 = 联邦/军工订单确定性高；NIS2 等欧盟指令扩展全球需求
2. 不可逆的架构迁移：从 VPN 到 ZTNA 是类似从物理服务器到云的范式迁移，一旦迁移不会回退
3. TAM 扩大：零信任融合了 IAM + 网络安全 + 终端安全 + 数据安全，把原来分散的预算统一到平台
4. SASE 合并效应：网络（SD-WAN）+ 安全（SWG/CASB/ZTNA）合一，单价提升 + 客户粘性
5. AI 催化：AI 应用需要更细粒度的访问控制（谁能访问哪个模型/数据集），零信任是天然基础设施

看空/风险

1. 部署复杂度高、周期长：真正的零信任落地需要 1-3 年，很多企业停留在 MFA 阶段就被报告为”已实施零信任”
2. 竞争格局分散：大厂（微软、谷歌、思科）自带零信任能力，纯安全厂商面临平台挤压
3. 估值已高：Zscaler、CrowdStrike 等在 2020-2021 年经历大幅估值扩张，当前 P/S 仍处于高位
4. 经济下行时 IT 安全预算可能被压缩：虽是刚需，但实施类项目（非维护）可能延迟
5. 概念通胀：几乎所有安全厂商都宣称”零信任”，真实差异化难以评估

关键观察指标

• Zscaler / Cloudflare