3 ms·
> how to make backups safe in age of encrypting ransom ware. Versioned, offsite backups. For instance, if you have a database in an AWS account: * Give the ba
by damagednoob 4y ago
> how to make backups safe in age of encrypting ransom ware.
Versioned, offsite backups. For instance, if you have a database in an AWS account:
* Give the backup process write only (I.e. no delete permissions) to a GCP account.
* Create the backup in AWS and timestamp it
* Copy the backup to GCP using the above permissions.
* If you want to be more secure, copy the backup to a USBHDD (daily/weekly) and unplug it.
- deathanatos 4y ago> Give the backup process write only (I.e. no delete permissions) to a GCP account. I've looked into this before, and it is just not that easy. "Write" is delete, for most cloud storage systems, for the practical purposes of trying to keep a backup safe. (I.e., you might not be able to delete a blob in some bucket, but if you can write to it, you can just overwrite it with 0s.) "WORM" (write-once read-many) tends to be the term to search / gets the right documentation from most providers. In GCP's case, it appears to be "set up a retention policy", and that's similar to my experience with other providers. These bring their own set of problems. That said, encrypting ransomware isn't going to magically determine where your backups are, and for most orgs, having the backup at all (and having it tested) is the priority, not the whole WORM thing. (Orgs, IMO, also tend to get really uppity about having "database" backups, where "database" == {MySQL, Postgres, etc.}. But then there will be an S3 bucket that also has a bunch of data in it, and that never gets backed up, and nobody even questions that. And half the time it seems impractical to back up, too, due to a mix of cost and S3's design.)