implementing-zero-trust-in-cloud

在云中实施零信任

何时使用

• 从传统的基于边界的安全迁移到以身份为中心的访问控制时
• 消除远程员工访问云应用对 VPN 的依赖时
• 对每个访问请求实施持续验证，无论网络位置如何时
• 为多云工作负载设计微隔离策略时
• 法规要求强制采用零信任架构时（联邦指令、NIST 指南）

不要使用于没有更广泛架构变更的简单 VPN 替换、仅用于网络防火墙规则管理（参见 implementing-cloud-network-segmentation），或用于身份提供商初始设置（参见 managing-cloud-identity-with-okta）。

前提条件

• 能够进行 OIDC/SAML 集成的身份提供商（Okta、Azure AD、Google Workspace）
• 用于终端信任评估的设备管理解决方案（Intune、Jamf、Google Endpoint Verification）
• 可通过 HTTPS 访问的云工作负载，具备负载均衡器或反向代理基础设施
• 用于持续监控访问决策和异常检测的 SIEM 平台

工作流

步骤 1：定义零信任原则和架构

遵循 NIST SP 800-207 建立核心原则：永不信任，始终验证。每个访问请求都必须经过身份验证、授权和加密，无论来源如何。

Zero Trust Architecture Components:
+-------------------------------------------------------------------+
|                        Policy Decision Point                       |
|  +-------------------+  +------------------+  +-----------------+ |
|  | Identity Provider |  | Device Trust     |  | Risk Engine     | |
|  | (Okta/Azure AD)   |  | (Intune/Jamf)    |  | (Continuous)    | |
|  +-------------------+  +------------------+  +-----------------+ |
+-------------------------------------------------------------------+
                              |
                    +--------------------+
                    | Policy Enforcement |
                    | Point (IAP/Proxy)  |
                    +--------------------+
                              |
          +-------------------+-------------------+
          |                   |                   |
    +----------+        +----------+        +----------+
    | App A    |        | App B    |        | App C    |
    | (AWS)    |        | (Azure)  |        | (GCP)    |
    +----------+        +----------+        +----------+

步骤 2：部署身份感知代理

配置身份感知代理（IAP），在请求到达应用之前强制执行基于身份和上下文的访问决策。消除对应用后端的直接网络访问。

# GCP: Enable Identity-Aware Proxy for a backend service
gcloud services enable iap.googleapis.com

# Configure IAP for an App Engine application
gcloud iap web enable --resource-type=app-engine

# Set IAP access policy requiring specific user group
gcloud iap web add-iam-policy-binding \
  --resource-type=app-engine \
  --member="group:[email protected]" \
  --role="roles/iap.httpsResourceAccessor"

# Create Access Level requiring corporate device and MFA
gcloud access-context-manager levels create corporate-device \
  --title="Corporate Device with MFA" \
  --basic-level-spec='{
    "conditions": [
      {
        "devicePolicy": {
          "requireScreenlock": true,
          "allowedEncryptionStatuses": ["ENCRYPTED"],
          "osConstraints": [
            {"osType": "DESKTOP_CHROME_OS", "minimumVersion": "100.0"},
            {"osType": "DESKTOP_MAC", "minimumVersion": "12.0"},
            {"osType": "DESKTOP_WINDOWS", "minimumVersion": "10.0.19041"}
          ]
        },
        "requiredAccessLevels": ["accessPolicies/POLICY_ID/accessLevels/require-mfa"]
      }
    ]
  }'

# AWS: Configure AWS Verified Access for zero trust application access
aws ec2 create-verified-access-instance \
  --description "Zero Trust Access Instance"

aws ec2 create-verified-access-trust-provider \
  --trust-provider-type user \
  --user-trust-provider-type oidc \
  --oidc-options '{
    "Issuer": "https://company.okta.com/oauth2/default",
    "AuthorizationEndpoint": "https://company.okta.com/oauth2/default/v1/authorize",
    "TokenEndpoint": "https://company.okta.com/oauth2/default/v1/token",
    "UserInfoEndpoint": "https://company.okta.com/oauth2/default/v1/userinfo",
    "ClientId": "verified-access-client-id",
    "ClientSecret": "verified-access-client-secret",
    "Scope": "openid profile groups"
  }'

步骤 3：实施持续验证

配置实时风险评估，根据身份、设备状态、位置、行为模式和威胁情报信号评估每个访问请求。

# Azure Conditional Access Policy (JSON representation)
{
  "displayName": "Zero Trust - Require MFA and Compliant Device",
  "state": "enabled",
  "conditions": {
    "users": {"includeUsers": ["All"]},
    "applications": {"includeApplications": ["All"]},
    "locations": {
      "includeLocations": ["All"],
      "excludeLocations": ["AllTrusted"]
    },
    "signInRiskLevels": ["medium", "high"],
    "deviceStates": {
      "includeStates": ["All"],
      "excludeStates": ["Compliant", "DomainJoined"]
    }
  },
  "grantControls": {
    "operator": "AND",
    "builtInControls": [
      "mfa",
      "compliantDevice"
    ]
  },
  "sessionControls": {
    "signInFrequency": {"value": 4, "type": "hours"},
    "persistentBrowser": {"mode": "never"}
  }
}

步骤 4：强制执行微隔离

通过将云工作负载分割为隔离区域，并为每条通信路径设置显式允许规则，在网络安全层面应用零信任。

# AWS: Create isolated VPC with no default routes
aws ec2 create-vpc --cidr-block 10.100.0.0/16 --no-amazon-provided-ipv6-cidr-block

# Create security groups implementing micro-segmentation
aws ec2 create-security-group \
  --group-name web-tier-sg \
  --description "Web tier - accepts traffic from ALB only" \
  --vpc-id vpc-abc123

aws ec2 authorize-security-group-ingress \
  --group-id sg-web123 \
  --protocol tcp --port 8080 \
  --source-group sg-alb123

aws ec2 create-security-group \
  --group-name app-tier-sg \
  --description "App tier - accepts traffic from web tier only"

aws ec2 authorize-security-group-ingress \
  --group-id sg-app123 \
  --protocol tcp --port 8443 \
  --source-group sg-web123

步骤 5：实施设备信任评估

集成终端验证，在授予访问权限之前评估设备安全状态。要求加密、操作系统补丁和终端保护。

# Google Endpoint Verification with BeyondCorp
gcloud access-context-manager levels create managed-device \
  --title="Managed and Encrypted Device" \
  --basic-level-spec='{
    "conditions": [{
      "devicePolicy": {
        "requireScreenlock": true,
        "requireAdminApproval": true,
        "allowedEncryptionStatuses": ["ENCRYPTED"],
        "allowedDeviceManagementLevels": ["COMPLETE"]
      }
    }]
  }'

# Apply access level to IAP-protected resource
gcloud iap web set-iam-policy \
  --resource-type=backend-services \
  --service=web-app-backend \
  --condition='expression=accessPolicies/POLICY_ID/accessLevels/managed-device'

步骤 6：通过持续分析进行监控和调整

部署日志记录和分析，监控所有访问决策、检测异常，并根据实际使用模式持续改进零信任策略。

# Export IAP access logs to BigQuery for analysis
gcloud logging sinks create iap-access-logs \
  bigquery.googleapis.com/projects/my-project/datasets/security_logs \
  --log-filter='resource.type="gce_backend_service" AND protoPayload.serviceName="iap.googleapis.com"'

# AWS Verified Access logs to CloudWatch
aws ec2 modify-verified-access-instance-logging-configuration \
  --verified-access-instance-id vai-abc123 \
  --access-logs '{
    "CloudWatchLogs": {"Enabled": true, "LogGroup": "/aws/verified-access/logs"},
    "S3": {"Enabled": true, "BucketName": "verified-access-logs"}
  }'

关键概念

术语	定义
Zero Trust	通过要求对每个访问请求进行持续身份验证、授权和加密来消除隐式信任的安全模型
BeyondCorp	Google 对零信任的实现，将访问控制从网络边界转移到单个用户和设备
Identity-Aware Proxy	在将请求转发到后端应用之前验证用户身份和上下文的反向代理，取代基于 VPN 的访问
Continuous Verification	对每个访问请求实时评估身份、设备状态、位置和行为，而不仅仅是在初始身份验证时
Device Trust	在授予访问权限之前评估终端安全状态，包括加密状态、操作系统版本、补丁级别和 MDM 合规性
NIST SP 800-207	美国国家标准与技术研究院发布的出版物，定义零信任架构原则和部署模型
Access Context Manager	GCP 服务，用于根据设备属性、IP 范围和身份属性定义条件访问策略
AWS Verified Access	AWS 服务，基于身份和设备信任信号提供零信任应用访问，无需 VPN

工具与系统

• Google BeyondCorp Enterprise：端到端零信任平台，包含 Identity-Aware Proxy、Access Context Manager 和 Endpoint Verification
• AWS Verified Access：零信任应用访问服务，可与身份提供商和设备信任服务集成
• Azure 条件访问：策略引擎，为 Azure AD 应用程序强制执行基于身份、设备、位置和风险的访问控制
• Zscaler Private Access：零信任网络访问平台，用基于身份和上下文的应用程序访问取代 VPN
• Cloudflare Access：零信任代理，通过身份验证和设备态势检查保护内部应用程序

常见场景

场景：为远程工程访问消除 VPN

背景：某组织有 500 名工程师通过 VPN 访问内部工具。VPN 集中器是单点故障，而近期的凭据窃取事件表明，VPN 访问会授予过度的横向移动能力。

方法：

1. 清点所有通过 VPN 访问的内部应用程序，并按敏感级别分类
2. 在每个应用程序前部署 Identity-Aware Proxy (GCP) 或 Verified Access (AWS)
3. 配置与企业身份提供商的 OIDC 集成，要求所有访问均使用 MFA
4. 实施设备信任策略，要求使用加密设备，并安装最新的操作系统补丁和端点保护
5. 启用持续会话评估，对敏感应用程序要求每 4 小时重新认证
6. 逐步将团队从 VPN 迁移到 IAP 访问，监控访问失败并调整策略
7. 在 100% 迁移并并行运行 30 天后，停用 VPN

陷阱：在设备管理尚未到位时部署零信任，会阻止使用个人设备的合法用户。将重新认证间隔设置得太短，会因过多的登录提示而影响开发者生产力。

输出格式

Zero Trust Architecture Assessment Report
===========================================
Organization: Acme Corp
Cloud Providers: AWS, Azure, GCP
Assessment Date: 2025-02-23

MATURITY LEVEL: Level 2 (Advanced) - NIST ZTA Maturity Model

IDENTITY PILLAR:
  MFA Enforcement: 98% of users (target: 100%)
  Phishing-Resistant MFA: 34% (target: 80%)
  SSO Coverage: 87% of applications
  Conditional Access Policies: 12 active policies

DEVICE PILLAR:
  MDM Enrollment: 92% of corporate devices
  Encryption Enforcement: 95%
  OS Patch Compliance: 78% (30-day window)
  Endpoint Protection: 96%

NETWORK PILLAR:
  VPN Dependency: 3 applications remaining (target: 0)
  IAP-Protected Applications: 47/50
  Micro-Segmented Workloads: 65%
  East-West Traffic Encryption: 40% (mTLS adoption)

APPLICATION PILLAR:
  Applications Behind Zero Trust Proxy: 94%
  Session Re-Authentication: Configured for 85% of apps
  Runtime Access Logging: 100%

RECOMMENDATIONS:
  1. [HIGH] Migrate remaining 3 VPN-dependent apps to IAP
  2. [HIGH] Increase phishing-resistant MFA to 80% within 6 months
  3. [MEDIUM] Expand micro-segmentation to remaining 35% of workloads
  4. [MEDIUM] Deploy service mesh for east-west mTLS encryption