Implementing Beyondcorp Zero Trust Access Model

Implementing BeyondCorp Zero Trust Access Model

When to Use

• When replacing traditional VPN infrastructure with identity-based application access
• When migrating to Google Cloud and requiring zero trust access for internal applications
• When implementing device trust verification as a prerequisite for resource access
• When needing context-aware access policies based on user identity, device posture, and location
• When securing access for remote and hybrid workforce without network-level trust

Do not use when applications require raw network-level access (e.g., UDP-based protocols not supported by IAP), for consumer-facing public applications, or when the organization lacks an identity provider with MFA capabilities.

Prerequisites

• Google Cloud organization with Cloud Identity or Google Workspace
• Identity-Aware Proxy (IAP) API enabled on the GCP project
• Chrome Enterprise Premium license for endpoint verification
• Applications deployed behind a Google Cloud Load Balancer or on App Engine/Cloud Run
• Endpoint Verification extension deployed on all corporate devices
• Access Context Manager API enabled

Workflow

Step 1: Configure Access Context Manager with Access Levels

Define access levels that represent trust tiers based on device and user attributes.

# Enable required APIs
gcloud services enable iap.googleapis.com
gcloud services enable accesscontextmanager.googleapis.com
gcloud services enable beyondcorp.googleapis.com

# Create an access policy (organization level)
gcloud access-context-manager policies create \
  --organization=ORG_ID \
  --title="BeyondCorp Enterprise Policy"

# Create a basic access level for corporate managed devices
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

# Create a custom access level using CEL expressions
gcloud access-context-manager levels create high-trust \
  --policy=POLICY_ID \
  --title="High Trust Level" \
  --custom-level-spec=high-trust-cel.yaml

Step 2: Deploy Identity-Aware Proxy on Applications

Enable IAP on backend services to enforce identity verification before granting access.

# Create OAuth consent screen
gcloud iap oauth-brands create \
  --application_title="Corporate Applications" \
  --support_email=security@company.com

# Create OAuth client for IAP
gcloud iap oauth-clients create BRAND_NAME \
  --display_name="BeyondCorp IAP Client"

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

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

# Enable IAP on Cloud Run service
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

Step 3: Configure IAM Bindings with Access Level Conditions

Bind IAP access to specific groups with access level requirements.

# Grant access to engineering group with corporate device requirement
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"

# Grant access to contractors with high-trust requirement
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"

# Configure re-authentication settings (session duration)
gcloud iap settings set --project=PROJECT_ID \
  --resource-type=compute \
  --service=internal-app-backend \
  --reauth-method=LOGIN \
  --max-session-duration=3600s

Step 4: Deploy Endpoint Verification on Corporate Devices

Roll out Chrome Enterprise Endpoint Verification for device posture collection.

# Deploy Endpoint Verification via Chrome policy (managed browsers)
# In Google Admin Console > Devices > Chrome > Apps & extensions
# Force-install: Endpoint Verification extension ID: callobklhcbilhphinckomhgkigmfocg

# Verify device inventory in Admin SDK
gcloud endpoint-verification list-endpoints \
  --filter="deviceType=CHROME_BROWSER" \
  --format="table(deviceId, osVersion, isCompliant, encryptionStatus)"

# Create device trust connector for third-party EDR signals
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

# List enrolled devices and their compliance status
gcloud alpha devices list --format="table(name,deviceType,complianceState)"

Step 5: Implement BeyondCorp Enterprise Threat Protection

Enable URL filtering, malware scanning, and DLP for Chrome Enterprise users.

# Configure Chrome Enterprise Premium threat protection rules
# In Google Admin Console > Security > Chrome Enterprise Premium

# Create a BeyondCorp Enterprise connector for on-prem apps
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

# Enable security investigation tool for access anomaly detection
gcloud logging read '
  resource.type="iap_tunnel"
  jsonPayload.decision="DENY"
  timestamp >= "2026-02-22T00:00:00Z"
' --project=PROJECT_ID --format=json --limit=100

Step 6: Monitor and Audit BeyondCorp Access Decisions

Set up comprehensive logging and alerting for zero trust policy enforcement.

# Create a log sink for IAP access decisions
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"'

# Query BigQuery for access pattern analysis
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, "$") 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
'

# Create an alert policy for repeated access denials
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

Key Concepts

Tools & Systems

• Google Cloud IAP: Identity-aware reverse proxy enforcing per-request authentication and authorization for GCP-hosted applications
• Access Context Manager: Policy engine defining access levels based on device attributes, IP ranges, and geographic locations
• Chrome Enterprise Premium: Extended BeyondCorp capabilities including real-time threat protection and data loss prevention
• Endpoint Verification: Device posture collection agent deployed as Chrome extension to all corporate endpoints
• BeyondCorp Enterprise Connectors: Secure tunnel connectors enabling IAP protection for on-premises applications
• Cloud Audit Logs: Immutable log records of all IAP access decisions for compliance and forensic analysis

Common Scenarios

Scenario: Migrating 50+ Internal Applications from VPN to BeyondCorp

Context: A technology company with 3,000 employees uses Cisco AnyConnect VPN for accessing internal applications. The VPN introduces latency, creates a single point of failure, and grants excessive network access after authentication.

Approach:

1. Inventory all 50+ applications and categorize by hosting (GCP, on-prem, SaaS) and protocol (HTTPS, TCP, SSH)
2. Deploy Endpoint Verification to all corporate devices and establish baseline device posture data over 2 weeks
3. Create access levels in Access Context Manager: corporate-managed, contractor-device, high-trust
4. Enable IAP on GCP-hosted HTTPS applications first (App Engine, Cloud Run, GKE services)
5. Deploy BeyondCorp Enterprise connectors for on-premises applications
6. Migrate users in 3 phases: IT/Engineering (week 1-2), General staff (week 3-4), Executives/Finance (week 5-6)
7. Configure re-authentication policies: 8 hours for general apps, 1 hour for financial systems
8. Set up BigQuery audit pipeline for continuous monitoring and anomaly detection
9. Decommission VPN after 30-day parallel operation period

Pitfalls: Some legacy applications may not support HTTPS proxying and require TCP tunnel mode. Device enrollment takes time; plan a 2-week onboarding period before enforcing device posture requirements. Break-glass accounts with bypassed access levels must be created and tested for identity provider outages.

Output Format

BeyondCorp Zero Trust Implementation Report
==================================================
Organization: TechCorp Inc.
Implementation Date: 2026-02-23
Migration Phase: Phase 2 of 3

ACCESS ARCHITECTURE:
  Identity Provider: Google Workspace
  Access Proxy: Google Cloud IAP
  Device Management: Chrome Enterprise + Endpoint Verification
  Threat Protection: Chrome Enterprise Premium
  On-Prem Connector: BeyondCorp Enterprise Connector (3 instances)

ACCESS LEVEL COVERAGE:
  Access Level: corporate-managed
    Devices enrolled:              2,847 / 3,000 (94.9%)
    Compliant devices:             2,712 / 2,847 (95.3%)
  Access Level: high-trust
    Devices enrolled:              312 / 350 (89.1%)
    Compliant devices:             298 / 312 (95.5%)

APPLICATION MIGRATION:
  GCP HTTPS apps (IAP-protected):  32 / 35 (91.4%)
  On-prem apps (via connector):    12 / 15 (80.0%)
  SaaS apps (via SAML/OIDC):       8 / 8 (100%)
  Total migrated:                  52 / 58 (89.7%)

SECURITY METRICS (last 30 days):
  Total access requests:           1,247,832
  Denied by IAP policy:            3,412 (0.27%)
  Denied by access level:          1,208 (0.10%)
  Re-authentication triggered:     45,219
  Anomalous access patterns:       12 (investigated)
  VPN-related incidents (before):  8/month
  BeyondCorp incidents (after):    1/month

VPN DECOMMISSION STATUS:
  Parallel operation remaining:    14 days
  Users still on VPN:              148 (5%)
  Planned decommission:            2026-03-15

Source: mukul975/Anthropic-Cybersecurity-Skills → skills/implementing-beyondcorp-zero-trust-access-model/SKILL.md