零信任架构下的云原生安全实战：从BeyondCorp到微隔离与持续身份验证

安全范式的根本转变

传统城堡-护城河安全模型在网络边界日益模糊的今天已彻底失效。远程办公、多云部署、容器化和微服务让「内网可信」的假设不再成立。零信任（Zero Trust）提出了核心原则：永不信任，始终验证——无论请求来自内网还是外网，每次访问都需身份验证、设备健康检查和最小权限授权。本文从架构原理到实战落地方案，解析零信任如何重塑云原生安全。

从边界模型到BeyondCorp：Google的零信任实践

2010年遭受极光行动(Aurora Attack)后，Google启动了BeyondCorp项目——废除VPN、取消特权内网，将所有内部应用视为在公共互联网上运行。核心原则：访问策略基于用户和设备身份而非网络位置；所有通信必须TLS加密；所有访问记录可审计。BeyondCorp的实现依赖三个核心组件：设备清单(Device Inventory)服务持续收集设备证书、OS版本、补丁状态；信任推断引擎(Trust Inference)基于设备状态和设备信任等级动态赋值；访问控制引擎(Access Control Engine)根据信任等级决定资源访问权限。

零信任架构的NIST SP 800-207模型

NIST SP 800-207标准定义了零信任架构(ZTA)的三大控制平面：

• 策略引擎(Policy Engine)：基于主体信任评分、资源属性、行为异常检测和外部威胁情报做出访问决策
• 策略管理员(Policy Administrator)：建立或关闭主体与资源之间的通信会话，签发短期访问令牌
• 策略执行点(Policy Enforcement Point)：在资源网关或侧车代理层面执行策略决策，持续监控会话状态

两种主流部署方式：基于设备代理(Agent-based)+微隔离、基于网络/身份感知代理(Identity-aware Proxy)+SDP(软件定义边界)。

服务网格层：mTLS与SPIFFE身份框架

云原生零信任的关键战场在服务间通信层。在Kubernetes集群中，微服务之间通过IP+端口直接通信——一旦攻击者进入集群，即可横向移动。服务网格(Service Mesh)通过两种机制构建零信任通信：

• mTLS双向TLS：每个服务由sidecar代理自动签发X.509证书，双方验证证书建立加密信道，即使底层网络被监听也无法窃听或篡改
• SPIFFE/SPIRE身份框架：为每个工作负载签发加密可验证身份文档(SVID)，实现跨集群、跨云的统一身份命名空间(spiffe://trust-domain/path)

# Istio PeerAuthentication：严格mTLS模式
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT   # 拒绝所有明文通信

# 授权策略：基于ServiceAccount的细粒度访问控制
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payment-service-policy
  namespace: prod
spec:
  selector:
    matchLabels:
      app: payment-service
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/prod/sa/order-service"]
    to:
    - operation:
        methods: ["POST"]
        paths: ["/api/v1/payments"]
    when:
    - key: request.auth.claims[scope]
      values: ["payments:write"]

# 默认拒绝所有入站+允许特定标签通信
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-server-netpol
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-server
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/name: ingress-nginx
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8443
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: redis-cache
    ports:
    - protocol: TCP
      port: 6379
  - to:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53