Storage-VPS verschlüsseln: Welche Methode schützt?

Was es bedeutet, Ihre Daten auf einem Storage-VPS zu verschlüsseln

Wenn Sie Ihre Daten auf einem Storage-VPS verschlüsseln, legen Sie zuerst fest, vor wem Sie sie verbergen möchten. Die Datenträger befinden sich im Rack eines anderen Betreibers. Das Wort verschlüsselt sagt nichts aus, solange Sie den Angreifer nicht benennen können, den die Verschlüsselung abwehrt. Hier sind drei Ebenen relevant. Sie schützen Sie jeweils vor unterschiedlichen Personen.

Die kurze Antwort für Backup-Daten lautet: Verschlüsseln Sie die Daten auf dem System, auf dem sie entstehen, laden Sie ausschließlich Chiffretext hoch und bewahren Sie den Schlüssel an einem Ort auf, den der Storage-Anbieter nie gesehen hat. Genau das erledigen restic und BorgBackup standardmäßig. Es ist die einzige Ebene, die gleichzeitig gegen einen neugierigen Betreiber und einen beschlagnahmten Server schützt.

Die serverseitige Verschlüsselung ruhender Daten ist ein anderes Produkt. Der Anbieter erzeugt und verwaltet den Schlüssel. Dadurch schützt sie seinen Prozess zur Datenlöschung und seine internen Abläufe. Sie schützt Sie jedoch nicht vor dem Anbieter. Wenn Sie den Schlüssel nicht selbst erzeugt haben, behandeln Sie die Daten als für jeden lesbar, der den Schlüssel erzeugt hat.

Vier Bedrohungen und welche Schicht welche verhindert

Verschlüsselt bedeutet nicht automatisch sicher. Dies sind vier getrennte Probleme. Eine Schicht, die eines davon löst, kann gegen das nächste wirkungslos sein.

• Eine Festplatte verlässt das Rack. Ein Laufwerk wird ausgetauscht, weiterverkauft oder entsorgt, während sich Ihre Datenblöcke noch darauf befinden. Eine vollständige Datenträgerverschlüsselung schützt hier gut, weil der Rechner ausgeschaltet ist und sich der Schlüssel nie auf diesem Laufwerk befand.
• Ein neugieriger Betreiber. Jemand mit Zugriff auf den Hypervisor oder den Speicher liest Ihre Dateien oder kopiert einen Snapshot. Ein verschlüsseltes Dateisystem, dessen Schlüssel auf einem anderen Rechner liegt, löst dieses Problem. Eine vollständige Datenträgerverschlüsselung auf derselben gemieteten Maschine reicht nicht aus, weil diese Maschine den Schlüssel während des Betriebs im Arbeitsspeicher hält.
• Ein beschlagnahmter oder forensisch erfasster Server. Eine laufende virtuelle Maschine wird einschließlich des Arbeitsspeichers aufgrund einer rechtlichen Anordnung oder während eines Sicherheitsvorfalls erfasst. Nur Daten, die bereits vor ihrer Ankunft als Ciphertext vorlagen, bleiben geschützt. Alles, was zu diesem Zeitpunkt eingehängt und lesbar ist, ist auch im Abbild lesbar.
• Ein kompromittiertes root-Konto auf Ihrer eigenen Maschine. root kann jedes eingehängte Dateisystem lesen. Daher sind für root alle darüberliegenden Schichten transparent. Den Schaden begrenzt die Trennung: Der Backup-Schlüssel liegt auf einer Maschine, die das Speichergerät nicht erreichen kann, und eine Kopie liegt an einem Ort, den die kompromittierte Maschine nicht löschen kann.

Entscheiden Sie, welche dieser vier Bedrohungen für Sie tatsächlich relevant ist, bevor Sie auch nur einen einzigen cryptsetup-Befehl eingeben. Die meisten Nutzer, die Speicher mieten, müssen die ersten beiden berücksichtigen. Ein Unternehmen, das Kundendaten speichert, muss auch die dritte beantworten.

Ebene 1: Vollverschlüsselung des Datenträgers mit LUKS

LUKS (Linux Unified Key Setup) ist der Standard für die Verschlüsselung auf Blockebene unter Linux. Es verschlüsselt eine gesamte Partition. Dadurch sind alle Daten, die Sie in das eingehängte Dateisystem schreiben, einschließlich Dateinamen und Metadaten, auf dem Datenträger Chiffrat. Auf einem Storage-VPS wenden Sie LUKS normalerweise auf das große Datenvolume und nicht auf die Root-Disk an, weil die Root-Disk klein ist und keine schützenswerten Daten enthält.

luksFormat löscht alle Daten auf der Zielpartition. Lesen Sie die Ausgabe von lsblk und vergewissern Sie sich vor der Ausführung, dass der Gerätename korrekt ist.

lsblk
sudo apt update && sudo apt install -y cryptsetup
sudo cryptsetup luksFormat --type luks2 /dev/sdb1
sudo cryptsetup open /dev/sdb1 vault
sudo mkfs.ext4 /dev/mapper/vault
sudo mkdir -p /srv/vault
sudo mount -o nosuid,nodev /dev/mapper/vault /srv/vault

Prüfen Sie das Ergebnis, bevor Sie Daten darauf speichern.

sudo cryptsetup status vault
sudo cryptsetup luksDump /dev/sdb1
lsblk -f

cryptsetup status vault sollte type: LUKS2 und cipher: aes-xts-plain64 melden. luksDump sollte im Keyslot PBKDF: argon2id anzeigen. Dabei handelt es sich um die speicherintensive Schlüsselableitung, die das Erraten einer Passphrase aufwendig macht. lsblk -f sollte auf /dev/sdb1 crypto_LUKS und Ihren ext4 auf /dev/mapper/vault anzeigen. Wenn cryptsetup status inactive ausgibt, ist das Gerät geschlossen. Das Einhängen schlägt dann mit special device /dev/mapper/vault does not exist fehl.

Diese Mount-Optionen sind nicht bloße Dekoration. Ein Storage-Volume enthält Daten. Daher muss nichts darauf ausführbar sein oder ein setuid-Bit besitzen. nosuid, nodev und noexec auf einem Daten-Mount zu setzen, verursacht keinen nennenswerten Aufwand.

Die Geschwindigkeit ist selten das Problem. Wenn grep -m1 -o aes /proc/cpuinfo aes ausgibt, stellt der Prozessor die AES-NI-Instruktionen bereit. Dadurch läuft aes-xts deutlich schneller, als ein netzwerkgebundenes Storage-Volume Daten liefern kann. Fehlt dieses Flag, wird die Verschlüsselung selbst zum Engpass. Das sollten Sie zuerst wissen: Siehe ob Ihr VPS AES-NI bereitstellt.

Warum LUKS auf einem gemieteten Server einen ausgemusterten Datenträger schützt, aber keinen laufenden Server

Hier liegt die Grenze, die niemand bewirbt. Der Rechner kann das Volume ohne den Schlüssel nicht entschlüsseln. Damit das Volume nach einem unbeaufsichtigten Reboot wieder eingebunden wird, muss der Schlüssel für den Rechner selbst erreichbar sein. Es gibt zwei ehrliche Möglichkeiten. Beide haben einen Nachteil.

Eine Keyfile auf dem Rechner. Das Volume wird beim Booten ohne anwesende Person entsperrt. Der Schlüssel liegt dann auf demselben gemieteten Server, auf der unverschlüsselten Root-Disk, die ebenfalls beim Provider liegt. Gegen den Fall eines ausgetauschten Datenträgers schützt das vollständig: Wird /dev/sdb aus dem Rack entfernt, enthält er nur unbrauchbare Daten. Gegen nichts anderes schützt es.

sudo install -d -m 700 /etc/cryptsetup-keys.d
sudo dd if=/dev/urandom of=/etc/cryptsetup-keys.d/vault.key bs=512 count=8
sudo chmod 600 /etc/cryptsetup-keys.d/vault.key
sudo cryptsetup luksAddKey /dev/sdb1 /etc/cryptsetup-keys.d/vault.key
sudo blkid -s UUID -o value /dev/sdb1

Übernehmen Sie die UUID aus dem letzten Befehl in /etc/crypttab.

vault UUID=8f14e45f-ceea-467a-9f9c-1b2c3d4e5f60 /etc/cryptsetup-keys.d/vault.key luks,discard

Fügen Sie das Mount anschließend in /etc/fstab ein.

/dev/mapper/vault /srv/vault ext4 defaults,nosuid,nodev 0 2

Testen Sie die Konfiguration mit einem Reboot, solange noch nichts verloren gehen kann. Nach dem Reboot bedeutet findmnt /srv/vault mit Ausgabe des Mounts und sudo cryptsetup status vault mit Ausgabe von active, dass crypttab und fstab übereinstimmen. Hängt der Boot und fordert ein Passwort an, ist der Pfad zur Keyfile in crypttab falsch. systemd fordert dann eine Person zur Eingabe auf, die nicht anwesend ist.

Eine Passphrase bei jedem Boot eingeben. Nichts auf dem Rechner kann das Volume selbstständig entsperren. Eine Kopie der ausgeschalteten Disk ist dadurch für Angreifer nutzlos. Der Preis dafür ist, dass Sie bei jedem Reboot benötigt werden, auch beim Reboot nach einem Kernel-Update. Markieren Sie ein Daten-Volume als noauto und entsperren Sie es über SSH, sobald der Rechner betriebsbereit ist.

vault UUID=8f14e45f-ceea-467a-9f9c-1b2c3d4e5f60 none luks,noauto

sudo cryptsetup open /dev/disk/by-uuid/8f14e45f-ceea-467a-9f9c-1b2c3d4e5f60 vault
sudo mount /srv/vault

Wenn das verschlüsselte Gerät stattdessen das Root-Dateisystem enthält, läuft sshd zu diesem Zeitpunkt noch nicht. Sie benötigen dann eine Shell innerhalb des initramfs. dropbear-initramfs stellt diese bereit.

sudo apt install -y dropbear-initramfs
sudo install -m 600 ~/.ssh/authorized_keys /etc/dropbear/initramfs/authorized_keys
sudo update-initramfs -u

Verbinden Sie sich nach einem Reboot als root und führen Sie cryptroot-unlock aus. Das initramfs verwendet einen eigenen Host-Key. Ihr Client warnt deshalb vor einem geänderten Schlüssel, sofern Sie nicht mit ssh -o HostKeyAlias=vps-initramfs root@your.server verbinden. Setzen Sie DROPBEAR_OPTIONS in /etc/dropbear/initramfs/dropbear.conf auf -p 2222, wenn diese Shell einen separaten Port verwenden soll, statt den Port des sshd des laufenden Systems zu nutzen.

In beiden Fällen bleibt eine Tatsache unverändert. Solange das Volume eingebunden ist, befindet sich der Master-Key im Speicher des Kernels. Der Speicher einer virtuellen Maschine gehört dem Hypervisor. Ein Memory-Snapshot oder ein Debugger auf Host-Ebene kann den Schlüssel daher auslesen. Eine vollständige Datenträgerverschlüsselung auf gemieteter Hardware schützt einen Datenträger, der das Rechenzentrum verlässt, sehr gut. Sie schützt einen laufenden Rechner dagegen nur eingeschränkt. Dafür benötigen Sie Hardware, die den Speicher des Gasts gegenüber dem Host verschlüsselt. Genau darum geht es bei vertraulichem Computing auf einem VPS. Voraussetzung ist Prozessorunterstützung, die Ihr Provider anbieten muss.

Layer 2: ein verschlüsseltes Dateisystem, dessen Schlüssel den Storage-Server nie erreicht

Diese Ebene beantwortet die Frage neugieriger Betreiber. Sie funktioniert aufgrund einer einzigen Anordnung: Der Chiffretext liegt auf dem Storage-VPS, der Schlüssel auf Ihrem eigenen Rechner. Der Storage-Server enthält Dateien, die er nicht lesen kann, weil die Passphrase zu keinem Zeitpunkt auf ihm gespeichert wird.

gocryptfs ist dafür das naheliegende Werkzeug. Es ist eine FUSE-Schicht (Filesystem in Userspace): ein Verzeichnis mit verschlüsselten Dateien und ein Mountpoint, an dem die Klartextansicht nur für Ihren Benutzer erscheint.

sudo apt update && sudo apt install -y gocryptfs sshfs
mkdir -p ~/cipher ~/plain
sshfs backup@storage.example.com:/srv/vault ~/cipher
gocryptfs -init ~/cipher
gocryptfs ~/cipher ~/plain

gocryptfs -init benötigt ein leeres Verzeichnis und schreibt gocryptfs.conf dort hinein. Kopieren Sie eine Datei hinein und sehen Sie sich beide Seiten an.

cp /srv/data/invoice.pdf ~/plain/
ls ~/plain
ls ~/cipher
fusermount -u ~/plain

ls ~/plain listet invoice.pdf auf. ls ~/cipher listet gocryptfs.conf, gocryptfs.diriv und eine Datei auf, deren Name eine Base64-Zeichenfolge ist. Genau das sieht der Anbieter. Nach fusermount -u ist die Klartextansicht verschwunden und nur noch das verschlüsselte Verzeichnis vorhanden.

gocryptfs.conf enthält den mit Ihrer Passphrase über scrypt verpackten Hauptschlüssel. Sichern Sie diese Datei und bewahren Sie die Passphrase getrennt davon auf. gocryptfs -info ~/cipher gibt die Parameter eines vorhandenen Verzeichnisses aus. gocryptfs -passwd ~/cipher ändert die Passphrase, ohne etwas neu zu verschlüsseln, weil die Passphrase ausschließlich den verpackten Hauptschlüssel schützt.

Beachten Sie, welche Informationen weiterhin sichtbar sind. gocryptfs verschlüsselt Dateiinhalte und Dateinamen. Die Anzahl der Dateien, die Struktur des Verzeichnisbaums, die ungefähre Größe jeder Datei und die Änderungszeiten werden jedoch nicht verborgen. Ein Betreiber, der Ihr Chiffretextverzeichnis liest, kann sehen, dass Sie letzten Dienstag viertausend Dateien hinzugefügt haben und eine davon 2 GB groß ist. Wenn dieses Muster selbst vertraulich ist, reicht diese Ebene nicht aus.

Für ein Object-Storage-Ziel oder wenn Sie überhaupt keinen FUSE-Mountpoint verwenden möchten, erledigt ein rclone-crypt-Remote dieselbe Aufgabe auf der Übertragungsebene. Es kapselt ein anderes Remote. Alles, was über diese Kapselung geschrieben wird, wird verschlüsselt, bevor es den Rechner verlässt.

sudo apt update && sudo apt install -y rclone
rclone obscure 'a-long-passphrase-you-chose'
rclone config

Das Ergebnis in ~/.config/rclone/rclone.conf sieht so aus. Die Zeile remote = macht den zweiten Abschnitt zu einer Kapselung des ersten.

[storage]
type = sftp
host = storage.example.com
user = backup
key_file = ~/.ssh/id_ed25519

[secret]
type = crypt
remote = storage:vault/rclone
filename_encryption = standard
directory_name_encryption = true
password = <first rclone obscure output>
password2 = <second rclone obscure output>

rclone sync /srv/data secret: --progress
rclone ls secret:
rclone ls storage:vault/rclone

rclone ls secret: zeigt Ihre tatsächlichen Dateinamen, weil rclone sie beim Auflisten für Sie entschlüsselt. rclone ls storage:vault/rclone liest dieselben Bytes ohne die Crypt-Kapselung und zeigt verschlüsselte Namen an. Führen Sie beide Befehle einmal aus. Der Unterschied zwischen den beiden Auflistungen ist der Nachweis, dass die Anbieter-Seite undurchsichtig ist.

Eine Warnung, die häufig übersehen wird: rclone obscure ist keine Verschlüsselung. Der Vorgang ist umkehrbar, und rclone reveal macht ihn rückgängig. Daher ist rclone.conf genauso vertraulich wie die Passphrase selbst. Setzen Sie den Modus auf 600. Legen Sie mit rclone config ein Konfigurationspasswort fest, wenn sich diese Datei an einem Ort befindet, an dem sie gelesen werden könnte. Dann fragt rclone vor der Verwendung eines Remotes nach dem Passwort oder liest es aus RCLONE_CONFIG_PASS.

Ebene 3: Verschlüsselung, bevor die Daten Ihr System verlassen

Für Backups ist dies die entscheidende Ebene. Gleichzeitig verursacht sie den geringsten Aufwand, weil die Werkzeuge die Verschlüsselung bereits übernehmen. restic und BorgBackup verschlüsseln und authentifizieren jeden Chunk auf dem System, das Ihre Dateien liest. Das Repository auf dem Storage-VPS ist bereits ab dem ersten Byte nicht lesbar. Der Storage-Server besitzt daher niemals einen Schlüssel und muss nicht als vertrauenswürdig gelten.

sudo apt update && sudo apt install -y restic
umask 077
nano ~/.restic-pass
chmod 600 ~/.restic-pass
export RESTIC_REPOSITORY=sftp:backup@storage.example.com:/srv/vault/restic
export RESTIC_PASSWORD_FILE=$HOME/.restic-pass
restic init
restic backup /srv/data

Tragen Sie eine lange Passphrase aus Ihrem Passwortmanager mit dem Editor in diese Datei ein und nicht mit echo. Dadurch gelangt sie nicht in Ihre Shell-History. Prüfen Sie anschließend die Konfiguration und sehen Sie nach, welche Informationen auf der Storage-Seite sichtbar sind.

restic snapshots
restic check
restic check --read-data-subset=5%
ssh backup@storage.example.com 'ls /srv/vault/restic'

restic snapshots listet Ihre Inhalte auf. restic check prüft die Repository-Struktur. --read-data-subset=5% lädt eine Stichprobe der tatsächlichen Daten herunter und prüft sie. Dadurch werden Storage-Systeme erkannt, die unbemerkt falsche Bytes zurückgeben. Der ls über SSH gibt die Verzeichnisse config, data, index, keys, locks und snapshots aus. Jede Datei unter data/ enthält einen Pack aus verschlüsselten Blobs. restic verfügt über keinen unverschlüsselten Modus. Der Repository-Schlüssel wird bei init erzeugt und mit Ihrer Passphrase geschützt. Jeder Pack wird mit AES-256 im Counter-Modus verschlüsselt und mit Poly1305-AES authentifiziert.

Borg erreicht dasselbe Ziel, mit einem wichtigen Unterschied.

sudo apt update && sudo apt install -y borgbackup
borg init --encryption=repokey-blake2 ssh://backup@storage.example.com/srv/vault/borg
borg create --stats ssh://backup@storage.example.com/srv/vault/borg::data-{now} /srv/data
borg list ssh://backup@storage.example.com/srv/vault/borg

Bei Borg wird die Verschlüsselung unter init als Option festgelegt. --encryption=none ist eine gültige Option. Geben Sie den Modus daher ausdrücklich an. Sie können ihn später nicht ändern, ohne ein neues Repository zu erstellen. repokey-blake2 speichert den Schlüssel im Repository und schützt ihn mit Ihrer Passphrase. Damit ist die Passphrase das einzige Geheimnis, das Sie mitführen müssen. Die Modi keyfile speichern den Schlüssel dagegen unter ~/.config/borg/keys auf dem Client. Wenn ein Client verloren geht und kein exportierter Schlüssel vorhanden ist, bleibt ein Repository zurück, das niemand lesen kann. Exportieren Sie den Schlüssel in jedem Fall und bewahren Sie ihn getrennt von beiden Systemen auf.

borg key export ssh://backup@storage.example.com/srv/vault/borg ~/borg-key.txt
borg key export --paper ssh://backup@storage.example.com/srv/vault/borg

Verschlüsselung macht eine Kopie nicht dauerhaft verfügbar. Der Anbieter kann das Repository weiterhin löschen. Das kann auch jeder tun, der Ihre Zugangsdaten stiehlt. Bewahren Sie eine zweite Kopie an einem anderen Ort auf. Schränken Sie außerdem den SSH-Schlüssel auf der Storage-Seite ein, damit ein kompromittierter Client keine Backup-Historie bereinigen kann. Zeitplanung und Aufbewahrung gehören zum Backup-Job selbst: siehe restic-Backups von einem VPS aus ausführen. Wenn der Storage-Server als Ziel für einen weiteren von Ihnen betriebenen Server dient, beschreibt einen Storage-VPS mit Ihrem Haupt-VPS koppeln die Netzwerkseite dieser Verbindung.

Benötigt die Verschlüsselung keinen AV-Vertrag nach der DSGVO?

Nein. Wenn ein Anbieter personenbezogene Daten für Sie speichert, ist er Ihr Auftragsverarbeiter. Art. 28 DSGVO verlangt eine schriftliche Vereinbarung zur Auftragsverarbeitung, den Auftragsverarbeitungsvertrag oder AV-Vertrag. Eine clientseitige Verschlüsselung ändert daran nichts. Es ist umstritten, ob Chiffretext, auf den eine Person ohne Zugriff auf den Schlüssel keinen Zugriff hat, in ihren Händen weiterhin als personenbezogene Daten gilt. Die sichere Auslegung besteht darin, die Vereinbarung als Verarbeitung zu behandeln und den Vertrag trotzdem zu unterzeichnen. Damit gehen Sie das geringere Risiko ein.

Die Verschlüsselung ändert jedoch, welche Folgen ein Verstoß für Sie hat. Art. 32 DSGVO nennt Verschlüsselung als Beispiel für eine geeignete technische Maßnahme. Sie belegt daher, dass Sie entsprechende Maßnahmen umgesetzt haben. Art. 33 verpflichtet Sie weiterhin, eine Verletzung des Schutzes personenbezogener Daten innerhalb von 72 Stunden der Aufsichtsbehörde zu melden. Art. 34(3)(a) ist der entscheidende Punkt: Sie müssen nicht jede betroffene Person benachrichtigen, wenn die Daten für Personen ohne den Schlüssel unverständlich gemacht wurden. Eine Festplatte, die mit einem geschlossenen LUKS-Volume das Rack verlässt, während der Schlüssel auf einer Maschine eines anderen Unternehmens liegt, führt zu einem völlig anderen Bericht als dieselbe Festplatte mit Klartextdaten.

Daraus ergeben sich zwei praktische Konsequenzen. Dokumentieren Sie, wer welchen Schlüssel verwaltet und wie er ausgetauscht wird. Eine Verschlüsselung, die niemand dokumentieren kann, lässt sich schwer verteidigen, wenn Sie dazu aufgefordert werden. Denken Sie außerdem daran, dass die Verschlüsselung nichts über den Speicherort aussagt: Wenn Ihre Verpflichtung lautet, dass die Daten innerhalb der EU bleiben, ist das eine Hosting-Entscheidung. EU-Datenspeicherung auf einem Storage-VPS und ihre Kosten ist eine davon getrennte Frage. Ihr Datenschutzbeauftragter klärt die Einzelheiten für Ihr Unternehmen. Der technische Teil oben ist die Grundlage, die Sie ihm geben.

Wo der Schlüssel aufbewahrt wird und wie Sie seine Funktion nachweisen

Ein Schlüssel auf dem Storage-VPS ist kein Schlüssel. Eine Passphrase im Repository, das sie schützt, ist keine Passphrase. Zwei Regeln decken den größten Teil ab: Das Geheimnis liegt auf einem Computer, den der Storage-Anbieter nicht betreibt, und eine zweite Kopie davon liegt offline auf Papier oder auf einem Gerät in einem anderen Gebäude.

Weisen Sie die Konfiguration anschließend nach, denn ein nicht getesteter Schlüssel ist nur eine Vermutung. Verwenden Sie dafür einen dritten Computer, auf dem Ihre Daten noch nie gespeichert waren. Stellen Sie ihm nur das Schlüsselmaterial und Lesezugriff auf das Repository bereit. Stellen Sie dann eine kleine Datenmenge wieder her.

export RESTIC_REPOSITORY=sftp:backup@storage.example.com:/srv/vault/restic
restic restore latest --target /tmp/restore-test --include /srv/data/invoice.pdf
sha256sum /tmp/restore-test/srv/data/invoice.pdf

Eine mit dem Original übereinstimmende Prüfsumme weist zwei Dinge nach: Der Schlüssel funktioniert, und das Repository kann von einem anderen Computer als dem, auf dem es geschrieben wurde, gelesen werden. Führen Sie diesen Test einmal pro Quartal durch und notieren Sie das Datum.

Die praktische Antwort für Backup-Daten

Bei Dateien, die Sie speichern und nicht bereitstellen, sollten Sie es einfach halten. Verschlüsseln Sie die Daten mit restic oder Borg auf der Maschine, auf der sie verwaltet werden, übertragen Sie nur das Repository auf den Storage-VPS und speichern Sie die Passphrase in einem Passwortmanager mit einer Offline-Kopie. Fügen Sie auf dem Storage-Volume zusätzlich LUKS hinzu, wenn auch der Fall eines ausgemusterten Datenträgers auf der Seite des Providers abgedeckt sein soll. Beachten Sie dabei, dass dies keinen Schutz gegen einen aktiven Betreiber bietet. Verwenden Sie gocryptfs oder ein rclone-crypt-Remote, wenn Sie statt eines Backup-Repositorys ein durchsuchbares Verzeichnis benötigen. Binden Sie es von Ihrer eigenen Maschine aus ein, damit der Schlüssel niemals auf gemieteter Hardware gespeichert wird.

Wenn Sie den Storage-Server noch nicht ausgewählt haben, beeinflusst diese Entscheidung den Rest: wie sich ein Storage-VPS von einem regulären VPS unterscheidet erklärt, warum diese Volumes günstig und langsam sind, und ob selbst gehosteter Speicher preislich wirklich besser als Dropbox ist klärt, ob sich der Eigenbetrieb überhaupt lohnt.

FAQ

Schützt mich eine vollständige Festplattenverschlüsselung auf einem VPS vor dem Hosting-Anbieter?

Nicht, solange der Server läuft. Das Volume kann nur mit dem Schlüssel entschlüsselt werden. Der Schlüssel liegt daher entweder als Keyfile auf der Maschine oder nach seiner Eingabe im Speicher des Kernels. Auf beide Bereiche hat der Host Zugriff. Ein Speicherabbild einer laufenden virtuellen Maschine enthält den Schlüssel. LUKS schützt dagegen vor dem Ausbau des Datenträgers: Ein ausgetauschtes, weiterverkauftes oder ausgemustertes Laufwerk ist nicht lesbar, weil die Maschine ausgeschaltet ist. Verwenden Sie LUKS für diesen Fall und clientseitige Verschlüsselung für den Fall eines Zugriffs durch den Anbieter.

Kann ich einen Storage-VPS verschlüsseln, der bereits vollständig mit Daten belegt ist?

Nicht direkt mit LUKS. cryptsetup luksFormat löscht die Partition. Es gibt zwei praktikable Vorgehensweisen. Binden Sie ein zweites Volume ein, verschlüsseln Sie es, kopieren Sie die Daten mit rsync -aHAX --info=progress2 und formatieren Sie anschließend das alte Volume neu. Oder lassen Sie das Dateisystem unverändert und schreiben Sie die verschlüsselten Daten mit gocryptfs oder einem rclone-crypt-Remote in ein neues Verzeichnis. Löschen Sie anschließend die Klartextdaten. Das Löschen von Klartextdaten auf einer virtuellen Festplatte garantiert nicht, dass die alten Blöcke unerreichbar sind. Die Speicherschicht des Hosts kann Snapshots oder Kopien enthalten, auf die Sie nicht zugreifen können. Behandeln Sie daher alle Daten, die dort jemals im Klartext lagen, als bereits offengelegt.

Benötige ich weiterhin einen AV-Vertrag, wenn der Anbieter ausschließlich Chiffretext sieht?

Ja. Ein Anbieter, der personenbezogene Daten für Sie speichert, ist gemäß Art. 28 DSGVO ein Auftragsverarbeiter. Dafür ist unabhängig davon, wie die Daten auf seinen Datenträgern aussehen, eine schriftliche Vereinbarung erforderlich. Die Verschlüsselung ändert die Pflichten bei einer Datenschutzverletzung, nicht den Vertrag: Art. 34(3)(a) lässt die Pflicht zur Benachrichtigung jeder betroffenen Person entfallen, wenn die Daten ohne den Schlüssel unverständlich sind. Die 72-Stunden-Meldung an die Aufsichtsbehörde gemäß Art. 33 bleibt jedoch erforderlich.

Was geschieht, wenn ich meine restic- oder Borg-Passphrase verliere?

Die Daten sind verloren. Es gibt keinen Wiederherstellungsweg und kein Support-Ticket kann helfen, weil der Repository-Schlüssel mit dieser Passphrase geschützt ist und nichts anderes ihn entschlüsseln kann. Die keyfile-Modi von Borg führen einen zweiten Verlustpunkt ein: die Key-Datei auf dem Client. Deshalb gibt es borg key export --paper. Bewahren Sie die Passphrase in einem Passwortmanager und eine Offline-Kopie auf, die nicht auf der gesicherten Maschine liegt.

Ist gocryptfs oder restic die bessere Wahl für einen Storage-VPS?

Sie lösen unterschiedliche Aufgaben. restic ist für Backups vorgesehen: versionierte Snapshots, Deduplizierung und ein Repository, aus dem Sie Daten wiederherstellen. gocryptfs ist für aktive Dateien vorgesehen, die Sie wie in einem gewöhnlichen Verzeichnis öffnen und bearbeiten möchten. Wenn Sie beides benötigen, verwenden Sie beides. Behandeln Sie ein Backup-Repository nicht als Dateifreigabe.