Keys, masking, and retention | AWS Security Specialty: evidence-based security

Concept and mechanism

KMS material rotation retains the logical key and neither re-encrypts data nor replaces previously issued data keys. If a plaintext data key was exposed, response needs to address that material and affected data. Do not declare complete mitigation merely because KMS rotation occurred. Current documentation supports on-demand rotation of symmetric keys with EXTERNAL material after importing fresh material; automatic rotation has symmetric AWS_KMS scope. BYOK also does not make symmetric KMS ciphertext decryptable outside KMS. Confirm actual interoperability before using material ownership as proof of an external recovery plan.

Guided application

Across accounts, KMS access needs owner authorization and suitable external IAM permission. Identify the key with an operation-supported ARN; an alias without context can resolve in the wrong account. For sensitive logs, CloudWatch Logs data protection acts at ingestion and does not retroactively mask older events. The logs:Unmask permission reveals original values and should have controlled scope. For retention, S3 Object Lock protects versions; it does not prevent every new version using the same key. Expired fixed retention does not remove an active legal hold. Retirement decisions should confirm both mechanisms and owners, including cost and exit conditions. Do not use key or object deletion as an automatic solution to every risk.

IN PRACTICE

FinOps sees an expired deadline, but the version has an active hold. The evidence owner needs to participate in the decision.

Common pitfalls

Rotation as re-encryption; BYOK as open format; masking as deletion; key name as version; deadline as absence of hold.

Related topics: Governance and central controls · Detection and security evidence

Take this idea with you

Relate each control to the data, material, version, and period it actually protects.

Create account

Reference: SCS-C03 domain 5 · SCS-C03