[jwnin]

Markup aside, your description of what Salesforce is offering is what the article is saying should be done. Encryption of the disk at rest doesn't do anything for data exfil situations; it protects against physical theft or improper disposal - only.

[cjonas]

Sorry, still reading so having gotten there yet. How does Salesforce offering a "light" version of encryption at rest improve security? Or are you saying it's a better balance of performance / security by only selectively encrypting specific data points?

[ziddoap]

What do you mean "light" version of encryption?

Anyways, the improved security comes from the fact that even when the server itself is improperly accessed (maliciously or not), the data you aren't currently accessing remains encrypted.

With (just) full disk encryption, you aren't protected when the (running) server is accessed. All of the data can be exfiltrated in plaintext.

[cjonas]

Gotcha... so basically encryption of disk at rest prevents someone from walking out with a drive...

Encryption "at rest" in the database prevents someone with server or direct db connection from pulling the data.

I had never really thought of those as two different vectors, but of course they are. Thanks for clarifying!

With Salesforce and how a lot of these companies manage their security model, I'm still confident that investing in securing unauthorized user access is still orders of magnitude more useful than putting time and effort into this vector.

[ziddoap]

>I'm still confident that investing in securing unauthorized user access is still orders of magnitude more useful than putting time and effort into this vector.

These are addressing two different scenarios, so they should be mitigated separately. In one case, you are mitigating against unauthorized access. In the other, you are mitigating the damage that can be done when someone has already gained unauthorized access (however that occurred). After all, the only system immune to unauthorized access is the one that doesn't get powered.

"Defense in-depth" is thrown around a lot, but it really is important. I do agree though, when it comes to priority of implementation, I would start with protecting against unauthorized access first.

[cjonas]

I don't disagree on a conceptual level, but on a regular basis I deal with companies completely lacking any real access model, users without MFA, blanket admin level access, etc... getting sold on this particular product and something spending 7 figures to adopt it.

[sebazzz]

It sounds like they are using/implementing something similar to SQL Server Always Encrypted[0]. This basically works by encrypting specific fields using a certificate that needs to be supplied by the connecting SQL client (application). Obvious limitations is that you can't use the fields for sorting in queries (ORDER BY), and depending if deterministic encryption is not enabled, you can't use it in filters (WHERE) either. Same applies for any T-SQL logic on the data fields - because the encrypted blob is opaque to SQL Server - it is decrypted client-side. There is no workaround, except for pulling the data locally and sorting client-side.

[0]: https://learn.microsoft.com/en-us/sql/relational-databases/s...

[CiPHPerCoder]

> Obvious limitations is that you can't use the fields for sorting in queries (ORDER BY), and depending if deterministic encryption is not enabled, you can't use it in filters (WHERE) either. Same applies for any T-SQL logic on the data fields - because the encrypted blob is opaque to SQL Server - it is decrypted client-side. There is no workaround, except for pulling the data locally and sorting client-side.

This is a reasonable limitation when you're aware of the attacks on Order Revealing Encryption: https://blog.cryptographyengineering.com/2019/02/11/attack-o...

[kbolino]

It sounds like it is in addition to full-disk encryption, not instead of it.

Encrypting each field with a distinct key that an attacker cannot glean by simply exfiltrating all the data on disk and/or all the data in RAM protects against online attacks in a way that full-disk encryption cannot.

The real question is: does Salesforce do this properly?

[apgwoz]

It’s certainly possible that there’s a valid oversight here, but Salesforce has a rather talented security team, and the company truly lives by “Trust is our #1 value”^1

I can’t speak for the implementation, but my guess is that it’s been very thoroughly vetted by both internal security and external pen tests. They wouldn’t market a high profile security feature without that.

(1: I am an ex-Heroku / Salesforce employee)