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.
|
Das BPC verwendet Websockets (unter |
NGINX
NGINX ist ein sehr häufig eingesetzter Webserver/Reverse Proxy.
Die folgende Konfiguration kann genutzt werden, um das BPC unter dem Pfad HOSTNAME/bpc zur Verfügung zu stellen.
server {
server_name HOSTNAME;
listen 80 default_server;
listen [::]:80 default_server;
# TODO TLS configuration
keepalive_timeout 300s;
client_max_body_size 2048m;
proxy_connect_timeout 300s;
proxy_send_timeout 300s;
proxy_read_timeout 300s;
fastcgi_read_timeout 300s;
location /bpc/ {
# needed for websockets
proxy_set_header Upgrade "websocket";
proxy_set_header Connection "Upgrade";
proxy_set_header X-Real_IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_read_timeout 36000s;
# This is necessary to pass the correct IP to be hashed
real_ip_header X-Real-IP;
proxy_redirect off;
proxy_pass http://127.0.0.1:8181/;
}
}|
Diese Konfiguration dient nur als einfaches Beispiel. In der Regel muss die Konfiguration an Ihre Gegebenheiten angepasst werden. Es besteht kein Anspruch auf Vollständigkeit oder Fehlerfreiheit. |
HAProxy
Der HAProxy ist ebenfalls eine etablierte Option.
global
log /dev/log local0
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
user haproxy
group haproxy
daemon
ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets
ssl-default-bind-ciphers HIGH:!aNULL:!MD5
defaults
log global
option httplog
timeout connect 300s
timeout client 300s
timeout server 300s
frontend bpc_frontend
bind :80
bind :443 tfo ssl crt /etc/haproxy/certs/ alpn h2,http/1.1
mode http
http-request redirect scheme https unless { ssl_fc }
http-request set-header Host %[req.hdr(Host)]
http-request set-header X-Real-IP %[src]
http-request set-header X-Forwarded-For %[src]
http-request set-header X-Forwarded-Proto https
default_backend bpc_backend
backend bpc_backend
mode http
server bpc1 127.0.0.1:8181 check|
Diese Konfiguration dient nur als einfaches Beispiel. In der Regel muss die Konfiguration an Ihre Gegebenheiten angepasst werden. Es besteht kein Anspruch auf Vollständigkeit oder Fehlerfreiheit. |
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.
Datenbank-Verbindungen
Für Verbindungen zu relationen Datenbanken (Datenbanken und Backend Connection vom Typ data_source) wird in den meisten Fällen nur eine lesende Verbindung benötigt.
Um Sicherheitsproblemen vorzubeugen, empfiehlt es sich nach dem Least Privilege Prinzip einen Datenbankbenutzer zu verwenden, der nur Leserecht hat.
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.
