Overview

This topic provides an overview of Key Access Justifications. For information on creating and managing external keys, see Managing Cloud EKM keys.

Overview

Key Access Justifications works by adding a field to your Cloud EKM requests that allows you to view the reason for each request. With select external key management partners, you can automatically approve or deny these requests, based on the justification.

Enabling Key Access Justifications

In order to enable an organization for Key Access Justifications, submit the access request form.

Note: It takes 1-2 weeks for Key Access Justifications to completely turn on in all regions, so we recommend that you avoid using Key Access Justifications on production traffic for the first few weeks after turning it on.

Managing access to your externally-managed keys

Key Access Justifications provides a reason every time your externally-managed keys are accessed. Reasons are only visible when keys are externally-managed. Keys stored in Cloud KMS or Cloud HSM will not show a visible reason when accessed by your service. When a key is stored in your external key manager, you will receive a justification for both service based access (for supported services), as well as direct API access.

Once you are onboarded for Key Access Justifications and use an externally-managed key, you will immediately receive justifications for every key access.

Why would my keys be accessed?

Google Cloud encryption-at-rest works by encrypting your data stored on Google Cloud with an encryption key that lives outside the service where the data is stored. For example, if you encrypt data in Cloud Storage, the service only stores the encrypted information you have stored, whereas the key used to encrypt that data is stored in the Cloud KMS (if you are using customer-managed encryption keys (CMEK)) or in your external key manager (if you are using Cloud External Key Manager).

When you use a Google Cloud service, you want your applications to continue working as described, and this will require your data to be decrypted. For example, if you run a query using BigQuery, the BigQuery service needs to decrypt your data in order to analyze it. In order to do this, BigQuery will need to call the key manager in order to decrypt the data.

For a list of justifications, see Key Access Justifications Reasons.

Viewing and acting on justifications

Whenever your information is encrypted or decrypted, Key Access Justifications sends you a justification describing the reason for the access. Software by our Cloud EKM partners enables you to set policy to automatically approve or deny access based on the content of the justifications. Please see the relevant documentation for your chosen key manager for more information on how to set policy. The following partners support Key Access Justifications:

• Ionic
• Fortanix
• Thales

Note: Denying access can hinder the ability of Google personnel to help you with a contracted service.

- Denying access for reasons of CUSTOMER_INITIATED_ACCESS or GOOGLE_INITIATED_SYSTEM_OPERATION results in your service becoming unavailable.
- Denying access for reasons of CUSTOMER_INITATED_SUPPORT limits the ability of Google personnel to respond to support tickets on the rare occasion that your support ticket requires access to sensitive customer information (support tickets typically do not require this access and our frontline support personnel do not have this access).
- Denying access for GOOGLE_INITIATED_SERVICE reduces service availability and reliability and inhibits Google's ability to recover from outages.

The justification reason codes listed below cover different scenarios than the Access Transparency codes so will not match them.

Justification reason codes

Reason	Description
CUSTOMER_INITIATED_ACCESS	Customer uses their account to perform any access to their own data which is authorized by their own IAM policy.
MODIFIED_CUSTOMER_INITIATED_ACCESS	Customer uses their account to perform any access to their own data which is authorized by their own IAM policy, however a Google administrator has recently reset the superuser account associated with the user's Organization.
GOOGLE_INITIATED_SYSTEM_OPERATION	Google accesses customer data to help optimize the structure of the data or quality for future uses by the customer. This includes accesses for the purposes of indexing, structuring, precomputation, hashing, sharding and caching. This also includes backing up data for disaster recovery or data integrity reasons, and detecting errors that can be remedied from that backup data. Note that where the customer has delegated a managed control plane operation to Google, such as the creation of a managed instance group, all managed operations will show as system operations. Services such as the managed instance group manager that trigger downstream decryption operations do not have access to clear-text customer data.
REASON_NOT_EXPECTED	No reason is expected for this key request as the service in question has never integrated with Key Access Justifications, or is still in Preview and therefore may still have residual methods that call the external key manager but still do not provide a justification.
CUSTOMER_INITIATED_SUPPORT	Customer-initiated support, for example, "Case Number: ####".
GOOGLE_INITIATED_SERVICE	Google-initiated access, for example, to perform system management and troubleshooting, which includes: Backup and recovery from outages and system failures. Investigation to confirm that the customer is not affected by suspected service issues. Remediation of technical issues, such as storage failure or data corruption.
THIRD_PARTY_DATA_REQUEST	Google-initiated access in response to a legal request or legal process, including when responding to legal process from the customer that requires Google to access the customer's own data.
GOOGLE_INITIATED_REVIEW	Google-initiated access for security, fraud, abuse, or compliance purposes, including: Ensuring the safety and security of customer accounts and data. Confirming whether data is affected by an event that may impact account security (for example, malware infections). Confirming whether customer is using Google services in compliance with Google Terms of Service. Investigating complaints by other users and customers, or other signals of abusive activity. Checking that Google services are being used consistently with relevant compliance regimes (for example, anti-money laundering regulations).
REASON_UNSPECIFIED	Key Access Justifications is enabled but no justification is available for the request. This may have been due to a transient error, a bug, or some other circumstance.
No justification field present	Key Access Justifications isn't enabled for this customer.

Key Access Justifications exclusions

Key Access Justifications only applies to:

• Operations on encrypted data. For the fields within a given service that are encrypted by an externally managed key, please see the documentation for the given service you are using.
• The transition from data-at-rest to data-in-use. While Google continues to apply protections to your data-in-use, the Key Access Justifications governs the transition from data-at-rest to data-in-use only
• CMEK exemptions.
  • BigQuery:
    • BigQuery ML and BigQuery BI Engine are excluded.
  • Compute Engine/Persistent Disk
    • Local SSD and auto-restart are excluded.
    • Machine image operations are excluded.

Supported services

Service	Status
BigQuery	GA
Cloud Spanner	GA
Cloud Storage	Preview
Compute Engine	Preview
Google Kubernetes Engine	GA
Persistent Disk	Preview
Pub/Sub	GA

Note: If Key Access Justifications is in Preview for a service, we recommend that you don't use Key Access Justifications in production for that service. You should use Key Access Justifications in production only if it is in GA for a service.

What's next

• Read where you can get support for Key Access Justifications.