Sicherheit
Diese Seite beschreibt integrierte Sicherheitsfunktionen des Business Process Centers sowie Maßnahmen, die für den sicheren produktiven Einsatz empfohlen werden.
Empfohlene Systemarchitektur
Für den sicheren Einsatz des BPC wird eine Kombination von verschiedenen Maßnahmen empfohlen.
Achten Sie darauf, dass eine Transportverschlüsselung (siehe TLS / HTTPS) zum Einsatz kommt. Außerdem sollten Sie ein Reverse Proxy und eine Web Application Firewall vor dem BPC einrichten.
TLS / HTTPS
Es wird empfohlen, für das BPC eine Sichere Verbindung (TLS/HTTPS) zu konfigurieren. Somit wird eine verschlüsselte Übertragung im Netzwerk sichergestellt.
Ist dies umgesetzt, sollten Sie außerdem sichere Cookies aktivieren.
Reverse Proxy
Der Einsatz eines Reverse Proxy wird dringend empfohlen. Dieser sorgt dafür, dass das BPC auf Netzwerkebene abgeschottet und nur gezielt Netzwerkverkehr weitergeleitet wird. Ein Reverse Proxy kann zusätzliche Veränderungen am Netzwerkverkehr vornehmen und bietet weitere Funktionen, wie z.B. Caching.
Häufig wird hierfür NGINX verwendet.
|
Das BPC verwendet Websockets (unter |
Web Application Firewall
Mit einer Web Application Firewall kann der Netzwerkverkehr gescannt und gefiltert werden. Dabei können typische Angriffe erkannt und abgewehrt werden.
Für den Client-Zugriff (User mittels Webbrowser) sollten Sie eine Allowlist mit folgenden Werten aufsetzen:
SERVER/*.* (z.B: /index.html /index.jsp /app.js)
SERVER/cxf/** -> (z.B. /cxf/bpc-core/configuration)
SERVER/resources/**
SERVER/bpc-fe-*/**
SERVER/bpc-theme-*/**
SERVER/websocketHäufig wird hierfür ModSecurity verwendet.
OpenSearch Zugriff
Im Auslieferungszustand bindet sich OpenSearch nur an lokale Interfaces. Dies sollte auch so beibehalten werden.
Falls Sie den Zugriff ausdehnen wollen (zum Beispiel, um OpenSearch im Cluster oder auf einem separaten Server zu betreiben), dann sollten Sie Maßnahmen ergreifen, die den Zugriff einschränken.
Siehe dazu OpenSearch per HTTPS
|
Mit Netzwerkzugriff auf die REST-Schnittstelle von OpenSearch besteht uneingeschränkter Vollzugriff auf alle Daten. Daher sollte dieser Zugriff reglementiert sein. |
Weitere Maßnahmen zur Erhöhung des Sicherheitsniveaus
Im Folgenden werden im BPC integrierte Sicherheitsmaßnahmen beschrieben.
Cross-Site-Request-Forgery
Im BPC wird versucht, CSRF-Angriffe abzuwehren.
Wenn Sie eigene Module nutzen oder externe Anwendungen über das BPC einbinden, müssen Sie evtl. Anpassungen vornehmen, damit Sie durch den Schutzmechanismus selbst eingeschränkt werden.
Siehe dazu CSRF Abwehr
Bei Backend Connections vom Typ http_proxy ist es möglich, den CSRF Check abzuschalten.
User-Session IP Pinning
Um zu verhindern, dass eine User-Session "geklaut" wird, merkt sich das BPC beim Login die IP des Benutzers (Session Fixation). Diese Information wird bei jedem folgenden Aufruf mit der IP-Adresse des Aufrufs abgeglichen. Weicht die IP-Adresse des Aufrufs von der aus der User-Session ab, so wird der Aufruf abgelehnt.
|
Damit diese Funktion greift, muss beim Einsatz von Proxies der HTTP Header X-Forwarded-For korrekt gesetzt werden. Dies gilt auch für den Websocket. |
Content Security Policy
Über HTTP Header wird eine Content Security Policy (CSP) definiert. Diese wird vom Browser umgesetzt und führt dazu, dass z.B. Ressourcen wie Bilder und Skript-Dateien nicht von unbekannten Quellen geladen werden.
Es kann nötig sein, die CSP an ihre Bedürfnisse anzupassen. Dafür muss die Einstellung des Headers, wie auf der Seite HTTP Header beschrieben, geändert werden.
HTML Sanitizing
Im Frontend wird der von den Modulen erzeugte HTML-Code automatisch bereinigt. Dabei werden JavaScript und ungültige Elemente entfernt, um Scripting-Attacken vorzubeugen. Sollten Ihre Module inline JavaScript benötigen, so können Sie dies über die Einstellung sanitzeHTML am jeweiligen Modul abschalten.
Wenn die Bereinigung Elemente aus dem HTML entfernt, so wird dies in der Browser-Konsole geloggt.
Um diese Logs sehen zu können, müssen Sie das Log-Level unter Umständen auf debug/verbose einstellen.
