mobile wallpaper 1mobile wallpaper 2mobile wallpaper 3mobile wallpaper 4
4064 字
11 分钟
零信任架构
2026-04-06

传统安全模型假设”内网可信,外网危险”——但现实是,一旦攻击者进入内网,横向移动几乎畅通无阻。零信任架构彻底抛弃了这个假设:从不信任,始终验证。

一、零信任原则#

1.1 传统安全 vs 零信任#

维度传统安全(城堡模型)零信任
信任基础网络位置(内网=安全)身份认证(谁=验证)
边界防火墙为唯一防线无边界,处处验证
认证一次认证(登录)每次请求认证
授权宽泛(内网全访问)最小权限
假设内网可信内网同样不可信
graph TB subgraph "城堡模型" FW["防火墙"] --> INT["内网<br/>(信任区域)"] INT --> APP["应用"] Note1["一旦进入内网<br/>即可自由访问"] end subgraph "零信任模型" USER["用户/服务"] --> PEP["策略执行点<br/>(每次验证)"] PEP --> PDP["策略决策点<br/>(动态授权)"] PDP --> APP2["应用"] Note2["每次请求<br/>都需要认证和授权"] end

1.2 零信任三大原则#

原则说明密码学支撑
从不信任,始终验证每次访问都需要认证mTLS、JWT、OAuth
最小权限只授予必要的权限RBAC/ABAC
假设被入侵设计上假设网络已被入侵加密、签名、审计

原则一:从不信任,始终验证(Never Trust, Always Verify)#

这条原则彻底否定了”内网即安全区”的假设。在零信任架构中,不管请求来自内网还是外网,都必须经过完整的身份验证和授权检查。具体来说:

  • 不信任网络位置:即使请求来自公司内网 IP 段,也不能自动放行。攻击者一旦突破边界,内网横向移动几乎没有阻力——这正是 2013 年 Target 数据泄露的教训:攻击者通过 HVAC 供应商的 VPN 凭据进入内网,随后自由移动到 POS 系统
  • 不信任设备状态:即使设备曾经通过验证,也不代表当前安全。设备可能已经丢失、被恶意软件感染、或者系统补丁过期。每次访问都需要重新评估设备信任等级
  • 不信任用户身份:即使通过了 SSO 登录,也不意味着可以访问所有资源。每次请求都需要根据上下文(时间、地点、设备、行为模式)动态评估
def evaluate_access(request):
signals = {
'user_identity': verify_identity(request.user), # 用户身份
'device_trust': assess_device(request.device), # 设备信任
'network_context': evaluate_network(request.source), # 网络上下文
'resource_sensitivity': classify_resource(request.resource), # 资源敏感度
'behavior_anomaly': detect_anomaly(request.user, request.action), # 行为异常
}
risk_score = calculate_risk(signals)
if risk_score < LOW_THRESHOLD:
return allow_access(request.resource, privileges='read')
elif risk_score < MEDIUM_THRESHOLD:
return require_mfa_then_allow(request.resource, privileges='limited')
else:
return deny_access(reason='risk_too_high')

原则二:最小权限(Least Privilege)#

最小权限原则要求每个实体(用户、服务、设备)只拥有完成其任务所需的最小权限集合。这不仅仅是”少给权限”,而是一套系统性的权限管理方法:

  • RBAC(基于角色的访问控制):将权限绑定到角色而非个人。例如”只读分析师”角色只能查询数据,不能修改
  • ABAC(基于属性的访问控制):根据多个属性动态决定权限。例如”工作时间内、从公司设备、访问低敏感数据”允许读写,“非工作时间、从个人设备”只允许只读
  • JIT(Just-In-Time 权限):临时授予高权限,过期自动回收。例如运维人员需要生产环境访问权时,申请 2 小时的临时权限
policy = {
"resource": "customer_pii_db",
"rules": [
{
"effect": "ALLOW",
"action": ["read"],
"conditions": {
"user.role": "analyst",
"device.compliant": True,
"time.hour": {"between": [9, 18]},
"network.location": "corporate"
}
},
{
"effect": "ALLOW",
"action": ["read", "write"],
"conditions": {
"user.role": "data_steward",
"device.compliant": True,
"mfa.verified": True,
"request.justification": "required"
}
},
{
"effect": "DENY",
"action": ["export", "bulk_read"],
"conditions": {
"behavior.anomaly_score": {">": 0.7}
}
}
]
}

原则三:假设被入侵(Assume Breach)#

这条原则要求我们承认一个现实:不管防御多严密,攻击者总有可能找到突破口。因此系统设计必须假设攻击者已经在网络内部:

  • 微分段(Micro-segmentation):将网络划分为极小的安全区域,每个区域都有独立的访问控制。即使攻击者攻破一个区域,也无法横向移动到其他区域
  • 加密一切:所有通信必须加密(mTLS),所有数据必须加密存储,即使攻击者拿到数据也无法读取
  • 持续监控与审计:记录所有访问行为,实时检测异常模式。日志本身也要防篡改(使用区块链或签名日志)
Warning

“假设被入侵”不是悲观主义,而是务实的工程思维。2020 年 SolarWinds 供应链攻击中,攻击者在 Orion 软件更新中植入后门,影响了 18000+ 组织——包括拥有强大边界防御的美国政府机构。这证明”城堡模型”在供应链攻击面前不堪一击。

1.3 微分段(Micro-segmentation)#

微分段是零信任在网络层面的核心实现。传统网络分段通常只划分几个大区域(DMZ、内网、数据库区),而微分段将控制粒度细化到单个工作负载:

维度传统分段微分段
粒度网络区域(/16 子网)单个工作负载(Pod/容器)
策略基于 IP/端口基于身份/标签
实现防火墙规则软件定义(SDN/服务网格)
横向移动区域内自由移动每次通信都需授权
graph TB subgraph "传统分段" FW["防火墙"] --> DMZ["DMZ 区<br/>(Web 服务器)"] FW --> INTERNAL["内网区<br/>(所有内部服务)"] INTERNAL --> DB["数据库"] NOTE1["内网区内自由通信<br/>攻击者可横向移动"] end subgraph "微分段" W1["Web 服务 A"] -->|"允许 HTTP"| APP1["应用服务 A"] W2["Web 服务 B"] -->|"允许 HTTP"| APP2["应用服务 B"] APP1 -->|"允许 TCP:5432"| DB1["数据库 A"] APP2 -->|"允许 TCP:5432"| DB2["数据库 B"] APP1 -.-x|"拒绝"| DB2 APP2 -.-x|"拒绝"| DB1 NOTE2["每个连接都需要<br/>显式授权"] end

二、BeyondCorp#

2.1 Google BeyondCorp 模型#

BeyondCorp 是 Google 的零信任实践,从 2011 年开始逐步将内部系统从 VPN 模型迁移到零信任模型。其核心思想是:取消 VPN,所有访问都通过身份代理

组件说明密码学技术
身份代理统一认证入口OAuth 2.0 + OIDC
访问代理请求转发+授权mTLS + JWT
设备信任设备安全状态评估设备证书
用户信任用户身份验证多因素认证
graph LR USER["用户"] --> IDP["身份提供商<br/>(Okta/Google)"] IDP --> PROXY["访问代理<br/>(BeyondCorp)"] PROXY -->|"mTLS + JWT"| APP["应用服务"] PROXY -->|"策略检查"| PDP["策略引擎"]

2.2 BeyondCorp 架构详解#

BeyondCorp 的架构可以拆解为三层:身份层、策略层、执行层

graph TB subgraph "身份层" USER["用户"] --> SSO["SSO<br/>(SAML/OIDC)"] DEVICE["设备"] --> CERT["设备证书<br/>(X.509)"] SSO --> IDENTITY["统一身份"] CERT --> IDENTITY end subgraph "策略层" IDENTITY --> PDP["策略决策点<br/>(Access Engine)"] PDP -->|"评估"| RULES["访问规则<br/>(用户+设备+上下文)"] RULES -->|"决策"| DECISION["允许/拒绝/需MFA"] end subgraph "执行层" DECISION --> PEP["策略执行点<br/>(Access Proxy)"] PEP -->|"mTLS"| APP["应用服务"] PEP -->|"日志"| AUDIT["审计系统"] end

身份代理(Identity-Aware Proxy, IAP) 是 BeyondCorp 的核心组件。它的工作方式是:

  1. 用户发起请求时,IAP 拦截请求
  2. IAP 将用户重定向到身份提供商(IdP)进行认证
  3. 认证通过后,IAP 评估访问策略(用户角色、设备状态、请求上下文)
  4. 策略通过后,IAP 使用服务账号代表用户访问后端应用
  5. IAP 与后端之间通过 mTLS 保护
apiVersion: v1
kind: Service
metadata:
name: my-app
annotations:
run.googleapis.com/ingress: "internal" # 禁止直接外部访问
---
apiVersion: v1
kind: Policy
metadata:
name: iap-policy
spec:
bindings:
- role: roles/iap.httpsResourceAccessor
members:
- "group:engineers@example.com"
condition:
title: "限制访问时间和设备"
expression: |
request.time.getHours() >= 9 &&
request.time.getHours() <= 18 &&
device.isCorpOwned == true

2.3 BeyondCorp vs 传统 VPN#

维度VPN(城堡模型)BeyondCorp(零信任)
访问方式先连 VPN,再访问应用直接访问应用,代理验证
信任模型VPN 内网=可信每次请求独立验证
用户体验需要启动 VPN 客户端浏览器直接访问
攻击面VPN 网关是单点无单点,分布式代理
横向移动VPN 内可自由移动每个应用独立保护
审计粒度VPN 连接级每次请求级
第三方访问需要发 VPN 账号只需发应用访问权限
Note

BeyondCorp 不是要消灭 VPN,而是要让 VPN 不再是安全边界。Google 内部仍然使用 VPN,但 VPN 连接不再自动获得任何信任——所有访问仍然需要经过身份代理的策略评估。

三、mTLS(双向 TLS)#

3.1 mTLS 原理#

mTLS 要求客户端和服务器都提供证书:

sequenceDiagram participant C as Client (服务 A) participant S as Server (服务 B) C->>S: ClientHello + 客户端证书 S->>C: ServerHello + 服务器证书 S->>C: 验证客户端证书 C->>S: 验证服务器证书 Note over C,S: 双方都验证对方身份 C->>S: 加密通信
维度TLS(单向)mTLS(双向)
客户端认证证书认证
适用场景公开服务服务间通信
证书管理仅服务端双方都需要
安全等级

3.2 mTLS 深入:握手流程详解#

mTLS 在标准 TLS 握手基础上增加了客户端证书验证环节。以下是完整的 mTLS 握手流程:

sequenceDiagram participant C as Client participant CA as CA (证书颁发机构) participant S as Server Note over C,S: 阶段一:证书交换 C->>S: ClientHello<br/>(支持的密码套件、TLS 版本) S->>C: ServerHello + CertificateRequest<br/>(服务器证书 + 请求客户端证书) C->>S: Certificate<br/>(客户端证书) Note over S: 验证客户端证书链<br/>→ OCSP/CRL 检查 Note over C,S: 阶段二:密钥交换 C->>S: ClientKeyExchange<br/>(ECDHE 参数) S->>C: ServerKeyExchange<br/>(ECDHE 参数) C->>S: CertificateVerify<br/>(用客户端私钥签名握手消息) Note over S: 验证签名<br/>→ 确认客户端拥有私钥 Note over C,S: 阶段三:建立加密通道 C->>S: ChangeCipherSpec + Finished S->>C: ChangeCipherSpec + Finished Note over C,S: 双向认证完成<br/>开始加密通信

mTLS 的关键安全属性:

  • 双向身份验证:服务器验证客户端证书,客户端验证服务器证书。攻击者即使能中间人攻击,也无法伪造有效的客户端证书
  • 证书绑定身份:每个服务的证书包含其身份信息(SPIFFE ID、SAN),策略引擎可以基于证书身份做细粒度授权
  • 前向安全:使用 ECDHE 密钥交换,即使长期私钥泄露,历史通信也无法解密

3.3 mTLS 证书管理实践#

mTLS 的最大挑战不是握手本身,而是证书的生命周期管理——如何自动签发、分发、轮换和撤销证书。

cfssl gencert -initca ca-csr.json | cfssljson -bare ca
cat > ca-config.json << 'EOF'
{
"signing": {
"default": {
"expiry": "720h"
},
"profiles": {
"server": {
"usages": ["signing", "key encipherment", "server auth"],
"expiry": "720h"
},
"client": {
"usages": ["signing", "key encipherment", "client auth"],
"expiry": "720h"
},
"peer": {
"usages": ["signing", "key encipherment", "server auth", "client auth"],
"expiry": "720h"
}
}
}
}
EOF
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
-config=ca-config.json -profile=server \
server-csr.json | cfssljson -bare server
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
-config=ca-config.json -profile=client \
client-csr.json | cfssljson -bare client
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
-config=ca-config.json -profile=peer \
-hostname="service-a,service-a.default.svc.cluster.local" \
peer-csr.json | cfssljson -bare service-a
import ssl
import http.client
def create_mtls_connection(host, port, certfile, keyfile, cafile):
"""创建 mTLS 连接"""
context = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
context.load_cert_chain(certfile=certfile, keyfile=keyfile)
context.load_verify_locations(cafile=cafile)
context.verify_mode = ssl.CERT_REQUIRED
context.minimum_version = ssl.TLSVersion.TLSv1_3
conn = http.client.HTTPSConnection(
host, port, context=context
)
return conn
conn = create_mtls_connection(
host='api.internal.example.com',
port=8443,
certfile='/etc/certs/client.pem',
keyfile='/etc/certs/client-key.pem',
cafile='/etc/certs/ca.pem'
)
conn.request('GET', '/api/v1/data')
response = conn.getresponse()
print(response.status, response.read().decode())

3.4 SPIFFE:服务身份标准#

在 mTLS 中,证书不仅是加密工具,更是服务身份的载体。SPIFFE(Secure Production Identity Framework for Everyone)为服务身份定义了统一标准:

  • SPIFFE ID:服务的全局唯一标识符,格式为 spiffe://<trust domain>/<workload identifier>,例如 spiffe://example.com/billing-service
  • SVID(SPIFFE Verifiable Identity Document):将 SPIFFE ID 编码到 X.509 证书的 SAN(Subject Alternative Name)URI 字段中
  • Trust Bundle:信任域的根证书,用于验证 SVID
apiVersion: spire.spiffe.io/v1alpha1
kind: ClusterSPIFFEID
metadata:
name: billing-service
spec:
className: spire-server
spiffeIDTemplate: "spiffe://example.com/{{ .PodMeta.Namespace }}/{{ .PodMeta.Labels.app }}"
podSelector:
matchLabels:
app: billing-service
federatesWith:
- "spiffe://partner.example.com"
ttl: 3600 # 证书有效期 1 小时,自动轮换
维度传统服务身份SPIFFE 身份
标识方式IP 地址 / 服务名全局唯一 SPIFFE ID
信任基础网络位置X.509 SVID 证书
跨域信任手动配置联邦信任域
生命周期静态自动签发+轮换
审计IP 日志身份日志

四、服务网格零信任#

4.1 服务网格中的 mTLS#

服务网格(Service Mesh)是零信任架构在微服务场景下的最佳实践载体。它通过 Sidecar 代理自动为所有服务间通信启用 mTLS,开发者无需修改代码。

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
spec:
mtls:
mode: STRICT # 强制 mTLS

| 服务网格 | mTLS 实现 | 证书管理 | | | | | | Istio | Envoy sidecar | 自动签发+轮换 | | Linkerd | Proxy sidecar | 自动签发+轮换 | | Consul | Connect sidecar | Vault PKI |

4.2 Istio 零信任架构#

Istio 的零信任架构包含三个层次:身份层(mTLS)、策略层(AuthorizationPolicy)、观测层(遥测)

graph TB subgraph "Istio 零信任架构" subgraph "身份层" CITADEL["Citadel<br/>(CA/证书签发)"] CITADEL -->|"签发 SVID"| SIDE_A["Sidecar A"] CITADEL -->|"签发 SVID"| SIDE_B["Sidecar B"] end subgraph "策略层" AUTH_POLICY["AuthorizationPolicy<br/>(L7 访问控制)"] PEER_POLICY["PeerAuthentication<br/>(mTLS 模式)"] REQUEST_AUTH["RequestAuthentication<br/>(JWT 验证)"] end subgraph "执行层" SIDE_A -->|"mTLS"| SIDE_B SIDE_A -->|"策略检查"| ENVOY["Envoy Filter"] ENVOY -->|"允许/拒绝"| APP_B["应用 B"] end end
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: billing-service-policy
namespace: production
spec:
selector:
matchLabels:
app: billing-service
rules:
- from:
- source:
principals: ["cluster.local/ns/production/sa/order-service"]
namespaces: ["production"]
to:
- operation:
methods: ["GET", "POST"]
paths: ["/api/v1/billing/*"]
when:
- key: request.headers[x-time-window]
values: ["business-hours"]
- {}
action: DENY

4.3 Linkerd 零信任实践#

Linkerd 的零信任实现更加轻量,专注于”简单且安全”:

apiVersion: apps/v1
kind: Deployment
metadata:
name: billing-service
annotations:
linkerd.io/inject: enabled # 注入 Linkerd proxy
spec:
template:
metadata:
annotations:
linkerd.io/inject: enabled
spec:
containers:
- name: billing
image: billing:latest
apiVersion: policy.linkerd.io/v1alpha1
kind: AuthorizationPolicy
metadata:
name: billing-authz
spec:
targetRef:
group: ""
kind: ServiceAccount
name: billing-service
requiredAuthenticationRefs:
- name: order-service-identity
group: ""
kind: ServiceAccount

4.4 Istio vs Linkerd 零信任对比#

维度IstioLinkerd
代理Envoy(功能丰富)linkerd2-proxy(Rust,轻量)
mTLS需要配置 PeerAuthentication默认启用
策略粒度L3-L7(IP/端口/HTTP 头/路径)L3-L4 为主
证书管理Citadel + 外部 CA 支持内置 CA + Vault 集成
性能开销中(Envoy 功能多)低(Rust 代理)
学习曲线陡峭平缓
适用场景大规模、复杂策略中小规模、快速落地
Tip

选择 Istio 还是 Linkerd?如果你的团队已经有 Kubernetes 运维经验,且需要 L7 级别的细粒度策略控制,选 Istio。如果你追求快速落地、低运维开销,且 L4 级别的访问控制已经够用,选 Linkerd。两者都提供自动 mTLS,这是零信任的基础。

五、零信任与边界安全对比#

5.1 攻击场景对比#

攻击场景城堡模型防御零信任防御
外部攻击者突破边界内网自由移动每个服务独立认证
内部人员恶意操作内网权限过大最小权限+审计
供应链攻击供应商权限过大JIT 权限+行为监控
凭据泄露凭据=内网通行证MFA+设备信任+行为分析
横向移动内网无隔离微分段+mTLS
零日漏洞补丁前无防护微分段限制爆炸半径

5.2 真实案例分析#

案例 1:Target 数据泄露(2013)

攻击路径:HVAC 供应商 VPN → 内网 → POS 系统 → 4000 万信用卡号

在零信任架构下:

  • HVAC 供应商只能访问 HVAC 管理系统(最小权限)
  • HVAC 管理系统与 POS 系统之间有微分段隔离
  • 访问 POS 系统需要额外的 MFA 和设备信任验证
  • 异常的数据导出行为会被实时检测

案例 2:SolarWinds 供应链攻击(2020)

攻击路径:Orion 更新植入后门 → 18000+ 组织内网 → 横向移动到邮件系统

在零信任架构下:

  • 软件更新需要代码签名验证(供应链信任)
  • 内部服务间通信使用 mTLS,后门无法伪造身份
  • 异常的网络连接模式(C2 通信)会被行为分析检测
  • 数据外泄需要经过身份代理,异常大流量会被拦截

六、零信任迁移路径#

6.1 迁移阶段#

零信任不是一步到位的项目,而是一个渐进式的转型过程。以下是推荐的四个阶段:

graph LR subgraph "阶段 1:基础认证" S1A["SSO 部署"] --> S1B["MFA 启用"] S1B --> S1C["设备清单"] end subgraph "阶段 2:身份驱动" S2A["身份代理"] --> S2B["RBAC/ABAC"] S2B --> S2C["设备信任评估"] end subgraph "阶段 3:微分段" S3A["服务网格 mTLS"] --> S3B["网络微分段"] S3B --> S3C["L7 策略"] end subgraph "阶段 4:持续验证" S4A["实时风险评估"] --> S4B["自适应访问"] S4B --> S4C["自动化响应"] end S1C --> S2A S2C --> S3A S3C --> S4A
阶段时间关键行动依赖
基础认证0-3 月SSO + MFA + 设备清单身份提供商
身份驱动3-9 月身份代理 + RBAC/ABACSSO 基础
微分段6-18 月服务网格 + mTLS + 网络分段容器化/微服务
持续验证12-24 月实时风险 + 自适应 + 自动化前三阶段基础

6.2 迁移检查清单#

每个阶段的完成标准:

阶段 1:基础认证

  • 所有应用接入 SSO(SAML/OIDC)
  • 所有用户启用 MFA(TOTP/WebAuthn)
  • 完成设备资产清单
  • 禁用 VPN 直接访问(或限制 VPN 权限)
  • 密码策略升级(禁止弱密码、启用密码管理器)

阶段 2:身份驱动

  • 部署身份代理(IAP/Pomerium/Cloudflare Access)
  • 实施最小权限 RBAC 模型
  • 高敏感操作启用 ABAC 策略
  • 设备信任评估(MDM 合规检查)
  • 第三方访问通过身份代理(不再发 VPN 账号)

阶段 3:微分段

  • 服务间通信启用 mTLS(Istio/Linkerd)
  • 网络层微分段(Cilium/Calico 网络策略)
  • 数据库访问限制(只允许特定服务账户)
  • L7 级别授权策略(HTTP 方法/路径级别)
  • 内部 PKI 搭建完成(cfssl/Smallstep/HashiCorp Vault)

阶段 4:持续验证

  • 实时用户行为分析(UEBA)
  • 自适应 MFA(高风险操作自动触发)
  • 自动化响应(异常行为自动锁定)
  • 完整审计链(不可篡改的日志)
  • 定期红队演练验证零信任有效性
Warning

迁移过程中最常见的失败原因是”试图一步到位”。零信任是一个架构转型,不是产品采购。每个阶段都应该有明确的度量指标:阶段 1 看 SSO 覆盖率,阶段 2 看策略命中率,阶段 3 看 mTLS 覆盖率,阶段 4 看异常检测准确率。

七、零信任实现代码示例#

7.1 使用 Pomerium 搭建零信任访问代理#

Pomerium 是一个开源的身份感知代理,可以快速为内部应用添加零信任访问控制:

config.yaml
authenticate_service_url: https://authenticate.example.com
idp:
provider: google
client_id: "YOUR_CLIENT_ID"
client_secret: "YOUR_CLIENT_SECRET"
routes:
- from: https://grafana.example.com
to: http://grafana.internal:3000
allowed_idp_claims:
groups:
- "engineers@example.com"
policy:
- allow:
or:
- authenticated_user:
groups:
- "engineers@example.com"
- from: https://admin.example.com
to: http://admin.internal:8080
allowed_idp_claims:
groups:
- "admins@example.com"
policy:
- allow:
or:
- authenticated_user:
groups:
- "admins@example.com"
- require_mfa: true

7.2 使用 Cilium 实现网络微分段#

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: billing-service-policy
spec:
endpointSelector:
matchLabels:
app: billing-service
ingress:
- fromEndpoints:
- matchLabels:
app: order-service
toPorts:
- ports:
- port: "8443"
protocol: TCP
rules:
http:
- method: GET
path: "/api/v1/billing/.*"
- method: POST
path: "/api/v1/billing/charge"
- fromEndpoints:
- matchLabels:
app: prometheus
toPorts:
- ports:
- port: "9090"
protocol: TCP
egress:
- toEndpoints:
- matchLabels:
app: postgres-billing
toPorts:
- ports:
- port: "5432"
protocol: TCP
- toEndpoints:
- matchLabels:
k8s:io.k8s.pod.namespace: kube-system
k8s-app: kube-dns
toPorts:
- ports:
- port: "53"
protocol: UDP

7.3 使用 Smallstep 自动化证书管理#

step ca init --name="Internal CA" --provisioner="admin@example.com" \
--dns="ca.example.com" --address=":443" --deployment-type=standalone
step ca certificate "billing.internal.example.com" billing.pem billing-key.pem \
--provisioner="admin@example.com" --not-after=24h
step ca renew billing.pem billing-key.pem --daemon --renew-before=8h
step mtls client billing.internal.example.com:8443 \
--cacert root_ca.pem \
--cert billing.pem \
--key billing-key.pem \
--server-name billing.internal.example.com

八、零信任成熟度模型#

级别说明关键能力典型技术
初级基础认证SSO、MFAOkta/Azure AD
中级动态授权RBAC/ABAC、mTLSIstio/Linkerd
高级持续验证实时风险评估、自动化响应UEBA、SIEM
最高自适应安全AI 风险评分、零信任自动化ML 驱动策略引擎
Tip

零信任不是”一步到位”的——从 SSO+MFA 开始,逐步引入 mTLS、动态授权、持续验证。每个阶段都比前一个更安全,但不需要一次性全部实现。

九、总结#

上一章理解了JWT 安全实践。

维度关键要点
零信任原则从不信任始终验证、最小权限、假设被入侵
BeyondCorpGoogle 零信任实践,身份代理+访问代理,取消 VPN 依赖
mTLS双向 TLS,服务间通信认证,证书身份绑定
服务网格Istio/Linkerd 自动 mTLS+证书轮换,L7 策略控制
微分段细粒度网络隔离,限制横向移动爆炸半径
迁移路径SSO+MFA → 身份代理 → mTLS+微分段 → 持续验证
实现工具Pomerium/Cilium/Smallstep/SPIRE

支持与分享

如果这篇文章对你有帮助,欢迎支持作者或分享给更多人

零信任架构
https://blog.souloss.com/posts/cryptography/cryptography-zero-trust-architecture/
作者
Souloss
发布于
2026-04-06
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时