11 ms·
A crucial point you missed: Ransomware gangs often destroy your backup infrastructure. So it's important to create pull-only backups or backups that cannot be
by likecarter 5y ago
A crucial point you missed:
Ransomware gangs often destroy your backup infrastructure. So it's important to create pull-only backups or backups that cannot be deleted / overwritten.
- varispeed 5y ago> backups that cannot be deleted / overwritten That gets complex if your database contains PII. If a user asks for their account to be deleted...
- tomrod 5y agoWould it be sufficient that the delete accounts script be managed and merged at restoration time?
- marcinzm 5y agoYou still have their data and anyone who bypasses the restoration script can get it so no.
- anang 5y agoThis is not true. The prevailing opinion is that backups do not need to be modified and that it’s enough to delete at restore time (and to of course not process the data again).
- varispeed 5y agoThe neatest way I heard is to store PII in an encrypted form and then delete encryption keys when a user requests deletion. That requires the keys to be in a different backup pipeline though.
- viraptor 5y agoIt's not "cannot be overwritten ever". It's more "you can overwrite it using credentials stored in a safe location and never from the production environment". Someone will always have permissions to remove or change the entries, just not easily and not in an automated daily process way.
- korethr 5y agoI thought this was sufficiently implied with "keep them segregated from the rest of your infrastructure," but yes, you are correct. It is important to have a set of backups that can't be destroyed by the attackers. You might get lucky that your hand-rolled solution is so hacky that a ransomware gang overlooks it. But better to not rely on that luck. In the past, this was achieved by having a set of tapes offsite. Today, one might configure Veeam to lie when issued a delete command, and instead send the data off to an Amazon glacier instance that requires different credentials to read, write, and delete.
- rsync 5y ago"Ransomware gangs often destroy your backup infrastructure. So it's important to create pull-only backups or backups that cannot be deleted / overwritten." Every rsync.net customer has ZFS snapshots available in their account that are immutable. They are read-only. So, even if Mallory trashes your primary site and then gains access to your rsync.net credentials, the daily/weekly/monthly snapshots cannot be destroyed.
- m3nu 5y agoImmutable backups are often overlooked. At borgbase.com, we call this “append-only” mode and the large majority of repositories uses it. With S3 (or similar) you would add some policies to disable deletions. So it’s usually doable, but needs to be considered when setting up the backup process.
- formerly_proven 5y agoDoes the append-only mode you have in borgbase fix the issues of the append-only mode in Borg itself? https://borgbackup.readthedocs.io/en/stable/usage/notes.html#drawbacks https://borgbackup.readthedocs.io/en/stable/usage/notes.html... Because the way it works in Borg isn't really workable in practice, it only seems to be good to check a box.
- m3nu 5y agoWe use the same public version of Borg, so those limitations apply. It’s still quite workable. Just prune from a different machine or once a year when the repo gets too large. We may move to reject destructive commands from append-only repos in the future, but this will break existing workflows. Discussion on this here: https://feedback.borgbase.com/posts/28/reject-delete-and-prune-commands-for-append-only-repos https://feedback.borgbase.com/posts/28/reject-delete-and-pru...
- closeparen 5y agoThat’s all well and good for weather data, but if anything in your backup is in any way related to user behaviors or transactions, immutability is a crime.