My Awesome Project

Appearance

Encryption: Google-Managed & CMEK ​

Encryption mặc định: không phải tùy chọn ​

Điều quan trọng đầu tiên: tất cả data trên Persistent Disk và Hyperdisk đều được mã hóa at-rest theo mặc định, không cần cấu hình thêm gì. Đây không phải feature cần bật — đây là behavior mặc định và không thể tắt.

Ngay cả khi một physical disk bị lấy ra khỏi datacenter Google, data trên đó không thể đọc được vì encryption key không có trên disk.

Kiến trúc mã hóa hai tầng ​

GCP dùng envelope encryption — một pattern phổ biến trong distributed systems:

Data (plaintext)
    │
    ▼ mã hóa bởi
Data Encryption Key (DEK)
    │
    ▼ mã hóa bởi
Key Encryption Key (KEK) ← đây là CMEK nếu bạn dùng CMEK
                          ← đây là Google-managed key nếu dùng mặc định

Tại sao dùng hai tầng thay vì mã hóa trực tiếp?

  1. Performance: DEK là AES-256 symmetric key, mã hóa/giải mã data nhanh. KEK (RSA hoặc AES) chỉ mã hóa DEK nhỏ, không mã hóa toàn bộ data.

  2. Key rotation: Khi cần rotate KEK, chỉ cần re-encrypt DEK với KEK mới — không cần re-encrypt toàn bộ data. Re-encrypt data TB/PB tốn nhiều I/O và thời gian; re-encrypt DEK nhỏ thì nhanh hơn nhiều.

  3. Access revocation: Thu hồi access bằng cách revoke KEK (qua Cloud KMS), tất cả DEKs được bảo vệ bởi KEK đó lập tức không giải mã được — hiệu quả ngay lập tức mà không cần xóa data.

Google-managed encryption (mặc định) ​

Với Google-managed encryption, toàn bộ key lifecycle được Google quản lý:

  • KEK được tạo và lưu trữ trong Google's internal key management infrastructure
  • Key rotation xảy ra tự động
  • Keys không bao giờ expose ra ngoài Google's security boundary
  • Google không thể access customer data vì encryption xảy ra trước khi data rời VM (xem Chương 01 về I/O path)

Theo documentation, cả DEK lẫn data đều không tồn tại unencrypted ở bất kỳ lớp nào của infrastructure. Persistent Disk driver trong VM thực hiện mã hóa trong VM trước khi data đi qua network đến Colossus.

Với phần lớn organizations, Google-managed encryption là đủ. Compliance requirements thực sự yêu cầu CMEK ít hơn nhiều so với suy nghĩ phổ biến.

CMEK (Customer-Managed Encryption Keys) ​

CMEK cho phép organization kiểm soát KEK thay vì để Google quản lý. KEK được lưu trong Cloud Key Management Service (Cloud KMS), do customer tạo và quản lý.

Cách hoạt động kỹ thuật ​

Khi tạo disk với CMEK, Cloud KMS được gọi để:

  1. Nhận DEK mới từ Colossus
  2. Mã hóa DEK bằng KEK trong Cloud KMS
  3. Lưu encrypted DEK cùng với disk metadata

Khi VM cần access disk:

  1. Request gửi đến Cloud KMS để decrypt DEK
  2. Cloud KMS verify permission (IAM check)
  3. Nếu có permission: trả về DEK (trong plaintext, chỉ trong secure channel)
  4. VM dùng DEK để decrypt data

Điều quan trọng: Nếu KEK bị disable hoặc destroyed trong Cloud KMS, disk trở nên inaccessible ngay lập tức — ngay cả khi VM đang chạy và disk đang mounted. Đây là cơ chế emergency lockout trong security incident.

Tạo disk với CMEK ​

bash
# Tạo Cloud KMS keyring và key
gcloud kms keyrings create my-keyring \
    --location=us-central1

gcloud kms keys create my-disk-key \
    --keyring=my-keyring \
    --location=us-central1 \
    --purpose=encryption

# Tạo disk với CMEK
gcloud compute disks create my-encrypted-disk \
    --zone=us-central1-a \
    --size=200GB \
    --type=pd-ssd \
    --kms-key=projects/PROJECT_ID/locations/us-central1/keyRings/my-keyring/cryptoKeys/my-disk-key

IAM permission cần thiết cho Compute Engine Service Agent:

roles/cloudkms.cryptoKeyEncrypterDecrypter

Constraints quan trọng của CMEK ​

Không thể áp dụng cho disk đã tồn tại. CMEK chỉ có thể được chỉ định lúc tạo disk. Không có migration path từ Google-managed encryption sang CMEK cho disk đang chạy — phải tạo disk mới với CMEK, migrate data, xóa disk cũ.

Không thể revert về Google-managed encryption. Một khi disk tạo với CMEK, không có cách nào chuyển về Google-managed keys. CMEK là quyết định một chiều.

Cloud KMS availability ảnh hưởng disk access. Nếu Cloud KMS không accessible (downtime, networking issue), VM không thể decrypt DEK → disk không thể đọc/ghi. Điều này thêm một dependency mới vào availability chain của application. Google-managed encryption không có dependency này.

Regional KMS key phải cùng region với disk. Không thể dùng Cloud KMS key ở us-central1 cho disk ở europe-west1. Cần tạo key riêng cho mỗi region.

Key rotation với CMEK ​

Key rotation với CMEK là re-encrypt DEK với KEK mới, không phải re-encrypt data. Cloud KMS hỗ trợ automatic key rotation:

bash
# Cấu hình auto-rotation mỗi 90 ngày
gcloud kms keys update my-disk-key \
    --keyring=my-keyring \
    --location=us-central1 \
    --rotation-period=7776000s \  # 90 days
    --next-rotation-time=2026-09-01T00:00:00Z

Khi key rotate:

  1. Cloud KMS tạo key version mới
  2. Key version mới trở thành "primary" — mọi operations encrypt mới dùng key version này
  3. Key version cũ vẫn được giữ để decrypt data được mã hóa bởi version cũ
  4. Có thể manually trigger re-encryption của tất cả DEKs sang key version mới

Khi nào cần manual rotation: Nếu suspect key compromise (leaked logs, insider threat), cần ngay lập tức rotate và re-encrypt tất cả DEKs. Automatic rotation chỉ rotation định kỳ.

Rotation với Persistent Disk và Hyperdisk:

  • Offline Hyperdisk: Luôn hỗ trợ key rotation
  • Online Hyperdisk trên A3, A4, Z3, H4D, TPU, Bare Metal variants: hỗ trợ
  • Online Confidential Hyperdisk: Không hỗ trợ rotation online

CSEK (Customer-Supplied Encryption Keys) ​

CSEK là tùy chọn thứ ba ít phổ biến hơn, trong đó customer cung cấp key trực tiếp thay vì lưu key trong Cloud KMS:

bash
gcloud compute disks create my-disk \
    --csek-key-file=key.json

Key file chứa raw AES-256 key (64 hex characters). GCP không lưu trữ key này — chỉ giữ wrapped version. Customer phải cung cấp key mỗi lần attach disk.

Khi nào dùng CSEK: Use case rất hẹp — khi organization có policy không được lưu encryption keys ở bất kỳ cloud provider nào, kể cả trong Cloud KMS. CSEK cho phép key hoàn toàn trong kiểm soát của customer.

Risk của CSEK: Nếu mất key file, disk vĩnh viễn inaccessible. Google không thể recover. Snapshot cũng không thể access. Đây là use case advanced — cần key management infrastructure riêng.

Confidential Hyperdisk ​

Bên cạnh encryption at-rest, Hyperdisk Balanced hỗ trợ Confidential mode — bổ sung bảo vệ khi data đang được xử lý (in-use):

Standard:
  data at-rest: encrypted (DEK + KEK)
  data in-use: plaintext trong VM memory (trust VM)

Confidential:
  data at-rest: encrypted
  data in-use: encrypted trong hardware-backed enclave (không trust VM host)

Với Confidential mode, DEK được bảo vệ bởi hardware-backed enclave (AMD SEV hoặc Intel TDX). Ngay cả nếu hypervisor bị compromise, key không thể extracted. Đây là "defense in depth" thêm một tầng cho compliance-heavy industries (financial services, healthcare).

Constraints của Confidential Hyperdisk:

  • Không hỗ trợ online key rotation
  • Chỉ available trên một số machine types hỗ trợ confidential computing
  • Performance overhead nhỏ do encryption in-use

Quyết định về encryption approach ​

RequirementSolution
Mặc định, no special requirementGoogle-managed encryption
Compliance cần audit trail key accessCMEK với Cloud KMS
Emergency lockout capabilityCMEK (disable key trong Cloud KMS)
Key hoàn toàn không ở cloud providerCSEK
In-use data protection (data trong memory)Confidential Hyperdisk

Cảnh báo common mistake: Nhiều teams implement CMEK vì "security best practice" mà không cân nhắc implications về Cloud KMS availability dependency. Nếu Cloud KMS có downtime và disk cần emergency access, application sẽ down. Evaluate tradeoff trước khi commit toàn bộ fleet sang CMEK.

Tài liệu tham khảo ​