Self-Hosted ISMS mit Docker: Setup, Backup und Wartung in der Praxis

Warum Self-Hosted? Weil dein Risikoregister nicht in fremde Hände gehört

Du hast dich entschieden, dein ISMS auf eigener Infrastruktur zu betreiben. Vielleicht wegen der Datensouveränität, vielleicht weil du im Audit klare Antworten auf die Frage geben willst, wo deine Risikobewertungen, Vorfallsdokumentationen und Notfallpläne liegen. In diesem Artikel zeige ich dir, wie das mit ISMS Lite konkret aussieht: vom Installer-Script über die Docker-Architektur bis zum ersten Backup.

ISMS Lite ist eine SvelteKit-2-Anwendung mit Node.js 24 und PostgreSQL 18 als Datenbank. Die gesamte Installation läuft über Docker Compose und einen vorgelagerten Reverse Proxy. Falls du mit Docker noch nicht gearbeitet hast: Docker packt eine Anwendung mit allen Abhängigkeiten in einen Container, der sich wie eine leichtgewichtige VM verhält. Docker Compose orchestriert mehrere Container, die zusammenarbeiten. Du brauchst dafür kein Kubernetes und kein DevOps-Team.

Die Architektur: Zwei Container, ein Reverse Proxy

Anders als viele Docker-Setups, die drei oder mehr Container mitbringen, ist ISMS Lite auf zwei Container reduziert. Der Reverse Proxy läuft direkt auf dem Host, nicht im Container. Das hat einen guten Grund: Caddy als Host-Dienst verwaltet die SSL-Zertifikate zentral für alle Dienste auf dem Server, nicht nur für ISMS Lite.

Container 1: Die Anwendung (app)

Der App-Container basiert auf node:24-slim und startet die SvelteKit-Anwendung mit node build/index.js. Er lauscht auf Port 3000, aber ausschließlich auf 127.0.0.1. Das heißt: Kein direkter Zugriff aus dem Internet. Alle Anfragen laufen über den Reverse Proxy.

Das App-Volume ist read-only gemountet. Die Anwendung schreibt nicht in ihr eigenes Verzeichnis. Uploads landen in einem separaten Volume unter ./data/uploads/ mit Schreibzugriff. Diese Trennung minimiert die Angriffsfläche: Selbst wenn jemand eine Schwachstelle in der App ausnutzt, kann er den Anwendungscode nicht manipulieren.

Container 2: Die Datenbank (db)

PostgreSQL 18 auf Alpine-Basis. Der Datenbankport ist bewusst auf 5433 gesetzt, nicht auf den Standard-Port 5432. Das vermeidet Konflikte mit einer eventuell vorhandenen lokalen PostgreSQL-Installation. Auch dieser Port bindet nur auf 127.0.0.1.

Die Datenbankdaten liegen persistent unter ./data/postgres/. Wenn du den Container aktualisierst oder neu startest, bleiben alle Daten erhalten.

Der Reverse Proxy: Caddy auf dem Host

Caddy läuft als Systemdienst direkt auf dem Host-Betriebssystem. Er nimmt HTTPS-Anfragen auf Port 443 entgegen, terminiert TLS und leitet den Traffic an localhost:3000 weiter. Let's-Encrypt-Zertifikate werden automatisch bezogen und erneuert. Du musst dich um nichts kümmern, solange Port 80 und 443 erreichbar sind.

Warum kein Caddy-Container? Weil ein Host-Dienst die Zertifikate für alle Anwendungen auf dem Server verwalten kann. Wenn du neben ISMS Lite noch andere Dienste betreibst, konfigurierst du einfach weitere Einträge in der Caddyfile, ohne Container-Netzwerke verschachteln zu müssen.

Installation: Ein Befehl, 15 Minuten

Die Installation von ISMS Lite erfordert kein manuelles Zusammenstöpseln von Docker-Compose-Dateien und Konfigurationen. Ein Installer-Script erledigt alles:

curl -sSL https://get.ismslite.de | sudo bash

Was das Script macht

Das ist kein blindes "curl | bash"-Abenteuer. Das Script durchläuft einen definierten Prozess:

1. Betriebssystem prüfen. Unterstützt werden Ubuntu 22/24 LTS und Debian 12/13. Andere Distributionen werden mit einer klaren Fehlermeldung abgelehnt.
2. Docker installieren. Falls Docker nicht vorhanden ist, installiert das Script die aktuelle stabile Version.
3. Release herunterladen. Das Archiv kommt von updates.ismslite.de, dem zentralen Release-Server.
4. Signatur verifizieren. Jedes Release wird mit SHA256-Prüfsumme und Ed25519-Signatur verifiziert. Manipulierte Downloads werden erkannt und abgebrochen.
5. Entpacken nach /opt/ismslite/. Das ist das Standard-Installationsverzeichnis.
6. Secrets generieren. Die .env-Datei wird automatisch mit kryptografisch sicheren Zufallswerten befüllt: ENCRYPTION_KEY, SESSION_SECRET und das Datenbank-Passwort, jeweils via openssl rand -hex 32.
7. Container starten. docker compose up -d startet App und Datenbank.
8. Health-Check. Das Script wartet, bis der Endpoint /api/health eine positive Antwort liefert. Erst dann gilt die Installation als abgeschlossen.
9. Caddy konfigurieren. Falls Caddy noch nicht installiert ist, wird es eingerichtet und die Konfiguration für deine Domain erstellt. HTTPS läuft automatisch via Let's Encrypt.

Optionale Flags

Du kannst das Verhalten des Installers anpassen:

# Domain für Caddy und APP_URL setzen
curl -sSL https://get.ismslite.de | sudo bash -s -- --domain isms.firma.de

# Anderen App-Port verwenden (Standard: 3000)
curl -sSL https://get.ismslite.de | sudo bash -s -- --port 3100

# Kein Caddy installieren (für bestehende Reverse Proxies wie Nginx oder Traefik)
curl -sSL https://get.ismslite.de | sudo bash -s -- --no-proxy

# Anderes Installationsverzeichnis
curl -sSL https://get.ismslite.de | sudo bash -s -- --install-dir /srv/ismslite

Das --no-proxy-Flag ist relevant, wenn du bereits einen Reverse Proxy betreibst. In diesem Fall konfigurierst du Nginx, Traefik oder was auch immer du nutzt selbst und leitest den Traffic an 127.0.0.1:3000 weiter.

Die .env-Datei nach der Installation

Nach der Installation sieht die generierte .env-Datei so aus:

DATABASE_URL=postgresql://isms:generiertes-passwort@localhost:5433/isms
ENCRYPTION_KEY=a3f8...64-stelliger-hex-wert
SESSION_SECRET=b7c2...64-stelliger-hex-wert
APP_URL=https://isms.firma.de
EMAIL_FROM=isms@firma.de

# Optional: KI-Unterstützung für Risikobeschreibungen und Maßnahmenvorschläge
AI_ENABLED=false
# AI_BASE_URL=http://localhost:11434/v1  # Für lokale LLMs wie Ollama

Der ENCRYPTION_KEY ist besonders wichtig: Er verschlüsselt sensible Datenbankfelder (Risiken, Vorfälle, Notfallpläne) mit AES-256-GCM. Verlierst du diesen Schlüssel, sind die verschlüsselten Felder nicht mehr lesbar. Sichere ihn separat, am besten in einem Secrets-Management-Tool oder zumindest in einem Passwort-Manager.

{% CTA %}

Sicherheitsarchitektur: Was unter der Haube passiert

ISMS Lite speichert hochsensible Daten. Die Sicherheitsarchitektur geht deshalb über Standard-Docker-Härtung hinaus.

Verschlüsselung auf Datenbankebene

Nicht alle Daten in der PostgreSQL-Datenbank sind gleich schützenswert. Stammdaten wie Benutzernamen oder Rollenzuweisungen liegen im Klartext. Aber Risikobewertungen, Vorfallsberichte und Notfallpläne werden mit AES-256-GCM verschlüsselt, bevor sie in die Datenbank geschrieben werden. Der Schlüssel dafür ist der ENCRYPTION_KEY aus der .env-Datei.

Das bedeutet: Selbst wenn jemand direkten Zugriff auf die PostgreSQL-Datenbank bekommt, sieht er bei den sensiblen Feldern nur verschlüsselte Binärdaten. Ohne den ENCRYPTION_KEY sind sie wertlos.

Authentifizierung und Zugriffskontrolle

• Passwort-Hashing: Argon2id, der aktuell empfohlene Algorithmus. Kein bcrypt, kein SHA-256.
• Zwei-Faktor-Authentifizierung: TOTP-basiert (kompatibel mit jeder Authenticator-App). Für Admins erzwingbar.
• SSO-Integration: LDAP und Entra ID (ehemals Azure AD) für Single Sign-On. Damit nutzen deine Mitarbeiter ihre bestehenden Unternehmens-Credentials.
• JWT-basierte Sessions: Kurzlebige Tokens mit automatischer Erneuerung.
• Content Security Policy: script-src 'self' verhindert Cross-Site-Scripting über eingeschleuste Scripts.

Unveränderliche Audit-Logs

Die Audit-Logs in ISMS Lite sind auf Datenbankebene durch Trigger geschützt. Das heißt: Selbst ein Datenbankadministrator kann nachträglich keine Einträge löschen oder verändern, ohne den Trigger zu deaktivieren. Das gibt dir im ISMS-Audit einen belastbaren Nachweis, wer wann was geändert hat.

Netzwerk-Isolation

Alle Ports binden nur auf 127.0.0.1. Weder die Anwendung noch die Datenbank sind direkt aus dem Internet erreichbar. Die einzigen offenen Ports nach außen sind 80 und 443, beides vom Caddy Reverse Proxy bedient. Stelle sicher, dass die Firewall auf dem Host-System entsprechend konfiguriert ist.

Backup und Restore: Eingebaut, nicht nachgerüstet

Backups sind kein Nachgedanke, sondern Teil der ISMS-Lite-CLI. Du brauchst keine eigenen Backup-Scripts zu schreiben.

Manuelles Backup

isms-lite backup

Das erstellt einen vollständigen Backup-Dump (Datenbank + Uploads) unter /opt/ismslite/data/backups/. Der Dateiname enthält einen Zeitstempel.

Willst du das Backup an einen anderen Ort schreiben:

isms-lite backup --output /mnt/backup-share/isms/

Automatische Pre-Update-Backups

Bevor ein Update eingespielt wird, erstellt ISMS Lite automatisch ein Backup. Das passiert sowohl bei CLI-Updates als auch bei Updates über die Web-UI. Du hast also immer einen Rückfallpunkt.

Restore

isms-lite restore backup.dump

Der Restore-Befehl stellt Datenbank und Uploads aus einem Backup-Dump wieder her. Teste das regelmäßig. Ein Backup, das nie getestet wurde, ist eine Hoffnung, kein Plan. Die Backup-Strategie deines Unternehmens sollte quartalsweise Restore-Tests vorsehen.

Offsite-Replikation

Die eingebaute Backup-Funktion sichert lokal auf dem Server. Für eine vollständige Backup-Strategie nach BSI-Empfehlung brauchst du zusätzlich eine Offsite-Kopie. Ein Cronjob, der die Backup-Dateien per rsync oder rclone an einen zweiten Standort überträgt, reicht dafür aus:

# /etc/cron.d/isms-offsite-backup
30 3 * * * root rsync -az /opt/ismslite/data/backups/ backup@zweitstandort:/backups/isms/

Updates: Signiert, verifiziert, mit Rollback

Updates sind einer der Punkte, an denen Self-Hosting traditionell Arbeit macht. ISMS Lite reduziert das auf zwei Wege.

Per CLI

# Prüfen ob ein Update verfügbar ist
isms-lite update --check

# Update einspielen (interaktiv, mit Changelog)
isms-lite update

Das Update-Kommando:

1. Prüft auf neue Versionen bei updates.ismslite.de
2. Zeigt das Changelog
3. Erstellt automatisch ein Backup
4. Lädt das neue Release herunter
5. Verifiziert SHA256-Prüfsumme und Ed25519-Signatur
6. Tauscht die Container aus
7. Führt Datenbankmigrationen durch
8. Prüft den Health-Check

Wenn bei Schritt 6-8 etwas schiefgeht, wird automatisch auf den vorherigen Stand zurückgerollt: App-Container und Datenbank. Du musst nicht manuell eingreifen.

Per Web-UI

Alternativ kannst du Updates über die Web-Oberfläche einspielen: Einstellungen → System → Update. Das ist der gleiche Prozess wie per CLI, nur mit grafischer Oberfläche. Praktisch, wenn der ISB selbst das Update anstoßen will, ohne SSH-Zugang.

Release-Signierung

Jedes ISMS-Lite-Release ist mit Ed25519 signiert. Das ist keine optionale Sicherheitsfunktion, sondern Pflicht: Der Installer und der Update-Prozess verweigern die Installation, wenn die Signatur nicht stimmt. Damit ist sichergestellt, dass kein manipuliertes Release auf deinen Server gelangt, selbst wenn jemand den Download-Server kompromittiert.

{% CTA %}

Monitoring: Health-Check und Docker-Status

Ein Self-Hosted-System braucht Monitoring. ISMS Lite bringt die Grundlagen mit, die Infrastruktur-Ebene liegt bei dir.

Eingebauter Health-Endpoint

GET /api/health

Dieser Endpoint prüft drei Dinge:

• Ist die Anwendung erreichbar?
• Antwortet die Datenbank?
• Sind alle Datenbankmigrationen durchgelaufen?

Wenn einer dieser Checks fehlschlägt, liefert der Endpoint einen Fehler-Statuscode. Du kannst ihn in dein bestehendes Monitoring einbinden, egal ob Uptime Kuma, Prometheus Blackbox Exporter oder ein simpler Curl-Check per Cronjob:

*/5 * * * * curl -sf https://isms.firma.de/api/health || \
  mail -s "ISMS Health Check Failed" admin@firma.de < /dev/null

Docker Health-Checks

Beide Container bringen eigene Docker Health-Checks mit. Docker erkennt also selbstständig, wenn ein Container nicht mehr korrekt funktioniert, und kann ihn dank restart: unless-stopped automatisch neu starten.

Prüfe den Status mit:

docker compose -f /opt/ismslite/docker-compose.yml ps

Festplattenbelegung

Wenn die Festplatte voll ist, stoppt PostgreSQL. Überwache die Belegung und warne frühzeitig:

0 * * * * df -h /opt/ismslite | awk 'NR==2 && int($5)>80 {print}' | \
  mail -s "ISMS Disk Warning" admin@firma.de

Systemanforderungen und Kostenkalkulation

Was dein Server braucht

Das ist bewusst niedrig angesetzt. Ein ISMS-Tool bedient typischerweise 5-30 gleichzeitige Nutzer, keine Tausende. Die Datenbankgröße wächst langsam: Selbst nach Jahren intensiver Nutzung bleibst du unter einem Gigabyte reiner Daten (plus Uploads).

Was es kostet

Server: Ein vServer bei Hetzner oder Netcup mit diesen Spezifikationen kostet 5-10 Euro pro Monat. Bei einem deutschen Hoster hast du gleich die DSGVO-konforme Datenhaltung erledigt.

ISMS Lite Lizenz: 500 €/Jahr im Abo oder 2.500 € als Einmalkauf. Für MSPs gibt es ein Paket mit 10 Instanzen für 10.000 €.

Zum Vergleich: Cloud-ISMS-Tools liegen typischerweise bei 200-800 € pro Monat, also 2.400-9.600 € im Jahr. Die Einsparung ist erheblich, aber der eigentliche Vorteil ist die Kontrolle. Du weißt, wo die Daten liegen, wer Zugriff hat und wie sie geschützt sind. Das sind Fragen, die im Management Review und in jedem externen Audit kommen.

Bestehende Reverse Proxies: Nginx und Traefik

Nicht jeder will Caddy. Wenn du bereits einen Reverse Proxy betreibst, nutzt du das --no-proxy-Flag bei der Installation und konfigurierst die Weiterleitung selbst.

Nginx

server {
    listen 443 ssl http2;
    server_name isms.firma.de;

    ssl_certificate     /etc/letsencrypt/live/isms.firma.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/isms.firma.de/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Traefik

Wenn du Traefik mit Docker-Labels nutzt, denke daran, dass der ISMS-Lite-App-Container nur auf 127.0.0.1 lauscht. Du brauchst ein gemeinsames Docker-Netzwerk zwischen Traefik und ISMS Lite, oder du konfigurierst Traefik als Host-Dienst mit File-Provider.

Interne Netze ohne Let's Encrypt

Wenn dein ISMS nur im internen Netzwerk erreichbar sein soll und keine öffentliche Domain hat, kannst du kein Let's-Encrypt-Zertifikat verwenden. Zwei Optionen:

Eigene CA. Du betreibst eine interne Certificate Authority und stellst Zertifikate für interne Domains aus. Die Root-CA wird auf den Clients als vertrauenswürdig importiert. Das ist der sauberste Weg und bei Unternehmen mit Active-Directory-Umgebung oft schon vorhanden.

Self-signed Zertifikat. Für kleine Installationen reicht ein selbstsigniertes Zertifikat. Die Browser-Warnung ist lästig, aber die Verschlüsselung funktioniert trotzdem. Importiere das Zertifikat auf den zugreifenden Rechnern, um die Warnung zu vermeiden.

Praxisbeispiel: Von null auf laufendes ISMS in 15 Minuten

Ein konkreter Ablauf, wie du von einem blanken Ubuntu-Server zu einem laufenden ISMS kommst.

Minute 0-2: Server vorbereiten. Du hast einen frischen Ubuntu 24.04 LTS vServer bei einem deutschen Hoster. SSH-Zugang steht, Firewall ist auf Ports 22, 80 und 443 beschränkt. DNS-Eintrag für isms.firma.de zeigt auf die Server-IP.

Minute 2-8: Installer ausführen.

curl -sSL https://get.ismslite.de | sudo bash -s -- --domain isms.firma.de

Das Script installiert Docker, lädt das Release herunter, verifiziert die Signatur, generiert die Secrets, startet die Container und konfiguriert Caddy. Du siehst den Fortschritt in der Konsole. Am Ende steht: ISMS Lite is running at https://isms.firma.de.

Minute 8-12: Ersteinrichtung. Du öffnest https://isms.firma.de im Browser. Caddy hat automatisch ein Let's-Encrypt-Zertifikat bezogen, die Verbindung ist verschlüsselt. Der Setup-Wizard führt dich durch: Admin-Benutzer anlegen, Unternehmensname und Branche eintragen, MFA aktivieren.

Minute 12-15: Backup und Monitoring. Du richtest den Offsite-Backup-Cronjob ein und trägst den Health-Check-URL in dein Monitoring ein. Fertig.

Ab jetzt kannst du mit dem eigentlichen ISMS-Aufbau beginnen: Geltungsbereich definieren, Risiken erfassen, Controls zuordnen.

Häufige Fehler beim Self-Hosted-Betrieb

ENCRYPTION_KEY verlieren. Der Verschlüsselungsschlüssel in der .env-Datei ist nicht wiederherstellbar. Wenn du ihn verlierst, sind die AES-256-GCM-verschlüsselten Datenbankfelder dauerhaft unlesbar. Sichere den Schlüssel an einem zweiten Ort, bevor du das System produktiv nutzt.

Datenbank-Port freigeben. PostgreSQL darf niemals direkt aus dem Internet erreichbar sein. In der Standard-Konfiguration bindet der Port nur auf 127.0.0.1. Ändere das nicht. Wenn du von einem anderen Rechner auf die Datenbank zugreifen musst, nutze einen SSH-Tunnel.

Updates aufschieben. Docker-Images und das Host-Betriebssystem brauchen regelmäßige Updates. Richte einen festen Patch-Management-Rhythmus ein: monatlich für reguläre Updates, sofort bei kritischen Sicherheitslücken. Die eingebaute Update-Funktion macht das einfach, nutze sie auch.

Keinen zweiten Backup-Standort haben. Die lokalen Backups unter /opt/ismslite/data/backups/ schützen vor Fehlbedienung und fehlgeschlagenen Updates. Sie schützen nicht vor Hardware-Ausfall, Ransomware oder Feuer. Repliziere Backups an einen physisch getrennten Standort.

Restore nie testen. Ein Backup, das nie getestet wurde, existiert nicht. isms-lite restore auf einem Testsystem ausprobieren ist eine Sache von 10 Minuten. Mach es quartalsweise. Im ISMS-Kontext ist ein dokumentierter Restore-Test auch ein Nachweis, den der Auditor sehen will.

Kein Monitoring einrichten. "Läuft ja." Bis es nicht mehr läuft und niemand es bemerkt. Der Health-Endpoint ist in 5 Minuten in ein Monitoring eingebunden. Wenn du noch kein Monitoring hast, reicht Uptime Kuma als Docker-Container auf einem anderen Server als Einstieg.

Wartungsaufwand: Realistisch geschätzt

Die ehrliche Antwort auf "Wie viel Aufwand macht Self-Hosting?" lautet: 1-2 Stunden pro Monat.

Das ist weniger Aufwand als die Verwaltung eines SaaS-Abonnements, bei dem du Subprocessor-Änderungen bewerten, AVV-Aktualisierungen prüfen und Zertifikatsnachweise des Anbieters für die Lieferantenbewertung einholen musst. Beim Self-Hosting investierst du die Zeit in technische Kontrolle statt in Papierkram.

Und wenn du ehrlich bist: Die meisten dieser Aufgaben fallen ohnehin an, egal ob du ISMS Lite betreibst oder nicht. Betriebssystem-Updates, Festplattenüberwachung und Backup-Monitoring sind Grundlagen der IT-Hygiene, die auf jedem Server laufen sollten. ISMS Lite fügt dem lediglich einen Update-Befehl und einen Restore-Test pro Quartal hinzu.

{% CTA %}

Checkliste: Self-Hosted ISMS Lite in Betrieb nehmen

• Server mit Ubuntu 22/24 oder Debian 12/13 bereitstellen (2 Cores, 2 GB RAM, 10 GB SSD)
• DNS-Eintrag für die ISMS-Domain anlegen (A-Record auf Server-IP)
• Ports 80, 443 und SSH in der Firewall freigeben
• Installer ausführen: curl -sSL https://get.ismslite.de | sudo bash --domain isms.firma.de
• Ersteinrichtung im Browser abschließen (Admin-Account, Firmendaten)
• ENCRYPTION_KEY aus .env separat sichern (Passwort-Manager, Tresor)
• MFA für Admin-Accounts aktivieren
• Offsite-Backup per rsync/rclone einrichten
• Health-Check-Monitoring konfigurieren
• Ersten Restore-Test durchführen
• Wartungsintervall im Kalender eintragen

Weiterführende Artikel

• Self-Hosted vs. Cloud: Datensouveränität bei Compliance-Software
• Backup-Strategie und Restore-Tests: Weil Backups allein nicht reichen
• Verschlüsselung von ISMS-Daten: At Rest, In Transit und im Backup
• Container-Sicherheit: Docker und Kubernetes im Mittelstand absichern
• ISMS-Daten sichern: Backup-Strategie für selbst gehostete Compliance-Systeme