Datenschutz - eStudy-Steckbrief

Aus THM-Wiki
Wechseln zu: Navigation, Suche

In diesem Artikel wird eStudy mit seinen wichtigsten Funktionalitäten vorgestellt. Besonderen Wert wird hierbei den datenschutzrechtlichen Aspekten zugemessen.

Inhaltsverzeichnis

Kurzvorstellung des eStudy-Projekts

eStudy ist eine von Studenten der FH-Gießen-Friedberg entwickelte Lern-, Lehr- und Kollaborationsplattform. Sie steht unter der GNU General Public Lizenz. Der Quellcode ist offen im Projektmanagement-Tool Trac einsehbar. eStudy ist somit vergleichbar mit anderen Lernplattformen wie Moodle, Stud.IP und ILIAS oder die proprietären -plattformen wie WebCT und CLIX.

Mithilfe von eStudy können Studenten und Dozenten mit- oder untereinander kommunizieren. Es besteht die Möglichkeit, Kurse und eCommunities zu erstellen. Ersteres stellt durch (kursinterne) Foren, Fotoforen, Aushänge, Dateien und Links, usw. eine hervorragende Ergänzung zur Präsenzphase zur Verfügung. Der Dozent kann auf einfache Art und Weise nachvollziehbar alle Kursmitglieder kontaktieren, beispielsweise bei kurzfristigen Terminänderungen oder zum Notenversand, wobei bei Letzterem die Note nur temporär gespeichert wird.

Blended Learning (Integriertes Lernen)

Blended Learning beschreibt das Zusammenspiel zwischen Präsenzveranstaltungen und dem autodidaktischen, selbständigen Lernen unter Verwendung der Neuen Medien. Die Herausforderung bei Blended Learning besteht darin, die richtige Mischung zwischen den beiden Formen zu finden und diese funktional aufeinander abzustimmmen.

Häufig verwendete Features und Module

Ein kurzer Überblick über die in eStudy am häufigsten verwendeten Features und Module:

Kurse/eCommunities

Dozenten können Kurse, Studierende eCommunities erstellen. Ersteres stellt eine virtuelle Erweiterung der klassisch in Präsenzphasen veranstalteten Kurse dar. Der Zugang zu Kursen kann offen, halb-offen und geschlossen sein. Der Dozent kann genau skalieren, wie viele und welche Mitglieder in seinen Kurs beitreten. Darüber hinaus kann er die Zustimmung zu einer Kurs-Policy als Voraussetzung zum Beitritt des Kurses festlegen. Je nach Inhalt der Kurs-Policy könnte er damit einstellen, dass der Beitritt zum Kurs als Prüfungsversuch nach der Prüfungsordnung (PO) gewertet wird. Das Nichterreichen des Kursziels wird somit als Fehlerversuch des im Modulhandbuch zugehörigen Scheins gewertet.

eCommunities (im Nachfolgenden "eComs" abgekürzt) werden von Studierenden erstellt, um beispielsweise Lerngruppen zu finden. Durch die Integration von GoogleMaps können Kommilitonen aus der Nähe gefunden und beispielsweise Lerngruppen mit diesen gegründet werden.

Aushang

Über den Aushang können für alle Teilnehmer des Kurses relevante Neuigkeiten (Terminänderungen, Kursbewertungsdetails, usw.) sichtbar veröffentlicht werden. Ein Aushang kann auch an alle Teilnehmer per E-Mail versendet werden. Somit hat der Dozent die Möglichkeit, alle Kursteilnehmer komfortabel und schnell zu erreichen.

eModeration

Die eModeration ist die virtuelle Variante der klassischen Metaplan®-Methode. Mit Hilfe dieser können Umfragen, Diskussionen und Abstimmungen über Beamer und Laptops durchgeführt werden. Diese Art der Durchführung regt die Studierenden, welche zu einem großen Teil über einen eigenen Laptop verfügen, zu einer hohen Interaktion an. Der Dozent tritt hierbei als Moderator auf und lenkt die Diskussion grob in die gewünschte Richtung, um die Studierenden zu neuen Erkenntnissen kommen zu lassen. Die Studierenden haben die Möglichkeit, sofern vom Dozenten erwünscht und freigeschaltet, eigene Karten zu schreiben und diese auf die Moderationspinnwand zu platzieren.

Tiefergehende Informationen finden Sie in der Projektskizze dieses Projekts.

Planspiel

Das Planspiel ist ein rollenbasiertes System, in dem jedes Kursmitglied eine bestimmte Rolle einnimmt. Dies ist zur zielorientierten Durchführung von Projekten sehr hilfreich. Es können verschiedene Phasen mit Deadlines definiert, Dokumente hochgeladen und gereviewt werden. Hierbei steht das Wissen um den Status und dem Fortschritt des Projekts im Fokus. Zeitverzögerungen werden schnell analysiert und es können Maßnahmen, beispielsweise eine Ressourcenverschiebung und Neuzuordnung diverser Kursmitglieder auf eine Phase, ergriffen und umgesetzt werden.

Barrierefreier/mobiler Zugang

Um eStudy mobil nutzen zu können, wurde eStudy2go als alternativer und zudem barrierearmer Zugang entwickelt. Der zunehmend steigende Anteil von Nutzern, welche bequem von unterwegs auf eStudy zugreifen möchten, werden durch diesen Zugang bedient. Die Funktionalitäten wurden auf die Wesentlichen beschränkt, so dass der Benutzer sich schnell einen Überblick über die in eStudy2go angebotenen Module und deren Funktionsumfang verschaffen kann.

(Foto)Forum

Das Forum ist ein zentrales Modul in eStudy, welches asynchron zum Diskutieren genutzt wird. Wie in Internetforen üblich, bietet es die Möglichkeit des Erstellens, der Beantwortung und der Editierbarkeit einzelner Posts. Das Forum wird, wie fast alle Module in eStudy, kurs- und foyerbezogen benutzt. Daraus folgend gibt es pro Kurs ein Forum, welches aber nur in dem Kurs zugänglich ist. Im Foyer, welches keinen Kurs, sondern die virtuelle "Empfangshalle" von eStudy darstellt, können auch Posts in das Forum geschrieben werden, wobei der Sichtbarkeitsbereich alle eStudy-Nutzer umfasst.


Ein Sonderfall zum Forum bietet das Schwesternmodul Fotoforum. In diesem können Bilder hochgeladen, zugeschnitten und diskutiert werden. Es können ganze Galerien erstellt und hochgeladen werden.

Lehrvehikel in BA- und MA-Kursen der Informatik

Nachfolgend werden einige wichtige Lehrvehikel kurz vorgestellt, welche im Rahmen der Bachelor- und Master-Studiengänge (Informatik) angeboten werden.

Web Security

Die Studierenden werden in die Lage versetzt, sichere Webanwendungen zu implementieren. Hierzu werden technische Maßnahmen der Implementierung mit organisatorischen Aspekten verknüpft. Im Rahmen der praktischen Qualitätssicherung auf einem Continuous-Integration-Server erlernen die Studierenden die Evaluierung der ergriffenen Maßnahmen mithilfe von "Hackertools" und Application-Level-Logging. Bei der Implementierung wird darauf geachtet, dass diese nach den Empfehlungen des Bundesamts für Sicherheit (BSI) geschieht.

Nähere Informationen befinden sich in der Modulbeschreibung des Kurses.

Refactoring

Refactoring ist eine Methode, um die Struktur schlecht geschriebener Software zu verbessern, ohne das funktionale Verhalten zu ändern. Die Studierenden kennen diese neue Herangehensweise an die objektorientierte Programmierung, die ihre Selbstsicherheit fördert und die Qualität ihres Codes sichert. Am Ende der praktischen Übungen zur Vorlesung werden sie durch werkzeuggestütztes Refactoring ihre persönliche Code-Produktivität deutlich steigern können. Dabei wird mit der Open-Source-Plattform Eclipse gearbeitet, sowie der Test-First Ansatz mithilfe von PHPUnit weiter verfolgt.


Nähere Informationen befinden sich in der Modulbeschreibung des Kurses.

Methoden des Software-Entwicklungsprozesses (MSP)

Die Studierenden lernen die aktuellen Methoden der industriellen Software-Entwicklung kennen. Der Schwerpunkt liegt auf den agilen iterativen Vorgehensmodellen, besonders den Praktiken von Extreme Programming. Anhand von Fallstudien werden die jeweiligen Konzepte, Phasen, Aufgaben, Rollen und Ergebnistypen praxisnah vermittelt. In Planspielen erfahren die Teilnehmer(innen) die gruppendynamischen Entscheidungsprozesse, die mit der Herstellung von Software im Team verbunden sind.

Nähere Informationen befinden sich in der Modulbeschreibung des Kurses.

Softwaretechnik-Projekt (SWTP)

Weitgehend selbständige Planung und Durchführung eines größeren Softwareentwicklungsprojekts in Kleingruppen von etwa vier Personen. Im einzelnen haben die Teilnehmenden ein Pflichtenheft, einen Grob- und Feinentwurf, eine detaillierte Programmdokumentation, eine Testdokumentation sowie eine Benutzerdokumentation für das zu realisierende Software-Produkt erstellt, Einsicht in die Notwendigkeit einer systematischen Vorgehensweise wie z.B. Projektplanung und -verfolgung, Konfigurationsmanagement, Qualitätssicherung, etc. gewonnen. Sie erkennen und erfahren, dass die Erstellung von Entwicklungsdokumenten, schriftliche Schnittstellenabsprachen (insb. Softwareergonomie) unabdingbare Voraussetzungen für eine arbeitsteilige Vorgehensweise bei der Software-Erstellung sind.


Nähere Informationen befinden sich in der Modulbeschreibung des Kurses.

Web-Basics

Die Studierenden lernen die technologischen Grundlagen der modernen Web-Programmierung kennen. Im Vordergrund stehen (X)HTML, CSS, PHP5 und MySQL für die Programmierung interaktiver datenbankgestützter Websites. Besonderer Wert wird hierbei auf barrierefreies Web-Design, objektorientierte Entwicklung in PHP und testgetriebener Entwicklung mit Unit-Test gelegt.

Nähere Informationen befinden sich in der Modulbeschreibung des Kurses.

Web-Engineering

Web-Engineering versteht sich als Anwendung und Anpassung der Konzepte, Methoden und Werkzeuge der modernen Softwaretechnik auf die ingenieurmäßige Entwicklung von Websystemen. Die Studierenden kennen die spezifischen Probleme bei Planung, Entwicklung und Test webbasierter Softwaresysteme - im Fokus stehen Open-Source-Content-Management-Systeme - und haben die Kompetenz, komplexe Websysteme W3C-konform zu realisieren.

Nähere Informationen befinden sich in der Modulbeschreibung des Kurses.

Web-Applications

Die Studierenden wissen, wie qualitätssichernde Maßnahmen in einem Entwicklungsprojekt einführt, mit Tools umgesetzt und in der Produktion überwacht werden. Am Beispiel eines lastbalancierten Webclusters haben sie komplexe qualitätssichernde Maßnahmen, wie Last- und Performance-Tests, Fernadministrierung und SLA-Monitoring praktisch erprobt.

Nähere Informationen befinden sich in der Modulbeschreibung des Kurses.

QA-Masterprojekte

Automatisierte Qualitätssicherung in Altsystemen

Altsysteme stellen eine besondere Herausforderung für Entwickler dar. Sie basieren typischerweise auf Jahre alte Technologien und Methoden. Dennoch erfüllen sie die Aufgaben der Kunden und könnten daher nur mit einem hohen Kostenaufwand ersetzt werden. Die Entwickler müssen also trotz der technologischen Einschränkungen auf neue Kundenwünsche reagieren können, ohne die bestehenden und erprobten Funktionen zu verändern. Dies erfordert eine disziplinierte Herangehensweise. Vieles davon lässt sich heutzutage jedoch automatisieren. Dazu zählen die Einhaltung von Programmiervorgaben, das Testen der bestehenden Funktionen und das Erstellen von Metriken in einem kontinuierlichen Integrationsprozess, sowie die Langzeitüberwachung von neuen Releases mit einem Staging-System.

eStudy: vom Prototypen zum Produkt

Das Themengebiet zeigt wichtige Aspekte, die für eine Vermarktung von Open-Source-Produkten von besonderer Bedeutung sind. Dazu zählt an erster Stelle die einfache Bedienung der Software und damit verbunden eine schnelle und unkomplizierte Inbetriebnahme. Anforderungen, die sich durch den Vertrieb und das Marketing des Produktes ergeben, werden sich beispielhaft in konkreten softwaretechnischen Implementierungen widerspiegeln. Für das strategische Management wird die Position von der mobilen und barrierearmen Variante von eStudy - eStudy2Go - und eStudy selber am Markt ermittelt. Dadurch entsteht nicht nur ein Bild, das die typischen LMS auf Feature-Ebene vergleicht, sondern die ganzheitliche Durchdringung am Markt darstellt. Es werden Maßnahmen identifiziert, die zu einer höheren Verbreitung von eStudy(2Go) führen können.

Ein weiteres Thema wird das Release Management sein. Hierfür ist das Time-based Verfahren vorgesehen. Regelmäßige Release-Termine sollen der 01.06. und 01.12. eines Jahres sein, um ein neues stabiles Release der Open-Source-Software eStudy zu veröffentlichen. Diese Releases werden sowohl via Ohloh.net, SourceForge oder der neuen eStudy-Projektseite erhältlich sein.

Performanceoptimierung von eStudy

Ein weiterer Arbeitsbereich ist die Optimierung der Performance. Schwerpunkte sind hier die Analyse und Optimierung von Codestrukturen sowie die Anpassung der Datenhaltung. Hierzu werden bekannte Techniken wie z.B. Refactoring angewendet und Code sowie Datenbankanfragen auf Ebene der Datenhaltung und -bereitstellung an die Erfordernisse angepasst. Ziel ist es, den Aufwand, sowohl auf Seiten der Anwendung, als auch auf Datenbankseite weitgehendst zu verringern.

Maßgeblich sind hier nicht nur Reviews und Optimierung von Code auf Verdacht, sondern die Analyse des Laufzeitverhaltens mit Profiling-Tools. Hierdurch ist es möglich, eine objektive Aussage über inperformante Codestrukturen zu treffen.

Neben einer Optimierung der bestehenden Anwendung werden hierbei auch neue Techniken integriert. Als Beispiel kann hier Cachen von Daten dienen, die für einen bestimmten Zeitraum, ohne datenbankseitige Neuanforderung, vorgehalten werden. Dies wird unter dem Aspekt der Datensicherheit durchgeführt. Dazu zählt auch die Abdeckung mit UnitTests vor Änderung und Optimierung von Programmcode.

WAI - Barrierefreier Zugang zu Lernplattformen

Die Lernplattform eStudy, das ebenfalls an der FH verwendete Moodle, sowie die an der Universität in Gießen verwendenden Lernplattformen Stud.IP und ILIAS, wurden bislang nicht vorrangig auf Barrierefreiheit getestet. Sie waren zwar für alle Benutzer in Lehre, Studium und Forschung gedacht, allerdings sind sehbehinderte und blinde Nutzer nicht berücksichtigt worden. Diesem Defizit soll durch dieses Projekt abgeholfen werden.

Dieses Projekt soll das Verhalten unterschiedlichster LMS unter verschiedenen Anwendungsszenarien aufzeigen. Als Anwendungsszenario wird hierbei ein ganz bestimmter Vorgang bezeichnet, wie etwa ein Log-In Vorgang oder das Auffinden eines Beitrags in einem Forum eines bestimmten Kurses.

Jedes Fehlverhalten in exakt dokumentierten Situationen, wie auch jedes korrekte Verhalten, soll ausführlich in Form von Testberichten festgehalten werden. Anhand dieser Dokumentationen sollen dann Verbesserungsvorschläge ausgesprochen werden. Erfolgte Testberichte werden dann den Entwicklern der jeweiligen Lernplattformen zugänglich gemacht, damit diese die nötigen Änderungen vornehmen können.

Datenschutzrechtliche Aspekte von eStudy

Offenheit

Einer der Grundsätze des eStudy-Projekts ist die offene Dokumentation der Softwarearchitektur, der Softwarekonzepte und letztendlich auf niedrigster Ebene der Software-Code.

Datenbankschema

Das Datenbank-Schema ist offen im Trac unter [1] einsehbar.

Quellcode

Ebenso ist der restliche Quellcode im Trac zu finden.

Entwicklungsumgebung als VM

Die komplette Entwicklungsumgebung zum freien Download mit lauffähiger LAMP-Demo in allen Benutzerrollen ist momentan nur aus dem Intranet der FH-Gießen Friedberg erreichbar. Zukünftig soll dies aber auch extern gehostet werden. Die aktuelle Version ist im Wiki-Artikel Howto Virtual eStudy Development zu finden.

No security by obscurity

eStudy möchte keine (scheinbare) höhere Sicherheit durch Geheimhaltung ihrer Quellen und ihres Aufbaus erreichen. Die Philosophie, die eStudy antreibt, hält ein offenes System für sicherer. Der Code kann von jedermann eingesehen werden und sicherheitskritische Fehler bzw. Verbesserungsvorschläge von der hohen Anzahl der Entwickler entdeckt werden.

Datensicherheit

Data-Klasse

eStudy bietet als zentrale Sicherheitsarchitektur die Validierung und Maskierung von Ein- und Ausgaben über die sogenannte DATA-Klasse. Alle Eingaben sollen, bevor sie in die Datenbank geschrieben oder anderweitig verarbeitet werden, auf Schadcode hin geprüft werden. Entsprechend sollen alle Ausgaben, wobei in den meisten Fällen Daten aus der Datenbank gelesen werden, maskiert werden. Für diese Zwecke bietet die Klasse diverse Erkennungsfilter (zum Beispiel für XSS, SQL-Injection, usw).

Darüber hinaus kann geprüft werden, ob eine Zeichenkette ein bestimmtes vorgegebenes Format erfüllt. Diese Validierung existiert für IntegerNumberData (ganzzahliger Wert), FloatNumberData (Fließkommawerte), LoginData (TH-Kennung, speziell für die TH Mittelhesssen) und einige andere Formate. Auf diese Art und Weise kann man überprüfen, ob eine Zeichenkette das erwartete Format enthält.

Die angesprochenen Filter zur Validierung von Benutzereingaben, werden durch Subklassen realisiert. Jede Subklasse repräsentiert einen Datentyp oder ein spezielles Format, zum Beispiel IntegerNumberData, welches eine Ganzzahl darstellt oder EmailData, welche eine E-Mail Adresse darstellt.

Die regulären Ausdrücke der Angriffsvektoren, sowie der Validierungsklassen, sind hart kodiert. D.h. sie werden nicht automatisch aktualisiert und müssen händisch auf den kurzlebigen aktuellen Stand gebracht werden.

Das Benutzen der Maskierungs-/Validierungsfunktionen ist nicht bindend. Es kann über verschiedene Arten und Weisen (ezSQL, PHP, Zend-Framework) direkt in die Datenbank geschrieben und Daten aus dieser herausgelesen werden. Das Datenschutzbewusstsein und das Wissen um die Data-Klasse ist somit eine notwendige Bedingung, damit Ein- und Ausgaben validiert und maskiert werden.

Die schadhaften Aktivitäten eines Benutzers können nur für eine Eingabe festgestellt werden. Im Gegensatz zu dem im nächsten Kapitel vorgestellten IDS (Intrusion Detection System) können Request-übergreifende Angriffe eines Users nicht in eine Relation gebracht werden.

Eine ausführliche Analyse der DATA-Klasse, runter bis auf Methoden-Ebene, befindet sich in diesem Wiki-Artikel.

Intrusion Detection System

Das Intrusion Detection System - abgekürzt IDS - soll durch die Analyse aller Eingaben Angriffe auf das Portal bemerken und diese dem Intrusion Prevention System (IPS) melden. Das IDS scannt alle Eingaben auf bestimmte Angriffsvektoren. Diese Angriffsvektoren können automatisch vom Administrator auf den aktuellsten Stand gebracht werden. Der Administrator kann, je nach Einstellung, unterschiedlich auf Angriffe reagieren. Diese Eskalationsstufen hängen von dem Impact-Wert eines Angriffs ab. Der Impact-Wert ist die vom IDS erstellte Einschätzung der Schwere des Angriffs.

Das IDS kann alle potentiellen Angriffe wahlweise in Dateien oder in die Datenbank (nicht disjunkt) loggen. In der GUI des IDS kann er sich alle potentiellen Angriffe mit dem zugehörigen Angreifer anzeigen lassen. Darüber hinaus hat er die Möglichkeit, eine Whitelist von Parametern zu definieren, die nicht vom IDS erfasst werden. So ist es beispielsweise wichtig, einen bestimmten Post-Wert der Nachricht-Verfassen Funktion nicht zu analysieren. Dieser enthält den Inhalt einer persönlichen Nachricht des Benutzers an einem oder mehre weitere eStudy-Nutzer. In diesem Fall ist die Respektierung der Privatsphäre des Nutzers höher als das Angriffsrisiko zu bewerten.

Intrusion Prevention System

Was passiert bei einem sicheren Angriff? Da es unrealistisch wäre, darauf zu vertrauen, dass der Administrator anhand der Logs einen Angriff in Echtzeit bemerkt, muss über den Einsatz automatisierter Verteidigungsmechanismen nachgedacht werden. Genau das "erledigt" das IPS. Das IPS bietet vier Möglichkeiten einer Reaktion, sogenannten Commands, auf einen potentiellen Angriff.

Log-Command

Bei Ausführung dieses Commands wird der Angriffstext zusammen mit dem angreifenden Benutzer geloggt.

Warn-Command

Der Benutzer bekommt eine Meldung angezeigt, in der er darauf hingewiesen wird, dass er möglicherweise einen Angriff gestartet hat und bei Wiederholung von diesem gesperrt wird.

Mail-Command

Alle Mitglieder der Admininstrator-Gruppe bekommen eine Benachrichtigung über den Angriff.

Ban-Command

Der Benutzer wird auf eine bestimmte oder unbestimmte Zeit verbannt. Beides kann von einem Administrator widerrufen werden.


Alle Commands sind beliebig in einer Aktion (zum Beispiel Ban-Action) kombinierbar. Der Impact, welcher vom IDS errechnet wird, kann hierbei als Schwellenwert für die Ausführung der Aktionen verwendet werden. Das IDS/IPS-System wird in dem im Kurs Web-Security enstandenen Wiki-Artikel ausführlich dezidiert behandelt.

Strong Passwords

Um sicherzugehen, dass Benutzer sichere Passwörter haben, kann der Portalbetreiber Vorgaben geben, die selbst vergebene Passwörter erfüllen müssen. Dazu gehören

  • Die minimale Länge des Passworts kann eingestellt werden
  • Einstellung, ob Zahlen und Sonderzeichen im Passwort enthalten sein müssen
  • Maximale Anzahl Fehlversuche für die Eingabe des Passwortes
  • Dauer der Sperrung bei Erreichen der maximalen Anzahl Fehlversuche (in Minuten). Falls ein Benutzer die Anzahl der erlaubten Fehlversuche überschreitet, wird sein Account für die angegebene Zeit gesperrt.
  • Maximale Anzahl Benutzerbenachrichtigungen wegen zu schwachem Passwort. Falls sich die Vorgaben seitens des Portalbetreibers ändern, kann es passieren, dass die bestehenden Passwörter nicht mehr den Richtlinien entsprechen. In diesem Fall hat Benutzer je nach eingestellten Benutzerbenachrichtigungen Zeit, dass Passwort zu ändern. Bei Nichtänderung nach den eingestellten Richtlinien wird der Account für die eingestellte Zeit gesperrt.
  • Einstellung, ob die LDAP-Passwörter auch auf eStudy-Richtlinien geprüft werden. Da sich Mitglieder auch über den LDAP-Login des Datenverarbeitungszentrums der Technischen Hochschule Mittelhessen anmelden können, kann die Sicherheit des Passworts in deren Zuständigkeit überlassen werden.

Datenauszugs-Modul

Nach § 34 des Bundesdatenschutzgesetzes ist eStudy dazu verpflichtet, auf Nachfrage jedem Mitglied kostenlos eine personenbezogenen Daten anzuzeigen. Für in Hessen beheimatete Unternehmen/Institutionen greift darüber hinaus das hessische Datenschutzgesetz (§ 8 Rechte der Betroffenen), welches dem Benutzer ebenso das Recht auf die Auskunft, Berichtigung und Löschung der von ihm gespeicherten personenbezogenen Daten gibt.

eStudy geht allerdings einen Schritt weiter: Anstatt, wie leider noch viele Unternehmen, nur auch Nachfrage (manuell) einen Datenauszug zu generieren, kann der Benutzer selbständig vollautomatisiert sich einen Datenauszug erstellen lassen.

Durch den modularen Aufbau von eStudy muss bei der Entwicklung von neuen Modulen die API des Datenauszugsmoduls bedient werden, welche die personenbezogenen Daten als solche erkennt und später ausgibt. Die Schnittstelle ist folgendermaßen aufgebaut:

Datenauszugsschnittstelle und Klassenhierarchie


Die Schnittstelle beinhaltet die Methode getUserData(...), welche als Parameter die ID des Benutzers erwartet. Diese wiederum gibt eine Array mit den entsprechenden Benutzerdaten zurück.

Folgende Werte werden von allen Modulen für die Aufbereitung der Informationen verwendet:

  • Identifikationsnummer des Datensatzes
  • Datum
  • Zugehöriger Kurs
  • Kurze Beschreibung des Inhalts
  • Der Inhalt des Datenauszugselement


Die Entwickler müssen das Interface so implementieren, dass die oben aufgeführten Informationen, welche als Konstanten definiert werden müssen, enthalten sind. Dadurch kann das Datenauszugsmodul zum späteren Zeitpunkt sich von jedem Modul, welches personenbezogene Daten speichert, diese holen und in Tabellenform anzeigen. Der Benutzer kann nun sehen, welche Daten über ihn gesspeichert sind und diese an der Stelle, wo er sie erstellt hat, löschen.

Durch diese Vorgehensweise kann der Benutzer ohne großen Aufwand seinen Datenauszug bekommen, ohne das administrative Vorgänge vonnöten wären, was in einer schnelleren und effektiveren Bearbeitung resultiert. Darüber hinaus stärkt der automatisiert erstellte Datenauszug das Vertrauen in das Datenschutz-Bewusstsein von eStudy.

Datensparsamkeit und -vermeidung

Es wird versucht, so wenige personenbezogene Daten wie möglich von dem Benutzer zu erheben. Jene Daten, die erhoben werden, sind absolut zweckgebunden, siehe die Datenschutzbestimmungen der eStudy-Policy.

Zu keinem Zeitpunkt wird die Matrikelnummer, über die ein Studierender hochschulweit eindeutig identifizierbar ist, gespeichert. Nachrichten, die über das Portal versendet werden, werden nach 180 Tagen automatisch gelöscht. Das Mitglied hat allerdings die Möglichkeit, einzelne Nachrichten zu archivieren, womit sie bis zum manuellen Löschen des Mitglieds gespeichert bleiben.

Sichere/zertifizierte E-Mail

Die Mitglieder, insbesondere die Dozenten, von eStudy haben die Möglichkeit, zertifizierte und verschlüsselte E-Mais an einzelne Empfänger zu verschicken.

Motivation

Bevor dieses Feature geschaffen wurde, hatte der Dozent keine Möglichkeiten, Notenlisten seinen Studierenden zu kommen zu lassen. Das resultierte darin, dass Studierende mehrere hundert Kilometer an die TH gefahren sind, um sich den Aushang des Professors anzuschauen oder abfotografierte Aushänge im Umlauf waren. Ebenfalls kam es auch vor, dass der Dozent die Noten per E-Mail (unverschlüsselt) an den Prüfling gesendet hat. Darüber hinaus waren die von den Dozenten verschickten Mails nicht signiert, d.h. es konnte nicht 100%ig festgestellt werden, ob die Mail wirklich von dem Dozenten stammt. Es war möglich, dass diese gefälscht ist und nicht von dem Dozenten stammt.

Diese Vorgehensweisen sind natürlich datenschutzrechtlich sehr bedenklich und führten zu der Idee, durch Zertifikate verschlüsselte E-Mails an die Kursmitglieder senden zu können.

Durchführung

Jede E-Mail, die sicher versendet werden soll, wird mit dem öffentlichen Schlüssel des Empfängers verschlüsselt und mit dem Zertifikat des Absenders signiert. Das Zertifikat, welches den öffentlichen Schlüssel enthält, muss sich der Benutzer vorher in seinem Profil von eStudy erstellen lassen. Alternativ kann er auch ein eigenes Zertifikat hochladen. Ebenso muss sich der Absender für seine Signatur ein Zertifikat vor dem Versand von sicheren E-Mails auf die selbe Art und Weise erstellen.

Jede E-Mail, die nun sicher an einen Empfänger versendet werden soll, wird mit dem öffentlichen Schlüssel seiner Zertifikats verschlüsselt. Eine Manipulation der versendeten E-Mail "unterwegs" oder ein unberechtigtes Mitlesen sind somit ausgeschlossen. Darüber hinaus ist diese Vorgehensweise im Vergleich zur konservativen Methode für Dozenten und Studierende einfacher, konform mit datenschutzrechtlichen Ansprüchen, die Studierende erhalten ihre Noten in kürzerer Zeit und der Dozent weiß, welche Kursmitglieder ihre Kursnote erhalten haben. Durch die Signatur seitens des Absenders ist für den Empfänger sichergestellt, dass die Mail von dem Absender verfasst wurde, da nur dieser den privaten Schlüssel besitzt.

Versand von Noten per sicherer E-Mail

Der Dozent hat die Möglichkeit, sich eine Excel-formatierte Notenliste herunterzuladen, welche die Namen der Kursmitglieder enthält. Diese Liste füllt er anschließend mit der Kursergebnissen aus. Daraufhin lädt er sie im Notenexport-Modul in eStudy hoch, welches daraufhin prüft, welche Mitglieder sich ein Zertifikat erstellt haben und mit dem Empfang ihrer Note per sicherer E-Mail einverstanden sind. 'Nur' nach einer vorher aktiven Einverständnis des Benutzers kann dieser seine Note per sicherer E-Mail empfangen.

Insofern das Kursmitglied sich vorher ein Zertifikat erstellt bzw. hochgeladen hat und mit dem Empfang von der Note per sicherer E-Mail einverstanden ist, wird die E-Mail verschlüsselt an seine Adresse geschickt.

Die Notenliste wird zu 'keiner Zeit' permanent gespeichert - die temporär hochgeladene Datei wird nach Versand der E-Mails unverzüglich gelöscht.

Authentizität des Benutzers

Benutzer, die sich auf eStudy registrieren möchten, können dies auf zwei Arten durchführen: Zum einen können sie sich selbst registrieren, zum anderen können sie die Benutzerkennung, welche sie vom Datenverarbeitungszentrum (DVZ) der TH Mittelhessen erhalten haben, benutzen. Ersteres kommt sehr selten vor, da eStudy hauptsächlich von Mitgliedern (Professoren, Studenten, Mitarbeiter) der TH Mittelhessen genutzt wird.

Durch den zentralen Authentifizierungsdienst CAS (Central Authentication Service) der TH Mittelhessen wird der Benutzer anhand seiner TH-Benutzerkennung authentifiziert.

In beiden Fällen der Anmeldung ist der volle Name, d.h. Vor- und Nachname, für die Mitglieder im gesamten Portal sichtbar. Durch den Verzicht auf Pseudonyme wird das ernsthafte, lehr- und lernförderndes wissenschaftliche Arbeiten gefördert und beispielsweise ausgetragene "Kleinkriege" in Foren weitgehendst verhindert.

Anonymisierungsfunktion

An eStudy arbeiten eine hohe Anzahl von Entwicklern, die für das Refaktorisieren und Kreieren von neuen Modulen zuständig sind. Da die Entwicklung für eStudy testgetrieben erfolgt, d.h. die Funktionalitäten der Module werden durch fest definierte Tests überprüft (worauf auch der Hudson-Server zurückgreift), sind die Entwickler auf produktionsnahe Zustände angewiesen.

Ein Dutzend Testbenutzer reichen dafür nicht aus, da manche Probleme erst bei einer hohen Anzahl von Benutzern und komplexen Verschränkungen beim Zusammenspiel der zahlreichen Module auftreten.

Um den Entwicklern die Möglichkeit der Entwicklung an einer produktionsnahen Test-Plattform zu geben, gibt es das Anonymisierungs-Modul. Dieses erstellt aus den Daten der Datenbank einen komplett anonymisierten Testdaten-Dump. In diesem Dump sind (selbstverständlich) keine personenbezogenen Daten gespeichert. Darüber hinaus verpflichtet sich jeder Entwickler, nach Abschluss seines Projekts den Test-Datendump und die daraus erstellte Datenbank-Tabelle zu löschen.

Projektmanagement-, Bugtracker- und Softwarequalitätmessungs-Tool

Trac

Mit Trac und seiner integrierten Subversion-Schnittstelle können die Entwicklungen im eStudy-Projekt transparent gemacht werden. Die letzten Build-Vorgänge können angezeigt werden und anhand der Commit-Kommentare kann man sich einen schnellen Überblick über den derzeitigen Stand des Projekts machen. Es können Meilensteine definiert werden, um die Entwicklung strukturierter gestalten zu können. Eine weitere wichtige Funktion ist das Bugtracking. Es können Tickets erstellt werden, in denen ein Bug oder ein Feature-Wunsch eingetragen wird. Diesem kann eine gewisse Priorität, Keywords zur Kategorisierung und weitere Informationen zugewiesen werden. Die Entwickler erhalten so eine zentrale Stelle, wo alle Bugs/Features enthalten sind. Gefixte Bugs/erfüllte Featurewünsche können eingetragen werden, womit das Ticket als erledigt gilt.

Nachfolgend die Übersicht über die vergangenen Builds:

Übersicht über vergangene Builds



Nachfolgend die Übersicht von Tickets im Trac:

Tickets im Trac

Software-Metriken im Hudson anzeigen

Für das eStudy-Projekt läuft ein eigener Hudson-Server. Mithilfe diesem Server können Metriken erstellt werden, anhand dessen die Qualität der ausgecheckten Codes automatisiert beurteilt werden kann.

Ein Beispiel für das Erstellen von Metriken wäre PHPDepend .

PHPDepend misst ähnlich wie JDepend die Qualität des Codes anhand folgender Metriken:

  • Cyclomatic Complexity: Misst die Komplexität des Code indem es einen Kontrollflussgraphen bestimmt. Je mehr Möglichkeiten es gibt, sich durch das Programm zu bewegen, desto komplizierter ist es und ab einer bestimmten Komplecxitätsstufe wird dis schlecht bewertet. Unter anderem wird die Tiefe der Verschachtelungen gemessen. Siehe auch McCabe-Metrik
  • NPath Complexity: Auch diese Metrik bestimmt die Komplexität einer Funktion, indem es die Anzahl der möglichen Pfade bestimmt.
  • CodeRank: Ähnlich wie der Algorithmus von Google um den PageRank zu bestimmen.
  • Lines Of Code: Diese Metrik erfasst das Verhältnis von Kommentaren im Code zu reinem Code sowie weitere Verhältnisse wie z.B. Anzahl der Methoden und Funktionen pro Klasse usw.

Die folgenden Grafiken sind die Ergebnisse eines PHPDepend Testlaufes auf dem lokalen Rechner. Die Berechnung dauerte 30 Minuten und verbrauchte während dieser Zeit über 3.8GB an Hauptspeicher sowie mehrere Gigabyte an Festplattenkapazität.

Jdepend-chart-estudy.svg


Jdepend-pyramid-estudy.svg

Siehe auch einem Artikel zu Metriken der Komplexität in der Software.

Technische Infrastruktur

Allgemeine Informationen

eStudy läuft auf 4 Knoten, denen zwei Lastverteiler vorgeschaltet sind. Alle in diesem Zusammenhang betriebenen Server sind als virtuelle Maschinen (zukünftig mit "VM" abgekürzt) innerhalb einer VM-Ware Infrastruktur realisiert. Diese VM-Ware Infrastruktur-Umgebung wird durch die hochschuleigene IT-Services betreut.

Struktureller Aufbau

Die Knoten der eStudy-Plattform werden hinter zwei Lastverteilern betrieben, welche zwecks Ausfallsicherheit über Heartbeat-Monitoring verbunden sind. Heartbeat-Monitorung bedeutet, dass ein Lastverteiler den "Herzschlag", also die Funktionstüchtigkeit des anderen Lastverteilers überwacht. Bei einem Ausfall des aktiven Lastverteilers bemerkt dies der Passive sofort und wird sofort aktiv mit dem Verteilen von Anfragen. Somit werden keine oder nur eine sehr geringe Anzahl von Anfragen verpasst. Diese Lastverteiler sind eigenständige reale Server, die nicht Teil der VM-Ware Lösung sind. Die Lastverteiler leiten Anfragen im Round-Robin Verfahren an die einzelnen Cluster-Knoten weiter. Bearbeitet werden die Anfragen durch Apache2/PHP5-Instanzen des jeweiligen Knoten. Durch das bereits angesprochene LDAP-Verzeichnis benötigen alle Benutzer nur ihren Mail-Account um auf eStudy zugreifen zu können. Die Daten der Plattform werden in 2 redundanten MySQL Servern gehalten. Für die Dateiablage (Ressourcen/Uploads) wird ein OCFS2 Cluster Filesystem auf einem externen SAN verwendet. Zusätzlich stehen drei NAS-Systeme zum Erstellen von Backups zur Verfügung.

Firewall

Auf allen VM's kommt eine iptables-basierte Whitelist-Firewall zum Einsatz. Zusätzlich zur generellen Sperre aller nicht benötigten Ports werden Pakete mit ungültigen Flags verworfen und geloggt. Somit kann der Administrator bereits früh mögliche Angriffsversuche erkennen und dementsprechend reagieren

Kernel

Für alle VM's mit OCFS2-Cluster Dateisystem wird momentan eine speziell für den Betrieb dieses Dateisystems gepatchter Kernel in der Version 2.6.26 verwendet. Alle hierfür notwendigen Dateien sind auf der Homepage von dem IT-Service Mitarbeiter Sven Hartge zu finden. Die restlichen VM's werden mit dem jeweils aktuellen 2.6. - Kernel der Debian Distribution betrieben.

Cronjobs

Für regelmäßige Wartungsarbeiten wird der von Linux mitgelieferte Cron-Daemon genutzt. Der Ablauf der Cronjobs findet in der Regel nachts statt, da zu diesem Zeitpunkt zum einen die Performance-Anforderungen gering sind, und zum anderen ein möglicher Ausfall die geringsten Auswirkungen hätte. So findet jeder Tag ein Timesync, also die Synchronisation der Server-Zeit mit der aktuellen Zeit statt. Außerdem wird jeden Morgen um 5:00 Uhr die daily.php ausgeführt, in der Modulbauer rechenintensive Operationen durchführen lassen können (zum Beispiel die Berechnung der portalweiten Statistiken mit Anzahl Foreneinträge, am häufigsten verwendete Wörter, usw.).

NAS (Network Attached Storage)

Regelmäßige Backupjobs der NAS-Geräte:

  • nas-01
    • Montags und Donnerstags, 01:00: rsync [estudy-upload] -> nas-03.its.fh-giessen.de::estudy_res_back
  • nas-02
    • Montags und Donnerstags, 03:00: rsync [db-backup] -> nas-03.its.fh-giessen.de::db_res_back

Dies sind die Zeitfenster, in denen zum einen der eStudy-Upload Ordner, in denen hochgeladene Dateien gespeichert werden, und zum anderem der Inhalt der Datenbank gesichert wird.

Ausblick

In diesem Kapitel wird besprochen, welche datenschutzrelevanten Änderungen an dem eStudy-Portal kurz- und mittelfristig geplant sind.

Erstellung eines Datenschutzcenters

Es soll ein "Datenschutzcenter" entstehen, welches eine Erweiterung des vorhandenen Datenauszugs darstellt. In diesem wird über die bestehenden Rechte in Deutschland (Auskunft, Löschung, usw.) informiert. Der Benutzer kann seine Daten löschen und Einträge, je nach Foyer- bzw. Kurs-Einstellung, pseudonymisieren.

Zusammengefasst soll das Datenschutzcenter dem Anwender eine übersichtliche, intuitiv bedienbare Ansicht seiner Rechte und seiner Daten inklusive deren Löschung ermöglichen.

Skalierbarkeit diverser Pseudonymisierungsstufen

Die Opt-in/Opt-out-Verfahren sollen je nach Intimität der persönlichen Daten benutzt werden.