4 ms·
> you'll need to make sure that your master access to AWS S3 is never compromised Your master access to S3 should never go into your servers. Create an IAM acc
by rmbyrro 5y ago
> you'll need to make sure that your master access to AWS S3 is never compromised
Your master access to S3 should never go into your servers. Create an IAM access with authorization to only PUT objects into S3.
> For the purpose we have, Governance mode is OK
Maybe not (?), since Governance mode allows for deletion of previous versions. One careless mistake handling your access key/secret and you're exposed to bye bye backups.
End note: this is still not enough. An attacker could compromise your backup script and wait for 40 days before locking yourself out of your data. When you try to recover a backup, you'll notice you have none.
Perhaps most attackers won't have the patience and will just forget about you, but who knows?
A naive protection from that would be to store at least one version of the backups forever. But we're still not covered, since the attacker could compromise that particular version and boom.
I can't think of a comprehensive, fully closed-loop solution right now...
- bradknowles 5y agoThere is an immutable backup solution to S3: https://www.retrospect.com/en/support/kb/immutable_backups_on_amazon_s3 https://www.retrospect.com/en/support/kb/immutable_backups_o...
- rsync 5y ago"I can't think of a comprehensive, fully closed-loop solution right now..." The ZFS snapshots that you may configure on an rsync.net account are immutable. There are no credentials that can be presented to destroy them or alter their rotation other than our account manager whose changes always pass by a set of human eyes. Which is to say, no 'zfs' commands are ever automated. So the short answer is you simply point borg backup to rsync.net and configure some days/weeks/months of snapshots. The long answer - if you're interested: https://twitter.com/rsyncnet/status/1470669611200770048 https://twitter.com/rsyncnet/status/1470669611200770048 ... skip to 52:20 for "how to destroy an rsync.net account": "... Another thing that lights up big and red on our screen is ... someone's got a big schedule of snapshots ... and then they change it to zero ... you've got seven days and four weeks and six months but we want to change that to zero days of snapshots. We see those things ... and we reach out to people."
- selykg 5y agoRe: HN rsync.net discounts. Is that basically the Borg specific product? Or is there some discount on the normal rsync.net service? The Borg product misses one important thing for me and that is sub accounts. But the price difference between them is pretty large. I don't need the hand holding service, I already use the Borg service you provide but definitely would prefer having the sub accounts and possibly the ZFS snapshots might be useful.
- amluto 5y agoI’m a bit confused. https://www.rsync.net/products/borg.html https://www.rsync.net/products/borg.html says that, with the Borg pricing, there are no free snapshots. Are there non-free snapshots? The Borg pricing is quite competitive with S3 Glacier, although Deep Archive seems to have you beat. (Of course, Deep Archive loses badly if you actually read the data…)
- rsync 5y agoYes - any account can have snapshots. The discounted ones just don’t have free snapshots. They count against your quota. Full price accounts have 7 days that don’t count against your quota.
- hsbauauvhabzb 5y agoCan we stop it with the thinly veiled advertising?
- 5y ago
- justin_oaks 5y agoYou're right master access to S3 should never be on your servers. Permission to deleting object versions from your backup bucket should be reserved for the highest level of trust in your organization. These permissions shouldn't be accessible via a key sitting around on a computer, but should only be accessible to a person logging in with MFA. With such access only accessible to a person with MFA, it should be pretty hard to accidentally leak the secret (MFA-authenticated sessions have tokens that are time-limited). If even those AWS permissions are compromised, yes, you could lose your backups, but I hope you don't use S3 as your sole backup storage. I keep backups on both a local backup server and also in S3. If my AWS credentials are compromised, there should be no access to the local server. If someone accesses my local server, the access it has won't allow deleting S3 backups. Since my backups are encrypted, the attacker would have to also have the key to the backups to read the content.
- shkkmo 5y ago> An attacker could compromise your backup script and wait for 40 days before locking yourself out of your data. When you try to recover a backup, you'll notice you have none. There are many reasons why recovery from backup could fail. Verifying recovery from backup is critical, so the solution here is to not delete you oldest backup until you have verified recovery from a newer version.
- alanfranz 5y agoAuthor here. > Your master access to S3 should never go into your servers. Create an IAM access with authorization to only PUT objects into S3. Isn't this precisely the approach I take in the article? But, you need to make sure the master access to S3 is not compromised as well. Probably obvious, but certainly not wrong. > End note: this is still not enough. An attacker could compromise your backup script and wait for 40 days before locking yourself out of your data. When you try to recover a backup, you'll notice you have none. I agree that's a reasonable attack scenario. Just as for any backup strategy, you'd need a monitoring strategy (i.e. try restoring a backup at least every X days), and that was left as an exercise at the end of the post.