---

name: implementing-beyondcorp-zero-trust-access-model description: "实施 Google 的 BeyondCorp 零信任访问模型，通过 IAP、Access Context Manager 和 Chrome Enterprise Premium，消除网络边界的隐式信任，强制执行基于身份的访问控制，实现无 VPN 的安全应用访问。适用于将传统 VPN 替换为零信任架构、部署 Identity-Aware Proxy、配置设备信任策略、或为远程办公实施上下文感知访问控制时使用。" domain: cybersecurity subdomain: zero-trust-architecture tags: [beyondcorp, zero-trust, zero-trust-architecture, google-cloud, iap, identity-aware-proxy, ztna, access-context-manager, vpn-replacement, remote-access-security, device-trust] version: "1.0" author: mahipal license: Apache-2.0

实施 BeyondCorp 零信任访问模型

适用场景

• 以基于身份的应用访问取代传统 VPN 基础设施时
• 迁移到 Google Cloud 并需要对内部应用进行零信任访问时
• 将设备信任验证作为资源访问前提条件时
• 需要基于用户身份、设备态势和位置的上下文感知访问策略时
• 在不依赖网络级信任的情况下保护远程和混合员工的访问时

不适用于需要原始网络级访问的应用（如 IAP 不支持的基于 UDP 的协议）、面向消费者的公开应用，或组织缺乏具有 MFA 能力的身份提供商的场景。

前置条件

• 具有 Cloud Identity 或 Google Workspace 的 Google Cloud 组织
• GCP 项目已启用 Identity-Aware Proxy（IAP）API
• 用于端点验证的 Chrome Enterprise Premium 许可证
• 应用程序部署在 Google Cloud 负载均衡器或 App Engine/Cloud Run 后方
• 所有企业设备已部署 Endpoint Verification 扩展
• 已启用 Access Context Manager API

工作流程

步骤 1：使用访问级别配置 Access Context Manager

定义代表信任级别的访问级别，基于设备和用户属性。

# 启用所需 API
gcloud services enable iap.googleapis.com
gcloud services enable accesscontextmanager.googleapis.com
gcloud services enable beyondcorp.googleapis.com

# 创建访问策略（组织级别）
gcloud access-context-manager policies create \
  --organization=ORG_ID \
  --title="BeyondCorp Enterprise Policy"

# 为企业托管设备创建基本访问级别
cat > corporate-device-level.yaml << 'EOF'
- devicePolicy:
    allowedEncryptionStatuses:
      - ENCRYPTED
    osConstraints:
      - osType: DESKTOP_CHROME_OS
        minimumVersion: "13816.0.0"
      - osType: DESKTOP_WINDOWS
        minimumVersion: "10.0.19045"
      - osType: DESKTOP_MAC
        minimumVersion: "13.0.0"
    requireScreenlock: true
    requireAdminApproval: true
  regions:
    - US
    - GB
    - DE
EOF

gcloud access-context-manager levels create corporate-managed \
  --policy=POLICY_ID \
  --title="Corporate Managed Device" \
  --basic-level-spec=corporate-device-level.yaml

# 使用 CEL 表达式创建自定义访问级别
gcloud access-context-manager levels create high-trust \
  --policy=POLICY_ID \
  --title="High Trust Level" \
  --custom-level-spec=high-trust-cel.yaml

验证检查点：运行 gcloud access-context-manager levels list --policy=POLICY_ID 确认访问级别已正确创建。如创建失败，检查组织 ID 和策略权限（需要 accesscontextmanager.policies.create 权限）。

回滚：使用 gcloud access-context-manager levels delete LEVEL_NAME --policy=POLICY_ID 删除错误配置的访问级别。

步骤 2：在应用上部署 Identity-Aware Proxy

在后端服务上启用 IAP，在授予访问前强制执行身份验证。

# 创建 OAuth 同意屏幕
gcloud iap oauth-brands create \
  --application_title="Corporate Applications" \
  --support_email=security@company.com

# 为 IAP 创建 OAuth 客户端
gcloud iap oauth-clients create BRAND_NAME \
  --display_name="BeyondCorp IAP Client"

# 在后端服务上启用 IAP（GCE/GKE 在 HTTPS 负载均衡器后方）
gcloud compute backend-services update internal-app-backend \
  --iap=enabled,oauth2-client-id=CLIENT_ID,oauth2-client-secret=CLIENT_SECRET \
  --global

# 在 App Engine 上启用 IAP
gcloud iap web enable \
  --resource-type=app-engine \
  --oauth2-client-id=CLIENT_ID \
  --oauth2-client-secret=CLIENT_SECRET

# 在 Cloud Run 服务上启用 IAP
gcloud run services add-iam-policy-binding internal-api \
  --member="serviceAccount:service-PROJECT_NUM@gcp-sa-iap.iam.gserviceaccount.com" \
  --role="roles/run.invoker" \
  --region=us-central1

验证检查点：运行 gcloud iap web get-iam-policy --resource-type=backend-services --service=internal-app-backend 确认 IAP 已启用。通过浏览器访问应用 URL，应出现 Google 登录页面。

回滚：使用 gcloud compute backend-services update internal-app-backend --no-iap --global 禁用 IAP 恢复原始访问方式。

步骤 3：配置带访问级别条件的 IAM 绑定

将 IAP 访问与具有访问级别要求的特定组绑定。

# 授予工程团队访问权限，要求企业设备
gcloud iap web add-iam-policy-binding \
  --resource-type=backend-services \
  --service=internal-app-backend \
  --member="group:engineering@company.com" \
  --role="roles/iap.httpsResourceAccessor" \
  --condition="expression=accessPolicies/POLICY_ID/accessLevels/corporate-managed,title=Require Corporate Device"

# 授予承包商访问权限，要求高信任级别
gcloud iap web add-iam-policy-binding \
  --resource-type=backend-services \
  --service=internal-app-backend \
  --member="group:contractors@company.com" \
  --role="roles/iap.httpsResourceAccessor" \
  --condition="expression=accessPolicies/POLICY_ID/accessLevels/high-trust,title=Require High Trust"

# 配置重新认证设置（会话时长）
gcloud iap settings set --project=PROJECT_ID \
  --resource-type=compute \
  --service=internal-app-backend \
  --reauth-method=LOGIN \
  --max-session-duration=3600s

验证检查点：使用测试用户访问受保护应用，验证符合访问级别的用户可访问，不符合的用户被拒绝。检查 gcloud logging read 'resource.type="iap_tunnel"' --limit=5 确认访问决策日志正常。

回滚：使用 gcloud iap web remove-iam-policy-binding 移除错误的 IAM 条件绑定。注意：先在非生产环境测试条件表达式。

步骤 4：在企业设备上部署端点验证

推出 Chrome Enterprise Endpoint Verification（端点验证）以收集设备态势数据。

# 通过 Chrome 策略部署端点验证（托管浏览器）
# 在 Google 管理控制台 > 设备 > Chrome > 应用和扩展程序中
# 强制安装：Endpoint Verification 扩展 ID：callobklhcbilhphinckomhgkigmfocg

# 通过 Admin SDK 验证设备清单
gcloud endpoint-verification list-endpoints \
  --filter="deviceType=CHROME_BROWSER" \
  --format="table(deviceId, osVersion, isCompliant, encryptionStatus)"

# 为第三方 EDR 信号创建设备信任连接器
gcloud beyondcorp app connections create crowdstrike-connector \
  --project=PROJECT_ID \
  --location=global \
  --application-endpoint=host=crowdstrike-api.internal:443,port=443 \
  --type=TCP_PROXY_TUNNEL \
  --connectors=projects/PROJECT_ID/locations/us-central1/connectors/connector-1

# 列出已注册设备及其合规状态
gcloud alpha devices list --format="table(name,deviceType,complianceState)"

验证检查点：运行 gcloud alpha devices list --format="table(name,deviceType,complianceState)" --limit=10 确认设备已注册并报告合规状态。预留 1-2 周设备注册引导期再强制执行设备态势要求。

步骤 5：实施 BeyondCorp Enterprise 威胁防护

为 Chrome Enterprise 用户启用 URL 过滤、恶意软件扫描和 DLP。

# 在 Google 管理控制台 > 安全 > Chrome Enterprise Premium 中配置威胁防护规则

# 为本地应用创建 BeyondCorp Enterprise 连接器
gcloud beyondcorp app connectors create onprem-connector \
  --project=PROJECT_ID \
  --location=us-central1 \
  --display-name="On-Premises App Connector"

gcloud beyondcorp app connections create hr-portal \
  --project=PROJECT_ID \
  --location=us-central1 \
  --application-endpoint=host=hr.internal.company.com,port=443 \
  --type=TCP_PROXY_TUNNEL \
  --connectors=projects/PROJECT_ID/locations/us-central1/connectors/onprem-connector

# 启用安全调查工具进行访问异常检测
gcloud logging read '
  resource.type="iap_tunnel"
  jsonPayload.decision="DENY"
  timestamp >= "2026-02-22T00:00:00Z"
' --project=PROJECT_ID --format=json --limit=100

验证检查点：运行 gcloud beyondcorp app connections list --project=PROJECT_ID --location=us-central1 验证连接器状态为 ACTIVE。通过内部网络测试本地应用是否可通过 IAP 隧道访问。

回滚：使用 gcloud beyondcorp app connections delete CONNECTION_NAME --project=PROJECT_ID --location=us-central1 删除错误配置的连接。本地应用将恢复为直接内网访问。

步骤 6：监控和审计 BeyondCorp 访问决策

为零信任策略执行设置全面的日志记录和告警。

# 为 IAP 访问决策创建日志接收器
gcloud logging sinks create iap-access-audit \
  --destination=bigquery.googleapis.com/projects/PROJECT_ID/datasets/beyondcorp_audit \
  --log-filter='resource.type="iap_tunnel" OR resource.type="gce_backend_service"'

# 通过 BigQuery 查询访问模式分析
bq query --use_legacy_sql=false '
SELECT
  protopayload_auditlog.authenticationInfo.principalEmail AS user,
  resource.labels.backend_service_name AS application,
  JSON_EXTRACT_SCALAR(protopayload_auditlog.requestMetadata.callerSuppliedUserAgent, "quot;) AS device,
  protopayload_auditlog.status.code AS decision_code,
  COUNT(*) AS request_count
FROM `PROJECT_ID.beyondcorp_audit.cloudaudit_googleapis_com_data_access`
WHERE timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 24 HOUR)
GROUP BY user, application, device, decision_code
ORDER BY request_count DESC
LIMIT 50
'

# 为重复访问拒绝创建告警策略
gcloud alpha monitoring policies create \
  --display-name="BeyondCorp Repeated Access Denials" \
  --condition-display-name="High denial rate" \
  --condition-filter='resource.type="iap_tunnel" AND jsonPayload.decision="DENY"' \
  --condition-threshold-value=10 \
  --condition-threshold-duration=300s \
  --notification-channels=projects/PROJECT_ID/notificationChannels/CHANNEL_ID

常见场景

场景：将 50 多个内部应用从 VPN 迁移到 BeyondCorp

场景背景：一家拥有 3000 名员工的科技公司使用 Cisco AnyConnect VPN 访问内部应用。VPN 引入了延迟、造成单点故障，并在认证后授予过多网络访问权限。

方法：

1. 清点所有 50 多个应用，按托管方式（GCP、本地、SaaS）和协议（HTTPS、TCP、SSH）分类
2. 向所有企业设备部署端点验证，并在 2 周内建立设备态势基线数据
3. 在 Access Context Manager 中创建访问级别：corporate-managed、contractor-device、high-trust
4. 首先在 GCP 托管的 HTTPS 应用上启用 IAP（App Engine、Cloud Run、GKE 服务）
5. 为本地应用部署 BeyondCorp Enterprise 连接器
6. 分 3 个阶段迁移用户：IT/工程团队（第 1-2 周）、普通员工（第 3-4 周）、高管/财务（第 5-6 周）
7. 配置重新认证策略：通用应用 8 小时，财务系统 1 小时
8. 设置 BigQuery 审计流水线用于持续监控和异常检测
9. 在 30 天并行运行期后下线 VPN

常见陷阱：某些遗留应用可能不支持 HTTPS 代理，需要 TCP 隧道模式。设备注册需要时间；在强制执行设备态势要求前需规划 2 周的引导期。必须创建并测试具有绕过访问级别能力的紧急访问账户，以应对身份提供商中断情况。

输出格式

BeyondCorp 零信任实施报告
==================================================
组织：TechCorp Inc.
实施日期：2026-02-23
迁移阶段：第 2 阶段（共 3 阶段）

访问架构：
  身份提供商：Google Workspace
  访问代理：Google Cloud IAP
  设备管理：Chrome Enterprise + 端点验证
  威胁防护：Chrome Enterprise Premium
  本地连接器：BeyondCorp Enterprise Connector（3 个实例）

访问级别覆盖：
  访问级别：corporate-managed
    已注册设备：              2,847 / 3,000（94.9%）
    合规设备：                2,712 / 2,847（95.3%）
  访问级别：high-trust
    已注册设备：              312 / 350（89.1%）
    合规设备：                298 / 312（95.5%）

应用迁移：
  GCP HTTPS 应用（IAP 保护）：  32 / 35（91.4%）
  本地应用（通过连接器）：      12 / 15（80.0%）
  SaaS 应用（通过 SAML/OIDC）：  8 / 8（100%）
  总迁移数：                    52 / 58（89.7%）

安全指标（过去 30 天）：
  总访问请求数：           1,247,832
  IAP 策略拒绝：           3,412（0.27%）
  访问级别拒绝：           1,208（0.10%）
  触发重新认证：           45,219
  异常访问模式：           12（已调查）
  VPN 相关事件（迁移前）：  8 次/月
  BeyondCorp 事件（迁移后）：1 次/月

VPN 下线状态：
  剩余并行运行时间：  14 天
  仍使用 VPN 的用户：148（5%）
  计划下线日期：      2026-03-15