Overview
This page provides an overview of Key Access Justifications. Key Access Justifications lets you set a policy on Cloud Key Management Service (Cloud KMS) keys to view, approve, and deny key access requests depending on the provided justification code. For select external key management partners, you can configure Key Access Justifications policies outside of Google Cloud to be exclusively enforced by the external key manager rather than by Cloud KMS. Key Access Justifications works with the following Cloud KMS key types depending on which Assured Workloads control package you select:
How encryption at rest works
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 Cloud KMS (if you are using customer-managed encryption keys (CMEK)) or in your external key manager (if you are using Cloud EKM).
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 to be able to analyze it. BigQuery accomplishes this by making a decryption request to the key manager to get the required data.
Why would my keys be accessed?
Your encryption keys are most often accessed by automated systems while servicing your own requests and workloads on Google Cloud.
In addition to customer-initiated accesses, a Google employee might need to initiate operations which use your encryption keys for the following reasons:
Optimize the structure or quality of data: Google systems might need to access your encryption keys to index, structure, precompute, hash, shard, or cache your data.
Back up your data: Google might need to access your encryption keys to back up your data for disaster recovery reasons.
Resolve a support request: A Google employee might need to decrypt your data to fulfill the contractual obligation of providing support.
Manage and troubleshoot systems: Google personnel can initiate operations which use your encryption keys to perform technical debugging needed for a complex support request or investigation. Access might also be needed to remediate storage failure or data corruption.
Ensure data integrity and compliance, and protect against fraud and abuse: Google might need to decrypt data for the following reasons:
- To ensure the safety and security of your data and accounts.
- To make sure that you are using Google services in compliance with the Google Cloud Terms of Service.
- To investigate complaints by other users and customers, or other signals of abusive activity.
- To verify that Google Cloud services are being used in accordance with applicable regulatory requirements, such as anti-money laundering regulations.
Maintain system reliability: Google personnel can request access to investigate that a suspected service outage doesn't affect you. Also, access might be requested to ensure backup and recovery from outages or system failures.
For the list of justification codes, see justification reason codes for Key Access Justifications.
Managing access to your externally managed keys
Key Access Justifications provides a reason every time your externally managed keys are accessed. Reasons are only provided when keys are externally managed. Accesses to keys stored in Cloud KMS or Cloud HSM don't provide a reason. When a key is stored in your external key manager, you receive a justification for both service-based access (for supported services) and direct API access.
After you are enrolled in Key Access Justifications and using an externally managed key, you immediately receive justifications for every key access.
If you are using Key Access Justifications and Access Approval with an external customer-managed key, administrative access requests can't be processed unless the approvals are signed with the externally managed key after passing a Key Access Justifications policy check for the signing request. All access approvals that are signed by the key appear in Access Transparency logs.
Enabling Key Access Justifications
Key Access Justifications can only be used with Assured Workloads, and is enabled by default when you create a new Assured Workloads folder configured for a control package that includes Key Access Justifications. See the Assured Workloads overview for more information.
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 a customer-managed key, refer to the service's documentation.
- The transition from data-at-rest to data-in-use. While Google continues to apply protections to your data-in-use, Key Access Justifications only governs the transition from data-at-rest to data-in-use.
- The following Compute Engine and Persistent Disk features are exempted when used with CMEK:
What's next
- See services supported by Assured Workloads for EU Regions and Support with Sovereignty Controls and the list of additional KAJ-supported services.
- Read how to view and act on justifications.
- Read where you can get support for Key Access Justifications.
- Learn what an Access Approval request looks like.
- Learn about the core principles upon which controls that prevent unauthorized administrative access are based.