Backups verschluesseln richtig gemacht

1. Warum unverschluesselte Backups ein Sicherheitsrisiko sind

Ein unverschluesseltes Backup enthaelt exakt dieselben sensiblen Daten wie das Produktivsystem, oft sogar mehr, weil aeltere Datenstaende und geloeschte Datensaetze darin noch vorhanden sind. Waehrend das Produktivsystem meist durch Firewalls, Monitoring und Zugriffskontrollen abgesichert ist, wandert ein Backup haeufig auf externe Speichermedien, in Cloud-Storage oder auf Wechseldatentraeger, wo dieser Schutz nicht automatisch mitkommt. Backup-Verschluesselung schliesst genau diese Luecke.

Rechtlich verschaerft die DSGVO diese Anforderung zusaetzlich: personenbezogene Daten muessen dem Stand der Technik entsprechend geschuetzt werden, und ein gestohlenes, unverschluesseltes Backup-Medium gilt in aller Regel als meldepflichtiger Datenschutzvorfall. Ein durch Backup-Verschluesselung geschuetztes Medium hingegen bleibt selbst bei physischem Diebstahl unlesbar, sofern der Schluessel nicht ebenfalls kompromittiert wurde, was die Meldepflicht in vielen Faellen entschaerft.

2. Verschluesselung at rest versus in transit

Backup-Verschluesselung muss zwei unterschiedliche Bedrohungsszenarien gleichzeitig adressieren. Verschluesselung in transit schuetzt Daten waehrend der Uebertragung, etwa beim Hochladen zu einem Offsite-Ziel, ueblicherweise durch TLS. Verschluesselung at rest schuetzt die Daten dagegen im gespeicherten Zustand, unabhaengig davon, ob sie gerade uebertragen werden oder ruhen. Beide Ebenen sind fuer eine vollstaendige Backup-Verschluesselung notwendig, denn TLS allein schuetzt nicht vor einem gestohlenen Speichermedium, und eine verschluesselte Datei allein schuetzt nicht vor einem abgehoerten, unverschluesselten Uebertragungskanal.

Der robusteste Ansatz kombiniert clientseitige Verschluesselung, also Backup-Verschluesselung, die bereits vor dem Verlassen des Quellsystems angewendet wird, mit einer zusaetzlichen TLS-Absicherung des Transportwegs. Damit sieht selbst ein kompromittierter Zwischenserver oder ein neugieriger Cloud-Anbieter niemals unverschluesselte Daten, was clientseitige Backup-Verschluesselung gegenueber serverseitiger Verschluesselung des Speicheranbieters klar bevorzugt macht.

3. GPG-basierte Verschluesselung von Backup-Archiven

GnuPG (GPG) ist das Standardwerkzeug fuer asymmetrische Backup-Verschluesselung unter Linux. Ein Backup-Archiv wird dabei mit dem oeffentlichen Schluessel des Empfaengers verschluesselt, sodass ausschliesslich der Besitzer des zugehoerigen privaten Schluessels es wieder entschluesseln kann. Dieser Ansatz eignet sich besonders fuer automatisierte Backup-Verschluesselung, weil der oeffentliche Schluessel gefahrlos auf dem Backup-Server liegen kann, ohne dass jemand mit Zugriff auf diesen Server allein schon entschluesseln koennte.

In der Praxis wird ein tar-Archiv erzeugt und direkt in der Pipe an GPG weitergereicht, sodass niemals eine unverschluesselte Zwischendatei auf der Platte entsteht. Diese Streaming-Verschluesselung ist fuer produktive Backup-Verschluesselung wichtig, weil eine unverschluesselte Zwischendatei, und sei sie nur fuer Sekunden vorhanden, ein zusaetzliches Zeitfenster fuer einen Angreifer mit Dateisystemzugriff eroeffnet.

#!/usr/bin/env bash
# gpg-backup-encrypt.sh — asymmetric backup encryption, no plaintext temp file
set -euo pipefail

readonly SOURCE_DIR="/var/www/html"
readonly OUTPUT_FILE="/var/backup/encrypted/site-$(date +%Y%m%d).tar.gz.gpg"
readonly RECIPIENT="backup@mironsoft.de"

mkdir -p "$(dirname "$OUTPUT_FILE")"

# Stream tar directly into gpg — no unencrypted archive ever touches disk
tar -czf - -C "$SOURCE_DIR" . | \
  gpg --encrypt \
      --recipient "$RECIPIENT" \
      --trust-model always \
      --output "$OUTPUT_FILE"

echo "[OK] Encrypted backup written to $OUTPUT_FILE"

# Decryption (only possible with the matching private key):
# gpg --decrypt "$OUTPUT_FILE" | tar -xzf - -C /restore/target

4. Schluesselverwaltung: wo Private Keys sicher aufbewahren

Die staerkste Backup-Verschluesselung ist wertlos, wenn der private Schluessel unsicher aufbewahrt wird, etwa auf demselben Server, der auch die verschluesselten Backups speichert. Ein Angreifer, der Zugriff auf diesen einen Server erlangt, bekaeme dann sowohl die verschluesselten Daten als auch den Schluessel, der sie oeffnet, was die gesamte Backup-Verschluesselung wirkungslos macht. Der private Schluessel gehoert deshalb strikt getrennt von den verschluesselten Backups aufbewahrt, idealerweise auf einem separaten, besonders geschuetzten System oder in einem Hardware-Sicherheitsmodul.

Fuer kleinere Umgebungen ist ein Offline-Schluessel auf einem verschluesselten USB-Stick, der nur im tatsaechlichen Restore-Fall angeschlossen wird, eine pragmatische Loesung. Fuer groessere Setups empfiehlt sich ein dedizierter Secret-Store wie HashiCorp Vault oder ein Cloud-KMS, das den Zugriff auf den Schluessel protokolliert und nach dem Prinzip geringster Rechte beschraenkt. In jedem Fall gilt: Backup-Verschluesselung ohne dokumentierte, getestete Schluessel-Wiederherstellungsstrategie ist ein Risiko, denn ein verlorener Schluessel macht saemtliche damit verschluesselten Backups dauerhaft unbrauchbar.

; gpg-agent.conf — key handling policy for backup encryption
; Located at ~/.gnupg/gpg-agent.conf on the dedicated backup key host

; Never cache the passphrase longer than necessary for a single operation
default-cache-ttl 60
max-cache-ttl 120

; Require pinentry confirmation for every private key operation
pinentry-program /usr/bin/pinentry-curses

; Log key usage for audit purposes
log-file /var/log/gpg-agent-key-usage.log
verbose

5. OpenSSL als Alternative fuer symmetrische Verschluesselung

Fuer Faelle, in denen ein vollstaendiges GPG-Schluesselpaar-Management zu aufwendig ist, bietet openssl enc eine einfachere, symmetrische Backup-Verschluesselung mit einem einzigen gemeinsamen Passwort. AES-256 im GCM-Modus liefert dabei sowohl Vertraulichkeit als auch Integritaetsschutz, was fuer Backup-Verschluesselung wichtig ist, weil ein manipuliertes verschluesseltes Archiv sonst unbemerkt eingespielt werden koennte. Der entscheidende Nachteil gegenueber GPG: Das Passwort selbst muss sicher zwischen allen Systemen geteilt werden, die ver- oder entschluesseln muessen, was bei mehreren Beteiligten schnell zum Schwachpunkt wird.

OpenSSL-basierte Backup-Verschluesselung eignet sich deshalb vor allem fuer Einzelserver-Szenarien mit einer einzigen verantwortlichen Person, oder als schnelle Zwischenloesung, bevor eine vollstaendige GPG- oder Secret-Store-Infrastruktur aufgebaut ist. Fuer Teams mit mehreren Zugriffsberechtigten ist asymmetrische Backup-Verschluesselung mit GPG grundsaetzlich vorzuziehen, weil dort jeder Beteiligte seinen eigenen privaten Schluessel behalten kann, statt ein gemeinsames Geheimnis zu teilen.

#!/usr/bin/env bash
# openssl-backup-encrypt.sh — symmetric backup encryption with AES-256-GCM
set -euo pipefail

readonly SOURCE_DIR="/var/www/html"
readonly OUTPUT_FILE="/var/backup/encrypted/site-$(date +%Y%m%d).tar.gz.enc"
readonly PASS_FILE="/etc/backup/encryption.pass"  # chmod 600, root only

if [[ ! -f "$PASS_FILE" ]]; then
  echo "[ERROR] Passphrase file missing: $PASS_FILE" >&2
  exit 1
fi

tar -czf - -C "$SOURCE_DIR" . | \
  openssl enc -aes-256-gcm -pbkdf2 -iter 100000 \
    -pass "file:$PASS_FILE" \
    -out "$OUTPUT_FILE"

echo "[OK] Symmetrically encrypted backup written to $OUTPUT_FILE"

# Decryption:
# openssl enc -d -aes-256-gcm -pbkdf2 -iter 100000 \
#   -pass "file:$PASS_FILE" -in "$OUTPUT_FILE" | tar -xzf - -C /restore/target

6. restic und Borg: eingebaute Verschluesselung moderner Tools

Moderne Backup-Werkzeuge wie restic und Borg Backup integrieren Verschluesselung direkt in ihr Repository-Format, statt sie als nachtraeglichen Schritt ueber GPG oder OpenSSL hinzuzufuegen. Bei restic ist jedes Repository standardmaessig verschluesselt, ein Repository ohne Verschluesselung anzulegen ist gar nicht vorgesehen. Diese eingebaute Backup-Verschluesselung nutzt AES-256 kombiniert mit Poly1305-Authentifizierung und dedupliziert Daten zusaetzlich, bevor sie verschluesselt werden, was Speicherplatz spart, ohne die Sicherheit zu beeintraechtigen.

Borg Backup verfolgt einen aehnlichen Ansatz mit repokey- oder keyfile-Verschluesselungsmodi. Beim repokey-Modus wird der Verschluesselungsschluessel selbst verschluesselt im Repository gespeichert und mit einer Passphrase geschuetzt, was Backup-Verschluesselung besonders einfach macht, aber die Passphrase zum kritischen Single-Point-of-Failure erhebt. Der keyfile-Modus trennt Schluessel und Repository staerker, aehnlich der GPG-Schluesseltrennung aus Abschnitt vier, und ist fuer produktive Umgebungen mit hoeheren Sicherheitsanforderungen vorzuziehen.

#!/usr/bin/env bash
# restic-encrypted-backup.sh — built-in encryption, deduplication, and offsite target
set -euo pipefail

export RESTIC_REPOSITORY="s3:s3.eu-central-1.example-cloud.com/mironsoft-backups"
export RESTIC_PASSWORD_FILE="/etc/backup/restic.pass"  # chmod 600

# Repository is always encrypted — restic refuses to create an unencrypted one
if ! restic snapshots &>/dev/null; then
  restic init
fi

# Deduplicated, encrypted backup of the source directory
restic backup /var/www/html --tag nightly

# Verify encryption is enforced and check repository integrity
restic check

echo "[OK] Encrypted, deduplicated backup completed"

7. Verschluesselte Offsite-Uebertragung kombinieren

Backup-Verschluesselung entfaltet ihre volle Wirkung erst in Kombination mit einer Offsite-Strategie, denn genau dort verlaesst die Sicherung die physische Kontrolle des eigenen Rechenzentrums. Ein mit GPG oder restic bereits verschluesseltes Archiv kann gefahrlos per rclone zu einem Cloud-Ziel synchronisiert werden, ohne dass zusaetzliche serverseitige Verschluesselung noetig waere, weil die Daten schon vor der Uebertragung unlesbar sind. Der Cloud-Anbieter selbst bekommt so niemals unverschluesselten Zugriff auf die Inhalte.

Wichtig bleibt dabei, dass auch der Transportweg selbst per TLS abgesichert ist, denn doppelte Absicherung, Backup-Verschluesselung plus TLS, schuetzt zusaetzlich vor Metadaten-Lecks wie Dateigroessen oder Zugriffsmustern, die selbst bei verschluesseltem Inhalt Rueckschluesse zulassen koennten. Diese Kombination aus clientseitiger Backup-Verschluesselung und transportverschluesseltem Offsite-Sync ist der Goldstandard fuer Backups, die sowohl vor physischem Zugriff als auch vor Netzwerkabhoerung geschuetzt sind.

8. Performance-Overhead und Kompression vor Verschluesselung

Backup-Verschluesselung kostet CPU-Zeit, in der Praxis meist deutlich weniger als befuerchtet, weil AES auf moderner Hardware durch die AES-NI-Erweiterung nahezu ohne messbaren Overhead beschleunigt wird. Der weitaus groessere Performance-Faktor ist die Reihenfolge von Kompression und Verschluesselung: Daten muessen immer zuerst komprimiert und erst danach verschluesselt werden, niemals umgekehrt. Verschluesselte Daten sehen fuer einen Kompressionsalgorithmus wie zufaelliges Rauschen aus und lassen sich praktisch nicht mehr komprimieren, was ein bereits verschluesseltes und danach komprimiertes Archiv unnoetig aufblaeht.

Alle in diesem Artikel gezeigten Ansaetze respektieren diese Reihenfolge automatisch, tar komprimiert vor der GPG- oder OpenSSL-Verschluesselung, restic und Borg dedupliziert und komprimiert intern vor der eingebauten Backup-Verschluesselung. Wer eigene Skripte baut, sollte diese Reihenfolge explizit pruefen, denn ein vertauschter Schritt bleibt technisch funktionsfaehig, produziert aber unnoetig grosse und langsame Backups.

9. Verschluesselungsmethoden im Vergleich

Die Wahl der passenden Backup-Verschluesselung haengt von Teamgroesse, vorhandener Infrastruktur und Automatisierungsanforderungen ab.

Fuer die meisten produktiven Linux-Server-Setups ist restic oder Borg mit integrierter Backup-Verschluesselung die pragmatischste Wahl, weil Verschluesselung, Deduplikation und Kompression aus einer Hand kommen und keine separate Skript-Pipeline mit manueller Reihenfolge-Logik gepflegt werden muss. GPG bleibt relevant, wenn mehrere Personen unabhaengig voneinander entschluesseln koennen muessen sollen.

10. Zusammenfassung

Backup-Verschluesselung ist keine optionale Zusatzmassnahme, sondern eine Grundvoraussetzung, sobald eine Sicherung den eigenen Server verlaesst, sei es auf ein externes Medium oder zu einem Cloud-Ziel. GPG bietet asymmetrische Verschluesselung mit sauberer Schluesseltrennung fuer Teams, OpenSSL eine einfache symmetrische Alternative fuer Einzelserver, und moderne Tools wie restic und Borg integrieren Backup-Verschluesselung direkt in ihr Repository-Format, kombiniert mit Deduplikation.

Unabhaengig vom gewaehlten Werkzeug entscheidet die Schluesselverwaltung ueber Erfolg oder Misserfolg: Ein privater Schluessel, der getrennt vom Backup selbst aufbewahrt, dokumentiert und im Rahmen von Restore-Tests regelmaessig auf Funktionsfaehigkeit geprueft wird, macht aus Backup-Verschluesselung einen verlaesslichen Schutz statt eines zusaetzlichen Ausfallrisikos.

11. FAQ: Backups verschluesseln richtig gemacht