Overview

Stay organized with collections Save and categorize content based on your preferences.

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

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.

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

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

Viewing justifications in the Google Cloud console

You can also use the Google Cloud console to view the justification Key Access Justifications sends to your external key manager when your data is accessed. In order to access the justification, you first need to enable Cloud Audit Logs with Cloud KMS on the project containing the key used for encryption.

After you have completed the setup, the Cloud Audit Logs also includes the justitication used in the external request for cryptographic operations. The justification shows up as part of the Data Access logs on the resource key, in the protoPayload's metadata entries. For more information on these fields, see Understanding audit logs. For more information about using Cloud Audit Logs with Cloud KMS, see Cloud KMS audit logging information.

Note that unlike the justification shared with the external key manager, the justification in the Cloud Audit Logs cannot be used for approving or denying the associated cryptographic operation. Google Cloud logs the justification only after the operation is completed. Therefore, the logs in Google Cloud must be used primarily for record keeping.

Justification reason codes

Reason Description
CUSTOMER_INITIATED_ACCESS Customer uses their account to perform any access to their own data which their IAM policy authorizes. These accesses include operations that are executed indirectly on behalf of or in response to customer resource activity, such as logging.
MODIFIED_CUSTOMER_INITIATED_ACCESS Customer uses their account to perform any access to their own data which their IAM policy authorizes. These accesses include operations that are executed indirectly on behalf of or in response to customer resource activity, such as logging.

At the same time, one of the following is true: * A Google administrator has reset the root-access account associated with the user's organization within the past 7 days. * A Google-initiated emergency access operation has interacted with a resource in the same project or folder as the currently accessed resource within the past 7 days.

GOOGLE_INITIATED_SYSTEM_OPERATION Google systems access customer data to help optimize the structure of the data or quality for future uses by the customer. These accesses can be for indexing, structuring, precomputation, hashing, sharding and caching customer data. This also includes backing up data for disaster recovery or data integrity reasons, and detecting errors that the backup data could remedy. Certain operations such as key health checks are initiated by Google systems in direct response to customer resource activity but can generate a GOOGLE_INITIATED_SYSTEM_OPERATION justification due to the architecture of the systems involved. Key accesses with this justification are always in service of a customer workload.

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.
MODIFIED_GOOGLE_INITIATED_SYSTEM_OPERATION Google systems access customer data to help optimize the structure of the data or quality for future uses by the customer. These accesses can be for indexing, structuring, precomputation, hashing, sharding and caching customer data. This also includes backing up data for disaster recovery or data integrity reasons, and detecting errors that the backup data could remedy. Certain operations such as key health checks are initiated by Google systems in direct response to customer resource activity but can generate a GOOGLE_INITIATED_SYSTEM_OPERATION justification due to the architecture of the systems involved. Key accesses with this justification are always in service of a customer workload.

At the same time, one of the following is true: * A Google administrator has reset the root-access account associated with the user's organization within the past 7 days. * A Google-initiated emergency access operation has interacted with a resource in the same project or folder as the currently accessed resource within the past 7 days.

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 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 due to there being at least on service involved in servicing the request which has one of the following characteristics:

  • The service has never integrated with Key Access Justifications.
  • The service has partially integrated with Key Access Justifications but this integration is still in Preview. Portions of such services might not be completely integrated with Key Access Justifications, which can lead to justifications not being producible.

Note that while a REASON_NOT_EXPECTED justification carries the aforementioned meaning, services which have not yet reached the GA status for their Key Access Justifications integration might also generate other justifications including REASON_UNSPECIFIED. Google makes no guarantees regarding the justifications generated while using services which are not Key Access Justifications GA.
CUSTOMER_INITIATED_SUPPORT Customer-initiated support, for example, "Case Number: ####".
GOOGLE_INITIATED_SERVICE

Refers to Google-initiated access for system management and troubleshooting. Google personnel can make this type of access for the following reasons:

  • To perform technical debugging needed for a complex support request or investigation.
  • To remediate 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 might 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).
GOOGLE_RESPONSE_TO_PRODUCTION_ALERT

Refers to Google-initiated access to maintain system reliability. Google personnel can make this type of access for the following reasons:

  • To investigate and confirm that a suspected service outage doesn't affect the customer.
  • To ensure backup and recovery from outages and system failures.
REASON_UNSPECIFIED

You have Key Access Justifications enabled but no justification is available for this request. The reason could be a transient error, a bug, or some other circumstance.

To reduce operational risk of an outage resulting from the denial of a request with `REASON_UNSPECIFIED` justification, we recommend that you allow `REASON_UNSPECIFIED` in your Key Access Justifications policies.
No justification field present Key Access Justifications isn't enabled for you.

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 Bigtable GA
Cloud Logging GA
Cloud Spanner GA
Cloud Storage GA
Cloud SQL GA
Compute Engine GA
Google Kubernetes Engine GA
Persistent Disk GA
Pub/Sub GA

If Key Access Justifications is in Preview for a service, Google recommends that you don't use Key Access Justifications in production for that service. You should use Key Access Justifications for a service in production only if Key Access Justifications for that service is in General Availability (GA). This includes transitive usage of unintegrated or Preview services that do not themselves store data encrypted using customer keys, because all services involved in servicing a request must have a GA Key Access Justifications integration status for Google to reliably generate justifications. If you are unable to avoid using a service for which Key Access Justifications is not in GA in your workloads that depend on Key Access Justifications, then you must also allow REASON_NOT_EXPECTED and REASON_UNSPECIFIED justifications in your Key Access Justifications policies or risk outages.

What's next