KMS and Cloud Encryption

• Encrypted-at-rest without key management is theater — a leaked master key ruins the encryption either way.
• Envelope encryption (KMS wraps a data key) is the pattern behind every cloud storage service; you need it to read how data flows.
• Key rotation and customer-managed-keys are audit questions regulators ask before they ask about the algorithm.

Protect the hotkey better than every safe, and rotate it so a stolen copy expires.

• A KMS holds master keys (CMKs); it never exports them outside the HSM-backed vault.
• To encrypt an object, the app calls the KMS, which returns a data key (plaintext + ciphertext) usable for that operation.
• The ciphertext data key rides with the data; the plaintext half lives only in the app's memory briefly.
• Rotation changes the master key material while keeping the same logical key id — old data stays decryptable via versioned keys.

• A bank enables customer-managed keys on object storage so supply-chain incidents discover nothing to steal.
• An org enables automatic KMS rotation and schedules a manual key-material rotation for legacy systems.
• A data pipeline keys partitions per-date buckets so analyst access is scoped by partition-level policy.

• Use KMS-managed keys for anything 'at rest' and customer-managed keys where compliance requires control.
• Prefer automatic rotation on the cadence your policy demands; review key versions after rotation.
• Lock KMS admin to break-glass paths and enable key usage auditing.
• Never hardcode plaintext keys; always issue through KMS or a secrets manager.

• Turning on 'encryption' with the provider's default service key and calling it a control — you never rotate it.
• Copying a plaintext data key into logs 'for debugging'.
• Forgetting that a lost customer-managed key means permanent data irretrievability — a DR plan must mirror it.
• Pinning to key version IDs so rotation silently breaks every pipeline.

• When a decrypt fails after rotation, check the key version referenced in the error vs the current one.
• Enable KMS KeyEvents/audit logs and search for repeated 'AccessDenied' — that is usually a policy issue.
• Test rotation in a scratch key namespace before touching production data.

• A KMS key is a fail-closed control: losing access rights is data loss until policy is restored.
• Think of key access as identity: a KMS-granted app role is as valuable as a DB password.
• Only ever test with keys and data you own; never wrap someone else's ciphertext without scope.