Wasabi/S3: Question re: hacker-safe bucket access for backups

Is there anywhere in the Duplicacy documentation where the required Wasabi/S3 permissions are documented for each operation (e.g. backup, stage-1 prune, stage-2 prune, etc.)? If so, please point me to it (I didn’t find it).

If someone has looked into this please let me know if this makes sense. Goal: Limit damage that can be done if the machine getting backed-up get compromised.

Here’s my proposed plan:

Backup a headless VPS
-Wasabi credentials for a user that can only write and not delete from a bucket are used for Duplicacy config that is only accessible by root to backup the VPS. If the VPS gets compromised by a hacker and they get access to the Wasabi bucket credentials through the Duplicacy config, the backups already in the Wasabi bucket cannot be edited/deleted by the hacker.

Pruning
-On a different machine (e.g. a server I trust with no incoming ports open), I periodically run the pruning operation using a different set of credentials that have read/write access to the same storage bucket on Wasabi that was used to backup the VPS.

hello I have implemented that same configuration in several installations, even so I have the doubt if I have compromised the security since those wasabi credentials do have permissions to modify files. Wasabi’s policy (on the server where the copies are made) allows you to add and modify files and denies the deletion option.
What do you think @gchen ?

I do not know if this is implemented at Duplicacy level anywhere. At its simplest, you could implement object locking/versioning with an enforcement of X days; long enough for you to realise a hacker has dropped all your backups, and restore them from the versioned/locked objects in the bucket instead.

It was supposed to be implemented in the next release, but I’m not sure what’s the status now: