2

I need to protect sensitive data by doing data encryption at rest. Context : I have at least the data of 20 app to protect. I want protection from those with legitimate access to the virtual machine hosting the database (sysadmin) or the database (DBA, some end users) for 3 reasons : one of them could go rogue, some of their access are from "normal" PC which could be compromised, states or equivalent threat with a lot of power can do APT and try to steal credential or to make complex attack (rebound on machines, privileges escalation) and gain access to the VM or the database. In all those scenarios I want my sensitive data protected in confidentiality.

Option 1: Full Disk Encryption (FDE)

Weak level of protection protects only from physical loss of storage media. In 76% of data breaches, the attacker begins by stealing and using the credentials of a privileged account, making the protection provided by disk encryption useless (source https://www.forbes.com/sites/louiscolumbus/2019/02/26/74-of-data-breaches-start-with-privileged-credential-abuse/) I plan to discard this option. Am I right?

Option 2: Database Encryption

  • Sub-option 1: Transparent Data Encryption which offers encryption at file level. I'm unsure if that is equivalent to FDE. Is it or not?
  • Sub-option 2: use postgresql and pgcrypto to encrypt only sensitive data. If I understand correctly, anyone who has access to the virtual machine (like the sysadmin) or the database in the VM (like the dba or the humans who have valid account) will the the data only in the encrypted form. Only the app will see the sensitive data in decrypted form. Am I right? If so, this solution seems good.

Option 3: Application Layer Encryption

Highest level of security but hard to implement app-by-app so a possibility would be to use a third-party solution like cipher trust from Thales or for the specific case of elastic search a tool like cloaked search.

Option 4 : File-Based Encryption (FBE)

source https://cpl.thalesgroup.com/encryption/selecting-right-encryption-approach.

Encrypting data at the file or volume level (typically used for databases) offers security controls with software agents installed in the operating system. For many organizations and purposes, file encryption represents the optimal approach. Its broad protections support the vast majority of use cases, and it is easy to deploy and operate.

In the case of database I don't understand the difference in security level obtained between FDE, FBE and TDE: I think that in the 3 cases, anyone who has access to the virtual machine or the database in the VM will access the data in plain text so I don't find those solutions relevant. Am I right?

3
  • Thanks for the edit, that makes things much clearer.
    – schroeder
    Commented Nov 19, 2023 at 12:26
  • 1
    The one complexity in all of this is key management (who has access to the keys).
    – schroeder
    Commented Nov 19, 2023 at 12:35
  • In my opinion full-disk-encryption isn't necessarily "data-at-rest" unless the disk is offline, as also mentioned here: security.stackexchange.com/a/41489/72031.
    – Bob Ortiz
    Commented Nov 20, 2023 at 12:12

1 Answer 1

1

First: you cannot protect data against a rogue sysadmin. They already have access, they know how the system works, and they can use workarounds to exfiltrate data. Even the NSA could not protect themselves against Snowden.

The average user (and even above-average company) cannot protect against state-level threats. If you are protecting state-level secrets, you will need state-level defenses, not a team of 3-4 sysadmins.

Weak level of protection protects only from physical loss of storage media.

Full disk encryption is not weak, it's one of the easiest ones to activate and protects more than you think. It protects against theft of the hardware, and protects data when your hardware malfunctions and you need to send it for repairs. And protects the data if the storage device is improperly disposed of. Do not discard this option.

For the database encryption, it will provide some protection, but not against a sysadmin. The application has the credentials to see the plaintext data, and the sysadmin can get the application credentials. It's the same for file-based encryption: no matter how you protect something, a sysadmin will have enough access to the system to get the credentials.

I would use at least Full Disk Encryption and database encryption. They are easy to use, usually have negligible performance penalty, and is absolute protection in some cases.

Encryption at rest is one security measure and it's not meant to protect against everything. You must use it along with privilege separation, auditing and logging, network security, secure coding, and other defenses. Encryption alone won't protect much.

5
  • "The application have the credentials to see the plaintext data, and the sysadmin can get the application credentials" : the credential can be store in a numeric vault like hashicorp vault and the acces to the credential not given to the sysadmin
    – loic midy
    Commented Nov 19, 2023 at 18:36
  • " I would use at least Full Disk Encryption and database encryption" : for database encryption what is your opinion on the 2 sub option I mention : TDE (seems not good) vs use postgresql and pgcrypto to encrypt only sensitive data (seems good) : "The client supplies the decryption key and the data is decrypted on the server and then sent to the client".
    – loic midy
    Commented Nov 19, 2023 at 18:38
  • 1
    Even with Hashicorp Vault, the sysadmin is still sysadmin: he can dump traffic, dump memory, compile and install kernel modules, run strace/ptrace/ltrace/gdb on any process, hook into syscalls, modify binaries... you cannot defend against a competent rogue sysadmin.
    – ThoriumBR
    Commented Nov 19, 2023 at 18:59
  • @ThoriumBR "You cannot defend against a competent rogue sysadmin" .. and let them do their job at the same time.
    – Cort Ammon
    Commented May 19 at 19:32
  • @CortAmmon if you fire them or block them, they are not your sysadmin anymore...
    – ThoriumBR
    Commented May 19 at 20:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .