Backup Strategie zu unverschlüsselten USB Medien

  • Ab sofort steht euch hier im Forum die neue Add-on Verwaltung zur Verfügung – eine zentrale Plattform für alles rund um Erweiterungen und Add-ons für den DSM.

    Damit haben wir einen Ort, an dem Lösungen von Nutzern mit der Community geteilt werden können. Über die Team Funktion können Projekte auch gemeinsam gepflegt werden.

    Was die Add-on Verwaltung kann und wie es funktioniert findet Ihr hier

    Hier geht es zu den Add-ons

Joschie

Benutzer
Registriert
10. Juli 2023
Beiträge
178
Reaktionspunkte
3
Punkte
18
Guten Tag Alle :D

ich habe hier eine DS 723+ mit DSM 7.3.2

Zur Sicherung meiner Synology NAS, Daten und System, nutze ich verschlüsselte HyperBackup's. Scheint auch gut zu klappen, aber dieser Schlüssel liegt auf einem ungeschützten Bereich meiner NAS.

Hierzu habe ich verschiedene Lösungs-Ansätze zu denen ich Eure Meinungen hören möchte:
  1. Den Schlüssel der HyperBackup's aus dem System löschen, sodass ich bei jedem Backup das Passwort für das HyperBackup manuell eingeben muss.
  2. Einen eigenen Key-Server auf der gleichen Maschine mit Docker-Container, der aber besser verschlüsselt ist. Oder den Key-Server auf einem meiner verschlüsselten Clients.
  3. Auf das USB-Medium ein weitere verschlüsselte Ebene einbauen, die aber manuell entschlüsselt wird.
  4. HyperBackup komplett streichen und dafür BTRFS+Snapshots auf den verschlüsselten "Freigabe Ordnern" einrichten.
  5. Hybrid-Lösung aus 1)+4) Also den HyperBackup von Synology löschen. Dann nur noch manuelle HyperBackups. Und den Rest mit BTRFS-Snapshots.
  6. Manuell mit selbst gebastelten Skripten aufbauend auf den Verschlüsselungs-Werkzeugen meiner NAS und rsync, oder sogar Borg, zur lokalen Nutzung. Server Dokumentation manuell besser ausarbeiten.
  7. 2FA mit USB-Key um Schlüssel-Manager auf der Synology abzusichern.
  8. LUKS auf externem USB-Laufwerk, manuell einbinden.

Weitere Ideen?


Bei den Snapshots weiß ich halt nicht, ob man die HOME-Verzeichnisse der Borg-Backup Benutzer auslassen kann? Borg verschlüsselt ja alles Client-seitig.

Grüße
 
Zuletzt bearbeitet:
Den Schlüssel der HyperBackup's aus dem System löschen, sodass ich bei jedem Backup das Passwort für das HyperBackup manuell eingeben muss.
Reden wir hier wirklich von HyperBackup? Ich mache auch verschlüsselte Backups, muss aber beim Backup keinen Schlüssel eingeben, sondern nur, wenn ich was eben aus diesem wiederherstellen will.

Auch auf USB Medien lässt sich mit HB verschlüsselt backupen.
 
@Kachelkaiser Genau so möchte er es ja haben, dass er eben das Passwort jedes mal eingeben muss vor einem Backup und der Schlüssel nicht automatisch "unverschlüsselt"(?) auf dem NAS liegt.
 
ah sorry, dann hatte ich das falsch verstanden. Sehe aber auch irgendwie den Sinn nicht darin :-(

Je aufwändiger ein Backup wird, desto eher wird es dann nicht mehr gemacht.

Wüsste jetzt aber auch nicht, wie man in HB einstellen kann, dass das Passwort bei Starten des Backup eingegeben wird. :unsure:
 
  • Like
Reaktionen: ottosykora
Meiner Meinung nach sieht das so aus:

Das, was Hyperbackup zum Verschlüsseln benutzt, ist der Public Key. Der kann nur zum Verschlüsseln benutzt werden. Wenn der lokal auf der Syno liegt, ist das also keine Sicherheitslücke.

Entschlüsseln kann man nur mit dem Private Key. Der Private Key wird beim Anlegen des Jobs als Schlüsseldatei heruntergeladen und kann natürlich sicher irgendwo anders abgespeichert werden.

Und beim Private Key scheint Synology auch ein eigenes Format zu benutzen. Die Datei ist jedenfalls mit puttygen z.B. nicht zu lesen.
 
Und beim Private Key scheint Synology auch ein eigenes Format zu benutzen. Die Datei ist jedenfalls mit puttygen z.B. nicht zu lesen.
Wobei das meine ich nicht immer so war, früher waren es normale Schlüsseldateien die man in einem normalen Editor anzeigen konnte, keine binärdatei wie jetzt.

Gab meine ich hier auch ein Thread damals dazu
 
Wobei das meine ich nicht immer so war, früher waren es normale Schlüsseldateien
Das kann durchaus sein, ich meine mich auch schwach erinnern zu können, war mir aber nicht mehr sicher.
 
Meiner Meinung nach sieht das so aus:

Das, was Hyperbackup zum Verschlüsseln benutzt, ist der Public Key. Der kann nur zum Verschlüsseln benutzt werden. Wenn der lokal auf der Syno liegt, ist das also keine Sicherheitslücke.

Entschlüsseln kann man nur mit dem Private Key. Der Private Key wird beim Anlegen des Jobs als Schlüsseldatei heruntergeladen und kann natürlich sicher irgendwo anders abgespeichert werden.

Und beim Private Key scheint Synology auch ein eigenes Format zu benutzen. Die Datei ist jedenfalls mit puttygen z.B. nicht zu lesen.
Laut Synology wird eine symetrische Verschlüsselung verwendet,

https://blog.synology.com/ger/hyper-backup-verschluesselungstechnologien/?utm_source=chatgpt.com

Also kein Public+Private ONLY-System.

Anscheinend wird über diese symetrische Verschlüsselung ein asymetrisches Verfahren drüber gelegt, aber jeder mit Admin Rechten kann ohne Passwort-Eingabe die Daten einsehen und in einen definierten Ordner zurückspielen. Ist das so richtig?
 
Zuletzt bearbeitet:
ich denke das ist wie alles andere, verschlüsselt kann nur symetrisch sein, asymetrisch wird für Transport und Lagerung etc des Schlüssels verwendet.
Asym zu verwenden für die Daten selber könnte diese extrem gross werden lassen, so was wäre total unpraktisch
 
Ist das so richtig?
Also wenn ich meine Daten in Hyper Backup von einem verschlüsselten Job anschauen oder zurückspielen möchte, brauche ich das Passwort der Verschlüsselung oder das Key-File. Klicke auf den HBK Ordner brauche ich das Passwort oder das Key-File.

Also meiner Meinung ist hier nix mit einfach als Admin ohne Passwort zurückspielen. Aber vielleicht stehe ich auch auf dem Schlauch und erkenne das Problem noch nicht richtig. 🤷‍♂️
 
sehe ich genauso wie @Ronny1978 . Ohne Passwort oder ohne Keyfile kein Restore. Das geht in HyperBackup so und auch im HyperBackupExplorer unter Windows.
 
  • Like
Reaktionen: luxdunkel
ist alles logisch
wenn man den Job erstellt, gibt man ein Pass ein und es wird auch ein Asym Schlüsselpaar erstellt. Password kann man sich merken oder aufschreiben. Den privat key kann man speichern wo man will, auf einem anderen Medium, im Netzwerk oder so was. Damit wird ja der Symkey verschlüsselt.

Dann kann man einen Backup machen. Dabei wird man logischerweise nichts gefragt, warum auch?

Wenn man dann aber an die .hbk will, muss man Passw eingeben oder den keyfile angeben. Dieser ist eben irgendwo abgelegt wo man es selber abgelegt hat.
(in meinem Fall auf einem anderen Server )

Daten werden dann mit dem key entschlüsselt welchen man soeben mit dem Passw oder dem Keyfile selber entschlüsselt hat.
 
  • Like
Reaktionen: luddi und Crashandy
was Hyperbackup zum Verschlüsseln benutzt, ist der Public Key.
das wird kaum so sein, damit würde die Daten extrem gross.
Verschlüsselt wird normalerweise mit einem Schlüssel, dieser selber wird aber mit dem Asym Schlüssel verschlüsselt und damit auch dann wieder freigegeben
 
Wenn man dann aber an die .hbk will, muss man Passw eingeben oder den keyfile angeben. Dieser ist eben irgendwo abgelegt wo man es selber abgelegt hat.
Das ist absolut korrekt! (y)

Bei der Erstellung eines verschlüsselten Backups muss man dafür ein Passwort eingeben und bekommt eine Schlüsseldatei. Ich verwende KeePass als Passwortmanager und genau dort hinein speichere ich mein Passwort und die Schlüsseldatei.

Wenn man nun aus Versehen die Schlüsseldatei versemmelt hat, dann gibt es später die Möglichkeit diesen Verschlüsselungsschlüssel herunterzuladen. Dieser Schlüssel liegt NICHT auf dem NAS, sondern in dem jeweiligen *.hbk Verzeichnis. In dem Fall von @Joschie also auf dem USB-Laufwerk.

2026-01-09 NAS-Server - Hyper Backup.png
 
Danke der Klarstellung. Dieses Konzept ist komfortabel aber bietet auch mehr Angriffsfläche. Ist aber ok. (y):)
 
Anders lässt sich das mit HB auch nicht abbilden denke ich.
 
aber bietet auch mehr Angriffsfläche
Wo? Du musst dich als Admin einloggen, die 2FA überwinden und ggf. auch noch das Key-File oder das Passwort haben. Übersehe ich was? Oder wo entsteht hier die Lücke?
 
  • Like
Reaktionen: Kachelkaiser
Au0er den Konto ist bereits ein Admin-Konto, was ich nicht hoffe :)
 
Also kein Public+Private ONLY-System.
Joschie, gerade du kennst es doch von anderen Gebieten. Public+Private Only gibt es nicht weil kaum realisierbar und sehr wenig nützlich wenn es einigermassen brauchbar sein sollte ;-)
 

Additional post fields

 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat