implementing-zero-trust-network-access

实施零信任网络访问

何时使用

• 当用基于身份的访问控制替代传统的基于 VPN 的远程访问时
• 当实施微隔离以限制云网络内的横向移动时
• 当合规或安全策略要求采用零信任架构时
• 当为云工作负载提供安全访问且不将其暴露于公网时
• 当基于用户身份、设备健康状况和位置构建上下文感知的访问策略时

不要使用作为网络安全控制的完整替代（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 Identity-Aware Proxy (IAP) 以访问应用

配置 IAP，以在不使用 VPN 的情况下提供对 Web 应用的身份验证访问。

# Enable IAP API
gcloud services enable iap.googleapis.com

# Configure OAuth consent screen
gcloud iap oauth-brands create \
  --application_title="Corporate Apps" \
  [email protected]

# Enable IAP on an App Engine application
gcloud iap web enable \
  --resource-type=app-engine \
  --oauth2-client-id=CLIENT_ID \
  --oauth2-client-secret=CLIENT_SECRET

# Enable IAP on a backend service (GCE/GKE)
gcloud compute backend-services update BACKEND_SERVICE \
  --iap=enabled,oauth2-client-id=CLIENT_ID,oauth2-client-secret=CLIENT_SECRET \
  --global

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

# Configure access levels based on device and context
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，以提供对内部应用的基于身份的访问。

# Create a Verified Access trust provider (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"
  }'

# Create a Verified Access instance
aws ec2 create-verified-access-instance \
  --description "Zero Trust Access Instance"

# Attach trust provider to instance
aws ec2 attach-verified-access-trust-provider \
  --verified-access-instance-id vai-INSTANCE_ID \
  --verified-access-trust-provider-id vatp-PROVIDER_ID

# Create a Verified Access group with policy
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"
        }
      }
    }]
  }'

# Create endpoint for an internal application
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 以实现网络隔离，并设置条件访问以实现基于身份的控制。

# Create Private Endpoint for an Azure service
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

# Configure private DNS zone for the service
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

# Create Conditional Access policy requiring compliant device + 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: Create security groups for micro-segmentation
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 for pod-level segmentation
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 步：启用持续验证和日志记录

实施持续信任验证，而不是一次性身份验证。

# Configure CloudWatch to monitor access decisions
aws logs create-log-group --log-group-name /verified-access/access-logs

# Enable Verified Access logging
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"
    }
  }'

# Query access logs for denied requests
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	Zero Trust Network Access，通过提供身份感知、基于上下文的应用程序访问来实施零信任原则的技术
Identity-Aware Proxy	在允许访问后端应用程序之前验证用户身份和设备上下文的代理服务，取代基于 VPN 的访问
Micro-Segmentation	一种网络安全技术，围绕单个工作负载或应用程序创建细粒度的安全区域，以限制横向移动
BeyondCorp	Google 对零信任架构的实施，将访问控制从网络边界转移到单个用户和设备
Continuous Verification	在整个会话期间持续评估用户身份、设备健康状况和访问上下文，而不仅仅在身份验证时

工具与系统

• GCP Identity-Aware Proxy：Google 的 BeyondCorp 实现，提供对 Web 应用和 VM 的上下文感知访问
• AWS Verified Access：AWS 服务，用于基于身份和设备态势验证对应用程序进行零信任访问
• Azure Conditional Access：Microsoft 的策略引擎，用于根据用户、设备、位置和风险实施基于上下文的访问控制
• Cloudflare Access：云交付的 ZTNA 解决方案，提供对内部应用程序的身份感知访问
• Zscaler ZPA：企业级 ZTNA 平台，用基于身份和上下文的应用程序级访问取代 VPN

常见场景

场景：用零信任访问替换企业 VPN 以保护云应用

背景：一家拥有 2,000 名员工的组织通过传统 VPN 集中器访问 30 多个内部云应用。VPN 性能问题和安全顾虑促使该组织决定实施 ZTNA。

方法：

1. 清点当前通过 VPN 访问的所有应用，并按敏感度分类
2. 为基于 Web 的内部应用部署 GCP IAP 或 AWS Verified Access
3. 配置条件访问策略，要求所有应用使用 MFA 和设备合规
4. 使用安全组实施微隔离，以限制应用层之间的横向移动
5. 为敏感应用设置持续验证，每 4 小时重新认证一次
6. 分阶段迁移用户，先从低风险应用开始，并监控访问日志以发现问题
7. 在所有应用都能通过 ZTNA 访问并具备完整日志记录后，停用 VPN

陷阱：并非所有应用都支持身份感知代理集成。传统厚客户端应用可能需要基于 Agent 的 ZTNA 解决方案，而不是基于代理的方法。设备态势评估需要一套部署到所有企业设备的终端管理解决方案。必须为身份提供商不可用的场景记录 break-glass 访问流程。

Output Format

Zero Trust Network Access Implementation Report
==================================================
Organization: Acme Corp
Implementation Date: 2026-02-23
Applications Migrated: 24 / 30

ZTNA ARCHITECTURE:
  Identity Provider: Microsoft Entra ID
  Access Proxy: AWS Verified Access + GCP IAP
  Device Management: Microsoft Intune
  MFA: FIDO2 + Authenticator App

ACCESS POLICY COVERAGE:
  Applications requiring MFA:          30 / 30 (100%)
  Applications requiring compliant device: 24 / 30 (80%)
  Applications with continuous verification: 18 / 30 (60%)
  Applications with location restrictions:  12 / 30 (40%)

SECURITY IMPROVEMENTS:
  VPN-related incidents (before):      12/month
  ZTNA-related incidents (after):       2/month
  Mean time to detect unauthorized access: 4 min (was 2 hours)
  Lateral movement paths eliminated:   85%

MIGRATION STATUS:
  Phase 1 (low-risk apps):     12/12 complete
  Phase 2 (medium-risk apps):  12/12 complete
  Phase 3 (high-risk apps):     0/6  in progress
  VPN decommission:            Scheduled after Phase 3