Question about backup encryption

Posted by sdns575@reddit | linuxadmin | View on Reddit | 10 comments

Hi,

suppose you have a server in your company that backups several server (remote and local) and data on server are not encrypted. The backup can use whatever backup solution (bacula, bareos, veeam, acronis, borgbackup, restic, kopia, rsync...) and that it encrypt backups. Being an automatic operation the encryption key(s) is stored on the backup server and used when the backup start. In this way if an attacker take control of backup server he can stole the key, data and decrypt them or worst corrupt data without need of decrypt them.

It can be usefull if you use tape and store them, or when disks are full and they are swapped and stored.

I can understand when you need to save them offsite (like on S3 or another solution) and encryption is a must, but as said, is it worth encrypt local backups considering the previous scenario?

In what case having encrypted backup is usefull?

Thank you in advance.

When encryption is useful:

If you’re moving backup data to an external location (e.g., tapes stored offsite, S3, or another cloud), encryption is almost non-negotiable to prevent unauthorized access to sensitive data.

For backups stored on removable media (e.g., tapes or swapped disks), encryption protects against theft or loss of the physical device. Without encryption, someone with access to the physical media could easily read the data.

Even if someone compromises your backup server, encryption adds an extra layer of security that could deter less sophisticated attackers or at least delay them.

Depending on your industry or country, you might be required to encrypt backups, even if stored locally, to comply with data protection laws like GDPR, HIPAA, or PCI DSS.

Encryption helps limit the damage in case an insider gains unauthorized access to backup media but not the encryption keys.

When encryption might not be worth it:

If your encryption keys are stored insecurely (e.g., on the same server), you’re not really improving security. Worse, it can create a false sense of safety.

If your backup server is air-gapped, heavily firewalled, or otherwise isolated, the risk of compromise might be so low that encryption isn’t a top priority.

Encryption adds computational overhead and complicates the backup/restore process. In some environments, this may not be worth the trade-off if the risk of attack is minimal.

Encrypted backups make corruption harder to detect and recover from. If an attacker corrupts the encrypted backup, you might not realize it until you try to restore.

If you're worried about your scenario (attacker compromises backup server + keys), consider:

Use a hardware security module (HSM) or a key management service to keep keys off the backup server.

Use write-once-read-many (WORM) storage to prevent tampering.

Protect access to the backup server with MFA to make it harder for attackers to gain control.

Implement strict monitoring of the backup server for signs of compromise.

[-]

michaelpaoli@reddit

if an attacker take control of backup server he can stole the key, data and decrypt them

Encryption and decryption keys need not be the same - that's the whole basis of public key cryptography, and upon which, e.g. https works. Encryption key need not at all be capable of decrypting the data, and can in fact safely be public ... that's the key with all https servers - they offer the public key up to any and all, and data is encrypted using that (the full details get more complex, but that's the basics to start). So, protect public key cryptography, well protect the decryption keys, then even if attacker gains access to backup server, generally won't have access to decryption key(s). E.g. decryption keys could potentially only be loaded into RAM as and when needed, and can be different for each host backed up, or even each run of any give backup for any given host backed up. And if restore server is isolated from backup server, that may add yet another layer of protection. And backup server need only see (if the encryption is done locally on it) the data in the clear while it's backing it up - not once it's written - or it could use a client process on the host being backed up to encrypt the data - then even the backup server would never see the data in the clear, and could even never touch, see, or have access to the decryption keys.

But don't forget - still have to manage the keys - most notably private keys - and somehow store them, back them up, etc. ... but that's much smaller (notably data size wise) issue to deal with than the entire volume of all the backups. E.g. key(s) to decrypt/access the private keys could be sufficiently small as to be printed on a single sheet of paper - that's much easier to protect than, e.g. many TiB or more of data in the clear. Also makes easier to effectively "wipe" the data - destroy the corresponding private key(s), and that data is as good as securely wiped. So can effectively wipe up to a huge amount of data very quickly (e.g. running an embassy in a hostile country?)

[-]

sdns575@reddit (OP)

Thank you so much for your explanation. Appreciated.

symcbean@reddit

It's worse than pointless if you store the *decryption* key in the same place as the encrypted backup.

You are just adding another layer of complexity to your restore.

But as others have pointed out - you don't need to use same key for decrypting as encrypting. If the decryption key is only in memory on the backup, and the backup host has more layers of protection, then you have mitigated the risks of compromise.

rfc2549-withQOS@reddit

Borg. Make backup append only, create high secure server to do pruning.

clients can only add, backup srv can be hacked, all good

BrokenWeeble@reddit

Don't use symmetric keys, then it doesn't matter if they have the encryption key, you keep the decryption key safe and off the server.

therealtimwarren@reddit

Asymmetric keys are very computationally expensive and therefore are not used to encrypt a lot of data. They would not be appropriate for backup use.

To solve this problem you can encrypt the backup using a randonly generated symmetric session key and then encrypt the session key with the asymmetric public key and attach the result to the backup too. That way you combine both speed of symmetric encryption with the security and flexibility of asymmetric encryption.

SurfRedLin@reddit

Does borgbackup support this?

Thank you for your answer. Appreciated

WildFrontier2023@reddit

TLDR: Encrypting local backups can be useful but isn't foolproof if the encryption keys are on the same server. Whether it's worth it depends on your threat model and how you manage access to the keys.

You’ve already identified the core issue: if the encryption key is stored on the backup server and the server gets compromised, the attacker can access both the data and the keys. So, does it make sense to encrypt in this case? It depends.

If you’re moving backup data to an external location (e.g., tapes stored offsite, S3, or another cloud), encryption is almost non-negotiable to prevent unauthorized access to sensitive data.
For backups stored on removable media (e.g., tapes or swapped disks), encryption protects against theft or loss of the physical device. Without encryption, someone with access to the physical media could easily read the data.
Even if someone compromises your backup server, encryption adds an extra layer of security that could deter less sophisticated attackers or at least delay them.
Depending on your industry or country, you might be required to encrypt backups, even if stored locally, to comply with data protection laws like GDPR, HIPAA, or PCI DSS.
Encryption helps limit the damage in case an insider gains unauthorized access to backup media but not the encryption keys.

If your encryption keys are stored insecurely (e.g., on the same server), you’re not really improving security. Worse, it can create a false sense of safety.
If your backup server is air-gapped, heavily firewalled, or otherwise isolated, the risk of compromise might be so low that encryption isn’t a top priority.
Encryption adds computational overhead and complicates the backup/restore process. In some environments, this may not be worth the trade-off if the risk of attack is minimal.
Encrypted backups make corruption harder to detect and recover from. If an attacker corrupts the encrypted backup, you might not realize it until you try to restore.

Use a hardware security module (HSM) or a key management service to keep keys off the backup server.
Use write-once-read-many (WORM) storage to prevent tampering.
Protect access to the backup server with MFA to make it harder for attackers to gain control.
Implement strict monitoring of the backup server for signs of compromise.

If you're not managing the encryption keys securely or your backup server is a high-value target, encryption might not provide the protection you’re hoping for. However, it still has value for physical media protection, compliance, and defense in depth. Ultimately, it boils down to your specific threat model and risk tolerance.

Thank you for your detailed and complete answer. I appreciate it. Upvoted