Cloud KMS Key Hierarchy and Lifecycle

Introduction to Cloud KMS

Managing cryptographic keys at scale is one of the most difficult tasks in security. Cloud Key Management Service (KMS) is Google Cloud's managed solution for creating, using, rotating, and destroying keys.

For a Professional Cloud Security Engineer (PSE), Cloud KMS is the foundation of "Encryption at Rest." You must understand how keys are structured and how to manage their lifecycle to meet compliance and security requirements.

白話文解釋（Plain English Explanation）

Analogy 1: The Bank Safe Deposit Box Building

Think of a Cloud KMS resource hierarchy as a high-security bank. The Project is the bank branch, the Location (e.g. us-central1, global) is the floor that vault is on, the Key Ring is a room of safe deposit boxes grouped by department, the Key (CryptoKey) is one specific box, and each Key Version is a different lock that was installed on that box over the years. When you "rotate" the key, you don't throw out the old locks — you just stop issuing new contents under them, because tenants who deposited items earlier still need the old lock to retrieve their stuff. Destroying a version is like grinding the lock and key into dust: once the 24-hour recovery window expires, nothing inside that was sealed with that lock is ever readable again.

Analogy 2: Hotel Master Keys vs. Room Keys

Envelope encryption mirrors how hotels manage keys. Each room has a unique room key that is rewritten every checkout — that is the Data Encryption Key (DEK), stored right next to the door (next to the data). The hotel doesn't keep thousands of room keys at the front desk; instead they keep one master key that can unlock any room key's programming console — that is the Key Encryption Key (KEK) managed in Cloud KMS. The KEK never leaves the front office (HSM). If a room key is lost, you reprogram only that room. If you suspect the master is compromised, you rotate the KEK and re-wrap every room key.

Analogy 3: The Pharmacy Controlled-Substance Cabinet

The Separation of Duties model in KMS IAM is like a hospital pharmacy. The Cloud KMS Admin is the pharmacist who orders, labels, and disposes of medications (key rings, key creation, rotation, scheduling for destruction) but is never allowed to dispense them to patients. The CryptoKey Encrypter/Decrypter is the nurse who can administer doses (encrypt/decrypt data) but cannot order new drugs or destroy supply. The Viewer is the auditor who only sees inventory counts. If one person held both pharmacist and nurse roles, they could secretly create a key, use it to decrypt PII, and then destroy the evidence — which is exactly the audit failure mode CMEK governance is designed to prevent.

Understanding the Key Hierarchy

Google Cloud uses a hierarchical approach to encryption, known as Envelope Encryption.

The Three Layers:

1. Data Encryption Key (DEK): The key used to encrypt the actual data (e.g., a file or a database row). DEKs are stored with the encrypted data.
2. Key Encryption Key (KEK): The key used to encrypt (wrap) the DEK. This is the key you manage in Cloud KMS.
3. KMS Master Key (Root Key): The internal key used by Google to encrypt the KMS service itself.

Software vs. Hardware (HSM) Protection Levels

When creating a key in KMS, you choose a Protection Level:

• Software: Keys are stored in secure software modules. This is cost-effective and suitable for most use cases.
• Hardware (HSM): Keys are stored in FIPS 140-2 Level 3 certified Hardware Security Modules. The key material never leaves the HSM in plaintext.
• External (Cloud EKM): Keys are stored in an external key manager outside of Google Cloud.

Key Rotation: Automatic and Manual

Rotation is the process of creating a new Key Version.

• Automatic Rotation: You set a schedule (e.g., every 90 days). KMS automatically creates a new primary version.
• Manual Rotation: You trigger a rotation immediately (e.g., due to a suspected compromise).

Key Versioning and Destruction

Every key in KMS has one or more Key Versions.

• Primary Version: The version used for new encryption operations.
• Scheduled for Destruction: When you delete a key version, it enters a "Recovery Period" (default 24 hours, but can be configured). During this time, you can "restore" the version. Once the period ends, the key material is permanently destroyed.

IAM for Cloud KMS

KMS follows the principle of least privilege through specific roles:

• Cloud KMS Admin: Manage key rings and keys (create/rotate/delete). Cannot use keys to encrypt/decrypt.
• Cloud KMS CryptoKey Encrypter/Decrypter: Can use keys to protect data. Cannot manage the keys.
• Cloud KMS Viewer: Can see metadata but cannot use or manage keys.

Multi-region vs. Regional Key Rings

• Regional: Keys are stored in a specific region (e.g., us-central1). High performance for resources in that same region.
• Multi-regional: Keys are stored across multiple regions (e.g., us). Provides higher availability and is required for multi-regional GCS buckets.
• Global: A special location that should be used sparingly, as it can introduce latency.

Auditing Key Usage in Cloud Audit Logs

Every time a key is used (Encrypt, Decrypt, Sign), a log entry is generated in Cloud Audit Logs (if Data Access logs are enabled).

• Log contains: Who used the key, when, and for which resource.
• Crucial for Compliance: Proving that keys were only accessed by authorized identities.

Symmetric vs. Asymmetric Keys

• Symmetric (AES-256): The same key is used for encryption and decryption. Faster and used for most data at rest (GCS, BigQuery).
• Asymmetric (RSA/EC): Uses a Public Key for encryption/verification and a Private Key for decryption/signing. Used for digital signatures and external identity integration.

Best Practices for Key Lifecycle Management

1. Use a dedicated Project: Store your KMS Key Rings in a separate "Security Project" to isolate them from application projects.
2. Enable Automatic Rotation: Reduce the "blast radius" of a potential key compromise.
3. Monitor Destruction: Set alerts for any Destroy operations.
4. Enforce CMEK: Use Organization Policies to ensure that services only use Customer-Managed Encryption Keys.

PSE Exam Scenarios

Scenario 1: Key Compromise Recovery

"A developer accidentally committed a service account key to a public GitHub repo. This service account has Encrypter/Decrypter access to a KMS key. What should the security engineer do?" Answer: 1. Revoke the service account's IAM permissions immediately. 2. Manually rotate the KMS key to create a new version. 3. Re-encrypt the most sensitive data using the new primary version.

Scenario 2: Separation of Duties

"A compliance auditor requires that the person who creates encryption keys should not be the same person who can use them. How do you implement this?" Answer: Assign the Cloud KMS Admin role to a Security Administrator and the Cloud KMS CryptoKey Encrypter/Decrypter role to the Application Service Account. Ensure neither has the other's role.

Summary Checklist

• Draw the DEK -> KEK -> Root encryption hierarchy.
• Explain the difference between Software and HSM protection.
• Describe what happens to old versions during a key rotation.
• Identify the IAM roles needed for "Separation of Duties."
• List the steps to destroy a key version safely.