## tl;dr
To secure backups without storing backup credentials on the server being backed up, I utilize a separate server to initiate and authenticate the backup process. This prevents potential attackers with access to the production server from also gaining access to the backup storage.
## long story
Some time ago, I read about a situation where a hacker acquired credentials for remote backup storage and proceeded to encrypt or destroy both local and remote data.
Many administrators rely on cronjobs to automate backups to external storage using familiar tools like rsync, BorgBackup, Restic, or Rclone. Naturally, authentication data must be accessible for this process. In the case of BorgBackup, for instance, the key is also necessary if the data is encrypted.
However, the destination, such as cloud backup, isn't typically a one-way "data tomb" where you can only upload data without any capability to read or alter existing data. The authentication data can potentially be exploited to manipulate or destroy a repository, such as in the case of BorgBackup.
## solution approaches
Of course, a tamper-proof write-only backup storage with snapshot backup would be desirable, but most cloud services do not offer this. Also, no provider that I know of offers the option of "pull" backups. This would mean that hundreds of your own server credentials would end up with the cloud provider - and you don't necessarily want that either.
I implement my data backups following the 3-2-1 rule, utilizing multiple cloud services. However, my approach involves:
1. Absence of credentials for the cloud storage on my server.
2. A user account on the server capable of initiating BorgBackup with restricted rights in a restricted environment.
3. Initiation of a backup via a cronjob on another server, which logs in to the primary server, executes BorgBackup with the necessary credentials, and then logs out upon completion.
If an attacker gains access to the system, they won't actively find access credentials for the backup server. Ultimately, they would need to debug the incoming call for BorgBackup or read the memory. Nevertheless, this setup ensures that backup storage credentials are not stored on the production server.
### pros
- Backup credentials remain separate from the server being backed up.
- Prevents manipulation of backups by attackers with access to the production server.
- Backup process is initiated from a separate, secured server.
### cons
- Additional management overhead of maintaining a separate backup initiation server.
- Risk of missed backups if the backup initiation server experiences downtime.
- Complexity involved in setting up the restricted user account and shell on the production server.
