Zugangssicherheit: Unterschied zwischen den Versionen
Sbiele (Diskussion | Beiträge) |
Sbiele (Diskussion | Beiträge) (→Allgemeines) |
||
(18 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
Zeile 3: | Zeile 3: | ||
#Bereits beim Anlegen eines Mitarbeitenden sollte das Passwort mit einer hohen Komplexität angelegt werden. Auch das Login kann komplex gewählt werden, damit niemand es erraten kann. | #Bereits beim Anlegen eines Mitarbeitenden sollte das Passwort mit einer hohen Komplexität angelegt werden. Auch das Login kann komplex gewählt werden, damit niemand es erraten kann. | ||
− | #Je nach Status des Mitarbeitenden wird der Mitarbeitende nach dem Betreten des TraiNex gegebenenfalls dazu aufgefordert, die Komplexität des Passwortes zu erhöhen. TraiNex zeigt während der Passwort-Definition an, wie sicher es das Passwort einschätzt. Solange der Mitarbeitende der Aufforderung zur Erhöhung der Komplexität nicht nachkommt, wird die Startseite funktionell eingeschränkt. | + | #Je nach Status des Mitarbeitenden wird der Mitarbeitende nach dem Betreten des TraiNex gegebenenfalls dazu aufgefordert, die Komplexität des Passwortes zu erhöhen. TraiNex zeigt während der Passwort-Definition an, wie sicher es das Passwort einschätzt. Solange der Mitarbeitende der Aufforderung zur Erhöhung der Komplexität nicht nachkommt, wird die Startseite funktionell eingeschränkt. Standard-Passwörter wie "123456" oder solche, die den Namen beinhalten, sind nicht zulässig und werden abgelehnt. |
#Jedem Mitarbeitenden sollte nur die benötigte [[Rechte]]stufe und nur die benötigten Funktionen ([[Sonderfunktion]]) zugeordnet werden, die ihm erst danach den lesenden oder schreibenden Zugang zu den speziellen Daten oder Studiengruppen ermöglichen. | #Jedem Mitarbeitenden sollte nur die benötigte [[Rechte]]stufe und nur die benötigten Funktionen ([[Sonderfunktion]]) zugeordnet werden, die ihm erst danach den lesenden oder schreibenden Zugang zu den speziellen Daten oder Studiengruppen ermöglichen. | ||
− | # | + | #Jede TraiNex-Seite wird im SSL-Modus ausgeliefert. Sollte dies nicht der Fall sein, kann auf der Loginseite jeder Nutzer vor einem Login durch Klick auf das Schloss-Icon in den SSL-Modus wechseln. Mitarbeitende mit Sonderfunktionen werden auf der Startseite nochmals aufgefordert, per Mausklick in den SSL-Modus zu wechseln. Im SSL-Modus wird der komplette Datenverkehr hochgradig verschlüsselt. <!--Auf Wunsch kann der Server so eingerichtet werden, dass eine Nutzung ohne SSL unmöglich ist, was bei einigen wenigen Browsern aber zu Problemen führen kann. --> |
− | # | + | #Mitarbeitende mit höheren Rechten können nicht gleichzeitig mit unterschiedlichen IP-Adressen, wie es bei Verschleierungssoftware vorkommt, im System unterwegs sein. Sobald in einer Session die IP wechselt, muss der Nutzer sich erneut einloggen, um arbeiten zu können.[[Datei:autocheck.JPG|300px|thumb|right|Auto-Sicherheits-Check]] |
− | #Auto-Sicherheits-Check: Im Bereich Privat/Passwort können Mitarbeitende mit höherem Status den "Auto-Sicherheits-Check" selber aktivieren. Dies führt dazu, dass das TraiNex jedes Login dieses Mitarbeitenden vergleicht mit dem historischen Login-Verhalten dieses Mitarbeitenden und dem Mitarbeitenden eine E-Mail sendet, sobald eine ungewöhnliche Login-Aktivität beobachtet wurde. Dies könnte zum Beispiel ein Login aus dem Ausland oder ein Login zu einer für den Mitarbeitenden ungewöhnlichen Zeit sein. Der Auto-Sicherheits-Check führt nur zu einer Mail-Warnung und zu keiner funktionellen Einschränkung. (siehe Bild)[[Datei:ipcheck.JPG|300px|thumb|right|TraiNex als LAN-Intranet einrichten bei einem Mitarbeitenden, der nur mit einem Rechner / einer IP arbeitet | + | #Auto-Sicherheits-Check: Im Bereich Privat/Passwort können Mitarbeitende mit höherem Status den "Auto-Sicherheits-Check" selber aktivieren. Dies führt dazu, dass das TraiNex jedes Login dieses Mitarbeitenden vergleicht mit dem historischen Login-Verhalten dieses Mitarbeitenden und dem Mitarbeitenden eine E-Mail sendet, sobald eine ungewöhnliche Login-Aktivität beobachtet wurde. Dies könnte zum Beispiel ein Login aus dem Ausland oder ein Login zu einer für den Mitarbeitenden ungewöhnlichen Zeit sein. Der Auto-Sicherheits-Check führt nur zu einer Mail-Warnung und zu keiner funktionellen Einschränkung. (siehe Bild)[[Datei:ipcheck.JPG|300px|thumb|right|TraiNex als LAN-Intranet einrichten bei einem Mitarbeitenden, der nur mit einem Rechner / einer IP arbeitet]] |
− | #IP-Restriktionen: Durch den Einsatz von IP-Restriktionen kann das TraiNex von einem WWW-Extranet-System quasi in ein LAN-Intranet-System überführt werden. Dies kann zum Beispiel sinnvoll sein für einen Notenbeauftragten, der innerhalb der Hochschule tagsüber eine feste IP verwendet. Administratoren mit dem Sonderrecht "IP-Restriktionen", sog. IP-Admin, können bei anderen Mitarbeitenden festlegen, dass diese das TraiNex nur betreten dürfen mit bestimmten IP-Adressen. Der IP-Admin würde hierzu auf dem Datenblatt des z.B. Notenbeauftragten zunächst prüfen, welche IP-Adressen zu welcher Zeit bisher verwendet wurden. Danach kann der IP-Admin festlegen, welche IP-Adressen zukünftig für diesen Notenbeauftragten erlaubt sind. Die Eingabe von ("192.3.4" / nicht nachts) bedeutet dabei, dass der Notenbeauftragte alle IP-Adressen verwenden kann, die mit 192.3.4 beginnen, allerdings nicht nachts. Wenn eine Restriktion greift, dann ist für diesen Nutzer keine Hauptnavigation im TraiNex mehr möglich, außer die Buttons Start, Privat und Logout. Auch wird der ungewöhnliche Login in der Logdatei festgehalten. Diese Maßnahme der IP-Restriktion wird von uns empfohlen für Administratoren mit Sonderrechten, die als z.B. Verwaltungsmitarbeitende in einem festen Büro arbeiten | + | #IP-Restriktionen: Durch den Einsatz von IP-Restriktionen kann das TraiNex von einem WWW-Extranet-System quasi in ein LAN-Intranet-System überführt werden. Dies kann zum Beispiel sinnvoll sein für einen Notenbeauftragten, der innerhalb der Hochschule tagsüber eine feste IP verwendet. Administratoren mit dem Sonderrecht "IP-Restriktionen", sog. IP-Admin, können bei anderen Mitarbeitenden festlegen, dass diese das TraiNex nur betreten dürfen mit bestimmten IP-Adressen. Der IP-Admin würde hierzu auf dem Datenblatt des z.B. Notenbeauftragten zunächst prüfen, welche IP-Adressen zu welcher Zeit bisher verwendet wurden. Danach kann der IP-Admin festlegen, welche IP-Adressen zukünftig für diesen Notenbeauftragten erlaubt sind. Die Eingabe von ("192.3.4" / nicht nachts) bedeutet dabei, dass der Notenbeauftragte alle IP-Adressen verwenden kann, die mit 192.3.4 beginnen, allerdings nicht nachts. Wenn eine Restriktion greift, dann ist für diesen Nutzer keine Hauptnavigation im TraiNex mehr möglich, außer die Buttons Start, Privat und Logout. Auch wird der ungewöhnliche Login in der Logdatei festgehalten. Diese Maßnahme der IP-Restriktion wird von uns empfohlen für Administratoren mit Sonderrechten, die als z.B. Verwaltungsmitarbeitende in einem festen Büro arbeiten (siehe Bild). Sinnvoll ist es auch bei Homeoffice, wenn im Homeoffice eine feste IP genutzt wird. |
#Loginfehlversuche werden registriert. Nach einer gewissen Anzahl Fehlversuche wird dem Nutzer eine Warnmail gesendet und nach weiteren Fehlversuchen wird der Zugang für 15 Minuten gesperrt. | #Loginfehlversuche werden registriert. Nach einer gewissen Anzahl Fehlversuche wird dem Nutzer eine Warnmail gesendet und nach weiteren Fehlversuchen wird der Zugang für 15 Minuten gesperrt. | ||
#Komplettverschlüsselung der Passwort-Speicherung: Passwörter werden so gespeichert, dass diese auch bei physischem Tabellenzugriff nicht auslesbar sind (empfohlen von TraiNex und Bundesamt für Sicherheit in der Informationstechnik). | #Komplettverschlüsselung der Passwort-Speicherung: Passwörter werden so gespeichert, dass diese auch bei physischem Tabellenzugriff nicht auslesbar sind (empfohlen von TraiNex und Bundesamt für Sicherheit in der Informationstechnik). | ||
#Session-Identifikation erfolgt via Cookie oder URL-Token. Der Standard bis 2018 waren URL-Token, seit 2019 sind es Cookies (in Kombination mit Token). | #Session-Identifikation erfolgt via Cookie oder URL-Token. Der Standard bis 2018 waren URL-Token, seit 2019 sind es Cookies (in Kombination mit Token). | ||
− | #URL-Bildnamen werden nur gekrypted in URL übergeben und wenn möglich mit Sicherheits-Abgleichs-Variable. | + | #Bilder sind nicht einfach speicherbar, sondern werden dynamisch eingebunden. URL-Bildnamen werden nur gekrypted in URL übergeben und wenn möglich mit Sicherheits-Abgleichs-Variable. |
− | #Captcha-Bildrätsel auf Login-Seite bei Einwahl aus dem Ausland, um automatische Angriffe abzuwehren | + | #[[Captcha]]-Bildrätsel oder Challenge auf Login-Seite bei Einwahl aus dem Ausland, um automatische Angriffe abzuwehren. Blockung von Nutzungsversuchen mit hohem Threat-Score. Blockung/Challenge von Nutzungsversuchen mit hohem OWASP-Score. |
+ | #Rate-Limiting (IP): Wenn von einer IP-Adresse eine bestimmte Anzahl Aufrufe (z.B. 15000) innerhalb 10 Sekunden ausgeführt wird, wird der Aufruf für diese IP-Adresse für eine gewisse Zeit geblockt bzw. es wird eine Aufgabe (Challenge) gestellt. | ||
+ | #Rate-Limiting (Seite): Wenn eine definierte Seite sehr häufig aufgerufen wird innerhalb 60 Sekunden, dann werden den aufrufenden Nutzern browserseitige Warte-Hinweise (Warteschlange) gegeben. | ||
Folgende Features werden auf Anfrage aktiviert/deaktiviert: | Folgende Features werden auf Anfrage aktiviert/deaktiviert: | ||
#Unterscheidung von Groß- und Kleinschreibung beim Passwort für alle Nutzer | #Unterscheidung von Groß- und Kleinschreibung beim Passwort für alle Nutzer | ||
+ | #Passwort-Änderung: Nutzer wird nach 24 Monaten (+/-12 je nach Recht) aufgefordert, sein Passwort zu ändern (Standard und empfohlen). | ||
#Passwort-Export: Deaktivierung des administrativen Passwort-Exportes für Studierende (Standard und empfohlen) | #Passwort-Export: Deaktivierung des administrativen Passwort-Exportes für Studierende (Standard und empfohlen) | ||
#Passwort-Anforderung: Die Passwortanfrage bei "Zugangsdaten vergessen" sendet statt den Zugangsdaten nur einen Rücksetzlink (Standard und empfohlen). | #Passwort-Anforderung: Die Passwortanfrage bei "Zugangsdaten vergessen" sendet statt den Zugangsdaten nur einen Rücksetzlink (Standard und empfohlen). | ||
Zeile 26: | Zeile 29: | ||
Weitere Sicherheitsfunktionen, z.B. bezüglich der Session-Identifikation, SQL-Injektion-Abwehr oder Session-Hijacking sowie Honigtöpfen, sind nur nicht-öffentlich und nur ggf. auf Anfrage zugänglich. Bitte bedenken Sie: Höhere Sicherheitshürden können zu eingeschränkter Nutzungsmöglichkeit des TraiNex führen. Das Sicherheitslevel sollte deshalb mit Trainings-Online abgesprochen, optimiert und geplant werden. Abhängig ist es auch von der gewählten [[Server-Variante]]. Beachten Sie auch den zugehörigen Workshop "Experte SH/Sicherheitskonzepte" unter https://akademie.trainings-online.de | Weitere Sicherheitsfunktionen, z.B. bezüglich der Session-Identifikation, SQL-Injektion-Abwehr oder Session-Hijacking sowie Honigtöpfen, sind nur nicht-öffentlich und nur ggf. auf Anfrage zugänglich. Bitte bedenken Sie: Höhere Sicherheitshürden können zu eingeschränkter Nutzungsmöglichkeit des TraiNex führen. Das Sicherheitslevel sollte deshalb mit Trainings-Online abgesprochen, optimiert und geplant werden. Abhängig ist es auch von der gewählten [[Server-Variante]]. Beachten Sie auch den zugehörigen Workshop "Experte SH/Sicherheitskonzepte" unter https://akademie.trainings-online.de | ||
+ | |||
+ | ==Schwachstellen-Identifikation== | ||
+ | Wenn Sie eine Schwachstelle entdecken, bitte wir um sofortigen Hinweis, damit wir die Schwachstelle beheben können. | ||
+ | |||
+ | ==Verfolgung von Angriffen== | ||
+ | Wir sind verpflichtet, Angriffe auf Hard-/Software zu lokalisieren. Wir unterscheiden zwischen Angriffen von registrierten Nutzern und nicht registrierten Nutzern. Bei Angriffen von registrierten Nutzern nehmen wir zunächst ggf. Kontakt auf zum Kunden. Gem. AGB gilt u.a.: Angriffe auf das System, von innen oder außen, sind unzulässig. Dies gilt auch, falls Angriffe nur zu Übungszwecken durchgeführt werden. [...] Bei einem Verstoß gegen die Nutzer-Pflichten kann dem Nutzer die Bereitstellung von TraiNex entzogen werden. Weitergehende juristische Schritte behält der Betreiber sich ausdrücklich vor, insbesondere zum Schadenersatz. Hinzuweisen ist auf § 202a Strafgesetzbuch: Wer unbefugt sich oder einem anderen Zugang zu Daten, die nicht für ihn bestimmt und die gegen unberechtigten Zugang besonders gesichert sind, [...] wird mit Freiheitsstrafe bis zu drei Jahren oder mit Geldstrafe bestraft. | ||
+ | Bei Angriffen von unregistrierten Nutzern geben wir die technische Daten zur Nachverfolgung ggf. weiter an die zuständigen Strafverfolgungsbehörden, die Schritte zur Identifizierung des Nutzers einleiten sowie automatisch ein Strafverfahren. Dies gilt auch für Angriffe von registrierten Nutzern, die behaupten, den Angriff nicht ausgeführt zu haben. | ||
==TraiNex-Akademie== | ==TraiNex-Akademie== | ||
Zeile 41: | Zeile 51: | ||
==Letzte funktionale Änderungen== | ==Letzte funktionale Änderungen== | ||
+ | *Februar 2024: [[Sicherheit]]: Optimierung des Codes im Hinblick auf [[Server-Variante]] 4 | ||
+ | *Februar 2024: [[Sicherheit]]: Optimierung des Codes zur Abwehr neuer Angriffstechniken | ||
+ | *Januar 2023: [[Zugangssicherheit]]: Optimierung der Navigation im Hinblick auf das Verbot, die "Zurück"-Buttons vom Browser nutzen zu können bei Studierenden | ||
+ | *August 2022: [[Zugangssicherheit]]: Ausblendung der URL-Variablen bei Studierenden/Alumni/Personalverantwortlichen | ||
+ | *August 2022: [[Zugangssicherheit]]: Verbesserte Überprüfung von URL-Variablen, um Manipulationen noch sicherer zu verhindern | ||
*Dezember 2021: Verbesserung der regional abgestuften [[Zugangssicherheit]] durch z.B. [[Captcha]] | *Dezember 2021: Verbesserung der regional abgestuften [[Zugangssicherheit]] durch z.B. [[Captcha]] | ||
− | *August 2020: Aktivierung einer Zusatz-Firewall, um "distributed denial-of-service"-Attacken besser abwehren zu können sowie verdächtige Anfragen automatisch gesondert behandeln zu können | + | *August 2020: Aktivierung einer Zusatz-Firewall, um "distributed denial-of-service"-Attacken besser abwehren zu können sowie verdächtige Anfragen automatisch gesondert behandeln zu können |
*Oktober 2019: Zugangssicherheit/[[Zweifaktor-Authentisierung]]: Neben Papier-Pass-Code-Tabelle nun auch möglich mit der Google-Authenticator-App | *Oktober 2019: Zugangssicherheit/[[Zweifaktor-Authentisierung]]: Neben Papier-Pass-Code-Tabelle nun auch möglich mit der Google-Authenticator-App | ||
*Juli 2019: Umstellung auf Cookie-Session-Identifikation in Kombination mit URL-Token als Standard | *Juli 2019: Umstellung auf Cookie-Session-Identifikation in Kombination mit URL-Token als Standard |
Aktuelle Version vom 18. Juli 2024, 05:46 Uhr
Inhaltsverzeichnis
Allgemeines
Datensicherheit und Datenschutz haben im TraiNex höchste Priorität. Unter Datensicherheit verstehen wir insbesondere, dass wichtige Daten physisch gesichert werden bzw. gesichert werden können und nicht unberechtigt manipuliert werden können. Unter Datenschutz verstehen wir, dass niemand unberechtigt Einsicht nehmen darf auf Daten, für die er keinen Zugriff haben darf oder soll. Dem TraiNex liegt ein Datenschutz- und Datensicherheitskonzept zu Grunde, welches NICHT öffentlich zur Verfügung gestellt wird. Die Zugangssicherheit ist ein wichtiger Teil dieses Konzeptes und betrifft u.a. die Möglichkeiten, die die Mitwirkung der Nutzer erforderlich macht. Insbesondere für Lehrkräfte und Administratoren wurde spezielle Zugangssicherheit realisiert.
- Bereits beim Anlegen eines Mitarbeitenden sollte das Passwort mit einer hohen Komplexität angelegt werden. Auch das Login kann komplex gewählt werden, damit niemand es erraten kann.
- Je nach Status des Mitarbeitenden wird der Mitarbeitende nach dem Betreten des TraiNex gegebenenfalls dazu aufgefordert, die Komplexität des Passwortes zu erhöhen. TraiNex zeigt während der Passwort-Definition an, wie sicher es das Passwort einschätzt. Solange der Mitarbeitende der Aufforderung zur Erhöhung der Komplexität nicht nachkommt, wird die Startseite funktionell eingeschränkt. Standard-Passwörter wie "123456" oder solche, die den Namen beinhalten, sind nicht zulässig und werden abgelehnt.
- Jedem Mitarbeitenden sollte nur die benötigte Rechtestufe und nur die benötigten Funktionen (Sonderfunktion) zugeordnet werden, die ihm erst danach den lesenden oder schreibenden Zugang zu den speziellen Daten oder Studiengruppen ermöglichen.
- Jede TraiNex-Seite wird im SSL-Modus ausgeliefert. Sollte dies nicht der Fall sein, kann auf der Loginseite jeder Nutzer vor einem Login durch Klick auf das Schloss-Icon in den SSL-Modus wechseln. Mitarbeitende mit Sonderfunktionen werden auf der Startseite nochmals aufgefordert, per Mausklick in den SSL-Modus zu wechseln. Im SSL-Modus wird der komplette Datenverkehr hochgradig verschlüsselt.
- Mitarbeitende mit höheren Rechten können nicht gleichzeitig mit unterschiedlichen IP-Adressen, wie es bei Verschleierungssoftware vorkommt, im System unterwegs sein. Sobald in einer Session die IP wechselt, muss der Nutzer sich erneut einloggen, um arbeiten zu können.
- Auto-Sicherheits-Check: Im Bereich Privat/Passwort können Mitarbeitende mit höherem Status den "Auto-Sicherheits-Check" selber aktivieren. Dies führt dazu, dass das TraiNex jedes Login dieses Mitarbeitenden vergleicht mit dem historischen Login-Verhalten dieses Mitarbeitenden und dem Mitarbeitenden eine E-Mail sendet, sobald eine ungewöhnliche Login-Aktivität beobachtet wurde. Dies könnte zum Beispiel ein Login aus dem Ausland oder ein Login zu einer für den Mitarbeitenden ungewöhnlichen Zeit sein. Der Auto-Sicherheits-Check führt nur zu einer Mail-Warnung und zu keiner funktionellen Einschränkung. (siehe Bild)
- IP-Restriktionen: Durch den Einsatz von IP-Restriktionen kann das TraiNex von einem WWW-Extranet-System quasi in ein LAN-Intranet-System überführt werden. Dies kann zum Beispiel sinnvoll sein für einen Notenbeauftragten, der innerhalb der Hochschule tagsüber eine feste IP verwendet. Administratoren mit dem Sonderrecht "IP-Restriktionen", sog. IP-Admin, können bei anderen Mitarbeitenden festlegen, dass diese das TraiNex nur betreten dürfen mit bestimmten IP-Adressen. Der IP-Admin würde hierzu auf dem Datenblatt des z.B. Notenbeauftragten zunächst prüfen, welche IP-Adressen zu welcher Zeit bisher verwendet wurden. Danach kann der IP-Admin festlegen, welche IP-Adressen zukünftig für diesen Notenbeauftragten erlaubt sind. Die Eingabe von ("192.3.4" / nicht nachts) bedeutet dabei, dass der Notenbeauftragte alle IP-Adressen verwenden kann, die mit 192.3.4 beginnen, allerdings nicht nachts. Wenn eine Restriktion greift, dann ist für diesen Nutzer keine Hauptnavigation im TraiNex mehr möglich, außer die Buttons Start, Privat und Logout. Auch wird der ungewöhnliche Login in der Logdatei festgehalten. Diese Maßnahme der IP-Restriktion wird von uns empfohlen für Administratoren mit Sonderrechten, die als z.B. Verwaltungsmitarbeitende in einem festen Büro arbeiten (siehe Bild). Sinnvoll ist es auch bei Homeoffice, wenn im Homeoffice eine feste IP genutzt wird.
- Loginfehlversuche werden registriert. Nach einer gewissen Anzahl Fehlversuche wird dem Nutzer eine Warnmail gesendet und nach weiteren Fehlversuchen wird der Zugang für 15 Minuten gesperrt.
- Komplettverschlüsselung der Passwort-Speicherung: Passwörter werden so gespeichert, dass diese auch bei physischem Tabellenzugriff nicht auslesbar sind (empfohlen von TraiNex und Bundesamt für Sicherheit in der Informationstechnik).
- Session-Identifikation erfolgt via Cookie oder URL-Token. Der Standard bis 2018 waren URL-Token, seit 2019 sind es Cookies (in Kombination mit Token).
- Bilder sind nicht einfach speicherbar, sondern werden dynamisch eingebunden. URL-Bildnamen werden nur gekrypted in URL übergeben und wenn möglich mit Sicherheits-Abgleichs-Variable.
- Captcha-Bildrätsel oder Challenge auf Login-Seite bei Einwahl aus dem Ausland, um automatische Angriffe abzuwehren. Blockung von Nutzungsversuchen mit hohem Threat-Score. Blockung/Challenge von Nutzungsversuchen mit hohem OWASP-Score.
- Rate-Limiting (IP): Wenn von einer IP-Adresse eine bestimmte Anzahl Aufrufe (z.B. 15000) innerhalb 10 Sekunden ausgeführt wird, wird der Aufruf für diese IP-Adresse für eine gewisse Zeit geblockt bzw. es wird eine Aufgabe (Challenge) gestellt.
- Rate-Limiting (Seite): Wenn eine definierte Seite sehr häufig aufgerufen wird innerhalb 60 Sekunden, dann werden den aufrufenden Nutzern browserseitige Warte-Hinweise (Warteschlange) gegeben.
Folgende Features werden auf Anfrage aktiviert/deaktiviert:
- Unterscheidung von Groß- und Kleinschreibung beim Passwort für alle Nutzer
- Passwort-Änderung: Nutzer wird nach 24 Monaten (+/-12 je nach Recht) aufgefordert, sein Passwort zu ändern (Standard und empfohlen).
- Passwort-Export: Deaktivierung des administrativen Passwort-Exportes für Studierende (Standard und empfohlen)
- Passwort-Anforderung: Die Passwortanfrage bei "Zugangsdaten vergessen" sendet statt den Zugangsdaten nur einen Rücksetzlink (Standard und empfohlen).
- Session-Footprint: Mitarbeitende ab einem bestimmten Recht dürfen während einer Session nicht den Browser oder das Betriebssystem wechseln dürfen (digital footprint / Standard und empfohlen).
- Auto-Logout: Der automatische Logout bei Inaktivität loggt den Benutzer nach einer allgemein festgelegten Zeit (z.B. 45 Minuten) automatisch aus. Je höher das Recht des Nutzers, desto kürzer die akzeptierte Inaktivitätszeit (Standard und empfohlen).
- Die AGB verdeutlichen dem Nutzer einen angemessenen Umgang mit TraiNex-Daten (Standard und empfohlen).
- Zweifaktor-Authentisierung, um den Login-Vorgang abzusichern
- Die aktuelle Konfiguration findet sich im Bereich der Logdatei.
Weitere Sicherheitsfunktionen, z.B. bezüglich der Session-Identifikation, SQL-Injektion-Abwehr oder Session-Hijacking sowie Honigtöpfen, sind nur nicht-öffentlich und nur ggf. auf Anfrage zugänglich. Bitte bedenken Sie: Höhere Sicherheitshürden können zu eingeschränkter Nutzungsmöglichkeit des TraiNex führen. Das Sicherheitslevel sollte deshalb mit Trainings-Online abgesprochen, optimiert und geplant werden. Abhängig ist es auch von der gewählten Server-Variante. Beachten Sie auch den zugehörigen Workshop "Experte SH/Sicherheitskonzepte" unter https://akademie.trainings-online.de
Schwachstellen-Identifikation
Wenn Sie eine Schwachstelle entdecken, bitte wir um sofortigen Hinweis, damit wir die Schwachstelle beheben können.
Verfolgung von Angriffen
Wir sind verpflichtet, Angriffe auf Hard-/Software zu lokalisieren. Wir unterscheiden zwischen Angriffen von registrierten Nutzern und nicht registrierten Nutzern. Bei Angriffen von registrierten Nutzern nehmen wir zunächst ggf. Kontakt auf zum Kunden. Gem. AGB gilt u.a.: Angriffe auf das System, von innen oder außen, sind unzulässig. Dies gilt auch, falls Angriffe nur zu Übungszwecken durchgeführt werden. [...] Bei einem Verstoß gegen die Nutzer-Pflichten kann dem Nutzer die Bereitstellung von TraiNex entzogen werden. Weitergehende juristische Schritte behält der Betreiber sich ausdrücklich vor, insbesondere zum Schadenersatz. Hinzuweisen ist auf § 202a Strafgesetzbuch: Wer unbefugt sich oder einem anderen Zugang zu Daten, die nicht für ihn bestimmt und die gegen unberechtigten Zugang besonders gesichert sind, [...] wird mit Freiheitsstrafe bis zu drei Jahren oder mit Geldstrafe bestraft. Bei Angriffen von unregistrierten Nutzern geben wir die technische Daten zur Nachverfolgung ggf. weiter an die zuständigen Strafverfolgungsbehörden, die Schritte zur Identifizierung des Nutzers einleiten sowie automatisch ein Strafverfahren. Dies gilt auch für Angriffe von registrierten Nutzern, die behaupten, den Angriff nicht ausgeführt zu haben.
TraiNex-Akademie
Bitte beachten Sie dazu auch das Schulungsangebot der TraiNex-Akademie und besuchen Sie die Online-Schulung
Sicherheitskonzepte.
Den nächsten Termin erfahren Sie im
Schulungsprogramm unter https://Akademie.Trainings-Online.de
Sonderfunktion
Mit dem Sonderrecht 103 lassen sich IP-Adressen beschränken (notwendig: Recht der Nutzerverwaltung Doz Nr. 38).
Siehe auch
Server-Variante
Captcha
Datenschutzgrundverordnung: DSGVO
Letzte funktionale Änderungen
- Februar 2024: Sicherheit: Optimierung des Codes im Hinblick auf Server-Variante 4
- Februar 2024: Sicherheit: Optimierung des Codes zur Abwehr neuer Angriffstechniken
- Januar 2023: Zugangssicherheit: Optimierung der Navigation im Hinblick auf das Verbot, die "Zurück"-Buttons vom Browser nutzen zu können bei Studierenden
- August 2022: Zugangssicherheit: Ausblendung der URL-Variablen bei Studierenden/Alumni/Personalverantwortlichen
- August 2022: Zugangssicherheit: Verbesserte Überprüfung von URL-Variablen, um Manipulationen noch sicherer zu verhindern
- Dezember 2021: Verbesserung der regional abgestuften Zugangssicherheit durch z.B. Captcha
- August 2020: Aktivierung einer Zusatz-Firewall, um "distributed denial-of-service"-Attacken besser abwehren zu können sowie verdächtige Anfragen automatisch gesondert behandeln zu können
- Oktober 2019: Zugangssicherheit/Zweifaktor-Authentisierung: Neben Papier-Pass-Code-Tabelle nun auch möglich mit der Google-Authenticator-App
- Juli 2019: Umstellung auf Cookie-Session-Identifikation in Kombination mit URL-Token als Standard
- April 2019: Login-Seite: Bei der Anforderung der Zugangsdaten muss aus Gründen der Zugangssicherheit auch ggf. ein Captcha eingegeben werden.
- April 2019: Zugangssicherheit: Optionale Aktivierung der Zweifaktor-Authentisierung
- September 2016: Zugangssicherheit: Verbesserte Komplettverschlüsselung der Passwort-Speicherung