Hi Divine.
I think I can help. Taking your questions in order:
-
Master key rotation using a purpose-generated Amazon KMS master key (“CMK”) rotation: In Amazon (and GCP & Azure) parlance, key service “rotations” are really just versioning techniques. Because many use cases (such as FLE data in MongoDB) are for long term storage with potentially massive numbers of records and previously encrypted data must still continue to be accessible, a CMK rotation will create a new wrapping envelope on any newly created data (field) keys, but all previous “old” encrypted payloads carry enough meta information so they can still be decrypted as well. In this sense, rotation is meant to signifiy that a given key is only used for encryption for a specific period of time. You can read more details here: Rotating AWS KMS keys - AWS Key Management Service, but the take-away is, no, automatic rotation with AWS KMS CMKs do not pose any issue for FLE. They are essentially an opaque implementation detail and from the view of our drivers, old and new field keys can still be decrypted through API calls using the same IAM account privileges as always.
-
Not sure I entirely follow what you’re asking, but the actual (raw/plaintext) data encryption keys (field keys) themselves are not rotated, only the encryption key that protects them on initial generation. You can think of this as similar to what happens on a laptop with disk encryption - when you change your password, a key derivation algorithm is used to create a new wrapping for the disk encryption key, but the disk data encryption key itself does not change; if it did, your whole drive would have to be re-encrypted block by block, and with a sizable volume that could take a considerable amount of time.
-
As mentioned, the field encryption keys themselves are not rotated, but their encrypted versions can be, if desired. One of the advantages of a hardened, mature key service like AWS KMS is that the master key material used to perform the envelope encrypt/decrypt operations never leaves the confines of the service, and depending on the provider may not even leave the backing Hardware Security Module. This is not the case with the local key service (which could be supplied with either an actual local key file or results of a REST call to a remote key/secrets manager like Hashicorp Vault).
What may be helpful is to consider real world threat modeling: how likely is it that an attacker would compromise your application server, capturing database credentials and privileged network access and plaintext FLE encryption keys (or the latter and a full snapshot of the production database)? And if that were to occur, it may make sense to rotate your keys, but in many (most?) cases this would be a distant priority from dealing with the fact that your application server were compromised in the first place; responding to a catastrophic breach would take precendent.
From a compliance perspective, rotating master keys typically meets the intention of most major regulatory frameworks and industry guidelines.
Hope that helps.
-Kenn