LEARN. PRACTICE. GROW.Two keys, two responsibilities
In a fictional settlement archive, each batch is encrypted using a data encryption key, the DEK. A separate key encryption key, the KEK, protects that DEK. The stored package needs ciphertext, IV, tag, encrypted DEK and the information required to find the correct KEK. Storing the encrypted DEK beside the batch can be appropriate; storing the plaintext DEK there removes the intended separation. The design must explain where plaintext exists during processing, who can request decryption and how the application authenticates the result. A policy that protects only the file while overlooking key-use permissions leaves the read path incompletely controlled.
Authenticated context and output not yet accepted
The exercise uses AES-256-GCM with a random 12-byte IV and a 16-byte tag. Every encryption generates a fresh IV; per-key uniqueness remains an obligation in a real design, especially at high volume. AAD binds tenant, object and version to ciphertext without hiding those fields. If the application opens it using a different context, authentication fails. Do not put secrets in AAD. In Node, update can produce bytes before final validation: this example returns output only after final succeeds. Authentication failure must prevent those bytes from entering batch processing even when they appear readable.
Distinguish rotation, rewrap and re-encryption
Run node run.mjs using the complete script in the next lesson. The first group creates a synthetic batch and protects the same DEK under a new KEK. The batch ciphertext hash remains unchanged: the key wrapper changed. The check named retained data key still decrypts after rewrap shows that someone holding the original DEK can still decrypt that ciphertext. To respond to DEK exposure, assess affected data, access, evidence preservation and whether a new DEK and data re-encryption are needed. Do not declare an incident resolved simply because a rotation dashboard is green. This local exercise does not reproduce internal material rotation within a KMS key.
Backups have key dependencies too
The script retains an old and a new wrapper. It removes the old reference from the key registry: the old backup fails and the new one works. Restoring the reference recovers the first. This demonstrates logical unavailability, not physical erasure; the oldKek variable remains in memory. In APS work, also inventory immutable backups, exported copies and older consumers before retiring a key. Define who approves, how restoration is rehearsed and which signals stop the change. Restoration using the engineer’s personal account does not establish operational-identity autonomy. Recovery evidence should use the intended identity, the correct object and the process integrity requirements.
Interpret failures before closing the change
Both recorded executions passed 36 checks each, including 12 in the envelope group. Changes to ciphertext, tag, context and key trigger rejection. This demonstrates the exercised cases in this runtime without proving KMS availability, HSM protection, FIPS compliance or application acceptance. For handover, add a matrix containing backup version, key dependency, authorized identity, latest restoration and retention decision. If a copy still depends on the old key, keep retirement pending or migrate it through an authorized process. Connect this lesson with retention, incidents and recovery: the control is useful when data remains recoverable by the intended parties.
Synthetic settlement-batch data; no BNP Paribas internal information.
Common pitfalls
Accepting an isolated technical indicator as proof of the complete control; omitting negative tests and dependencies.
Related topics: Cloud recovery and incidents · Data protection and IAM
Execute authenticated encryption and distinguish rewrap, DEK exposure and recovery dependencies.
Reference: AWS KMS cryptography essentials · CCSP examination outline effective 2026-08-01; January2026 V2 PDF