Google Workspace Context-Aware Access: Granular Access Control

Introduction

In today's dynamic work environment, ensuring secure access to corporate resources is paramount. Google Workspace Context-Aware Access (CAA) provides administrators with robust control over how and when users can access Google Workspace applications and data. This guide provides a comprehensive overview of Context-Aware Access, detailing its functionalities, deployment strategies, configuration steps, and troubleshooting tips for Google Workspace administrators.

Context-Aware Access allows you to create granular security policies based on various contextual attributes such as user identity, geographic location, device security status, and IP address. This enables organizations to protect sensitive data by enforcing access only from trusted environments and compliant devices. For instance, you can allow access to apps exclusively from company-issued devices, ensure Google Drive is only accessible if a user's storage device is encrypted, or restrict access from outside the corporate network.

Understanding Context-Aware Access

Context-Aware Access is a security feature that empowers administrators to define and enforce access policies for Google Workspace applications based on the user's context.

How Context-Aware Access Works

The evaluation of Context-Aware Access policies differs slightly based on the application type:

• Google Workspace Core Services: For core services like Gmail, Google Drive, Google Calendar, and Google Meet, policy evaluation is continuous. This means if a user changes their context (e.g., moves from the office network to a coffee shop), the policy is re-evaluated immediately, and access can be revoked if the new context violates the policy.
• SAML Apps: For third-party SAML applications (where Google acts as the Identity Provider), policy evaluation occurs at the time of sign-in to the app. If a user's location changes after signing in, the policy will only be rechecked when their session ends and they sign in again.

Supported Editions, Apps, and Platforms

Context-Aware Access policies are applicable to users holding licenses for specific Google Workspace editions, including Frontline Standard, Frontline Plus, Enterprise Standard, Enterprise Plus, Education Standard, Education Plus, and Cloud Identity Premium. Users with other editions will not be subject to these policies, even if they belong to an organizational unit or group where a CAA policy is applied.

CAA supports a wide range of applications and platforms:

• Google Workspace Core Services: Gmail, Calendar, Cloud Search, Drive (including Docs, Sheets, Slides, Forms, and Drive for Desktop), Gemini, Google Meet, Groups for Business, Google Vault, Chat, Keep, Sites, Tasks, Admin console, and NotebookLM.
• Additional Google Services: Looker Studio and Google Play Console.
• SAML Apps: Third-party SAML apps that use Google as the identity provider, or those using a third-party IdP federated to Google Cloud Identity.

Platform Support by Policy Type:

• IP and Geographic Origin:
  • Device Type: Desktop, laptop, mobile device.
  • Operating System: macOS, Windows, ChromeOS, Linux OS (desktop); Android, iOS (mobile).
  • Access: Web browser (desktop) and Drive for desktop; Web browser and built-in first-party apps (mobile).
  • Software: No agent required, except for Safari with Apple Private Relay enabled, which can hide the IP address and lead to blocked access if an IP subnet access level is applied.
• Device Policy:
  • Device Type: Desktop, laptop, mobile device.
  • Operating System: macOS, Windows, ChromeOS, Linux OS (desktop); Android, iOS (mobile).
  • Access: Chrome browser (desktop) and Drive for desktop; Chrome browser for built-in first-party apps (mobile).
  • Software: Chrome web browser, Chrome Endpoint Verification extension (desktop); Google endpoint management (basic or advanced) for mobile.

Admin Privileges Required

To set Context-Aware Access policies, an administrator must be a Super Administrator or have the following specific privileges:

• Data Security > Access level management
• Data Security > Rule management
• Admin API Privileges > Groups > Read
• Admin API Privileges > Users > Read

Planning and Deployment

A well-planned deployment of Context-Aware Access is crucial to protect sensitive data while minimizing user disruption.

Deployment Recommendations

• Monitor Mode: Start by assigning access levels in monitor mode. This simulates the effect of enforcing an access level without actually blocking user access, allowing you to review logs and verify behavior before enforcement. It's recommended to leave it in monitor mode for at least a week.
• Phased Rollout: Begin with a pilot organizational unit (OU) or group. Once satisfied with the results, gradually roll out policies to other groups.
• Selected Apps: Deploy policies on less frequently used apps first, then progressively apply them to more critical applications.
• Avoid Lockouts: Do not block access to essential Google Workspace services (like Gmail) that users rely on for communication.
• IP Ranges: Identify and account for necessary IP ranges used by users and partners.
• GCP Interface: If you are a Workspace-only customer, avoid using the Google Cloud Platform (GCP) interface to add or modify Context-Aware Access levels, as this can lead to errors.
• Help Desk Support: Plan for help desk support to assist users who might encounter issues during the rollout.

Preparing for Deployment

Before creating or implementing new access policies, follow these steps:

• Inform Your Users: Communicate the upcoming changes and their potential impact. Explain how policies might affect their access and why these measures are being implemented to promote user acceptance.
• Organize Users into Organizational Units or Groups: Ensure users are correctly assigned to OUs or configuration groups, as policies can be applied at these levels.
• Survey Enterprise Devices: Verify that devices in your environment are properly managed and compliant with company standards (e.g., encrypted, up-to-date OS, company-owned vs. personal).
• Enroll Mobile Devices with Endpoint Management: Mobile devices must be managed using Google endpoint management (either basic or advanced) for CAA policies to be enforced.
• Enforce Endpoint Verification: Set up Endpoint Verification and force its installation for Chrome extensions, requiring an access key. Users should sign into Endpoint Verification and refresh their browser before device policies are enforced to avoid initial access denied messages.

Turning On/Off Context-Aware Access

You can enable or disable Context-Aware Access at different stages of your deployment.

To Turn On Context-Aware Access:

1. Sign in to the Google Admin console with an administrator account.
2. Navigate to Menu > Security > Access and data control > Context-Aware Access.
3. Verify that Context-Aware Access is ON. If not, click Turn On.

To Turn Off Context-Aware Access:

1. Sign in to the Google Admin console with an administrator account.
2. Navigate to Menu > Security > Access and data control > Context-Aware Access.
3. Click Turn Off.
   • Note: It can take up to 24 hours for Context-Aware Access to be fully disabled, during which users might still be affected by previous access levels. Deleted access levels cease to apply immediately.

Creating Context-Aware Access Levels

Context-Aware Access levels define the conditions users must meet to access apps. They combine one or more conditions and attributes to define a user's or device's context.

Basic Mode

Basic mode provides a user-friendly interface with predefined attributes.

To Create an Access Level in Basic Mode:

1. Sign in to the Google Admin console with an administrator account.
2. Navigate to Security > Access and data control > Context-Aware Access > Access levels.
3. Click Create access level. Basic mode is selected by default.
4. Enter an Access level name and an optional description.
5. For each condition, specify whether users must Meet attributes (satisfy all attributes) or Don't meet attributes (don't meet any of the attributes). The "Don't meet attributes" option is often used for IP subnets (e.g., blocking access from a specific IP range).
6. Click Add Attribute and select one or more attributes:
   • IP subnet: IPv4 or IPv6 address/routing prefix in CIDR block notation. Private IP addresses and dynamic IPs are not supported, though a static IP subnet can define a dynamic IP range.
   • Location: Countries/regions where the user is accessing services.
   • Device policy:
     • Admin approval is required.
     • Company-owned device is required.
     • Screen password protected.
     • Device encryption (Not supported, Not encrypted, Encrypted).
   • Device OS: Specify allowed operating systems and minimum versions (major.minor.patch format).
     • macOS, Windows, Linux, Chrome OS, iOS, Android.
   • Access level: Requires the user to meet the requirements of an existing access level.
7. To add another condition, click Add condition and specify whether to join with And (users must meet both conditions) or Or (users must meet only one condition).
8. Click Save.

Example Basic Mode Access Level: An access level named "corp_access" could require users to access Gmail only from an encrypted and company-owned device located in the US or Canada.

• Access level name: corp_access
• A user gets access if they: Satisfy all the attributes in the condition
  • Condition 1 attributes:
    • Device policy
      • Device encryption = encrypted
      • Company-owned device = required
  • Join condition 1 and condition 2 with: AND
  • Condition 2 attributes:
    • Geographic origin
      • Countries = US, Canada

Advanced Mode

Advanced mode allows for more complex access levels using Common Expression Language (CEL). This is useful for conditions not available in basic mode, such as vendor conditions for third-party integrations or certificate-based authentication.

To Define Access Levels in Advanced Mode:

1. Follow steps 1-3 from Basic Mode, then select Advanced Mode.
2. Enter an Access level name and optional description.
3. Build your custom access level using a CEL expression in the editor. Google provides guidance and examples in their Custom access level specification.
4. Click Save. The expression is compiled, and syntax errors are reported for correction.

Example Advanced Mode Access Level: An access level that requires the originating device to be encrypted, AND either the request originated in the United States OR the device is administrator-approved:

device.encryption_status == DeviceEncryptionStatus.ENCRYPTED && (origin.region_code in ["US"] || device.is_admin_approved_device)

Assigning Context-Aware Access Levels to Apps

After creating access levels, you assign them to specific applications to enforce the desired access controls.

To Assign Context-Aware Access Levels to an App:

1. Sign in to the Google Admin console with an administrator account.
2. Navigate to Menu > Security > Access and data control > Context-Aware Access.
3. Click Assign access levels. You will see a list of applications.
4. (Optional) To apply settings to a specific organizational unit or configuration group, select it from the side panel.
5. Hover over an app and click Assign, or select multiple apps and click Assign at the top.
6. Select one or more access levels (up to 10) from the left.
   • Selected access levels default to Monitor mode. This is recommended for testing without blocking users. Change to Active when ready to enforce.
   • If users need to meet conditions of multiple access levels, create a nested access level that combines them with a logical AND operation.
7. Click Continue.
8. (Recommended) Check Block users from accessing Google desktop and mobile apps if access levels aren't met to apply policies to native desktop, Android, iOS, and web apps.
9. (Optional) Check Block other apps from accessing the selected apps via APIs, if access levels aren't met to restrict API access to Workspace data.
10. (Optional) To exempt trusted apps from API blocking, check Exempt allowlisted apps so that they can always access APIs for specific Google services, regardless of access levels. You may need to configure app access control to trust the app first. Google apps cannot be exempted.
11. Click Continue, review the settings, and click Assign.

App Behavior Based on Access Level Settings: The behavior of apps (mobile native, mobile web, desktop web, desktop native) depends on whether "Block users from accessing Google desktop and mobile apps if access levels aren't met" is checked and if Endpoint Verification is deployed. Generally, if device attributes are used in an access level, Endpoint Verification must be deployed for full enforcement across all app types.

Review or Modify Assigned Access Levels

1. Hover over the app and click Assign.
2. To unassign, click Remove next to the access level.
3. To change mode, toggle between Monitor and Active status.
4. To assign more levels, select them from the left.
5. Click Continue to modify policy settings and then Save.

Viewing Logged Events for Access Levels

Access levels in both monitor and active modes generate events in the Context-Aware Access log.

1. Click Assign access levels.
2. Select the OU or group to review.
3. Hover over an app and click View report.
4. Click Link to Security Investigation Tool to view relevant log events.
   • Access denied (Monitor mode) events show who would have been blocked.
   • Logs indicate access levels applied, satisfied, and unsatisfied.

Using Context-Aware Access with Configuration Groups

Configuration groups offer a flexible way to apply Context-Aware Access levels to specific user groups, irrespective of their organizational unit. This is particularly useful for managing access for contractors or IT staff.

How Configuration Groups Work

• Membership: Configuration groups can contain any users in your organization. A user can belong to multiple configuration groups.
• Priority: You set the priority of configuration groups. If a user belongs to multiple groups with conflicting settings for an app, the setting from the highest priority group applies.
• Overrides: A user's group access level for an app always overrides their organizational unit's access level. If a configuration group doesn't specify an access level for an app, the user's OU access level is used.
• Creation: Configuration groups must be created in the Admin console, Directory API, or Google Cloud Directory Sync; Google Groups cannot be used as configuration groups.

Designing Configuration Groups for CAA

• Options: You can apply access levels directly to existing user groups (good for testing, small organizations, or specific teams like IT) or create dedicated configuration groups that act as containers for access levels, then add user groups as members.
• Priority Planning: Assign higher priority to critical or sensitive configuration groups (e.g., "Urgent Access" to override limits).
• Naming Standards: Use a consistent naming standard (e.g., caa_p0.0_unrestricted_access@example.com) for easier searching and auditing.

Setting Up and Managing Configuration Groups

1. Apply a Configuration Group:
   • Sign in to the Admin console.
   • Navigate to Menu > Security > Access and data control > Context-Aware Access.
   • Click Assign access levels, then Groups.
   • Select an app or search for a group.
   • Click the group, then select one or more apps, and click Assign.
   • Select the access levels for the app within that group and click Save.
   • New groups are added at the lowest priority by default.
2. Check Access Levels for a User:
   • Navigate to Menu > Security > Access and data control > Context-Aware Access.
   • In the Admin console, go to the app's settings page, click Users, then Select a user and enter their email address.
   • The "Inherited from" column shows which group or OU determined the user's settings.
3. Remove a Configuration Group:
   • Navigate to Menu > Security > Access and data control > Context-Aware Access.
   • Click Assign access levels, then Groups.
   • Select the group to remove. First, unassign all access levels from all apps within that group.
   • The group will no longer appear in the list.
4. Edit a Configuration Group:
   • Navigate to Menu > Security > Access and data control > Context-Aware Access.
   • Click Assign access levels, then Groups.
   • Search and select the group to edit.
   • Update the access level assignments for the group's apps.
   • Click Save.

Combining Context-Aware Access with Data Loss Prevention (DLP)

For enhanced security, you can combine Data Loss Prevention (DLP) rules with Context-Aware Access conditions. This means a DLP rule is only enforced if specific contextual conditions are met, providing finer control over sensitive content.

Benefits

• Control file uploads, web content uploads, downloads, and page prints in Chrome.
• Control copying, downloading, and printing of Drive files.
• Example: Block downloads of sensitive content only when users are outside the corporate network, logging in from risky countries, or using non-admin-approved devices.

Requirements

• Google Workspace add-on, Chrome Enterprise Premium (for Chrome DLP), Chrome 105 or later.
• Endpoint verification for desktop devices (for device/OS conditions).
• Mobile devices under basic or advanced management.
• Admin privileges: Data Security > Access Level Management, and/or Services > Data Security > Rule Management.

Setting Up Combined Rules

You can create an access level either before or during DLP rule creation. A single access level can be assigned to a DLP rule, and complex conditions can be built using Advanced mode.

Example: Block download of sensitive content on a device outside the corporate network (Chrome):

1. In the Admin console, go to Rules > Create rule > Data protection.
2. Name and describe the rule. Define the Scope (e.g., All in your domain or specific OUs/groups).
3. In Apps, under Chrome, check File downloaded.
4. In Conditions, add a condition for Content type to scan (e.g., All content) and What to scan for (your DLP scan type and attributes).
5. In Context conditions, click Select an access level > Create new access level.
6. Name and describe the new access level. In Context conditions, click Add condition.
7. Select Doesn't meet 1 or more attributes, then Select attribute > IP subnet, and enter your corporate network's IP address in CIDR notation.
8. Click Create, then Continue on the Create Rule page.
9. On the Actions page, for ChromeOS action, choose Block.
10. Review details, choose a status (Active/Inactive), and click Create.

Important Notes for DLP with CAA: * Rules are only triggered when both content conditions and context conditions are met. * Context conditions are ignored in older Chrome versions. * Rules do not apply in Chrome incognito mode. * If an assigned access level is deleted, context conditions default to true, potentially widening the rule's application. * Context-Aware Access itself does not need to be enabled for access level evaluation in DLP rules; it's independent.

Managing Admin Console Access with CAA

You can apply Context-Aware Access levels to the Google Admin console itself, providing an extra layer of security for administrator access. This helps define the context (e.g., device, location) from which other administrators can access the console.

Caution: Do not assign access levels to the Admin console unless explicitly needed to limit admin access. Always ensure at least one super administrator can access the Customer Care Portal in case of lockout.

Assigning and Updating Access Levels

1. Sign in to the Admin console with an administrator account.
2. Navigate to Security > Access and data control > Context-Aware Access.
3. Find Admin console at the top of the application list and click Assign.
4. Select one or more access levels. Access is granted if an admin meets conditions in any selected access level (logical OR). To require meeting multiple access levels, create a nested access level with a logical AND.
5. Click Save. The system verifies that the access level conditions do not lock out any admins.

Avoiding and Responding to Lockout Scenarios

• Review Access Levels: Before applying, carefully review access levels to ensure at least one admin meets the criteria.
• Configuration Groups: Apply policies to configuration groups that can act as a container for access levels, adding user groups as members to avoid unintended lockouts.
• Support Access: Verify that the designated super admin or support contact can access the Google Customer Care Portal.
• Lockout Response: In a total lockout, contact Google support through the Customer Care Portal. Support can temporarily remove Context-Aware Access policies in the Admin console (only for the Admin console, not other apps). Reapply policies immediately after access is restored.

Editing and Deleting Access Levels for Admin Console

• Editing Restrictions: If an access level is assigned to the Admin console, you can edit its name and description, but not its conditions. To edit conditions, you must first unassign it from the Admin console.
• Deletion Restrictions: You can only delete access levels if doing so does not block access to the Admin console. Non-super admins cannot delete access levels assigned to the Admin console.

Troubleshooting Common Context-Aware Access Issues

When users encounter blocked access, Context-Aware Access provides remediation messages and detailed logs to help administrators troubleshoot.

Remediation Messages

Remediation messages replace default "access denied" messages and provide system-generated guidance corresponding to the policy violation. You can also add custom messages with specific help or links.

To Turn On Remediation Messages:

1. Sign in to the Admin console.
2. Navigate to Security > Access and data control > Context-Aware Access.
3. Select User message.
4. Under Remediation messages, slide the toggle to ON.
5. Click Save.

Common Remediation Messages and Actions: The system generates messages based on the violated attribute. Examples include:

• Admin approval: "Switch to a device approved by your organization."
• Company owned device: "Switch to a device owned by your organization."
• Encryption: "Switch to a device that has one of the following encryption statuses: [status1, status2]."
• IP address: "You can't access this app from your current IP subnetwork."
• Screen lock: "Set a screen password on your device."

Common Errors Before Remediation Messages Display:

• Device not recognized: Users must use a Chrome profile with the Endpoint Verification extension installed and synced (desktop), or have their mobile device managed by Google endpoint management (mobile). Users cannot log in via incognito, guest, or personal profiles.
• Sync Issues: Device sync is crucial. Users might need to force a sync from the Endpoint Verification extension (desktop) or the device policy app (advanced mobile management). iOS users might need to clear Safari tokens and cookies if blocked after logging into Google apps.

Understanding Context-Aware Access Log Events

The Context-Aware Access log events provide valuable data for troubleshooting access issues.

To Run a Search for Log Events:

1. Sign in to the Admin console.
2. Navigate to Reporting > Audit and investigation > Context Aware Access log events.
3. Click Add a filter and select an attribute (e.g., Access level applied, Access level satisfied, Access level unsatisfied, Actor, Application, Event, IP address, Device state).
4. Select an operator and value, then click Apply.
5. Click Search.

Key Attributes in Logs:

• Access level applied: The access levels assigned for the specific app.
• Access level satisfied: Access levels the user successfully met (if any).
• Access level unsatisfied: Access levels the user did not meet. If all applied access levels are in this list, access is denied.
• Event: Indicates whether access was denied, denied in monitor mode, or if an internal error occurred.
• Device state: Shows the state of the device (Normal, Out of sync, Cross organization, No device signals). "No device signals" often means reporting agents like Endpoint Verification or MDM are missing.

For more advanced search and investigation, use the Security Investigation Tool if your Google Workspace edition supports it. This tool allows for more complex queries and actions based on log data.

Frequently Asked Questions (FAQs)

• Why aren't Context-Aware Access policies applied to some users? Users may not have the required Context-Aware Access-supported Google Workspace editions. Verify user licenses in the Admin Console.
• Why don't access levels behave as intended? Verify the access setting in the policy (e.g., Meet attributes vs. Don't meet attributes) is correctly configured.
• What prevents Context-Aware Access from working with Chrome browser? If a device policy is enforced, users must set up Endpoint Verification and ensure Chrome browser sync is turned on.
• Why is a user request denied when CAA is configured correctly? The user might need to force a server-side device state refresh.
• Why shouldn't I use Google Cloud Platform (GCP) to add or change Context-Aware Access levels? If you are a Workspace-only customer, using GCP for this can result in errors and potentially block users due to unsupported attributes.
• Can remediation messages cause additional Access Denied cases? No, enabling or disabling remediation messages does not affect the access status. If messages cannot be generated, the default message displays.
• How long does it take for users to get access after completing remediation actions? Users do not get access until their device syncs with Google servers. This can sometimes take time, and manual sync options are available.

References

• Context-Aware Access FAQ - Google Workspace Admin Help
• Assign Context-Aware access levels to the Admin console - Google Workspace Admin Help
• Context-Aware Access examples for Advanced mode - Google Workspace Admin Help
• Allow users to unblock apps with remediation messages in Context Aware Access - Google Workspace Admin Help
• Deploy Context-Aware Access - Google Workspace Admin Help
• About Context-Aware Access - Google Workspace Admin Help
• Combine DLP rules with Context-Aware Access conditions - Google Workspace Admin Help
• Assign Context-Aware access levels to apps - Google Workspace Admin Help
• Create Context-Aware access levels - Google Workspace Admin Help
• Protect your business with Context-Aware Access - Google Workspace Admin Help
• Context-Aware Access log events - Google Workspace Admin Help
• Context-Aware Access examples for Basic mode - Google Workspace Admin Help
• Use Context-Aware Access with configuration groups - Google Workspace Admin Help