Enforce Customer Managed KMS Keys and Key Rotation for Audit Logs
Specification & Description
Enforce the use of Customer Managed Keys (CMKs) with automated key rotation enabled and strict cross-account key policies for encrypting centralized CloudTrail and audit log archives.
Technical Specifications
Default AWS-managed keys (aws/s3 or aws/cloudtrail) are insufficient for enterprise Landing Zone
audit logging because their key policies cannot be modified to restrict access, cannot be shared across
accounts with granular IAM conditions, and do not provide detailed KMS access logs for forensic investigation.
1. Customer Managed Key (CMK) Governance
- All audit trails and centralized log archive buckets must use dedicated AWS KMS Customer Managed Keys.
- CMKs provide granular control over key administration versus key usage permissions.
- Decryption capabilities can be isolated to dedicated security and forensic roles, preventing unauthorized member account admins from decrypting sensitive organizational audit trails.
2. Automated Key Rotation
- Regular automated key rotation must be enabled on the KMS key.
- When rotation occurs, KMS automatically creates a new backing key while retaining previous versions to seamlessly decrypt historical logs without manual key migration.
3. Multi-Account KMS Key Policy Guardrails
- Key policies must explicitly allow the
cloudtrail.amazonaws.comservice principal to generate data keys across the organization usingaws:SourceOrgIDconditions. - Key policies must prevent
kms:DisableKey,kms:ScheduleKeyDeletion, or policy modifications by unauthorized principals.
Security Rationale
Using KMS Customer Managed Keys with automated rotation ensures cryptographic separation of duties and maintains log confidentiality. Even if an attacker compromises an S3 bucket policy or acquires raw S3 object permissions, they cannot decrypt the forensic logs without explicit KMS key permissions. Automated key rotation limits the cryptanalytic blast radius of any individual key version.