How do you protect a remote backup from a compromised account?
from eyesaremosaics@lemmy.zip to selfhosted@lemmy.world on 19 Jun 23:00
https://lemmy.zip/post/66460350

Let’s say you have access to a remote machine and use it to copy backups occasionally, eg with rsync. Your local machine has credentials stored that allow write access on the remote machine, however if the local account was compromised that could also allow access to the remote machine and the data stored there.

How can you grant access to an account to write remotely, but also protect the data from this account? One possibility could be to change the permissions on the data after it is copied to prevent deletion/interference, although I’m just making this up. Is there a standard practise for this?

#selfhosted

threaded - newest

ShellMonkey@piefed.socdojo.com on 19 Jun 23:04 next collapse

Encrypt before send, and if you want to have protection against deletions of the data have a cold backup offline other than during the copy.

zorflieg@lemmy.world on 19 Jun 23:19 next collapse

What you are talking about is Immutability and an append only backup. The s3 file system and some others has Immutability built in. Not all backups can do append only.

TheFogan@programming.dev on 19 Jun 23:19 next collapse

I mean depends on the solution you are using, but you can have multiple accounts on the remote backup. IE so upon completion of the backup. The remote machine moves the backup to an offline or read only share (depending if you need those credentials to access the data again later),

Obviously most important thing is your credentials that make the backup… should be very limited in scope to just doing those backups.

HelloRoot@lemy.lol on 19 Jun 23:20 next collapse

I think you could do it somewhat like hetzner does for their storage boxes. You get an account that has read and write access to a directory and nothing outside. The accound can only run a limited set of commands, like ls, cat, nano, rsync etc. but has no access to commands that modify the filesystem.

Then you can use a copy on write fs like btrfs and make scheduled staggered snapshots.

I usually do 1x per year, 1x per month of current year, 4 per week of current montg, 7 per day in current week.

I have no clue what they use to limit the user accounts like that btw. but maybe that gives you a new jump off point for further research.

bacon_pdp@lemmy.world on 19 Jun 23:28 next collapse

Append only permissions.

Encrypted deltas.

Basically the time of the connection is the name of the only that folder that you have access to.

You can also setup a yubikey (or nitrokey) that requires you to physically process and would be immune to the host being compromised.

eleijeep@piefed.social on 19 Jun 23:37 next collapse

Restic has quite a good solution for this: https://restic.readthedocs.io/en/stable/060_forget.html#security-considerations-in-append-only-mode

in_my_honest_opinion@piefed.social on 20 Jun 00:00 collapse

Funny thing is that blockchains are actually good for this type of thing. Too bad crypto bros got a hold of it.

xia@lemmy.ca on 19 Jun 23:43 next collapse

You’ve got the right idea with the permission change… the key is that you can have code executing on the remote side with different permissions. So the writer process has permission to write in one directory, and the turnsyle procees (often the root super-user) rotates the files or directories at a different time (or on a signal, sometimes).

frongt@lemmy.zip on 19 Jun 23:46 collapse

WORM: write once, read many. Any good backup software supports this.

You could also keep offline backups. You can’t compromise what you can’t reach.