Access Context Manager

Introduction to Access Context Manager (ACM)

In a Zero Trust architecture, identity is just one piece of the puzzle. Access Context Manager (ACM) is the engine that evaluates the "context" of a request—the where, the what, and the how—before granting access. While IAM manages "Who," ACM manages "Under what conditions."

For a Professional Cloud Security Engineer (PSE), ACM is the central policy engine for Context-Aware Access. It allows you to create fine-grained Access Levels that can be used by Identity-Aware Proxy (IAP) and VPC Service Controls (VPC SC) to provide a unified security posture across web applications and cloud APIs.

白話文解釋（Plain English Explanation）

1. The High-Security Vault (Access Levels)

Imagine a bank vault. To get in, you don't just need a key (Identity). The security guard also checks: Are you wearing a company uniform? (Device posture). Is it during business hours? (Time context). Are you coming from the main entrance and not the back alley? (IP/Location). If any of these conditions are not met, the vault stays locked, even if you have the key.

2. The Airport Security Screening (Basic vs. Custom)

A Basic Access Level is like the standard security line: Everyone goes through the same checks (ID, bags, metal detector). A Custom Access Level is like the "Pre-Check" or "Diplomatic" line, where specific rules (CEL expressions) are used to verify complex combinations of credentials and status that the standard line can't handle.

3. The Digital Health Certificate (Device State)

Think of an international traveler who needs a health certificate to enter a country. ACM checks your device's "health": Is the disk encrypted? Is there a screen lock? Is the OS up to date? If your device is "sick" (unencrypted), ACM denies entry to the cloud application.

Defining Access Levels (Basic vs. Custom)

An Access Level is a named set of conditions.

Basic Access Levels

Basic levels are created using the Google Cloud Console or YAML files. They support common attributes:

• IP Subnetworks: Restrict access to specific CIDR ranges (e.g., corporate VPN or office IP).
• Device Policy: Check for screen lock, disk encryption, and OS version.
• Geographic Location: Allow access only from specific countries.
• Required Access Levels: You can nest access levels (Level A requires Level B).

Custom Access Levels

Custom levels use Common Expression Language (CEL) for complex logic.

• Scenario: Grant access if the user is in the "Finance" group AND is using a managed device OR is coming from a "Trusted IP."
• CEL allows for if/then/else logic that Basic levels cannot provide.

Attributes: IP, Device State, and Location

ACM leverages Endpoint Verification, a Chrome extension or mobile app, to gather device telemetry.

Device State Attributes:

• is_managed: Is the device enrolled in your organization's management system?
• is_encrypted: Is the device's storage encrypted at rest?
• screen_lock_enabled: Is a PIN or password required to unlock the device?
• os_type: Restrict to specific operating systems (e.g., only macOS and Windows).

Using Access Levels with VPC Service Controls (VPC SC)

VPC Service Controls create a "perimeter" around your data. However, sometimes legitimate users need to reach into that perimeter from the outside.

Bridge to the Perimeter:

1. Define an ACM Access Level (e.g., "Corporate_IPs").
2. In the VPC SC Perimeter configuration, add that Access Level to the Ingress Policy.
3. Users coming from Corporate IPs can now access the restricted APIs (like BigQuery or GCS) from their laptops, even if they aren't inside the VPC.

Integrating with BeyondCorp Enterprise

ACM is the heart of BeyondCorp Enterprise. It enables:

• Continuous Evaluation: If a user unencrypts their disk while logged in, ACM (via Endpoint Verification) can detect the change and revoke access immediately.
• Secure Browsing: Combined with Chrome Enterprise, ACM can ensure that data can only be downloaded to "Authorized Devices."

Device Security Posture Checks

For a PSE, "Posture" is more than just a checkbox. ACM can enforce specific OS versions to prevent access from devices with known vulnerabilities.

• Constraint: device.os_config.version >= "10.0.19041" (Windows 10 version check).

Managing Multiple Access Policies

In large organizations, different departments might need different security rules.

• Organization Policy: There is one global Access Policy for the entire Organization by default.
• Scoped Policies: You can now create Scoped Access Policies that apply only to specific Folders or Projects. This prevents the "Blast Radius" of a policy change from affecting the whole company.

Custom Access Levels with CEL

CEL expressions are powerful but require careful syntax.

Example CEL Expression:

// Access allowed if (Encrypted AND Screen Lock) OR (On Corporate IP)
(device.encryption_status == DeviceEncryptionStatus.ENCRYPTED && 
 device.screen_lock_enabled == true) || 
(levels.select_trusted_ips)

Troubleshooting Access Level Denial

When a user is blocked by ACM, the logs are your best friend.

1. Cloud Logging: Search for protoPayload.status.code=7 (Permission Denied) in the accesscontextmanager.googleapis.com logs.
2. Audit Logs: Look for the accessLevels field in the log entry to see which specific level failed.
3. Endpoint Verification Console: Check if the user's device is correctly reporting its state.

ACM and Identity-Aware Proxy (IAP) Interaction

ACM and IAP work together to provide Context-Aware Access for Web Apps.

• IAP handles the Identity (Who).
• ACM handles the Access Level (Context).
• Workflow: User logs in → IAP checks IAM → IAP calls ACM → ACM checks Device/IP → Access Granted/Denied.

CLI Commands for ACM

Listing Access Levels

gcloud access-context-manager levels list \
    --policy=1234567890

Creating a Basic Access Level (YAML)

- title: Trusted_IPs
  description: Only corporate office IPs
  basic:
    conditions:
    - ipSubnetworks:
      - 203.0.113.0/24
    combiningFunction: OR

gcloud access-context-manager levels create Trusted_IPs \
    --policy=1234567890 \
    --yaml-file=trusted_ips.yaml

Security Best Practices for PSE

1. Start Simple: Begin with IP-based restrictions before moving to complex device posture checks.
2. Use Scoped Policies: For large organizations, use scoped policies to delegate management to different teams.
3. Monitor with SCC: Security Command Center can alert you if an Access Level is deleted or modified insecurely.
4. Grace Periods: When enforcing OS updates, give users a "Grace Period" (defined in ACM) so they aren't locked out immediately when a new update is released.

Troubleshooting Scenarios

Scenario: User is blocked despite being on a Corporate Laptop

Diagnosis: The Endpoint Verification extension might be disabled, or the device hasn't synced with the cloud in the last 24 hours. Fix: Instruct the user to open Chrome and ensure the Endpoint Verification extension is active and "Syncing."

Scenario: A VPC Service Control perimeter is blocking a valid Admin

Diagnosis: The Admin is attempting to use the gsutil or bq tool from a local machine that is not covered by an ACM Access Level in the perimeter's ingress policy. Fix: Add the Admin's IP range or device policy to an ACM Access Level and update the VPC SC ingress rules to allow that level.

PSE Exam Scenarios

Scenario 1: Multi-Factor Context

"A company wants to ensure that BigQuery data can only be accessed by users who are using a managed, encrypted laptop AND are located in either the US or Canada. How do you implement this?" Answer: Create a Basic Access Level in ACM. Add conditions for is_managed, is_encrypted, and a list of allowed regions (US, CA). Set the combiningFunction to AND.

Scenario 2: Dynamic Policy Changes

"You need to allow a temporary contractor access to a protected app from their home IP for 48 hours. What is the most secure way?" Answer: Create a temporary ACM Access Level for the contractor's IP and use an IAM Condition on the iap.httpsResourceAccessor role that expires after 48 hours.

Summary Checklist

• Differentiate between Basic and Custom Access Levels.
• List at least four device attributes that ACM can check.
• Explain how ACM integrates with VPC Service Controls.
• Identify the role of Endpoint Verification in the ACM ecosystem.
• Understand the purpose of Scoped Access Policies.