Hochschule für Technik und Wirtschaft Dresden (FH) Fachbereich Informatik/Mathematik Diplomarbeit im Studiengang Wirtschaftsinformatik Thema: „Entwurf und prototypische Realisierung von Maßnahmen eines Autorisierungs- und Datensicherheitskonzeptes in einer SQL-basierten chemischen Stoffdatenbank“ eingereicht von: Mathias Herzog eingereicht am: 02.11.2009 Betreuer: Prof. Dr. oec. Gunter Gräfe Fachbereich Informatik / Mathematik Hochschule für Technik und Wirtschaft Dresden (FH) Dr. Vinzenz Brendler Institut für Radiochemie Forschungszentrum Dresden-Rossendorf e. V.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Hochschule für Technik und Wirtschaft Dresden (FH)
Fachbereich Informatik/Mathematik
Diplomarbeit
im Studiengang Wirtschaftsinformatik
Thema:
„Entwurf und prototypische Realisierung von Maßnahmen eines
Autorisierungs- und Datensicherheitskonzeptes
in einer SQL-basierten chemischen Stoffdatenbank“
eingereicht von: Mathias Herzog
eingereicht am: 02.11.2009
Betreuer: Prof. Dr. oec. Gunter Gräfe
Fachbereich Informatik / Mathematik
Hochschule für Technik und Wirtschaft Dresden (FH)
Dr. Vinzenz Brendler
Institut für Radiochemie
Forschungszentrum Dresden-Rossendorf e. V.
Danksagung
Ich möchte mich an dieser Stelle bei allen bedanken, die mich bei der Bearbeitung
meines Diplomarbeitsthemas unterstützt haben.
Für die Betreuung seitens der Hochschule für Technik und Wirtschaft (HTW) Dresden,
bedanke ich mich bei Herrn Prof. Günter Gräfe. Außerdem danke ich Herrn Dr. Vinzenz
Brendler vom Forschungszentrum Dresden-Rossendorf, für zahlreiche interessante
Diskussionen und die Betreuung meiner Diplomarbeit. Des Weiteren möchte ich den
Verbundspartnern im Verbundprojekt THEREDA, besonders Frau Dr. Anke Richter
vom Forschungszentrum Dresden-Rossendorf, Herrn Dr. Helge Moog von der
Gesellschaft für Anlagen- und Reaktorsicherheit sowie Herrn Steffen Leske meinen
Dank aussprechen.
- I -
Inhaltsverzeichnis
ABBILDUNGSVERZEICHNIS ................................................................................. IV
TABELLENVERZEICHNIS ........................................................................................ V
ABKÜRZUNGSVERZEICHNIS ............................................................................... VI
Um die Sicherheit eines Endlagers für radioaktive Abfälle, sowie von
Untertagedeponien für chemisch-toxische Stoffe und die Sanierung von Altlasten des
Uranbergbaus zu gewährleisten, ist es von entscheidender Bedeutung den
Schadstofftransport in die Biosphäre voraussagen zu können. Hierfür ist ein vertieftes
Verständnis der physikalisch-chemischen Eigenschaften der Schadstoffe, wie auch ihrer
Wechselwirkungen im System Abfall, Geosphäre und Biosphäre erforderlich.
Die derzeit vorhandenen Datenbasen sind jedoch nicht einheitlich, inkonsistent,
unvollständig und bieten nur einen begrenzten Variationsbereich für Temperatur und
Druck. Um Grundzüge einer einheitlichen, konsistenten und qualitätsgesicherten
thermodynamischen Referenzdatenbasis zu entwickeln, hat sich der „Arbeitskreis
Thermodynamische Referenzdatenbasis“ gebildet. Für weitere Details wird auf
Altmaier et al. ([Z_ALTMAI]) verwiesen.
Zu den Mitgliedern des Arbeitskreises gehören die Gesellschaft für Anlagen- und
Reaktorsicherheit, das Institut für Nukleare Entsorgung des Forschungszentrums
Karlsruhe, das Institut für Radiochemie des Forschungszentrums Dresden-Rossendorf,
das Institut für Anorganische Chemie der TU Bergakademie Freiberg sowie die AF-
Colenco AG (Baden/CH).
Seit Juli 2006 wird durch das Bundesministerium für Bildung und Forschung (BMBF),
das Bundesministerium für Wirtschaft und Technologie (BMWi) und das
Bundesministerium für Umwelt, Naturschutz und Reaktorsicherheit (BMU) das Projekt
„THEREDA“ – Thermodynamische Referenzdatenbasis gefördert. Das Projekt zielt
darauf ab, Langzeitsicherheitsanalysen mittel- bis langfristig besser, zuverlässiger,
vergleichbarer, belastbarer und nachvollziehbarer zu machen.
Datenintegrität, sowie Zugriffsschutz spielen in diesem Projekt eine bedeutende Rolle,
da die Datenbasis für sicherheitsrelevante Aufgaben mit hoher öffentlicher
Aufmerksamkeit eingesetzt werden soll. Die vorliegende Diplomarbeit widmet sich
1. Einleitung
- 2 -
aufgrund dessen daher den verschiedenen Aspekten der IT-Sicherheit, sowie den
Methoden zur Authentifizierung und Autorisierung von Nutzern.
Des Weiteren werden verschiedene Web-Technologien hinsichtlich ihrer Sicherheit
diskutiert und einige Angriffsmethoden vorgestellt. In Zusammenarbeit mit dem
Projektpartner „Forschungszentrum Dresden-Rossendorf“ erfolgte eine Analyse der
Ausgangsituation. Darauf aufbauend werden die einzelnen Nutzergruppen sowie die
damit verbundenen funktionalen Anforderungen an das THEREDA Projekt definiert.
Im weiteren Verlauf erfolgt eine Konkretisierung und Verknüpfung dieser
Anforderungen.
Abschließend werden der Datenbanknutzer, die Webserverauthentifizierung sowie die
Passwortrichtlinien prototypisch realisiert.
Diese Diplomarbeit ist ein weiterer Grundbaustein innerhalb des THEREDA Projektes.
Ihr Wert liegt vor allem in der konzeptionellen Zuarbeit für nachfolgende Projektphasen
mit dem Schwerpunkt der Realisierung der einzelnen hier definierten funktionalen
Anforderungen.
2. IT-Sicherheit
- 3 -
2. IT-Sicherheit
In diesem Kapitel werden die für diese Arbeit relevanten Begriffe definiert.
Anschließend wird auf allgemeine Richtlinien, Gesetze und Standards, die sich mit
verschiedenen Aspekten der Sicherheit von Informationssystemen befassen,
eingegangen. Nach diesem allgemeinen Überblick werden Maßnahmen zur
Datensicherheit in Datenbanken vertieft betrachtet, bevor abschließend einige
Verschlüsselungsverfahren und deren Einsatzgebiet in der Kommunikationstechnik
behandelt werden.
2.1 Aspekte der IT-Sicherheit
2.1.1 Begriffe
„Unter IT-Sicherheit versteh[t man] den Schutz von Informationen und
Informationssystemen gegen unbefugten Zugriff und Manipulation sowie die
Sicherstellung der Verfügbarkeit der durch die Systeme bereitgestellten Dienste für
legitime [N]utzer, einschließlich aller Maßnahmen zur Verhinderung, Entdeckung oder
Protokollierung von Bedrohungen.“, Kappe ([B_KAPPE1], S. 2)
Abbildung 1: Zusammenhang der Begriffe
Die Datensicherheit wird im Rahmen dieser Arbeit mit der Integritätssicherung
gleichgesetzt und beschäftigt sich mit der „Sicherung der Richtigkeit, Vollständigkeit
und logischen Widerspruchsfreiheit der Daten“ ([I_HTWDD1], S. 4). In Kapitel 2.3.2.
• Protokollauswertung
• Backup/Recovery
• Integritätssicherheit
• Protokollierung
• Authentifizierung
• Autorisierung
• Protokollierung
IT-Sicherheit
Datensicherheit Zugriffsschutz Verfügbarkeit
2. IT-Sicherheit
- 4 -
wird die Integritätssicherung näher betrachtet. Des Weiteren schließt die
Integritätssicherung die Protokollierung von Änderungen am Datenbestand mit ein.
Unter dem Zugriffsschutz sind die Authentifizierung, Autorisierung und das
Protokollieren von Anmeldeinformationen zu verstehen. Dabei beschäftigt sich die
Authentifizierung mit der eindeutigen Identifikation von Nutzern und Systemen. Die
Autorisierung befasst sich dagegen mit der Zugriffskontrolle (engl. access control) und
der Vergabe bzw. dem Entzug von Rechten/Privilegien an Nutzer. Dabei werden die
verschiedenen Möglichkeiten und Maßnahmen zur Authentifizierung und Autorisierung
in Kapitel 3 ausführlicher diskutiert.
Beim Zugriffsschutz unterscheidet man zwischen Subjekt (engl subject), Objekt (engl.
object) und den eigentlichen Zugriffsrechten (engl. access right). Ein Subjekt ist ein
Nutzer, eine Rolle, ein Prozess oder ein System, welches eine Handlung auslöst. Die
initiierte Handlung wird auf einem entsprechenden Objekt bzw. einer entsprechenden
Ressource ausgeführt. Objekte können z.B. Tabellen oder Funktionen sein. Unter
Umständen können auch Subjekte Gegenstand einer Handlung werden und somit als
Objekte auftreten. Die Zugriffsrechte beschreiben, welche Handlungen ein Subjekt an
einem Objekt durchführen darf. Dabei kann ein Subjekt z.B. lesende, schreibende,
ausführende oder löschende Zugriffsrechte für ein Objekt besitzen.
Die Verfügbarkeit besagt, dass das System für legitime Nutzer immer erreichbar ist.
Hierfür sollen die verschiedenen Protokolldateien ausgewertet werden, um eventuelle
Bedrohungen frühzeitig zu erkennen und ggf. die Angriffspunkte zu eliminieren. Nach
einem Systemausfall kann mittels der in Kapitel 2.3.2. vorgestellten Backupvarianten
sowie der Logging- und Protokolldateien, die Systemwiederherstellung (engl. recovery)
schnellstmöglich gewährleistet werden. Dabei ist es notwendig, die erstellten Backups
auf deren Funktionstüchtigkeit zu prüfen und den Wiederherstellungsprozess zu
trainieren. Innerhalb dieser Arbeit wird auf die Verfügbarkeit des Systems nicht weiter
eingegangen.
2. IT-Sicherheit
- 5 -
2.1.2 BSI: Leitfaden IT-Sicherheit
Die Bundesregierung hat eine spezielle Bundesbehörde gebildet, das Bundesamt für
Sicherheit in der Informationstechnik (BSI). Diese Behörde befasst sich mit den in
§3 (1) des BSI Gesetzes (BSIG) definierten Aufgaben. Dazu zählen unter anderem:
„3. [die] Untersuchung von Sicherheitsrisiken bei Anwendung der
Informationstechnik sowie Entwicklung von Sicherheitsvorkehrungen,
insbesondere von informationstechnischen Verfahren und Geräten für die
Sicherheit in der Informationstechnik [..], soweit dies zur Erfüllung von
Aufgaben des Bundes erforderlich ist, einschließlich der Forschung im Rahmen
seiner gesetzlichen Aufgaben;
4. [die] Entwicklung von Kriterien, Verfahren und Werkzeugen für die Prüfung
und Bewertung der Sicherheit von informationstechnischen Systemen oder
Komponenten [...];
5. [die] Prüfung und Bewertung der Sicherheit von informationstechnischen
Systemen oder Komponenten und Erteilung von Sicherheitszertifikaten; […]“.
([I_BSIGx1], §3 (1))
Die durch das BSI erstellten oder in Auftrag gegebenen Studien, Richtlinien und
Empfehlungen sowie zahlreiche Publikationen, welche sich mit Sicherheitsfragen in der
Informationstechnik befassen, werden auf der Webpräsenz des BSI ([I_BSIxx1])
veröffentlicht. An gleicher Stelle ist ebenfalls der Leitfaden IT-Sicherheit, der „einen
kompakten Überblick über die wichtigsten organisatorischen, infrastrukturellen und
technischen IT-Sicherheitsmaßnahmen [gibt].“ ([I_BSILF1], Seite 3), publiziert. Im
Folgenden wird jeweils eine organisatorische, eine infrastrukturelle und eine technische
Maßnahme zur Sicherstellung bzw. Verbesserung der IT-Sicherheit erläutert.
„15. Datenzugriffsmöglichkeiten sollten auf das erforderliche Mindestmaß
beschränkt werden“ ([I_BSILF1], Seite 23)
Ein Anwender sollte immer nur auf die von ihm benötigten Ressourcen und
Informationen Zugriff haben, das „Need-to-Know“ Prinzip. Hierfür ist es sinnvoll und
teilweise notwendig, den Anwendern spezielle Rollen und Profile zuzuordnen, um so
2. IT-Sicherheit
- 6 -
den organisatorischen Aufwand zu reduzieren. Wichtig ist ebenfalls, dass nicht
benötigte Zugriffsrechte schnellstmöglich entzogen werden können, um die Gefahr von
unberechtigten Zugriffen zu minimieren. Näheres wird in Kapitel 3.2. unter
Autorisierung erläutert.
„22. Zum Schutz von Netzen muss eine Firewall verwendet werden“ ([I_BSILF1],
Seite 26)
Eine Firewall bietet die Möglichkeit, zwei oder mehrere Netze bzw. Teilnetze
voneinander abzuschirmen bzw. den Datenverkehr zu filtern. Dabei wird Datenverkehr
nach speziellen Regeln innerhalb der Firewall gefiltert und auffällige/verdächtige
Datenpakete werden blockiert. Diese Filterung des Datenverkehrs findet anhand
definierter Regeln innerhalb der Firewall statt. So ist man z.B. besser in der Lage, ein
internes Netzwerk vor bekannten Viren oder Angriffen von außen zu schützen.
„37. Alle wichtigen Daten müssen regelmäßig gesichert werden (Backup)“
([I_BSILF1], Seite 31)
Die Datensicherung (engl. Backup) sichert den Zustand oder die Daten eines Systems
zu einem bestimmten Zeitpunkt. Dadurch ist man in der Lage, ein System bzw. Daten
nach einem Hardware- oder Softwareausfall bzw. -defekt ohne größere Datenverluste
wiederherzustellen. Es sollte darauf geachtet werden, dass das Backupmedium, z.B.
eine DVD oder eine andere Festplatte, an einem anderem Ort aufbewahrt wird.
2.1.3 Gesetze und Standards
Neben den Richtlinien, welche im Leitfaden des BSI aufgeführt sind, gibt es in
Deutschland verschiedene Gesetze, die sich mit unterschiedlichen Aspekten der IT-
Sicherheit beschäftigen. Zu diesen zählen unter anderem das Bundesdatenschutzgesetz,
das Telekommunikationsgesetz sowie das Signaturgesetz, die nachfolgend kurz erläutert
werden. Weitere Gesetze werden innerhalb dieser Arbeit nicht betrachtet, stattdessen
wird auf Spezialliteratur wie z.B. [B_KOITZ1] verwiesen.
2. IT-Sicherheit
- 7 -
Bundesdatenschutzgesetz
Das Bundesdatenschutzgesetz (BDSG) beinhaltet Regelungen für den Umgang und die
Verarbeitung personenbezogener Daten natürlicher Personen, sowie Bußgeld- und
Strafvorschriften. „Jede natürliche Person soll davor geschützt werden, dass sie durch
den Umgang mit ihren personenbezogenen Daten in ihrem Persönlichkeitsrecht
beeinträchtigt wird“, Koitz ([B_KOITZ1], Seite 232). Dies ist auch in §1 Abs. 1 des
BDSG definiert. Der erste Abschnitt des BDSG enthält weitere grundlegende
Definitionen, so genannte Legaldefinitionen. Die weiteren Abschnitte beinhalten u. a.,
wie öffentliche und nicht öffentliche Stellen mit personenbezogenen Daten umzugehen
haben und welche Rechte eine natürliche Person besitzt, um den Umgang mit
personenbezogenen Daten einzuschränken.
Jedes Bundesland besitzt sein eigenes Datenschutzgesetz, die so genannten
Landesdatenschutzgesetze (LDSG). Diese beinhalten die Regelungen für die
öffentlichen und nicht-öffentlichen Stellen des jeweiligen Bundeslandes.
Telekommunikationsgesetz
Das Telekommunikationsgesetz (TKG) umfasst technologieneutrale Regelungen, mit
denen der Wettbewerb in den Bereichen der Telekommunikation sowie der
Telekommunikationsinfrastruktur gewährleistet und gefördert werden sollen. Hierfür
enthält das Gesetz neben den Marktregulierungen und dem Kundenschutz auch die
Aufgaben und Befugnisse der Bundesnetzagentur. „Die Bundesnetzagentur legt den
gesetzgebenden Körperschaften des Bundes [...] einen Bericht über ihre Tätigkeit sowie
über die Lage und die Entwicklung auf dem Gebiet der Telekommunikation vor [...]“,
nach §121 (1) TKG.
Signaturgesetz
Im Signaturgesetz (SigG) sind Rahmenbedingungen für elektronische Signaturen
definiert sowie Legaldefinitionen für diesen Bereich. Auf digitale Signaturen und die
dadurch erreichbaren Authentifizierungsmöglichkeiten wird in Kapitel 3.1.3. näher
eingegangen.
2. IT-Sicherheit
- 8 -
Neben diesen Gesetzen und Richtlinien existieren noch mehrere verschiedene
Standards. Dazu zählen die Trusted Computer Security Evaluation Criteria (TCSEC),
die in den USA durch die National Security Agency (NSA) zusammengestellt wurden.
Diese Kriterien sind in dem so genannten Orange Book (einfache Systemsicherheit),
dem Red Book (Interpretation des Orange Book im Kontext von Netzwerken) oder dem
Blue Book (NATO TCSEC, 1987, inhaltlich mit Orange Book übereinstimmend)
definiert. Des Weiteren gibt es die Europäischen Kriterien (ITSEC), die deutschen
Sicherheitskriterien (ITSK), sowie die Common Criteria (CC), welche in der ISO-15408
standardisiert wurden. (vgl. [S_FRITZ1])
2.2 Maßnahmen zur Datensicherheit in Datenbanksystemen
In Datenbanksystemen stellt das Datenbankmanagementsystem (engl. Database
Management System, kurz DBMS) unter anderem die Funktionen des Zugriffsschutzes
und der Datensicherheit zur Verfügung. Die Konzepte des Zugriffsschutzes werden in
Kapitel 3 ausführlicher diskutiert. Im Folgenden wird das Transaktionskonzept in
Datenbanken betrachtet und hinsichtlich des Zugriffsschutzes untersucht. Anschließend
wird auf die Integritätssicherung näher eingegangen.
2.2.1 Transaktion
„Eine Transaktion ist eine konsistenzerhaltende Operation auf einer Datenbank, d.h. sie
lässt die Datenbank in konsistentem Zustand zurück, wenn diese vor Beginn der
Transaktion schon konsistent war“, Zehnder ([B_ZEHND1], S. 47). Konsistent steht in
diesem Zusammenhang für die Einhaltung der semantischen Integritätsbedingungen,
basierend auf dem ACID-Prinzip. Dieses stellt die Merkmale einer Transaktion dar:
• Atomicity (Ununterbrechbarkeit, Atomarität)
Diese Eigenschaft besagt, dass eine Transaktion entweder vollständig oder gar
nicht ausgeführt wird, also nach dem „Alles oder Nichts“-Prinzip. Wird eine
Transaktion nicht erfolgreich abgeschlossen, so wird der konsistente Zustand,
der vor Beginn der Transaktion vorlag, wiederhergestellt und damit die
Zwischenergebnisse der Transaktion zurückgesetzt.
2. IT-Sicherheit
- 9 -
• Consistency (Konsistenzerhaltung)
Die Konsistenzerhaltungseigenschaft einer Transaktion stellt sicher, dass sich
die Datenbank vor bzw. nach einer Transaktion in einem konsistenten Zustand
befindet.
• Isolation (Isolation, Isolierter Ablauf)
Jede Transaktion läuft unabhängig von allen anderen parallelen Transaktionen
ab. Hier wird sichergestellt, dass eine Transaktion nicht auf inkonsistente
Zwischenwerte einer anderen Transaktion zugreifen kann und dass eine
Transaktion selbst keine inkonsistenten Werte zur Verfügung stellt.
• Durability (Dauerhaftigkeit, Persistenz)
Die Dauerhaftigkeitseigenschaft stellt sicher, dass Ergebnisse erfolgreich
abgeschlossener Transaktionen nicht verloren gehen, selbst wenn vor dem
physischen Schreiben Fehler auftreten.
In einigen Fällen kann das ACID-Prinzip nicht während einer gesamten Transaktion
eingehalten werden. In diesem Fall soll „[d]as Ergebnis einer Transaktion […]
berechnet werden, als sei sie nach dem ACID-Prinzip abgelaufen[…]“, Saake
([B_SAAKE1], S. 500). Zielsetzung ist und bleibt, die Datenbank von einem
konsistenten in einen anderen konsistenten Zustand zu überführen.
Eine Transaktion kann entweder mit einem COMMIT oder ABOUT abgeschlossen
werden. Bei einem COMMIT tritt kein Fehler innerhalb einer Transaktion auf und die
Transaktion wird erfolgreich abgeschlossen. Das heißt, dass sich die Datenbank in
einem neuen konsistenten Zustand befindet. Wird eine Transaktion mittels eines
ABOUT abgebrochen, wird in der Regel der konsistente Zustand vor Beginn einer
Transaktion wiederhergestellt.
Das ACID-Prinzip, COMMIT und ABOUT sind die grundlegendsten Eigenschaften,
welche das Transaktionskonzept aufweist. Innerhalb einer Transaktion, in der mehrere
Befehle/Anweisungen ausgeführt werden können, kann aus unterschiedlichen Gründen
ein Abbruch (ABOUT) der Transaktion erfolgen, beispielsweise durch die Verletzung
von Zugriffsberechtigungen oder von Integritätsbedingungen.
2. IT-Sicherheit
- 10 -
Innerhalb einer Transaktion wird geprüft, ob ein Subjekt für die Ausführung der
Befehle/Anweisungen die notwendigen Rechte für die davon betroffenen Objekte
besitzt. Ist dies nicht der Fall, so wird diese Transaktion durch ein ABOUT beendet. Ein
Transaktionsabbruch kann außerdem durch die Verletzung der Datenintegrität erfolgen,
welches im nächsten Unterkapitel diskutiert wird.
2.2.2 Datenintegrität
Die Datenintegrität beschäftigt sich mit der „Sicherung der Richtigkeit, Vollständigkeit
und logischen Widerspruchsfreiheit der Daten“ ([I_HTWDD1], S. 4). Dabei
unterscheidet man in
1. Semantische Integrität
2. Operationelle Integrität
3. Physische Integrität.
Semantische Integrität
Die semantische Integrität befasst sich mit der „Gewährleistung der ‚Richtigkeit’,
‚Korrektheit’ und ‚logischen Widerspruchsfreiheit’ der Daten. Die semantische
Integrität [kann] durch Fehler (beabsichtigt oder unbeabsichtigt) bei der Eingabe und
Änderung der Daten verletzt [werden]“ ([I_HTWDD2], S. 4). Dieser Prozess der
Dateneingabe und -änderung wird vom DBMS überwacht und die Einhaltung der
semantischen Integrität anhand von definierten Integritätsbedingungen sichergestellt.
Integritätsbedingungen müssen manuell aufgestellt werden und bestehen in
vollständiger Form aus den vier nachfolgenden Bestandteilen:
„• die eigentliche Integritätsbedingung
• Objektangaben (Attributwerte, Spalte, Tupel, Relation), auf die sich die
Integritätsbedingung bezieht
• die Auslöseregel, die angibt, wann die Einhaltung der Bedingung überprüft
werden soll (z.B. gleich nach Abschluss der Elementaroperation oder am
Ende der Transaktion)
2. IT-Sicherheit
- 11 -
• die Reaktionsregel, die angibt, welche Aktionen bei der Verletzung der
Bedingung auszulösen sind (z.B. Meldung an den Nutzer, Rücksetzen der
Transaktion)“ ([I_HTWDD2], S. 7).
Die Sicherung der semantischen Integrität lässt sich unter anderem mittels Check-
Klauseln, Rules, Assertions oder auch Trigger realisieren. Diese werden im Rahmen
dieser Arbeit nicht näher erläutert, vgl. [I_HTWDD2], [B_GERHA1] sowie
[B_LONEY1].
Operationelle Integrität
Operationelle Integrität wird auch als Ablaufintegrität bezeichnet. Hierbei handelt es
sich um das „Verhindern von Fehlern, die durch den gleichzeitigen Zugriff mehrerer
Nutzer auf die Datenbank entstehen können“, Gerhardt ([B_GERHA1], S. 31). „Zur
Vermeidung dieser Fehler müssen die gleichzeitig zugreifenden Nutzer bzw.
Transaktionen synchronisiert – die parallelen Abläufe serialisiert werden“
([I_HTWDD3], S. 4). Die größte Gefahr, die durch den Mehrnutzerbetrieb entstehen
kann, sind Fehler im Datenbestand. Diese können durch das Phantomproblem, nicht-
wiederholbares Lesen, verloren gegangene Änderungen sowie den Zugriff auf
„schmutzige“ Daten bzw. Zugriff auf nicht freigegebene Änderungen auftreten, die in
([I_HTWDD3], S. 5) genauer spezifiziert werden. Auf diese Probleme wird aber nicht
weiter eingegangen.
Zur Sicherstellung der operationellen Integrität gibt es drei unterschiedliche Verfahren:
1. Pessimistische oder Sperrverfahren: Bei diesen Verfahren wird vom
schlimmsten Fall ausgegangen, das heißt, dass „parallele Transaktionen auf die
gleichen Daten [...] zugreifen werden und so Konflikte sehr wahrscheinlich
sind“ ([I_HTWDD1], S. 9). Aus diesem Grund werden die von einer
Transaktion benutzen Daten für deren Dauer für andere Transaktionen gesperrt.
2. Optimistische Verfahren: Im Gegensatz zu dem pessimistischen Verfahren
„gehen [optimistische Verfahren] davon aus, dass parallele Transaktionen nicht
auf die gleichen[...] Daten zugreifen.“ ([I_HTWDD3], S. 9). Um sicherzustellen,
dass durch diese Verfahrensweise keine Fehler im Datenbestand generiert
werden, wird vor Abschluss einer Transaktion geprüft, ob Konflikte aufgetreten
2. IT-Sicherheit
- 12 -
sind. Das heißt, es werden die Datensätze, die während der Transaktion gelesen
wurden, mit den entsprechenden Datensätzen in der Datenbank verglichen. Im
Fall eines Konfliktes wird die Transaktion zurückgesetzt, andernfalls wird sie
erfolgreich abgeschlossen.
3. Zeitstempelverfahren: Bei diesen Verfahren wird mit Zeitstempeln gearbeitet.
Das bedeutet, dass bei der Verwendung von Datenbankobjekten durch eine
Transaktion eine Lesezeitmarke gesetzt wird. Ändert die Transaktion ein
entsprechendes Datenobjekt und versucht dieses zurückzuschreiben, so wird
eine Schreibzeitmarke gesetzt. Durch den „[V]ergleich der unterschiedlichen
Zeitmarken kann ermittelt werden, ob eine Transaktion erfolgreich fortgeführt
werden kann oder [ggf.] erneut gestartet werden muss“ ([I_HTWDD3], S. 9).
Physische Integrität
Mittels der physischen Integrität stellt man den Schutz vor Verlust der Daten durch
physische Zerstörung oder Fehler sicher. Diese Fehler werden in Software- und
Hardwarefehler eingeteilt. Sie können außerdem durch gezielte Angriffe herbeigeführt
werden. Um Daten vor Verlust zu schützen, sollte regelmäßig eine Datensicherung
(engl. Backup) durchgeführt werden. Mit Hilfe der Backups wird ein konsistenter
Datenbankzustand zu einer bestimmten Zeit gesichert. Die darauf folgenden
Änderungen am Datenbestand werden in Protokolldateien dokumentiert.
Im Falle eines Systemausfalls wird der in den Backupdateien gespeicherte konsistente
Zustand durch einen Recovery-Prozess wiederhergestellt. Anschließend werden die in
den Protokolldateien dokumentierten Änderungen am Datenbestand eingespielt, um den
Zustand vor dem Systemausfall zu rekonstruieren. Dabei kann man die Backups nach
komplettem, partiellem oder inkrementellem sowie zwischen Online- und Offline-
Backup unterscheiden. Für nähere Beschreibungen und Erläuterungen siehe Störl
([B_STÖRL1], S. 24 – 27) oder Lemay ([B_LEMAY1], S. 485 – 488).
2. IT-Sicherheit
- 13 -
2.3 Verschlüsselungsverfahren zur sicheren Kommunikation
Zum Schutz von sensiblen Daten werden verschiedene Verschlüsselungsverfahren
eingesetzt, z.B. zur Verschlüsselung von Passwörtern. Durch diese Verfahren sind die
Daten nicht ohne Weiteres für Dritte lesbar. Der Schutz innerhalb eines Systems reicht
aber nicht aus, sobald dieses mit anderen Systemen/Nutzern über ein unsicheres
Medium kommuniziert. Das World Wide Web, kurz WWW, ist eines dieser unsicheren
Medien. Darum wurden verschiedene Protokolle und Verfahren für den Einsatz im
WWW entwickelt, um die Kommunikation und somit auch die Daten besonders zu
schützen. Nachfolgend werden die grundlegenden Verfahren der Verschlüsselung kurz
erläutert. Anschließend wird auf das SSL-Protokoll näher eingegangen, das diese
Grundlagen nutzt und im WWW eine sichere Kommunikation ermöglicht.
2.3.1 Kryptographische Grundlagen
Das Verschlüsseln von Daten oder Nachrichten wird als Kryptographie bezeichnet.
Dabei wird vereinfacht dargestellt eine Klartextnachricht in einen Geheimcode
verschlüsselt. Dies passiert bei den modernen Kryptographieverfahren mittels eines so
genannten Schlüssels bzw. eines Schlüsselpaares. Das Verschlüsseln von Nachrichten
wird als Chiffrieren und die verschlüsselte Nachricht als Chiffriertext bezeichnet. Dieser
Chiffriertext lässt sich nur mit dem passenden Schlüssel in die ursprüngliche
Klartextnachricht überführen, was als Dechiffrieren bezeichnet wird. Dies wird
vereinfacht in Abb. 2 veranschaulicht.
Abbildung 2: Einfaches kryptographisches Modell, nach [B_KAPPE1], S. 19
Chiffrierschlüssel Dechiffrierschlüssel
Chiffriertext Chiffriertext Klartext Klartext
Chiffrierverfahren
Dechiffrierverfahren
Verschlüsselung Entschlüsselung
2. IT-Sicherheit
- 14 -
Wird zum Ver- bzw. Entschlüssen einer Nachricht derselbe Schlüssel verwendet, so
spricht man von symmetrischen Verfahren. Bei der Verwendung eines so genannten
Schlüsselpaares werden unterschiedliche Schlüssel zum Chiffrieren und Dechiffrieren
eingesetzt. Hierbei spricht man von asymmetrischen Verfahren, welche auch als
Public-Key-Verfahren bekannt sind. Werden symmetrische und asymmetrische
Verfahren in Kombination eingesetzt, spricht man von hybrid Verfahren. Diese
Verfahren können durch den Einsatz von Hashfunktionen unterstützt und sicherer
gestaltet werden. Diese kryptographischen Verfahren werden nachfolgend kurz erläutert
und relevante Algorithmen entsprechend zugeordnet. Hierbei wird kein Anspruch auf
Vollständigkeit erhoben und die mathematischen Hintergründe nicht näher betrachtet.
Für zusätzliche Informationen wird auf die spezielle Fachliteratur verweisen, wie z.B.
[B_SWOBO1], [S_FRITZ1] oder [B_BLESS1].
Das Gegenstück zur Kryptographie ist die Kryptoanalyse, die sich mit dem
Entschlüsseln von Chiffriertexten ohne Besitz des Schlüssels befasst, dies ist jedoch
nicht Thema der vorliegenden Arbeit.
Symmetrische Verfahren
Die symmetrischen Verschlüsselungsverfahren nutzen, wie in Abb. 3 dargestellt,
denselben Schlüssel zum Ver- und Entschlüsseln.
Abbildung 3: Symmetrische Kryptographie, vgl. [B_KAPPE1], S. 26
Die verschiedenen Verschlüsselungsverfahren erwarten in der Regel Eingaben mit
fester Länge. Somit ist es für die Verschlüsselung notwendig, dass der Klartext in
Blöcke mit einer festen Länge oder Zeichen aufgeteilt wird.
Chiffriertext Chiffriertext Klartext Klartext
Chiffrierverfahren
Dechiffrierverfahren
Verschlüsselung Entschlüsselung
Schlüssel
2. IT-Sicherheit
- 15 -
Aus diesem Grund unterscheidet man die symmetrischen Verfahren in Block- oder
Stromchiffren-Verarbeitung.
Wird der Eingabestrom in Blöcke eingeteilt, so spricht man von Blockchiffren. Dabei
verwendet der entsprechende Algorithmus für jeden Block den gleichen Schlüssel zum
Verschlüsseln. Wenn der Eingabestrom kein Vielfaches der Blockgröße ist, muss beim
letzten Block das so genannte Padding angewendet werden. Hierbei wird der letzte
Block mit entsprechenden Füllzeichen vervollständigt. Innerhalb dieser Füllzeichen
wird entweder die Länge des Füllbereiches oder die des Klartextes kodiert, damit man
beim Entschlüsseln auch die Originalnachricht unverfälscht erhält.
Ein bekanntes Verfahren für Blockchiffren ist der Data Encryption Standard (DES).
Dieser verwendet eine Blockgröße von 64 Bit, wobei davon nur 56 Bit relevant sind.
Heutzutage gilt dieses Verfahren jedoch als unsicher. Als sicher werden unter anderem
die Verfahren AES 128 sowie AES 256 oder auch Triole-DES angesehen.
Bei Stromchriffren wird der Eingabestrom bit- oder byte- bzw. zeichenweise
verarbeitet. Hierfür wird zur Verschlüsselung des Eingabestroms ein Pseudozufalls-
zahlengenerator genutzt. Dieser generiert für jedes Bit die entsprechende
Schlüsselfolge. Für die Entschlüsselung benötigt man denselben Pseudozufalls-
zahlengenerator und dessen Initialwert, wodurch der Zufallszahlengenerator die
identische Zufallszahlenfolge, wie sie zur Verschlüsselung eingesetzt wurde, generiert.
Das RC4-Verfahren ist ein Vertreter dieses Verfahrens. Es arbeitet mit Schlüsseln
variabler Länge.
Weitere symmetrische Verschlüsselungsverfahren sind die so genannten One-Time-
Pads. Dafür „wird eine sehr lange Folge zufällig gewählter Schlüsselbuchstaben
benötigt. Mit jedem Schlüsselbuchstaben wird genau ein Klartextzeichen nach einem
definierten Verfahren (z.B. modulo 26) verschlüsselt. Der Schlüssel darf nur in einer
einzigen Nachricht verwendet werden. Wenn jede Schlüsselsequenz gleich
wahrscheinlich ist, gibt es keine Informationen für eine Kryptoanalyse“ ([S_FRITZ1]).
Dadurch stellen One-Time-Pads ein perfektes Verschlüsselungskonzept dar.
2. IT-Sicherheit
- 16 -
Die größte Schwachstelle symmetrischer Verfahren stellt das Bekanntmachen des
jeweiligen Schlüssels dar. Dieser muss vor Beginn einer sicheren Kommunikation erst
über ein unsicheres Medium, wie z.B. das WWW, allen Kommunikationspartnern
mitgeteilt werden.
Asymmetrische Verfahren
Im Gegensatz zu symmetrischen Verfahren verwenden asymmetrische Verfahren ein so
genanntes Schlüsselpaar zum Ver- und Entschlüsseln. Ein solches Schlüsselpaar besteht
aus einem öffentlichen (engl. Public Key) und einem privaten (engl. Private Key)
Schlüssel. Aus diesem Grund werden asymmetrische Verfahren auch als Public-Key-
Verfahren bezeichnet. Die Idee hinter diesem Verfahren ist, dass der öffentliche
Schlüssel allen Kommunikationspartnern bekannt ist und zum Verschlüsseln von
Nachrichten verwendet werden kann. Die so verschlüsselten Nachrichten können nur
mit dem passenden privaten Schlüssel wieder entschlüsselt werden. Dieser Prozess ist in
Abb. 4 dargestellt.
Abbildung 4: Asymmetrische Kryptographie, nach [B_KAPPE1], S. 28
Ein Vertreter der asymmetrischen Verfahren ist das RSA-Verfahren, „das auf der
Faktorisierung großer Zahlen, speziell des Produkts zweier Primzahlen basiert“, Kappes
([B_KAPPE1], S. 29).
Öffentlicher Schlüssel
des Empfängers
Privater Schlüssel
des Empfängers
Chiffriertext Chiffriertext Klartext Klartext
Chiffrierverfahren
Dechiffrierverfahren
Verschlüsselung Entschlüsselung
2. IT-Sicherheit
- 17 -
Hashfunktionen
„Hashfunktionen bilden einen String variabler Länge auf einen String fester Länge –
den Hashwert – ab“ ([S_FRITZ1]). Dabei sollen Hashfunktionen den Hashwert auf
effiziente Art und Weise berechnen können und möglichst kollisionsfrei sein. Weist
eine Hashfunktion einen hohen Grad an Kollisionsfreiheit auf spricht man von Einweg-
Hashfunktionen. Im Wesentlichen bedeutet Kollisionsfreiheit, dass es schwer ist zwei
Originalnachrichten mit demselben Hashwert zu erzeugen.
Beispiele für Einweg-Hashfunktionen sind unter anderem MD5 und SHA-1. Letzteres
ist im ISO/IEC Standard 10118 beschrieben. Daneben gibt es mittlerweile auch den
Nachfolger SHA-2.
2.3.2 Verfahren zur sicheren Kommunikation
Aufbauend auf den gerade dargestellten kryptographischen Verfahren wurden speziell
für das WWW Sicherheitsprotokolle entwickelt, die diese nutzen und es so
ermöglichen, sichere Verbindungen aufzubauen. Durch diese sicheren Verbindungen ist
es nun möglich, die Kommunikationspartner sowie die übertragenen Daten vor
unerlaubtem Zugriff bzw. Manipulation zu schützen. Ein Überblick über verschiedene
Protokolle, nach Martius ([B_MARTI1], S. 148) wird im Anhang I gegeben.
Nachfolgend wird auf das für diese Arbeit relevante SSL/TLS-Protokoll sowie das
HTTPS-Protokoll eingegangen.
SSL/TLS-Protokoll
Mittels des SSL (Secure Socket Layer)-Protokolls lassen sich gesicherte TCP-Dienste
zur Verfügung stellen. Dabei können SSL und TLS (Transport Layer Security), seit der
SSL Version 3.0 und der TLS Version 1.0, im Wesentlichen als Synonyme verwendet
werden, da SSL den Kern von TLS bildet. Dabei kombiniert SSL sowohl symmetrische
als auch asymmetrische Verschlüsselungsverfahren und stellt somit ein hybrides
Verschlüsselungsverfahren dar.
2. IT-Sicherheit
- 18 -
Der Aufbau einer gesicherten Verbindung findet in zwei Schritten statt. Zu Beginn wird
das so genannte Handshakeverfahren initialisiert und anschließend der Datenaustausch
über die Records abgewickelt.
Innerhalb des Handshakeverfahrens findet die Authentifizierung eines Servers
gegenüber dem Client statt. Des Weiteren werden die eingesetzten kryptographischen
Algorithmen zwischen Client und Server ausgehandelt. Optional ist dabei noch eine
Authentifizierung des Clients beim Server. Aus diesen ausgehandelten und
ausgetauschten Informationen können die entsprechenden Schlüssel für die Übertragung
der Records berechnet werden. Abbildung 5 skizziert den Ablauf des
Handshakeverfahrens.
Abbildung 5: SSL-Handshakeverfahren, vgl. [B_MARTI1], S. 89
Nachfolgend werden die einzelnen Schritte nach Martius ([B_MARTI1], S. 88 - 89)
näher beschrieben:
CLIENT_HELLO: Innerhalb des CLIENT_HELLO übermittelt der Client die von ihm unterstützten kryptographischen Verfahren.
SERVER_HELLO: „Der Server antwortet mit einem von ihm selektierten Verfahren. Standardmäßig wird dabei das erste in der Liste vorkommende Verfahren gewählt, das der Server selbst unterstützt. [...]“, Martius ([B_MARTI1], S. 88)
Certificate: Das Serverzertifikat wird regelmäßig als Nachweis an den Client gesendet.
ServerKeyExchange: (Optional) Wird nur dann benötigt, wenn der im Zertifikat enthaltene Schlüssel nur zum Signieren vorgesehen ist.
ChangeCipherSpac / Finished
Server
CLIENT_HELLO
SERVER_HELLO
Client
Certificate
ServerKeyExchange
CertificateRequest
ServerHelloDone
Certificate
ClientKeyExchange
CertificateVerify
ChangeCipherSpac / Finished
TCP-Verbindungsaufbau
2. IT-Sicherheit
- 19 -
CertificateRequest: (Optional) Wird vom Server eine Clientauthentifizierung gefordert, so fordert der Server das entsprechende Zertifikat vom Client an.
ServerHelloDone: Der Server teilt dem Client mit, dass er nun auf Nachrichten vom ihm wartet.
Certificate: (Optional) Wurde ein Clientzertifikat angefordert, so wird dieses nun bereitgestellt.
ClientKeyExchange: „Der Client wählt Parameter für den späteren gemeinsamen Sitzungs-schlüssel, die (wenn im Serverzertifikat ein Verschlüsselungs-Schlüssel enthalten ist) mit dem öffentlichen Schlüssel des Servers codiert werden. Möglich ist jedoch auch die Übermittlung eines öffentlichen DH-Exponenten und eines Zufallswertes.“, Martius ([B_MARTI1], S. 89)
CertificateVerify: (Optional) Ein vom Server übermittelter Zufallswert wird vom Client signiert zum Nachweis, dass er im Besitz des passenden geheimen Schlüssels ist.
Während des Aushandelns aller Parameter, die zur Berechnung des gemeinsamen
geheimen Sitzungsschlüssels benötigt werden, kommen asymmetrische Verfahren zum
Einsatz. Nachdem die Parameter nach dem Handshakeverfahrens beiden
Kommunikationspartnern zur Verfügung stehen und der Sitzungsschlüssel berechnet
wurde, wird die Kommunikation symmetrisch verschlüsselt fortgesetzt. Dieser
Sitzungsschlüssel wird zur Kodierung der SSL-Records eingesetzt.
Das BSI stellt hierfür ein Umsetzungskonzept sowie eine SSL-Studie unter [I_BSISL1]
bereit, welche Maßnahmen und Voraussetzungen für die Einführung und Verwendung
von SSL diskutiert. Nachfolgend wird SSL in Verbindung mit dem HTTP-Protokoll
näher betrachtet. Dies wird auch als HTTPS (HTTP Secure)-Protokoll bezeichnet.
HTTPS-Protokoll
Das Hypertext Transfer Protocol (HTTP) ist das Kommunikationsprotokoll des WWW.
Es basiert auf einem einfachen Frage/Antwort-Prinzip, in dem der Clientbrowser eine
Anfrage (engl. Request) an einen Webserver stellt, der diese mit einer Antwort (engl.
Response) beantwortet. In den meisten Fällen ist die Antwort eine HTML-Seite, welche
vom Webserver ausgeliefert und beim Client anschließend dargestellt wird. Da diese
Kommunikation unverschlüsselt stattfindet, stellt dies für sicherheitskritische
Anwendungen bzw. Teilanwendungen ein enormes Gefahrenpotential dar. Um diese
Sicherheitslücke zu schließen, kann man das SSL-Protokoll in Verbindung mit dem
HTTP-Protokoll einsetzen. Das so bezeichnete HTTPS-Protokoll ermöglicht daraufhin
den Aufbau von gesicherten HTTP-Verbindungen. So können Daten zwischen Client
und Server verschlüsselt übertragen werden.
3. Authentifizierung und Autorisierung
- 20 -
3. Authentifizierung und Autorisierung
In diesem Kapitel werden Methoden zur Feststellung der eindeutigen Identität von
Personen und/oder Systemen erläutert, der sogenannten Authentifizierung.
Anschließend werden Autorisierungsmethoden zur Vergabe von Zugriffsrechten für IT-
Ressourcen diskutiert.
3.1 Authentifizierung
Die Authentifizierung befasst sich mit Maßnahmen, durch die die Identität eines
Nutzers/Systems oder der Ursprung eines Dokumentes eindeutig identifiziert werden
kann. Methoden zur Benutzerauthentifizierung können wie folgt eingeteilt werden:
1. Wissen: Die Authentifizierung durch Wissen basiert auf einem Geheimnis, dass
ausschließlich der Authentifizierende und der Verifizierende kennen. Dabei
prüft der Verifizierende, ob das Geheimnis, welches ihm der Authentifizierende
mitteilt, identisch mit dem Geheimnis ist, dass er bereits besitzt. Beispiele
hierfür sind die Authentifizierung mittels Passwort, Personal Identification
Number (PIN) oder Transaction Authentication Number (TAN).
2. Besitz: Der Authentifizierende ist im Besitz eines Gegenstandes, durch den er
sich gegenüber Anderen eindeutig identifizieren kann. Smart Card oder Token
Card sind Anwendungsbeispiele hierfür.
3. Biometrie: Bei biometrischer Authentifizierung dienen personenbezogene
Merkmale zum Nachweis der Identität. Diese Merkmale können zum Beispiel
der Fingerabdruck oder die Iris sein.
Bei sicherheitskritischen Anwendungen kann auch eine Kombination aus verschiedenen
Benutzerauthentifizierungsmethoden eingesetzt werden. Ein Beispiel dafür ist die
Kombination aus dem Besitz einer Smart Card und dem Wissen eines geheimen PINs,
durch den der Zugriff auf die Daten der Smart Card ermöglicht wird. Im WWW stellt
die Benutzerauthentifizierung durch Wissen, vor allem die Passwortauthentifizierung,
die wohl momentan am weitesten verbreitete Methode der Authentifizierung, dar. Diese
3. Authentifizierung und Autorisierung
- 21 -
Methode wird bevorzugt, da sie sich relativ einfach implementieren lässt und keine
zusätzliche Hardware benötigt. Für die Authentifizierung durch Besitz oder Biometrie
ist dagegen eine spezielle Hard- und Softwarekomponente notwendig. Daher gestaltet
sich die Verwendung etwas aufwendiger, bietet jedoch ein erhöhtes Sicherheitsniveau.
Tabelle 1: Vergleich der Methoden zur Benutzerauthentifizierung, vgl. [I_BROMB1]
Wissen Besitz Biometrie
Beispiele Passwort, PIN Schlüssel, Token Card Fingerabdruck, DNA
Kopierbarkeit „Software“ einfach bis sehr schwierig einfach bis schwierig
Verlust vergessen einfach sehr schwierig
Diebstahl ausspionieren möglich schwierig
Weitergabe einfach einfach einfach bis schwierig
Änderbarkeit einfach einfach einfach bis sehr schwierig
Neben der Benutzerauthentifizierung spielt die Authentifizierung von Systemen bzw.
Servern eine wichtige Rolle im WWW. Hierzu werden im Allgemeinen digitale
Zertifikate eingesetzt, die durch eine als vertrauenswürdig angesehene Einrichtung
beglaubigt werden. Hinzu kommt noch die Authentifizierung von Dokumenten bzw.
dessen Urheber, welcher sein Dokument mittels einer digitalen Signatur unterzeichnet.
Zum Abschluss dieses Unterkapitels wird noch auf das Challenge-Response Verfahren
eingegangen.
3.1.1 Passwort-Authentifizierung
Wie bereits erwähnt, ist die Authentifizierung mittels Passwörtern das verbreitetste
Verfahren. Dies liegt vor allem in der einfachen Nutzbarkeit, Implementierbarkeit und
der Hardwareunabhängigkeit begründet. Das Passwort stellt das Geheimnis dar, durch
das die Identität des zu authentifizierenden Nutzers überprüft und nachgewiesen werden
kann. Dabei muss dieses Geheimnis beiden Seiten bekannt sein.
Im Folgenden werden Schwachstellen und Möglichkeiten zu deren Minimierung
diskutiert.
3. Authentifizierung und Autorisierung
- 22 -
Passwortsicherheit
Ein Passwort zeichnet sich durch den verwendeten Passwortraum aus, unter dem man
„die Anzahl aller möglichen Passwörter“, Kappes ([B_KAPPE1], S. 41) versteht. Dieser
Raum definiert sich durch die Länge eines Passwortes und die zulässigen Zeichen. Dies
wird in der nachfolgenden Tabelle verdeutlicht.
Tabelle 2: Übersicht möglicher Passworträume, nach [B_KAPPE1], S. 42
Passwort-länge
Erlaubte Zeichen Anzahl erlaubter Zeichen
Möglichkeiten Entsprechung in Bit
4 0-9 10 104 13,3
8 a-z 26 268 37,6
8 a-z, A-Z, 0-9 62 628 47,6
8 a-z, A-Z, 0-9, 28 Sonderzeichen 90 908 51,9
16 a-z 26 2616 75,2
16 a-z, A-Z, 0-9 62 6216 95,3
16 a-z, A-Z, 0-9, 28 Sonderzeichen 90 9016 103,9
n q qn log2(qn)
Die Sicherheit einer Passwortauthentifizierung ist stark vom gewählten Passwortraum
und den Passwortrichtlinien abhängig. Die Richtlinien definieren Eigenschaften, die ein
neues Passwort mindestens erfüllen muss, damit es akzeptiert wird.
Wählt man zum Beispiel einen großen Passwortraum, welcher starke Passwörter
erlaubt, aber definiert nur schwache Richtlinien, kann es dazu führen, dass Nutzer
einfache und somit schwache Passwörter verwenden. Dies begünstigt so gennannte
Wörterbuchangriffe, bei denen ein Angreifer versucht, durch Probieren von Passwörtern
das Richtige zu erraten.
Werden hingegen starke Richtlinien, z.B. mindestens 16 Zeichen mit mindestens zwei
Sonderzeichen, gewählt, kann dies zur Verringerung der Bedienbarkeit und der
Nutzerakzeptanz führen. Dies führt wiederum dazu, dass Passwörter aufgeschrieben
werden und so ausspioniert werden können. Es ist somit sinnvoll, den Passwortraum
sowie die Richtlinien an die jeweiligen Bedürfnisse bezüglich der Sicherheit und
Bedienbarkeit je nach Anwendung bzw. System anzupassen.
3. Authentifizierung und Autorisierung
- 23 -
Tabelle 3: Passwortrichtlinien, vgl. [B_RICHT1], S. 13
Methode Erläuterung
Passwortzyklus Definiert wie lange ein Passwort gültig ist bzw. in welchem Zyklus das Passwort geändert werden muss.
Wiederverwendung Kann man ein Passwort durch sich selbst ersetzen, macht dies einen Passwortzyklus überflüssig. Aus diesem Grund ist es sinnvoll eine bestimmte Anzahl von bereits verwendeten Passwörtern zu definieren, die nicht wieder verwendet werden dürfen.
Wörterlisten Die Wörterliste enthält eine Reihe von Passwörtern, welche nicht verwendet werden dürfen.
Zeichensatz Innerhalb des Zeichensatzes ist festgelegt, welche Zeichen verwendet werden können (vgl. Tabelle 2).
Passwortlänge Definiert die Mindestlänge für Passwörter.
Sperren Legt fest, nach wie vielen Fehlversuchen ein Nutzerkonto gesperrt wird. Alternativ hierzu können auch Antwortzeitverzögerungen eingesetzt werden bei denen festgelegt wird, nach welcher Zeitspanne frühestens ein neuer Anmeldeversuch vorgenommen werden darf.
Durch die in Tabelle 3 dargestellten Eigenschaften, die eine Passwortrichtlinie
beinhalten kann, lässt sich die Sicherheit von Passwörtern effektiv steigern und die
Gefahr von schwachen Passwörtern minimieren.
An dieser Stelle soll noch einmal darauf hingewiesen werden, dass ein Kompromiss
zwischen Passwortsicherheit und Benutzbarkeit eingegangen werden muss. Selbst wenn
man durch einen guten Kompromiss stärkere Passwörter erhält, muss immer
berücksichtigt werden, dass auch diese Passwörter erraten bzw. entschlüsselt werden
können, vor allem durch die Verwendung veralteter oder bereits als entschlüsselbar
bekannter Verschlüsselungsalgorithmen.
In dem Artikel von Arbeiter und Deegen ([Z_CT0609], S. 204f) wird beschrieben, wie
die Rechenleistung eines normalen Computers durch die Kombination aus CPU und
Grafikkartenprozessoren enorm gesteigert werden kann. Diese Steigerung der
Rechenleistung führt dazu, dass Passwörter, welche mit dem NTML-Hash Algorithmus
verschlüsselt wurden, je nach verwendetem Zeichensatz relativ schnell berechnet
werden können. Der NTML-Hash Algorithmus wird von aktuellen Windows-Versionen
und Netzwerkprotokollen verwendet.
3. Authentifizierung und Autorisierung
- 24 -
In der nachfolgenden Tabelle werden die in dem Test ermittelten Berechnungsdauern
übersichtlich dargestellt. Dabei ist zu berücksichtigen, dass „[i]m statistischen Mittel
[...] ein Passwort nach der Hälfte der angegebenen Maximalzeit ermittelt [ist]“
([Z_CT0609], S. 205).
Tabelle 4: Crack-Dauer für Windows-Passwörter (NTLM), nach [Z_CT0609], S. 205
8 [a-z], [A-Z], [0-9], [typ. Sonderzeichen] 33 Tage
8 [a-z], [A-Z], [0-9], [alle Sonderzeichen] 82 Tage
11 [a-z], [A-Z] 270 Jahre
Die in Tabelle 4 aufgeführten Zeiten wurden unter den für den Bericht spezifischen
Systemvoraussetzungen ermittelt und können durch leistungsfähigere Hardware
verringert werden.
Des Weiteren kann es einem Angreifer durch geschickte Wahl von Parametern oder
durch eigene Algorithmen gelingen, bereits nach wenigen Versuchen das richtige
Passwort zu erraten. Es wird an dieser Stelle jedoch nicht weiter auf entsprechende
Verfahren, Algorithmen oder Cracker-Programme eingegangen.
Abschließend soll noch ein kleiner Exkurs zur Verwendung von Passwörtern, die hohen
Sicherheitsansprüchen genügen, aber dennoch relativ einfach zu merken sind, gegeben
werden.
Ein gutes und sicheres Passwort sollte mindestens acht Zeichen lang sein und aus
zufälligen Zeichen (Groß- und Kleinbuchstaben sowie Sonderzeichen) bestehen. Leider
lassen sich diese Passwörter nur sehr schlecht, wenn überhaupt einprägen, wodurch
Nutzer meist auf einfacher zu Merkende zurückgreifen. Abhilfe könnte die Verwendung
eines Passwortschemata bieten, dieses besteht aus einem Grundpasswort, welches
bereits die Kriterien eines sicheren Passwortes erfüllt und einer
anwendungsspezifischen Ergänzung.
3. Authentifizierung und Autorisierung
- 25 -
Dadurch, dass man das Grundpasswort in mehreren Anwendungen/Systemen
verwendet, prägt sich selbst eine wahllose Kombination von Zeichen relativ schnell ein
und die jeweilige Ergänzung lässt sich letztendlich von der Anwendung her ableiten.
Vgl. Rütten ([Z_CT0209], S. 86f).
Einmal-Passwörter
Eine weitere Möglichkeit die Passwortauthentifizierung sicherer zu gestalten, ist die
Verwendung von so genannten Einmal-Passwörtern. Bei diesen hat ein Angreifer keine
Chance das gültige Passwort zu missbrauchen, selbst wenn das Passwort über ein
abhörbares Medium übermittelt wird, da es nur ein einziges Mal gültig ist.
Der Nachteil dieser Verfahrensweise ist die Übermittlung der gültigen Einmal-
Passwörter, denn diese müssen beiden Seiten vor dem Authentifizierungsprozess
bekannt sein. Eines der bekanntesten Beispiele hierfür sind die für das Onlinebanking
verwendeten TAN-Verfahren.
3.1.2 Smart Card
Smart Cards sind sichere, kompakte und intelligente Datenträger in der Größe einer
Kreditkarte. Die auf dem Datenträger gespeicherten Daten können nur mithilfe eines
Chip Operating System (COS), das ein hohes Level an Sicherheit bereitstellt, gelesen
werden. Meist ist diese COS zusätzlich durch ein Passwort geschützt.
Um Smart Cards zur Authentifizierung nutzen zu können ist ein spezielles Lesegerät
notwendig. Des Weiteren müssen besondere Schnittstellen für die Systeme und
Anwendungen implementiert werden, damit die Authentifizierung nur mittels Smart
Card und ggf. dem entsprechenden Passwort funktioniert. (Vgl. [B_ECKER1] und
[I_TECHF1])
3. Authentifizierung und Autorisierung
- 26 -
3.1.3 Fingerprint-Scanner
Fingerabdrücke weisen ein für jeden Nutzer individuelles Muster auf, dass es einem
System bzw. einer Softwarekomponente ermöglicht einen Nutzer eindeutig zu
identifizieren.
Damit ein Nutzer sich mittels seines Fingerabdrucks gegenüber einem System
authentifizieren kann, muss dieser zuvor in diesem gespeichert sein. Zum Einscannen
eines Fingerabdruckes wird eine spezielle Hardwarekomponente und zum Vergleich des
eingescannten Fingermusters mit den gespeicherten eine Softwarekomponente benötigt.
Das eingescannte Fingermuster stimmt nicht immer hundertprozentig mit dem
gespeicherten Muster überein, dies kann z.B. durch einen leicht veränderten
Neigungswinkel beim Scannen geschehen oder auch durch eine Verletzung bedingt
sein. Aus diesem Grund wird beim Abgleich der Muster ein gewisser Grad an Toleranz
eingeräumt. (Vgl. [I_BROMB1] und [I_SCHMU1])
3.1.4 Digitale Zertifikate
Das Problem im WWW ist die Glaubhaftigkeit der einzelnen Nutzer bzw. Systeme.
Hierfür wurden digitale Zertifikate eingeführt, die nähere Informationen über den
Zertifikatbesitzer enthalten und den öffentlichen Schlüssel für z.B. eine verschlüsselte
Kommunikation bereit stellen. Diese Zertifikate sollten von einer allgemein als
vertrauenswürdig geltenden Zertifizierungsstelle ausgestellt sein, um die
Glaubhaftigkeit und Echtheit zu verifizieren. Eine dieser vertrauenswürdigen Stellen ist
das BSI.
Es gibt daneben die Möglichkeit, selbst Zertifikate zu erstellen und diese bei Bedarf
beglaubigen zu lassen. Ein nicht beglaubigtes Zertifikat kann entsprechend leicht
gefälscht werden. Eine dieser Möglichkeiten ist die Verwendung von OpenSSL.
(Vgl. [I_DEUTS1] und [I_OPENS1])
3. Authentifizierung und Autorisierung
- 27 -
3.1.5 Digitale Signatur
Digitale Signaturen dienen wie handschriftliche Unterschriften/Signaturen dazu, die
Echtheit, Unverfälschtheit und Nicht-Abstreitbarkeit von Dokumenten sicherzustellen.
Der Empfänger eines Dokumentes kann so zweifelsfrei feststellen, ob das erhaltene
Dokument wirklich vom Empfänger stammt und dieser es willentlich unterzeichnet hat.
Für das Unterzeichnen können symmetrische und asymmetrische Verfahren verwendet
werden, wobei der Unterzeichner entweder das gesamte Dokument oder den von diesem
Dokument berechneten Hashwert digital signiert und letzteren anschließend mit dem
Dokument versendet. Der Empfänger kann mittels dieser Signatur ein Dokument
eindeutig dem Unterzeichner zuordnen.
Die genauen Methoden, Möglichkeiten und Verfahrensweisen werden im Rahmen
dieser Arbeit nicht näher betrachtet. Abschließend soll noch auf das in Deutschland
gültige Signaturgesetz verwiesen werden, welches unter anderem Rahmenbedingungen
für elektronische Signaturen definiert. (Vgl. [S_FRITZ1] und [I_DEUTS2])
3.1.6 Challenge-Response-Authentifizierung
Challenge-Response-Authentifizierung basiert auf dem Frage (engl. Challenge) /
Antwort (engl. Response) - Prinzip. Möchte sich ein Client an einem Server
authentifizieren, so sendet dieser eine Challenge, die der Client beantworten muss und
nur durch die richtige Antwort kann die Authentifizierung erfolgreich abgeschlossen
werden. Hierfür können sowohl symmetrische als auch asymmetrische
kryptographische Verfahren eingesetzt werden.
In Abbildung 6 wird eine Challenge-Response-Authentifizierung mittels eines
asymmetrischen Verfahrens veranschaulicht.
3. Authentifizierung und Autorisierung
- 28 -
Abbildung 6: Asymmetrische Challenge-Response-Authentifizierung, vgl. [B_KAPPE1], S. 51
Um die Sicherheit der Challenge-Response-Authentifizierung zu steigern ist es möglich,
diese mehrstufig durchzuführen. In diesem Fall wird das gerade skizzierte Verfahren
mehrfach wiederholt. Dies stellt für Angreifer eine fast nicht zu überwindende Hürde
dar, denn für jeden Authentifizierungsvorgang wird eine neue Kennung generiert.
Je nachdem welcher Zufallszahlengenerator verwendet wird und welche Qualität die
generierten Zufallszahlen haben, können diese unter Umständen im Vorfeld berechnet
werden, was eine potenzielle Schwachstelle des Verfahrens darstellt.
(Vgl. [B_KAPPE1] und [B_ECKER1])
3.2 Autorisierung
„Autorisierung bezeichnet die Zuweisung von Zugriffsrechten auf IT-Ressourcen […]“,
Richter ([B_RICHT1], S. 6). Die Zugriffsrechte können nur von authentifizierten und
mit den notwendigen Rechten bzw. Privilegien ausgestatteten Nutzern an andere
berechtigte Nutzer vergeben werden.
3.2.1 Discretionary Access Control (DAC)
Discretionary Access Control basiert auf der Vergabe bzw. dem Entzug von Rechten
auf Objekte. Dabei geht man davon aus, dass ein Nutzer, welcher ein Objekt anlegt, alle
Server B generiert zufälliges X Server B sendet X an Client A
Client A Server B
Client A verschlüsselt X
mittels privatem Schlüssel Entschlüsselt X’ durch
öffentlichen Schlüssel von Client A
und vergleicht X und X’ OK
Hallo ich bin Client A
Voraussetzung: Client A verfügt über ein Public-Key-Schlüsselpaar und Server B besitzt den öffentlichen Schlüssel von A
3. Authentifizierung und Autorisierung
- 29 -
Rechte für dieses Objekt besitzt und dass dieser anderen Nutzern Rechte für seine
Objekte einräumen kann.
Welche Rechte ein Nutzer für bestimmte Objekte besitzt, kann am einfachsten in einer
Zugriffsmatrix abgespeichert werden. „Abhängig von der Granularität der Autorisierung
können Zugriffsmatrizen allerdings sehr groß werden“, Kemper ([B_KEMPE1],
S. 339). Werden einem Objekteigentümer alle Rechte für eines seiner Objekte entzogen,
so ist dieses Objekt auch für keinen anderen Nutzer mehr erreichbar. (Vgl.
[B_FERRA1], [I_PLANE1] und [I_ENGEL1])
3.2.2 Mandatory Access Control (MAC)
Bei Mandatory Access Control werden basierend auf dem Bell-LaPadula Modell
„jedem Subjekt s […] eine Sicherheitsklasse, die so genannte Clearance […] und jedem
Objekt o […] eine Sicherheitsklassifikation, die so genannte Classification […]
zugeordnet.“, Eckert ([B_ECKER1], S. 126). Beim Lesen und Schreiben von Objekten
durch Subjekte werden deren Sicherheitseinstufungen verglichen:
Für das Lesen gilt, dass das Objekt einer Menge von Subjekten untergeordnet ist
und eine geringere oder gleiche Sicherheitseinstufung besitzt.
Für das Schreiben gilt, dass ein Subjekt einer Menge von Objekten
untergeordnet ist und es eine höhere oder gleiche Sicherheitseinstufung besitzt.
Jedes Subjekt und jedes Objekt muss eingestuft werden. Dies kann bei großen sich
schnell ändernden Datenmengen sehr aufwendig und problematisch werden. Des
Weiteren wird ein Objekt, welches durch ein Subjekt mit höherer Sicherheitseinstufung
bearbeitet wird, automatisch mit der höheren Einstufung versehen. Dies führt dazu, dass
geringer eingestufte Subjekte nicht mehr auf das geänderte Objekt zugreifen können.
(Vgl. [B_KEMPE1], [B_FERRA1], [I_PLANE1] und [I_ENGEL1])
3. Authentifizierung und Autorisierung
- 30 -
3.2.3 Role-based Access Control (RBAC)
In DBMS werden Nutzern in der Regel bestimmte Rollen zugeordnet, die bestimmte
Rechte auf Objekte vereinen. Man spricht hierbei auch von Role-based Access Control
(RBAC). Eine Rolle „repräsentiert die Funktion eines Benutzers in einem System und
beinhaltet die zur Erfüllung der Funktionen notwendigen Rechte“, Kemper
([B_KEMPE1], S. 339). In den SQL-99 Standards ist dieses Konzept enthalten. Mit
dieser Verfahrensweise versucht man die komplexen Mengen von Zugriffsrechten in
deren Definition und Verwaltung zu vereinfachen.
Man kann Rollen auch hierarchisch aufbauen und so innerhalb einer Datenbank eine
organisatorische Struktur abbilden. Dadurch besitzen übergeordnete Rollen alle Rechte
der Untergeordneten. Hierbei spricht man von impliziter Autorisierung. Dieses Prinzip
baut auf den expliziten Rechten jeder einzelnen Rolle auf, welche dann implizit
weitergereicht werden. Werden bestimmte Rechte einer Rolle entzogen, so verlieren
auch die untergeordneten Rollen diese Rechte.
(Vgl. [B_FERRA1] und [I_PLANE1])
4. Web-Technologien und spezielle Angriffstechniken
- 31 -
4. Web-Technologien und spezielle Angriffstechniken
Dieses Kapitel beschäftigt sich mit Technologien, die in Verbindung mit dem WWW
verwendet werden und deren Sicherheitsaspekten. Des Weiteren werden verschiedene
vom WWW ausgehende Bedrohungen erläutert und entsprechende Gegenmaßnahmen
besprochen.
Eine Klassifizierungsmöglichkeit für Web-Technologien und Softwareprodukte ist die
Einteilung nach Closed Source und Open Source. Dabei wird Software, deren
Quellcode nicht öffentlich zugänglich ist, als Closed Source bezeichnet. Bei den
meisten kommerziellen Softwareprodukten (proprietäre Software) ist dies der Fall. Des
Weiteren ist auch das Wiederherstellen des Quellcodes aus dem lauffähigen Programm
meistens durch die dazugehörigen Lizenzbestimmungen verboten.
Bei Open Source Software wird der Quellcode offen gelegt. Dadurch ist es möglich
Open Source Software selbständig zu verändern, zu verbessern und diese dann wieder
zu veröffentlichen. Dies ist auch in den Definitionen der Open Source Initiative (OSI)
und der Free Software Foundation (FSF) benannt. Laut diesen Definitionen stehen
einem Benutzer außerdem noch die nachfolgenden Freiheiten zu:
• die Software darf für beliebige Zwecke verwendet werden,
• der Quellcode darf studiert werden, um herauszufinden wie das Programm
funktioniert,
• die Software darf uneingeschränkt an Dritte weitergegeben werden.
Dennoch gibt es auch im Open Source Bereich verschiedene Lizenzen, von denen
einige in der nachfolgenden Tabelle aufgeführt werden. Hierbei besagt das „Copyleft
[...], dass sämtliche Änderungen und Weiterentwicklungen einer Open-Source-Software
nur unter der gleichen Lizenz als freie Software weitergegeben werden dürfen“
[I_KLEIJ1].
4. Web-Technologien und spezielle Angriffstechniken
- 32 -
Tabelle 5: Open Source Lizenzen, nach [I_KLEIJ1]
Art des Copyleft Starkes Copyleft Schwaches Copyleft Kein Copyleft Kombinations-möglichkeiten mit proprietärer Software
keine Einbindung in proprietären Code möglich
statisches und dynamisches Linken von Code mit proprietärer Software möglich.
Eigenentwicklungen möglich
dürfen als proprietäre Software weitergegeben werden
keine Vorgaben.
der gesamte Code darf auch als proprietäre Software weitergegeben werden
Beispiel-Lizenz GPL LGPL, MPL BSD, Apache
4.1 Sicherheitsaspekte webbasierter Technologien
Es gibt im WWW verschiedene Möglichkeiten Informationen, Daten und ganze
Anwendungen zu präsentieren bzw. auszutauschen. Hierzu wurden im Laufe der Jahre
verschiedene Technologien entwickelt, die es ermöglichen, vielfältige Inhalte (z.B.
Texte, Videos oder Musik) zu präsentieren bzw. zu verarbeiten. Dabei stellt HTML die
grundlegendste Technologie zum Darstellen dieser Inhalte im WWW dar. HTML wird
von anderen Technologien als Ausgabesprache verwendet, da sie von allen gängigen
Browsern unterstützt wird.
Die verschiedenen Technologien lassen sich in client- und serverseitige Technologien
differenzieren. Bei clientseitigen Technologien wird die gesamte Anwendung vom
Webserver heruntergeladen und beim Client zur Ausführung gebracht. Technologien
hierfür sind beispielsweise clientseitige Skriptsprachen wie JavaScript oder VBScript,
sowie Flash, Java-Applets oder ActiveX.
Bei serverseitigen Technologien wird die eigentliche Anwendung auf dem Server
ausgeführt. Der Client stößt durch seine Anfragen die serverseitige Abarbeitung an und
erhält lediglich das Ergebnis seiner Anfrage, meist in Form eines HTML- oder XML
(Extensible Markup Language)-Dokumentes. Zu den serverseitigen Technologien
zählen unter anderem SSI (Server Side Includes), ASP (Active Server Pages), JSP (Java
Server Pages) sowie serverseitige Skriptsprachen wie PHP, Ruby oder Python.
4. Web-Technologien und spezielle Angriffstechniken
- 33 -
Aus den letzten beiden Skriptsprachen haben sich in den vergangenen Jahren zwei sehr
bekannte Frameworks zur agilen Webprogrammierung entwickelt, Ruby on Rails für
Ruby und Django für Python.
In den nachfolgenden Unterkapiteln werden einige der oben aufgeführten Technologien
kurz vorgestellt und hinsichtlich ihrer Sicherheit diskutiert. Dabei wird das
Sicherheitsmodel der verschiedenen Java-basierten Technologien bereits im
nachfolgenden Abschnitt erläutert und nicht bei den Technologien separat aufgeführt.
Die Programmiersprache Java ist eine sehr mächtige, von Sun Microsystems
entwickelte objektorientierte Programmiersprache, für die zahlreiche
Zusatzbibliotheken im WWW verfügbar sind. Es steht allen in Java über die J2EE-
Plattform entwickelten Programmen, beispielsweise die JDBC-Schnittstelle zur
Verfügung. Diese ermöglicht einen problemlosen Datenbankzugriff auf alle bekannten
Datenbanksysteme.
Zu den clientseitigen Java-Technologien gehören beispielsweise die Java-Applets und
JavaBeans. Zu den serverseitigen zählen unter anderem die Java-Servlets und Java
Server Pages.
Bei der Entwicklung von Java stand von Beginn an die Sicherheit des jeweiligen
Zielrechners, auf dem die Anwendung ausgeführt werden soll, im Blickpunkt. Das
bedeutet unter anderem, dass das Ausführen von sicherheitskritischen Operationen
kontrollierbar sein soll. Sun entwickelte deshalb das Prinzip der “Sandbox“. Dieses
beinhaltet, dass die jeweilige Anwendung in einer durch den Benutzer kontrollierbaren
eingeschränkten Laufzeitumgebung ausgeführt wird, der so genannten Java Virtual
Machine (JVM). Die JVM interpretiert den Java-Byte-Code, in dem die jeweilige
Anwendung vorliegt, in einen systemspezifischen Maschinencode und bringt diesen zur
Ausführung. Hierbei kann die Anwendung in der Regel nicht auf Systemressourcen
außerhalb der Laufzeitumgebung zugreifen. (Vgl. [B_ULLEN1] und [I_SUNSA])
4. Web-Technologien und spezielle Angriffstechniken
- 34 -
4.1.1 clientseitige Technologien
Java-Applets
Java-Applets sind eigenständige lauffähige Programme, die als vorkompilierter Byte-
Code auf dem Web-Server gespeichert sind. Auf Anfrage eines Web-Clients werden die
in HTML-Seiten eingebetteten Applets vom Web-Server an den Client übermittelt, dort
von der JVM interpretiert und zur Ausführung gebracht.
Das Verwenden von Java-Applets setzt eine JVM auf dem Clientrechner voraus. Diese
ist entweder ein fester Bestandteil des jeweiligen Browsers oder muss als zusätzliches
PlugIn installiert werden.
Der Datenbankzugriff erfolgt mittels JDBC-API, einer standardisierten Java-
Schnittstelle für den Zugriff auf Datenbanken. Durch die Verwendung der JDBC-
Schnittstelle ist ein direkter Zugriff auf den Datenbankserver möglich, wodurch der
Web-Server von zusätzlichem Datentransfer entlastet wird. (Vgl. [B_RAHMx1] und
[B_MEINE1])
Eine der größten Gefahren in der Verwendung von Applets ist deren unbekannte
Herkunft, das heißt es lässt nicht sich einwandfrei feststellen, von welcher Quelle ein
Applet bzw. dessen Bestandteile geladen werden. Dadurch besteht die Gefahr, dass
beispielsweise schädliche Programme oder Viren auf den jeweiligen Rechner her-
untergeladen werden können.
Dieses Problem versucht man durch so genannte „Signed Applets“ zu minimieren.
„Signed Applets“ sind digital signierte Applets, bei denen durch die Prüfung der
Signatur festgestellt werden kann, wer den jeweiligen Code signiert hat und ob er
seitdem verändert wurde. Da die verschiedenen Hersteller wie Sun, Microsoft oder
Netscape unterschiedliche Techniken für signierte Applets entwickelt und implementiert
haben, ist es nicht möglich, ein signiertes Applet für alle Plattformen zu generieren.
(Vgl. [V_RAHMx1], [B_MEINE1], [I_GREEN1] und [I_SUNJA1])
4. Web-Technologien und spezielle Angriffstechniken
- 35 -
ActiveX
Das von Microsoft entwickelte ActiveX kann als ein Komponentensystem betrachtet
werden, welches nicht auf eine Programmiersprache beschränkt ist. Die einzelnen
Komponenten können beispielsweise in C, C++ oder auch Java programmiert werden.
Alle verwendeten Komponenten müssen nur auf dem Component Object Model (COM)
basieren, einer Plattform-Technologie.
Das Herzstück von ActiveX Kompositionen stellt das so genannte ActiveX-Control-
Objekt dar. Dieses Control-Objekt wird in HTML-Seiten eingebettet und clientseitig in
dessen Arbeitsspeicher zur Ausführung gebracht. Dabei ist zu beachten, dass ActiveX
von dem Clientbrowser unterstützt wird und aktiviert sein muss.
Das Sicherheitskonzept beruht auf dem „Alles oder Nichts“-Prinzip, denn der Nutzer
kann eine ActiveX-Anwendung entweder zulassen oder blockieren. Wird die jeweilige
Anwendung zugelassen, besitzt diese vollen Zugriff auf das lokale Dateisystem.
Wie bereits bei den Java-Applets erwähnt, besteht auch hier die Gefahr, dass man nicht
genau feststellen kann, von wem die ActiveX-Anwendung entwickelt wurde. Man
versucht deshalb durch das Erstellen von signierten ActiveX-Anwendungen die
Vertrauenswürdigkeit zu erhöhen.
Durch die systemspezifische Entwicklung und Optimierung für die Microsoft-
Plattformen besitzen ActiveX-Anwendungen gegenüber vergleichbaren Java-
Anwendungen einen Geschwindigkeitsvorteil. (Vgl. [B_RAHMx1], [I_MACKx1],
[I_MICRO1] und [I_SELFH1])
4.1.2 serverseitige Technologien
ASP .Net (Active Server Pages .NET)
ASP .NET ist eine Closed Source Technologie der Firma Microsoft, welche auf dem
.NET-Framework basiert. Das .NET-Framework erlaubt, Anwendungen in einer
beliebigen, von .NET unterstützten Programmiersprache zu schreiben. Zu diesen
Sprachen gehören unter anderem JScript, VScript oder auch C#.
4. Web-Technologien und spezielle Angriffstechniken
- 36 -
Hierbei wird eine strikte Trennung zwischen Anwendungslogik bzw. Programmcode
und dem Design vorgenommen. So ist es möglich, HTML-Seiten mit Cascading Style
Sheets (CSS) und JavaScript unabhängig von der Anwendungslogik zu entwickeln. Es
werden lediglich in die HTML-Seiten spezielle HTML Controls eingefügt, die als
Platzhalter dienen. HTML Control-Objekte sind Standardobjekte, wie z.B. Buttons oder
auch Eingabefelder, in deren Tags eine eindeutige ID sowie der Zusatz runat=“server“
eingefügt wird.
Auf diese Objekte kann das ASP .NET Programm zugreifen und dessen Eigenschaften
bearbeiten und anschließend die so generierte HTML-Seite dem Client zur Verfügung
stellen. Der Datenbankzugriff erfolgt durch die .NET-Klasse ActiveX Data Objects
.NET (ADO.NET).
Die Kommunikation zwischen den Web-Clients und ASP .Net Anwendungen erfolgt
über den Internet Information Services (IIS), welches zum Authentifizieren von
Ressourcen genutzt werden kann. Somit lässt sich mittels IIS eine Authentifizierung
und Autorisierung von Web-Clients realisieren. Es lassen sich zusätzlich auch die
Sicherheitsfeatures des .NET Framework verwenden. Darauf wird an dieser Stelle
jedoch nicht näher eingegangen. (Vgl. [I_MICRO2], [B_MEINE1] und [B_RAHMx1])
Java Servlets
Java Servlets sind auf der Java Plattform basierende Technologien, mit denen sich Web-
Server beliebig erweitern lassen. Ein in Java geschriebenes Servlet liegt auf dem Web-
Server vor und wird von dessen JVM beim ersten Aufruf oder gleich beim Start des
Servers interpretiert.
Die spezielle Servlet-Engine auf dem Web-Server ermöglicht bzw. vereinfacht die
Kommunikation zwischen verschiedenen Servlets, vor allem, wenn sie in derselben
Laufzeitumgebung gestartet werden. Es ist aber auch möglich mit mehreren JVM zu
arbeiten, um eine Lastverteilung des Web-Servers zu erreichen.
Bei Java Servlets ist eine Trennung von Logik und Design nur schwer möglich, da die
HTML-Tags mit in die Java-Klassen des Servlets eingebettet werden müssen. Um
dieses Problem zu lösen wurden die Java Server Pages (JSP) entwickelt, die eine
4. Web-Technologien und spezielle Angriffstechniken
- 37 -
Erweiterung der Servlet Technologie darstellen. (Vgl. [B_ULLEN1], [I_STELL1] und
[I_SUNJS1])
JSP (Java Server Pages)
JSP trennen Logik und Design voneinander. Es ist demnach möglich, eine statische
Web-Seite zu entwickeln und durch das Einfügen von speziellen Tags diese dann um
dynamische Elemente zu erweitern.
Wird ein JSP-Skript von einem Client aufgerufen, so übersetzt die auf dem Web-Server
installierte JSP-Engine dieses in ein Java Servlet und führt es aus. Nach der erstmaligen
Übersetzung eines Skriptes wird die erzeugte Klasse von der Servlet-Engine verwendet
und wie ein normales Servlet behandelt. (Vgl. [B_ULLEN1], [I_LEITE1] und
[I_SUNSP1])
Serverseitige Skriptsprachen
Skriptsprachen haben sich aus den Kommandosprachen heraus entwickelt. Dabei wird
eine Reihe von Kommandos in einer Datei zusammengefasst, die dann zur Laufzeit
interpretiert und ausgeführt werden.
Für das WWW existieren verschiedene Skriptsprachen, dazu zählen z.B. Perl, PHP oder
Ruby. Skriptsprachen grenzen sich von normalen Programmiersprachen dadurch ab,
dass sie in der Regel interpretiert werden und dass sie entweder schwach oder
vollständig typfrei sind. Typfrei bedeutet, dass die verwendeten Variablen nicht
typgebunden deklariert werden müssen, sondern intern immer den Typ annehmen ,der
erforderlich ist.
Die Entwicklung von Webanwendungen mittels Skriptsprachen erfolgt meist im
Baukasten-Prinzip. Das heißt, man verwendet vorgefertigte, im Internet verfügbare
Module und/oder eigene. Aus diesem Grund gibt es kein einheitliches Sicherheitsmodel.
Es gibt jedoch die verschiedensten sprachspezifischen Sicherheitsmodule, wie z.B. für
PHP Shuhosin. (Vgl. [B_WALTE1], [I_ESSER1] und [I_PFAHL1])
4. Web-Technologien und spezielle Angriffstechniken
- 38 -
4.2 Bedrohungen aus dem WWW
Das WWW bringt neben zahlreichen Möglichkeiten auch vielfältige Gefahren mit sich.
Gefährdet sind vor allem Firmen und Regierungen. Allein gegen Regierungen und
deren Organe richteten sich laut Breach Security, Inc. ([I_BREAC1], S. 8) ca. 32% der
Angriffe. Die Ziele der Angreifer sind von unterschiedlichster Natur, einerseits die reine
Informationsbeschaffung, andererseits das Sabotieren konkreter Systeme und
Anwendungen. Auf die Ziele und die Motivation der Angreifer wird jedoch im Rahmen
dieser Arbeit nicht weiter eingegangen. Einige der derzeitigen Angriffsmethoden
werden in Tabelle 6 nach Breach Security, Inc. ([I_BREAC1], S. 6) dargestellt.
Tabelle 6: Übersicht Angriffsmethoden, vgl. [I_BREAC1], S. 6
Angriffsmethode / ausgenutzte Schwachstellen %
SQL-Injection* 30
Unknown 29
Cross-Site Scripting (XSS)* 8
Cross-Site Request Forgery 3
Operating System Commanding 3
Denial of Service* 3
Brute Force 2
Die mit einem Stern (*) gekennzeichneten Angriffsmethoden werden nachfolgend näher
betrachtet. Diese Angriffe richten sich dabei einerseits gegen das zugrunde liegende
System und andererseits gegen den Endanwender. SQL-Injections sind beispielsweise
spezielle Parametermanipulationen und richten sich gegen das zugrunde liegende
System, ebenso wie Denial of Service (DoS). DoS-Angriffe versuchen die
Verfügbarkeit eines Systems zu unterbrechen. Gegen den Endanwender richtet sich
dagegen zum Beispiel ein Cross-Site Scripting (XSS) Angriff.
4.2.1 Parametermanipulation
Parameter sind veränderbare Werte, die zum Beispiel zwischen Client und Server
ausgetauscht werden. Diese können auf unterschiedliche Art und Weise manipuliert
werden abhängig von ihrer Form, in der sie übergeben werden. Durch die Manipulation
kann ein Angreifer beispielsweise Rechte erhalten, die ihm eigentlich nicht zustehen,
4. Web-Technologien und spezielle Angriffstechniken
- 39 -
und so Zugriff auf sensible Daten erlangen. Des Weiteren kann er gezielt Eingabefelder
dazu verwenden, einen schädlichen Code oder Anweisungen in die Anwendung
einzuschleusen. Beispiele hierfür sind die SQL-Injection sowie XSS, auf die im
weiteren Verlauf der Arbeit näher eingegangen wird. (Vgl. [B_KUNZx1])
Der Autor betrachtet dabei folgende Formen näher:
• URL-Parameter
• Cookies
• Formulardaten
URL-Parameter
Werden Parameter direkt über einen Uniform Resource Locator (URL) von einer
Webseite an den Webserver übermittelt, so ist es für einen Angreifer sehr einfach
möglich, diese zu manipulieren. Man verändert lediglich die URL-Parameterwerte und
wartet die Reaktion des Systems ab. Dies kann beispielsweise dafür genutzt werden,
gezielt Fehler zu provozieren, um an Informationen über die verwendeten Systeme zu
gelangen, welche dann beispielsweise für DoS-Angriffe verwendet werden können.
Eine weitere Möglichkeit ist, dass Angreifer die URL so manipulieren, dass sie Zugriff
auf das Serversystem erlangen, um dort beispielsweise Nutzerdateien auszuspähen.
Um die Gefahr von URL-Parametermanipulation zu minimieren, sollten die
Eingabewerte immer validiert werden. Des Weiteren könnte man Standard-
konfigurationen am System überprüfen. Vor allem sollte es vermieden werden, sensible
Daten wie die Benutzerkennung oder das Klartextpasswort als URL-Parameter zu
übergeben.
Cookies
Bei der Kommunikation zwischen Client und Server werden häufig Cookies auf Seiten
des jeweiligen Client gesetzt. Dadurch wird beispielsweise das Sitzungsmanagement
gesteuert. Diese Cookie-Dateien werden bei jeder weiteren Anfrage des gleichen Clients
mit an den entsprechenden Server übermittelt.
4. Web-Technologien und spezielle Angriffstechniken
- 40 -
Somit kann ein Angreifer durch Manipulation der Cookie-Inhalte versuchen, das
Sicherheitssystem des Servers zu umgehen oder gefährliche Daten an den Server zu
übermitteln. Diese Angriffe werden auch als Cookie Poisoning Angriffe bezeichnet. Mit
dieser Methode kann es außerdem gelingen, Informationen über andere Benutzer zu
erhalten oder deren Identität zu übernehmen.
Zur Vorbeugung dieser Angriffe, sollte das Speichern von sensiblen Daten in Cookies
vermieden und keine permanenten Cookies verwendet werden.
Formulardaten
Formulare bieten einem Nutzer verschiedene Möglichkeiten, z.B. dienen sie zur
Kommunikation mit den Betreibern einer Webseite oder zum Bestellen von Produkten.
Aber auch Angreifer können sich Formulare zu Nutze machen, z.B. zum Einschleusen
von einem Schadcode oder zur Manipulation von Parametern. An dieser Stelle wird auf
SQL-Injection und XSS verwiesen.
Innerhalb von Formularen ist es möglich Eingaben zu tätigen, welche ohne korrekte
Validierung enormen Schaden anrichten können. Dabei stellen nicht nur
alphanumerische Eingabefelder eine potenzielle Gefahr dar, sondern auch vermeintlich
nicht veränderbare Radiobuttons oder Checkboxen, die vom Entwickler mit Werten
vorbelegt sind. Ein Angreifer könnte das Formular lokal speichern, dieses editieren und
entsprechende Attribute oder vorgegebene Werte verändern. Wird ein so verfälschtes
Formular wieder an den Web-Server übertragen, könnte dieses das Verhalten der
Webanwendung verändern bzw. Schaden auf dem Web-Server, Datenbankserver oder
auch bei anderen Clients anrichten.
Um diese Sicherheitslücke zu schließen, ist es notwendig alle Nutzereingaben stets zu
validieren und nie ungeprüft weiter zu verarbeiten. Außerdem können auch Whitelists
dazu verwendet werden, die Eingabevalidierung zu erweitern. Dies bedeutet, dass nur
explizit zugelassene Befehle an den Webserver weitergeleitet werden.
4. Web-Technologien und spezielle Angriffstechniken
- 41 -
4.2.2 SQL-Injection
Durch die hohe Zahl der an das WWW angeschlossener datenbankbasierter
Anwendungen stellen SQL-Injections eine der größten Gefahren dar. Ein Angreifer
versucht hierbei, durch gezielte Parametermanipulation das Verhalten der Datenbank zu
beeinflussen. Diese Beeinflussung reicht von der gezielten Fehlerprovokation bis hin
zur Manipulation eines SQL-Statements. Damit ist ein Angreifer in der Lage auf für ihn
eigentlich nicht zugängige Daten zuzugreifen oder auch verschiedene Datenbank-
operationen auszuführen.
Um eine SQL-Injection durchzuführen, müssen die durch einen Angreifer manipulierten
Eingabeparameter direkt in ein SQL-Statement eingebunden sein und dieses nicht bzw.
unzureichend validiert an die Datenbank gesendet werden. Ist dies der Fall, so hat der
Angreifer bei einfachen SQL-Injections Zugriff auf die im originalen Statement
aufgeführten Tabellen bzw. Spalten. Dadurch ist der Angreifer in der Lage, die darin
enthaltenen Daten auszulesen, zu ändern oder zu löschen. Dies kann sich gegebenenfalls
auf die gesamte restliche Datenbank auswirken. Nachfolgendes Beispiel, angelehnt an
Kunz und Esser ([B_KUNZx1], S. 121 – 133), verdeutlicht dies. $sql = “SELECT * FROM user WHERE user_id =“.$_GET[‘id‘];
Der Parameter id wird ungeprüft an das SQL-Statement übergeben. Im harmlosesten Fall wurde
nur der numerische Wert dieses Parameters in einen anderen numerischen verändert. Es ist aber
auch möglich, anstatt einen numerischen Wert einen Zeichenkettenstring zu übergeben.
Durch ein Semikolon “;“ könnte das SELECT-Kommando abgeschlossen und ein anderes
Kommando angefügt werden. So könnte der Wert des Parameters id, z.B. wie folgt aussehen:
„1; DELETE FROM user“.
Das somit zur Ausführung an die Datenbank zu sendende SQL-Statement wäre:
SELECT * FROM user WHERE user_ID=1; DELETE FROM user;
Die Ausführung dieses Statements hätte somit zwei Ergebnisse, als erstes würden von der
Datenbank alle Daten zurückgeliefert werden, die der user_ID 1 zugeordnet sind. Das zweite
Ergebnis wäre das Löschen aller Daten aus der Tabelle user.
Neben den einfachen SQL-Injections können Angreifer noch die aufwendigere UNION-
Injection durchführen. Damit ist es möglich, auf sämtliche Tabellen der Datenbank
zuzugreifen. Hierfür sind jedoch spezielle Kenntnisse zu den in der Datenbank
4. Web-Technologien und spezielle Angriffstechniken
- 42 -
verwendeten Tabellen sowie Strukturen notwendig. Die UNION-Injections werden im
Folgenden nicht näher beleuchtet.
Zur Verhinderung von einfachen SQL-Injections sollten sämtliche Eingabe-
/Übergabeparameter validiert werden. Auch die Verwendung von Stored Procedures
und definierten Funktionen bieten zusätzlichen Schutz.
Eine weitere Möglichkeit ist es, die Syntax eines SQL-Statements komplizierter zu
gestalten. Hierfür können runde Klammern eingesetzt werden. Für einen Angreifer
gestaltet sich eine SQL-Injection nun schwieriger, da zu jeder sich öffnenden auch eine
schließende Klammer gesetzt werden muss.
Zur Eingabevalidierung von SQL-Statements bieten einige Web-Technologien
Funktionen an, die gefährliche Sonderzeichen filtern und diese maskieren. Mit
Maskieren ist das Unschädlichmachen von Sonderzeichen gemeint, so dass diese keinen
Einfluss mehr auf die Datenbank haben. Ist dies nicht der Fall, muss die
Eingabevalidierung durch eigene Funktionen abgedeckt werden. Um das Beispiel von oben, sicherer gegen SQL-Injections zu gestalten bzw. diese zu erschweren
könnten Klammern gesetzt werden. $sql = “SELECT * FROM user WHERE (user_id =“.$_GET[‘id‘].“)“;
Durch die umschließenden Klammern erzeugt der Ausdruck „1; DELETE FROM user“ einen
Fehler, da die öffnende Klammer nicht geschlossen wurde und somit wird der Befehl nicht
ausgeführt. Dies schützt ein SQL-Statement nicht vor SQL-Injections, erschwert diese aber.
PHP bietet zur Verhinderung von SQL-Injections Funktionen, welche die Sonderzeichen in
einem Statement maskieren. Für MySQL-Datenbanken wäre dies z.B. die Funktion
mysql_real_escape_string() und für PostgreSQL-Datenbanken pg_escape_string().
4.2.3 Denial of Service (DoS)
Diese Angriffe richten sich gegen die Verfügbarkeit von Systemen oder Diensten,
wobei sie in verschiedenen Ausprägungen auftreten. Diese sind in nachfolgender Liste
in Anlehnung an Bless ([B_BLESS1] S. 17-18) dargestellt:
4. Web-Technologien und spezielle Angriffstechniken
- 43 -
• physikalische Angriffe
Bei dieser Art von Angriffen werden entweder gezielt das jeweilige
Übertragungsmedium (z.B. Netzwerkkabel oder drahtlose Medien) oder die
jeweiligen Endsysteme bzw. die Übertragungseinrichtungen gestört bzw.
zerstört. Das bedeutet, dass diese Methode des Angriffes immer dann möglich
ist, wenn der Angreifer physischen Zugriff erlangen kann.
Um diese Angriffe zu verhindern, muss der Zugang zu den
Übertragungseinrichtungen, Endsystemen und den Übertragungsmedien
überwacht und kontrolliert werden.
• Ausnutzung von Implementierungsschwächen
Um Implementierungsschwächen eines Systems ausnutzen zu können, benötigt
der Angreifer Informationen über die zugrunde liegenden Systeme einer
Anwendung. Diese Informationen kann er durch das gezielte Provozieren von
Fehlern erlangen, sofern die vom System zurückgelieferten Fehlermeldungen
entsprechend ausführlich und umfangreich sind.
Implementierungsschwächen einer Anwendung lassen sich nie hundertprozentig
ausschließen. Deshalb ist die wirkungsvollste Gegenmaßnahme, nur minimale
Informationen sowie Fehlermeldungen preiszugeben.
• Ausnutzung von Protokollschwächen
Hierbei macht sich der Angreifer Schwächen in den zugrunde liegenden
Kommunikationsprotokollen zu Nutze. Da von DoS-Angriffen sämtliche
Implementierungen betroffen sein können, werden neuere Protokolle mit den
notwendigen Sicherheitsanforderungen versehen.
• Erzeugen von Ressourcenmängeln
Bei diesen Angriffen unterscheidet man zwei Kategorien. Zum einen Angriffe
auf Netzebene, die darauf zielen ein ganzes Netzwerk bzw. Teilnetze zu
überlasten und so deren Funktionsfähigkeit einzuschränken. Zum anderen
Angriffe auf Anwendungsebene, bei denen versucht wird ein System gezielt zu
überlasten, so dass die Bearbeitungsdauer von Anfragen länger dauert als die
Zeitspanne zwischen zwei Anfragen. Die Problematik ist das Erkennen dieser
Angriffsarten, da Überlastungen auch im normalen Betrieb auftreten können.
4. Web-Technologien und spezielle Angriffstechniken
- 44 -
Es ist schwer DoS-Angriffe als solche zu erkennen und entsprechend gezielte
Gegenmaßnahmen einzuleiten. Durch verschiedene Maßnahmen ist es dennoch
möglich, das Risiko zu reduzieren. Zu diesen Maßnahmen zählen beispielsweise:
• Netzwerkorganisation so einfach wie möglich halten
• zeitnahes Installieren von Patches zum Schließen von Implementierungs-
schwächen
• Verwenden von Firewallsystemen
• Abschalten unnötiger Dienste
(Vgl. [B_BLESS1] und [B_KUNZx1])
4.2.4 Cross-Site Scripting (XSS)
Auch diese Angriffstechnik nutzt die Manipulation von Parametern. Dabei ist jedoch
nicht der Web- oder Datenbankserver Angriffsziel, sondern der Clientbrowser.
Angreifer versuchen durch gezielte Platzierung von Schadcodescripten, beispielsweise
als interessant klingender Link oder als Bild getarnt, die Nutzer dazu zu bringen, den
Link oder das Bild anzuklicken und so die Ausführung des Skriptes anzustoßen. Gelingt
dies ist es einem Angreifer unter anderem möglich, unbemerkt an gespeicherte
Nutzercookies zu gelangen und so einen Session-Hijacking Angriff auszuführen.
Hierbei übernimmt der Angreifer durch den Besitz der gültigen Cookiedaten die
Identität des eigentlichen Nutzers gegenüber dem jeweiligen Servers.
Diese Angriffe lassen sich durch das Verbot und Blockieren von Script-Tags in Foren
und Gästebüchern verhindern.
5. THEREDA: Ausgangsituation und Anforderungen
- 45 -
5. THEREDA: Ausgangsituation und Anforderungen
Innerhalb dieses Kapitels wird das THEREDA Projekt vertieft vorgestellt und auf die
aktuell verwendeten Technologien eingegangen. Anschließend werden die einzelnen
Nutzergruppen definiert und die jeweiligen Aufgabenbereiche, durch ihre verschiedenen
Funktionalitäten, von einander abgegrenzt. Abschließend werden die Nicht-funktionalen
Anforderungen definiert.
5.1 Ziele und Nutzen von THEREDA
Bei dem THEREDA (Thermodynamische Referenzdatenbasis) Projekt handelt es sich
um ein Verbundprojekt. Innerhalb dieses Projekts bilden die fünf Projektpartner (die
Gesellschaft für Anlagen- und Reaktorsicherheit (GRS), das Institut für Nukleare
Entsorgung (INE) des Forschungszentrums Karlsruhe, das Institut für Radiochemie
(IRC) des Forschungszentrums Dresden-Rossendorf, das Institut für Anorganische
Chemie der TU Bergakademie Freiberg sowie die AF-Colenco AG (Baden/CH)) den
Kreis von Experten, die vorhandene thermodynamische Stoffgrößen für Schadstoffe
und relevante Matrixelemente (der Wirtsgesteine) sammelt, nach einheitlich vorher
festgesetzten Kriterien bewertet und diese in der THEREDA Datenbank zusammenfasst.
Ziel ist es, eine einheitliche, konsistente und qualitätsgesicherte thermodynamische
Referenzdatenbasis für geochemische Modellierungen bereitzustellen. Deren
vorrangiges Anwendungsprofil ist der Schadstofftransport von Actiniden und
radioaktiven Aktivierungs- und Zerfallsprodukten im Kontext der
Langzeitsicherheitsanalyse für nukleare Endlager. Des Weiteren soll die Datenbasis
auch bei der Planung von Untertagedeponien chemisch-toxischer Abfälle oder bei der
Entwicklung von Sanierungsmaßnahmen für Altlasten und Kontaminationen zur
Anwendung kommen.
Durch das THEREDA Projekt soll eine einheitliche Datenbasis bereitgestellt werden,
die es ermöglicht Modellierungsergebnisse zu beurteilen oder mit Modellierungen
anderer Institutionen zu vergleichen. Dies ist aktuell nicht möglich, da praktisch jede
5. THEREDA: Ausgangsituation und Anforderungen
- 46 -
gutachterlich tätige Institution mit einer „hausinternen“ Datenbasis arbeitet, die je nach
Aufgabenstellung mit gerade verfügbaren Daten erweitert oder modifiziert wird.
Die durch das THEREDA Projekt zusammengetragene Datenbasis soll der
interessierten Öffentlichkeit durch eine Webpräsenz (www.thereda.de) und spezielle
dort verfügbare Werkzeuge zugänglich gemacht werden.
5.2 Ausgangssituation
In der Diplomarbeit „Konzeptioneller Entwurf und prototypische Realisierung einer
Datenbanklösung für chemische Risikoanalysen“ von Herrn Münzberg (06.08.2007,
HTW Dresden, [S_MÜNZB1]) sowie weiteren internen Dokumenten des THEREDA-
Projektes wurden die grundlegenden Architekturen der THEREDA Datenbank, sowie
der Webanwendung geschaffen. Diese besteht aus einem Apache-Webserver, dem
Content Management System (CMS) Joomla! und einer MySQL-Datenbank, welche
die Voraussetzung für den Betrieb von Joomla! bildet. Das entwickelte
Datenbankschema von THEREDA wurde in PostgreSQL implementiert. Des Weiteren
wurden erste einfache PHP-Seiten gestaltet, welche die THEREDA Webanwendung
darstellen und die aktive Interaktion zwischen Datenbankserver und Client im Rahmen
einfacher Datenbankabfragen ermöglichen.
Die Dateneingabe hingegen lief bisher Offline, über eine lokal installierte MS-Excel
Applikation ab. Bei Eingaben-Kampagnen wurden zuerst der Datenbestand in MS-
Excel mit der jeweiligen THEREDA Datenbasis synchronisiert, alle notwendigen
Eingaben in MS-Excel realisiert und die neue Datenbasis (als MS-Excel Datei) an den
Projektkoordinator per Email gesandt. Dieser führte dann diverse Konsistenzchecks
durch, nach deren erfolgreicher Absolvierung aus der MS-Excel Datei automatisiert
SQL-Statements zur Dateneingabe bzw. –änderung geniert und z.B. mittels
phpPgAdmin an die THERDA-Datenbasis in PostgreSQL übermittelt wurden.
Diese Verfahrensweist erweist sich jedoch als ineffizient und fehleranfällig und
deswegen sind dringend grundlegende Veränderungen notwendig.
5. THEREDA: Ausgangsituation und Anforderungen
- 47 -
Abbildung 7: THEREDA: Web-Architektur
In der aktuellen Projektphase wurden die implementierten Versionen der einzelnen
Technologien aktualisiert. Diese Änderungen sind in nachfolgender Tabelle dargestellt.
Die Aktualisierungen ermöglichen es, bekannte Schwachstellen/Bugs der älteren
Versionen zu schließen. Daneben stehen auch neue Funktionen und Erweiterungen zur
Verfügung. Einzelheiten hierfür sind auf den Internetseiten der Technologien zu finden,
z.B. [I_POSTG1] oder [I_PHPGR1].
Tabelle 7: THEREDA: Versionsänderungen
Technologie Ausgangssituation August 2007
Aktueller Versionstand: Oktober 2009
Apache 2.0 2.2.10
Joomla! 1.0.12 1.5.14
MySQL
(Voraussetzung für Joomla!)
5.0 5.0.67
PostgreSQL 8.1.8 8.3.7
PHP 4.4.4-8 5.2.9
phpPgAdmin 4.1.1 4.2.2
Anwendungsdateien Content Management System
Datenbankserver Datenbankserver
Webserver
Client
Internet
5. THEREDA: Ausgangsituation und Anforderungen
- 48 -
5.3 Funktionale Anforderungen
Funktionale Anforderungen an das Anwendungssystem beschreiben die Funktionen und
Features, die dieses enthalten soll. Hierfür wird nachfolgend zwischen
Benutzerfunktionen und Systemfunktionen unterschieden.
Die Benutzerfunktionen lassen sich in bestimmte Aufgabenbereiche gliedern. Jedem
Aufgabenbereich kann eine Nutzergruppe zugeordnet werden. Hierbei lässt sich
zwischen aktiven und passiven Gruppen unterscheiden.
Passive Gruppenmitglieder sind in der Lage, bestimmte Daten einzusehen und zu
verarbeiten, wohingegen aktive Nutzer die Daten bzw. das Datenbankschema
manipulieren (hinzufügen, ändern oder löschen) können. Nachfolgend wird die
hierarchische Organisation der Nutzergruppen dargestellt und jede kurz definiert.
Abbildung 8: THEREDA: Nutzergruppendiagramm
• unregisteredUser
Als unregisteredUser ist jeder Besucher (engl. Visitor) der THEREDA
Webpräsenz zu verstehen, der keinen gültigen Nutzeraccount besitzt. Die
Webpräsenz wird dabei durch Joomla! bereitgestellt und ermöglicht den
Besuchern, sich über das THEREDA Projekt zu informieren.
auditor
author
registeredUser
unregisteredUser
systemAdministrator
accessAdministrator aktiv
passiv
5. THEREDA: Ausgangsituation und Anforderungen
- 49 -
• registeredUser
RegisteredUser besitzen einen gültigen Nutzeraccount. Sie sind in der Lage, die
THEREDA Webanwendung zu nutzen, das heißt Datenabfragen innerhalb der
THEREDA Datenbank durchzuführen.
• author
Mitglieder der Gruppe author können aktiv mit der THEREDA Datenbank
arbeiten. Sie sind in der Lage, Datensätze zu erstellen, zu ändern und zu
kontrollieren.
• auditor
Die Nutzergruppe auditor hat vorrangig die Aufgabe, die Qualität der in der
THEREDA Datenbank enthaltenen Datensätze sicherzustellen und die
inhaltliche Verantwortung für die Datensätze aufrecht zu erhalten.
• accessAdministrator
Der accessAdministrator übernimmt die Verwaltung der Nutzer und deren
Zuordnung in die einzelnen Nutzergruppen. Dies wird auf Joomla! Ebene
umgesetzt.
• systemAdministrator
Kernaufgabe eines systemAdministrator stellt die Sicherstellung der
Verfügbarkeit und Funktionstüchtigkeit der THEREDA Datenbank dar. Des
Weiteren ist ein systemAdministrator in der Lage, Erweiterungen, Anpassungen
und Optimierungen am Datenbankschema vorzunehmen.
Benutzerfunktionen
Benutzerfunktionen beschreiben die Interaktionsmöglichkeiten zwischen Nutzer und
Anwendung. Dabei ist jeder Nutzer einer Nutzergruppe zugeordnet, die einen
definierten Aufgabenbereich besitzt. Dadurch lassen sich die Benutzerfunktionen den
Aufgabengebieten der Nutzergruppe zuordnen.
5. THEREDA: Ausgangsituation und Anforderungen
- 50 -
Tabelle 8: THEREDA: Benutzerfunktionen, nach Nutzergruppen geordnet
Nutzergruppe Funktion
Kurzbeschreibung
unregisteredUser
Registrieren
Diese Funktion ermöglicht das Registrieren eines Besuchers für die THEREDA Webanwendung. Um diese Funktion erfolgreich abzuschließen, ist eine Bestätigung/Freischaltung durch einen accessAdministrator notwendig.
registeredUser
Login
Das Login dient zur Authentifizierung eines Nutzers und zur Spezifizierung der jeweiligen Gruppe und der damit verbundenen Rechte.
Passwort vergessen Falls ein Nutzer sein Passwort vergessen hat und sein Nutzerkonto noch aktiv ist, hat er die Möglichkeit sich einen neuen Aktivierungslink an seine E-Mail Adresse zusenden zu lassen.
Userdaten ändern Jeder Nutzer hat die Möglichkeit seine bei der Registrierung bekannt gegebenen Daten sowie sein Login-Passwort zu ändern.
Logout Logout dient dem Beenden einer aktuellen Sitzung. Falls ein Nutzer über eine definierte Zeitdauer nicht mit der Anwendung interagiert, findet ein automatisches Logout statt.
Abmelden (engl. cancel registration)
Hat ein Nutzer kein Interesse mehr am THEREDA Projekt, so hat er die Möglichkeit, sich abzumelden. Dies stößt Folgeprozesse an, falls der Nutzer mindestens der Nutzergruppe author zugeordnet war.
Downloads Die Downloadfunktion der Anwendung stellt den Nutzern vorab generierte, sowie eigen definierte Parameterdateien zum Herunterladen zur Verfügung.
Datensatzabfrage Unter Datensatzabfrage wird die Kernfunktionalität des Systems verstanden, Datensätze aus der PostgreSQL Datenbank abzufragen und geeignet zu repräsentieren. Des Weiteren ist es möglich, erstellte Abfragen und/oder Abfrageergebnisse zu speichern.
author
Datensatz erstellen Für das Anlegen neuer Datensätze in der Datenbank wird eine klare Eingabestruktur vorgegeben, um sicherzustellen, dass alle für einen Datensatz benötigten Ausgangsdaten bereits in der Datenbank vorliegen. Zum Abschluss des Erstellungsprozesses muss ein Datensatz durch den author selbst freigegeben werden. Dies stößt daraufhin einen Auditprozess an, durch den die Qualität der Eingabedaten geprüft wird. Ein Datensatz ist nach dem Erstellungsprozess nicht direkt von anderen Benutzern abrufbar.
Eigenen Datensatz ändern
Beim Anlegen neuer Datensätze können Eingabefehler auftreten, die entweder durch den Auditprozess erkannt oder durch den author selbst bemerkt werden. Jeder author ist in der Lage, seine eigenen Datensätze zu bearbeiten und damit Fehler zu korrigieren.
Datensatz kontrollieren
Wie bereits bei „Eigenen Datensatz erstellen“ erwähnt, gibt es einen Auditprozess für neu eingegebene bzw. signifikant geänderte Datensätze. Dabei nimmt ein anderer author die Rolle des Kontrolleurs ein und bewertet den entsprechenden Datensatz. Der Kontrolleur wird dabei durch einen auditor benannt.
5. THEREDA: Ausgangsituation und Anforderungen
- 51 -
auditor
Basisdaten verwalten Mit Basisdaten sind die grundlegenden Elemente innerhalb der THEREDA-Datenbank gemeint. Diese Datensätze können auch als Stammdatensätze betrachtet werden und können nur von einem auditor erstellt und verwaltet werden.
Datensatz ändern Der auditor ist für die Qualität aller Datensätze verantwortlich und kann bei Bedarf alle Datensätze direkt ändern. Durch den Auditprozess ist dies jedoch nur in den seltensten Fällen notwendig. Diese Funktion beinhaltet weiterhin das Freischalten bzw. Sperren von Datensätze für die „Datensatzabfrage“.
Auditprozess Der Auditprozess wird durch den auditor verwaltet. Dabei kann er Datensätze in erster Instanz selbst überprüfen oder einem author diese Aufgabe zuweisen. Der auditor der diese Zuweisung vornimmt, übernimmt auch die Schirmherrschaft über den speziellen Datensatz und wird mit dem Datensatzersteller über den Status des Auditprozesses sowie deren Abschlussergebnis informiert.
Zuständigkeit für Datensätze ändern
Meldet sich ein Nutzer, der mindestens der Nutzergruppe author zugeordnet war, vom THEREDA Projekt ab, so würden die von ihm erstellten Datensätze verwaisen und nur noch von einem auditor bearbeitet werden können. Um aber die inhaltliche Verantwortung aufrecht zu erhalten, kann ein auditor einem anderen author diese Datensätze zuordnen.
accessAdministrator
Nutzerverwaltung
Die Nutzerverwaltung umfasst das Freischalten und Sperren von Nutzern, ebenso die Einordnung der Nutzer in die verschiedenen Nutzergruppen.
systemAdministrator
Generierung der Download-Datenbank
Unter einer Download-Datenbank wird ein Datenbankabbild in einem unabhängigen Format verstanden. So können Nutzer die Daten der Datenbank auch Offline verwenden und in eigene Anwendungen oder ähnliches einbinden. Der systemAdministrator ist in der Lage diese zu generieren. Daneben wird automatisch eine Prüfsumme für diese Datei berechnet und im System hinterlegt.
Prüfen von externen Parameterdateien auf Unversehrtheit
Diese Funktionalität dient der Überprüfung von Parameterdateien, die durch Nutzer an einen systemAdministrator zugesendet werden. Ziel ist es die Unverfälschtheit der zugesendeten Datei zu überprüfen. Dies geschieht durch den Vergleich der Prüfsummen oder dem zeichenweisen Abgleich der ASCII-Dateien.
Manuelles Backup Neben einem automatischen Backup, welches vom System vorgenommen wird, kann ein systemAdministrator auch manuell ein Backup erstellen.
Recovery Nach einem Systemausfall ist es notwendig die Backups neu einzuspielen. Dieses Recovery muss manuell ausgelöst und überwacht werden.
Datenbankstrukturen verwalten
Die Verwaltung von Tabellen, Views, Funktionen und Sequenzen dient der Optimierung und Anpassung der Datenbank.
Zugriffsrechte verwalten
Für jede Nutzergruppe müssen in der Datenbank für Tabellen, Views, Funktionen und Sequenzen bestimmte Rechte gesetzt sein, die die Zugriffsmöglichkeiten auf das Objekt beschreiben. Diese Verwaltung übernimmt der systemAdministrator.
5. THEREDA: Ausgangsituation und Anforderungen
- 52 -
Systemfunktionen
Systemfunktionen sind Funktionalitäten des Systems, die durch Benutzerinteraktionen
angestoßen werden. Darunter fallen verschiedene Prüf- und Verarbeitungsfunktionen,
von denen nachfolgend die wichtigsten aufgeführt und kurz beschrieben werden.
Tabelle 9: THEREDA: Systemfunktionen
Funktionsgruppe Funktion
Kurzbeschreibung
Prüfen / Controlling
Passwortvalidierung Unter der Passwortvalidierung ist das Überprüfen von neuen Passwörtern gegenüber den Passwortrichtlinien zu verstehen. Dabei geht es vor allem darum, zu überprüfen, ob die Mindestlänge und Zeichenzusammensetzung beachtet wurden.
Eingabevalidierung Die Überprüfung der Nutzereingaben dient einerseits der Fehlervermeidung, andererseits der Sicherheit vor Angriffen bzw. ungewollten Zugriffen.
Logging Logging ist das Protokollieren von Login- und Logout-Aktionen, sowie Datenbanktransaktionen. Darunter fallen Datensatzabfragen und Datenmanipulationen.
Verarbeitung
Synchronisation Alle Nutzer die einer aktiven Nutzergruppe zugeordnet sind müssen in der PostgreSQL-Datenbank in der Tabelle „editor“ aufgeführt sein. Diese Funktionalität dient dazu, die Nutzer aus der MySQL-Datenbank mit der aufgeführten Tabelle abzugleichen und ggf. zu synchronisieren.
Automatisches Backup
In regelmäßigen Abständen werden Backups erstellt, die es ermöglichen die physische Integrität sicherzustellen. Dabei werden unterschiedliche Backups automatisch erstellt.
Generierung der Parameterdateien
Unter den Parameterdateien versteht man einerseits eine vordefinierte Abbildung der Datenbasis, andererseits anwenderspezifisch angepasste Abfrageergebnisse. Diese Dateien werden in dem unabhängigen JSON-Format, sowie für die Weiterverarbeitung in speziellen codespezifischen Formaten auf Nutzeranforderung generiert.
5.4 Nicht-funktionale Anforderungen
Nicht-funktionale Anforderungen sind Charakteristika bzw. Eigenschaften, die die
Anwendung aufweisen soll. Einige der relevantesten nicht-funktionalen Anforderungen
wurden in der ISO 9126 bzw. DIN 66272 spezifiziert. Nachfolgend werden nicht-
funktionelle Anforderungen nach ISO 9126 aufgeführt, die vom Projektteam als
„vorrangig“ eingestuften wurden.
5. THEREDA: Ausgangsituation und Anforderungen
- 53 -
Tabelle 10: Nicht-funktionale Anforderungen, nach ISO 9126
Kriterium Beschreibung
Funktionalität
Sicherheit Beschreibt die Fähigkeit unberechtigten Zugriff auf Daten oder Programmteile zu verhindern.
Richtigkeit Ist die Fähigkeit des Systems, Zahlenwerte richtig zu berechnen oder auch umzurechnen, z.B. bei unterschiedlichen Einheiten.
Zuverlässigkeit
Wiederherstellbarkeit Beinhaltet die Wiederherstellbarkeit der Anwendung bzw. des Systems nach Versagen. Hierfür sind regelmäßige Backups, sowie das Logging von Datenbanktransaktionen notwendige Mittel, um das System schnellstmöglich mit allen Daten wieder verfügbar zu machen.
Robustheit
Die Fähigkeit, stabil trotz Eingabefehler weiterzuarbeiten wird als Robustheit von Systemen verstanden. Das System sollte ein klar definiertes Verhalten bei Eingabefehlern aufweisen und Fehleingaben stabil abfangen.
Benutzbarkeit
Erlernbarkeit Mittels der Erlernbarkeit lässt sich der Aufwand, der betrieben werden muss, um mit dem System umgehen zu können, bewerten. Dabei sollte bei der Entwicklung eines Systems darauf geachtet werden, dass es eine klare und eindeutige Struktur besitzt und alle für die Anwendung notwendigen Informationen und Hilfen bereitstellt.
Bedienbarkeit Die Steuerung und Ergonomie einer Anwendung werden unter dem Kriterium der Bedienbarkeit verstanden. Zu kleine Schriften, versteckte Schaltflächen oder mehrdeutige Bezeichnungen verringern den Grad der Bedienbarkeit einer Anwendung, was wiederum deren Erlernbarkeit wesentlich schwieriger gestaltet. Darum sollte dem Aspekt der Bedienbarkeit innerhalb des Projektes auch hohe Aufmerksamkeit zukommen.
Effizienz
Zeitverhalten Die Antwort- und Verarbeitungszeiten des Systems sollten so gering wie möglich sein. Dies kann z.B. durch vordefinierte und ggf. vorberechnete Abfragen innerhalb der Datenbank geschehen oder durch leistungsfähigere Hardware.
Wartbarkeit
Analysierbarkeit Beschreibt die Fähigkeit eines Systems zur Bestimmbarkeit von Mängeln, Fehlerursachen oder von änderungsbedürftigen Programmteilen. Eine gute Analysierbarkeit lässt sich durch eine gute und umfangreiche, aber vor allem spezifische Dokumentation und einen modularen Programmaufbau erreichen.
Die Nicht-funktionalen Anforderungen sollten in der Entwicklung neuer Module und
bei der Erweiterung bestehender Programmbausteine berücksichtigt und durch die
Projektpartner kontrolliert werden. Je nach Projektstand bzw. Modulanforderungen
sollten die nicht-funktionalen Anforderungen erweitert bzw. angepasst werden.
6. Entwurf
- 54 -
6. Entwurf
Die im vorherigen Kapitel definierten Benutzer- und Systemfunktionen werden im
folgenden Kapitel vertieft dargestellt und deren Zusammenwirken herausgearbeitet.
Dabei wird zuerst dargestellt, wie die Verwaltung der einzelnen Nutzer realisiert und
umgesetzt wird. Anschließend werden die Benutzer- und Systemfunktionen in
Nutzergruppen-spezifischen USE-Cases veranschaulicht und erläutert.
6.1 Nutzerverwaltung
Die Verwaltung der einzelnen Nutzer soll mittels der in Joomla! integrierten
Nutzerverwaltung realisiert werden. Joomla! bietet die Möglichkeit, den
unterschiedlichen Nutzergruppen verschiedene Funktionalitäten über die Webpräsenz
zur Verfügung zu stellen. Welche Nutzergruppe auf welche Funktionalitäten zugreifen
darf, wird in der Backend-Komponente von Joomla! von den Administratoren
zugeordnet. So wird einer Nutzergruppe z.B. der Zugriff auf PHP-Anwendungsdateien
verwehrt oder gewährt. So können die einzelnen Aufgabengebiete klar voneinander
abgegrenzt werden. Für den Datenbankzugriff wird ein in der Datenbank angelegter
generischer Datenbanknutzer verwendet, der sämtliche Privilegien innerhalb der
Datenbank besitzt, die für die Erfüllung aller Aufgaben sämtlicher Nutzer und
Nutzergruppen notwendig sind. Im Anhang II sind die Datenbanktabellen aufgeführt,
für die ein Nutzer auf Grund seiner Aufgaben nicht nur Lese- sondern auch
Schreibrechte benötigt.
Joomla! stellt bereits vorgefertigte Funktionen und Komponenten bereit, die sich für das
Projekt verwenden lassen und so den Programmieraufwand reduzieren. Dazu zählen
beispielsweise die Funktionalitäten zum „Registrieren“ (Anmelden), „Abmelden“,
„Login“, „Logout“ sowie das „Userdaten ändern“. Des Weiteren wird die Komponente
„DOCman“ zur Verwaltung und Bereitstellung von Dokumenten verwendet. Die
bereitgestellten Funktionalitäten werden bei Bedarf projektspezifisch angepasst bzw.
erweitert.
6. Entwurf
- 55 -
6.2 Benutzerfunktionen
Nachfolgend werden alle Funktionalitäten bzw. Aufgaben der einzelnen Nutzergruppen
genauer dargestellt. Dabei wird die Systemfunktion „Eingabevalidierung“ bei
sämtlichen Nutzereingaben verwendet, um die Gefahr von SQL-Injections bzw.
Typenunverträglichkeiten nahezu auszuschließen. Auch das „Logging“ findet
unabhängig von speziellen Funktionen automatisch statt und wird deshalb bei den
einzelnen Funktionen nicht mit betrachtet. Alle anderen Systemfunktionen werden
hingegen nur durch konkrete Nutzeraktionen initialisiert.
6.2.1 unregisteredUser
Als unregisteredUser ist jeder Besucher (engl. Visitor) der THEREDA Webpräsenz zu
verstehen, der keinen gültigen Nutzeraccount besitzt. Diese Besucher können sich
mithilfe der bereitgestellten öffentlichen Informationen über das THEREDA Projekt,
dessen Zielsetzung und die zur Verfügung gestellte Datenbasis informieren. Bei
Interesse am Projekt haben sie die Möglichkeit, sich zu registrieren, um sich
anschließend als registeredUser anmelden zu können und so interaktiv mit den
bereitgestellten Daten arbeiten zu können.
Abbildung 9: USE CASE: unregisteredUser
6. Entwurf
- 56 -
Registrierung
Das Registrieren von neuen Nutzern funktioniert über ein einfaches Anmeldeformular.
Dieses enthält derzeit nur Pflichtfelder. Zu diesen zählen der Name, Benutzername
(Loginname), die E-Mail Adresse und das Passwort.
Um zu vermeiden, dass die Registrierung automatisiert über spezielle Roboter
stattfinden kann, wurde eine sogenannte CAPTCHA-Grafik eingefügt. CAPTCHA steht
für „Completely Automated Public Turing-Test to Tell Computers and Humans Apart“.
Die CAPTCHA Grafik stellt einen für Menschen lesbaren Inhalt dar, der jedoch für
viele Computerprogramme nicht erkennbar ist. Bei der Eingabe des grafisch
dargestellten Inhaltes handelt es sich ebenfalls um eine Pflichteingabe.
Das Anmeldeformular soll zukünftig um weitere projektspezifische Felder erweitert
werden. Dazu zählen unter anderem der Titel des Nutzers und dessen Fachgebiet.
Nachdem der Besucher das Anmeldeformular ausgefüllt und abgesendet hat, wird der
Datensatz in der Datenbank gespeichert und ein accessAdministrator über den neuen
Nutzer informiert. Der neu angemeldete Nutzer besitzt zu diesem Zeitpunkt noch keinen
Systemzugriff. Dieser wird ihm erst durch einen accessAdministrator gewährt.
Nachdem die Freischaltung durch einen accessAdministrator erfolgt ist, erhält der neu
registrierte Nutzer einen Aktivierungslink per E-Mail.
Dieser Link enthält einen Aktivierungsschlüssel, der auch in der Datenbank mit einem
Verfallsdatum gespeichert wird. Durch den Aufruf der THEREDA Webpräsenz mittels
des Aktivierungslinks wird der in der URL enthaltende Schlüssel mit dem in der
Datenbank gespeicherten abgeglichen. Bei erfolgreicher Validierung erfolgt die
automatische Weiterleitung zur Passworteingabe.
Das neu eingegebene Passwort muss dabei den unter 6.3.1 aufgeführten
Passwortrichtlinien entsprechen, um vom System angenommen zu werden. Hierfür wird
die Systemfunktion „Passwortvalidierung“ verwendet. Nach Abschluss aller Vorgänge
gilt der Besucher als registeredUser.
6. Entwurf
- 57 -
6.2.2 registeredUser
Jeder Besucher der THEREDA Webpräsenz, der einen gültigen Nutzeraccount besitzt,
ist prinzipiell ein registeredUser. Je nachdem, welcher Nutzergruppe er zugeordnet ist,
werden ihm unterschiedliche Funktionen angeboten. Ist der Nutzer in der Gruppe
registeredUser, so kann er passiv mit der Datenbank arbeiten. Darunter ist zu verstehen,
dass diese Gruppenmitglieder nur Datenabfragen durchführen dürfen. Des Weiteren
haben sie die Möglichkeit, die angebotenen Download-Datenbanken sowie die
Datenabfrageergebnisse in verschiedenen Formaten herunterzuladen. Neben dem
Herunterladen der verschiedenen Parameterdateien, welches durch die Systemfunktion
„Generierung der Parameterdateien“ realisiert wird, besteht die Möglichkeit die
erstellten Datenabfragen zu speichern.
Abbildung 10: USE CASE: registered User
6. Entwurf
- 58 -
Login
Das Login ist die grundlegendste Funktion, die die Anwendung zur Verfügung stellt.
Aus diesem Grund sollte an dieser Stelle das SSL-Protokoll zur Verschlüsselung der
Kommunikation verwendet werden, um Passwörter nicht im Klartext zu übertragen.
Beim Login wird nach der Eingabe des Nutzernamens und des dazugehörigen Passworts
vom System ermittelt, ob ein Nutzer mit der eingegebenen Kombination in der
Datenbank vorhanden ist. Ist das Login erfolgreich abgeschlossen, stehen dem Nutzer
alle seiner Nutzergruppe zugeordneten Funktionalitäten der Anwendung zur Verfügung.
Passwort vergessen
Vergisst ein Nutzer sein Passwort hat er die Möglichkeit, sich einen neuen
Aktivierungslink zusenden zu lassen. Hierfür muss er nur eine gültige E-Mail Adresse
eingeben. Wie bereits unter „Registrierung“ beschrieben, wird nach dem Aufruf der
THEREDA Webpräsenz über den Aktivierungslink eine Gültigkeitsprüfung
durchgeführt und der Nutzer an die Passworteingabe weitergeleitet.
Userdaten ändern
Die gespeicherten Nutzerinformationen können jederzeit durch den Nutzer geändert
werden. An dieser Stelle wird unterschieden, ob die gespeicherten Nutzerinformationen
oder das Passwort geändert werden sollen. Beim Ändern von Benutzerinformationen
findet eine einfache Eingabevalidierung der zu speichernden Daten statt. Das heißt, dass
die Eingabewerte maskiert werden, um SQL-Injections zu verhindern. Es finden
außerdem Logikprüfungen, wie z.B. die Prüfung der E-Mail Adresse, statt.
Auch bei der Passwortänderung findet die soeben dargestellte Eingabevalidierung statt.
Zusätzlich wird das neu eingegebene Passwort geprüft, ob es den projektspezifischen
Passwortrichtlinien entspricht und daraufhin entweder vom System angenommen oder
abgewiesen. Die einzelnen Richtlinien sind unter 6.3.1. definiert.
6. Entwurf
- 59 -
Downloads
Die Downloads bieten den Nutzern die Möglichkeit, vorab generierte Datenbank-
abbildungen und die Ergebnisse (aktueller oder früher gespeicherter) eigener
Datenbankabfragen herunterzuladen. Die Parameterdateien werden in verschiedenen
Formaten angeboten, um den Nutzern den Zugriff auf Daten auch im Offlinebetrieb zu
ermöglichen bzw. diese in eigene Programme/Projekte und Berechnungen direkt zu
importieren. Für die Generierung der einzelnen Dateien wird dabei die Systemfunktion
„Generierung der Parameterdateien“ verwendet.
Datensatzabfragen
Die Kernaufgabe der Webanwendung ist die Bereitstellung der gespeicherten Daten.
Hierfür gibt es zwei Varianten. Die erste basiert auf vordefinierten Abfragen, die
ausgeführt werden können. Hierbei handelt es sich um Standardabfragen, die von den
Projektmitgliedern als solche definiert und im System öffentlich hinterlegt sind.
Die zweite Variante sind individualisierte Abfragen. Ein Nutzer kann mit Hilfe des
Systems selbstständig Abfragen erstellen, die auf seine speziellen Wünsche abgestimmt
sind. Dabei wird dem Nutzer die grundlegende Datensatzabfragestruktur vom System
vorgegeben. Dies dient einerseits der Benutzerfreundlichkeit und verkürzt andererseits
die notwendige Einarbeitungszeit.
Bei allen Abfragen finden vor der Übermittlung zum Datenbankserver
Eingabevalidierungen statt. Dabei werden Logikprüfungen vorgenommen, z.B. ob der
Zahlenwert der Minimaltemperatur kleiner ist, als der Wert der Maximaltemperatur.
Diese beinhaltet außerdem eine Überprüfung des Variablentyps, z.B. eine Anzahl an
Elementen darf nur ganzzahlige Werte annehmen. Ganzzahlige Werte entsprechen dem
Datentyp „Integer“. Somit kann der Eingabewert mittels der PHP Funktion is_int()
entsprechend überprüft werden.
Nachdem die Überprüfung sämtlicher Eingabewerte fehlerfrei abgeschlossen wurde,
können diese an das SQL-Statement übergeben werden.
6. Entwurf
- 60 -
Dieses wird daraufhin, zur Verhinderung von SQL-Injections, mittels der PHP Funktion
pg_escape_string() maskiert. Anschließend wird das SQL-Statement an den
Datenbankserver übermittelt und das Ergebnis an die entsprechende Ausgabeseite
weitergeleitet.
6.2.3 author
Die Nutzergruppe author ist in der Lage den Datenbestand zu manipulieren. Hierfür
besitzen die Gruppenmitglieder die Möglichkeit der Dateneingabe bzw. -änderung ihrer
selbst erstellten Datensätze. Ihnen kann zudem die Aufgabe zugewiesen werden, andere
Datensätze zu kontrollieren, um die Datensatzqualität innerhalb der Anwendung zu
steigern bzw. sicherzustellen.
Abbildung 11: USE CASE: author
6. Entwurf
- 61 -
Datensatz erstellen
Das Erstellen neuer Datensätze ist ein aufwendiger Prozess, in dem viele interne
Bedingungen berücksichtigt werden müssen. Diese Bedingungen resultieren aus
chemischen Gegebenheiten und projektspezifischen Anforderungen.
Aus diesem Grund erfolgt die Dateneingabe anhand einer definierten Struktur, welche
hierarchisch aufgebaut ist. Hierfür wird im Anhang III ein erster Entwurf dieser
Dateneingabestruktur veranschaulicht. Dieser muss jedoch, um sämtliche
projektspezifischen Bedingungen sicher abdecken zu können, in den folgenden
Projektphasen verfeinert und optimiert werden.
Unabhängig von der Optimierung innerhalb des Prozesses, soll nach der vollständigen
Erstellung eines Datensatzes, die Datenfreigabe durch den author erfolgen. Mit dieser
Freigabe ist die automatische Initiierung des Auditprozesses verbunden, der unter 6.2.4
näher dargestellt ist. Vom Ergebnis dieses Prozesses hängt es ab, ob der Datensatz bei
Datenabfragen mit berücksichtigt wird oder nicht, d.h. nur durch einen positiven
Ausgang des Auditprozesses steht ein Datensatz öffentlich zur Verfügung.
Eigene Datensätze ändern
Jeder author hat eine Reihe von eigenen erstellten Datensätzen. Für diese besitzt er auch
die Verantwortung, d.h. für deren Korrektheit. Da sich jedoch Eingabefehler nicht
vermeiden lassen, ist es von Zeit zu Zeit notwendig, die eigenen Datensätze zu
korrigieren.
Die Korrektur findet nach demselben Prinzip wie die Erstellung des Datensatzes statt,
nur dass die gespeicherten Daten angezeigt und selektiv geändert werden können.
Werden hierbei entscheidende Datensatzinformationen, wie z.B. Zahlenwerte oder
Formeln, verändert, wird der Datensatz automatisch in den Auditprozess eingestellt und
ist erst nach dessen erfolgreichem Abschluss erneut öffentlich zugänglich. Ein author
kann hierbei aber nur selbst eingegebene Daten bearbeiten. Zusätzliche bzw. abgeleitete
Informationen, wie beispielsweise das Qualitätslabel sind nicht editierbar.
6. Entwurf
- 62 -
Datensatz kontrollieren
Zur Sicherstellung bzw. Steigerung der Qualität der einzelnen Datensätze und zum
Auffinden von inhaltlichen Fehlern oder Eingabefehlern wird jeder Datensatz
kontrolliert. Diese Kontrolle findet durch einen anderen author statt.
Diesem muss der Zugriff auf einen noch nicht freigegebenen Datensatz explizit durch
einen auditor eingeräumt werden. Normalerweise haben nur Mitglieder der Gruppe
auditor, sowie der author der den Datensatz erstellt hat, Zugriff auf die noch nicht
freigegebenen Datensätze.
Um einem anderen author Zugriff auf einen solchen Datensatz zu ermöglichen, wird der
author über eine spezielle Mappingtabelle mit dem entsprechenden Datensatz verknüpft.
Daraufhin ist dieser in der Lage, den Datensatz zu kontrollieren und abschließend zu
bewerten.
Die Verwaltung des Auditprozesses wird unter 6.2.4 „Auditprozess verwalten“ näher
dargestellt und der Prozessablauf in Anhang IV skizziert.
6.2.4 auditor
Ein auditor hat die Aufgabe alle grundlegenden Basisdaten zu verwalten, das heißt
bestehende Daten zu kontrollieren, zu pflegen oder neu anzulegen. Daneben ist er in der
Lage sämtliche Datensätze in der Datenbank zu bearbeiten und den Auditprozess zu
verwalten. Mit dessen Hilfe soll die Qualität der Datensätze sichergestellt bzw.
gesteigert werden. Abschließend kann ein auditor die Zuständigkeit für Datensätze
ändern. Dabei werden Datensätze von einem author einem anderen zugeordnet.
6. Entwurf
- 63 -
Abbildung 12: USE CASE: auditor
Basisdaten verwalten
Unter Basisdaten sind bestimmte chemische Elemente bzw. vordefinierte
Werte/Konstante zu verstehen, die z.B. bei Abfrage- und Erstellungsprozessen als
Ausgangsparameter ausgewählt werden können. Ein auditor hat hierbei die Aufgabe,
die Richtigkeit und Vollständigkeit dieser Daten zu gewährleisten. Des Weiteren darf er
neue Basisdaten anlegen oder bestehende ändern bzw. löschen.
6. Entwurf
- 64 -
Datensätze ändern
Diese Funktionalität ist identisch mit der Funktion der Nutzergruppe author „eigene
Datensätze ändern“. Ein auditor hat jedoch nicht nur die Möglichkeit eigene Datensätze
zu bearbeiten, sondern alle in der Datenbank vorhandenen. Dies ist jedoch nur in den
seltensten Fällen notwendig, da die Eigenverantwortung im Vordergrund steht und die
Datensatzqualität durch den Auditprozess sichergestellt wird.
Einem auditor ist es ebenfalls erlaubt, zusätzlich gespeicherte Informationen zu
bearbeiten, beispielsweise das Qualitätslabel. Dieses Label informiert über die Qualität
des Datensatzes und dessen Referenzen, auf denen dieser beruht. Stellt sich im
Nachhinein heraus, dass die Qualität der Referenzen und somit des Datensatzes nicht
den Ansprüchen des THEREDA Projektes genügt, kann durch die Änderung des
Qualitätslabels gesteuert werden, dass ein älterer Datensatz einem neuem Datensatz bei
Datenabfragen vorgezogen wird.
Auditprozess verwalten
Das Herzstück zur Gewährleistung der Qualität stellt der Auditprozess dar. Hierbei
obliegt einem auditor die Verwaltung des Auditprozesses, dessen Ablauf im Anhang IV
dargestellt wird. Innerhalb dieses Prozesses nimmt ein anderer author eine Bewertung
des neu eingegeben bzw. geänderten Datensatzes vor. Diese Bewertung dient einem
auditor als Entscheidungsgrundlage bezüglich der Freigabe des Datensatzes. Unter
Freigabe ist in diesem Zusammenhang das automatische Setzen des „approved“-Status
und damit die öffentliche Verfügbarkeit des Datensatzes, z.B. in der Datensatzabfrage
zu verstehen. Während des Auditprozesses hat ein author die Möglichkeit sich mittels
des „Auditstatus“ über den Stand der Kontrolle zu informieren und ggf. Maßnahmen zu
ergreifen.
6. Entwurf
- 65 -
Tabelle 11: THEREDA: Vordefinierte Auditstati
Auditstatus Beschreibung
not yet audited Dieser Status besagt, dass zum aktuellen Zeitpunkt der Auditprozess noch nicht begonnen hat.
author assigned Wurde ein author durch einen auditor einem Datensatz zugeordnet, so erhält der Datensatz diesen Status.
auditing ongoing Der Status wird gesetzt, wenn die Kontrollaufgabe von einem author angenommen wird und er die Kontrolle beginnt.
auditing finished Dieser Status wird vergeben, wenn ein author den kontrollierten Datensatz für korrekt und qualitativ gut befindet.
revision required Dieser Status besagt, dass die Qualität des kontrollierten Datensatzes durch den author für nicht ausreichend befunden wurde.
approved Ein auditor entscheidet abschließend über die Freigabe des Datensatzes. Gibt er den Datensatz frei, so erhält dieser den Status approved und der Datensatz wird beispielsweise bei Datensatzabfragen mit einbezogen.
not approved Dieser Status wird gesetzt, wenn der Datensatz nicht freigegeben wurde.
Zuständigkeiten für Datensätze ändern
Durch die lange Laufzeit des gesamten Projektes, kann es dazu kommen, dass ein
author das Projekt verlässt bzw. nicht mehr aktiv mitwirkt. Daraufhin würden alle von
ihm erstellten Datensätze verwaisen. Damit ist gemeint, dass nur noch Mitglieder der
Gruppe auditor diese Datensätze bearbeiten können. Um dies zu verhindern besteht die
Möglichkeit, Datensätze von einem author auf einen anderen zu übertragen. Ein auf
diese Weise neu zugeordneter author hat anschließend die Möglichkeit, diese
Datensätze wie eigene erstellte zu behandeln. Somit bleibt das Konzept der inhaltlichen
Eigenverantwortung für Datensätze durch einen author erhalten.
6.2.5 accessAdministrator
Dem accessAdministrator obliegt die Nutzerverwaltung. Darunter fallen die
Genehmigung neuer Nutzer, das Löschen, Sperren und Aktivieren von bereits
registrierten Nutzern sowie die Nutzergruppenzuordnung. Hierfür wird die in Joomla!
integrierte Nutzerverwaltung verwendet.
6. Entwurf
- 66 -
Abbildung 13: USE CASE: accessAdministrator
Nutzerverwalten
Die Verwaltung von Nutzern ist ein sehr wichtiger Aufgabenbereich innerhalb der
Webanwendung, denn hierdurch wird der Zugriff auf die Anwendung gewährt oder
verwehrt. Dabei übernimmt der accessAdministrator das Freischalten neu registrierter
bzw. gesperrter Nutzer, wodurch diese den Systemzugriff erhalten. Durch das Sperren
von Nutzern wird der Systemzugriff entzogen. Des Weiteren ist er in der Lage, einen
Nutzeraccount vollständig zu löschen.
Nutzergruppenzuordnung
Der accessAdministrator ordnet einzelnen Nutzern den hier aufgeführten Nutzergruppen
zu. Dafür verwendet er das Joomla!-Backend, in dem auch festgelegt wird, welche
Funktionalitäten der Anwendung welchen Nutzergruppen zur Verfügung stehen sollen.
6. Entwurf
- 67 -
6.2.6 systemAdministrator
Die Nutzergruppe systemAdministrator ist für die Funktionsfähigkeit der gesamten
Datenbank verantwortlich. Darunter zählen die Anpassung der Datenbank an geänderte
Anforderungen durch das Erstellen, Ändern oder auch Löschen von Datenbankobjekten
sowie das Setzen der entsprechenden Zugriffsrechte. Außerdem muss die Funktions-
fähigkeit der erstellten Backupdateien gewährleistet werden, um im Fall eines
Systemausfalls die Verfügbarkeit der Datenbank schnellstmöglich sicher zu stellen.
Unabhängig vom Datenbanksystem obliegt dieser Gruppe auch die Generierung der
Download-Datenbanken und die Überprüfung sämtlicher generierter Parameterdateien
auf Unversehrtheit.
Abbildung 14: USE CASE: systemAdministrator
6. Entwurf
- 68 -
Generierung der Download-Datenbank
Die Download-Datenbanken werden durch den systemAdministrator in bestimmten
Zeitintervallen (ca. jedes Halbjahr) generiert und über die Webpräsenz zum Download
angeboten. Für die Generierung bieten sich vorgefertigte SQL-Statements an, die die
entsprechende Datenbankstruktur abbilden und nur diejenigen Datensätze beinhalten,
welche freigegeben sind und ein entsprechendes Qualitätslabel besitzen. Die erstellte
Datenbankabbildung liegt im JSON-Format vor und kann in diesem heruntergeladen
werden. Daneben bietet die Systemfunktion „Generierung der Parameterdateien“ noch
die Möglichkeit weitere Formate aus der JSON-Datei zu generieren.
Prüfen von externen Parameterdateien auf Unversehrtheit
Bei den Parameterdateien, die sich ein Nutzer herunterladen und weiterverwenden kann,
handelt es sich momentan um reine Textdateien (ASCII-Dateien). Dadurch ist es relativ
einfach, die Daten innerhalb der Dateien zu manipulieren, was zu verfälschten
Berechnungsergebnissen führt. Diese können sich wiederum negativ auf das
THEREDA Projekt auswirken, da eine der Zielsetzungen die Bereitstellung einer
gesicherten Datenbasis ist.
Um auch im Nachhinein eine Prüfung zu ermöglichen, werden die erzeugten
Textdateien serverseitig gespeichert. Treten widersprüchliche Aussagen auf, wird der
Nutzer aufgefordert, seine heruntergeladene Datenbasis den THEREDA
Projektmitgliedern zur Verfügung zu stellen und ihnen mitzuteilen, wann er diese
generiert hat. Für die Überprüfung beider Textdateien können z.B. Programme wie
UltraEdit oder auch Kommandozeilenbefehle wie fc (für Windows) oder diff (für
Linux) verwendet werden. Es ist ebenfalls möglich, aus der zugesandten Datei den
Hashwert zu bestimmen und mit dem gespeicherten ursprünglichen Hashwert zu
vergleichen. Dies ist jedoch nur machbar, wenn der gleiche Hashalgorithmus verwendet
wird und keine unterschiedlichen Zusatzinformationen, wie beispielsweise Datum oder
Uhrzeit in den Dateien enthalten sind.
6. Entwurf
- 69 -
Manuelles Backup
Hat ein systemAdministrator Änderungen an der Datenbankstruktur, an Zugriffsrechten
oder größere Änderungen am Datenbestand vorgenommen, kann er unabhängig vom
automatischen Backup ein manuelles Backup durchführen. Hierfür kann er das
Programm pg_dump verwenden, welches den Inhalt der Datenbank auch im laufenden
Betrieb in eine ASCII-Datei schreibt. In diese Datei werden eine Folge von SQL-
Befehlen geschrieben, mit deren Hilfe der gesicherte Zustand der Datenbank nach
einem Systemausfall wiederhergestellt werden kann. Im einfachsten Fall kann pg_dump wie folgt ausgeführt werden:
pg_dump dbname > backup.sql
Hierbei wird als Parameter der zu sichernde Datenbankname übergeben und die Standardausgabe
in die Datei backup.sql umgeleitet. Dabei kann man bei pg_dump zwischen drei verschiedenen
Ausgabeformaten wählen, einmal dem soeben verwendeten “Plain Text“-, dem “Tar“- und dem
“Custom“- Format. Das “Plain Text“-Format ist das Standardausgabeformat, das mittels der
Option –Fp explizit festgelegt werden kann. Um eines der anderen Ausgabeformate zu wählen,
ist für das TAR-Format der Parameter –Ft und für das “Custom“-Format der Parameter –Fc
anzugeben. pg_dump sichert alle in der angegebenen Datenbank enthaltenen Datenbankobjekte.
Es werden dabei nicht die globalen Objekte des Datenbanksystems, wie Nutzer, Nutzergruppe,
Tablespaces, sowie die Definition der Datenbank, gesichert.
Möchte man alle Datenbanken und die dazugehörigen globalen Objekte des Datenbanksystems
sichern, kann man das Programm pg_dumpall verwenden.
pd_dumpall > backup.sql
Recovery
Die Wiederherstellung des mit pg_dump gesicherten Datenbanksystems erfolgt im
einfachsten Fall mit der Übergabe der Dump-Datei an psql. psql dbname < backup.sql
Bei der Wiederherstellung werden die in der Datei backup.sql enthaltenen SQL-Befehle
ausgeführt und damit die Datenbank rekonstruiert. Dabei ist zu beachten, dass für die
Wiederherstellung einer mit pg_dump erstellten Sicherung, alle globalen Objekte
bereits im Datenbanksystem mit identischen Namen vorhanden sein müssen.
Dies ist beim Recovery einer pg_dumpall-Sicherung nicht notwendig, da dort alle
Objekte automatisch angelegt werden.
6. Entwurf
- 70 -
Damit bei der Wiederherstellung auch solche Änderungen am Datenbestand mit
berücksichtigt werden, die seit der letzen Sicherung getätigt wurden, sollten auch die
Write-Ahead-Log (WAL) Aufzeichnungen, die PostgreSQL auf der Festplatte sichert
sowie weitere Logging Dateien mit einbezogen werden.
Datenbankstrukturen ändern
Die Erstellung und Änderung von Tabellen, Sichten (engl. Views), Funktionen,
Triggern sowie Sequenzen wird während des Projektes ein ständiger Prozess sein, der
vor allem der Optimierung und Anpassung an veränderte Anforderungen/Bedürfnisse
dient. Bei diesen Änderungen an der Datenbankstruktur ist immer darauf zu achten, dass
die Datenintegrität gewährleistet wird. Hierfür können beispielsweise Views,
Funktionen, Triggern, sowie Sequenzen unterstützend definiert werden. So werden bei
bestimmten SQL-Statements, definierte Trigger oder Sequenzen automatisch
aufgerufen, die eine bestimmte Aktion bzw. auch eine Aktionsfolge ausführen. Dadurch
lässt sich sicher stellen, dass z.B. Änderungen innerhalb einer Tabelle automatisch an
andere Tabellen weitergegeben werden.
Zugriffsrechte verwalten
Für die neu erstellen Datenbankobjekte besitzt nur der Ersteller alle entsprechenden
Rechte. Damit die einzelnen Datenbankobjekte durch andere Nutzer verwendet werden
können, müssen durch den Eigentümer diese Rechte explizit gesetzt werden. Hierbei ist
darauf zu achten, dass der Datenbanknutzer apache nur die nötigsten Rechte/Privilegien
für das entsprechende Datenbankobjekt erhält. Eine Liste aller möglichen Privilegien
für die jeweiligen Datenbankobjekte wird im Anhang V gegeben. Die einzelnen
Privilegien werden dabei mittels des GRANT-Befehls gesetzt oder per REVOKE
entzogen.
6. Entwurf
- 71 -
6.3 Systemfunktionen
Unter den Systemfunktionen sind die Funktionalitäten zu verstehen, die die
Benutzerfunktionen unterstützen bzw. völlig losgelöst von ihnen automatisch
abgearbeitet werden.
6.3.1 Prüfen / Controlling
Passwortvalidierung
Das Prüfen/Kontrollieren von neuen Passwörtern, dient dem Schutz vor zu schwachen
Passwörtern. Hierfür wurden für die unter 3.1.1 definierten Passwortrichtlinien
Durch den entpersonalisierten Datenbankzugriff, ist ein separates Logging auf der
Joomla! Ebene notwendig, um die ausgeführten Transaktionen konkreten Nutzern
zuordnen zu können. Erst dadurch ist es möglich Nutzer zu identifizieren, die versucht
haben einen schädlichen Code in die Anwendung einzuschleusen.
Die Kontrolle der erstellten Logging Dateien sollte regelmäßig stattfinden, um
potentielle Lücken und auffällige Nutzer so schnell wie möglich ausfindig zu machen
und Maßnahmen einzuleiten.
6.3.3 Verarbeitung
Synchronisation
Die Verwaltung der individuellen Nutzer findet auf Joomla! Ebene statt, wohingegen
der Datenbankzugriff entpersonalisiert ist. Einige Datensätze enthalten jedoch auch auf
Datenbankebene Nutzerinformationen, beispielsweise die Tabelle editor. Damit bei
Schreiboperationen an der Datenbank die semantische Integrität sicherzustellen, ist es
notwendig einen Teil der Nutzerinformationen zwischen Joomla! und der PostgreSQL-
Datenbank abzugleichen und bei Bedarf zu synchronisieren.
6. Entwurf
- 74 -
Automatische Backups
Automatische Backups lassen sich auf Datenbankebene mit den Programmen pg_dump
bzw. pg_dumpall erstellen. Um ein automatisches Backup durchzuführen wird ein entsprechender Anruf bei Cron
eingetragen. Dafür muss man z.B. als Nutzer postgres (Standardadministrator von PostgreSQL)
eingeloggt sein und crontab –e aufrufen und dort beispielsweise folgenden Befehl angeben.
0 4 * * 0 pg_dumpall > backup.sql
Hierbei wird eine wöchentliche Sicherung um 04:00 Uhr durchgeführt. Der nachfolgende Befehl
führt hingegen eine monatliche Sicherung durch.
0 4 1 * * pg_dumpall > backup.sql
In diesen beiden Beispielen überschreibt die neue die alte Sicherung, welche in der Datei
backup.sql enthalten ist. Damit dies nicht geschieht, kann man den Dateinamen automatisch
verändern, wodurch sich die Sicherungsdateien auch zeitlich ordnen lassen. %b steht in diesem
Fall für den entsprechenden Monatsnamen.
0 4 1 * * pg_dumpall > backup-$(date + %b).sql
Generierung der Parameterdateien
Die Anwendung stellt dem Nutzer Download-Datenbanken, sowie Abfrageergebnisse
als Parameterdateien in verschiedenen Formaten zur Verfügung. Das JSON-Format
wird dabei als Standardausgabeformat verwendet, aus dem weitere Formate generiert
werden. Dabei wird die JSON-Datei durch fest definierte Regeln in ein anderes
Ausgabeformat überführt. Dies ist relativ einfach möglich, weil es sich bei den anderen
Formaten ebenfalls um reine ASCII-Dateien handelt.
Dabei wird die im JSON generierte Download-Datenbank in der Joomla! Komponente
„DOCman“ veröffentlicht, während die anderen Formate der Datenbank, nach jetzigem
Stand erst nach der Initialisierung generiert und dem Nutzer direkt zum Download
angeboten werden. Ähnlich verhält es sich bei den Abfrageergebnissen, da diese nur in
dem vom Nutzer gewünschten Format zum Download zur Verfügung gestellt werden.
7. Prototypische Realisierung
- 75 -
7. Prototypische Realisierung
In diesem Kapitel werden die Anlegung eines Nutzers und die Zuweisung der
entsprechenden Schreibrechte im System anhand eines Beispiels erläutert.
Darauffolgend wird die Serverauthentifizierung mittels eines OpenSSL-Zertifikates
veranschaulicht. Abschließend folgt eine Erklärung der Umsetzung der Passwort-
Prüffunktion
7.1 THEREDA: Der Datenbanknutzer
Die personalisierte Nutzerverwaltung findet, wie bereits erwähnt, in Joomla! statt. Für
den Datenbankzugriff existiert auf PostgreSQL-Ebene der Datenbanknutzer apache,
über den die gesamte Kommunikation läuft. Daneben gibt es noch die Nutzergruppe
systemAdministrator, die sämtliche Rechte für alle Datenbankobjekte besitzt und somit
einen Superuser darstellt. In PostgreSQL werden Nutzer und Nutzergruppen unter dem Konzept der Rolle vereinheitlicht.
Die Unterscheidung, ob es sich um einen Nutzer oder eine Gruppe handelt, wird durch das
Login-Attribut getroffen. Wird das Login-Attribut gesetzt so handelt es sich um einen Nutzer,
der sich am Datenbanksystem einloggen kann. Zum Anlegen von Nutzern kann sowohl der SQL-
Befehl CREATE ROLE, als auch das Programm createuser verwendet werden.
CREATE ROLE apache LOGIN;
Um einen Superuser anzulegen, der sämtliche Rechte/Privilegien innerhalb des
Datenbanksystems besitzt, ergänzt man den SQL-Befehl CREATE ROLE mit dem Attribut
SUPERUSER.
CREATE ROLE systemAdministrator LOGIN SUPERUSER;
Vergabe und Entzug von Zugriffsrechten
Zum Arbeiten mit der Datenbank benötigt der Datenbanknutzer apache für sämtliche
Datenbankobjekte, die zur Erfüllung der Aufgaben der einzelnen Nutzergruppen
notwendig sind, die entsprechenden Rechte. Dabei gibt es für die verschiedenen
Datenbankobjekte (Datenbanken, Tabellen, Views usw.) unterschiedliche Rechte, die
im Anhang V aufgeschlüsselt dargestellt sind.
7. Prototypische Realisierung
- 76 -
Zum Setzen bzw. Entziehen der entsprechenden Rechte werden die SQL-Befehle
GRANT und REVOKE eingesetzt. Im Folgenden werden beispielshaft einige dieser
Rechte für Tabellen gesetzt. Eine Übersicht über alle Tabellen, die durch den Nutzer
apache bearbeitet werden können müssen, wird im Anhang II gegeben. Alle weiteren
Tabellen sind durch apache-Nutzer lesbar aber nur von einem Superuser editierbar. Für den lesenden Zugriff auf eine Tabelle wird der SQL-Befehl SELECT benötigt, für das
Editieren sind zusätzlich die Rechte INSERT, UPDATE und DELETE notwendig. Das
DELETE-Recht müsste jedoch nicht explizit gesetzt werden, da Daten auch durch einen
UPDATE-Befehl vernichtet werden können.
GRANT SELECT, INSERT, UPDATE, DELETE ON dbstatus, pcon [, …] TO apache;
Da PostgreSQL es erlaubt neben einer Liste aller Privilegien und Nutzer auch eine Tabellenliste
anzugeben, gestaltet sich die Vergabe dieser relativ einfach.
Stellt sich in einer späteren Projektphase heraus, dass für bestimmte Tabellen kein schreibender
oder sogar lesender Zugriff notwendig ist, sollten die entsprechenden Rechte dem Nutzer apache
entzogen werden.
REVOKE INSERT, UPDATE, DELETE | ALL ON dbstatus FROM apache;
7.2 Authentifizierung
7.2.1 Serverauthentifizierung
Um den Webserver gegenüber den Clients zu authentifizieren und die Kommunikation
zu verschlüsseln, wird ein mit OpenSSL erstelltes Zertifikat für Testzwecke eingesetzt.
Dabei wurde ein selbstsigniertes Zertifikat mittels des OpenSSL Toolkit, Version
0.9.8k, erstellt.
Abbildung 15: Erstellung des Serverzertifikats mittels OpenSSL
7. Prototypische Realisierung
- 77 -
Mit dem in Abbildung 15 abgebildeten Kommando wird ein neues (-new) Zertifikat (-x509) mit einer
Gültigkeitsdauer von einem Jahr (-days 365) erzeugt. Dieses wurde mit dem SHA1 Algorithmus
(-sha1) verschlüsselt. Anschließend wird der private Schlüssel mittels des RSA Algorithmus und
einer Schlüssellänge von 2048 Bit (-newkey rsa:2048) generiert. In diesem Fall wird der private
Schlüssel nicht durch ein Passwort geschützt (-nodes). Der genierte private Schlüssel wird in die
Datei server.key geschrieben und das eigentliche Zertifikat, welches den öffentlichen Schlüssel
enthält, in server.crt (-keyout server.key –out server.crt). Abschließend werden noch einige
Zertifikatsdaten angegeben, darunter die Landeskennung (C=DE), Stadt (L=Dresden),
Einrichtung/Organisation (O=Forschungszentrum Dresden-Rossendorf), das Organisationskürzel
(OU=FZD) und der Name der zu zertifizierenden Domain (CD=www.thereda.de).
(Vgl. [I_SECFO1])
Um den Apache-Webserver mit SSL betreiben zu können, muss das Modul mod_ssl
beim Start des Servers mit geladen werden. Der hierfür notwendige Kommando-Befehl
ist in der Datei httpd.conf bereits enthalten und muss ggf. nur durch das Entfernen des
Kommentarzeichens (#) aktiviert werden. Anschließend kopiert man das eben erstellte
Zertifikat (*.crt) sowie den entsprechenden Schlüssel (*.key), in das dafür vorgesehene
Webserver-Verzeichnis, ..\ssl.crt\ und ..\ssl.key\.
Nach dem Neustart des Webservers ist dieser in der Lage, eine mit SSL gesicherte
Verbindung aufzubauen.
7.2.2 Clientauthentifizierung
THEREDA verwendet zur Clientauthentifizierung, die von Joomla! mitgelieferte
wissensbasierte Passwortauthentifizierung. Auf diese Komponente wird hier nicht näher
eingegangen. Stattdessen soll gewährleistet werden, dass die verwendeten Passwörter
den definierten Passwortrichtlinien entsprechen. Dafür wird die PHP Erweiterung
„ext/crack“ verwendet.
Ist die Erweiterung richtig installiert und aktiv, kann damit die Passwortüberprüfung
stattfinden. Dabei wird ein Passwortkandidat unter anderem hinsichtlich der
Zeichenlänge, der Zeichenzusammensetzung und gegen ein eingebundenes Wörterbuch
geprüft. Das Ergebnis dieser Überprüfung ist entweder der Rückgabewert TRUE, für
ein starkes Passwort oder eine entsprechende Fehlermeldungen.
7. Prototypische Realisierung
- 78 -
Falls die Erweiterung nicht geladen werden kann, muss dennoch sichergestellt werden,
dass ein Passwortkandidat nicht ohne eine Überprüfung vom System akzeptiert wird.
Für diese alternative Überprüfung werden einfache IF-THEN-ELSE-Bedingungen
eingesetzt, die zumindest eine Grundsicherheit für neue Passwörter sicherstellen.
Abbildung 16: Passwortprüffunktion, nach [B_KUNZx1], S. 156f
8. Fazit
- 79 -
8. Fazit
Mit dieser Arbeit zum Entwurf und prototypischen Realisierung von Maßnahmen eines
Autorisierungs- und Datensicherheitskonzeptes, wurde ein weiterer Grundbaustein für
die nächsten Projektphasen des Verbundprojektes THEREDA gelegt, in denen es um
die Realisierung der definierten Anforderungen geht.
Im Vordergrund der Arbeit stand die Sensibilisierung der Projektmitglieder in Bezug
auf die IT-Sicherheit. Da das THEREDA Projekt staatliche Förderung erhält und die
gesetzlichen Vorgaben eingehalten werden sollen, wurde ein besonderes Augenmerk
auf geltende Richtlinien, Gesetze und Standards gelegt.
Um die Datensicherheit des Systems zu erhöhen, wurde im Rahmen dieser Arbeit ein
Autorisierungskonzept entworfen. Dieses ermöglicht mit Hilfe von definierten
Aufgabenbereichen, den Nutzern einzelne Funktionalitäten zuzuordnen und ihre genaue
Identität festzustellen. Die Zuordnung wird dabei durch Nutzergruppen realisiert.
Die Authentifizierung eines Nutzers wird mittels der Passwortauthentifizierung
verwirklicht, welche die am weitesten verbreitete Methode im World Wide Web
darstellt. Das Sicherheitsniveau dieser Verfahrensweise kann dabei durch die Definition
von Richtlinien erhöht werden. Authentifizierungsmethoden die auf Besitz oder
Biometrie beruhen, sind im Wesentlichen sicherer als die Passwortauthentifizierung.
Jedoch sind für diese Authentifizierungsmethoden spezielle Hard- und
Softwarekomponenten notwendig, die zurzeit nicht standardisiert allen Anwendern zur
Verfügung stehen.
Im weiteren Verlauf der Arbeit wurden verschiedene webbasierte Technologien
hinsichtlich deren Funktionalitäten und Sicherheit untersucht. Für das Projekt eignen
sich dabei die serverseitigen Java-basierten Technologien, sowie die Skriptsprache PHP
am besten. In diesem Zusammenhang wurden außerdem verschiedene
Angriffsmethoden, die vom World Wide Web ausgehen, veranschaulicht und mögliche
8. Fazit
- 80 -
Gegenmaßnahmen aufgezeigt. Das größte Gefahrenpotenzial für das THEREDA
Projekt stellen derzeitig die SQL-Injections dar.
In den nächsten Projektphasen muss die weitere Entwicklung im Bereich der IT-
Sicherheit stets berücksichtigt werden. Vor allem sollten aktuell veröffentlichte Studien
und Berichte über bekanntgewordene Bugs/Lücken in den einzelnen Technologien
verfolgt werden, auf denen das THEREDA Projekt beruht. Ein weiteres Augenmerk
sollte man auf neu aufkommende Angriffsmethoden richten, um frühzeitig auf neue
Bedrohungen reagieren zu können und Gegenmaßnahmen einzuleiten.
Für das THEREDA Projekt stellt meine Diplomarbeit über den Entwurf und die
prototypische Realisierung von Maßnahmen eines Autorisierungs- und
Datensicherheitskonzeptes in einer SQL-basierten chemischen Stoffdatenbank, einen
weiteren Grundbaustein für nachfolgende Projektphasen dar, in denen die eigentliche
Entwicklung der Webanwendung schließlich realisiert werden.
I. Anhang
- 81 -
I. Anhang
Anhang I: Übersicht über Internet-Sicherheitsprotokolle, nach [B_MARTI1], S. 148
I. Anhang
- 82 -
Anhang II: THEREDA: Tabellen mit Schreibrechten Tabelle Kurzbeschreibung
aggregationstate Aggregationszustand
calcmode Art der Berechnung bei intern abgeleiteten Daten
category Gibt an, ob eine Bildungsreaktion vorliegt oder nicht
controllingresult Liste der möglichen Kontrollergebnisse
data_standard Stoffdaten bei Standardbedingungen (25°, 1bar)
data_standard_pitzer Stoffdaten bei Standardbedingungen für das Pitzer-Modell
data_standard_sit Stoffdaten bei Standardbedingungen für das SIT-Modell
data_variable Stoffdaten bei nicht-Standardbedingungen
data_variable_pitzer Stoffdaten bei nicht-Standardbedingungen für das Pitzer-Modell
dataclass Eine Kombination aus einem nummerischem Element und der Datenkategorie
dataquality Liste der möglichen Qualitätslabels
datasource Liste der möglichen Datenquellen
datatype Art der Stoffdaten
datatype_x_calcmode Liste der erlaubten Kombinationen von datatype und calcmode
dbstatus Datenbankstatus
editor Liste der Editoren
element Periodensystem der chemischen Elemente
interaction Definiert Art und Beteiligte einer Wechselwirkung
interaction_standard Wechselwirkungsparamerter bei Standardbedingungen (25°, 1 bar)
interaction_variable Wechselwirkungsparameter bei nicht-Standardbedingungen
interactionmodel Liste erlaubter Wechselwirkungsmodelle
interactionmodel_x_phase Liste erlaubter Kombinationen von Wechselwirkungsmodellen und Phasen
reactions Liste der Reaktionspartner einer chemischen Reaktion
reference Detaillierte bibliographische Beschreibung einer Referenz (zitier fähige Publikation)
reference_author Liste der Autoren einer Publikation
reference_language Sprache der Publikation
reference_status Form der physischen Speicherung einer Literaturstelle/Kopie
I. Anhang
- 83 -
reference_type Art der Publikation (Buch, Report, Zeitschrift etc.)
tpfunc Liste von Temperatur- und Druckfunktionen
unctype Liste der möglichen Unsicherheiten
Anhang III: Tabellenübersicht
I. Anhang
- 84 -
Anhang IV: Ablauf des Dateneingabeprozesses
I. Anhang
- 85 -
I. Anhang
- 86 -
I. Anhang
- 87 -
I. Anhang
- 88 -
Anhang V: Übersicht der Privilegien für Datenbankobjekte, nach [B_EISEN1],
S. 186 - 190 Datenbankobjekt Privileg
Kurzbeschreibung
Tabellen und Sichten
SELECT Erlaubt das Lesen der Tabelle oder Sicht.
INSERT Erlaubt das Einfügen in eine Tabelle oder Sicht.
UPDATE Erlaubt das Ändern von Daten in einer Tabelle oder Sicht.
DELETE Erlaubt das Löschen von Daten aus einer Tabelle.
REFERENCES Erlaubt das definieren von Fremdschlüsseln, dabei muss man dieses Privileg für beide betroffene Tabellen besitzen.
TRIGGER Erlaubt das Anlegen von Triggern für die betroffene Tabellen.
Sequenzen
SELECT Erlaubt die Verwendung der Funktion currval mit der Sequenz.
UPDATE Erlaubt die Verwendung der Funktionen nextval und setvall mit der Sequenz
USAGE Erlauben die Verwendung der Funktionen currval und nextval mit der Sequenz.
Funktionen
EXECUTE Erlaubt das Ausführen einer Funktion.
Schemas
CREATE Erlaubt das Erzeugen von neuen Objekten im Schema.
USAGE Erlaubt die Verwendung von Objekten im Schema.
Datenbanken
CONNECT Erlaubt das Verbinden mit der Datenbank.
CREATE Erlaubt das Anlegen von Schemas in der Datenbank.
TEMP/TEMPORARY Erlaubt das Anlegen von temporären Tabellen in der Datenbank.
Sprachen
USAGE Erlaub das Verwenden von Sprachen zum erstellen neuer Funktionen.
Tablespaces
CREATE Erlaubt das Erzeugen von Objekten im Tablespace. Außerdem können neue Datenbanken angelegt werden, die den Tablespace als Default-Tablespace hat.
II. Literaturverzeichnis
- 89 -
II. Literaturverzeichnis
Bücher [B_XXXXX9]
[B_ABECK1] Abeck, S. , P. C. Lockemann, J. Schiller u. J. Seitz: Verteilte