Backup in die Cloud: Unterschied zwischen den Versionen
Die Seite wurde neu angelegt: „Nutzen Sie ihren (vielfach ungenutzt) vorhanden Speicherplatz bei Cloud-Anbietern für das persönliche Sicherheits-Backup außer Haus. Kür: Ein verschlüssel…“ |
Keine Bearbeitungszusammenfassung |
||
Zeile 4: | Zeile 4: | ||
Für letzteren Fall läuft auf meinem Fileserver drei Mal täglich ein Skript, welches ein Snapshot-Backup erzeugt, ohne wirklich viel Platz zu benötigen: Das allseits bekannte „rsync“ – das Schweizer Taschenmesser unter Sync- bzw. Kopierprogrammen – ist in der Lage, per Hardlink Kopien im Filesystem anzulegen, welchen keinen zusätzlichen Speicherplatz belegen. Es gibt natürlich viele Programme die Backups erzeugen können, aber ein stabiles selbstgeschriebenes Skript hat für mich immer noch einen gewissen Vorteil: Es funktioniert, überall. Ohne dass ein Programm-Update daran eventuell rumpfuscht, es nicht mehr unterstützt wird, eine neue Version ein Upgrade oder sogar eine Migration erfordern würde. | Für letzteren Fall läuft auf meinem Fileserver drei Mal täglich ein Skript, welches ein Snapshot-Backup erzeugt, ohne wirklich viel Platz zu benötigen: Das allseits bekannte „rsync“ – das Schweizer Taschenmesser unter Sync- bzw. Kopierprogrammen – ist in der Lage, per Hardlink Kopien im Filesystem anzulegen, welchen keinen zusätzlichen Speicherplatz belegen. Es gibt natürlich viele Programme die Backups erzeugen können, aber ein stabiles selbstgeschriebenes Skript hat für mich immer noch einen gewissen Vorteil: Es funktioniert, überall. Ohne dass ein Programm-Update daran eventuell rumpfuscht, es nicht mehr unterstützt wird, eine neue Version ein Upgrade oder sogar eine Migration erfordern würde. | ||
Dieser Artikel ist zugegebenermaßen entstanden, weil ich mein seit Jahr(zehnt)en installiertes System einer längst überfälligen Generalüberholung unterzog. Zur Verschlüsselung meiner persönlichen Daten kam EncFS zum Einsatz, welches 2014 in einem Audit einige Sicherheitslücken offenbarte, von denen einige immer noch nicht behoben sind (https://vgough.github.io/encfs/). Meine Recherche nach einer Alternative führte mich zu gocryptfs (https://github.com/rfjakob/gocryptfs-website). Gocryptfs auf der anderen Seite hielt (bisher) einem 2-Tages Audit stand. EncFS und gocryptfs verwenden das gleiche Konzept – ein virtuell ver- / entschlüsseltes Dateisystem wird durch einen Mount-Befehl in das Dateisystem eingehängt. Beide bieten eine „-reverse“ Option, welche unverschlüsselte Daten online in verschlüsselter Form in einem Dateisystem zur Verfügung stellt. Diese Option ist prädestiniert für das verschlüsselte Backup von Dateien, welche individuell und nur Bedarfsorientiert gesichert werden sollen. | |||
Ein früherer Defekt einer nagelneuen 4TB Disk innerhalb der Garantie zog aufgrund des Hardware-Fehlers einen zwei Wochen dauernden Löschvorgang der Disk nach sich. In Kombination mit den Sicherheitsbedenken des Einsatzes von EncFS für Backup-Szenarien in Cloud-Speicher ist demzufolge die Vollverschlüsselung aller Festplatten und der Einsatz von gocryptfs naheliegend. Mein Backup-Skript kopierte die bisher im Dateisystem verschlüsselten Dateien 1:1 in die Cloud. Mit der Vollverschlüsselung der Festplatte stehen aber keine verschlüsselten Daten zum Kopieren mehr zur Verfügung. Gocryptfs erzeugt mit der Option -reverse ein virtuelles Filesystem, welches Dateien online verschlüsselt, ohne diese erneut auf der Festplatte zu speichern. | |||
Das Passwort zum Ver- und Entschlüsseln der Disks sollte nicht auf der Festplatte selbst gespeichert werden, welche es entschlüsselt. Damit der Server bei einem Reboot trotzdem ohne Passwortabfrage automatisch hochfährt, wird das Passwort z.B. von einem USB-Stick gelesen. Dieses kann in einer Datei oder auch versteckt in den ersten ungenutzten Blocks eines Devices außerhalb des Dateisystems gespeichert sein. Da in meinem Boot-Vorgangs das Netzwerk schon zur Verfügung steht, wenn die Dateisysteme mit den User-Daten eingehängt werden, lese ich das Passwort per SSH von einem anderen Gerät ein, sodass der USB-Stick selbst nicht auf meinem Backup-Server erreichbar ist. | |||
In Punkto Datensicherheit werden jetzt folgende Aspekte berücksichtigt: | |||
* Mehrfache tägliche Datensicherung schützt vor versehentlichem Löschen | |||
* Vollverschlüsselung schützt persönliche Daten auf den Festplatten | |||
* Passwörter zum Entschlüsseln der Festplatten sind auf unabhängiges System bzw. Device wie USB-Sticks ausgelagert | |||
* Backup der Daten liegt verschlüsselt in der Cloud vor | |||
Wenden wir uns dem Thema Cloud-Backup zu. Wir haben alle erzwungenermaßen bereits Accounts bei mehreren Cloud-Providern wie z.B Google, Microsoft, T-Online um nur einige zu nennen. Viele bieten auch mehr oder weniger kostenlosen oder zusätzlichen Cloud-Speicher an, der selten Verwendung findet. Warum sollten wir also diesen allzeit und weltweit zur Verfügung stehenden Datenspeicher nicht dafür nutzen, unsere wichtigen Daten dort verschlüsselt abzuspeichern? Dem steht die durch dezentrale Zersplitterung entstehende Aufwand zur Beherrschung des zugrundeliegenden Datenchaos entgegen. Doch dem kann abgeholfen werden. | |||
Idee ist, dass wir die vorhandenen unterschiedlichen Cloud-Speicher für ein Backup der wichtigen persönlichen Daten nutzen. Dieser lässt ich normalerweise über Protokolle wie webdav oder SSH/SFTP auf dem eigenen Rechner einbinden. Zur Synchronisierung der Daten in die Cloud kommt rsync zum Einsatz. Entweder in Kombination mit SSH, oder per webdav werden die Daten per gocryptfs verschlüsselt und in die Cloud kopiert. Die benötigten Tools hierfür stehen alle als kostenlose Standard-Tools zur Verfügung: webdav, ssh, shell-skript, du, mount, find, rsync und gocryptfs. | |||
Um die in der Cloud verschlüsselten Daten zu lesen, werden diese per webdav oder sshfs auf einem Rechner gemountet und anschließend mittels gocryptfs wieder entschlüsselt in das lokale Dateisystem eingebunden. Das kann sogar auf einem Live-Linux und damit auch auf einem USB-Stick erfolgen, den ich am Schlüsselbund immer parat habe. | |||
Gocryptfs ist einfach zu benutzen. Man verschlüsselt ein vorhandenes Verzeichnis ‚SourceDir‘ wie folgt: |
Version vom 1. Dezember 2020, 21:35 Uhr
Nutzen Sie ihren (vielfach ungenutzt) vorhanden Speicherplatz bei Cloud-Anbietern für das persönliche Sicherheits-Backup außer Haus. Kür: Ein verschlüsselter USB-Stick mit einem beliebigen Live-Linux wie z.B. MX-Linux ermöglicht weltweiten Zugriff von einem beliebigen PC/Notebook.
Eines ist sicher, meine Daten sind sicher. So sicher, dass ich genau dann, wenn ich sie brauche, eventuell keinen Zugriff darauf habe: Im Urlaub im Ausland, wenn meine Papiere gestohlen wurden. Ein Stromausfall, der meinen Server außer Gefecht setzte, weil er nicht mehr fehlerfrei startet und ich keinen Zugriff auf den Fileserver mehr bekomme. Oder schlimmer: ein Unglück Zuhause wie Feuer oder Hochwasser, das meinen Server zerstört hat. Denkbar ist auch, dass Daten aus Versehen gelöscht wurden, was vielleicht nicht einmal bemerkt wurde.
Für letzteren Fall läuft auf meinem Fileserver drei Mal täglich ein Skript, welches ein Snapshot-Backup erzeugt, ohne wirklich viel Platz zu benötigen: Das allseits bekannte „rsync“ – das Schweizer Taschenmesser unter Sync- bzw. Kopierprogrammen – ist in der Lage, per Hardlink Kopien im Filesystem anzulegen, welchen keinen zusätzlichen Speicherplatz belegen. Es gibt natürlich viele Programme die Backups erzeugen können, aber ein stabiles selbstgeschriebenes Skript hat für mich immer noch einen gewissen Vorteil: Es funktioniert, überall. Ohne dass ein Programm-Update daran eventuell rumpfuscht, es nicht mehr unterstützt wird, eine neue Version ein Upgrade oder sogar eine Migration erfordern würde.
Dieser Artikel ist zugegebenermaßen entstanden, weil ich mein seit Jahr(zehnt)en installiertes System einer längst überfälligen Generalüberholung unterzog. Zur Verschlüsselung meiner persönlichen Daten kam EncFS zum Einsatz, welches 2014 in einem Audit einige Sicherheitslücken offenbarte, von denen einige immer noch nicht behoben sind (https://vgough.github.io/encfs/). Meine Recherche nach einer Alternative führte mich zu gocryptfs (https://github.com/rfjakob/gocryptfs-website). Gocryptfs auf der anderen Seite hielt (bisher) einem 2-Tages Audit stand. EncFS und gocryptfs verwenden das gleiche Konzept – ein virtuell ver- / entschlüsseltes Dateisystem wird durch einen Mount-Befehl in das Dateisystem eingehängt. Beide bieten eine „-reverse“ Option, welche unverschlüsselte Daten online in verschlüsselter Form in einem Dateisystem zur Verfügung stellt. Diese Option ist prädestiniert für das verschlüsselte Backup von Dateien, welche individuell und nur Bedarfsorientiert gesichert werden sollen.
Ein früherer Defekt einer nagelneuen 4TB Disk innerhalb der Garantie zog aufgrund des Hardware-Fehlers einen zwei Wochen dauernden Löschvorgang der Disk nach sich. In Kombination mit den Sicherheitsbedenken des Einsatzes von EncFS für Backup-Szenarien in Cloud-Speicher ist demzufolge die Vollverschlüsselung aller Festplatten und der Einsatz von gocryptfs naheliegend. Mein Backup-Skript kopierte die bisher im Dateisystem verschlüsselten Dateien 1:1 in die Cloud. Mit der Vollverschlüsselung der Festplatte stehen aber keine verschlüsselten Daten zum Kopieren mehr zur Verfügung. Gocryptfs erzeugt mit der Option -reverse ein virtuelles Filesystem, welches Dateien online verschlüsselt, ohne diese erneut auf der Festplatte zu speichern.
Das Passwort zum Ver- und Entschlüsseln der Disks sollte nicht auf der Festplatte selbst gespeichert werden, welche es entschlüsselt. Damit der Server bei einem Reboot trotzdem ohne Passwortabfrage automatisch hochfährt, wird das Passwort z.B. von einem USB-Stick gelesen. Dieses kann in einer Datei oder auch versteckt in den ersten ungenutzten Blocks eines Devices außerhalb des Dateisystems gespeichert sein. Da in meinem Boot-Vorgangs das Netzwerk schon zur Verfügung steht, wenn die Dateisysteme mit den User-Daten eingehängt werden, lese ich das Passwort per SSH von einem anderen Gerät ein, sodass der USB-Stick selbst nicht auf meinem Backup-Server erreichbar ist.
In Punkto Datensicherheit werden jetzt folgende Aspekte berücksichtigt:
- Mehrfache tägliche Datensicherung schützt vor versehentlichem Löschen
- Vollverschlüsselung schützt persönliche Daten auf den Festplatten
- Passwörter zum Entschlüsseln der Festplatten sind auf unabhängiges System bzw. Device wie USB-Sticks ausgelagert
- Backup der Daten liegt verschlüsselt in der Cloud vor
Wenden wir uns dem Thema Cloud-Backup zu. Wir haben alle erzwungenermaßen bereits Accounts bei mehreren Cloud-Providern wie z.B Google, Microsoft, T-Online um nur einige zu nennen. Viele bieten auch mehr oder weniger kostenlosen oder zusätzlichen Cloud-Speicher an, der selten Verwendung findet. Warum sollten wir also diesen allzeit und weltweit zur Verfügung stehenden Datenspeicher nicht dafür nutzen, unsere wichtigen Daten dort verschlüsselt abzuspeichern? Dem steht die durch dezentrale Zersplitterung entstehende Aufwand zur Beherrschung des zugrundeliegenden Datenchaos entgegen. Doch dem kann abgeholfen werden.
Idee ist, dass wir die vorhandenen unterschiedlichen Cloud-Speicher für ein Backup der wichtigen persönlichen Daten nutzen. Dieser lässt ich normalerweise über Protokolle wie webdav oder SSH/SFTP auf dem eigenen Rechner einbinden. Zur Synchronisierung der Daten in die Cloud kommt rsync zum Einsatz. Entweder in Kombination mit SSH, oder per webdav werden die Daten per gocryptfs verschlüsselt und in die Cloud kopiert. Die benötigten Tools hierfür stehen alle als kostenlose Standard-Tools zur Verfügung: webdav, ssh, shell-skript, du, mount, find, rsync und gocryptfs.
Um die in der Cloud verschlüsselten Daten zu lesen, werden diese per webdav oder sshfs auf einem Rechner gemountet und anschließend mittels gocryptfs wieder entschlüsselt in das lokale Dateisystem eingebunden. Das kann sogar auf einem Live-Linux und damit auch auf einem USB-Stick erfolgen, den ich am Schlüsselbund immer parat habe.
Gocryptfs ist einfach zu benutzen. Man verschlüsselt ein vorhandenes Verzeichnis ‚SourceDir‘ wie folgt: