Cloud-Encryption: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
Zeile 58: | Zeile 58: | ||
</pre> | </pre> | ||
'''Daten''' | |||
Die Daten liegen verschlüsselt im Verzeichnis ''/srv/crypt'', und werden entschlüsselt unter ''/srv/daten'' vom Fileserver zur Verfügung gestellt (CIFS, NFS). Anwender können auf die letzte Datensicherung zum einfachen ''Self-Service-Restore'' über ''/backup/snapshot-latest'' zugreifen. | Die Daten liegen verschlüsselt im Verzeichnis ''/srv/crypt'', und werden entschlüsselt unter ''/srv/daten'' vom Fileserver zur Verfügung gestellt (CIFS, NFS). Anwender können auf die letzte Datensicherung zum einfachen ''Self-Service-Restore'' über ''/backup/snapshot-latest'' zugreifen. | ||
=== Datensicherung === | === Datensicherung === |
Version vom 4. März 2014, 21:10 Uhr
Verschlüsselung, Datensicherung, Cloud und mehr
(En)CryptFS verschlüsselt Daten auf Fileebene. Diese können verschlüsselt in beliebigen Cloud-Storage (Anbindung z.B. per webdav) gesichert (z.B. mittels rsync) werden, und von beliebigen Geräten - sogar einem Live Linux auf einem USB-Stick - im Notfall gelesen werden.
Ich habe ein Knoppix mit verschlüsselter Datenpartition auf einem USB-Stick an meinem Schlüsselbund. Damit kann ich von jedem (fremden) PC vom USB-Stick booten, eine VPN-Verbindung nach Hause aufbauen oder ein verschlüsseltes Backup-Verzeichnis aus einem Cloud-Storage mounten und darauf entschlüsselt zugreifen. Meine Katastrophen-Datensicherung liegt somit verschlüsselt in einem Cloud-Storage - falls meine Hütte mal abbrennt oder absäuft, oder ein Blitzschlag sämtliche Harddisks zerstört, welche die Daten redundant speichern.
Verschlüsselung
Nachdem meine 2TB Harddisk einen Defekt hatte, und ich zwei Wochen gebraucht habe, die Daten runter zu kratzen und anschliessend zu löschen (dd dauert bei einer defekten 2TB Disk ziemlich lange), habe ich mich entschlossen meine persönlichen Daten zu verschlüsseln. Von drei neuen Festplatten war prompt eine sofort wieder defekt, freilich erst, nachdem ich diese mit 2TB in einem RAID eingebunden und gesynced hatte. Garantie heisst: Disk muss zurück zum Händler ... also sollten keine Daten mehr drauf liegen - ich bin extrem genervt.
Das Problem: Der (XEN-) Server muss vollautomatisch starten, der Schlüssel darf nicht auf den Platten liegen!
Die Lösung: Ich speicher den Schlüssel auf einem USB-Stick, und kopiere diesen verschlüsselt über das Netzwerk in den RAM (tmpfs)!
Der Fileserver (srv) liest den Schlüssel /etc/EncFS.PWD per ssh vom XEN-Hostsystem (m450). Im Bootscript rc.local wird der Schlüssel vorher vom USB-Stick in den RAM "importiert".
XEN-Host
Der Schlüssel /etc/EncFS.PWD wird im RAM (tmpfs) unter /var/run gespeichert und liegt somit nicht auf der Disk!
root@m450# ls -l /etc/EncFS.PWD lrwxrwxrwx 1 root root 18 Sep 9 17:38 /etc/EncFS.PWD -> /var/run/EncFS.PWD root@m450:~# df /var/run Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf tmpfs 35780 908 34872 3% /run root@m450:~# cat /etc/rc.local #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. ssh vm01 'cat /root/USB-Stick/EncFS.PWD' > /etc/EncFS.PWD # read EncFS.PWD with ssh
Fileserver
Der Fileserver srv benötigt den Schlüssel /etc/EncFS.PWD zum entschlüsseln des Filesystems. Zum mounten wird ein Helper-Skript /usr/local/sbin/encfs.sh verwendet, welches in /etc/fstab eingetragen ist:
root@srv:~# cat /usr/local/sbin/encfs.sh #!/bin/sh encfs --public --extpass="ssh m450 cat /etc/EncFS.PWD" $* # get EncFS.PWD via ssh root@srv:~# cat /etc/fstab | grep encfs /usr/local/sbin/encfs.sh#/srv/crypt /srv/daten fuse noauto,kernel_cache,nofail 0 0 /usr/local/sbin/encfs.sh#/backup/snapshot/latest/srv/crypt /backup/snapshot-latest fuse noauto,nofail,ro 0 0
Daten
Die Daten liegen verschlüsselt im Verzeichnis /srv/crypt, und werden entschlüsselt unter /srv/daten vom Fileserver zur Verfügung gestellt (CIFS, NFS). Anwender können auf die letzte Datensicherung zum einfachen Self-Service-Restore über /backup/snapshot-latest zugreifen.
Datensicherung
Verschlüsselte Daten können an beliebigen Orte gesichert werden. Ich benutze zur Sicherung rsync, der letzte Snapshot wird jede Nacht in verschiedene Cloud-Speicher (T-Online, 1blu, ...) synchronisert.
Meine rsync-snapshot Datensicherung legt Snapshots im Verzeichnis /backup/snapshot an, welche vom Fileserver bei Bedarf (readonly!) gemounted werden können.
Das verschlüsselte Verzeichnis /backup/snapshot/latest/srv/crypt wird jede Nacht per rsync in Cloud-Storage gesichert.
Cloud Storage
Cloud-Storage binde ich per webdav auf meinem Rechner ein. Teilweise kann sogar direkt rsync über ssh zur Synchronisation verwendet werden. Webdav-Storage kann man inzwischen meist direkt verwenden (Windows und Linux Clients), sehr praktisch.