Cloud External Key Manager — Keys Ngoài Hạ Tầng Google

Tại sao EKM tồn tại

Cloud KMS với SOFTWARE hoặc HSM protection level bảo vệ key material khỏi unauthorized access rất tốt. Nhưng nó không trả lời được một câu hỏi chính của certain regulated industries:

"Làm thế nào để tôi biết Google không thể access key material của tôi?"

Với SOFTWARE/HSM keys, key material tồn tại trong Google's infrastructure — được bảo vệ bởi Google's security controls, nhưng vẫn là Google's infrastructure. Một số use cases đòi hỏi cao hơn: key material phải nằm dưới kiểm soát vật lý và kỹ thuật hoàn toàn của customer, không bao giờ đến Google.

Cloud External Key Manager (Cloud EKM) giải quyết requirement này bằng cách cho phép Cloud KMS làm proxy đến external key management system do customer hoặc third-party vận hành. Key material không bao giờ rời external KMS.

Tuy nhiên — và đây là điểm quan trọng — EKM là double-edged sword. Kiểm soát cao hơn đồng nghĩa với rủi ro cao hơn nếu external KMS bị down hoặc key bị mất.

Internal model — Cơ chế hoạt động

Encryption với EXTERNAL key

REQUEST: Encrypt(plaintext, key=external-key-ref)

1. Cloud KMS generate internal key material (AES-256)
   [internal_material được lưu trong Cloud KMS, không ra ngoài]

2. Cloud KMS gửi request đến External KMS:
   External KMS wrap internal_material bằng external key material
   → encrypted_internal_material
   [external key material không bao giờ đến Cloud KMS]

3. Cloud KMS store: (encrypted_internal_material)
   [Cloud KMS không có plaintext của internal material khi external KMS offline]

4. Cloud KMS encrypt plaintext với internal_material:
   ciphertext = Encrypt(plaintext, key=internal_material)

5. Xóa plaintext internal_material khỏi memory
6. Return ciphertext đến caller

Mấu chốt của thiết kế: Cloud KMS lưu encrypted_internal_material nhưng không thể giải mã nó mà không gọi external KMS. Khi external KMS không available, Cloud KMS không thể unwrap internal_material → không thể decrypt bất cứ gì.

Decryption với EXTERNAL key

REQUEST: Decrypt(ciphertext, key=external-key-ref)

1. Cloud KMS fetch encrypted_internal_material từ storage

2. Cloud KMS gọi External KMS để unwrap:
   External KMS: Unwrap(encrypted_internal_material, external_key)
   → internal_material_plaintext
   [external KMS phải available cho step này]

3. Cloud KMS decrypt ciphertext:
   plaintext = Decrypt(ciphertext, key=internal_material_plaintext)

4. Xóa internal_material_plaintext khỏi memory

5. Return plaintext đến caller

Mọi crypto operation đều yêu cầu external KMS online. Không có caching của internal material trong Cloud KMS — đây là intentional design để đảm bảo "hold your own key" property thực sự.

EXTERNAL vs EXTERNAL_VPC protection levels

EXTERNAL

External KMS được truy cập qua internet công cộng.

Cloud KMS → internet → External KMS endpoint (HTTPS/TLS)

Đặc điểm:

Setup đơn giản hơn (chỉ cần HTTPS endpoint)
Latency phụ thuộc hoàn toàn vào internet path
Availability phụ thuộc vào internet connectivity
Phù hợp khi external KMS là SaaS (Thales, Fortanix, Equinix, ...)

EXTERNAL_VPC

External KMS được truy cập qua VPC network của customer.

Cloud KMS → VPC peering → Customer's VPC → Hybrid connectivity (VPN/Interconnect) → On-prem EKM

Cần cấu hình EKM Connection resource trong Cloud KMS:

bash

# Tạo EKM Connection
gcloud kms ekm-connections create my-ekm-connection \
  --location=us-central1 \
  --hostname=ekm.my-company.internal \
  --service-resolvers="[:my-ekm-service-resolver]" \
  --key-management-mode=MANUAL

Đặc điểm:

Latency ổn định hơn (không qua public internet)
Cần hybrid connectivity (Cloud VPN hoặc Cloud Interconnect) → thêm chi phí và complexity
Phù hợp khi external KMS là on-premises infrastructure
Cần EKM Connection resource để cấu hình network path

Key material flow — điều làm EKM độc đáo

Với SOFTWARE/HSM keys:

Data đến → Cloud KMS encrypt (key material trong Google infra) → Ciphertext

Với EXTERNAL keys:

Data đến → Cloud KMS encrypt với internal material
         → internal material được bảo vệ bởi external key (chỉ external KMS biết)
         → Nếu external KMS offline: ciphertext không thể decrypt

"Hold Your Own Key" (HYOK) model: Bạn giữ external key material, Google giữ encrypted data — nhưng Google không thể decrypt data mà không có sự tham gia của your external KMS.

Đây là fundamental shift so với CMEK thuần:

CMEK (SOFTWARE/HSM): Bạn kiểm soát key lifecycle trong Google's infrastructure; Google có thể revoke access nhưng key material vẫn trong Google's system
EKM: Key material không bao giờ trong Google's system; Google phải hỏi external KMS mỗi lần cần decrypt

Availability implications — đây là rủi ro thực sự

EKM availability = data availability

Với EKM, nếu external KMS không available:

Không thể encrypt data mới
Không thể decrypt data cũ
GCP services using CMEK với external key sẽ fail

Ví dụ impact:

Cloud SQL với CMEK EKM key: database không thể read/write khi external KMS down
Cloud Storage: object access fails
Cloud Spanner: tự động xóa database sau 30 ngày nếu key không accessible

Google documentation warn rõ:

"If you lose keys that you manage outside of Google Cloud, Google can't recover your data."

Single point of failure

Nếu không có HA cho external KMS, nó trở thành single point of failure cho toàn bộ data stack của bạn. Irony: nhiều team implement EKM để tăng security, nhưng vô tình giảm availability.

Minimum requirements cho production EKM:

External KMS deployment phải HA (multi-zone/multi-region)
Network path đến external KMS phải redundant
External KMS phải có SLA cao hơn hoặc bằng SLA của data services dùng nó
Có fallback/break-glass procedure khi external KMS không accessible

Latency impact

Mỗi encrypt/decrypt operation với EKM cần một round-trip đến external KMS. Với EXTERNAL (internet), latency có thể là 10-100ms. Với EXTERNAL_VPC (VPN/Interconnect), latency thường 5-50ms.

So sánh:

SOFTWARE key: <1ms (local to KMS infrastructure)
HSM key: 1-5ms
EXTERNAL key (VPC): 5-50ms
EXTERNAL key (internet): 10-100ms

Với high-throughput workloads (nhiều small encrypt/decrypt operations per second), EKM latency có thể trở thành bottleneck.

Khi nào thực sự cần EKM

EKM là over-engineering cho phần lớn use cases. Nên dùng chỉ khi có một trong các điều kiện sau:

1. Regulatory requirement chỉ định rõ "customer holds key material"

Một số regulations (FedRAMP High, certain banking regulations, EU Sovereignty requirements) yêu cầu customer controls key material và có thể physically prevent key access. CMEK với SOFTWARE/HSM không satisfy requirement này vì key material vẫn trong Google's infrastructure.

2. Legal obligation để có thể disable data access

Trong môi trường với potential government requests (ví dụ: international data disputes), EKM cho phép bạn disable access đến data của Google Cloud mà không cần Google's cooperation — chỉ cần take external KMS offline.

3. Multi-cloud với unified key management

Nếu tổ chức đã có HashiCorp Vault, Thales, hoặc similar KMS system serve cả on-prem và multi-cloud, EKM cho phép Google Cloud data dùng cùng key management infrastructure, tránh fragmentation.

Khi không nên dùng EKM

Bạn cần "kiểm soát nhiều hơn đối với key" → CMEK với Cloud KMS là đủ
Bạn muốn audit key usage → Cloud Audit Logs với CMEK là đủ
Bạn lo Google có thể access key → CMEK với HSM cung cấp strong protection nhưng key vẫn trong Google infra
Compliance requirement chỉ nói "customer-managed" nhưng không require "outside Google" → CMEK

Supported operations với EKM keys

EKM keys hỗ trợ:

Symmetric ENCRYPT_DECRYPT: CMEK cho GCP services, direct API encryption
ASYMMETRIC_SIGN: Digital signing operations
ASYMMETRIC_DECRYPT: Asymmetric decryption

Không hỗ trợ automatic rotation (không thể auto-rotate key material trong external KMS). Rotation phải là manual process.

EKM partners và integration

Cloud EKM hỗ trợ integration với các external KMS partners được Google certify:

Thales CipherTrust: Enterprise KMS, phổ biến nhất trong banking/finance
Fortanix: Cloud-native KMS, hỗ trợ confidential computing
Equinix: Colocation-based KMS
Futurex: Compliance-focused HSM/KMS
Atos: European enterprise KMS

Tất cả partners cần implement Cloud EKM API specification của Google (RESTful API với PKCS#11 semantics).

Monitoring EKM

Vì EKM phụ thuộc vào external service, monitoring phải cover cả hai phía:

bash

# Monitor Cloud KMS errors liên quan đến EKM
gcloud logging read \
  'resource.type="cloudkms_cryptokey" AND
   protoPayload.status.code!="0" AND
   protoPayload.request.@type:"CryptoKeyVersion"' \
  --format=json

Alert trên:

FAILED_PRECONDITION errors từ KMS (thường là external KMS unavailable)
Latency percentile (p99) của KMS operations tăng đột biến
External KMS endpoint health checks

Cloud External Key Manager — Keys Ngoài Hạ Tầng Google ​

Tại sao EKM tồn tại ​

Internal model — Cơ chế hoạt động ​

Encryption với EXTERNAL key ​

Decryption với EXTERNAL key ​

EXTERNAL vs EXTERNAL_VPC protection levels ​

EXTERNAL ​

EXTERNAL_VPC ​

Key material flow — điều làm EKM độc đáo ​

Availability implications — đây là rủi ro thực sự ​

EKM availability = data availability ​

Single point of failure ​

Latency impact ​

Khi nào thực sự cần EKM ​

1. Regulatory requirement chỉ định rõ "customer holds key material" ​

2. Legal obligation để có thể disable data access ​

3. Multi-cloud với unified key management ​

Khi không nên dùng EKM ​

Supported operations với EKM keys ​

EKM partners và integration ​

Monitoring EKM ​

References ​