Context-Aware Access overview

This page describes the basic concepts of Context-Aware Access.

Based on the BeyondCorp security model, Context-Aware Access is an approach that utilizes a variety of Google Cloud offerings to enforce granular access control based on a user's identity and context of the request.

For example, depending on the policy configuration, your sensitive app or resource can:

  • Grant access to all employees if they're using a trusted corporate device from your corporate network.
  • Grant access to employees in the Remote Access group if they're using a trusted corporate device with a secure password and up-to-date patch level, from any network.
  • Only grant access to employees in the Privileged Access group if the URL path starts with /admin.

When to use Context-Aware Access

Use Context-Aware Access when you want to establish fine-grained access control based on a wide range of attributes and conditions including what device is being used and from what IP address. Making your corporate resources context-aware improves your security posture.

You can also apply Context-Aware Access to G Suite apps. For more information about implementing Context-Aware Access with G Suite, see the G Suite overview.

How Context-Aware Access works

Implementing Context-Aware Access enacts a zero trust model. No one can access your resources unless they meet all the rules and conditions. Instead of securing your resources at the network-level, access controls are instead put on individual devices and users.

IAP is the base of Context-Aware Access, letting you grant members access to your HTTPS apps and resources. Once you've secured your apps and resources behind IAP, your organization can gradually extend Context-Aware Access as richer rules are needed. Extended Context-Aware Access resources can limit access based on properties like user device attributes, time of day, and request path.

Context-Aware Access works by leveraging four Google Cloud offerings:

Context-Aware Access flow

Gathering device information

Endpoint Verification gathers employee device information including encryption status, OS, and user details. Once enabled through the G Suite Google Admin console, you can deploy the Endpoint Verification Chrome extension to corporate devices. Employees can also install it on their managed, personal devices. This extension gathers and reports device information, constantly syncing with G Suite. The end result is an inventory of all the corporate and personal devices accessing your corporate resources.

Limiting access

Through Access Context Manager, access levels are created to define access rules. Access levels applied on your resources with IAM Conditions enforce fine-grained access control based on a variety of attributes.

Access levels restrict access based on the following attributes:

When you create a device-based access level, Access Context Manager references the inventory of devices created by Endpoint Verification. For example, an access level can restrict access to only employees who are using encrypted devices. Coupled with IAM conditions, you could make this access level more granular by also restricting access to the time between 9am and 5pm.

Securing resources with IAP

IAP ties everything together by letting you apply IAM conditions on Google Cloud resources. IAP lets you establish a central authorization layer for your Google Cloud resources accessed by HTTPS and SSH/TCP traffic. With IAP, you can establish a resource-level access control model instead of relying on network-level firewalls. Once secured, your resources are accessible to any employee, from any device, on any network, that meets the access rules and conditions.

Applying IAM conditions

IAM Conditions allow you to define and enforce conditional, attribute-based access control for Google Cloud resources.

With IAM Conditions, you can choose to grant permissions to members only if configured conditions are met. IAM Conditions can limit access with a variety of attributes, including access levels.

Conditions are specified in the IAP role bindings of a resource's IAM policy. When a condition exists, the role is only granted if the condition expression evaluates to true. Each condition expression is defined as a set of logic statements allowing you to specify one or many attributes to check.

What's next