[mjr00]

Not sure about any specific use cases for this Mongo feature, but security requirements are often just checkboxes without much thought put behind them, or not valid in certain contexts, like SaaS/cloud.

Classic example is on-prem enterprises requiring data encryption at rest when moving to a cloud vendor. I can explain to a client that encrypting an S3 bucket with an AWS-managed key doesn't really prevent anything beyond someone physically stealing a hard drive from the AWS data center, and that the cloud provider can still see all of their data because they control the encryption key... or I can just click the "encrypt data" flag on the S3 bucket, make their security and compliance officer happy, and be done with it.

So, you're totally right, but this might be a case they needed to satisfy where an enterprise security team or regulatory agency said that they couldn't put X data field in the cloud unless it was encrypted, but X data field was really important to the application team.

[bradstewart]

> that encrypting an S3 bucket with an AWS-managed key doesn't really prevent anything beyond someone physically stealing a hard drive from the AWS data center

It does, though. To get that data, you now need access to the bucket itself _and_ the KMS-managed encryption key. You might not be protecting the data from AWS, but one bucket misconfiguration doesn't lead to wholesale data loss now.

Is it perfect? No. You can misconfigure both. But misconfiguring KMS access is harder to do.

[mjr00]

To be clear, I"m talking about using the default "AWS KMS key" as they call it now, not managing your own keys. Just click the box on S3 and it's encrypted at rest, but completely transparent. If a user has access to the S3 bucket, they have access to the data within it. This has been sufficient for every enterprise client I've worked with because it checks the "data encrypted at rest" box for SOC2, ISO-27001, etc.