Die Self-Hosting-Datenschutz-Checkliste

Guides · 9 Min. Lesezeit

Kurzantwort: Eine solide Self-Hosting-Datenschutz-Checkliste deckt drei Ebenen ab: wer das Konto zu Ihnen zurückverfolgen kann, wie gut der Server selbst Angriffen standhält, und was Ihre Anwendungen im laufenden Betrieb preisgeben. In der Praxis bedeutet das: anonyme Anmeldung und Kryptozahlung, ausschließlich schlüsselbasierten SSH-Zugriff mit Firewall und fail2ban, Festplattenverschlüsselung oder verschlüsselte Volumes, minimales Logging sowie diszipliniertes Backup- und Update-Verhalten – regelmäßig überprüft, statt nur einmal bei der Einrichtung.

Warum eine Checkliste besser ist als ein einmaliges Setup

Die meisten Self-Hosting-Datenschutzfehler sind nicht dramatisch. Es sind kleine, kumulative Lücken: eine Logdatei, die still monatelang IP-Adressen aufbewahrt, ein Standard-SSH-Port, der offen blieb, weil eine Änderung unnötig erschien, ein Backup-Snapshot, der unverschlüsselt auf einem Laptop liegt, ein WHOIS-Eintrag, der noch auf einen echten Namen verweist. Keines davon wirkt für sich genommen dringend – genau deshalb überlebt es.

Eine Checkliste funktioniert, weil sie Privatsphäre als fortlaufende Eigenschaft eines Systems behandelt, nicht als einmaligen Konfigurationsschritt. Server driften. Pakete werden installiert, Ports werden für einen schnellen Test geöffnet und nie wieder geschlossen, und ein vergessener Dienst beginnt, ausführliche Logs zu schreiben. Dieselbe Liste monatlich oder nach jeder Änderung erneut durchzugehen, fängt diese Drift ab, bevor sie zur Exposition wird.

Behandeln Sie Datenschutz-Härtung als Wartung, nicht als Aufgabe am Launch-Tag
Überprüfen Sie die Liste nach jedem neuen Dienst, Paket oder jeder Konfigurationsänderung
Gehen Sie davon aus, dass Standardeinstellungen freizügig sind, bis Sie das Gegenteil verifiziert haben

Ebene eins: Wer das Konto zurückverfolgen kann

Bevor Sie überhaupt ein Terminal öffnen, ist das Konto selbst oft das schwächste Glied. Ein VPS mit Sicherheit nach militärischem Standard bleibt trotzdem rückverfolgbar, wenn die Anmeldung eine echte E-Mail, eine Kartenabrechnung oder einen ID-Scan verwendet hat. Bei dieser Ebene geht es darum, die Kette zwischen einer Zahlungsmethode und einem Server zu durchbrechen, bevor überhaupt technische Härtung beginnt.

Anonyme Anmeldeprozesse existieren genau aus diesem Grund. VPS GOAT etwa vergibt bei der Anmeldung einen einzigen gehashten Account-Schlüssel, statt eine E-Mail-Adresse oder ein Identitätsdokument zu erfassen, im selben Mullvad-Stil, den auch datenschutzorientierte VPN-Anbieter nutzen, und rechnet Zahlungen ausschließlich über Paymento in Kryptowährung ab, wobei Monero wegen seiner Privatsphäre auf Transaktionsebene neben Bitcoin, USDT, Litecoin, Ethereum und Tron empfohlen wird. Welchen Anbieter Sie auch nutzen, stellen Sie dieselben Fragen: Welche identifizierenden Daten erfasst die Anmeldung, was verrät die Zahlung, und was passiert mit diesen Daten, wenn der Anbieter zur Offenlegung gezwungen wird?

Nutzen Sie einen anonymen Account-Schlüssel oder eine pseudonyme E-Mail, niemals eine persönliche, die mit Ihrer echten Identität verknüpft ist
Bezahlen Sie mit einer datenschutzfreundlichen Kryptowährung statt einer Karte, die auf Ihren Namen läuft
Vermeiden Sie es, einen Benutzernamen, PGP-Schlüssel oder SSH-Schlüssel-Fingerabdruck über ein anonymes und ein persönliches Projekt hinweg wiederzuverwenden
Prüfen Sie, was der Anmeldeprozess des Anbieters tatsächlich speichert, bevor Sie sich anmelden, nicht danach

Ebene zwei: Wie Sie einen VPS auf Betriebssystemebene absichern

Ist das Konto sauber, folgt als nächste Ebene das Betriebssystem selbst. Einen VPS abzusichern beginnt damit, jeden Zugangspfad zu entfernen, den Sie nicht ausdrücklich benötigen, und dann die verbleibenden konsequent abzusichern. Das ist der Teil der Checkliste, der am direktesten bestimmt, ob ein opportunistischer Scanner Fuß fassen kann.

SSH ist bei fast jedem automatisierten Angriff auf einen frischen VPS das erste Ziel und verdient daher die größte Aufmerksamkeit. Deaktivieren Sie die Passwort-Authentifizierung vollständig und setzen Sie auf Schlüsselpaare, idealerweise lokal generierte Ed25519-Schlüssel, die nie irgendwohin hochgeladen werden. Verschieben Sie SSH nur als kleine Rauschreduzierung von Port 22, nicht als echte Sicherheitsmaßnahme, und kombinieren Sie es mit fail2ban oder einem ähnlichen Tool, um Brute-Force-Versuche automatisch zu drosseln.

Root-Login über SSH und Passwort-Authentifizierung deaktivieren, nur schlüsselbasierter Zugriff
Eine Firewall (ufw, nftables oder iptables) mit Standardverweigerung eingehenden Traffics und expliziten Erlaubnisregeln durchsetzen
fail2ban oder crowdsec installieren, um wiederholte fehlgeschlagene Login-Versuche automatisch zu blockieren
Sicherheitsupdates nach Zeitplan einspielen; unattended-upgrades erledigt dies unter Debian und Ubuntu automatisch
Einen Non-Root-Sudo-Nutzer für die tägliche Administration anlegen und Root Ausnahmefällen vorbehalten
Ungenutzte Dienste deaktivieren und jeden Port schließen, der nicht zu einem aktiv genutzten Dienst gehört

Ebene drei: Einen Server für Privatsphäre härten, nicht nur für Sicherheit

Sicherheit und Privatsphäre überschneiden sich, sind aber nicht identisch. Ein Server kann schwer zu knacken sein und trotzdem ein Jahr lang die IP-Adresse jedes Besuchers im Klartext protokollieren, was ein Datenschutzfehler ist, selbst wenn es kein Sicherheitsvorfall ist. Einen Server für Privatsphäre zu härten bedeutet, aktiv zu minimieren, was er zusätzlich zur üblichen Sicherheitsbasis aufzeichnet und aufbewahrt.

Festplattenverschlüsselung (LUKS unter Linux) schützt Daten im Ruhezustand, falls eine physische Festplatte je beschlagnahmt oder ein Snapshot ohne Berechtigung kopiert wird; die Pläne von VPS GOAT laufen standardmäßig auf verschlüsseltem NVMe-Speicher auf Infrastrukturebene, was die Hardware-Schicht abdeckt, aber Ihre eigene Festplattenverschlüsselung und Log-Disziplin auf Anwendungsebene bleiben weiterhin entscheidend für das, was Sie innerhalb des Gast-Betriebssystems kontrollieren. Prüfen Sie über die Verschlüsselung hinaus das Standard-Logging-Verhalten jedes Dienstes: Webserver, Mailserver und selbst der Shell-Verlauf können IP-Adressen, Zeitstempel und Abfragestrings weit länger aufbewahren als nötig.

Auch Zeitsynchronisation und DNS-Wahl spielen eine Rolle. Ein Server mit falscher Zeitzone oder ein DNS-Resolver, der jede Abfrage bis zu Ihrer Infrastruktur zurückprotokolliert, erzeugt Metadaten-Spuren, die im Alltag leicht übersehen werden, weil sie unsichtbar bleiben.

Daten im Ruhezustand mit LUKS oder gleichwertiger vollständiger Festplattenverschlüsselung innerhalb des Gast-Betriebssystems verschlüsseln
Ausführliche Zugriffslogs in nginx, Apache und Anwendungsservern kürzen oder deaktivieren, wo keine Aufbewahrung nötig ist
Logs aggressiv rotieren und ablaufen lassen (logrotate mit kurzer Aufbewahrung), statt sie unbegrenzt anzuhäufen
Einen datenschutzfreundlichen DNS-Resolver über DNS-over-TLS oder DNS-over-HTTPS statt den Standard Ihres Zugangsanbieters verwenden
Shell-Verlauf sensibler Befehle löschen und Bash-Verlauf für Automatisierungsskripte deaktivieren, die mit Geheimnissen arbeiten
NTP auf eine neutrale Zeitquelle statt eine an Ihren physischen Standort gebundene einstellen

Backups, Snapshots und die Wiederherstellungsfalle

Backups sind der Punkt, an dem Datenschutz-Härtung am häufigsten still versagt. Ein perfekt gehärteter Live-Server bedeutet wenig, wenn sein nächtlicher Snapshot unverschlüsselt in einem Storage-Bucket eines Drittanbieters liegt oder wenn die automatische Snapshot-Funktion eines Anbieters ein vollständiges Festplatten-Image irgendwo außerhalb Ihrer Kontrolle speichert.

Die Lösung besteht darin, Backup-Verschlüsselung mit derselben Ernsthaftigkeit zu behandeln wie die Live-Festplatte. Verschlüsseln Sie Backup-Archive clientseitig, bevor sie den Server verlassen, mit einem Tool wie restic oder borg und einer starken, offline gespeicherten Passphrase, sodass die Daten selbst bei kompromittiertem Backup-Ziel unlesbar bleiben. Bietet Ihr Anbieter integrierte Snapshots an, klären Sie, wo sie gespeichert werden und ob sie dieselbe Verschlüsselung wie das Quell-Volume erben.

Backups clientseitig vor dem Upload verschlüsseln, nicht erst am Speicherziel
Wiederherstellungen regelmäßig testen; ein ungetestetes Backup ist eine Hoffnung, kein Plan
Prüfen, ob vom Anbieter verwaltete Snapshots verschlüsselt sind und wo sie physisch gespeichert werden
Mindestens eine Backup-Kopie außerhalb der Gerichtsbarkeit des Live-Servers aufbewahren

Lecks auf Anwendungsebene, die Sie zuletzt prüfen sollten

Sind Konto, Betriebssystem und Backups abgedeckt, ist die letzte Ebene die Anwendungen, die Sie tatsächlich betreiben. Hier wird Datenschutz-Härtung anwendungsspezifisch: Ein selbstgehosteter E-Mail-Server, ein statischer Blog und ein Tor-Hidden-Service haben jeweils unterschiedliche Leck-Flächen, doch ein paar Prüfungen gelten fast universell.

Metadaten sind das häufigste Versäumnis. Hochgeladene Dateien können EXIF-Daten, Dokument-Autorenfelder oder zeitzonenverratende Zeitstempel enthalten. Webanwendungen können Server-Header, Softwareversionen oder ausführliche Fehlerseiten preisgeben, die einem Angreifer eine Blaupause liefern. Nichts davon ist exotisch zu beheben, aber jeder Punkt muss explizit geprüft werden, da Standardeinstellungen ihn selten für Sie verbergen.

EXIF-Daten und Metadaten aus Dateien oder Bildern entfernen, bevor Sie sie veröffentlichen
Ausführliche Server-Header (Server, X-Powered-By) unterdrücken und detaillierte Fehlerseiten in der Produktion deaktivieren
Kontaktformulare oder Kommentarsysteme auf ungewollt aktiviertes IP-Logging überprüfen
Bei einem Tor-Hidden-Service parallel zu einer Clearnet-Seite sicherstellen, dass beide keine identifizierenden Assets wie TLS-Zertifikate oder Analytics-Skripte teilen

Self-Hosting-Datenschutz-Checkliste nach Ebene
Ebene	Was zu prüfen ist	Gängiges Tool oder Einstellung
Konto	Anmeldeidentität, Zahlungsspur	Anonymer Account-Schlüssel, Monero via Paymento
Zugriff	SSH-Exposition, Brute-Force-Risiko	Nur schlüsselbasiertes SSH, fail2ban, Firewall mit Standardverweigerung
Speicher	Daten im Ruhezustand bei kopierter Festplatte oder kopiertem Snapshot	LUKS-Festplattenverschlüsselung, verschlüsseltes NVMe
Logs	Aufbewahrung von IPs und Zeitstempeln	logrotate mit kurzer Aufbewahrung, minimale Zugriffslogs
Backups	Exposition bei kompromittiertem Backup-Ziel	Clientseitige Verschlüsselung mit restic oder borg
Anwendungen	Metadaten- und Header-Lecks	EXIF-Bereinigung, unterdrückte Server-Header

FAQ

Was ist der wichtigste einzelne Schritt, um einen VPS für Privatsphäre abzusichern?+

Ausschließlich schlüsselbasierter SSH-Zugriff kombiniert mit einer Firewall mit Standardverweigerung stoppt die überwiegende Mehrheit automatisierter Angriffe auf einen frischen Server und ist daher meist der wirkungsvollste erste Schritt. Anonyme Anmeldung ist genauso wichtig, geschieht aber schon, bevor der Server überhaupt existiert, sodass sich beide im Grunde den ersten Platz teilen.

Ist Festplattenverschlüsselung nötig, wenn der Anbieter den Speicher bereits verschlüsselt?+

Anbieterseitige Verschlüsselung, wie verschlüsseltes NVMe bei VPS GOAT, schützt die physische Hardware-Ebene, doch Verschlüsselung auf Gast-Ebene (LUKS) schützt Daten, falls jemand Zugriff innerhalb des Betriebssystems erlangt oder einen Snapshot kopiert. Beides einzusetzen ist nicht redundant; sie decken unterschiedliche Bedrohungsszenarien ab.

Wie oft sollte ich eine Self-Hosting-Datenschutz-Checkliste durchgehen?+

Überprüfen Sie sie nach jeder relevanten Änderung, etwa der Installation eines neuen Dienstes oder dem Öffnen eines Ports, und führen Sie unabhängig davon mindestens monatlich einen vollständigen Durchgang durch. Konfigurations-Drift geschieht schleichend, weshalb seltene Überprüfung der Hauptgrund ist, warum kleine Lücken unbemerkt bleiben.

Verlangsamt die Härtung eines Servers für Privatsphäre die Leistung?+

Die meisten hier genannten Schritte, wie ausschließlich schlüsselbasiertes SSH, Firewall-Regeln und Log-Rotation, haben vernachlässigbare Leistungsauswirkungen. Festplattenverschlüsselung bringt einen kleinen CPU-Overhead mit sich, ist aber auf moderner Hardware mit AES-NI-Beschleunigung bei typischen Self-Hosting-Workloads selten spürbar.

Kann ich diese Checkliste bei jedem VPS-Anbieter befolgen, oder nur bei einem datenschutzorientierten?+

Die Härtungsschritte auf Betriebssystem- und Anwendungsebene gelten für jeden VPS, unabhängig vom Anbieter. Die Schritte auf Kontoebene, etwa anonyme Anmeldung und reine Kryptozahlung, hängen davon ab, ob der Anbieter sie unterstützt – genau hier unterscheidet sich ein datenschutzorientierter Host wie VPS GOAT von einem gewöhnlichen, der von vornherein ID und Kartendaten verlangt.

Bereit für Offshore?

Kein KYC, keine E-Mail – nur ein anonymer Schlüssel und Krypto. Bereitgestellt in ~55 Sekunden.

VPS konfigurieren →