> 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.)
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.)