Diplomarbeit Mathias Herzog - HZDR

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

1. EINLEITUNG ......................................................................................................... 1

2. IT-SICHERHEIT .................................................................................................... 3

2.1 ASPEKTE DER IT-SICHERHEIT ............................................................................ 3

2.1.1 Begriffe .......................................................................................................... 3

2.1.2 BSI: Leitfaden IT-Sicherheit ......................................................................... 5

2.1.3 Gesetze und Standards .................................................................................. 6

2.2 MAßNAHMEN ZUR DATENSICHERHEIT IN DATENBANKSYSTEMEN ...................... 8

2.2.1 Transaktion ................................................................................................... 8

2.2.2 Datenintegrität ............................................................................................ 10

2.3 VERSCHLÜSSELUNGSVERFAHREN ZUR SICHEREN KOMMUNIKATION ................ 13

2.3.1 Kryptographische Grundlagen.................................................................... 13

2.3.2 Verfahren zur sicheren Kommunikation ..................................................... 17

3. AUTHENTIFIZIERUNG UND AUTORISIERUNG ........................................ 20

3.1 AUTHENTIFIZIERUNG ....................................................................................... 20

3.1.1 Passwort-Authentifizierung ......................................................................... 21

3.1.2 Smart Card .................................................................................................. 25

3.1.3 Fingerprint-Scanner .................................................................................... 26

3.1.4 Digitale Zertifikate ...................................................................................... 26

3.1.5 Digitale Signatur ......................................................................................... 27

3.1.6 Challenge-Response-Authentifizierung ....................................................... 27

3.2 AUTORISIERUNG .............................................................................................. 28

3.2.1 Discretionary Access Control (DAC).......................................................... 28

3.2.2 Mandatory Access Control (MAC) ............................................................. 29

3.2.3 Role-based Access Control (RBAC) ............................................................ 30

- II -

4. WEB-TECHNOLOGIEN UND SPEZIELLE ANGRIFFSTECHNIKEN ...... 31

4.1 SICHERHEITSASPEKTE WEBBASIERTER TECHNOLOGIEN ................................... 32

4.1.1 clientseitige Technologien ........................................................................... 34

4.1.2 serverseitige Technologien ......................................................................... 35

4.2 BEDROHUNGEN AUS DEM WWW ..................................................................... 38

4.2.1 Parametermanipulation .............................................................................. 38

4.2.2 SQL-Injection .............................................................................................. 41

4.2.3 Denial of Service (DoS) .............................................................................. 42

4.2.4 Cross-Site Scripting (XSS) .......................................................................... 44

5. THEREDA: AUSGANGSITUATION UND ANFORDERUNGEN ................ 45

5.1 ZIELE UND NUTZEN VON THEREDA ............................................................... 45

5.2 AUSGANGSSITUATION ...................................................................................... 46

5.3 FUNKTIONALE ANFORDERUNGEN .................................................................... 48

5.4 NICHT-FUNKTIONALE ANFORDERUNGEN ......................................................... 52

6. ENTWURF ............................................................................................................ 54

6.1 NUTZERVERWALTUNG ..................................................................................... 54

6.2 BENUTZERFUNKTIONEN ................................................................................... 55

6.2.1 unregisteredUser ......................................................................................... 55

6.2.2 registeredUser ............................................................................................. 57

6.2.3 author .......................................................................................................... 60

6.2.4 auditor ......................................................................................................... 62

6.2.5 accessAdministrator .................................................................................... 65

6.2.6 systemAdministrator .................................................................................... 67

6.3 SYSTEMFUNKTIONEN ....................................................................................... 71

6.3.1 Prüfen / Controlling .................................................................................... 71

6.3.2 Logging ....................................................................................................... 73

6.3.3 Verarbeitung ............................................................................................... 73

7. PROTOTYPISCHE REALISIERUNG .............................................................. 75

7.1 THEREDA: DER DATENBANKNUTZER ............................................................ 75

7.2 AUTHENTIFIZIERUNG ....................................................................................... 76

- III -

7.2.1 Serverauthentifizierung ............................................................................... 76

7.2.2 Clientauthentifizierung ................................................................................ 77

8. FAZIT .................................................................................................................... 79

I. ANHANG ............................................................................................................... 81

II. LITERATURVERZEICHNIS ............................................................................. 89

- IV -

Abbildungsverzeichnis

Abbildung 1: Zusammenhang der Begriffe .............................................................. 3

Abbildung 2: Einfaches kryptographisches Modell, nach [B_KAPPE1], S. 19 ..... 13

Abbildung 3: Symmetrische Kryptographie, vgl. [B_KAPPE1], S. 26 ................. 14

Abbildung 4: Asymmetrische Kryptographie, nach [B_KAPPE1], S. 28 .............. 16

Abbildung 5: SSL-Handshakeverfahren, vgl. [B_MARTI1], S. 89 ....................... 18

Abbildung 6: Asymmetrische Challenge-Response-Authentifizierung, vgl.

[B_KAPPE1], S. 51 .......................................................................... 28

Abbildung 7: THEREDA: Web-Architektur .......................................................... 47

Abbildung 8: THEREDA: Nutzergruppendiagramm ............................................. 48

Abbildung 9: USE CASE: unregisteredUser .......................................................... 55

Abbildung 10: USE CASE: registered User ............................................................. 57

Abbildung 11: USE CASE: author ........................................................................... 60

Abbildung 12: USE CASE: auditor .......................................................................... 63

Abbildung 13: USE CASE: accessAdministrator .................................................... 66

Abbildung 14: USE CASE: systemAdministrator .................................................... 67

Abbildung 15: Erstellung des Serverzertifikats mittels OpenSSL ........................... 76

Abbildung 16: Passwortprüffunktion, nach [B_KUNZx1], S. 156f ......................... 78

- V -

Tabellenverzeichnis

Tabelle 1: Vergleich der Methoden zur Benutzerauthentifizierung, vgl.

[I_BROMB1] .................................................................................... 21

Tabelle 2: Übersicht möglicher Passworträume, nach [B_KAPPE1], S. 42 ..... 22

Tabelle 3: Passwortrichtlinien, vgl. [B_RICHT1], S. 13 .................................. 23

Tabelle 4: Crack-Dauer für Windows-Passwörter (NTLM), nach [Z_CT0609],

S. 205 ................................................................................................ 24

Tabelle 5: Open Source Lizenzen, nach [I_KLEIJ1] ........................................ 32

Tabelle 6: Übersicht Angriffsmethoden, vgl. [I_BREAC1], S. 6 ..................... 38

Tabelle 7: THEREDA: Versionsänderungen .................................................... 47

Tabelle 8: THEREDA: Benutzerfunktionen, nach Nutzergruppen geordnet .... 50

Tabelle 9: THEREDA: Systemfunktionen ........................................................ 52

Tabelle 10: Nicht-funktionale Anforderungen, nach ISO 9126 .......................... 53

Tabelle 11: THEREDA: Vordefinierte Auditstati ............................................... 65

Tabelle 12: THEREDA: Passwortrichtlinien ...................................................... 71

- VI -

Abkürzungsverzeichnis

ADO.NET ............................. ActiveX Data Object.NET

API ........................................ Application Programming Interface

ASCII .................................... American Standard Code for Information Interchange

ASP ....................................... Active Server Pages

BDSG .................................... Bundesdatenschutzgesetz

BMBF .................................... Bundesministerium für Bildung und Forschung

BMU ...................................... Bundesministerium für Umwelt, Naturschutz und

Reaktorsicherheit

BMWi .................................... Bundesministerium für Wirtschaft und Technologie

BSI ........................................ Bundesamt für Sicherheit in der Informationstechnik

BSI G ..................................... BSI Gesetz

CAPTCHA ............................ Completely Automated Public Turing-Test to Tell

Computers and Humans Apart

CC ......................................... Common Criteria

CMS ...................................... Content Management System

COM ...................................... Component Object Model

COS ....................................... Chip Operating System

CSS ........................................ Cascading Style Sheets

DAC ...................................... Discretionary Access Control

DBMS ................................... Datenbankmanagementsystem

DIN ........................................ Deutsche Industrie Norm

DoS ........................................ Denial of Services

FSF ........................................ Free Software Foundation

HTML ................................... Hypertext Markup Language

HTTP ..................................... Hypertext Transfer Protocol

HTTPS .................................. HTTP Secure

ID .......................................... Identifikator

IEC ........................................ International Electrotechnical Commission

IIS .......................................... Internet Information Services

ISO ........................................ International Organization for Standardization

- VII -

ITSEC .................................... Information Technology Security Evaluation Criteria

ITSK ...................................... Deutschen IT-Sicherheitskriterien

J2EE ...................................... Java Platform, Enterprise Edition

JDBC ..................................... Java Database Connectivity

JSON ..................................... JavaScript Object Notation

JSP ......................................... Java Server Pages

JVM ....................................... Java Virtual Machine

LDSG .................................... Landesdatenschutzgesetz

MAC ...................................... Mandatory Access Control

MS-EXCEL ........................... Microsoft-Excel

NATO .................................... North Atlantic Treaty Organization

NSA ....................................... National Security Agency

NTML ................................... NT LAN Manager

OSI ........................................ Open Source Initiative

PHP ....................................... PHP: Hypertext Preprocessor

PIN ........................................ Personal Identification Number

RBAC .................................... Role-bases Access Control

SigG ...................................... Signaturgesetz

SQL ....................................... Structured Query Language

SSI ......................................... Server Side Includes

SSL ........................................ Secure Socket Layer

TAN ...................................... Transaction Authentication Number

TCP ....................................... Transmission Control Protocol

TCSEC .................................. Trusted Computer Security Evaluation Criteria

THEREDA ............................ Thermodynamische Referenzdatenbasis

TKG ...................................... Telekommunikationsgesetz

TLS ........................................ Transport Layer Security

URL ....................................... Uniform Resource Locator

WAL ...................................... Write-Ahead-Log

WWW ................................... World Wide Web

XML ...................................... Extensible Markup Language

XSS ....................................... Cross-Site Scripting

- 1 -

1. Einleitung

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.


Chiffrierverfahren



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


Chiffrierverfahren



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 -


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


- 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.


- 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.


- 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.


- 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

Passwortlänge Erlaubte Zeichen Dauer

6 [a-z], [A-Z], [0-9] 1 Minute

6 [a-z], [A-Z], [0-9], [typ. Sonderzeichen] 6 Minuten

8 [a-z], [A-Z], [0-9] 2 Tage und 17 Stunden

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.


- 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])


- 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])


- 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.


- 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


- 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])


- 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 -


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].


- 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.


- 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])


- 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])


- 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#.


- 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


- 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])


- 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,


- 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.


- 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.


- 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


- 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:


- 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.


- 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 -


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


- 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.


- 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


- 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


- 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.


- 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.


- 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.


- 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.


- 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

projektspezifische Werte bestimmt.

Tabelle 12: THEREDA: Passwortrichtlinien

Methode Festlegungen

Passwortzyklus (Zeitlimit)

Keiner

Wiederverwendung 3

Wörterlisten siehe [I_COTSE1]

Zeichensatz [a-z], [A-Z], [0-9], typ. Sonderzeichen

Passwortlänge min. 5

Die Prüfung dieser Richtlinien kann z.B. mittels PHP realisiert werden. Um die

Sicherheit der Passwörter zu gewährleisten, müssen die in PHP definierten

Bedingungen lückenlos arbeiten. Damit ist gemeint, dass bei Nichterfüllung einer dieser

Bedingungen der Passwortkandidat vom System abgelehnt wird. Des Weiteren sollte

die Übertragung zwischen Client und Server verschlüsselt stattfinden.

Für die Passwortprüfung gibt es für PHP die Erweiterung “ext/crack“. Mit dieser lässt

sich der Passwortkandidat gegen eine Wörterliste, auf die Mindestlänge von 5 Zeichen

und die Zeichenzusammensetzung prüfen. Bei Letzterem wird geprüft, ob der

Passwortkandidat nicht ausschließlich aus Klein- oder Großbuchstaben oder aus Zahlen

besteht.

6. Entwurf

- 72 -

Das Ergebnis dieser Überprüfung kann entweder TRUE für ein „starkes Passwort“ oder

FALSE für ein „nicht ausreichend starkes Passwort“ sein. Unabhängig davon, welche

dieser Varianten verwendet wird, als Ergebnis erhält man im positiven Fall ein starkes

Passwort, aus dem dann der Hashwert berechnet und in der Datenbank abgelegt wird.

Eingabevalidierung

Die Eingabeüberprüfung dient der Integritätssicherung sowie dem Schutz vor

Angriffen. Im Folgenden werden dabei vor allem SQL-Injections betrachtet. Dabei

können zur Validierung PHP-spezifische Funktionen verwendet werden, die in

Kombination mit den in der Datenbank definierten Integritätsbedingungen die

Integritätssicherung gewährleisten.

So können durch PHP Funktionen, wie z.B. is_numeric() oder is_string(), die

eingegebenen Parameterwerte dahingehend geprüft werden, ob sie den von der

Datenbank erwarteten Datentypen entsprechen. Dies ist für Datenabfragen sowie

Dateneingaben notwendig. Bei Dateneingaben muss des Weiteren darauf geachtet

werden, dass die semantische Integrität eingehalten wird. Diese Überprüfung wird vom

Datenbanksystem automatisch vorgenommen, z.B. durch die Einhaltung von

Fremdschlüsselbeziehungen. Die Fremdschlüsselbeziehungen einer Tabelle können direkt beim Anlegen mit erzeugt werden

und werden daraufhin bei Einfüge-, Aktualisierungs- oder Löschaktionen kontrolliert. Die dafür

notwenige Ergänzung des CREAT-Befehls lautet:

FOREIGN KEY (Spalte) REFERENCES referenzTabelle (referenzSpalte)

Neben den Funktionen zur Typüberprüfung bietet PHP auch spezielle Funktionen zum

Zugriff auf die PostgreSQL-Datenbank und zur Maskierung von SQL-Statements. Die

Funktion pg_escape_string() maskiert die im SQL-Statement enthaltenen

Sonderzeichen, so dass diese keinen Einfluss mehr auf die Datenbank haben. Damit

lassen sich SQL-Injections unterbinden.

6. Entwurf

- 73 -

6.3.2 Logging

Logging ist das Protokollieren aller Aktionen am Datenbanksystem, einerseits die

Protokollierung aller vom Nutzer getätigten Aktionen, aller Datenabfragen und

-manipulationen, und andererseits die Login- und Logoutinformationen. Des Weiteren

werden von der PostgreSQL-Datenbank automatisch Write-Ahead-Log (WAL) Dateien

auf die Festplatte geschrieben. Diese enthalten Aufzeichnungen sämtlicher

Schreiboperationen, die im Datenbanksystem vorgenommen wurden. Bei der

Festlegung der Logging-Strategie sollte man berücksichtigen, dass die Zugriffe auf die

PostgreSQL-Datenbank entpersonalisiert stattfinden.

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 -


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.


- 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


- 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.


- 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

interactiontype Art des Wechselwirkungsparameters

modification Modifikationsform fester Phasen

pcon Komponenten einer Phase

pconcomposition Zusammensetzung einer Phase

pcontype Art einer Phasenkomponente

phase In sich abgeschlossene chemische Phase

physicalconstants Allgemeine physikalische Naturkonstanten

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 -


Bücher [B_XXXXX9]

[B_ABECK1] Abeck, S. , P. C. Lockemann, J. Schiller u. J. Seitz: Verteilte

Informationssysteme, dpunkt.verlag GmbH Heidelberg, 2002

[B_BALZE1] Balzert, H.: UML 2 kompakt, Elsevier GmbH, Spektrum

Akademischer Verlag, 2005, 2. Auflage

[B_BLESS1] Bless, R. , E. Blaß, M. Conrad, H. Hof,K. Kutzner,S. Mink u. M.

Schöller: Sichere Netzwerkkommunikation, Springer-Verlag

Berlin Heidelberg New York, 2005, 1. Auflage

[B_BOENI1] Boenigk, C.: PostgreSQL, dpunkt.verlag GmbH Heidelberg,

2003, 1. Auflage

[B_BRÖSS1] Brössler, P.: Flexible und effiziente Unterstützung von

Transaktionen auf persistenten Objekten, Verlag Shaker, 1994

[B_ECKER1] Eckert, C.: IT-Sicherheit, Oldenbourg Wissenschaftsverlag

GmbH, 2005

[B_EISEN1] Eisentraut, P. u. B. Helmle: PostgreSQL Administration, O'Reilly

Verlag, 2009, 1. Auflage

[B_EISEN2] Eisentraut, P.: PostgreSql GE-PACKT, mitp-Verlag/Bonn, 2005

[B_FERRA1] Ferraiolo, D., D. R. Kuhn u. R. Chandramouli: Role-based access

control, ARTECH HOUSE, Inc., 2003


- 90 -

[B_GERHA1] Gerhardt, W.: Zugriffskontrolle bei Datenbanken, Oldenbourg

Wissenschaftsverlag GmbH, 1993

[B_HAUSE1] Hauser, T. , C. Wenz u. F. Maurice: Das Website Handbuch,

Mark+Technik Verlag, 2008

[B_HERBO1] Herbolsheimer, A.: Datenbank-Programmierung, Addison-

Wesley Verlag, 2005, 5. Auflage

[B_KANNE1] Kannengiesser, M.: PHP 5 Objektorientierte Programmierung,

Franzis Verlag GmbH, 2009

[B_KAPPE1] Kappes, M.: Netzwerk- und Datensicherheit, Vieweg+Teubner


[B_KEMPE1] Kemper, A u. A. Eickler: Datenbanksysteme, Oldenbourg

Wissenschaftsverlag GmbH, 2004, 5. Auflage

[B_KLEIN1] Kleinschmidt, P. u. C. Rank: Relationale Datenbanksysteme,

Springer-Verlag Berlin Heidelberg New York, 2005, 3. Auflage

[B_KOITZ1] Koitz, R.: Informatikrecht - Schnell erfasst, Springer-Verlag

Berlin Heidelberg New York, 2002

[B_KRIHA1] Kriha, W. u. R. Schmitz: Internet-Security aus Software-Sicht,

Springer-Verlag Berlin Heidelberg New York, 2008

[B_KUNIC1] Kunick, S.: PostgreSQL und Windows, Books on Demand

GmbH, Norderstedt, 2008

[B_KUNZx1] Kunz C. u. S. Esser: PHP-Sicherheit, dpunkt.verlag GmbH

Heidelberg, 2008, 3. Auflage


- 91 -

[B_LEMAY1] Lemay, L. u. R. Cadenhead: Java 2 in 21 Tagen, Mark+Technik


[B_LONEY1] Loney, Kevin u. B. Bryla: QRACLE DATABASE 10g DBA-

Handbuch, Carl Hanser Verlag Münschen Wien, 2006

[B_MARTI1] Martius, K.: Sicherheitsmanagement in TCP/IP-Netzen, Vieweg

& Sohn Verlagsgesellschaft mbH, 2000

[B_MEINE1] Meinel, C. u. H. Sack: WWW, Springer-Verlag Berlin Heidelberg

New York, 2004

[B_MOMJI1] Momjian, B.: PostgreSQL Einführung und Konzepte, Addison-

Wesley Verlag, 2001, 1. Auflage

[B_RAHMx1] Rahm, E. u. G. Vossen: Web & Datenbanken, dpunkt.verlag

GmbH Heidelberg, 2003, 1. Auflage

[B_RAMAK1] Ramakrishnan, R. u. J. Gehrke: Database Management Systems,

The McGraw-Hill Companies, Inc., 2000, Second Edition

[B_RICHT1] Richter, M.: Identity Management, VDM Verlag Dr. Müller, 2007

[B_SAAKE1] Saake, G. , A. Heuer u. K.-U. Sattler: Datenbanken:

Implementierungstechniken, mitp-Verlag/Bonn, 2005, 2. Auflage

[B_STÖRL1] Störl, U.: Backup und Recovery in Datenbanksystemen, B.G.

Teubner GmbH Stutgart/Leipzig/Wiesbaden, 2001, 1. Auflage

[B_SWOBO1] Swoboda, J. , S. Spitz u. M. Pramateftakis: Kryptographie und IT-

Sicherheit, Vieweg+Teubner Verlag, 2008, 1. Auflage


- 92 -

[B_ULLEN1] Ullenboom, C.: Java ist auch eine Insel, Galileo Press, 2005

[B_WALTE1] Walter, T.: Kompendium der Web-programmierung: Dynamische

Web-sites, Springer-Verlag Berlin Heidelberg New York, 2008

[B_ZEHND1] Zehnder, C. A.: Informationssysteme und Datenbanken, vdf

Hochschulverlag AG, 2005, 8. Auflage

[B_ZWINT1] Zwintzscher, O.: Software-Kopomemten im Überlick:

Einführung, Klassifizierung und Vergleich von JavaBeans, .Net,

EJBs, Corba, UML2 , W3l, 2004, 1. Auflage

Internet [I_XXXXX9]

[I_ANONY1] anonym-surfen.com (2003-2009): Datenschutz, URL:

http://www.anonym-surfen.com/datenschutz/definition-

datenschutz/, 02.07.2009

[I_BREAC1] Breach Security, Inc. (Feb. 2009): THE WEB HACKING

INCIDENTS DATABASE 2008, URL:

http://www.breach.com/resources/whitepapers/downloads/WP_W

ebHackingIncidents_2008.pdf, 03.08.2009

[I_BROMB1] Bromba, Dr. M. (11.06.2009): BIOIDENTIFICATION, URL:

http://bromba.com/faq/biofaqe.htm, 06.09.2009

[I_BSIxx1] Bundesamt für Sicherheit in der Informationstechnik

(Unbekannt): Startseite, URL:

https://www.bsi.bund.de/cln_164/DE/Home/home_node.html,

02.05.2009


- 93 -

[I_BSIFB1] BSI für Bürger (2009): IT-Sicherheit, URL: http://www.bsi-fuer-

buerger.de/, 01.06.2009

[I_BSIGx1] Bundesamt für Sicherheit in der Informationstechnik

(14.04.2009): Gesetz zur Stärkung der Sicherheit in der

Informationstechnik des Bundes, URL:

https://www.bsi.bund.de/cae/servlet/contentblob/639500/publicati

onFile/36134/bsiges2009_pdf.pdf, 02.05.2009

[I_BSIGS1] Bundesamt für Sicherheit in der Informationstechnik (2009): IT

Grundschutz, URL:

https://www.bsi.bund.de/cln_164/sid_4D1B812CB46B94E2381D

2615CB4BF244/DE/Themen/ITGrundschutz/itgrundschutz_node.

html, 02.05.2009

[I_BSILF1] Bundesamt für Sicherheit in der Informationstechnik (2009):

Leitfaden Informationssicherheit, URL:


onFile/34672/GS-Leitfaden_pdf.pdf, 02.05.2009

[I_BSISL1] Bundesamt für Sicherheit in der Informationstechnik

(Unbekannt): SSL; Studie und Umsetzungskonzept, URL:

https://www.bsi.bund.de/cln_134/DE/Themen/weitereThemen/Ve

rwaltungsPKIVPKI/Wurzelzertifizierungsstelle/SSL/ssl_node.htm

l, 10.09.2009

[I_CAMPU1] CampusSource (26.02.2004): Open Source, URL:

http://www.campussource.de/opensource/, 27.08.2009


- 94 -

[I_COTSE1] Cotse.Net (Unbekannt): Word Lists, URL:

http://www.cotse.com/tools/wordlists.htm, 03.10.2009

[I_DEUTS1] Deutschland sicher im Netz e.V., Berlin (2009): Digitale

Zertifikate, URL: https://www.sicher-im-

netz.de/unternehmen/160.aspx, 10.09.2009

[I_DEUTS2] Deutschland sicher im Netz e.V., Berlin (Unbekannt):

Elektronische Signatur, URL: https://www.sicher-im-

netz.de/unternehmen/159.aspx, 10.09.2009

[I_ENGEL1] Engelmann, K. und L. Böhringer (13.07.2004): IT Security

Seminar, URL: http://fara.cs.uni-

potsdam.de/~engelman/8.%20Semester/IT%20Security/Vortrag/p

df/IT%20Security%20Seminar.pdf, 21.07.2009

[I_ESSER1] Esser, S. (2006-2007): Suhosin, URL: http://www.hardened-

php.net/suhosin/, 10.09.2009

[I_FACHH1] Fachhochschule Nordwestschweiz (25.03.2009): Datenbank-

Architektur, URL:

http://web.fhnw.ch/plattformen/dbarc/modulunterlagen/dbarc-

dac-mac.pdf, 28.07.2009

[I_GREEN1] Green, R. (2009): signed Applets : Java Glossary, URL:

http://mindprod.com/jgloss/signedapplets.html, 15.06.2009

[I_HENNE1] Hennebrueder, S. (06.03.2007): Java EE Application Security,

URL: http://www.laliluna.de/download/java-security-tutorial-

de.pdf, 15.06.2009

[I_HILKE1] Hilkenbach, Dr. R. (11.01.2002): Server Side Includes (SSI),

URL: http://www.netztrainer.de/ssi/ssi.html, 15.06.2009


- 95 -

[I_HTWDD1] HTW Dresden (Unbekannt): Grundlagen, URL:

http://wwwmi.informatik.htw-dresden.de/wbt-

ds2/application/grundlagen/grundlagen.pdf, 12.07.2009

[I_HTWDD2] HTW Dresden (Unbekannt): Semantische Integrität, URL:


ds2/application/semantisch/semantisch.pdf, 12.07.2009

[I_HTWDD3] HTW Dresden (Unbekannt): Ablaufintegrität, URL:


ds2/application/operational/operational.pdf, 12.07.2009

[I_HTWDD4] HTW Dresden (Unbekannt): Physische Integrität, URL:


ds2/application/physisch/physisch.pdf, 12.07.2009

[I_INSTI1] Institut für Internet-Sicherheit (Unbekannt): Verschlüsselung mit

TLS/SSL, URL: http://www.internet-sicherheit.de/forschung/

aktuelle-forschungsprojekte/internet-fruehwarnsysteme/

ergebnisse/verschluesselung-mit-tlsssl/, 06.09.2009

[I_INTER1] Internet Security Zone (2009): Glossary, URL:

http://www.internetsecurityzone.com/Glossary, 26.06.2009

[I_JOOML1] Joomla! Deutschlang (2005 - 2009): Joomla! …because open

source matters, URL: http://www.joomla.de/, 20.08.2009

[I_KLEIJ1] Kleijn, A. (25.07.2006): Open-Source-Lizenzen, URL:

http://www.heise.de/open/Open-Source-Lizenzen--/artikel/75786,

27.08.2009


- 96 -

[I_LEITE1] Leitenmüller, H. (2000/2001): JSP- Java Server Pages, URL:

http://www.ssw.uni-

linz.ac.at/Teaching/Lectures/Sem/2000/Leitenmueller/,

16.06.2009

[I_MACKx1] Mack , H. (1999): Sicherheit in Java und ActiveX, URL:

http://www.secorvo.de/publikationen/javaactx.pdf, 15.06.2009

[I_MARSC1] Marschke, E. (31.08.2004): Apache 2, OpenSSL und HTTPS:

server- und Client- Authentifizierung mit Zertifikaten über

verschlüsselte Internet-Verbindungen, URL:

http://www.marschke.info/admin/ap_opssl_https.html, 14.09.2009

[I_MICRO1] Microsoft (09.11.2004): Beschreibung von ActiveX-

Technologien, URL: http://support.microsoft.com/kb/154544/de,

10.09.2009

[I_MICRO2] Microsoft (2009): ASP.NET-Sicherheitsarchitektur, URL:

http://msdn.microsoft.com/de-de/library/yedba920(VS.80).aspx,

16.06.2009

[I_OPENS1] OpenSSL (Unbekannt): Welcome to the OpenSSL Project, URL:

www.openssl.org, 10.09.2009

[I_PFAHL1] Pfahler, P. und M. Thies (2009): Skriptsprachen, URL: http://ag-

kastens.upb.de/lehre/material/skriptsprachen/folien.html,

10.09.2009

[I_PHPGR1] The PHP Group (2001-2009): php, URL: http://php.net/,

10.09.2009


- 97 -

[I_PLANE1] PlaNet-ET Konsortium (Unbekannt): Zugriffskontrolle, URL:

http://e-campus.uibk.ac.at/planet-et-fix/M9/details/3008_ac.htm,

07.09.2009

[I_POSTG1] PostgreSQL Global Development Group (1996-2009):

PostgrSQL, URL: http://www.postgresql.org/, 10.09.2009

[I_POSTG2] PostgreSQL Global Development Group (1996-2009): pgcrypto,

URL: http://www.postgresql.org/docs/8.3/static/pgcrypto.html#

PGCRYPTO-WITH-WITHOUT-OPENSSL, 19.09.2009

[I_SCHMU1] Schmuhl, F. u. S. Schneemann (28.11.2006): Biometrische

Authentifizierungsverfahren in der Mediensicherheit, URL:

http://www.sebastian-

schneemann.de/userfiles/file/mesihandout.pdf, 10.09.2009

[I_SECFO1] SecurityFocus (02.02.2005): Apache 2 with SSL/TLS: Step-by-

Step, Part 2, URL: http://securityfocus.com/infocus/1820,

14.09.2009

[I_SECNE1] SecureNet (01.08.2006): Sicherheit von Webanwendungen, URL:


onFile/30642/WebSec_pdf.pdf, 14.06.2009

[I_SELFH1] selfhtml.org (2007): ActiveX und HTML, URL:

http://de.selfhtml.org/intro/technologien/activex.htm, 15.06.2009

[I_SOFTE1] Softed Systems (2009): Wie funktioniert HTTPS?, URL:

http://www.softed.de/fachthema/https.aspx, 31.07.2009

[I_STELL1] Steller, H. (2003): Java-Servlets, URL: http://www.ag-

nbi.de/lehre/03/S_WST/Referate/servlets.pdf, 16.06.2009


- 98 -

[I_SUNJA1] Sun Microsystems, Inc. (Unbekannt): Applets, URL:

http://java.sun.com/applets/, 10.09.2009

[I_SUNJS1] Sun Microsystems, Inc. (Unbekannt): Java Servlet Technology

Overview, URL:

http://java.sun.com/products/servlet/overview.html, 27.08.2009

[I_SUNSA] Sun Microsystems, Inc. (1997-1999): Java Security Architecture,

URL:

http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-

spec.doc1.html, 28.08.2009

[I_SUNSP1] Sun Microsystems, Inc. (Unbekannt): JavaServer Pages

Technology, URL: http://java.sun.com/products/jsp/, 10.09.2009

[I_TECHF1] techFAQ (Unbekannt): What is a Smart Card?, URL:

http://www.tech-faq.com/smart-card.shtml, 06.09.2009

[I_ZIRNx1] Zirn , C. (17.01.2005): (Verteilte) Denial-of-Service-Angriffe und

Gegenmaßnahmen, URL: http://pvs.informatik.uni-

heidelberg.de/Teaching/CSFP-0506/zirn.pdf, 18.06.2009

Zeitschriften und Reports [Z_XXXXXX]

[Z_CT0209] Rütten, C., Schön kompliziert, c’t – Magazin für

Computertechnik, 02/2009, S. 86f

[Z_CT0609] Arbeiter, S. u. Deeg M., Bunte Recjemlmecjte, c’t – Magazin für

Computertechnik, 06/2009, S. 204ff


- 99 -

[Z_ALTMAI] Altmaier, M., V. Brendler, S. Hagemann, H.-J. Herbert, B.

Kienzler, C. M. Marquardt, H. C. Moog, V. Neck, A. Richter, W.

Voigt u. S. Wilhelm, THEREDA – Ein Beitrag zur

Langzeitsicherheit von Endlagern nuklearer und nichtnuklearer

Abfälle,, Internationale Zeitschrift für Kernenergie, 53 (2008),

S. 249-253

Sonstiges [S_XXXXX9]

[S_FRITZ1] Fritzsche, H., Informationssicherheit: Script zur

Lehrveranstaltung, HTW Dresden, SS 2008

[S_MÜNZB1] Münzberg, M., Konzeptioneller Entwurf und prototypische

Realisierung einer Datenbanklösung für chemische

Risikoanalysen, HTW Dresden, 06.08.2007

Eidesstattliche Erklärung

Hiermit erkläre ich, dass ich die von mir am heutigen Tag eingereichte Diplomarbeit

selbstständig verfasst und ausschließlich die angegebenen Hilfsmittel benutzet habe.

__________________________

Mathias Herzog

Leipzig, den 02.11.2009

Documents

Diplomarbeit Mathias Herzog - HZDR