Selbsthosting bietet viele Vorteile: Die eigenen Daten bleiben unter der eigenen Kontrolle, Dienste können individuell angepasst werden und man ist weniger von großen Plattformanbietern abhängig. Gleichzeitig übernimmt man jedoch auch die Verantwortung für die Sicherheit der gesamten Infrastruktur.

Ein falsch konfigurierter Docker-Container, ein veralteter Dienst oder ein ungeschützter Administrationszugang kann ausreichen, um Angreifern Zugriff auf das eigene Netzwerk oder persönliche Daten zu ermöglichen. Sicherheit sollte deshalb nicht erst nach der Installation berücksichtigt werden, sondern von Anfang an Teil der Planung sein.

In diesem Beitrag erfahren Sie, welche Sicherheitsmaßnahmen beim Selbsthosten besonders wichtig sind, welche typischen Fehler vermieden werden sollten und welche Werkzeuge Sie beim Schutz Ihrer Dienste unterstützen können.

Warum Sicherheitsaspekte beim Selbsthosten wichtig sind

Wer einen Dienst aus dem Internet erreichbar macht, betreibt im Grunde einen kleinen öffentlichen Server. Dabei spielt es keine Rolle, ob es sich um eine große Unternehmensanwendung oder lediglich um eine private Nextcloud-, WordPress- oder Vaultwarden-Instanz handelt.

Automatisierte Bots durchsuchen das Internet permanent nach offenen Ports, bekannten Sicherheitslücken und falsch konfigurierten Diensten. Ein neuer Server kann bereits wenige Minuten nach seiner Inbetriebnahme erste Anmeldeversuche oder automatisierte Angriffe verzeichnen.

Zu den häufigsten Risiken beim Selbsthosten gehören:

• veraltete Anwendungen und Container-Images
• schwache oder mehrfach verwendete Passwörter
• öffentlich erreichbare Administrationsoberflächen
• falsch konfigurierte Netzwerkfreigaben
• ungeschützte Datenbanken
• gestohlene Zugangsdaten oder API-Tokens
• zu weitreichende Container-Berechtigungen
• fehlende oder ungetestete Backups
• fehlerhafte Reverse-Proxy-Konfigurationen
• unzureichende Protokollierung und Überwachung

Besonders kritisch ist, dass ein erfolgreicher Angriff oft nicht nur einen einzelnen Dienst betrifft. Wird beispielsweise ein Container übernommen, kann ein Angreifer unter ungünstigen Umständen auf andere Container, gemeinsam verwendete Volumes oder sogar auf das Hostsystem zugreifen.

Sicherheit beim Selbsthosten sollte daher immer nach dem Prinzip der mehreren Schutzschichten aufgebaut werden. Versagt eine einzelne Maßnahme, sollen weitere Sicherheitsmechanismen den Angriff erkennen oder begrenzen.

Dieses Konzept wird häufig als Defense in Depth bezeichnet.

Tipps für sichere Konfigurationen

Betriebssystem und Anwendungen aktuell halten

Sicherheitsupdates gehören zu den wichtigsten Schutzmaßnahmen überhaupt. Bekannte Schwachstellen werden häufig bereits kurz nach ihrer Veröffentlichung automatisiert ausgenutzt.

Aktualisieren Sie deshalb regelmäßig:

• das Betriebssystem
• Docker und Docker Compose
• Container-Images
• Reverse Proxys
• Content-Management-Systeme
• Plugins und Erweiterungen
• Datenbanken
• Sicherheitssoftware

Bei Docker-Containern sollten Updates jedoch nicht vollkommen ungeprüft erfolgen. Insbesondere bei produktiven Systemen empfiehlt es sich, vor größeren Versionswechseln die Release Notes zu lesen und ein aktuelles Backup anzulegen.

Statt ausschließlich den Tag latest zu verwenden, kann es sinnvoll sein, eine bestimmte Haupt- oder Nebenversion festzulegen:

services:
  traefik:
    image: traefik:v3.7

Dadurch lässt sich besser kontrollieren, wann ein größerer Versionswechsel durchgeführt wird.

Nur notwendige Dienste veröffentlichen

Nicht jeder Container benötigt einen öffentlich erreichbaren Port. Datenbanken, Redis-Server oder interne APIs sollten normalerweise ausschließlich über interne Docker-Netzwerke erreichbar sein.

Eine Datenbank muss beispielsweise nicht über den Host veröffentlicht werden:

services:
  database:
    image: postgres:18
    networks:
      - internal

Eine unnötige Portfreigabe wie die folgende sollte vermieden werden:

ports:
  - "5432:5432"

Je weniger Dienste öffentlich erreichbar sind, desto kleiner ist die Angriffsfläche.

Einen Reverse Proxy verwenden

Ein Reverse Proxy wie Traefik, Caddy oder Nginx Proxy Manager kann den zentralen Zugriff auf mehrere Dienste verwalten.

Zu den Vorteilen gehören:

• zentrale TLS-Zertifikate
• automatische HTTPS-Weiterleitungen
• Sicherheitsheader
• Zugriffsbeschränkungen
• zentrale Authentifizierung
• Rate Limits
• Protokollierung
• Integration von Web Application Firewalls

Alle öffentlich erreichbaren Dienste sollten nach Möglichkeit ausschließlich per HTTPS angeboten werden. Ungeschützte HTTP-Verbindungen können Zugangsdaten und andere sensible Informationen offenlegen.

Administrationsoberflächen besonders schützen

Administrationsbereiche sollten nicht ohne zusätzliche Schutzmaßnahmen öffentlich erreichbar sein.

Mögliche Schutzmechanismen sind:

• Zugriff nur aus dem lokalen Netzwerk
• Zugriff ausschließlich über VPN
• zusätzliche Authentifizierung über Authentik oder Authelia
• Multi-Faktor-Authentifizierung
• IP-Whitelist
• Cloudflare Access oder vergleichbare Zero-Trust-Lösungen

Besonders sensible Dienste wie das Traefik-Dashboard, Portainer oder Datenbankverwaltungen sollten im Idealfall überhaupt nicht direkt aus dem Internet erreichbar sein.

Starke Authentifizierung einsetzen

Für jeden Dienst sollte ein eigenes, starkes Passwort verwendet werden. Ein Passwortmanager wie Vaultwarden, Bitwarden oder KeePassXC erleichtert die sichere Verwaltung.

Wo immer möglich, sollte zusätzlich Multi-Faktor-Authentifizierung aktiviert werden. Besonders empfehlenswert sind:

• Passkeys
• WebAuthn
• Hardware-Sicherheitsschlüssel
• TOTP-Einmalcodes

SMS-Codes sind besser als gar keine zweite Sicherheitsstufe, gelten jedoch als weniger robust als WebAuthn oder Passkeys.

Besonders wichtig ist Multi-Faktor-Authentifizierung für:

• den Serveranbieter
• die Domainverwaltung
• den DNS-Anbieter
• GitHub oder GitLab
• Cloudflare
• E-Mail-Konten
• Administrationskonten
• Backup-Speicher

Wird eines dieser zentralen Konten übernommen, können Angreifer unter Umständen die gesamte Infrastruktur manipulieren.

Secrets nicht im Repository speichern

Passwörter, API-Schlüssel und Tokens gehören nicht direkt in eine docker-compose.yml oder in ein öffentliches Git-Repository.

Stattdessen können Umgebungsvariablen verwendet werden:

services:
  app:
    environment:
      DATABASE_PASSWORD: ${DATABASE_PASSWORD}

Die eigentlichen Werte werden in einer separaten .env-Datei gespeichert:

DATABASE_PASSWORD=ein-sehr-langes-zufaelliges-passwort

Die .env-Datei sollte über .gitignore vom Repository ausgeschlossen werden:

.env
*.env
data/
secrets/

Noch sicherer ist die Verwendung von Docker Secrets oder einer zentralen Secret-Verwaltung.

Container mit möglichst wenigen Rechten betreiben

Container sollten nur die Rechte erhalten, die sie tatsächlich benötigen.

Hilfreiche Maßnahmen sind:

• Container nicht als Root ausführen
• unnötige Linux-Capabilities entfernen
• Dateisysteme schreibgeschützt einbinden
• no-new-privileges aktivieren
• keine privilegierten Container verwenden
• den Docker-Socket nicht unnötig einbinden

Ein Beispiel für zusätzliche Einschränkungen:

services:
  app:
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    read_only: true

Nicht jede Anwendung funktioniert sofort mit allen Einschränkungen. Die Optionen sollten daher einzeln getestet und an den jeweiligen Container angepasst werden.

Den Docker-Socket schützen

Der Docker-Socket unter /var/run/docker.sock ermöglicht weitreichende Kontrolle über den Docker-Daemon. Ein Container mit Zugriff auf diesen Socket kann unter Umständen neue privilegierte Container starten, Dateien des Hosts einbinden oder auf sensible Informationen zugreifen.

Eine direkte Einbindung sollte daher nur erfolgen, wenn sie unbedingt erforderlich ist:

volumes:
  - /var/run/docker.sock:/var/run/docker.sock

Als sicherere Alternative kann ein Docker-Socket-Proxy eingesetzt werden. Dieser erlaubt es, den Zugriff auf bestimmte API-Funktionen zu begrenzen.

Auch ein nur lesend eingebundener Docker-Socket ist nicht automatisch ungefährlich. Die Docker-API kann trotz :ro weiterhin sensible Informationen bereitstellen.

Firewall richtig konfigurieren

Eine Host-Firewall wie UFW oder nftables sollte standardmäßig alle eingehenden Verbindungen blockieren und nur notwendige Ports erlauben.

Typischerweise werden lediglich folgende Ports benötigt:

• Port 22 für SSH
• Port 80 für HTTP
• Port 443 für HTTPS

SSH sollte nach Möglichkeit zusätzlich eingeschränkt werden, beispielsweise auf:

• eine feste IP-Adresse
• ein VPN-Netzwerk
• das lokale Netzwerk
• einen administrativen Jump Host

Wichtig: Docker kann eigene Firewall-Regeln erstellen und dadurch bestimmte UFW-Regeln umgehen. Deshalb sollte nach der Einrichtung geprüft werden, welche Ports tatsächlich von außen erreichbar sind.

SSH absichern

Für den Serverzugriff sollten SSH-Schlüssel anstelle von Passwörtern verwendet werden.

Nach erfolgreicher Einrichtung der Schlüsselanmeldung kann die Passwortanmeldung deaktiviert werden:

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

Zusätzlich können folgende Maßnahmen sinnvoll sein:

• SSH-Zugriff nur über VPN
• Rate Limiting
• Fail2ban oder CrowdSec
• getrennte Benutzerkonten
• keine direkte Root-Anmeldung
• Hardware-gestützte SSH-Schlüssel

Das Ändern des SSH-Ports kann automatisierte Logeinträge reduzieren, ersetzt aber keine echte Sicherheitsmaßnahme.

Sicherheitsheader verwenden

HTTP-Sicherheitsheader können bestimmte Angriffe erschweren und das Verhalten des Browsers einschränken.

Zu den wichtigsten Headern gehören:

• Strict-Transport-Security
• X-Content-Type-Options
• Content-Security-Policy
• Referrer-Policy
• Permissions-Policy
• X-Frame-Options

Ein Beispiel für Traefik:

http:
  middlewares:
    security-headers:
      headers:
        contentTypeNosniff: true
        frameDeny: true
        referrerPolicy: "same-origin"
        stsSeconds: 63072000
        stsIncludeSubdomains: true

Eine Content Security Policy sollte vorsichtig eingeführt und zunächst im Report-Only-Modus getestet werden. Eine zu strenge Konfiguration kann Funktionen einer Webseite blockieren.

Netzwerkbereiche voneinander trennen

Nicht alle Dienste sollten sich im selben Docker-Netzwerk befinden. Eine sinnvolle Trennung erschwert es einem kompromittierten Container, direkt auf andere Komponenten zuzugreifen.

Ein typisches Konzept könnte so aussehen:

• öffentliches Proxy-Netzwerk
• internes Anwendungsnetzwerk
• separates Datenbanknetzwerk
• Monitoring-Netzwerk
• Verwaltungsnetzwerk

Nur Container, die miteinander kommunizieren müssen, sollten ein gemeinsames Netzwerk verwenden.

Auch im Heimnetz können VLANs oder getrennte Netzwerksegmente sinnvoll sein. Server, IoT-Geräte, Arbeitsgeräte und Gäste sollten möglichst nicht uneingeschränkt miteinander kommunizieren können.

Rate Limits und Angriffserkennung aktivieren

Rate Limits begrenzen die Anzahl der Anfragen innerhalb eines bestimmten Zeitraums. Dadurch lassen sich einfache Brute-Force-Angriffe und manche Überlastungsversuche abschwächen.

Zusätzlich können Lösungen wie CrowdSec verdächtige Zugriffe erkennen und blockieren. CrowdSec analysiert Protokolldateien und kann beispielsweise reagieren auf:

• wiederholte fehlgeschlagene Anmeldungen
• bekannte Angriffsmuster
• aggressive Webscanner
• verdächtige Bots
• Zugriffe auf sensible Dateien
• bekannte schädliche IP-Adressen

Eine Web Application Firewall kann darüber hinaus typische Angriffe auf Webanwendungen erkennen, beispielsweise:

• SQL-Injection
• Cross-Site-Scripting
• Path Traversal
• Local File Inclusion
• Command Injection

Solche Systeme sind jedoch kein Ersatz für Updates und sichere Konfigurationen. Sie bilden lediglich eine zusätzliche Schutzschicht.

Backups nach der 3-2-1-Regel erstellen

Ein Backup ist nicht nur bei Hardwaredefekten wichtig. Es schützt ebenfalls vor:

• Ransomware
• fehlerhaften Updates
• versehentlichem Löschen
• beschädigten Datenbanken
• kompromittierten Servern
• Fehlkonfigurationen

Die 3-2-1-Regel empfiehlt:

• drei Kopien der Daten
• auf zwei unterschiedlichen Speichermedien
• davon eine Kopie an einem anderen Standort

Ein mögliches Konzept wäre:

1. Produktivdaten auf dem Server
2. lokales Backup auf einem NAS
3. verschlüsseltes externes Backup bei einem anderen Anbieter oder Standort

Backups sollten versioniert, verschlüsselt und regelmäßig automatisch erstellt werden.

Entscheidend ist jedoch nicht nur die Erstellung. Ein Backup ist erst dann verlässlich, wenn die Wiederherstellung erfolgreich getestet wurde.

Protokolle und Monitoring einrichten

Ohne Protokollierung bleibt ein Angriff möglicherweise lange unbemerkt.

Überwacht werden sollten unter anderem:

• fehlgeschlagene Anmeldungen
• ungewöhnliche HTTP-Anfragen
• Container-Neustarts
• hohe CPU- oder Speicherauslastung
• ungewöhnlicher Netzwerkverkehr
• fehlgeschlagene Backups
• ablaufende Zertifikate
• voller Speicherplatz
• nicht erreichbare Dienste

Mögliche Werkzeuge sind:

• Grafana
• Prometheus
• Loki
• Promtail oder Grafana Alloy
• Uptime Kuma
• Netdata
• GoAccess
• CrowdSec
• systemd-journal
• Docker-Logs

Warnmeldungen sollten über E-Mail, einen Messenger oder ein zentrales Benachrichtigungssystem versendet werden.

Häufige Fehler und wie man sie vermeidet

Alle Container-Ports veröffentlichen

Ein häufiger Fehler besteht darin, für jeden Container einen Host-Port zu definieren. Dadurch werden interne Dienste möglicherweise unbeabsichtigt aus dem Internet erreichbar.

Veröffentlichen Sie nur Ports, die wirklich benötigt werden. Dienste hinter einem Reverse Proxy benötigen normalerweise keine direkte Portfreigabe.

Standardpasswörter verwenden

Standardzugangsdaten werden von automatisierten Angreifern systematisch ausprobiert.

Ändern Sie Standardpasswörter unmittelbar nach der Installation und deaktivieren Sie nicht benötigte Standardkonten.

Administrationsbereiche offen zugänglich lassen

Ein Loginformular allein ist keine ausreichende Absicherung. Administrationsoberflächen sollten zusätzlich durch VPN, IP-Filter, zentrale Authentifizierung oder Multi-Faktor-Authentifizierung geschützt werden.

Updates dauerhaft verschieben

Viele Angriffe nutzen Schwachstellen aus, für die bereits Updates verfügbar sind. Ein Dienst sollte deshalb nicht über Monate oder Jahre unverändert betrieben werden.

Richten Sie einen festen Wartungszeitraum ein und abonnieren Sie Sicherheitsmeldungen der verwendeten Projekte.

Den Root-Benutzer für alles verwenden

Wer sämtliche Arbeiten als Root ausführt, erhöht die möglichen Auswirkungen eines Fehlers oder Angriffs.

Verwenden Sie einen normalen Benutzer mit gezielt vergebenen sudo-Rechten und führen Sie Container nach Möglichkeit ebenfalls ohne Root-Berechtigungen aus.

Ungeprüfte Images verwenden

Nicht jedes Container-Image aus einer öffentlichen Registry ist vertrauenswürdig.

Bevorzugen Sie:

• offizielle Images
• Images des jeweiligen Projekts
• bekannte und dokumentierte Maintainer
• regelmäßig aktualisierte Images
• signierte oder nachvollziehbar gebaute Images

Prüfen Sie außerdem, ob das Image noch gepflegt wird und ob bekannte Sicherheitslücken vorhanden sind.

Sensible Dateien öffentlich bereitstellen

Dateien wie .env, .git/config, Backups, Datenbankexporte oder Konfigurationsdateien dürfen nicht über den Webserver erreichbar sein.

Prüfen Sie insbesondere folgende Pfade:

/.env
/.git/
/backup/
/config/
/docker-compose.yml
/database.sql

Solche Dateien sollten außerhalb des Webroots gespeichert und zusätzlich durch den Reverse Proxy oder die Webserver-Konfiguration blockiert werden.

Ausschließlich auf einen Cloud-Proxy vertrauen

Ein vorgeschalteter Proxy wie Cloudflare kann viele Angriffe filtern und die öffentliche IP-Adresse des Servers verbergen. Der Schutz ist jedoch wirkungslos, wenn der Ursprungsserver weiterhin direkt erreichbar ist.

Die Firewall des Servers oder Providers sollte daher nur Verbindungen von den Proxy-Netzwerken zulassen. Administrationszugänge und SSH sollten separat behandelt werden.

Auch eine eventuell früher öffentlich bekannte Server-IP sollte als kompromittiert beziehungsweise weiterhin auffindbar betrachtet werden.

Keine Wiederherstellungstests durchführen

Ein erfolgreich angelegtes Backup bedeutet nicht automatisch, dass es verwendbar ist.

Typische Probleme sind:

• unvollständige Daten
• fehlende Datenbank-Dumps
• beschädigte Archive
• falsche Dateirechte
• verlorene Verschlüsselungsschlüssel
• nicht dokumentierte Wiederherstellungsschritte

Führen Sie deshalb regelmäßig eine testweise Wiederherstellung in einer separaten Umgebung durch.

Sicherheitsmaßnahmen nicht testen

Eine Firewall, ein Intrusion-Prevention-System oder eine Web Application Firewall kann falsch konfiguriert sein.

Testen Sie kontrolliert:

• ob nicht benötigte Ports geschlossen sind
• ob Administrationsbereiche tatsächlich geschützt sind
• ob Angriffe erkannt werden
• ob die echte Client-IP in den Logs erscheint
• ob Benachrichtigungen zugestellt werden
• ob Sperrregeln funktionieren
• ob legitime Anfragen weiterhin möglich sind

Tests sollten ausschließlich gegen eigene Systeme oder mit ausdrücklicher Erlaubnis durchgeführt werden.

Zusätzliche Sicherheitsressourcen und Tools

CrowdSec

CrowdSec analysiert Protokolldateien und erkennt verdächtige Verhaltensmuster. Über sogenannte Bouncer oder Reverse-Proxy-Plugins können erkannte Angreifer automatisch blockiert werden.

CrowdSec eignet sich besonders für:

• SSH
• Traefik
• Nginx
• Apache
• WordPress
• Nextcloud
• allgemeine Webanwendungen

Fail2ban

Fail2ban überwacht Logdateien und sperrt IP-Adressen nach wiederholten fehlgeschlagenen Anmeldeversuchen.

Es ist einfach einzurichten und eignet sich besonders für SSH oder klassische Serverdienste. Bei größeren oder verteilten Infrastrukturen bietet CrowdSec häufig umfangreichere Möglichkeiten.

Trivy

Trivy scannt Container-Images, Dateisysteme und Konfigurationsdateien auf bekannte Schwachstellen und Fehlkonfigurationen.

Ein einfacher Image-Scan kann beispielsweise folgendermaßen durchgeführt werden:

trivy image nginx:latest

Trivy kann außerdem in CI/CD-Pipelines integriert werden, sodass unsichere Images bereits vor der Bereitstellung erkannt werden.

Docker Bench for Security

Docker Bench for Security überprüft einen Docker-Host anhand etablierter Sicherheitsempfehlungen.

Das Werkzeug untersucht unter anderem:

• Docker-Daemon-Konfiguration
• Dateiberechtigungen
• Container-Rechte
• Netzwerkoptionen
• Logging
• Sicherheitsprofile

Die Ergebnisse sollten nicht ungeprüft übernommen werden, bieten jedoch eine gute Grundlage für ein Sicherheits-Audit.

Lynis

Lynis ist ein Audit- und Hardening-Werkzeug für Linux-Systeme. Es analysiert das Betriebssystem und gibt Empfehlungen zu:

• Benutzerkonten
• SSH
• Firewall
• Kernel-Einstellungen
• Dateiberechtigungen
• Logging
• installierter Software

Ein Audit wird typischerweise mit folgendem Befehl gestartet:

sudo lynis audit system

UFW und nftables

UFW bietet eine vergleichsweise einfache Oberfläche für die Linux-Firewall. nftables ermöglicht eine wesentlich feinere und umfangreichere Steuerung.

Unabhängig vom verwendeten Werkzeug sollte regelmäßig von einem externen System geprüft werden, welche Ports tatsächlich erreichbar sind.

OpenSCAP und CIS Benchmarks

CIS Benchmarks enthalten konkrete Empfehlungen zur Absicherung von Betriebssystemen, Docker, Kubernetes und weiteren Plattformen.

OpenSCAP kann Systeme automatisiert gegen bestimmte Sicherheitsprofile prüfen. Solche Werkzeuge sind besonders interessant, wenn eine Umgebung nach nachvollziehbaren und dokumentierten Standards gehärtet werden soll.

Security-Header-Tests

Online-Prüfwerkzeuge können untersuchen, ob eine Webseite wichtige Sicherheitsheader verwendet und wie gut die TLS-Konfiguration umgesetzt wurde.

Die Ergebnisse sollten als Orientierung betrachtet werden. Nicht jede pauschale Empfehlung passt zu jeder Anwendung.

Passwortmanager und Passkeys

Ein Passwortmanager gehört zu den wichtigsten Werkzeugen für sichere Selfhosting-Projekte.

Geeignete Lösungen sind unter anderem:

• Bitwarden
• Vaultwarden
• KeePassXC
• 1Password
• Proton Pass

Passkeys und WebAuthn bieten zusätzlichen Schutz gegen Phishing und sollten überall aktiviert werden, wo sie unterstützt werden.

Uptime- und Infrastruktur-Monitoring

Ein Monitoring-System kann nicht jeden Angriff verhindern, hilft aber dabei, Probleme frühzeitig zu erkennen.

Nützliche Werkzeuge sind:

• Uptime Kuma für Erreichbarkeitsprüfungen
• Prometheus für Metriken
• Grafana für Dashboards
• Loki für Logauswertung
• Alertmanager für Benachrichtigungen
• Blackbox Exporter für externe Prüfungen

Sicherheitsmeldungen abonnieren

Für alle zentralen Komponenten sollten Sicherheitsmeldungen und Release Notes verfolgt werden.

Besonders wichtig sind Hinweise zu:

• kritischen Sicherheitslücken
• nicht mehr unterstützten Versionen
• Breaking Changes
• zurückgezogenen Releases
• dringenden Konfigurationsänderungen
• kompromittierten Images oder Abhängigkeiten

Bei GitHub-Projekten können Releases und Security Advisories häufig direkt abonniert werden.

Fazit

Sicheres Selbsthosting besteht nicht aus einer einzelnen Einstellung oder einem bestimmten Sicherheitswerkzeug. Entscheidend ist das Zusammenspiel mehrerer Schutzschichten.

Ein solides Sicherheitskonzept umfasst mindestens:

• regelmäßige Updates
• möglichst wenige öffentlich erreichbare Dienste
• starke Authentifizierung mit MFA oder Passkeys
• eine restriktive Firewall
• HTTPS über einen Reverse Proxy
• voneinander getrennte Netzwerke
• eingeschränkte Container-Berechtigungen
• eine sichere Secret-Verwaltung
• zentrale Protokollierung und Überwachung
• getestete und externe Backups

Ebenso wichtig ist es, die eigene Konfiguration regelmäßig zu überprüfen. Eine heute sichere Umgebung kann durch neue Sicherheitslücken, veränderte Anforderungen oder fehlerhafte Updates morgen bereits neue Risiken enthalten.

Selfhosting bedeutet Freiheit und Kontrolle – aber auch Verantwortung. Wer Sicherheitsmaßnahmen von Anfang an einplant, seine Systeme aktuell hält und Wiederherstellungsprozesse regelmäßig testet, kann private Dienste zuverlässig und langfristig betreiben.