cross-posted from: https://lemmy.zip/post/1088852
Archived version: https://archive.ph/cR91h
Archived version: https://ghostarchive.org/archive/F2HRY
cross-posted from: https://lemmy.zip/post/1088852
Archived version: https://archive.ph/cR91h
Archived version: https://ghostarchive.org/archive/F2HRY
Often the server needs access to make backups, so when you get in and get root, you also have access to delete the backups.
It’s hard to protect against stuff like that if the hacker becomes root.
Part of a good backup solution involves ensuring that it’s literally impossible for the “root” / “administrator” whatever user on the production system to delete the backups. For instance, were this AWS, it would be done by creating a separate AWS account and use IAM roles to provide access to a S3 bucket with the “DeleteObject” permission explicitly denied. Perhaps, even deny everything except something like PutObject, and ensure the target S3 bucket is versioned, so even overwriting the contents with garbage is recovered by restoring a previous version.
But most businesses don’t think like that.
Yup. I work as a devops guy with aws and that’s what I do. But I’ve seen a lot of enterprises having no clue about these things.