Introduction to Advanced Key Management
For organizations with stringent regulatory requirements or those operating in highly regulated industries (like finance or government), standard software-based keys may not be sufficient.
Google Cloud provides two primary paths for enhanced key security: Cloud HSM, which keeps keys within Google-managed hardware, and Cloud EKM, which keeps keys entirely outside of Google Cloud.
白話文解釋（Plain English Explanation）
Analogy 1: The Hotel Safe vs. Your Own Bank Vault
Imagine you're staying at a luxury hotel (Google Cloud) and need to store valuables. Cloud HSM is like the in-room safe — the hotel built it, the hotel maintains it (FIPS 140-2 Level 3 certified), but only you know the combination. It's convenient and fast, but the safe sits inside the hotel building. Cloud EKM is like keeping your valuables in your own bank vault across town (Fortanix, Thales, Equinix, or Virtru). Every time the hotel concierge wants something from your vault, they have to call you, state exactly why (the Key Access Justifications code), and wait for your bank to slide a temporary key across the wire. If your bank closes, the hotel can't open the box — that's the kill switch in action.
Analogy 2: The Notary Stamp on Every Request
Picture Key Access Justifications (KAJ) as a courier service where every package comes with a notarised reason slip. When BigQuery asks your EKM for a key, the request arrives stamped with CUSTOMER_INITIATED_ACCESS, GOOGLE_INITIATED_SERVICE_MAINTENANCE, or one of the other defined justification codes. Your external key manager is the notary who reads the slip and decides whether to hand over the key. No slip, no key. Wrong slip, no key. This is how a Swiss bank can confidently say "Google support cannot read our data even if they wanted to" — because the notary (your EKM) physically refuses to stamp GOOGLE_INITIATED_SERVICE_MAINTENANCE requests.
Analogy 3: The Tethered Spacecraft
Cloud HSM is like a spacecraft with onboard life support — self-contained, low-latency, highly available (Google runs the cluster). Cloud EKM is a spacecraft tethered by an umbilical cable to a ground station you operate. Cut the cable (revoke EKM access) and the spacecraft (your encrypted data in BigQuery, GCS, Compute Engine) can no longer breathe — every read/write fails. This is powerful for Schrems II and ITAR compliance, but it means your EKM's uptime directly becomes your data's uptime. Tether it well: VPC connectivity via Service Directory beats raw internet, and multi-region EKM deployment is non-negotiable.
Cloud HSM: Hardware-Rooted Security
Cloud HSM is a managed service that allows you to host encryption keys in FIPS 140-2 Level 3 certified Hardware Security Modules.
Key Characteristics of Cloud HSM:
- No Infrastructure Management: Google manages the HSM cluster, ensuring high availability and automatic scaling.
- FIPS 140-2 Level 3: This level requires physical tamper-resistance and identity-based authentication.
- Integration: Works seamlessly with services that support CMEK (Cloud Storage, BigQuery, Compute Engine).
- Regional and Multi-regional: You can create HSM keys in specific regions to meet data residency requirements.
Unlike Software keys, Cloud HSM keys ensure that the cryptographic material never leaves the HSM boundary in plaintext, even during use. The HSM cluster behind Cloud HSM is certified to FIPS 140-2 Level 3, which requires physical tamper-evidence, identity-based operator authentication, and zeroisation of plaintext keys on tamper detection — a bar that pure software keys (FIPS 140-2 Level 1/2) cannot reach.
FIPS 140-2 Levels at a glance for the PSE exam: Level 1 = basic software; Level 2 = role-based auth + tamper-evident seals; Level 3 = identity-based auth + tamper-resistant hardware (Cloud HSM); Level 4 = environmental attack resistance. If the scenario mentions "FIPS 140-2 Level 3" or "hardware-rooted keys inside Google" → answer is Cloud KMS with HSM protection level. If it adds "keys must reside outside Google" → escalate to Cloud EKM.
Cloud EKM: External Key Control and Sovereignty
Cloud External Key Manager (EKM) allows you to protect data in Google Cloud using keys that reside in an external system managed by you, outside of Google's infrastructure.
Why use Cloud EKM?
- Data Sovereignty: You maintain physical control over your keys.
- External Authorization: Every time Google Cloud needs to encrypt or decrypt data, it must request permission from your external key manager.
- Kill Switch: If you revoke access or shut down your EKM, Google Cloud can no longer access your encrypted data.
Connectivity Options:
- EKM over Internet: Communication occurs over the public internet (secured by TLS).
- EKM over VPC: Communication occurs over a private VPC connection using Service Directory, providing lower latency and higher security by avoiding the public internet.
Cloud EKM is a service that enables Google Cloud to use keys stored in a third-party external key management system (e.g., Thales, Fortanix) to protect data at rest.
Cloud EKM only operates with Google-validated partner key managers: Fortanix Data Security Manager, Thales CipherTrust Manager, Equinix SmartKey, and Virtru. You cannot point Cloud EKM at an arbitrary REST endpoint — the partner has implemented the EKM API contract (including KAJ justification verification and the wrapped-DEK protocol) and been certified by Google. When choosing a partner, match the deployment model to your sovereignty requirement: Equinix SmartKey for colocation-based HSMs adjacent to Google PoPs, Fortanix/Thales for on-prem or your own colo, Virtru for collaboration-centric flows.
Key Access Justifications (KAJ)
Key Access Justifications (KAJ) is a unique feature of Cloud EKM that provides a "reason code" for every key request.
How KAJ Works:
- When a Google Cloud service (like BigQuery) needs to decrypt data, it sends a request to your EKM.
- The request includes a Justification (e.g.,
CUSTOMER_INITIATED_ACCESSorGOOGLE_INITIATED_SERVICE_MAINTENANCE). - Your EKM evaluates this justification against a policy you define.
- If the justification is denied, the EKM refuses to provide the key material, and the data remains encrypted.
KAJ is the ultimate tool for Administrative Privacy. It allows you to programmatically block Google personnel from accessing your data, even for support or maintenance purposes, unless you explicitly allow it.
Do not confuse "EKM over VPC" with sending traffic over your regular VPC peering. Cloud EKM over VPC requires registering your external key manager (e.g., Fortanix DSM, Thales CipherTrust, Equinix SmartKey) as a Service Directory endpoint, and the traffic flows over a Google-managed private path — not your standard VPC peering or Cloud Interconnect. Candidates also routinely answer "Cloud HSM" when the scenario says "keys must never reside inside the cloud provider's infrastructure" — but Cloud HSM keys do sit in Google-operated HSMs. Only Cloud EKM keeps the key material truly external.
Comparing Protection Levels
| Feature | Software Keys | Cloud HSM | Cloud EKM |
|---|---|---|---|
| Storage Location | Google Software | Google HSM | Your External HSM |
| Compliance | FIPS 140-2 L2 (Internal) | FIPS 140-2 L3 | Varies by EKM provider |
| Control | Google-managed | Google-managed | Customer-managed |
| Latency | Lowest | Low | Higher (Network dependent) |
| Availability | Highest | Very High | Dependent on your EKM |
Managing External Key Availability and Latency
Using EKM introduces a dependency on external infrastructure.
- Availability: If your EKM goes offline, your Google Cloud services using those keys will fail. You must ensure your EKM is highly available across multiple regions.
- Latency: The round-trip time between Google Cloud and your EKM adds to the operation time. VPC connectivity is recommended to minimize this.
Regulatory Requirements and Compliance
- ITAR/EAR: Cloud EKM is often used to meet US export control requirements.
- Schrems II / GDPR: For European customers, EKM provides a mechanism to ensure that data remains protected from foreign government access requests.
Auditing EKM Requests
Auditability is a core component of EKM.
- Cloud Audit Logs: Google logs the request and the justification sent.
- EKM Logs: Your external manager logs the receipt of the request and your decision (Allow/Deny).
- Reconciliation: You can compare Google's logs with your EKM logs to ensure no unauthorized requests were attempted.
Integration with Partners
Google Cloud EKM integrates with industry-leading providers:
- Thales (CipherTrust Manager)
- Fortanix (Data Security Manager)
- Equinix (SmartKey)
- Virtru
PSE Exam Scenarios
Scenario 1: Strict Regulatory Compliance
"A bank in Switzerland requires that their encryption keys never reside within a cloud provider's physical infrastructure and that they must be able to deny access to Google for any reason. Which solution should they use?" Answer: Cloud EKM with Key Access Justifications (KAJ). This ensures keys are external and provides granular control over every access request.
Scenario 2: FIPS 140-2 Level 3 Requirement
"A government agency requires that all data at rest be encrypted with keys stored in a hardware module that meets FIPS 140-2 Level 3. They prefer a fully managed solution within Google Cloud to minimize operational overhead. What should you recommend?" Answer: Cloud KMS with the Hardware (HSM) protection level.
Summary Checklist
- Differentiate between Cloud HSM and Cloud EKM protection levels.
- Explain the role of Key Access Justifications (KAJ) in administrative privacy.
- Describe the two connectivity options for Cloud EKM (Internet vs. VPC).
- List the risks associated with EKM (Latency and Availability).
- Identify which FIPS level is associated with Cloud HSM.