| ... |
... |
@@ -1,71 +1,160 @@ |
| 1 |
|
-Sicherheit |
| 2 |
|
-Konfigurationen der Umgebung |
| 3 |
|
-Betrieb über HTTPS |
| 4 |
|
-FORMCYCLE sollte, wenn möglich gerade im Internet nur über HTTPS bereitgestellt werden. Dies erhöht die Sicherheit der abgesendeten Daten, sodass diese über Netzwerk-Sniffing nicht mitgelesen oder per Man-in-the-middle manipuliert werden können. Sollte es möglich sein sollte der http-Connector komplett deaktiviert werden. |
| 5 |
|
-Konfiguration von HTTPS: |
| 6 |
|
-https://help.formcycle.de/xwiki/bin/view/Formcycle/SystemSettings/TomcatSettings/Bereitstellung%20%C3%BCber%20HTTPS/ |
| 7 |
|
-Session-Management |
| 8 |
|
-Tracking-Mode |
| 9 |
|
-Standardmäßig wird FORMCYCLE in einer Konfiguration ausgeliefert in der sowohl die Formulare als auch die Verwaltungsoberfläche mit und ohne akzeptierte Cookies betrieben werden kann. Hierfür ist durch die Anwendung keine Einschränkung des Tracking-modes konfiguriert. Sollten keine Cookies akzeptiert werden, so wird die Sitzungs-ID durch den Servlet-Container (z.B. Tomcat) in die URL kodiert. Ist die Benutzung von Cookies in allen gegebenen Anwendungsfällen und Umgebungen möglich, sollte dieses Verhalten abgeändert werden. Hintergrund ist, dass durch eine unachtsam weitergegebene URL mit Sitzungs-ID sonst sogenanntes Session-Hijacking möglich ist und dadurch ein Angreifer unberechtigte Zugriffe erlangen könnte. |
| 10 |
|
-Konfiguration des Session-Trackings: |
| 11 |
|
-https://help.formcycle.de/xwiki/bin/view/Formcycle/SystemSettings/TomcatSettings/#HSession-Tracking |
| 12 |
|
-Cookie-Konfiguration |
| 13 |
|
-Sollte FORMCYCLE ausschließlich über HTTPS betrieben werden ist es empfohlen die entsprechende Einstellung am Cookie zu hinterlegen. Diese verhindert, dass die Cookies bei Aufrufen über HTTP gesetzt und benutzt werden. Sollte FORMCYCLE dennoch über HTTP aufgerufen werden, so greift der ggf. noch vorhandene Fallback mit in der URL kodierten Session-ID. |
| 14 |
|
-Je nach Umgebung und Anwendungsfall ist es möglich die maximale Dauer einer Sitzung zu limitieren. Dies bezieht sich hierbei sowohl auf die Sitzung innerhalb des Formulars, als auch die der Verwaltungsoberfläche. Sobald keine Kommunikation zwischen Browser und Server für den gegebenen Zeitraum mehr stattfindet wird die Sitzung invalidiert. Um dies beim Ausfüllen von großen Formularen oder dem Arbeiten innerhalb der Verwaltungsoberfläche zu umgehen, ist hier ein Keep-Alive-Mechanismus implementiert welcher in Regelmäßigen Abständen ein Lebenszeichen an den Server übermittelt. Sollte nun das Fenster oder der Browser geschlossen werden oder durch z.B. Sperren des Endgerätes nicht mehr aktiv sein, fällt dieser Mechanismus weg und der Benutzer wird nach Ablauf der konfigurierten Zeit abgemeldet. |
| 15 |
|
-Auch lässt sich das Cookie hier weiter anpassen indem z.B. der Standardname oder der Standard-Pfad und die Domäne angepasst wird. |
| 16 |
|
-Konfiguration des Cookies: |
| 17 |
|
-https://help.formcycle.de/xwiki/bin/view/Formcycle/SystemSettings/TomcatSettings/#HCookie-Konfiguration |
|
1 |
+{{info}} |
| 18 |
18 |
|
| 19 |
|
-Härtung der Server |
| 20 |
|
-Alle bei der Kommunikation von FORMCYCLE mit dem Endanwender benutzten Server sollten soweit wie möglich gehärtet werden. Dies bedeutet vor allem, dass neben dem Einspielen regelmäßiger Sicherheitsupdates auch alle unnötigen Zugriffe deaktiviert oder verhindert werden sollten. Auch ist dem Prinzip des „Information hidings“ zu folgen. Dies bedeutet, dass jegliche nicht nötige Information der Infrastruktur nach außen versteckt werden sollte. Diese geben Angreifern sonst Hinweise auf mögliche Angriffsmöglichkeiten. Typtische Informationen und Situationen sind hierbei folgende: |
| 21 |
|
-- Rückgabe des Verwendeten Servers innerhalb von http-Headern. Dies geschieht meist mit Versionsnummern welche den Patch-Stand des Servers preisgibt |
| 22 |
|
-- Ausgabe der Server-Informationen auf Standard-Fehlerseiten |
| 23 |
|
-- Verwendung von erkennbaren Standard-Fehlerseiten welche Rückschlüsse auf den Server geben können |
| 24 |
|
-- Betrieb von Standard-Anwendungen (z.B. der Tomcat Manager) welcher zum einen den Server-Typ preisgibt, zum anderen auch weitere Angriffspunkt liefert |
| 25 |
|
-Einschränkung des Backend-Zugriffs (z.B. über Frontend-Server) |
| 26 |
|
-Sollte es im Anwendungsfall nicht anders vorgesehen sein, so sollte der Zugriff auf die Verwaltungsoberfläche nur intern ermöglicht werden. Dies lässt sich z.B. über Firewalls, Revers-Proxies oder Load-Balancer realisieren. Auch Kann hierfür der Frontend-Server zum Einsatz kommen. Je nach Anwendungsszenario ist dieser komplett ohne Oberfläche oder nur mit Postfach verwendbar. Diese können so z.B. in einer DMZ betrieben werden während der Master-Server inkl. Verwaltungsoberfläche im Intranet betrieben wird. Somit ist die Erstellung/Pflege von Formularen und Daten nur hier möglich während Formulare über den Frontend-Server auch über das Internet benutzt werden können. |
| 27 |
|
-Frontend- und Master-Server: |
| 28 |
|
-https://help.formcycle.de/xwiki/bin/view/Formcycle/SystemSettings/FrontendAndMasterServer |
| 29 |
|
-Proxy, Load-Balancer und co.: |
| 30 |
|
-https://help.formcycle.de/xwiki/bin/view/Formcycle/Installation/IntermediateServers |
| 31 |
|
-Verwendung eines Viren-Scanners |
| 32 |
|
-Um das Entgegennehmen von schädlichen Dateien oder Eingaben zu verhindern ist es empfohlen auf dem entsprechenden FORMCYCLE-Server (Master- und/oder Frontend) einen Virenscanner zu betreiben. Dieser kann auf das FORMCYCLE-Datenverzeichnis konfiguriert werden und sollte alle schädlichen Dateien löschen. FORMCYCLE erkennt anschließend, dass eine eigentlich abgesendete Datei entfernt wurde bzw. leer ist und vermerkt dies innerhalb des Vorgangs in der Übersicht der Uploads. |
| 33 |
|
-Konfigurationen innerhalb von FORMCYCLE |
| 34 |
|
-Verschlüsselung von Formular-Daten/Datenbank |
| 35 |
|
-Es ist empfehlenswert bei der FORMCYCLE-seitigen Verschlüsselung von Daten die Formular-Daten mit zu aktivieren. Dies bringt zwar kaum messbare Performance-Einbußen, verhindert jedoch, dass die Formular-Daten während der Kommunikation mit der Datenbank mitgelesen werden können und dass die Daten ohne Kenntnis des Algorithmuses und Passworts aus der Datenbank selbst ausgelesen werden können. Auch erhöht die Verschlüsselung der kompletten Datenbank durch das verwendete DBMS die Sicherheit im selben Angriffs-Szenario. |
| 36 |
|
-Verschlüsselte Kommunikation mit der Datenbank |
| 37 |
|
-Sollte dies in der bestehenden Umgebung möglich sein oder diese nicht komplett abgesichert sein, ist es empfohlen die Kommunikation mit der Datenbank per SSL zu verschlüsseln. Je nach Datenbankhersteller ist hierfür eine andere Datenbank-URL oder andere Parameter notwendig. Dies verhindert, dass Angreifer mit Zugriff auf die interne Netzwerkstruktur die Kommunikation zwischen FORMCYCLE und der Datenbank mitlesen könnten. |
| 38 |
|
-MS-FS-Kommunikation verschlüsseln |
| 39 |
|
-Sollte ein Frontend-Server benutzt werden ist es empfehlenswert die Kommunikation mit dem Master-Server zu verschlüsseln. Dies wird per SSL-Zertifikat realisiert welches nicht mit dem Zertifikat für die Formular-Auslieferung über HTTPS verwechselt werden sollte. Da dies nicht für die Kommunikation mit dem Anwender sichtbar ist und lediglich als eine Art Passwort dient, ist es hier auch möglich ein selbstgeneriertes Zertifikat zu benutzen. Dies stellt sicher, dass der von Angreifern abgefangene Netzwerk-Verkehr zwischen den Servern nicht lesbar ist. |
| 40 |
|
-Frontend-Server: |
| 41 |
|
-https://help.formcycle.de/xwiki/bin/view/Formcycle/SystemSettings/UserInterface/FrontendServer |
| 42 |
|
-Frontend-Server-Verschlüsselung: |
| 43 |
|
-https://help.formcycle.de/xwiki/bin/view/Formcycle/Installation/FrontendServer |
| 44 |
|
-Login und verschlüsselte Kommunikation mit Mail-Server |
|
3 |
+Die {{formcycle/}} Versionen 7.0.0 bis 7.0.11 enthalten eine Version vom Spring Framework, welche die am 31.03.2022 bekannt gewordene Sicherheitslücke [[CVE-2022-22965>>https://tanzu.vmware.com/security/cve-2022-22965]] enthält. |
|
4 |
+Die {{formcycle/}} Versionen 7.0.0 bis 7.0.6 verwenden eine Version von Log4j, welche die am 10.12.2021 bekannt gewordene Sicherheitslücke [[CVE-2021-44228>>https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228]] enthält. |
|
5 |
+Die {{formcycle/}} Versionen 7.0.0 bis 7.0.7 verwenden wiederum eine Version von Log4j, welche die am 14.12.2021 bekannt gewordene Sicherheitslücke [[CVE-2021-45046>>https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046]] enthält. |
|
6 |
+Die {{formcycle/}} Versionen 7.0.0 bis 7.0.8 verwenden wiederum eine Version von Log4j, welche die am 18.12.2021 bekannt gewordene Sicherheitslücke [[CVE-2021-45105>>https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105]] enthält. |
|
7 |
+Die {{formcycle/}} Versionen 7.0.0 bis 7.0.9 verwenden wiederum eine Version von Log4j, welche die am 11.12.2021 bekannt gewordene Sicherheitslücke [[CVE-2021-44832>>https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832]] enthält. |
|
8 |
+ |
|
9 |
+Momentan kennen wir kein Szenario, bei der diese Sicherheitslücken in {{formcycle/}} ausgenutzt werden können. **Wir empfehlen trotzdem, auf die {{formcycle/}} [[Version 7.0.12>>doc:Blog.WebHome]] zu aktualisieren, die neue Versionen von Log4j und dem Spring Framework verwendet, welche die Sicherheitslücken nicht mehr enthält.** |
|
10 |
+{{/info}} |
|
11 |
+ |
|
12 |
+{{info}} |
|
13 |
+ |
|
14 |
+Für Installationen, bei denen eine Aktualisierung auf die aktuelle {{formcycle/}} Version nicht möglich ist, empfehlen wir die Mitigation für __CVE-2021-44228__ umzusetzen, welche [[vom Hersteller>>https://logging.apache.org/log4j/2.x/security.html]] und [[vom BSI>>https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf?__blob=publicationFile]] für die in den möglicherweise betroffenen {{formcycle/}} Versionen verwendete Log4j-Version empfohlen wird. Diese sieht vor, für den verwendeten Servlet-Container die Option {{code language="none"}}-Dlog4j2.formatMsgNoLookups=true{{/code}} in den Java-Optionen zu setzen. |
|
15 |
+ |
|
16 |
+Für einen unter Windows laufenden Apache Tomcat kann dies beispielsweise im //Tomcat Monitor// an folgender Stelle getan werden: |
|
17 |
+[[image:tomcat_log4j_settings.png||width="350"]] |
|
18 |
+ |
|
19 |
+Unter Linux werden Umgebungsvariablen bei Apache Tomcat Installationen üblicherweise in der Datei {{code language="none"}}setenv.sh{{/code}} gesetzt. Diese könnte nach dem Setzen des Parameters dann zum Beispiel den folgenden Inhalt für die Java-Optionen aufweisen: |
|
20 |
+{{code language="none"}}export JAVA_OPTS="-Dfile.encoding=UTF-8 -Xms1024m -Xmx4096m -Dlog4j2.formatMsgNoLookups=true"{{/code}} |
|
21 |
+ |
|
22 |
+Bei der Verwendung von anderen Servlet-Containern als dem Apache Tomcat konsultieren Sie bitte die Dokumentation dieses Servlet-Containers, an welcher Stelle dieser Parameter übergeben werden kann. |
|
23 |
+ |
|
24 |
+Falls eine Aktualisierung auf die aktuelle {{formcycle/}} Version nicht möglich ist, ist eine Mitigation von __CVE-2021-45046__ & __CVE-2021-45105__ nur dann nötig, wenn manuell Logpattern konfiguriert worden, welche [[betroffene Konfigurationen>>https://logging.apache.org/log4j/2.x/security.html]] enthalten. In diesem Fall sollten die entsprechenden Pattern entfernt werden. |
|
25 |
+{{/info}} |
|
26 |
+ |
|
27 |
+{{content/}} |
|
28 |
+ |
|
29 |
+Für einen möglichst sicheren Betrieb von {{formcycle/}} sind je nach Systemumgebung und Anwendungsfällen verschiedene Konfigurationen möglich bzw. empfohlen. Hierbei ist zu unterscheiden zwischen der Konfiguration der Umgebung wie z.B. des Tomcat-Servers, der ggf. vorgeschaltenen Web-Server, Proxies oder Load-Balancer und der Konfiguration von {{formcycle/}} selbst. |
|
30 |
+ |
|
31 |
+== Konfigurationen der Umgebung == |
|
32 |
+ |
|
33 |
+=== Betrieb über HTTPS === |
|
34 |
+ |
|
35 |
+{{formcycle/}} sollte, wenn möglich gerade im Internet nur über HTTPS bereitgestellt werden. Dies erhöht die Sicherheit der abgesendeten Daten, sodass diese innerhalb des Netzwerks nicht mitgelesen oder per Man-in-the-middle manipuliert werden können. Sollte es möglich sein sollte der HTTP-Connector komplett deaktiviert werden. |
|
36 |
+ |
|
37 |
+Konfiguration von HTTPS innerhalb des Tomcats: [[{{formcycle/}}-Hilfe>>doc:Formcycle.SystemSettings.TomcatSettings.Bereitstellung über HTTPS.WebHome||target="_blank"]] |
|
38 |
+ |
|
39 |
+=== Session-Management === |
|
40 |
+ |
|
41 |
+Für den Betrieb von {{formcycle/}} ist es zwingend nötig, dass der Benutzer sowohl innerhalb der Verwaltungsoberfläche als auch innerhalb des Formulars eine dem Server bekannte Sitzung erhält. Diese muss zum Beispiel zwischen Aufruf und Absenden eines Formulars identisch sein um zum Beispiel eine Prüfung gegen automatisiertes Absenden (z.B. für DoS-Attacken) zu gewährleisten. |
|
42 |
+ |
|
43 |
+==== Tracking-Mode ==== |
|
44 |
+ |
|
45 |
+Standardmäßig wird {{formcycle/}} in einer Konfiguration ausgeliefert in der sowohl die Formulare als auch die Verwaltungsoberfläche mit und ohne akzeptierten Cookies betrieben werden kann. Hierfür ist durch die Anwendung keine Einschränkung des sogenannten Tracking-modes konfiguriert. Sollten keine Cookies akzeptiert werden, so wird die Sitzungs-ID durch den Server (z.B. Tomcat) in die URL geschrieben. Ist die Benutzung von Cookies in allen gegebenen Anwendungsfällen und Umgebungen möglich, sollte dieses Verhalten hierfür angepasst werden. Hintergrund ist, dass durch eine unachtsam weitergegebene URL mit Sitzungs-ID sonst sogenanntes Session-Hijacking, also die ungewollte Übernahme einer Sitzung möglich ist und Angreifer so unberechtigte Zugriffe erlangen könnte. |
|
46 |
+ |
|
47 |
+Konfiguration des Tracking-Modes: [[{{formcycle/}}-Hilfe>>doc:Formcycle.SystemSettings.TomcatSettings.WebHome||anchor="HSession-Tracking" rel="noopener noreferrer" target="_blank"]] |
|
48 |
+ |
|
49 |
+==== Cookie-Konfiguration ==== |
|
50 |
+ |
|
51 |
+Sollte {{formcycle/}} ausschließlich über HTTPS betrieben werden ist es empfohlen das sogenannte //secure//-Flag an Cookies zu aktivieren. Dieses verhindert, dass die Cookies bei Aufrufen über HTTP gesetzt und benutzt werden. Sollte dieses Flag gesetzt werden und {{formcycle/}} dennoch über HTTP aufgerufen werden, so greift der ggf. noch vorhandene Fallback mit der Sitzungs-ID innerhalb der URLs. Sollte wiederrum der Tracking-Mode (siehe oben) wie empfohlen nur Cookies verwenden und bei gesetztem //secure//-Flag ein Aufruf über HTTP erfolgen, ist weder ein Login noch die Benutzung der Verwaltungsoberfläche noch das Erfolgreiche Absenden von Formularen möglich. |
|
52 |
+ |
|
53 |
+Konfiguration des Session-Cookies: [[{{formcycle/}}-Hilfe>>doc:Formcycle.SystemSettings.TomcatSettings.WebHome||anchor="HCookie-Konfiguration" target="_blank"]] |
|
54 |
+ |
|
55 |
+Auch lässt sich das Sitzungs-Cookie hier weitergehend anpassen indem z.B. der Standard-Name, der Standard-Pfad, die Domäne oder auch separat die Gültigkeitsdauer geändert wird. Letztes sollte jedoch immer mit Hinblick auf das maximale Sitzungsdauer geschehen. |
|
56 |
+ |
|
57 |
+==== Session-Timeout ==== |
|
58 |
+ |
|
59 |
+Je nach Umgebung und Anwendungsfall ist es möglich die maximale Dauer einer Sitzung zu limitieren. Dies bezieht sich hierbei sowohl auf die Sitzung innerhalb des Formulars, als auch die der Verwaltungsoberfläche. Sobald keine Kommunikation zwischen Browser und Server für den gegebenen Zeitraum mehr stattfindet wird die Sitzung inklusive aller zugehörigen Daten zerstört. Um dies beim Ausfüllen von großen Formularen oder dem Arbeiten innerhalb der Verwaltungsoberfläche zu umgehen, ist hier ein Keep-Alive-Mechanismus vorhanden welcher in regelmäßigen Abständen ein Lebenszeichen an den Server übermittelt. Sollte nun das Fenster oder der Browser geschlossen werden oder durch z.B. Sperren des Endgerätes nicht mehr aktiv sein, fällt dieser Mechanismus weg und der Benutzer wird nach Ablauf der konfigurierten Zeit abgemeldet. |
|
60 |
+ |
|
61 |
+Konfiguration des Session-Timeouts: [[{{formcycle/}}-Hilfe>>doc:Formcycle.SystemSettings.TomcatSettings.WebHome||anchor="HSession-Timeout" target="_blank"]] |
|
62 |
+ |
|
63 |
+=== Härtung der Server === |
|
64 |
+ |
|
65 |
+Es ist zu empfehlen, dass neben dem eigentlichen Server, auf dem {{formcycle/}} betrieben wird, alle bei der Kommunikation relevanten Server soweit wie möglich zu härten. Dies bedeutet vor allem, dass neben dem Einspielen regelmäßiger Sicherheitsupdates auch alle unnötigen Zugriffe deaktiviert oder verhindert werden sollten. Auch ist dem Prinzip des „Information hiding“ zu folgen. Dies bedeutet, dass jegliche nicht nötige Information der Infrastruktur nach außen versteckt werden sollte. Hintergrund ist, dass diese sonst Angreifern Hinweise auf mögliche Angriffsmöglichkeiten in Form von zum Beispiel eingesetzten Software-Versionen bietet. Typtische Quellen für solche Informationen sind hierbei folgende: |
|
66 |
+ |
|
67 |
+* Rückgabe des verwendeten Servers innerhalb von HTTP-Headern. Dies geschieht meist mit Versionsnummern welche den Patch-Stand des Servers preisgibt |
|
68 |
+* Ausgabe der Server-Informationen auf Standard-Fehlerseiten |
|
69 |
+* Verwendung von erkennbaren Standard-Fehlerseiten welche Rückschlüsse auf den Server geben können |
|
70 |
+* Betrieb von Standard-Anwendungen (z.B. der Tomcat Manager) welcher zum einen den Server-Typ preisgibt, zum anderen selbst auch weitere Angriffspunkt liefert |
|
71 |
+ |
|
72 |
+Details für die Härung des Tomcat-Servers: [[{{formcycle/}}-Hilfe>>doc:Formcycle.SystemSettings.TomcatSettings.Härtung des Servers.WebHome||target="_blank"]] |
|
73 |
+ |
|
74 |
+=== Einschränkung des Backend-Zugriffs (z.B. über Frontend-Server) === |
|
75 |
+ |
|
76 |
+Sollte es im Anwendungsfall nicht anders vorgesehen sein, so sollte der Zugriff auf die Verwaltungsoberfläche nur internen Benutzern ermöglicht werden. Dies lässt sich z.B. über Firewalls, Revers-Proxies oder Load-Balancer realisieren welche die Verwaltungsoberflächen (//http(s):~/~/server/formcycle/ui///) komplett vor Zugriffen aus dem Internet sperren. Auch kann hierfür der Frontend-Server zum Einsatz kommen. Je nach Anwendungsszenario ist dieser komplett ohne Oberfläche oder nur mit Postfach verwendbar. Dieser können so z.B. in einer DMZ betrieben werden während der Master-Server inkl. Verwaltungsoberfläche im Intranet betrieben wird und mit diesem kommuniziert. Somit ist die Erstellung bzw. Pflege von Formularen und Daten nur intern möglich während Formulare über den Frontend-Server auch über das Internet bereitgestellt werden können. |
|
77 |
+ |
|
78 |
+Details über Frontend- und Master-Server: [[{{formcycle/}}-Hilfe>>doc:Formcycle.SystemSettings.FrontendAndMasterServer||target="_blank"]] |
|
79 |
+ |
|
80 |
+Details über den Betrieb hinter Proxy, Load-Balancer oder ähnlichem: [[{{formcycle/}}-Hilfe>>doc:Formcycle.Installation.IntermediateServers||target="_blank"]] |
|
81 |
+ |
|
82 |
+=== Verwendung eines Viren-Scanners === |
|
83 |
+ |
|
84 |
+Um das Entgegennehmen von schädlichen Dateien oder Eingaben zu verhindern ist es empfohlen auf dem entsprechenden {{formcycle/}}-Server (Master- und/oder Frontend) einen Virenscanner zu betreiben. Hierbei gibt es zwei Möglichkeiten: |
|
85 |
+ |
|
86 |
+: Zum einen kann der Virenscanner auf das {{formcycle/}}-Datenverzeichnis konfiguriert werden und sollte somit alle schädlichen Dateien löschen. {{formcycle/}} erkennt anschließend, dass eine eigentlich abgesendete Datei entfernt wurde bzw. leer ist und vermerkt dies innerhalb des Vorgangs in der Übersicht der hochgeladenen Dateien. |
|
87 |
+: Details über die Datenverzeichnisse von {{formcycle/}}: [[{{formcycle/}}-Hilfe>>doc:Formcycle.SystemSettings.TomcatSettings.ChangeDataDirectory||target="_blank"]] |
|
88 |
+ |
|
89 |
+: Zum anderen kann für bestimmte Virenscanner ein [[Virenscanner Plugin>>Formcycle.PluginDocumentation.MalwareScannerPlugins]] verwendet werden, welches den Virenscanner direkt anspricht, um Dateien von ihm überprüfen zu lassen. |
|
90 |
+ |
|
91 |
+ |
|
92 |
+== Konfigurationen innerhalb von {{formcycle/}} == |
|
93 |
+ |
|
94 |
+=== Verschlüsselung von Formular-Daten/Datenbank === |
|
95 |
+ |
|
96 |
+Es ist empfehlenswert bei der {{formcycle/}}-seitigen Verschlüsselung von Daten die Formular-Daten mit einzubeziehen. Dies bringt zwar kaum messbare Performance-Einbußen, verhindert jedoch, dass die Formular-Daten während der Kommunikation mit der Datenbank mitgelesen werden können und dass die Daten ohne Kenntnis des Algorithmuses und Passworts aus der Datenbank selbst ausgelesen werden können. Auch erhöht die Verschlüsselung der kompletten Datenbank durch das verwendete DBMS die Sicherheit im selben Angriffs-Szenario. |
|
97 |
+ |
|
98 |
+Konfiguration der Anwendungsseitigen Datenbank-Verschlüsselung: [[{{formcycle/}}-Hilfe>>doc:Formcycle.SystemSettings.UserInterface.Database||anchor="HDatenverschlFCsselung" target="_blank"]] |
|
99 |
+ |
|
100 |
+=== Verschlüsselte Kommunikation mit der Datenbank === |
|
101 |
+ |
|
102 |
+Es wird empfohlen die komplette Kommunikation mit der Datenbank per SSL zu verschlüsseln. Je nach Datenbankhersteller sind hierfür andere Datenbank-URLs oder spezielle Parameter notwendig. Die Verschlüsselung verhindert, dass Angreifer mit Zugriff auf die interne Netzwerkstrukturen die Kommunikation zwischen {{formcycle/}} und der Datenbank mitlesen können und somit Zugriff auf sensible Daten erhalten. |
|
103 |
+ |
|
104 |
+Konfiguration der Datenbank-Anbindung: [[{{formcycle/}}-Hilfe>>doc:Formcycle.SystemSettings.UserInterface.Database||anchor="HDatenbankverbindung" target="_blank"]] |
|
105 |
+ |
|
106 |
+Weitere Informationen über die Verschlüsselte Kommunikation entnehmen Sie der Dokumentation ihre Datenbank-Herstellers. |
|
107 |
+ |
|
108 |
+=== Verschlüsselte Kommunikation zwischen Master- und Frontend-Server === |
|
109 |
+ |
|
110 |
+Sollte ein Frontend-Server benutzt werden ist es empfehlenswert die Kommunikation mit dem Master-Server zu verschlüsseln. Dies wird per SSL-Zertifikat realisiert welches nicht mit dem Zertifikat für die Formular-Auslieferung über HTTPS verwechselt werden sollte. Da dies nicht bei Kommunikation mit dem Formularbenutzer sichtbar ist und lediglich als eine Art Passwort dient, ist es hier auch möglich ein selbstgeneriertes Zertifikat zu benutzen. Allgemein stellt die Verschlüsselung hier sicher, dass Angreifer mit Zugriff auf den Netzwerk-Verkehr die zwischen dem Master- und Frontend-Server übertragenen Daten nicht mitlesen können. |
|
111 |
+ |
|
112 |
+Anleitung zur Installation des Frontend-Server inkl. SSL: [[{{formcycle/}}-Hilfe>>doc:Formcycle.Installation.FrontendServer||target="_blank"]] |
|
113 |
+ |
|
114 |
+Anleitung zum Einrichten der Frontend-Server-Verbindung inkl. SSL: [[{{formcycle/}}-Hilfe>>doc:Formcycle.SystemSettings.UserInterface.FrontendServer||anchor="HSSL-VerschlFCsselung" target="_blank"]] |
|
115 |
+ |
|
116 |
+=== Login und verschlüsselte Kommunikation mit Mail-Server === |
|
117 |
+ |
| 45 |
45 |
Sofern es möglich ist, sollte bei der Anbindung des Mail-Servers darauf geachtet werden, dass diese per Login geschützt ist und eine verschlüsselte Kommunikation stattfindet. Sollte dies nicht der Fall sein, ist es einem Angreifer mit Zugriff auf die interne Netzwerkstruktur möglich versendete Mails mitzulesen. |
| 46 |
|
-Passwortrichtlinien |
| 47 |
|
-Um einen möglichst sicheren Login für Benutzer zu gewährleisten ist es empfohlen entweder bereits bestehende System-Umgebungen mit entsprechenden Richtlinien (z.B. LDAP) zu verwenden oder für den eigenen Anwendungsfall möglichst sichere Passwort-Richtlinien für Benutzer innerhalb von FORMCYCLE festzulegen. |
| 48 |
|
-Passwort-Richtlinien: |
| 49 |
|
-https://help.formcycle.de/xwiki/bin/view/Formcycle/SystemSettings/UserInterface/General/#HPasswort-Richtlinien |
| 50 |
|
-HTTP Strict Transport Security (HSTS) |
| 51 |
|
-Bei HSTS handelt es sich um einen Netzwerk-Header welcher gesetzt werden kann um die Möglichkeit eines Downgrads auf http zu verringern. Hierbei wird an den Browser der entsprechende Header inkl. Gültigkeitsdauer und der Information ob dieser auch für Subdomains gilt übertragen. Der Browser wird nun bis zum Ablauf der Gültigkeit und ggf. für alle Sub-Domains keinerlei Anfragen über eine unverschlüsselte http-Verbindung aufbauen bzw. gestatten. Sollten Sie FORMCYCLE ausschließlich über HTTPS betreiben ist es empfohlen diese Option zu aktivieren und eine möglichst lange Gültigkeit zu wählen. Auch sollte diese Option für Subdomains benutzt werden. Zu beachten ist jedoch, dass ein gewollter Umstieg auf unverschlüsseltes http bei Benutzern auf Grund dieses Header und dessen Gültigkeit zu Problemen kommen kann. |
| 52 |
|
-HSTS-Konfiguration: |
| 53 |
|
-https://help.formcycle.de/xwiki/bin/view/Formcycle/SystemSettings/UserInterface/General/#HHTTPStrictTransportSecurity28HSTS29 |
| 54 |
54 |
|
| 55 |
|
-Referrer-Policy einschränken |
| 56 |
|
-Die Referrer-Policy gibt an ob und wie die Information der ursprünglich aufgerufenen URL an Unterseiten oder Folgeseiten weitergegeben werden soll. Die bedeutet konkret, dass zum Beispiel die komplette ursprüngliche URL oder auch nur die Domäne (origin genannt) mitgeteilt werden soll. Da die URLs ggf. sicherheitsrelevante Informationen enthalten können, ist es empfohlen die Einstellung so restriktiv wie möglich zu wählen. Der Standardwert „strict-origin-when-cross-origin“ bietet meist ausreichenden Schutz ohne ggf. nötige Funktionalität zu beeinflussen. Er gibt an, dass die alle Informationen innerhalb der selben Domäne komplett geteilt werden und Domän-übergreifend nur die Name der Domäne (der origin) übermittelt wird. Dies passiert wiederrum nur wenn sich das Sicherheits-Level der Übertragung (HTTPS oder http) nicht unterscheidet. |
| 57 |
|
-Einstellung der Referrer-Policy: |
| 58 |
|
-https://help.formcycle.de/xwiki/bin/view/Formcycle/SystemSettings/UserInterface/General/#HReferrer-Policy |
| 59 |
|
-Komplette Dokumentaion: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy |
| 60 |
|
-Systeminterne Beschränkungen |
| 61 |
|
-Die systeminternen Beschränkungen dienen sowohl einer allgemeinen fachlichen aus auch daraus resultieren technischen Limitierung auf verschiedene Teilbereiche. So kann hier global festgelegt werden wie groß Absendung eines Formulars (mit Uploads) insgesamt, als auch wie groß die einzelnen Dateien separat sein dürfen. Hier sollte der möglichst kleinste verwendbare Wert gewählt werden um das System vor übergroßen Dateien oder Anfragen zu schützen. |
|
120 |
+Konfiguration des System-Mail-Server: [[{{formcycle/}}-Hilfe>>doc:Formcycle.SystemSettings.UserInterface.EmailServer||anchor="HSicherheit" target="_blank"]] |
|
121 |
+ |
|
122 |
+Konfiguration von Mandant-Mail-Servern: [[{{formcycle/}}-Hilfe>>doc:Formcycle.UserInterface.Client.Settings||anchor="HMailserverbenutzen" target="_blank"]] |
|
123 |
+ |
|
124 |
+=== Passwortrichtlinien === |
|
125 |
+ |
|
126 |
+Um einen möglichst sicheren Login für Benutzer zu gewährleisten ist es empfohlen entweder bereits bestehende System-Umgebungen mit entsprechenden Richtlinien (z.B. LDAP) zu verwenden oder für den eigenen Anwendungsfall möglichst sichere Passwort-Richtlinien für Benutzer innerhalb von {{formcycle/}} festzulegen. |
|
127 |
+ |
|
128 |
+Konfiguration der Passwortrichtlinien: [[{{formcycle/}}-Hilfe>>doc:Formcycle.SystemSettings.UserInterface.General.WebHome||anchor="HPasswort-Richtlinien" target="_blank"]] |
|
129 |
+ |
|
130 |
+=== HTTP Strict Transport Security (HSTS) === |
|
131 |
+ |
|
132 |
+Bei HSTS handelt es sich um einen HTTP-Header welcher gesetzt werden kann um die Möglichkeit eines Rückfalls auf eine unsichere HTTP-Verbindung zu unterbinden. Hierbei wird an den Browser der entsprechende Header inkl. Gültigkeitsdauer und der Information ob dieser auch für Subdomains gilt übertragen. Der Browser wird nun bis zum Ablauf der Gültigkeit und ggf. für alle Sub-Domains keinerlei Anfragen über eine unverschlüsselte HTTP-Verbindung aufbauen bzw. gestatten. Sollten Sie {{formcycle/}} ausschließlich über HTTPS betreiben ist es empfohlen diese Option zu aktivieren und eine möglichst lange Gültigkeit zu wählen. Auch sollte die Option für das Einbeziehen von Subdomains benutzt werden. Zu beachten ist jedoch, dass ein gewollter Umstieg auf unverschlüsseltes HTTP auf Grund dieses Headers und dessen Gültigkeit bei Benutzern zu Problemen führen könnte. |
|
133 |
+ |
|
134 |
+Konfiguration des HSTS-Headers: [[{{formcycle/}}-Hilfe>>doc:Formcycle.SystemSettings.UserInterface.General.WebHome||anchor="HHTTPStrictTransportSecurity28HSTS29" target="_blank"]] |
|
135 |
+ |
|
136 |
+=== Referrer-Policy einschränken === |
|
137 |
+ |
|
138 |
+Die Referrer-Policy gibt an ob und wie die Information der ursprünglich aufgerufenen URL an Unterseiten oder Folgeseiten weitergegeben werden soll. Die bedeutet konkret, dass zum Beispiel die komplette ursprüngliche URL oder auch nur die Domäne (origin genannt) mitgeteilt werden kann. Da die URLs ggf. sicherheitsrelevante Informationen enthalten können, ist es empfohlen die Einstellung so restriktiv wie möglich zu wählen. Der Standardwert „same-origin“ bietet meist ausreichenden Schutz ohne ggf. nötige Funktionalität zu beeinflussen. Er gibt an, dass alle Informationen nur innerhalb derselben Domäne geteilt werden und Domäne-übergreifend nichts übermittelt wird. |
|
139 |
+ |
|
140 |
+Konfiguration der Refferer-Policy: [[{{formcycle/}}-Hilfe>>doc:Formcycle.SystemSettings.UserInterface.General.WebHome||anchor="HReferrer-Policy" target="_blank"]] |
|
141 |
+ |
|
142 |
+Weitere Informationen und mögliche Werte: [[Mozilla-Hilfe>>url:https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy||rel="noopener noreferrer" target="_blank"]] |
|
143 |
+ |
|
144 |
+=== Systeminterne Beschränkungen === |
|
145 |
+ |
|
146 |
+Die systeminternen Beschränkungen dienen sowohl einer allgemeinen fachlichen, als auch daraus resultierenden technischen Limitierungen innerhalb verschiedener Teilbereiche. So kann hier global festgelegt werden wie groß Absendung eines Formulars (inkl. Uploads) insgesamt, als auch wie groß die einzelnen Dateien separat sein dürfen. Hier sollte der möglichst kleinste verwendbare Wert gewählt werden um das System vor übergroßen Dateien oder Anfragen zu schützen. |
|
147 |
+ |
| 62 |
62 |
Ähnlich verhält es sich bei der Limitierung der maximalen Anzahl an Zeilen einer Datenbank-Abfrage sowie die Größenbeschränkung der einzelnen Datenbankzellen. Ein möglichst geringer Wert verhindert, dass z.B. bei Auswahl- oder AutoComplete-Felden zu viele Zeilen ausgeliefert werden und deswegen die Performance des Servers und des Clients (also des Formulars im Browser) leidet. |
| 63 |
|
-Die dritte Einstellung zum Festlegen der Dateigröße ab welcher Uploads oder auch Formular-Eingaben auf die Festplatte geschrieben werden sollen erlaubt gerade im Zusammenspiel mit einem Viren-Scanner eine Feinjustierung der zu behandelnden Daten. Ein Wert größer 0 führ dazu, dass Formulardaten kleiner als dieser Wert nur innerhalb des Arbeitsspeichers behandelt werden. Dies erhöht tendenziell die Performance beim Absenden des Formulars, erhöht jedoch nachvollziehbarerweise die Auslastung des Arbeitsspeichers. Auch können diese Daten nicht durch einen Datei-basierten Viren-Scanner behandelt werden. Sollte ein Viren-Scanner zum Einsatz kommen oder der zur Verfügung stehende Arbeitsspeicher gering ausfallen, ist es empfohlen diesen Wert auf 0 zu lassen. |
| 64 |
|
-Interne Einschränkungen: https://help.formcycle.de/xwiki/bin/view/Formcycle/SystemSettings/UserInterface/General/#HSysteminterneBeschrE4nkungen |
| 65 |
65 |
|
| 66 |
|
-Automatisches Löschen von Protokolleinträgen |
| 67 |
|
-Da innerhalb des fachlichen Protokolls von FORMCYCLE Fehler während der Verarbeitung protokolliert werden kann es hier dazu kommen, dass z.B. Fehler-Einträge von angebundenen Drittsystemen erfasst werden. Da FORMCYCLE nicht die Kontrolle über deren Inhalt hat und diese aber für die Fehlerbehebung erfasst, ist es empfohlen über die entsprechende Konfiguration das Protokoll regelmäßig zu bereinigen. Auch verhindert dies, dass die Datenbank mit alten, nicht mehr relevanten Einträgen gefüllt wird und je nach System-Limitierung früher oder später voll läuft. |
| 68 |
|
-Konfiguration der autom. Löschen: |
| 69 |
|
-https://help.formcycle.de/xwiki/bin/view/Formcycle/SystemSettings/UserInterface/General/#HAutomatischesLF6schenvonProtokolleintrE4gen |
|
150 |
+Die dritte Einstellung zum Festlegen der Dateigröße ab welcher Uploads oder auch Formular-Eingaben auf die Festplatte geschrieben werden sollen, erlaubt gerade im Zusammenspiel mit einem Viren-Scanner eine Feinjustierung der zu behandelnden Daten. Ein Wert größer 0 führ dazu, dass Formulardaten kleiner als dieser Wert nur innerhalb des Arbeitsspeichers behandelt werden. Dies erhöht tendenziell die Performance beim Absenden des Formulars, erhöht jedoch nachvollziehbarerweise die Auslastung des Arbeitsspeichers. Auch können diese Daten nicht durch einen Datei-basierten Viren-Scanner behandelt werden. Sollte ein Viren-Scanner zum Einsatz kommen oder der zur Verfügung stehende Arbeitsspeicher limitiert sein, ist es empfohlen diesen Wert auf 0 zu belassen. |
| 70 |
70 |
|
|
152 |
+Konfiguration der systeminternen Beschränkungen: [[{{formcycle/}}-Hilfe>>doc:Formcycle.SystemSettings.UserInterface.General.WebHome||anchor="HSysteminterneBeschrE4nkungen" rel="noopener noreferrer" target="_blank"]] |
| 71 |
71 |
|
|
154 |
+=== Automatisches Löschen von Protokolleinträgen === |
|
155 |
+ |
|
156 |
+Da innerhalb des fachlichen Protokolls von {{formcycle/}} Fehler während der Verarbeitung protokolliert werden, kann es hier dazu kommen, dass z.B. Fehlermeldungen von angebundenen Drittsystemen erfasst werden. Da {{formcycle/}} nicht die Kontrolle über deren Inhalt hat und diese aber für die Fehlerbehebung erfasst, ist es empfohlen über die entsprechende Konfiguration das Protokoll regelmäßig zu bereinigen zu lassen. Auch verhindert dies, dass die Datenbank mit veralten, nicht mehr relevanten Einträgen gefüllt wird und je nach System-Limitierung früher oder später vollläuft. |
|
157 |
+ |
|
158 |
+Konfiguration der automatisierten Löschung von Protokolleinträgen: [[{{formcycle/}}-Hilfe>>doc:Formcycle.SystemSettings.UserInterface.General.WebHome||anchor="HAutomatischesLF6schenvonProtokolleintrE4gen" target="_blank"]] |
|
159 |
+ |
|
160 |
+ |
