I am currently dealing with the need to protect backups from malicious destruction and have already read a lot about “ransomware protection” and “WORM support” here in the forum.
The question came to me why there couldn’t be a general (i.e. storage provider-independent) way to protect against deletion. I mean, many of the solutions involve using a read-only repo and then tinkering with it in order to “prune” the data anyway.
How about simply assigning a role to the keys for a repo? Since a repo can have several keys, you would have a key that is used to execute an append-only use of the repository from an “insecure” client. And a second key that is also allowed to delete. This one would be used on a “secure” client to clean up (=delete content).
The big advantage would be that you would not have to rely on a rest-server with the append-only option or use a functionality of S3 buckets, but this combination would be compatible with any backend.
@tribor The access permissions to a storage backend you give to restic can also be used by an adversary. And having access permissions which allow to remove or overwrite data in the storage backend, they wouldn’t need to open a restic key, but can just destroy your backup.
If your idea was about saving access permissions of a storage backend in the key information - the keys are stored in the storage backend, so that way you’d just created an hen-and-egg problem…
hello @alexweiss, first of all thank you for the quick answer. I assume that the key, that has delete authorization, is executed from a secure system only. This should be a prerequisite for consideration.
The other key only allows the addition of data (write new backups/restore backups/list backups). but not the modification of existing backups or any operations with keys.
In my opinion, this should actually be possible, even if the keys are stored in the backend server.
@tribor My point is: Independent from what you store in restic key files or implement into restic depending on keys - if you don’t add restic-independent protection to your storage backend, an adversary can destroy your backup without even using restic.
But, if you anyway do have to ensure such protection to your storage backend, and this suffices for ransomware protection - why should you add an additional layer by adding functionality to restic keys?
@tribor Put another way - the only thing that determines which key can be used for what is the client (i.e. the restic binary or anything else that has access to the repository). There is nothing on the storage/backend/server side that is involved in the decryption and usage of keys (since restic is designed to not trust the storage backend). This means that an attacker that is able to access/use a given key can do whatever they want with the repository, since it’s up to them (e.g. their software or modified restic binary) to read or ignore the suggested role information in that key.
thanx @alexweiss and @rawtaz for clarification. I now understand that my idea is not a security gain nor a solution to a ransomware threat
1 Like