3 ms·
Meh, just another backup solution that requires AWS keys, ssh keys, etc. to be kept on the same server where your data is. What if that server is compromised? T
by kijin 7y ago
Meh, just another backup solution that requires AWS keys, ssh keys, etc. to be kept on the same server where your data is. What if that server is compromised? The attacker now has all the keys he needs to delete or modify your backups, too.
For maximum peace of mind, always pull backups from a separate server that is not exposed to the world. Don't let your primary server push arbitrary data to the backup store.
This rule is trickier to follow when your backup store can't run scripts, which is why so many tools designed to work with S3 tell you to keep the keys exposed. But if you really want to, you can use an intermediate host to pull backups before pushing them again to S3.
- slig 7y agoCan't you set up keys that are only allowed to do GET/PUT? I know that tarsnap [1] can work with `list`, `write` and `delete` keys. [1]: http://www.tarsnap.com/man-tarsnap-keymgmt.1.html http://www.tarsnap.com/man-tarsnap-keymgmt.1.html
- akerl_ 7y agoAs the other commenter noted, this is why you’d give the backup keys the ability to upload data but not delete data. Combine that w/ S3 Object Versioning and you’ve got a pretty solid approach.
- longwave 7y agoBorg has an append-only mode [1] that prevents clients from overwriting data. [1] https://borgbackup.readthedocs.io/en/stable/usage/notes.html#append-only-mode https://borgbackup.readthedocs.io/en/stable/usage/notes.html...