Serversicherheit

Dieser Abschnitt behandelt die Überprüfung der Sicherheitskontrollen auf Serverebene für ein Passwork-On-Premise-Deployment. Bei Cloud-gehosteten Instanzen werden Netzwerk- und Zertifikatskontrollen von der Passwork-Infrastruktur verwaltet — konzentrieren Sie diese Überprüfung auf Einstellungen auf Anwendungsebene.

---

1. TLS / HTTPS

Was zu überprüfen ist

1.1 HTTPS erzwungen

Alle HTTP-Anfragen müssen auf HTTPS umleiten. Überprüfen Sie mit:

curl -I http://your.passwork.url/
# Expected: HTTP/1.1 301 Moved Permanently
# Location: https://your.passwork.url/

1.2 Gültiges Zertifikat in der Produktion

Selbstsignierte Zertifikate sind nur in isolierten Entwicklungs- oder PoC-Umgebungen akzeptabel. Produktions-Deployments erfordern ein von einer vertrauenswürdigen CA signiertes Zertifikat (Let's Encrypt, interne CA für air-gapped Netzwerke oder eine kommerzielle CA).

Prüfen Sie das Zertifikat:

openssl s_client -connect your.passwork.url:443 -servername your.passwork.url 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates

Überprüfen Sie:

• Der Aussteller ist eine vertrauenswürdige CA (nicht self-signed)
• notAfter liegt mindestens 30 Tage in der Zukunft
• Der Subject stimmt mit dem Hostnamen überein (CN oder SAN)

1.3 TLS-Version

Mindestens TLS 1.2. TLS 1.3 bevorzugt. SSLv3, TLS 1.0 und TLS 1.1 müssen deaktiviert sein.

nmap --script ssl-enum-ciphers -p 443 your.passwork.url

Oder verwenden Sie einen externen Scanner: SSL Labs, testssl.sh.

Erwartete Bewertung: A oder höher.

1.4 HSTS-Header vorhanden

Der Strict-Transport-Security-Header verhindert, dass Browser nach der ersten HTTPS-Verbindung über HTTP auf die Website zugreifen.

curl -s -I https://your.passwork.url/ | grep -i strict
# Expected: strict-transport-security: max-age=31536000; includeSubDomains

Standardkonfiguration

Bei Docker-Builds wird HSTS in conf/nginx/nginx.conf konfiguriert. Bei Apache2/IIS wird es in der Virtual-Host-Konfiguration gesetzt. Wenn der Header fehlt, siehe SSL-Terminierung.

---

2. HTTP-Sicherheits-Header

Passwork setzt die folgenden Header standardmäßig in Docker (Nginx extra/security-headers.conf) und Apache2 (.htaccess). Überprüfen Sie, dass alle vorhanden sind.

curl -s -I https://your.passwork.url/ | grep -iE "x-frame|x-content|x-xss|referrer|permissions|strict"

Header	Erwarteter Wert	Risiko bei Fehlen
X-Frame-Options	DENY	Clickjacking
X-Content-Type-Options	nosniff	MIME-Sniffing-Angriffe
X-XSS-Protection	1; mode=block	XSS in älteren Browsern
Referrer-Policy	strict-origin-when-cross-origin	Referrer-Leck
Permissions-Policy	camera=(), microphone=(), geolocation=()	Unnötiger API-Zugriff
Strict-Transport-Security	max-age=31536000; includeSubDomains	Downgrade-/MITM-Angriffe

Konfigurationsdetails finden Sie unter Header.

Wenn ein Header fehlt

Für Docker: Überprüfen Sie, dass extra/security-headers.conf in die Nginx-Konfiguration eingebunden ist und dass der Container nach Änderungen neu gestartet wurde. Für Apache2: Überprüfen Sie, dass die .htaccess-Verarbeitung aktiviert ist (AllowOverride All).

---

3. CORS-Konfiguration

CORS steuert, welche externen Origins Anfragen an die Passwork-API stellen können.

Risiko der Standardkonfiguration: Die standardmäßige Docker-cors.conf setzt Access-Control-Allow-Origin: *, wodurch jeder Origin Cross-Origin-Anfragen stellen darf. Dies ist akzeptabel, wenn Passwork in einem privaten Netzwerk ohne externen Zugriff bereitgestellt wird, muss aber überprüft werden, wenn die Instanz aus dem Internet erreichbar ist.

Was zu überprüfen ist

Prüfen Sie den aktuellen CORS-Header:

curl -s -I -H "Origin: https://attacker.example.com" https://your.passwork.url/api/ \
  | grep -i access-control

Feststellung: Wenn die Antwort Access-Control-Allow-Origin: * enthält und der Server aus dem Internet erreichbar ist, beschränken Sie den Origin auf die exakte Passwork-URL.

So beschränken Sie ihn (Docker):

Bearbeiten Sie conf/nginx/extra/cors.conf und ersetzen Sie den Platzhalter durch ein spezifisches Origin-Muster. Die genaue Konfiguration finden Sie unter Header — CORS-Konfiguration.

---

4. Netzwerk-Härtung

MongoDB

MongoDB darf nicht aus dem Internet erreichbar sein. Überprüfen Sie:

# From an external host:
nc -zv your.passwork.url 27017
# Expected: Connection refused

Korrekte Konfiguration: MongoDB bindet nur an 127.0.0.1 (Loopback) oder eine private Netzwerkschnittstelle. Es darf in einer Produktionsumgebung niemals an 0.0.0.0 binden.

On-Premise-Deployments sollten außerdem überprüfen, dass die MongoDB-Authentifizierung aktiviert ist. Siehe Konfiguration der MongoDB-Autorisierung.

Firewall / exponierte Ports

Nur die folgenden Ports sollten aus nicht vertrauenswürdigen Netzwerken erreichbar sein:

Port	Protokoll	Zweck
443	TCP	HTTPS (Passwork-Weboberfläche und -API)
80	TCP	HTTP (nur Umleitung auf HTTPS)

Alle anderen Ports (27017 für MongoDB, Ports für die Datenbankreplikation, interne Admin-Schnittstellen) müssen auf Ebene der Netzwerk-Firewall blockiert werden.

Reverse Proxy und vertrauenswürdige Proxys

Wenn Passwork hinter einem Reverse Proxy (Nginx, Apache, HAProxy, Cloud-Load-Balancer) bereitgestellt wird, konfigurieren Sie vertrauenswürdige Proxys in config.env:

CLIENT_IP_SOURCES=REMOTE_ADDR

Oder beschränken Sie ihn auf bekannte Proxy-IPs, um IP-Spoofing über den X-Forwarded-For-Header zu verhindern. Siehe Vertrauenswürdige Proxys.

---

5. Health-Check-Endpunkt

Passwork stellt einen Health-Check-Endpunkt unter /api/latest/health-check bereit. Dieser Endpunkt kann Informationen zum Systemstatus preisgeben.

Was zu überprüfen ist

Prüfen Sie, ob der Endpunkt eine Authentifizierung erfordert:

curl -s https://your.passwork.url/api/latest/health-check

Wenn der Endpunkt Daten ohne Token zurückgibt, konfigurieren Sie HEALTH_CHECK_TOKEN in config.env:

HEALTH_CHECK_TOKEN=<random-256-bit-string>

Nach der Konfiguration erfordert der Endpunkt das Token im Anfrage-Header. Siehe Health Check.

---

6. Notfall-Reset-Modus

Das Flag IS_EMERGENCY_RESET_ENABLED=1 in config.env erlaubt das Zurücksetzen von Passwort und 2FA für das Besitzer-Konto über die Serverkonsole ohne Authentifizierung. Dies ist ein mächtiger Wiederherstellungsmechanismus, der nach der Verwendung nicht aktiviert bleiben darf.

Was zu überprüfen ist

Prüfen Sie auf dem Server die Konfigurationsdatei:

# Linux
grep "IS_EMERGENCY_RESET_ENABLED" /var/www/init/config.env

# Docker
grep "IS_EMERGENCY_RESET_ENABLED" /<passwork>/conf/keys/config.env

Akzeptable Werte:

• Einstellung nicht vorhanden → korrekt
• IS_EMERGENCY_RESET_ENABLED=0 → korrekt
• IS_EMERGENCY_RESET_ENABLED=1 → Feststellung: muss auf 0 gesetzt oder entfernt werden

Wenn dieses Flag kürzlich verwendet wurde, überprüfen Sie im Audit-Log, dass nur auf das erwartete Besitzer-Konto zugegriffen wurde.

Zum Verfahren für den Notfall-Reset siehe Notfallmodus.

---

7. Hintergrundaufgaben und Aktualität der LDAP-Synchronisierung

Hintergrundaufgaben steuern die LDAP-Synchronisierung, Prüfungen des Passwortablaufs und andere automatisierte Wartung. Wenn Cron nicht läuft, kann die LDAP-Gruppenmitgliedschaft veraltet sein — Benutzer, die eine AD-Gruppe verlassen haben, könnten den Tresorzugriff in Passwork behalten.

Was zu überprüfen ist

Gehen Sie im Passwork-Admin-Panel zu Einstellungen → Hintergrundaufgaben und überprüfen Sie:

• Alle Aufgaben zeigen einen aktuellen Startzeit-Zeitstempel (innerhalb des erwarteten Zeitplanfensters)
• Keine Aufgabe zeigt einen Fehlerstatus

Details zur Cron-Konfiguration finden Sie unter Cron-Einrichtung für Linux oder Einrichtung der Windows-Aufgabenplanung.

---

Zusammenfassende Checkliste

#	Kontrolle	Status
1.1	HTTP → HTTPS-Umleitung aktiv
1.2	Gültiges, von einer CA signiertes SSL-Zertifikat
1.3	Nur TLS 1.2+; ältere TLS-Versionen deaktiviert
1.4	HSTS-Header vorhanden mit includeSubDomains
2	Alle 6 Sicherheits-Header vorhanden
3	CORS-Origin beschränkt (falls aus dem Internet erreichbar)
4.1	MongoDB-Port 27017 nicht extern erreichbar
4.2	MongoDB-Authentifizierung aktiviert
4.3	Nur Ports 80/443 gegenüber nicht vertrauenswürdigen Netzwerken exponiert
4.4	Vertrauenswürdige Proxys konfiguriert (falls hinter einem Reverse Proxy)
5	Health-Check-Endpunkt mit Token geschützt
6	IS_EMERGENCY_RESET_ENABLED ist 0 oder nicht vorhanden
7	Hintergrundaufgaben laufen planmäßig

LLM version