¶ Sicherheit
Diese Sektion befasst sich mit sicherheitsrelevanten Informationen zu den Themen Datenverarbeitung, Informationsfluss und Netzwerkstruktur.
¶ TLS-Terminierung
Die TLS-Terminierung wird nicht von Dynexite vorgenommen. Dazu kann ein belieber Webservice wie z.B. nginx verwendet werden.
Eine Außnahme stellt zur Zeit noch das satellite-backend dar, welcher die Option zu einer TLS-Terminierung verfügt um eine direkte Websocketverbindung zu ermöglichen und Fehlkonfiguration des Reverse-Proxies zu vermeiden.
Da die Auswahl vom Orchestrierungstool abhängt und unzählige Tutorials zum Thema Reverse-Proxy in Containerumgebungen existieren, können wir hier keine universelle Empfehlung geben.
Wir verwenden zurzeit primär diesen nginx Reverse Proxy:
https://github.com/nginx-proxy/nginx-proxy
Siehe auch: https://en.wikipedia.org/wiki/TLS_termination_proxy
¶ Reverse Proxy - X-Forwarded-For
Der Header X-Forwarded-For ist ein wichtiges Werkzeug bei der Arbeit mit Reverse Proxies.
Um sicherzustellen, dass der Wert nicht von außen manipuliert werden kann, muss der äußerste Reverse Proxy entsprechend konfiguriert werden. Dazu muss die IT-Abteilung entsprechende Werte setzen.
Diese Einstellung hier muss als für primären Reverse Proxy gesetzt werden
# Nginx will use the IP address of the client that directly connected to it.
proxy_set_header X-Forwarded-For $remote_addr;
Für innere Proxies können folgende Einstellungen verwendet werden:
# By using this setting, Nginx will forward the X-Forwarded-For header it received without modification.
proxy_set_header X-Forwarded-For $http_x_forwarded_for;
# Using this setting, Nginx adds the $remote_addr to the end of the
# existing X-Forwarded-For header, preserving the entire chain of IP addresses through proxies.
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
Quellen:
https://paigekim29.medium.com/understanding-x-forwarded-for-header-settings-in-nginx-4929f49d57dd
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For
https://www.loadbalancer.org/blog/nginx-and-x-forwarded-for-header/
¶ Zertikate im Satelliten
Jedes System ist anders. Stellen sie sicher, dass Ihr Prüfungssystem genau Ihren Ansprüchen genügt. Was ich hier anreiße ist ein komplexes Thema, welches individuell geplant, bewertet und durchgeführt werden muss.
Eine TLS-Terminierung im Satelliten stellt die Betreiber vor einer weiteren Herausforderungen, da sich das System in der Regel in einem abgeschlossenem Bereich befindet: Die Clients müssen das Zertifikat akzeptieren!
- Es wird möglicherweise ein lokaler DNS benötigt, da es mit der Nutzung von IP-Adressen vermehrt zu Problemen kommen kann. (d.h. https://satellite.dynexite/ vs https://10.0.5.12/)
- Wenn ein öffentliches Zertifikat verwendet wird, so muss sichergestellt sein, dass die Clients diese in dem geschlossenem System akzeptieren.
- Wenn ein selbstsigniertes Zertifikat verwendet werden soll, so ist ggf. der Einsatz einer eigene CA ratsam, welches einmalig auf alle Clientgeräte aufgespielt werden muss. Siehe z.B. grundsätzliche Idee.
- Als letzte Bastion kann eine individuelles Freigabe aller Geräte gesehen werden. In diesem Fall empfehle ich einen zentralen Reverse Proxy für
frontendundbackend, damit diese simultan freigegeben werden können.
Aufbau eines gesicherten Satelliten
1.) Verwenden sie einen Reverse-Proxy für das satellite-frontend mit entsprechender Konfiguration.
2.) Verwenden Sie entweder denselben Reverse-Proxy (besondere Konfiguration für Websocket beachten!) oder nutzen sie die Optionen SSH, SSH_CERT, und SSH_KEY des satellite-backend. (siehe Fußnote in Installation des Salliten)
¶ Aktualisierung von interner Container-Software
Dynexite verwendet den Golang Webserver und immer den letzte stabile Version von Nginx über das offizielle Docker-Image.
Die verwendeten Hilfs-Dienste verwenden sowohl Nginx, Golang und Python. Aber: Diese sollten niemals öffentlich bereitgestellt werden. Sollte einer dieser Dienste von Sicherheitslücken befallen sein, stehen Optionen abhängig vom Typ des Problems zur Auswahl.
Allgemeine Empfehlung
Um die Möglichkeit eines Angriffs zu reduzieren und das System als lokaler IT-Administrator immer auf dem neuesten Stand zu halten, empfehlen wir, die Container immer hinter einer Firewall und einem Reverse-Proxy zu betreiben.
Dieser kann ohne Rücksprache aktualisiert werden, dient als Blockade für alle eingehenden Angriffe, versteckt zudem die verwendeten Webservers und muss zur Zeit ohnehin verwendet werden um die TLS-Terminierung durchzuführung.
¶ Nginx Webserver
Es ist nicht direkt vorgesehen, aber theoretisch möglich einen Server innerhalb eines Containers zu aktualisieren. Bitte beachten Sie auch das FAQ zu diesem Thema.
Alle *-frontend Services beinhalten nur statisch kompilierte Webseiten und keine sicherheitskritischen Daten. Eine mögliche Gefahr besteht hier nur im Rahmen einer „Privilege Escalation“, welche Zugriff auf den Container und das Hostsystem geben könnten.
¶ Golang Webserver (*-backend) und Hilfsdienste
Hierbei handelt sich um vorkompilierte Server, welche nicht ohne Weiteres getauscht werden können. Bitte informieren Sie uns umgehen, damit wir den Patch direkt bei uns einspielen können.
¶ Daten
Dynexite funktioniert nach Möglichkeit autark von Fremdsystemen und benötigt nur wenig Informationen. Lediglich eine Identifikationsnummer (bei aus auch identifier) wird dringend benötigt.
Dynexite interessiert es dabei nicht, woher diese ID kommt, solange sie einzigartig verwendet wird. Die Verwendung der Hochschulinternen ID ist ratsam, aber nicht notwendig!
¶ Datenfluss
Dieser Bereich wird zurzeit noch überarbeitet
Dieser Abschnitt soll einen möglich einfachen Einblick in den Datenfluss von Dynexite geben. Sie sind an den DFD Standard angelehnt, vereinfachen allerdings die meisten Elemente auf das Wesentliche.
Besondere oder personenbezogene Daten werden nach Möglichkeit geziehlt hervorgehoben.
¶ Orbit
Folgende Informationen wurden weggelassen:
- Aufgabenerstellung und -verwaltung
- Klausurkonstruktion
- Profil-Management
- Administrative Funktionen
¶ Satellite
¶ Netzwerkdiagram
Da sich der Aufbau von Dynexite sehr stark ändern kann, sind wir zu dem Punkt gekommen, an dem es nicht hilfreich wäre ein detailiertes Diagram zur Verfügung zu stellen.
Bitte werfen sie einen Blick auf Aufbau und Struktur um einen Einblick in die allgemeine Deployment-Struktur von Dynexite zu erhalten.
¶ FAQ
Wie ist das Verhalten im Falle eines Fehlers im Betriebssystem?
Wir verwenden eigene Docker Images (z.B. nginx, alpine) als Basis für Dynexite. Diese werden täglich aktualisiert. Im Fall eines kritischen Fehlers können wir auch für ältere Dynexite Versionen unsere Images neu bauen lassen, diese ersetzen dann automatisch das Image in der Docker Registry.
Kann ich selber in die Images eingreifen?
Es ist immer möglich selber an den Images zu arbeiten. Dies erfordert etwas know-how im Bereich Docker (siehe z.B. hier).
Sollten Sie Zugriff auf unsere Repositories haben, so können Sie auch Issues eröffnen, Änderungen an unseren Dockerfiles oder .gitlab-ci-Skripten vornehmen und als Merge-Request bereitstellen!