Cloud KMS Key Management: Review Access and Lifecycle
Encryption at rest is not proof of controlled decryption. A key-management review identifies key owner, protected workload, administrators, cryptographic users, policy paths, lifecycle state, and recovery dependency. Separate people who administer a key from workloads that encrypt or decrypt with it. One identity doing both weakens separation of duties.
Establish key inventory and ownership
Inventory customer-managed keys, aliases or key versions, region/location, purpose, protection level, integrations, data classification, owner, and recovery dependency. AWS customer managed keys let customers control policy, lifecycle, rotation, and auditability; AWS managed and owned keys have different control boundaries. Google Cloud KMS supports customer-managed keys, HSM, external keys, and CMEK integrations. Azure Key Vault supports keys, secrets, and certificates with authorization through Azure RBAC or Key Vault access policies.
Mark default-provider encryption separately from a requirement for customer control. It may protect data but does not necessarily provide customer-selected lifecycle, access policy, or usage records. Never claim a key is recoverable without testing application recovery with retained key versions.
Review policy, grant, and context
In AWS, key policies, IAM policies, and grants are evaluated together. A grant allows one KMS key and one grantee to perform specified supported operations; it cannot deny. Review kms:CreateGrant carefully because a principal allowed to create grants can delegate key use. For a temporary service need, use scoped operations and constraints, name a retiring principal, inventory grant ID, and retire or revoke it after use.
Encryption context adds non-secret authenticated context for symmetric KMS encryption. Same context is required for decrypt, and AWS logs it in CloudTrail. Use stable labels such as application, environment, and tenant ID, never credentials, emails, or customer content. Bind policy or grant conditions when context is part of authorization.
{
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::111122223333:role/payments-app"},
"Action": ["kms:Decrypt"],
"Resource": "*",
"Condition": {"StringEquals": {"kms:EncryptionContext:App": "payments"}}
}This is a starting pattern, not a complete key policy. Test decrypt with correct context, wrong context, wrong principal, and wrong environment. Also test that an application needing only GenerateDataKey cannot decrypt arbitrary ciphertext.
Manage rotation and deletion as production changes
Document rotation method, cadence, trigger, old-version decrypt support, application rollout, and rollback. Rotation creates new material for new encryption; older material can remain necessary to decrypt prior data. Google Cloud CMEK supports customer control of rotation and key-version lifecycle. In Azure, central vault logging and per-application authorization help make key use reviewable. A rotation plan without consumer testing can produce an outage.
Deletion is destructive. AWS customer managed keys can be scheduled for deletion; schedule only after owner approval, dependency inventory, backup and restore test, and documented cancellation path. Disabling or destroying a key version elsewhere must receive same change control. “No current traffic” is insufficient evidence because archives, snapshots, delayed queues, and legal retention can require old ciphertext.
| Check | Evidence fields | Owner | Pass/fail | Exception | Remediation |
|---|---|---|---|---|---|
| Key access | key ID, policy/grant version, test output | key owner | pass/fail | scoped partner use, expiry | remove broad decrypt or grant |
| Context | allowed values, negative test, CloudTrail event | service owner | pass/fail | legacy format, migration date | add condition and deploy change |
| Rotation | version history, consumer test, rollback result | platform owner | pass/fail | unsupported integration | document compensating control |
| Deletion | dependency inventory, approval, restore proof | risk owner | pass/fail | retention hold | cancel schedule and preserve key |
Completed artifacts include timestamp, environment, reviewer, immutable policy/export references, test result, exception approver, expiry, remediation owner, and retest date. Include failed-decrypt output as well as successful use; a successful happy-path test does not demonstrate least privilege. Infrastructure testing can validate approved cryptographic access paths.
Worked case: encryption-context separation
Create two test records under same key with distinct encryption context values representing tenant and purpose. Expected decrypt output succeeds only when caller supplies exact context authorized by key policy and application record. Attempt ciphertext swap, missing context, altered tenant, disabled key, and revoked grant. Record each error class without treating error text as customer-facing behavior. Verify recovery run can decrypt only documented scope and uses separately approved principal.
Closure evidence links key identifier alias, policy version, rotation decision, grant inventory, test ciphertext hashes, and deletion-protection review. An emergency exception must name key, caller, purpose, start and end time, then receive independent expiry check. Retest after policy edits and software library upgrades; a successful encrypt operation alone does not prove unauthorized decrypt is blocked.
Operational handoff: key owner maintains inventory of active callers and recovery route. Security reviewer compares grants against inventory. When caller is removed, run decrypt-denial test before closing change. Preserve result without plaintext or key material.
Test key disable, scheduled deletion protection, and grant revocation in approved non-production scope. Expected outputs distinguish unavailable key from denied caller while no protected record is exposed. Attach timestamps and authorization boundary to closure record.