[snorkel]

This seems more applicable for the SaaS hosting model where the database service is managed by a 3rd party. So the use case is "I trust your SaaS service is compliant with my legal obligations to protect my customer data, but it'd be easier for everyone involved if your database service also has no way of seeing sensitive data fields. That would make it easier for me to pass my compliance audits, otherwise I need to audit you." So the data is encrypted client-side before it's sent over to the database service, and the database service is not able to decrypt it, but can still can include the encrypted value in a query.

[SkyPuncher]

The problem is that situation doesn't really exist.

At an organizational level, it's extremely hard to control what information get put into a SaaS. There are far too many ways in which data can be de-anonymized or inferred against (e.g. a field existing can have privacy implications).

It's far safer to use a SaaS provider that meets general control requirements than to try to shoe-horn encrypted data into them.

[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.

[snorkel]

Correct, a database feature can't prevent errant developers from posting customer credit card numbers on Twitter either, but compliance auditors won't accept "We don't bother encrypting data because it's pointless!" as an answer. The very real use case here is when private contracts between an end customer and a service provider says "You are in breach of this contract if load my data to any 3rd party service that has the ability to see my data, regardless of whether they use that ability or not. You are allowed to use that other service if you extend your audit program to also audit that other service provider according to my standards and report back to me." I've personally seen this situation prevent the use of SaaS. An encryption control like this where the 3rd party doesn't have keys to decrypt the data is considered satisfactory.