killvxk 在云中实施零信任架构
适用场景
- 从传统边界安全迁移到以身份为中心的访问控制时
- 为远程办公人员消除访问云应用的 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 建立核心原则：永不信任，始终验证。每个访问请求无论来源如何，都必须经过认证、授权和加密。
零信任架构组件:
+-------------------------------------------------------------------+
| 策略决策点 (Policy Decision Point) |
| +-------------------+ +------------------+ +-----------------+ |
| | 身份提供商 | | 设备信任 | | 风险引擎 | |
| | (Okta/Azure AD) | | (Intune/Jamf) | | (持续评估) | |
| +-------------------+ +------------------+ +-----------------+ |
+-------------------------------------------------------------------+
|
+--------------------+
| 策略执行点 |
| (IAP/代理) |
+--------------------+
|
+-------------------+-------------------+
| | |
+----------+ +----------+ +----------+
| 应用 A | | 应用 B | | 应用 C |
| (AWS) | | (Azure) | | (GCP) |
+----------+ +----------+ +----------+
步骤 2：部署身份感知代理
配置身份感知代理（Identity-Aware Proxy，IAP），在请求到达应用之前强制执行基于身份和上下文的访问决策。消除对应用后端的直接网络访问。
# GCP：为后端服务启用身份感知代理
gcloud services enable iap.googleapis.com
# 为 App Engine 应用配置 IAP
gcloud iap web enable --resource-type=app-engine
# 设置 IAP 访问策略，要求特定用户组
gcloud iap web add-iam-policy-binding \
--resource-type=app-engine \
--member="group:engineering@company.com" \
--role="roles/iap.httpsResourceAccessor"
# 创建要求企业设备和 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：配置 AWS Verified 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 条件访问策略（JSON 格式）
{
"displayName": "零信任 - 要求 MFA 和合规设备",
"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：创建没有默认路由的隔离 VPC
aws ec2 create-vpc --cidr-block 10.100.0.0/16 --no-amazon-provided-ipv6-cidr-block
# 创建实现微分段的安全组
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：实施设备信任评估
集成终端验证以在授权访问前评估设备安全态势。要求加密、操作系统补丁和终端保护。
# 使用 BeyondCorp 进行 Google Endpoint Verification
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"]
}
}]
}'
# 将访问级别应用于受 IAP 保护的资源
gcloud iap web set-iam-policy \
--resource-type=backend-services \
--service=web-app-backend \
--condition='expression=accessPolicies/POLICY_ID/accessLevels/managed-device'
步骤 6：通过持续分析进行监控和自适应
部署日志记录和分析工具，监控所有访问决策、检测异常，并根据真实使用模式持续优化零信任策略。
# 将 IAP 访问日志导出到 BigQuery 进行分析
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 日志输出到 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 Conditional Access：策略引擎，为 Azure AD 应用实施基于身份、设备、位置和风险的访问控制
- Zscaler Private Access：零信任网络访问平台，通过基于身份和上下文的应用访问替代 VPN
- Cloudflare Access：零信任代理，通过身份验证和设备态势检查保护内部应用
常见场景
场景：消除远程工程师访问的 VPN 依赖
场景背景：一个组织有 500 名工程师通过 VPN 访问内部工具。VPN 集中器是单点故障，近期的凭据窃取事件表明 VPN 访问赋予了过多的横向移动能力。
方法：
- 梳理通过 VPN 访问的所有内部应用，并按敏感程度分类
- 在每个应用前部署身份感知代理（GCP）或 Verified Access（AWS）
- 配置与企业身份提供商的 OIDC 集成，要求所有访问使用 MFA
- 实施设备信任策略，要求已加密且安装了最新操作系统补丁和终端保护的设备
- 为敏感应用启用持续会话评估，每 4 小时重新认证
- 逐步将团队从 VPN 迁移到 IAP 访问，监控访问失败情况并调整策略
- 完成 100% 迁移并经过 30 天并行运行期后停用 VPN
常见陷阱：未部署设备管理就实施零信任，会阻止使用个人设备的合法用户。重新认证间隔设置过短会因频繁登录提示影响开发人员的工作效率。
输出格式
零信任架构评估报告
===========================================
组织: Acme Corp
云提供商: AWS, Azure, GCP
评估日期: 2025-02-23
成熟度级别: Level 2（高级）- NIST ZTA 成熟度模型
身份支柱:
MFA 实施率: 98% 用户（目标: 100%）
抗钓鱼 MFA: 34%（目标: 80%）
SSO 覆盖率: 87% 应用
条件访问策略: 12 个活跃策略
设备支柱:
MDM 注册率: 92% 企业设备
加密实施率: 95%
操作系统补丁合规率: 78%（30 天窗口）
终端保护: 96%
网络支柱:
VPN 依赖: 剩余 3 个应用（目标: 0）
IAP 保护的应用: 47/50
微分段工作负载: 65%
东西向流量加密: 40%（mTLS 采用率）
应用支柱:
位于零信任代理后的应用: 94%
会话重新认证: 已为 85% 的应用配置
运行时访问日志: 100%
建议:
1. [高] 将剩余 3 个 VPN 依赖应用迁移到 IAP
2. [高] 在 6 个月内将抗钓鱼 MFA 提升至 80%
3. [中] 将微分段扩展到剩余 35% 的工作负载
4. [中] 部署服务网格实现东西向 mTLS 加密