Das KürzlicheAbschaffung von Codespacesbrachte mich zum Nachdenken über Offsite-Backup-Prozesse (die ich derzeit manuell mit Passworteingabe durchführe). Ich habe gelesenAnleitungenzeigt, wie Backups durch Duplicity automatisiert werden. Dabei geht es meist um die Verwendung eines SSH-Schlüssels, um den Authentifizierungsprozess beim Backup-Server zu automatisieren.
Dies scheint mir jedoch voller Lücken zu sein. Wenn der Server, der gesichert wird, so kompromittiert ist, dass der böswillige Benutzer Zugriff erlangt hat, könnte er sich automatisch beim Backup-Server anmelden und die Backups entfernen. Vorausgesetzt, der Administrator hat /usr/bin/nologindie /etc/passwdDatei für den Backup-Benutzer verwendet (ich habe keine Ahnung, inwieweit man sich darauf verlassen kann oder ob es Duplicity ohnehin daran hindern würde, remote zu arbeiten), könnte der böswillige Benutzer Duplicity mithilfe des duplicity remove-older-than [time now]Befehls dennoch dazu bringen, die Backups zu löschen.
Ist die einzige sichere Lösung, die Dateien mit rsync über ssh an den Backup-Server zu senden und einen „Master-Benutzer“ auf dem Backup-Server lokale iterative Backups aller Benutzerkonten in seinem eigenen Speicherbereich durchführen zu lassen (d. h. nur er hat Berechtigungen für seine eigenen Dateien, aber er hat die Berechtigung, alle Dateien der anderen Konten zu lesen)? Oder gibt es eine Möglichkeit, zu verhindern, dass Duplikate Backups entfernen und Remote-Logins zu verhindern?
Antwort1
Soweit ich weiß, kann Duplicity kein Backup eines Remote-Verzeichnisses in ein lokales Verzeichnis erstellen. Ich löse das Problem in zwei Schritten. Auf dem Backup-Server führen Sie Folgendes aus:
Führen Sie rsync über SSH mit SSH-Schlüsseln aus, um das Remote-Verzeichnis mit einem lokalen Verzeichnis zu synchronisieren
rsync -avz -e ssh user@remote:/remote/verzeichnis lokales_verzeichnis
Führen Sie Duplicity von einem Verzeichnis in ein anderes aus. Verwenden Sie asymmetrische GnuPG-Schlüssel, sodass Sie bei der Verschlüsselung keine Passphrasen benötigen.
duplicity --encrypt-key=IHRE_SCHLÜSSEL-ID lokales_Verzeichnis file://Backup-Verzeichnis
oder ohne das Backup zu verschlüsseln:
duplicity --no-encryption local_directory file://backup_directory
Antwort2
Nach dem Hochladen der Sicherung können Sie chattr +isie unveränderlich machen, sodass sie nicht geändert oder gelöscht werden können. Nur Root kann dieses Flag setzen oder löschen.
Alternativ könnte man chowndie Dateien nach dem Hochladen auch einem anderen Benutzer zuweisen, so dass der Backup-Account keinen Zugriff mehr darauf hat.