传统安全模型假设”内网可信,外网危险”——但现实是,一旦攻击者进入内网,横向移动几乎畅通无阻。零信任架构彻底抛弃了这个假设:从不信任,始终验证。
一、零信任原则
1.1 传统安全 vs 零信任
| 维度 | 传统安全(城堡模型) | 零信任 |
|---|---|---|
| 信任基础 | 网络位置(内网=安全) | 身份认证(谁=验证) |
| 边界 | 防火墙为唯一防线 | 无边界,处处验证 |
| 认证 | 一次认证(登录) | 每次请求认证 |
| 授权 | 宽泛(内网全访问) | 最小权限 |
| 假设 | 内网可信 | 内网同样不可信 |
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),所有数据必须加密存储,即使攻击者拿到数据也无法读取
- 持续监控与审计:记录所有访问行为,实时检测异常模式。日志本身也要防篡改(使用区块链或签名日志)
“假设被入侵”不是悲观主义,而是务实的工程思维。2020 年 SolarWinds 供应链攻击中,攻击者在 Orion 软件更新中植入后门,影响了 18000+ 组织——包括拥有强大边界防御的美国政府机构。这证明”城堡模型”在供应链攻击面前不堪一击。
1.3 微分段(Micro-segmentation)
微分段是零信任在网络层面的核心实现。传统网络分段通常只划分几个大区域(DMZ、内网、数据库区),而微分段将控制粒度细化到单个工作负载:
| 维度 | 传统分段 | 微分段 |
|---|---|---|
| 粒度 | 网络区域(/16 子网) | 单个工作负载(Pod/容器) |
| 策略 | 基于 IP/端口 | 基于身份/标签 |
| 实现 | 防火墙规则 | 软件定义(SDN/服务网格) |
| 横向移动 | 区域内自由移动 | 每次通信都需授权 |
二、BeyondCorp
2.1 Google BeyondCorp 模型
BeyondCorp 是 Google 的零信任实践,从 2011 年开始逐步将内部系统从 VPN 模型迁移到零信任模型。其核心思想是:取消 VPN,所有访问都通过身份代理。
| 组件 | 说明 | 密码学技术 |
|---|---|---|
| 身份代理 | 统一认证入口 | OAuth 2.0 + OIDC |
| 访问代理 | 请求转发+授权 | mTLS + JWT |
| 设备信任 | 设备安全状态评估 | 设备证书 |
| 用户信任 | 用户身份验证 | 多因素认证 |
2.2 BeyondCorp 架构详解
BeyondCorp 的架构可以拆解为三层:身份层、策略层、执行层。
身份代理(Identity-Aware Proxy, IAP) 是 BeyondCorp 的核心组件。它的工作方式是:
- 用户发起请求时,IAP 拦截请求
- IAP 将用户重定向到身份提供商(IdP)进行认证
- 认证通过后,IAP 评估访问策略(用户角色、设备状态、请求上下文)
- 策略通过后,IAP 使用服务账号代表用户访问后端应用
- IAP 与后端之间通过 mTLS 保护
apiVersion: v1kind: Servicemetadata: name: my-app annotations: run.googleapis.com/ingress: "internal" # 禁止直接外部访问---apiVersion: v1kind: Policymetadata: name: iap-policyspec: bindings: - role: roles/iap.httpsResourceAccessor members: - "group:engineers@example.com" condition: title: "限制访问时间和设备" expression: | request.time.getHours() >= 9 && request.time.getHours() <= 18 && device.isCorpOwned == true2.3 BeyondCorp vs 传统 VPN
| 维度 | VPN(城堡模型) | BeyondCorp(零信任) |
|---|---|---|
| 访问方式 | 先连 VPN,再访问应用 | 直接访问应用,代理验证 |
| 信任模型 | VPN 内网=可信 | 每次请求独立验证 |
| 用户体验 | 需要启动 VPN 客户端 | 浏览器直接访问 |
| 攻击面 | VPN 网关是单点 | 无单点,分布式代理 |
| 横向移动 | VPN 内可自由移动 | 每个应用独立保护 |
| 审计粒度 | VPN 连接级 | 每次请求级 |
| 第三方访问 | 需要发 VPN 账号 | 只需发应用访问权限 |
BeyondCorp 不是要消灭 VPN,而是要让 VPN 不再是安全边界。Google 内部仍然使用 VPN,但 VPN 连接不再自动获得任何信任——所有访问仍然需要经过身份代理的策略评估。
三、mTLS(双向 TLS)
3.1 mTLS 原理
mTLS 要求客户端和服务器都提供证书:
| 维度 | TLS(单向) | mTLS(双向) |
|---|---|---|
| 客户端认证 | 无 | 证书认证 |
| 适用场景 | 公开服务 | 服务间通信 |
| 证书管理 | 仅服务端 | 双方都需要 |
| 安全等级 | 中 | 高 |
3.2 mTLS 深入:握手流程详解
mTLS 在标准 TLS 握手基础上增加了客户端证书验证环节。以下是完整的 mTLS 握手流程:
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-aimport sslimport 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/v1alpha1kind: ClusterSPIFFEIDmetadata: name: billing-servicespec: 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/v1beta1kind: PeerAuthenticationmetadata: name: defaultspec: mtls: mode: STRICT # 强制 mTLS| 服务网格 | mTLS 实现 | 证书管理 | | | | | | Istio | Envoy sidecar | 自动签发+轮换 | | Linkerd | Proxy sidecar | 自动签发+轮换 | | Consul | Connect sidecar | Vault PKI |
4.2 Istio 零信任架构
Istio 的零信任架构包含三个层次:身份层(mTLS)、策略层(AuthorizationPolicy)、观测层(遥测)。
apiVersion: security.istio.io/v1beta1kind: AuthorizationPolicymetadata: name: billing-service-policy namespace: productionspec: 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: DENY4.3 Linkerd 零信任实践
Linkerd 的零信任实现更加轻量,专注于”简单且安全”:
apiVersion: apps/v1kind: Deploymentmetadata: name: billing-service annotations: linkerd.io/inject: enabled # 注入 Linkerd proxyspec: template: metadata: annotations: linkerd.io/inject: enabled spec: containers: - name: billing image: billing:latestapiVersion: policy.linkerd.io/v1alpha1kind: AuthorizationPolicymetadata: name: billing-authzspec: targetRef: group: "" kind: ServiceAccount name: billing-service requiredAuthenticationRefs: - name: order-service-identity group: "" kind: ServiceAccount4.4 Istio vs Linkerd 零信任对比
| 维度 | Istio | Linkerd |
|---|---|---|
| 代理 | Envoy(功能丰富) | linkerd2-proxy(Rust,轻量) |
| mTLS | 需要配置 PeerAuthentication | 默认启用 |
| 策略粒度 | L3-L7(IP/端口/HTTP 头/路径) | L3-L4 为主 |
| 证书管理 | Citadel + 外部 CA 支持 | 内置 CA + Vault 集成 |
| 性能开销 | 中(Envoy 功能多) | 低(Rust 代理) |
| 学习曲线 | 陡峭 | 平缓 |
| 适用场景 | 大规模、复杂策略 | 中小规模、快速落地 |
选择 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 迁移阶段
零信任不是一步到位的项目,而是一个渐进式的转型过程。以下是推荐的四个阶段:
| 阶段 | 时间 | 关键行动 | 依赖 |
|---|---|---|---|
| 基础认证 | 0-3 月 | SSO + MFA + 设备清单 | 身份提供商 |
| 身份驱动 | 3-9 月 | 身份代理 + RBAC/ABAC | SSO 基础 |
| 微分段 | 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(高风险操作自动触发)
- 自动化响应(异常行为自动锁定)
- 完整审计链(不可篡改的日志)
- 定期红队演练验证零信任有效性
迁移过程中最常见的失败原因是”试图一步到位”。零信任是一个架构转型,不是产品采购。每个阶段都应该有明确的度量指标:阶段 1 看 SSO 覆盖率,阶段 2 看策略命中率,阶段 3 看 mTLS 覆盖率,阶段 4 看异常检测准确率。
七、零信任实现代码示例
7.1 使用 Pomerium 搭建零信任访问代理
Pomerium 是一个开源的身份感知代理,可以快速为内部应用添加零信任访问控制:
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: true7.2 使用 Cilium 实现网络微分段
apiVersion: cilium.io/v2kind: CiliumNetworkPolicymetadata: name: billing-service-policyspec: 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: UDP7.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、MFA | Okta/Azure AD |
| 中级 | 动态授权 | RBAC/ABAC、mTLS | Istio/Linkerd |
| 高级 | 持续验证 | 实时风险评估、自动化响应 | UEBA、SIEM |
| 最高 | 自适应安全 | AI 风险评分、零信任自动化 | ML 驱动策略引擎 |
零信任不是”一步到位”的——从 SSO+MFA 开始,逐步引入 mTLS、动态授权、持续验证。每个阶段都比前一个更安全,但不需要一次性全部实现。
九、总结
上一章理解了JWT 安全实践。
| 维度 | 关键要点 |
|---|---|
| 零信任原则 | 从不信任始终验证、最小权限、假设被入侵 |
| BeyondCorp | Google 零信任实践,身份代理+访问代理,取消 VPN 依赖 |
| mTLS | 双向 TLS,服务间通信认证,证书身份绑定 |
| 服务网格 | Istio/Linkerd 自动 mTLS+证书轮换,L7 策略控制 |
| 微分段 | 细粒度网络隔离,限制横向移动爆炸半径 |
| 迁移路径 | SSO+MFA → 身份代理 → mTLS+微分段 → 持续验证 |
| 实现工具 | Pomerium/Cilium/Smallstep/SPIRE |
支持与分享
如果这篇文章对你有帮助,欢迎支持作者或分享给更多人
部分信息可能已经过时






