LeitF SuperXDatenschutz - Versionsgeschichte

Floss am 20. August 2025 um 12:02 Uhr

2025-08-20T12:02:22Z

← Nächstältere Version		Version vom 20. August 2025, 12:02 Uhr
Zeile 4:		Zeile 4:
	{{ImagePara \|imgsrc=icon_lock.svg\|width=80px\|caption=Datenschutz}}		{{ImagePara \|imgsrc=icon_lock.svg\|width=80px\|caption=Datenschutz}}

	Bei Implementierung eines ~~Data Warehouse~~ stellen sich immer auch datenschutzrechtliche Fragen~~. Im~~ Laufe der letzten Jahre und aufgrund der Zusammenarbeit mit der HIS e.G. den Hochschulen und Ministerien gibt ~~das System von vornherein einige~~ Antworten zu den Themen Datensparsamkeit, Transparenz, Datensicherheit und Performanz.		Bei Implementierung eines Datawarehouse stellen sich immer auch datenschutzrechtliche Fragen, die im Laufe der letzten Jahre und aufgrund der Zusammenarbeit mit der HIS e.G., den Hochschulen und den Ministerien an Bedeutung gewonnen haben. Dieser Leitfaden gibt Antworten zu den Themen Datensparsamkeit, Transparenz, Datensicherheit und Performanz.

	=== Datensparsamkeit ===		=== Datensparsamkeit ===

Floss am 20. August 2025 um 11:50 Uhr

2025-08-20T11:50:09Z

Änderungen zeigen

Floss: /* 1.2.4 Keine Anzeige von internen Details bei Fehlermeldungen */

2025-08-20T07:48:10Z

1.2.4 Keine Anzeige von internen Details bei Fehlermeldungen

← Nächstältere Version		Version vom 20. August 2025, 07:48 Uhr
Zeile 76:		Zeile 76:
	Für maximale Sicherheit empfiehlt es sich physikalisch getrennte Server für Apache, Tomcat und die Datenbank zu betreiben. Des Weiteren sollten die Server durch eine Firewall abgeschottet werden, normalerweise steht der Apache-Server in der DMZ.		Für maximale Sicherheit empfiehlt es sich physikalisch getrennte Server für Apache, Tomcat und die Datenbank zu betreiben. Des Weiteren sollten die Server durch eine Firewall abgeschottet werden, normalerweise steht der Apache-Server in der DMZ.

	=== ~~1.2.4~~ Keine Anzeige von internen Details bei Fehlermeldungen ===		===Keine Anzeige von internen Details bei Fehlermeldungen ===
	Schalten Sie den Entwicklungsmodus aus, damit keine detaillierten Fehlermeldungen bei SQL-Abfragen nach außen angezeigt werden.		Schalten Sie den Entwicklungsmodus aus, damit keine detaillierten Fehlermeldungen bei SQL-Abfragen nach außen angezeigt werden.

Zeile 88:		Zeile 88:

	Editieren Sie anschließend $WEBAPP/WEB-INF/web.xml und fügen an das Ende der Datei (also vor dem Endtag </web-app>) folgenden Abschnitt ein:		Editieren Sie anschließend $WEBAPP/WEB-INF/web.xml und fügen an das Ende der Datei (also vor dem Endtag </web-app>) folgenden Abschnitt ein:
			<source lang="xml">
	<error-page>		<error-page>

	<error-code>500</error-code>		<error-code>500</error-code>

	<location>/error.htm</location>		<location>/error.htm</location>
			</error-page>
			</source>

	~~</error-page>~~

	=== 1.2.5 Sperren der DBFORMS-Komponente ===		=== 1.2.5 Sperren der DBFORMS-Komponente ===
	Die DBFORMS-Komponente des XML-Frontends dient nur der Datenbankadministration und kann daher in Produktivsystemen mit WWW-Anbindung [http://www.superx-projekt.de/doku/kern_modul/admin/f_SperrenderDBFORMS-Komponente.htm deaktiviert] werden. Damit sind von außen keine Datenbankverbindungen mehr möglich.		Die DBFORMS-Komponente des XML-Frontends dient nur der Datenbankadministration und kann daher in Produktivsystemen mit WWW-Anbindung [http://www.superx-projekt.de/doku/kern_modul/admin/f_SperrenderDBFORMS-Komponente.htm deaktiviert] werden. Damit sind von außen keine Datenbankverbindungen mehr möglich.

Floss am 20. August 2025 um 07:46 Uhr

2025-08-20T07:46:52Z

← Nächstältere Version		Version vom 20. August 2025, 07:46 Uhr
Zeile 112:		Zeile 112:
	<source lang="xml">		<source lang="xml">
	<init-param>		<init-param>

	<param-name>referer_start</param-name>		<param-name>referer_start</param-name>

	<param-value>https://webserver/superx</param-value>		<param-value>https://webserver/superx</param-value>

	</init-param>		</init-param>
	</source>		</source>
Zeile 127:		Zeile 124:

	In Tomcat muss in der Datei $TOMCAT_HOME/conf/web.xml im folgenden Abschnitt der Eintrag für listings auf false gesetzt werden.		In Tomcat muss in der Datei $TOMCAT_HOME/conf/web.xml im folgenden Abschnitt der Eintrag für listings auf false gesetzt werden.
			<source lang="xml">
	<servlet>		<servlet>

	<servlet-name>default</servlet-name>		<servlet-name>default</servlet-name>

	<servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>		<servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>

	<init-param>		<init-param>

	<param-name>debug</param-name>		<param-name>debug</param-name>

	<param-value>0</param-value>		<param-value>0</param-value>

	</init-param>		</init-param>

	<init-param>		<init-param>

	<param-name>listings</param-name>		<param-name>listings</param-name>

	<param-value>'''false'''</param-value>		<param-value>'''false'''</param-value>

	</init-param>		</init-param>

	<load-on-startup>1</load-on-startup>		<load-on-startup>1</load-on-startup>

	</servlet>		</servlet>
			</source>
	=== 1.2.9 Kontrolle von (fehlerhaften) Anmeldungen ===		=== 1.2.9 Kontrolle von (fehlerhaften) Anmeldungen ===
	Kontrollieren Sie die Tabelle protokoll auf Häufung von Fehlanmeldungen (proto_fkt_id=2), z.B. per cron-job.		Kontrollieren Sie die Tabelle protokoll auf Häufung von Fehlanmeldungen (proto_fkt_id=2), z.B. per cron-job.

	Wenn Sie zusätzlich erfolgreiche Anmeldungen loggen wollen, setzen Sie den Eintrag "Erweitertes Protokoll" in der konstanten-Tabelle auf apnr=1 und starten Sie Tomcat neu.		Wenn Sie zusätzlich erfolgreiche Anmeldungen loggen wollen, setzen Sie den Eintrag "Erweitertes Protokoll" in der konstanten-Tabelle auf apnr=1 und starten Sie Tomcat neu.

Floss: /* 1.2.7 Kontrolle des Referers */

2025-08-20T07:40:43Z

1.2.7 Kontrolle des Referers

← Nächstältere Version		Version vom 20. August 2025, 07:40 Uhr
Zeile 115:		Zeile 115:
	<param-name>referer_start</param-name>		<param-name>referer_start</param-name>

	<param-value~~><nowiki~~>https://webserver/superx~~</nowiki>~~</param-value>		<param-value>https://webserver/superx</param-value>

	</init-param>		</init-param>

Floss: /* 1.2.7 Kontrolle des Referers */

2025-08-20T07:39:30Z

1.2.7 Kontrolle des Referers

← Nächstältere Version		Version vom 20. August 2025, 07:39 Uhr
Zeile 110:		Zeile 110:
	Um diese Funktion zu aktivieren, fügen Sie den folgenden Abschnitt als zusätzlichen Parameter zum SuperXManager-Servlet in der $WEBAPP/WEB-INF/web.xml hinzu:		Um diese Funktion zu aktivieren, fügen Sie den folgenden Abschnitt als zusätzlichen Parameter zum SuperXManager-Servlet in der $WEBAPP/WEB-INF/web.xml hinzu:

			<source lang="xml">
	<init-param>		<init-param>

Zeile 117:		Zeile 118:

	</init-param>		</init-param>
			</source>

Floss am 19. Juli 2025 um 12:41 Uhr

2025-07-19T12:41:02Z

← Nächstältere Version		Version vom 19. Juli 2025, 12:41 Uhr
Zeile 1:		Zeile 1:


	== 1.1 Einleitung ==		== 1.1 Einleitung ==
			{{ImagePara \|imgsrc=icon_lock.svg\|width=80px\|caption=Datenschutz}}

	Bei Implementierung eines Data Warehouse stellen sich immer auch datenschutzrechtliche Fragen. Im Laufe der letzten Jahre und aufgrund der Zusammenarbeit mit der HIS e.G. den Hochschulen und Ministerien gibt das System von vornherein einige Antworten zu den Themen Datensparsamkeit, Transparenz, Datensicherheit und Performanz.		Bei Implementierung eines Data Warehouse stellen sich immer auch datenschutzrechtliche Fragen. Im Laufe der letzten Jahre und aufgrund der Zusammenarbeit mit der HIS e.G. den Hochschulen und Ministerien gibt das System von vornherein einige Antworten zu den Themen Datensparsamkeit, Transparenz, Datensicherheit und Performanz.

Floss: Die Seite wurde neu angelegt: „ == 1.1 Einleitung == Bei Implementierung eines Data Warehouse stellen sich immer auch datenschutzrechtliche Fragen. Im Laufe der letzten Jahre und aufgrund der Zusammenarbeit mit der HIS e.G. den Hochschulen und Ministerien gibt das System von vornherein einige Antworten zu den Themen Datensparsamkeit, Transparenz, Datensicherheit und Performanz. === 1.1.1 Datensparsamkeit === * Das System ist '''modular''' [http://www.superx-projekt.de/f_DerAufbaudesD…“

2025-07-19T11:42:07Z

Die Seite wurde neu angelegt: „ == 1.1 Einleitung == Bei Implementierung eines Data Warehouse stellen sich immer auch datenschutzrechtliche Fragen. Im Laufe der letzten Jahre und aufgrund der Zusammenarbeit mit der HIS e.G. den Hochschulen und Ministerien gibt das System von vornherein einige Antworten zu den Themen Datensparsamkeit, Transparenz, Datensicherheit und Performanz. === 1.1.1 Datensparsamkeit === * Das System ist '''modular''' [http://www.superx-projekt.de/f_DerAufbaudesD…“

Neue Seite

== 1.1 Einleitung ==
Bei Implementierung eines Data Warehouse stellen sich immer auch datenschutzrechtliche Fragen. Im Laufe der letzten Jahre und aufgrund der Zusammenarbeit mit der HIS e.G. den Hochschulen und Ministerien gibt das System von vornherein einige Antworten zu den Themen Datensparsamkeit, Transparenz, Datensicherheit und Performanz.

=== 1.1.1 Datensparsamkeit ===

* Das System ist '''modular''' [http://www.superx-projekt.de/f_DerAufbaudesDataWarehouse.htm#Aufbau aufgebaut], die Hochschule kann einzelne Komponenten nutzen oder eben nicht. Wer z.B. die Studierendenverwaltung nutzt, aber keine Personalverwaltung, kann dies leicht durch Installation / Deinstallation von Komponenten tun.
* Das System liefert fertige '''Schnittstellen''' zu den HIS-Systemen bzw. konkrete Schnittstellenbeschreibungen für Nicht-HIS-Systeme. Es werden in der Regel nur die Tabellen entladen, die auch in den Berichten ausgewertet werden. Die Aufforderung zum Entladen kommt dabei von den Hopchschulen, d.h. der Bedarf steuert das System.
* Darüber hinaus wird i.d.R. der '''Personenbezug''' bei den Daten entfernt.
** Bei Studierenden z.B. wird nicht der Personenname entladen, und die Matrikelnummer kann [http://www.superx-projekt.de/doku/sos_modul/admin/f_EntladenunterPostgre.htm pseudonymisiert] werden.
** Bei der [http://www.superx-projekt.de/doku/fin_modul/admin/f_Einrichtung.htm Finanz-Komponente] können personenbezogene Daten wie Zahlungspartnernummer oder Verwendungszweck entfernt werden.
** Eine Ausnahme ist die Personal Komponente, dort kann die Hochschule auch personenbezogene Daten laden, wenn diese in Berichten genutzt werden. Auch hier sind aber spezielle Pseudonymisierungs- und [http://www.superx-projekt.de/doku/sva_modul/admin/f_EinrichtungderEntlad.htm Anonymisierungsfunktionen] enthalten.
* Bei Entfernung des Personenbezugs von Daten durch Pseudonymisierung und Anonymisierung findet dies bereits '''beim Entladen''' aus dem Vorsystem statt, d.h. die personenbezogenen Daten verlassen das Vorsystem nicht.
* Alle Datenbereiche lassen sich '''zeitbezogen''' entladen, z.B. Startjahr oder Startsemester. Bei der Personal-Komponente gibt es darüber hinaus spezielle [http://www.superx-projekt.de/doku/sva_modul/admin/f_Konstanten.htm Löschungskonzepte].
* Um die DSGVO Richtlinien zu erfüllen, empfiehlt es sich keine IP Adressen im Apache oder Tomcat mit zu loggen. Um die IP Adressen zu anonymisieren, gibt es [http://www.superx-projekt.de/doku/kern_modul/admin/f_IPAdressenausLogdateienlschen.htm hier] ein paar Hinweise.

=== 1.1.2 Datensicherheit ===

* Die [http://www.superx-projekt.de/f_ArchitekturvonSuperX.htm Serverarchitektur] bedingt, dass kein Anwender eine '''direkte Datenbankverbindung''' bekommt, d.h. die Gefahr von Missbrauch ist geringer als bei älteren Client-Server-Anwendungen.
* Das Vorsystem muss nicht unbedingt eine '''Online-Verbindung''' zum Data Warehouse bieten, die Daten können in festgelegten Rhythmen zum DWH kopiert werden.
* [http://www.superx-projekt.de/f_NutzerverwaltunginSuperX.htm Nutzerverwaltung] des Systems prüft bei jedem http-Zugriff die '''Rechte''' des angemeldeten Benutzers in Bezug auf Berichte, Institutionen innerhalb der Berichte, und [http://www.superx-projekt.de/doku_his/kern_modul/admin/f_VerwaltungundRechtev.htm Hierarchien] innerhalb der Berichte. Siehe auch das [http://www.superx-projekt.de/doku/kern_modul/admin/f_Benutzerbearbeiten.htm Administrationshandbuch].
* Passworte werden '''verschlüsselt''' bzw. als Hash gespeichert.
* Die Abschottung des Data Warehouse obliegt der '''IT-Abteilung''', es gibt konkrete Anleitungen zur [http://adminhandbuch.superx-projekt.de/ Implementation] des Systems. Darüber hinaus gibt es eine Checkliste für spezielle [http://www.superx-projekt.de/doku_his/kern_modul/admin/f_Sicherheitsmassnahme.htm Sicherheitsmaßnahmen].

=== 1.1.3 Transparenz ===

* Zunächst einmal ist es ein Vorteil, dass das System '''standardisierte Schnittstellen''' zum Vorsystem nutzt. Dies ist eine Vorbedingung für Transparenz. Sobald die Hochschule eigene Schnittstellen erstellt, muss sie die Transparenz mit aufwändigen Eigenmitteln herstellen. Aufwändigere Funktionen wie stichtagsbasiertes Entladen oder Pseudonymisierung sind nur schwer aus eigener Kraft zu implementieren.
* Generell ist der '''Quellcode''' der Schnittstellen offengelegt, d.h. jede Person mit SQL-Kenntnissen kann sich einen Überblick verschaffen.
* Da dieser Zugang für Nicht-Programmierer mühsam ist, gibt es darüber hinaus spezielle '''Webseiten''' zur Schnittstellendokumentation:
** Dokumentation des '''Entladescripts''', z.B. [http://www.superx-projekt.de/doku/sva_modul/sva_unload.html Personal-Komponente]
** Dokumentation des '''Datenmodells''' in SuperX, z.B. [http://www.superx-projekt.de/doku/sva_modul/sva.html Personal-Komponente]
** Dokumentation der '''Schnittstelle''', z.B. [http://www.superx-projekt.de/doku/sva_modul/sva_load.html Personal-Komponente].
* Die Dokumentationen werden '''automatisch''' aus den Quellen [http://www.superx-projekt.de/doku/kern_modul/adminhandbuch/html/f_ModulscripteimKernmo.htm erzeugt] und sind daher immer aktuell.

=== 1.1.4 Performanz und Verfügbarkeit ===
Das System muß eine hohe '''Verfügbarkeit''' bieten, d.h. Anwender müssen schnell Ergebnisse bekommen können.

* Daher laufen wichtige, aber zeitaufwändige Transformation scriptgesteuert in der '''Nacht'''. Beispielscripte liegen dafür vor, z.B. in der [http://www.superx-projekt.de/doku/sva_modul/admin/f_EinladenderSVADaten.htm Personal-Komponente].
* Dazu gibt es u.a. die Möglichkeit des [http://www.superx-projekt.de/doku/kern_modul/admin/f_AusbaustufeneinerSuperX-Implementierung.htm Lastausgleichs] oder der Datenbank-Replikation. Dies sind allerdings keine Leistungsmerkmale des Systems, sondern von den zugrunde liegenden Technologien (Apache, Tomcat, DBMS). In dem System werden aber [http://www.superx-projekt.de/doku/kern_modul/admin/f_EinrichtungvonLoadBalancing.htm Beispielkonfigurationen] mitgeliefert.
* Auch für [http://www.superx-projekt.de/doku/kern_modul/admin/f_TomcatalsDienstunterLinux.htm Diensteinrichtung], Datenbankwartung und [http://www.super-ics.de/superx/doku/kern_modul/adminhandbuch/html/f_JavaMonitoringmitJCo.htm Server-Neustart] werden '''Beispielscripte''' mitgeliefert.
* Das '''Logging''' ist transparent und kann speziell [http://www.superx-projekt.de/doku/kern_modul/admin/f_berwachungundPerformancederWebanwendung.htm gesteuert] werden.

== 1.2 Checkliste Sicherheitsmassnahmen ==
Um die Datensicherheit zu verbessern, empfehlen wir folgende Massnahmen:

=== 1.2.1 SSL-Verschlüsselung mit Zertifikat von Trustcenter ===
Generell sollten Sie den Server immer mit SSL-Verschlüsselung betreiben, egal ob über Tomcat oder Apache.

Es wird an [http://www.superx-projekt.de/doku/kern_modul/admin/f_EinrichtenvonSSLbeimApachexunterLinux.htm anderer Stelle] beschrieben, wie Sie ein Zertifikat selbst erstellen können, dies sollte nur zu Testzwecken dienen. Lassen Sie stattdessen ein persönliches Zertifikat durch einen kommerziellen Zertifizierungsserver publizieren. Akkreditierte Anbieter von qualifizierten Zertifikaten gemäß Deutschem Signaturgesetz sind die AuthentiDate International AG, verschiedene Bundesnotarkammern, D-TRUST (Bundesdruckerei-Gruppe), DATEV, Deutsche Post, TC Trustcenter, T-Systems und S-Trust Sparkassen-Finanzgruppe.

=== 1.2.2 Einstellungen zur Passwortsicherheit ===
Bitte folgen Sie den Empfehlungen von [http://www.zendas.de/ Zendas] zur [http://www.superx-projekt.de/doku/kern_modul/admin/f_EinstellungenzurPasswortsicherheit192.htm Passwortsicherheit]. Die Zentrale Datenschutzstelle der baden-württembergischen Universitäten macht folgende Empfehlung:

: {| class="wikitable"
|Passwortgültigkeit (Tage)
|90-180
|-
|Passwort Groß- u. Kleinb.
|1
|-
|Passwort erfordert Ziffer
|1
|-
|Passwortlänge (Minimum)
|8
|}

Diese Einstellungen können in der Konstanten-Tabelle geändert werden.

Der Administrator kann erzwingen, dass der Benutzer sein Passwort ändern muss, indem er im XML-Frontend den entsprechenden User bearbeitet und bei "User muss Passwort ändern" ein Häkchen setzt.

=== 1.2.3 Servertrennung für maximale Sicherheit ===
Für maximale Sicherheit empfiehlt es sich physikalisch getrennte Server für Apache, Tomcat und die Datenbank zu betreiben. Des Weiteren sollten die Server durch eine Firewall abgeschottet werden, normalerweise steht der Apache-Server in der DMZ.

=== 1.2.4 Keine Anzeige von internen Details bei Fehlermeldungen ===
Schalten Sie den Entwicklungsmodus aus, damit keine detaillierten Fehlermeldungen bei SQL-Abfragen nach außen angezeigt werden.

Setzen Sie in $WEBAPP/WEB-INF/db.properties „developmentMode“ auf „false“.

Eine weitere Verschleierungstechnik stellt das Aktivieren einer eigenen allgemeinen Fehlermeldung dar. Dadurch soll verhindert werden, das weitere Details – wie zum Beispiel der Java-Stacktrace – angezeigt wird. Richten Sie dafür eine Html-Datei error.htm ein, in der könnte zum Beispiel stehen:

"Es ist ein Fehler aufgetreten. Bitte wenden Sie sich an admin@universitaet.de"

Editieren Sie anschließend $WEBAPP/WEB-INF/web.xml und fügen an das Ende der Datei (also vor dem Endtag </web-app>) folgenden Abschnitt ein:

<error-page>

<error-code>500</error-code>

<location>/error.htm</location>

</error-page>

=== 1.2.5 Sperren der DBFORMS-Komponente ===
Die DBFORMS-Komponente des XML-Frontends dient nur der Datenbankadministration und kann daher in Produktivsystemen mit WWW-Anbindung [http://www.superx-projekt.de/doku/kern_modul/admin/f_SperrenderDBFORMS-Komponente.htm deaktiviert] werden. Damit sind von außen keine Datenbankverbindungen mehr möglich.

Eine Abschaltung der DBFORMS beeinträchtigt in keiner Weise die "normalen" Funktionen zur Berichtserstellung. Wenn die DBFORMS-Komponente benötigt wird, kann eine Installation der betreffenden Module in einem separaten Tomcat auf einem lokalen oder besonders geschützten System stattfinden, wo die DBFORMS dann freigeschaltet werden können.

=== 1.2.6 Logging von Aktivitäten im Adminbereich (dbforms) ===
Das Logging für DBFORMS wird in der Datei $WEBAPP/WEB-INF/log4j.properties festgelegt. Passen Sie die Datei entsprechend Ihrer Erfordernisse an.

=== 1.2.7 Kontrolle des Referers ===
Zur Steigerung der Sicherheit kann eingestellt werden, dass bei aufgerufenen Links kontrolliert wird, ob auch ein bestimmter Referer im Request-Parameter enthalten ist.

Um diese Funktion zu aktivieren, fügen Sie den folgenden Abschnitt als zusätzlichen Parameter zum SuperXManager-Servlet in der $WEBAPP/WEB-INF/web.xml hinzu:

<init-param>

<param-name>referer_start</param-name>

<param-value><nowiki>https://webserver/superx</nowiki></param-value>

</init-param>

Es ist allerdings zu berücksichtigen, dass einige Browser erlauben, die Übermittlung des Referrers zu deaktivieren. Auch Content-Filter (sowohl im Browser als auch auf Proxys) können entsprechend eingestellt werden. Ein Aufruf mittels IP-Nummer statt Rechnername würde ebenfalls dann fehlschlagen.

=== 1.2.8 Directory-Listing in Tomcat/Apache abschalten ===
Kontrollieren Sie, dass die Funktion Directory-Listing sowohl im Apache als auch im Tomcat abgeschaltet ist.

In Tomcat muss in der Datei $TOMCAT_HOME/conf/web.xml im folgenden Abschnitt der Eintrag für listings auf false gesetzt werden.

<servlet>

<servlet-name>default</servlet-name>

<servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>

<init-param>

<param-name>debug</param-name>

<param-value>0</param-value>

</init-param>

<init-param>

<param-name>listings</param-name>

<param-value>'''false'''</param-value>

</init-param>

<load-on-startup>1</load-on-startup>

</servlet>

=== 1.2.9 Kontrolle von (fehlerhaften) Anmeldungen ===
Kontrollieren Sie die Tabelle protokoll auf Häufung von Fehlanmeldungen (proto_fkt_id=2), z.B. per cron-job.

Wenn Sie zusätzlich erfolgreiche Anmeldungen loggen wollen, setzen Sie den Eintrag "Erweitertes Protokoll" in der konstanten-Tabelle auf apnr=1 und starten Sie Tomcat neu.