A key principle of BeyondCorp Enterprise is "Access to services is granted based on what we know about you and your device." The level of access given to a single user or a single device is dynamically inferred by interrogating multiple data sources. BeyondCorp Enterprise uses this level of trust as part of its decision process.
Access Context Manager is BeyondCorp Enterprise's zero-trust policy engine. Access Context Manager allows administrators to define fine-grained, attribute based access control for applications and Google Cloud resources.
Use access levels to permit access to resources based on contextual information about the request. By using access levels, you can start to organize tiers of trust. For example, you might create an access level called
High_Level that permits requests from a small group of highly-privileged individuals. You might also identify a more general group to trust, such as an IP range that you want to permit requests from. In that case, you might create an access level called
Medium_Level to permit those requests.
One of the key requirements for zero trust access is to only allow access when the device is managed or owned by the company. There are many ways to determine whether a device is corporate-owned, and one way is to determine if a valid certificate, issued by the company, exists on the device. The existence of an enterprise certificate on a device can be used to indicate that the device is corporate-owned.
Enterprise certificates for context-aware access is a feature of the overall BeyondCorp Enterprise certificate-based access solution. This feature leverages device certificates as an alternative context-aware signal to determine if a device is a corporate-owned asset.
Because a device can have more than one certificate, enterprise certificates can be accessed in the custom access level through macros
In the example,
cert is a simple identifier to be used in
predicator which binds to the device certificate. The
exist() macro combines per-element predicate results with the "or" (||) operator, meaning that macros return true if at least one certificate satisfies the
The certificate has the following attributes that can be checked together. Note that string comparisons are case sensitive.
|Attribute||Description||Example of predicate expression (where
||True if the certificate is valid and not expired (boolean).||
||Fingerprint of the certificate (base64 unpadded SHA256).||
||Fingerprint of the Root CA certificate used to sign the certificate (base64 unpadded SHA256).||
||Issuer name (fully expanded names).
To find the issuer name, you can use the following approach:
Run the following command on the certificate:
The issuer string used in the access level is the reverse of the output and the / replaced by a comma. Example:
||Subject name of the certificate (fully expanded names).||
||Serial number of the certificate (string).||
||Template ID of the X.509 extension Certificate Template for the certificate (string).|
The following table contains examples of policies that you can set:
|Device has a valid certificate signed by the company root certificate.||
|Device has a valid certificate issued by issuer
Configuring enterprise certificates
Before configuring enterprise certificates, ensure you have configured custom access levels, Creating a custom access level.
You can use an Access Context Manager custom access level definition to set the appropriate policies. Custom access levels use boolean expressions written in a subset of Common Expression Language (CEL) to test the attributes of a client making a request.
Uploading trust anchors in the Admin console
In order for BeyondCorp Enterprise to collect and validate the device enterprise certificate, you must upload the trust anchors that are used to issue the device certificate. The trust anchors here refer to the self signed root CA (Certification Authority) certificate and the relevant intermediate and subordinate certificates. Complete the following steps to upload the trust anchors:
- Go to the Admin console and navigate to Devices > Networks > Certificates.
- Select the appropriate organizational unit.
- Select Add Certificate.
- Enter the certificate name.
- Upload the certificate.
- Enable the Endpoint Verification checkbox.
- Click Add.
- Ensure users belong to the organizational unit for which the trust anchors are uploaded.
Configure an AutoSelectCertificateForUrls policy
For Endpoint Verification to search the device certificate and collect it through Chrome, you must configure the AutoSelectCertificateForURLs chrome policy by completing the following steps:
- Ensure that the Chrome browser is managed by Chrome browser cloud management or Windows group policy.
- [Win/OSX/Linux] Setup for managed chrome browser using CBCM https://support.google.com/chrome/a/answer/9301891.
- [Chrome] Enroll the device to the enterprise.
In the Admin console, add the AutoSelectCertificateForUrls policy:
- Go to the Admin console and navigate to Devices > Chrome > Settings > User & Browser Settings > Client certificates.
- Select the appropriate organizational unit.
- Add a policy (AutoSelectCertificateForUrls, as demonstrated in the following example:
NOTE: The filter should refer to an issuer certificate, uploaded in the previous steps.
To verify the policy configuration, complete the following steps:
- Navigate to chrome://policy in the browser.
- Verify the configured value for AutoSelectCertificateForUrls.
- Ensure that the policy Applies to value is set to Machine. On the Chrome operating system, the value is applied to Current User*.
- Ensure that the Status for the policy does not have a Conflict.
Troubleshooting your configuration
Review the certificate attributes on the device details page to ensure that certificate attributes are listed correctly
You can use the Endpoint Verification logs to help you troubleshoot any issues. To download the Endpoint Verification logs, complete the following steps:
- Right-click on the Endpoint Verification extension and then go to Options.
- Select Log level > All > Download Logs.
- Open a support case with Cloud Customer Care and share the logs for further debugging.