killvxk 实施零信任网络访问
适用场景
- 将传统 VPN 远程访问替换为基于身份的访问控制时
- 实施微分段（Micro-Segmentation）以限制云网络内的横向移动时
- 合规要求或安全策略需要采用零信任架构时
- 为云工作负载提供安全访问而无需将其暴露到公共互联网时
- 基于用户身份、设备健康状况和位置构建上下文感知访问策略时
不适用于：完全替代网络安全控制（ZTNA 是防火墙和网络 ACL 的补充而非替代）、保护面向互联网的公共应用（应使用 WAF），或无法实现基于身份认证的 IoT 设备访问场景。
前置条件
- 已启用 MFA 的身份提供商（Entra ID、Okta、Google Workspace）
- 云原生网络能力（AWS PrivateLink、Azure Private Link、GCP IAP）
- 用于设备态势评估的设备管理解决方案（Intune、Jamf、CrowdStrike）
- 服务网格或零信任代理（Cloudflare Access、Zscaler ZPA 或云原生 IAP）
- 用于访问决策和策略执行的集中日志记录
工作流程
步骤 1：为应用访问部署 GCP 身份感知代理（IAP）
配置 IAP，无需 VPN 即可为 Web 应用提供经身份验证的访问。
# 启用 IAP API
gcloud services enable iap.googleapis.com
# 配置 OAuth 同意屏幕
gcloud iap oauth-brands create \
--application_title="Corporate Apps" \
--support_email=security@company.com
# 为 App Engine 应用启用 IAP
gcloud iap web enable \
--resource-type=app-engine \
--oauth2-client-id=CLIENT_ID \
--oauth2-client-secret=CLIENT_SECRET
# 为后端服务（GCE/GKE）启用 IAP
gcloud compute backend-services update BACKEND_SERVICE \
--iap=enabled,oauth2-client-id=CLIENT_ID,oauth2-client-secret=CLIENT_SECRET \
--global
# 设置 IAP 访问策略（谁可以访问）
gcloud iap web add-iam-policy-binding \
--resource-type=app-engine \
--member="group:engineering@company.com" \
--role="roles/iap.httpsResourceAccessor"
# 基于设备和上下文配置访问级别
gcloud access-context-manager levels create corporate-device \
--title="Corporate Managed Device" \
--basic-level-spec=level-spec.yaml \
--policy=POLICY_ID
步骤 2：实施 AWS Verified Access 实现零信任
部署 AWS Verified Access，为内部应用提供基于身份的访问。
# 创建 Verified Access 信任提供程序（OIDC）
aws ec2 create-verified-access-trust-provider \
--trust-provider-type user \
--user-trust-provider-type oidc \
--oidc-options '{
"Issuer": "https://login.microsoftonline.com/TENANT_ID/v2.0",
"AuthorizationEndpoint": "https://login.microsoftonline.com/TENANT_ID/oauth2/v2.0/authorize",
"TokenEndpoint": "https://login.microsoftonline.com/TENANT_ID/oauth2/v2.0/token",
"UserInfoEndpoint": "https://graph.microsoft.com/oidc/userinfo",
"ClientId": "CLIENT_ID",
"ClientSecret": "CLIENT_SECRET",
"Scope": "openid profile email"
}'
# 创建 Verified Access 实例
aws ec2 create-verified-access-instance \
--description "Zero Trust Access Instance"
# 将信任提供程序附加到实例
aws ec2 attach-verified-access-trust-provider \
--verified-access-instance-id vai-INSTANCE_ID \
--verified-access-trust-provider-id vatp-PROVIDER_ID
# 创建带策略的 Verified Access 组
aws ec2 create-verified-access-group \
--verified-access-instance-id vai-INSTANCE_ID \
--policy-document '{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": "*",
"Action": "verified-access:AllowAccess",
"Condition": {
"StringEquals": {
"verified-access:user/groups": "engineering"
}
}
}]
}'
# 为内部应用创建端点
aws ec2 create-verified-access-endpoint \
--verified-access-group-id vag-GROUP_ID \
--endpoint-type load-balancer \
--attachment-type vpc \
--domain-certificate-arn arn:aws:acm:REGION:ACCOUNT:certificate/CERT_ID \
--application-domain app.internal.company.com \
--endpoint-domain-prefix app \
--load-balancer-options '{
"LoadBalancerArn": "arn:aws:elasticloadbalancing:REGION:ACCOUNT:loadbalancer/app/internal-app/xxx",
"Port": 443,
"Protocol": "https",
"SubnetIds": ["subnet-xxx"]
}'
步骤 3：配置 Azure Private Link 和条件访问
设置 Azure Private Link 实现网络隔离，并配置条件访问实现基于身份的控制。
# 为 Azure 服务创建私有端点
az network private-endpoint create \
--name app-private-endpoint \
--resource-group production-rg \
--vnet-name production-vnet \
--subnet private-endpoint-subnet \
--private-connection-resource-id /subscriptions/SUB_ID/resourceGroups/RG/providers/Microsoft.Web/sites/internal-app \
--group-ids sites \
--connection-name app-connection
# 为服务配置私有 DNS 区域
az network private-dns zone create \
--resource-group production-rg \
--name privatelink.azurewebsites.net
az network private-dns link vnet create \
--resource-group production-rg \
--zone-name privatelink.azurewebsites.net \
--name production-link \
--virtual-network production-vnet \
--registration-enabled false
# 创建要求合规设备和 MFA 的条件访问策略
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
$params = @{
DisplayName = "Zero Trust - Require MFA and Compliant Device"
State = "enabled"
Conditions = @{
Applications = @{
IncludeApplications = @("All")
}
Users = @{
IncludeUsers = @("All")
ExcludeGroups = @("BreakGlass-Group-ID")
}
Locations = @{
IncludeLocations = @("All")
ExcludeLocations = @("AllTrusted")
}
}
GrantControls = @{
Operator = "AND"
BuiltInControls = @("mfa", "compliantDevice")
}
SessionControls = @{
SignInFrequency = @{
Value = 4
Type = "hours"
IsEnabled = $true
}
}
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params
步骤 4：使用网络策略实施微分段
部署网络层微分段，以补充基于身份的访问控制。
# AWS：创建微分段安全组
aws ec2 create-security-group \
--group-name web-tier-sg \
--description "Web tier - only HTTPS from ALB" \
--vpc-id vpc-PROD
aws ec2 authorize-security-group-ingress \
--group-id sg-WEB \
--protocol tcp --port 443 \
--source-group sg-ALB
aws ec2 create-security-group \
--group-name app-tier-sg \
--description "App tier - only from web tier"
aws ec2 authorize-security-group-ingress \
--group-id sg-APP \
--protocol tcp --port 8080 \
--source-group sg-WEB
# Kubernetes NetworkPolicy 实现 Pod 级别分段
cat << 'EOF' | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: api-allow-web-only
namespace: production
spec:
podSelector:
matchLabels:
app: api-server
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: web-frontend
ports:
- protocol: TCP
port: 8080
EOF
步骤 5：启用持续验证和日志记录
实施持续信任验证，而非一次性认证。
# 配置 CloudWatch 监控访问决策
aws logs create-log-group --log-group-name /verified-access/access-logs
# 启用 Verified Access 日志记录
aws ec2 modify-verified-access-instance-logging-configuration \
--verified-access-instance-id vai-INSTANCE_ID \
--access-logs '{
"CloudWatchLogs": {
"Enabled": true,
"LogGroup": "/verified-access/access-logs"
}
}'
# 查询被拒绝的访问日志
aws logs start-query \
--log-group-name /verified-access/access-logs \
--start-time $(date -d "24 hours ago" +%s) \
--end-time $(date +%s) \
--query-string '
fields @timestamp, identity.user, http_request.url, decision
| filter decision = "deny"
| sort @timestamp desc
| limit 50
'
核心概念
| 术语 | 定义 |
|---|---|
| 零信任（Zero Trust） | 要求对访问资源的每个人和每台设备进行严格身份验证的安全模型，与网络位置无关 |
| ZTNA | 零信任网络访问，通过提供基于身份感知、上下文的应用访问实现零信任原则的技术 |
| 身份感知代理（Identity-Aware Proxy） | 在允许访问后端应用前验证用户身份和设备上下文的代理服务，替代 VPN 访问 |
| 微分段（Micro-Segmentation） | 在单个工作负载或应用周围创建细粒度安全区域以限制横向移动的网络安全技术 |
| BeyondCorp | Google 的零信任架构实现，将访问控制从网络边界转移到个人用户和设备 |
| 持续验证（Continuous Verification） | 在整个会话中而非仅在认证时持续评估用户身份、设备健康状况和访问上下文 |
工具与系统
- GCP Identity-Aware Proxy：Google 的 BeyondCorp 实现，为 Web 应用和虚拟机提供上下文感知访问
- AWS Verified Access：基于身份和设备态势验证提供应用零信任访问的 AWS 服务
- Azure Conditional Access：Microsoft 的策略引擎，基于用户、设备、位置和风险实施上下文访问控制
- Cloudflare Access：云交付的 ZTNA 解决方案，为内部应用提供身份感知访问
- Zscaler ZPA：企业级 ZTNA 平台，通过基于身份和上下文的应用级访问替代 VPN
常见场景
场景：用零信任访问替代企业 VPN 访问云应用
场景背景：一个拥有 2000 名员工的组织通过传统 VPN 集中器访问 30 多个内部云应用。VPN 性能问题和安全顾虑推动了实施 ZTNA 的决策。
方法：
- 梳理所有通过 VPN 访问的应用并按敏感程度分类
- 为基于 Web 的内部应用部署 GCP IAP 或 AWS Verified Access
- 配置条件访问策略，要求所有应用使用 MFA 和设备合规
- 使用安全组实施微分段，限制应用层级之间的横向移动
- 为敏感应用设置持续验证，每 4 小时重新认证
- 分阶段迁移用户，从低风险应用开始，监控访问日志排查问题
- 所有应用通过 ZTNA 可访问且有完整日志后，停用 VPN
常见陷阱：并非所有应用都支持身份感知代理集成。传统厚客户端应用可能需要基于代理的 ZTNA 解决方案而非代理方式。设备态势评估需要在所有企业设备上部署终端管理解决方案。必须为身份提供商不可用的场景记录应急访问程序。
输出格式
零信任网络访问实施报告
==================================================
组织: Acme Corp
实施日期: 2026-02-23
已迁移应用: 24 / 30
ZTNA 架构:
身份提供商: Microsoft Entra ID
访问代理: AWS Verified Access + GCP IAP
设备管理: Microsoft Intune
MFA: FIDO2 + 认证器应用
访问策略覆盖率:
要求 MFA 的应用: 30 / 30 (100%)
要求合规设备的应用: 24 / 30 (80%)
启用持续验证的应用: 18 / 30 (60%)
有位置限制的应用: 12 / 30 (40%)
安全改进:
VPN 相关事件（之前）: 12 次/月
ZTNA 相关事件（之后）: 2 次/月
检测未授权访问的平均时间: 4 分钟（原来 2 小时）
已消除的横向移动路径: 85%
迁移状态:
第 1 阶段（低风险应用）: 12/12 完成
第 2 阶段（中风险应用）: 12/12 完成
第 3 阶段（高风险应用）: 0/6 进行中
VPN 停用: 计划在第 3 阶段完成后执行