AWS solutions documentation change
Summary
Added documentation about KMS key retention policies, orphaned key identification, and cleanup options including auditing and deletion procedures.
Security assessment
The changes document security best practices for KMS key management including retention policies to prevent data loss and procedures to audit/orphaned keys. While it enhances security awareness, there's no evidence of addressing a specific vulnerability. The guidance helps prevent accidental data loss through key deletion.
Diff
diff --git a/solutions/latest/landing-zone-accelerator-on-aws/key-management.md b/solutions/latest/landing-zone-accelerator-on-aws/key-management.md index 104391f8d..0b6c96a66 100644 --- a//solutions/latest/landing-zone-accelerator-on-aws/key-management.md +++ b//solutions/latest/landing-zone-accelerator-on-aws/key-management.md @@ -7 +7 @@ -All accountsManagement accountLogArchive accountAudit account +All accountsManagement accountLogArchive accountAudit accountKey retention policyOrphaned KMS keysCleanup options for orphaned keys @@ -66,0 +67,44 @@ This key is distinct from the per-account/Region key because additional services +## Key retention policy + +The solution sets a `RETAIN` removal policy on every customer-data-bearing KMS key listed above. This applies across all stacks (`Prepare`, `Key`, `Logging`, `Security`, `Operations`, `Network`) and all account types (`Management`, `LogArchive`, `Audit`, and workload accounts). The retention policy is applied even on initial-create rollback, which means a KMS key created during a failed deployment is preserved rather than discarded by AWS CloudFormation. + +This is a deliberate design choice. The KMS keys provisioned by the solution encrypt data at rest in CloudWatch Logs, Amazon S3 buckets, AWS Lambda environment variables, AWS Systems Manager Session Manager logs, Amazon EBS volumes, AWS Backup vaults, and the central audit logs in the LogArchive account. Some of this data falls under regulatory retention requirements that span multiple years. Allowing AWS CloudFormation to discard a KMS key would render any data already encrypted under that key permanently unreadable, including data needed to demonstrate compliance. + +###### Note + +The `RETAIN` policy is the default for all customer-data-bearing CMKs in this solution and is not configurable. Keys are preserved on stack rollback, stack deletion, and account removal. + +## Orphaned KMS keys + +After a failed deployment, a deleted stack, or an account removal, you might find KMS keys in your account with the following characteristics: + + * No alias attached. AWS KMS aliases are created in the same stack as the key and are removed when that stack rolls back, even though the key itself is retained. + + * The `Accelerator` tag (or your configured prefix) and a creation timestamp that matches the failed deployment. + + * A status of **Enabled**. The key is active and continues to incur a monthly key-storage charge. See [AWS KMS pricing](https://aws.amazon.com/kms/pricing/) for current rates. + + + + +These keys do not block subsequent deployments. A successful redeploy creates fresh keys with their aliases attached. The orphaned keys remain in your account until you decide how to handle them. + +## Cleanup options for orphaned keys + +You have three options for handling orphaned KMS keys. + + 1. **Leave the keys in place.** This is the safest option. The orphaned keys do not interfere with subsequent deployments and preserve any data that might have been encrypted under them. + + 2. **Exclude the keys from cost reports.** Apply a custom tag (for example, `accelerator:status=orphan-cleanup`) to the orphaned keys and filter that tag out of your billing reports. The keys remain available if any retained data needs to be decrypted. + + 3. **Schedule the keys for deletion.** Before scheduling deletion, audit AWS CloudTrail for `kms:GenerateDataKey` and `kms:Encrypt` events against each key ID to confirm that no data was encrypted under the key. After you confirm the key was unused, schedule deletion with a 30-day pending window so that you can cancel the deletion if you discover that the key is needed. + + aws kms schedule-key-deletion --key-id <key-id> --pending-window-in-days 30 + + + + +###### Important + +Scheduling a KMS key for deletion is irreversible after the pending window expires. Any data encrypted under a deleted key becomes permanently unreadable. Always audit AWS CloudTrail before scheduling deletion, and prefer the maximum 30-day pending window. +