Architektur und Administration einer webbasierten
Werbung
Hochschule für Technik und Wirtschaft Dresden (FH) Fachbereich Informatik/Mathematik Diplomarbeit im Studiengang Wirtschaftsinformatik Thema: „Architektur und Administration einer webbasierten chemischen Stoffdatenbank. Konzept und Prototyp“ eingereicht von: Alexander Ihlau eingereicht am: 15.10.2007 Betreuer: Prof. Dr. oec. Gunter Gräfe Fachbereich Informatik/ Mathematik Hochschule für Technik und Wirtschaft Dresden (FH) Dr. Vinzenz Brendler Abteilung Radiochemie Forschungszentrum Dresden-Rossendorf e. V. Inhaltsverzeichnis Inhaltsverzeichnis II Abbildungsverzeichnis V Tabellenverzeichnis Verzeichnis verwendeter Abkürzungen VI VII 1. Einleitung 1 2. Architektur webbasierter Datenbanksysteme 3 3. 4. 2.1 Allgemeiner Aufbau und Technologien webbasierter Lösungen......................3 2.2 Datenbanken im Web........................................................................................5 2.3 Vor- und Nachteile webbasierter Datenbanken ................................................6 2.4 Technologien und Zugriffsmethoden für webbasierte Datenbanken ................9 Sicherheit und Gefahren bei Web-Anwendungen im Internet 16 3.1 Informationssicherheit und Schutzziele ..........................................................16 3.2 Schwachpunkte und Angriffsszenarien...........................................................18 3.3 Schutzmaßnahmen und –techniken.................................................................20 3.3.1 Verhindern von Fremdzugriffen und –übernahmen................................20 3.3.2 Verschlüsselungsstrategien .....................................................................23 Administration von Datenbanken im Web 26 4.1 Grundlegende Konzepte der Datenbank-Administration................................26 4.2 Rechte- und Nutzerverwaltung .......................................................................29 4.3 Datensicherung................................................................................................30 4.4 Tuning und Abfrageoptimierung.....................................................................32 4.5 Auditing und Protokollierung .........................................................................34 4.6 Fehlermanagement ..........................................................................................35 II 5. ISDA: Ausgangssituation und Ist-Analyse 5.1 Das Verbundprojekt ISDA zur Verwaltung chemischer Stoffdaten ...............37 5.2 Ziele und Nutzen von ISDA............................................................................38 5.3 Chemisches Modell und technologische Umsetzung......................................41 5.4 ISDA auf dem Datenbanksystem „PostgreSQL“............................................43 5.4.1 Implementierung in Soft- und Hardware, Installation, Hinweise ...........43 5.4.2 Funktionsbeschreibung wichtiger ISDA-Tabellen..................................45 5.5 6. Ist-Analyse von ISDA .....................................................................................46 Anforderungsanalyse und Konzeption Ziel und Nutzen des Administrationssystems .................................................48 6.2 Funktionale Anforderungen ............................................................................49 6.2.1 Allgemeine Systemfunktionen ................................................................49 6.2.2 Tabellen, Attribute und Datenstruktur ....................................................51 Nicht-Funktionale Anforderungen ..................................................................53 6.3.1 Allgemeine Anforderungen (Rahmenbedingung)...................................53 6.3.2 Qualitätsanforderung...............................................................................54 6.4 Fehlerbehandlung............................................................................................56 6.5 Architektur der ISDA-Umsetzung ..................................................................57 6.6 Konzeption - Use cases ...................................................................................59 Realisierung eines Prototyps zur Administration einer chemischer Stoffdatenbank 8. 48 6.1 6.3 7. 37 63 7.1 Einrichtung und Installation von Web- und Datenbankserver........................63 7.2 Aufbau und Realisierung des Prototyps..........................................................64 7.2.1 Architektur und Aufbau ..........................................................................64 7.2.2 Programmtechnische Realisierung mit PHP und SQL............................67 7.2.3 Codebeispiel............................................................................................69 7.2.4 Frontend, Layout und Design..................................................................72 Fazit 74 III Anlagen 76 Literaturverzeichnis 80 Glossar 83 IV Abbildungsverzeichnis Abbildung 1: einfache Client-Server-Darstellung ..........................................................4 Abbildung 2: Darstellung einer in das DBMS integrierten CGI-basierten Datenbankanbindung...............................................................................14 Abbildung 3: Flexibilität der Eigenschaften im ISDA-Datenbank-Modell am Beispiel eines Minerals .....................................................................42 Abbildung 4: Gesamtstruktur des ISDA-Datenbank-Systems bei Beginn der Diplomarbeit .....................................................................................44 Abbildung 5: Entity-Relationship-Diagramm...............................................................51 Abbildung 6: neue Architektur des ISDA-Systems ......................................................57 Abbildung 7: Ablaufdiagramm eines allgemeinen Anmeldeprozesses (use case 1).....60 Abbildung 8: Ablaufdiagramm mit den Optionen eine "Editors" nach dem Anmeldeprozess (use case 2) ..................................................................61 Abbildung 9: Ablaufdiagramm mit den Optionen eines "Administrators" nach dem Anmeldeprozess (use case 3)..................................................62 Abbildung 10: Darstellung des Aufbaus der Seiten und Objekte des Prototyps.............64 Abbildung 11: Code-Ausschnitt aus "site_structure.php" ..............................................70 Abbildung 12: Code-Ausschnitt aus "page.php" ............................................................71 Abbildung 13: Screenshot Protoyp - Registrierung ........................................................72 Abbildung 14: Screenshot Prototyp - Login ...................................................................73 Abbildung 15: Screenshot Prototyp - Hauptseite (als Administrator) ............................73 V Tabellenverzeichnis Tabelle 1: Hauptunterschiede beim Zugriff relationaler DBMS und Information Retrieval Systeme ......................................................................6 Tabelle 2: Funktion wichtiger ISDA-Tabellen .............................................................45 Tabelle 3: Funktionale Anforderungen: Verarbeitungsfunktionen ...............................50 Tabelle 4: Funktionale Anforderungen: Prüffunktionen...............................................50 Tabelle 5: Tabelle "isda_users".....................................................................................52 Tabelle 6: Tabelle "isda_user_roles" ............................................................................52 Tabelle 7: Tabelle "isda_user_activate"........................................................................52 Tabelle 8: Use case 1: Nutzerregistrierung ...................................................................60 Tabelle 9: Use case 2: Funktionen eines Editors ..........................................................61 Tabelle 10: Use case 3: Funktionen eines Administrators ..............................................62 Tabelle 11: Im Prototyp verwendete PHP-Klassen.........................................................76 Tabelle 12: Im Prototyp verwendete PHP-Seiten ...........................................................78 Tabelle 13: Im Prototyp verwendete StyleSheets ...........................................................79 VI Verzeichnis verwendeter Abkürzungen BMBF Bundesministeriums für Bildung und Forschung BMWi Bundesministeriums für Wirtschaft DBS/ DBMS Datenbanksystem/ Datenbankmanagementsystem DBA Datenbankadministrator dbo database owner (Datenbankeigner) ERD Entity-Relationship-Diagramm FZD Forschungszentrum Dresden-Rossendorf e.V. GRS Gesellschaft für Anlagen- und Reaktorsicherheit ISDA Integriertes Sorptions-Datenbankensystem für Wechselwirkungen chemisch-toxischer und radioaktiver Kontaminanten mit mineralischen Systemen ITSEC Information Technology Security Evaluation Criteria MD5 Message-Digest-Algorithm 5 RES³T Rossendorf Expert System for Surface and Sorption Thermodynamics SQL Structured Query Language SODA Sorptions-Datenbank TCSEC Trusted Computer System Evaluation Criteria (Orange Book) VII 1. Einleitung Das Thema der Diplomarbeit orientiert sich an einem dringenden Bedarf des Forschungszentrums Dresden-Rossendorf (FZD). Das Institut für Radiochemie des FZD ist zurzeit damit befasst, im Rahmen eines Verbundprojektes mit anderen Instituten das System einer chemischen Stoffdatenbank neu zu organisieren und zu strukturieren. Das Verbundprojekt hat die Bezeichnung ISDA – „Integriertes Sorptions-Datenbanksystem für Wechselwirkungen chemischer und radioaktiver Kontaminanten mit mineralischen Systemen“. Ziel dieses Projektes ist es, den in verschiedenen Inhouse-Datenbanken verankerten und zum Teil noch unstrukturierten großen Umfang an Daten und Knowhow zum Fachgebiet in einem gemeinsamen Datenbanksystem zusammenzuführen. Durch die Web-Anbindung soll zugleich erreicht werden, dass die interaktive Arbeit aller Nutzer des Datenbanksystems wesentlich verbessert wird, der Daten- und Wissensspeicher einer breiteren Öffentlichkeit zur Verfügung gestellt werden kann und die Vorteile einer webbasierten Datenbank für die Organisation des Datenbanksystem selbst genutzt werden können. Die vorliegende Diplomarbeit widmet sich einem ganz bestimmten Teilaspekt dieses komplexen Themas – der Entwicklung einer geeigneten Administrationsstrategie und struktur für diese webbasierte Datenbanklösung, da hierfür im Institut für Radiochemie des FZD keine Erfahrungen vorliegen. Um diese Aufgabe zu lösen, werden zunächst die theoretischen Grundlagen und der aktuelle Entwicklungsstand hinsichtlich der Architektur, Sicherheit und Administration webbasierter Datenbanken in einer Übersicht dargestellt. Damit wird bereits für den Anwender eine wichtige Orientierung über den gegenwärtigen Erkenntnisstand und über optionale Lösungswege gegeben. In enger Zusammenarbeit mit dem Anwender werden ausgehend von der Ausgangssituation des Projektes die weiteren Anforderungen an die Architektur und Administration der webbasierten chemischen Stoffdatenbank analysiert und die -1- Konzeption für deren praktische Lösung entwickelt. Das Problem der Datensicherheit und der Zugriffsrechte ist dabei von übergreifender Bedeutung. Die Diplomarbeit ist in das Gesamtprojekt eingeordnet. Ihr Wert liegt vor allem in der konzeptionellen Zuarbeit für ein wesentliches Gebiet des Projektes. In der Konzeption der Architektur und der Administration der webbasierten chemischen Stoffdatenbank und der Entwicklung eines Prototyps dazu sieht das Institut für Radiochemie des FZD einen sehr wichtigen Beitrag für die Weiterführung des Verbundprojektes ISDA. -2- 2. Architektur webbasierter Datenbanksysteme 2.1 Allgemeiner Aufbau und Technologien webbasierter Lösungen Um Technologien webbasierter Datenbanken und deren Administration über das Internet genauer zu betrachten, werden im Folgenden zunächst die Grundlagen bzw. der generelle Aufbau webbasierter Lösungen allgemein kurz dargestellt. Üblicherweise unterscheidet man bei webbasierten Lösungen zwischen serverseitigen und clientseitigen Techniken. Eine serverseitige Technik ist ein Programm oder eine Programmiersprache, die von einem Webserver oder Applikationsserver ausgeführt wird. Sie ist, bis auf wenige Systemanforderungen, vom Client unabhängig. Als clientseitige Technik werden alle Techniken bezeichnet, die ein Programm des Endnutzers, in dem Fall der Browser, ausführen muss. HTML ist beispielsweise eine solche Technik, die allerdings von jedem gängigen Webbrowser beherrscht wird. Andere clientseitige Techniken, wie zum Beispiel JavaScript oder Flash, werden nicht von allen Browsern unterstützt oder benötigen zusätzliche Komponenten. Sie sind daher beim Einsatz von Internetanwendungen browserabhängig. Die Vorteile clientseitiger Technologien liegen hauptsächlich in der Entlastung des Servers, da eine komplexere Anwendung jeweils nur einmal heruntergeladen werden muss. Aufwendige Berechnungen und Funktionen müssen nicht bei jeder Anfrage des Clients vom Server berechnet und die Ergebnisse wieder zurück an den Browser geschickt werden. Um Datenbanken im Web verfügbar zu machen, eignen sich serverseitige Technologien sehr gut, wofür bereits eine Reihe von verschiedensten Techniken zur Verfügung steht. Neben der Unabhängigkeit vom Browser haben serverseitige Techniken noch weitere Vorteile: - Der Benutzer bekommt nur die Ergebnisse von Berechnungen auf dem Browser zu sehen. Andere Nutzerdaten oder komplizierte Prozesse und Methoden, deren -3- Vorgehensweise vielleicht sogar geheim ist, bleiben dem Nutzer verborgen und sind nicht ohne weiteres zugänglich. - Aufwendige Berechnungen und Datenbankabfragen werden zum Teil serverseitig schneller abgearbeitet, da zum einen die Server-Hardware meist besser ausgestattet ist als der Rechner des Benutzers, und zum anderen der Datenbankserver sich oft in der Nähe des Web- oder Applikationsservers befindet und damit lange Übertragungswege beziehungsweise eine hohe Netzlast vermieden werden. - Ein weiterer Vorteil serverseitiger Techniken ist die Möglichkeit, Benutzer- und Zugangsdaten, zum Beispiel für den Zugriff auf Datenbanken, zu speichern. Diese auf dem Client-Rechner zu speichern ist, bis auf wenige Ausnahmen, nicht sinnvoll. Es besteht auch die Möglichkeit, client- und serverseitige Technologien zu kombinieren, beispielsweise PHP und Flash, um die Vorteile beider nutzen zu können. In der folgenden Abbildung wird eine einfache Client-Server-Architektur dargestellt, wobei der Client HTML-Seiten von einem Server anfordert, herunter lädt und über den Webbrowser darstellt. Abbildung 1: einfache Client-Server-Darstellung -4- 2.2 Datenbanken im Web Das Web ermöglicht die globale Bereitstellung von Informationen und den globalen Zugriff auf zentrale Daten, Datenbanksysteme, die universelle Datenverwaltung. Die Kombination von Datenbanksystemen mit dem Internet birgt viele Nutzungsmöglichkeiten in sich und hat heute schon zu einer Vielzahl webbasierter Datenbankanwendungen geführt, wie zum Beispiel Online-Banking und -Nachrichten, Auftragsverfolgung, Virtuelles Warenhaus mit Bestellkatalogen. Das Potential, das der Zugriff über das Web für den Einsatz von Datenbanksystemen bietet, reicht von der Transaktionsverarbeitung beim elektronischen Handel (E-Commerce) über digitale Bibliotheken bis hin zu unternehmensübergreifenden Abwicklungen von Geschäftsprozessen aller Art. Der Begriff „Datenbanken im Web“ ist zunächst sehr weit gefasst und kann im Allgemeinen in zwei Gruppen unterschieden werden: - Datenbanken, die vor und neben dem Internet entstanden sind, haben ein logisches Datenmodell (hierarchisch bzw. netzwerk-, relational- oder objektorientiert) - Datenbanken, die für und mit dem Internet entstanden sind, haben kein logisches Datenmodell als Grundlage (z.B. Information Retrieval Systeme) Information Retrieval Systeme ermöglichen die Speicherung und Wiedergewinnung von Informationen in Online-Datenbanken. Dabei sind folgende Hauptunterschiede beim Zugriff auf relationale Datenbankmanagementsysteme (DBMS) und Information Retrieval Systeme zu betrachten: -5- Tabelle 1: Hauptunterschiede beim Zugriff relationaler DBMS und Information Retrieval Systeme Speichern Wiederauffinden Relationale DBMS Formatierte Datensätze Attributwerte als Ganzes zur Indexierung benutzt Nutzung Auswerten, Ändern, Löschen, Eingeben Information Retrieval System Unformatierte Datensätze Werte eines längeren textlichen Feldes zur Indexierung benutzt, wortweise Indexierung, Invertierung, Volltextinvertierung, Deskriptorinvertierung Eingeben, Auswerten, (kaum Änderungen) Bei der Kopplung von Internet und Datenbank-Technologien können DatenbankBetriebssysteme einerseits zur Verwaltung der Webseiten eingesetzt werden, andererseits zur Verwaltung der traditionellen Daten, die über das Web zugänglich gemacht werden. [I_WLOKA1] Im Rahmen dieser Diplomarbeit kommen Web-Anwendungen mit Zugriff auf eine traditionelle Datenbank zum Einsatz. Daher wird nicht weiter auf die Verwaltung von Webseiten mittels Datenbanken, wie zum Beispiel bei einem webbasierten Content Management System, eingegangen. Gemeinsamkeiten des WWW und der Datenbanknutzung sind unter anderem: - das Abspeichern von Daten und der Zugriff über Server - es existieren geregelte Zugriffspfade zu diesen Daten - das Abspeicherung erfolgt auf verschiedene Knoten im Netzwerk - Suche ist nach gewissen Kriterien möglich 2.3 Vor- und Nachteile webbasierter Datenbanken Das Internet ist heutzutage das Netzwerk der Informationen, auf das man an jedem Ort der Welt relativ schnell zugreifen kann. Um Zugang zu bekommen, braucht man nur einen Computer oder technisches Gerät, welches am Internet angeschlossen ist, und zur Darstellung von Webseiten einen webfähigen Browser. Dies hat sehr viele Vor- und -6- Nachteile, die nachfolgend, in Bezug auf Datenbanken mit Zugriff aus dem Web, kurz beleuchtet werden. Vorteile Durch neueste client- und serverseitige Technologien ist es kein Problem mehr, unabhängig vom Aufenthaltsort Netzwerke, Datenbank- und andere Computersysteme zu steuern und zu administrieren. Das heißt, durch diese dezentrale Administration wird man flexibler und kann auf Veränderungen und Ausfälle viel schneller reagieren. Die weite Verbreitung des Internets und der technische Fortschritt erschufen eine Menge von Technologien, um Daten im Internet zur Verfügung zu stellen. HTML und weitere weltweite Standards bzw. Richtlinien für die Kommunikation zwischen Server und Clients ermöglichen den Einsatz von Webseiten relativ unabhängig von bestimmter Server-Hardware oder proprietärer Software. Durch diese Standards und durch zusätzliche Sprachpakete für Browser wird der Datenaustausch international, also relativ unabhängig auch von einer Landessprache. Ein weiterer Grund, webbasierte Technologien für die Bereitstellung von Daten zu nutzen, ist die Kontrolle über die Zugriffe von Nutzern sowie über Sichten auf öffentliche und nicht öffentliche Daten. Dies beinhaltet auch den Schutz geistigen Eigentums, der beispielsweise bei einer Verbreitung von Daten auf CDs nicht gewährleistet werden kann, da der Nutzer die Daten und teilweise auch die Datenstruktur auf einem Medium besitzt. Diese könnte er dann am Rechner vervielfältigen, verändern und ggf. auch verbreiten, bis hin zum Reverse-Engineering. Die Bestimmung über Zugriffe sowie die Kontrolle der Nutzer und insbesondere des Verbreitungsgrades sind somit auch ein großer Vorteil bei der Bereitstellung der Daten im Internet. Außerdem kann, im Gegensatz zum langwierigen Versand von Daten auf CDs oder anderen Medien, eine Webseite mit Anbindung an eine Datenbank auf einem zentralen Server viel schneller aktualisiert, angepasst und der Öffentlichkeit zur Verfügung gestellt werden. -7- Neben der Verwaltung traditioneller Daten, die über das Netz verfügbar gemacht werden, können Datenbanksysteme auch für die Verwaltung von Webseiten selbst genutzt werden. Webbasierte Content Management Systeme nutzen beispielsweise diese Technologie, wobei meist Layout und Daten getrennt abgespeichert werden, um eine größere Flexibilität zu erhalten. Wichtig für die Optimierung und Anpassung einer Webseite ist die Möglichkeit der statistischen Erhebungen über Zugriffsfrequenzen, Fehleingaben und eventuelle Systemausfälle. Auch kann ein schnelleres direkteres Feedback des Endnutzers bezüglich der Zufriedenheit und Benutzerfreundlichkeit der Seite eingeholt und über die Datenbank ausgewertet werden. Nachteile Nutzt man einen zentralen Server für die Verarbeitung von Anfragen, muss dieser auch permanent verfügbar sein. Ein Ausfall von Web- oder Datenbankserver hat eine hohe Hebelwirkung und bedeutet, dass global kein Nutzer mehr Zugang zu den Daten hat. Um die Robustheit und ständige Verfügbarkeit der Daten zu realisieren, benötigt man, je nach Zugriffsfrequenz der Seite und Datenbank, leistungsstarke Hardware und Backup-Systeme. Sehr wichtige Server und Rechensysteme, wie die der Banken und Börsen beispielsweise, befinden sich meist in bewachten und klimatisierten Gebäuden oder Rechenzentren. Hierbei entstehen zum Teil enorme zusätzliche Kosten und Aufwendungen. Ein weiterer Nachteil von webbasierten Datenbanken besteht darin, dass die ständige Kontrolle und Übersicht über die Daten gewährleistet sein muss. Durch schlechte Datenstrukturen und durch die weite Verbreitung im Netz kann es bei der Informationsflut schnell passieren, dass eine Firma den Überblick über ihre Daten verliert. Alte, nicht mehr verwendete Daten befinden sich zum Teil auf verschiedensten Servern im Internet und sind nur sehr schwer zu überschauen oder zu korrigieren. -8- Durch die weltweite Erreichbarkeit der Server und der Technologien entsteht weiterhin die Gefahr von ungewollten Fremdzugriffen durch Sicherheitslücken. Dies wird umfassender im Kapitel 3 erläutert. 2.4 Technologien und Zugriffsmethoden für webbasierte Datenbanken In diesem Abschnitt werden einige bedeutende webbasierte Sprachen und Technologien vorgestellt, die der Darstellung von Daten dienen und Methoden des Zugriffs auf Datenbanken im Internet bereitstellen. Dabei wird zwischen clientseitigen, serverseitigen und übergreifenden Techniken unterschieden. Die Basistechnologien für den Zugriff auf Datenbanken über das WWW werden jeweils kurz erläutert. Auf Technologien und Sprachen, die sich nicht konkret für den Zugriff auf Datenbanken in Betracht kommen, wie zum Beispiel HTML, wird dabei nicht näher eingegangen. Clientseitige Techniken JavaScript JavaScript ist eine objektbasierte Skriptsprache mit Elementen aus den funktionalen Programmiersprachen und wird überwiegend clientseitig eingesetzt. Trotz der Namensähnlichkeit hat JavaScript nur geringe Gemeinsamkeiten mit der Programmiersprache Java. Mit clientseitigem JavaScript können dynamisch Inhalte generiert werden, die zum Beispiel das Erscheinungsbild einer Seite bei Nutzerinteraktion ändern. Voraussetzung ist die Unterstützung des Webbrowsers und ein kompatibler JavaScript-Interpreter, der den im HTML eingebetteten Code ausführt. JavaScript selbst kann jedoch keine Verbindung mit einem Server aufnehmen und bietet daher keine Möglichkeit, auf dem Server liegende Dateien oder Datenbanken auszulesen. [B_SPONA1] -9- Java-Applets Im Gegensatz zu JavaScript sind Java-Applets Computerprogramme, die in der Programmiersprache Java geschrieben wurden. Diese werden meist von HTML-Seiten aufgerufen, heruntergeladen und ausgeführt. Voraussetzung dazu ist eine Java-VM (Virtual Machine), über die der jeweilige Webbrowser verfügen muss. Diese VM kann entweder Teil des entsprechenden Browsers sein oder in Form eines Plugins (zusätzlicher Softwarekomponente) nachträglich installiert werden. Mit Java-Applets lassen sich bereits komplexe Anwendungen erstellen, die auf diese Weise auf die Installation lokaler Software verzichten und ohne großen Aufwand mit unterschiedlichen Browsern und Betriebssystemen laufen können. Mit Java Applets kann bereits über eine JDBC-API eine Verbindung vom Client direkt mit einer Datenbank aufgenommen werden. Dies bedeutet zwar eine aufwendigere Programmierung der Benutzerschnittstelle und bedarf einer längeren Ladezeit des Applets, jedoch wird gleichzeitig der Webserver von intensiven Datenbankabfragen entlastet. Durch die Java-Schnittstelle (JDBC) ist ebenfalls eine höhere Portabilität gewährleistet. [B_SPONA1] Flash „Adobe Flash“ ist eine proprietäre integrierte Entwicklungsumgebung zur Erstellung multimedialer Inhalte, so genannter „Flash-Filme“. Die dabei entstehenden Dateien liegen im SWF-Format vor, einem auf Vektorgrafik basierenden Grafik- und Animationsformat. Um diese Flash-Dateien im Browser zu betrachten, ist ein proprietäres Abspielprogramm (Flash-Player) oder Plugin erforderlich. Durch den hohen Verbreitungsgrad und wegen der vielfältigen Möglichkeiten, besonders im Animationsbereich, bietet sich diese Technologie zur professionellen Darstellung und Präsentation an. Ein Datenbankzugriff mit Flash wird meist über andere Skriptsprachen, wie PHP, realisiert, da der Aufruf von Flash-Animationen oftmals sowieso aus diesen Skripts heraus durchgeführt wird. [I_ADOBE1] -10- Serverseitige Techniken CGI (Common Gateway Interface) Das Common Gateway Interface ist eine so genannte allgemeine Schnittstelle und Standard für den Datenaustausch zwischen einem Webserver und dritter Software, die Anfragen bearbeitet. Ein Webserver, der CGI unterstützt, stellt der externen Software eine Laufzeitumgebung zur Verfügung, die im Grunde aus der Bereitstellung von Einund Ausgabekanälen (stdin und stdout) und Umgebungsvariablen besteht. Diese helfen dem Programm, sich über die Anfrage, Webserver-Einstellungen und -Situation zu informieren. Datenbankabfragen lassen sich über Skriptsprachen wie Perl im Zusammenhang mit CGI realisieren. [B_LOESE1] Perl Perl ist eine freie, plattformunabhängige Programmiersprache, deren Code durch einen Interpreter auf dem Server übersetzt wird. Perl-Skripte werden nicht innerhalb von HTML-Dateien gespeichert, sondern in separaten Dateien, die in einem CGI-BINVerzeichnis innerhalb der Webpräsenz liegen müssen. Eine Webseite, die mit einem Perl-Skript generiert wird, muss auch komplett mit dem Skript erstellt werden. Es ist nicht möglich, nur einzelne Teile der Seite durch ein Perl-Skript generieren zu lassen, jedoch können in der Perl-Datei HTML-Teile definiert werden. Der Pfad des PerlInterpreters wird im Skript angegeben, was die Portabilität auf andere Webserver erschwert. Die datenbankunabhängige Schnittstelle DBI bietet in Perl einen guten Zugriff auf alle gängigen Datenbanken. [B_SPONA1] JSP (Java-Server-Pages) Es handelt sich bei JSP um eine serverseitige Technik, die auf dem Server Java-Code ausführt und zur dynamischen Erzeugung von HTML oder XML dient. Java-ServerPages werden unter Verwendung eines speziellen JSP-Compilers in Java-Quellcode, welcher einem Java-Servlet entspricht, umgewandelt. Die mit dem Java-Compiler erzeugten Klassen werden von einem Webserver ausgeführt beziehungsweise interpretiert. Damit das funktioniert, muss neben dem Webserver auch ein ApplicationServer installiert sein. Application-Server sind für den privaten Einsatz oft kostenlos, jedoch für den kommerziellen Einsatz verursachen sie nicht gerade geringe Kosten. Aus -11- diesem Grund gibt es kaum Webspace-Provider, die JSP unterstützen. Durch viele Programme zur visuellen Gestaltung von JSP-Seiten (zum Beispiel „Adobe Dreamweaver“ und „Adobe GoLive“) wird diese Technologie trotzdem auf vielen zumeist firmeneigenen Webservern, die unabhängig von Webspace-Providern sind, eingesetzt. Wie bei allen in Java über die J2EE-Plattform entwickelten Programmen kann auch hier über die JDBC-Schnittstelle problemlos auf alle bekannteren Datenbanksysteme zugegriffen werden. [B_SPONA1] ASP.NET (Active Server Pages .NET) Dies ist eine serverseitige Technologie von Microsoft zum Erstellen von WebAnwendungen auf der Basis des Microsoft .NET-Frameworks. Hierbei ist es möglich, in einer, von .NET unterstützter, beliebiger Sprache Anwendungen für das Web zu schreiben. Inbegriffen sind zum Beispiel die Sprachen C#, VB.NET, J#, Delphi.NET und viele mehr. ASP.NET ist keine Programmiersprache, sondern eine Technologie. Somit kann jede ASP.NET-Webseite in allen .Net Sprachen programmiert werden, wobei alle Programme in den so genannten CLR-Code übersetzt werden. Die CLR (Common Language Runtime) ist eine virtuelle Maschine und stellt somit die Laufzeitumgebung für alle unterstützen Sprachen dar. Ein Teil der .NET-Plattform ist ADO.NET (ActiveX Data Objects .NET). Es handelt sich um eine Sammlung von Klassen, um den Datenbankzugriff zu gewährleisten. [B_SPONA1] ColdFusion ColdFusion ist eine proprietäre Technologie (Adobe, zuvor Macromedia) zur Erstellung von Web-Applikationen, die grundlegend aus der ColdFusion Markup Language, dem ColdFusion Application-Server und einer geeigneten Entwicklungsumgebung besteht. Die CFML (ColdFusion Markup Language) ist eine Skriptsprache, die es ermöglicht, serverseitige Anwendungen zu programmieren. Sie besteht aus einer Sammlung von Tags (Steuerzeichen) und Funktionen, die die Entwicklung von Web-Anwendungen stark vereinfachen. Im Gegensatz zu Skriptsprachen wie PHP und Perl, die Open Source sind, ist ColdFusion nicht im Quellcode verfügbar. Über gängige Schnittstellen wie z.B. ODBC oder OLEDB lassen sich Datenbankzugriffe auf Datenbanken problemlos bewerkstelligen. [B_SPONA1] -12- PHP PHP (PHP: Hypertext Preprocessor) ist eine in HTML eingebettete Skriptsprache für die dynamische Erzeugung von Webseiten oder Web-Anwendungen, deren Syntax an C bzw. C++ angelehnt ist. Der Quelletext wird von einem Interpreter auf dem Server übersetzt und die Ausgabe an den Browser gesendet. In den meisten Fällen ist dies HTML, wobei es auch möglich ist, andere Dateitypen, wie z.B. Bilder oder PDFDateien, zu generieren. PHP zeichnet sich besonders durch die leichte Erlernbarkeit, die breite Datenbankanbindung und Internet-Protokolleinbindung aus. Es existieren zahlreiche zusätzliche Funktions- und Programmbibliotheken, um beispielsweise Bilder und Grafiken zur Einbindung in Webseiten dynamisch zu generieren. Durch die große Verbreitung von PHP (beispielsweise in webbasierten Datenbank-Anwendungen, Content Management Systemen und Software für das Erstellen von Webblogs), aufgrund des großen Funktionsumfangs und der riesigen Community bietet sich diese Open Source Software für kleine bis große Projekte an. PHP eignet sich ebenfalls besonders gut für Datenbankzugriffe, da bereits eine große Bibliothek mit Klassen für alle gängigen Datenbanksysteme besteht und leicht in die PHP-Skripts eingebunden und verwendet werden kann. [B_SPONA1][B_WIGAR1] Datenbankserver mit Webserver-Funktionalität Um den Datentransport zu minimieren und somit die Leistungsfähigkeit zu erhöhen, sind Web Server physisch oft am selben Ort wie das Datenbankmanagementsystem. Dann kann der Webserver allerdings auch gleich in das DBMS verlegt werden. Dies hätte den Vorteil, dass der Verbindungsauf- und -abbau direkt im DBMS erfolgt. Folgende Abbildung zeigt einen in das DBMS integrierten CGI-basierten Datenbankanschluss. [B_LOCKE1] -13- Abbildung 2: Darstellung einer in das DBMS integrierten CGI-basierten Datenbankanbindung Übergreifende Techniken XML (eXtensible Markup Language) Diese erweiterbare Auszeichnungssprache dient zur Darstellung hierarchisch strukturierter Daten in Form von Textdateien und wird vorrangig für den Austausch von Daten zwischen IT-Systemen im Internet eingesetzt. Anders als HTML definiert die vom World Wide Web Consortium (W3C) herausgegebene XML-Spezifikation eine Metasprache, mit deren Hilfe man andere Auszeichnungssprachen (Markup-Sprachen) definieren kann. Die Regeln für erlaubte Elemente, Attribute und Verschachtelungsmöglichkeiten einer XML-gerechten Auszeichnungssprache werden unabhängig von den eigentlichen Daten in einer so genannten Documenttype-Definition (DTD) definiert. Ein DTD ist jedoch nicht unbedingt erforderlich. „Wohlgeformte“ XML-Dokumente halten sich an die allgemeinen Regeln und „gültige“ folgen zusätzlich noch der zum Dokument gehörenden DTD. In Bezug auf Datenbanksysteme mit Nutzung des XML-Formats unterscheidet man zwischen datenorientierter und dokumentorientierter Vorgehensweise. „Herkömmliche Datenbanksysteme“ (z.B. relationale Datenbanksysteme), die eine Abbildung (Mapping) auf oder ins XML- -14- Format erlauben (XML-enabled), werden als „datenorientiert bezeichnet“. Und „native XML-Datenbanksysteme“, die XML-Dokumente direkt im Dateisystem speichern, gehen „dokumentorientiert“ vor. Aufgrund der Standardisierung und der weiten Verbreitung von XML wird diese Technik häufig für Datenaustausch und Integration verwendet. [B_LOESE1] -15- 3. Sicherheit und Gefahren bei Web-Anwendungen im Internet 3.1 Informationssicherheit und Schutzziele Private Unternehmen sowie öffentliche Einrichtungen sind heute in allen Bereichen ihrer Geschäftstätigkeit auf IT-Systeme und auf die weltweite Vernetzung angewiesen. Durch die Erreichbarkeit von Computersystemen beziehungsweise Web-Anwendungen im Internet und durch den damit verbundenen Informationsaustausch von Daten entstehen auch Gefahren und Bedrohungen. Insbesondere trifft dies auf wirtschaftliche Unternehmen und auf wissenschaftliche Lehr- und Forschungseinrichtungen zu, da hier neben der Abhängigkeit auch die Risiken für IT-Systeme größer sind als im privaten Bereich. Aus diesen Gründen wird die „Informationssicherheit“ überwiegend in Unternehmen betrieben. Im internationalen und deutschsprachigen Raum kommt die Verpflichtung durch verschiedene Gesetze, zum Beispiel zum Gesellschaftsrecht, Haftungsrecht, Datenschutz und Bankenrecht, hinzu. Die Informationssicherheit dient dem Schutz vor Gefahren beziehungsweise Bedrohungen sowie der Vermeidung von Schäden und der Minimierung von Risiken. Als Informationssicherheit bezeichnet man die Eigenschaften von IT-Systemen, die mit dem Ziel geschaffen wurden, die Verarbeitung, Speicherung und Kommunikation so zu gestalten, dass die Vertraulichkeit, Verfügbarkeit und Integrität in ausreichendem Maße sichergestellt wird. Neben diesen drei international anerkannten Sachzielen gibt es noch viele weitere Ziele, wie z.B. Authentizität, Nachweisbarkeit und Verbindlichkeit, die oft im Umfeld des E-Commerce eine wichtige Rolle spielen. Nachfolgend werden die drei wichtigsten Sachziele genauer beschrieben. Vertraulichkeit bedeutet, dass gespeicherte Daten vor unbefugter Weitergabe geschützt werden müssen. Einen Verlust der Vertraulichkeit, d.h. die Weitergabe vertraulicher Daten an Dritte, kann man nicht direkt erkennen und auch nicht rückgängig machen. -16- Mit geeigneten Maßnahmen kann ein Verlust der Vertraulichkeit jedoch verhindert werden. Von Verfügbarkeit spricht man, wenn das IT-System zum gewünschten Zeitpunkt mit den erforderlichen Funktionen und Daten zur Verfügung steht. Ob ein System verfügbar ist, kann man leicht erkennen. Und ein nicht verfügbares System ist bei geeigneter Vorbereitung relativ schnell wiederherzustellen. Allerdings kann man eine Beeinträchtigung nie mit vollständiger Sicherheit verhindern. [I_EILER1] Die Integrität ist gewährleistet, wenn die Daten vollständig und unverändert sind. Sie lässt sich mit geeigneten Maßnahmen beweisen. Bei einer Veränderung der Daten lassen sich diese bei einer ausreichenden Vorbereitung wiederherstellen. Man unterscheidet zwischen semantischer Integrität, Ablaufintegrität und physischer Integrität. [I_WLOKA2] Ein erstes wichtiges Ziel des DBMS ist also, die Konsistenz der Daten als solches nach den festgelegten Integritätsbedingungen zu gewährleisten. Zusätzlich sind Nutzer bzw. Programme im Mehrnutzerbetrieb, bei dem gleichzeitig zugreifende Nutzer mit den selben Daten arbeiten, zu synchronisieren. Für die Sicherung der physischen Integrität ist das Wiederherstellen von Daten und Informationen bei Verlust durch Software- oder Hardwarefehler unbedingt sicherzustellen. Verursacht werden solche Verluste und die Zerstörung physischer Bedingungen oft durch Fehler im Betriebssystem, Hauptspeicherfehler, Plattencrashs aber auch durch Stromausfälle, Brände und Wasserschäden. Ein weiteres Ziel ist der Schutz geistigen Eigentums. Durch die Vernetzung des Internets und die Möglichkeit des weltweiten Zugriffes auf verschiedenste Daten kann man sehr schnell an wichtige und brauchbare Informationen gelangen. Oft stecken jedoch hinter diesen Daten Erkenntnisse und Informationen langer, arbeits- und kostenaufwendiger Forschungen, die dann einfach durch dritte Personen im Internet kopiert und für den eigenen Vorteil genutzt werden. Hier ist es natürlich im Interesse -17- der Entwickler und Schöpfer, ihr geistiges Eigentum, auch im Sinne von Urheberrechten und Lizenzen, vor ungewollten Kopieren und Einsichten zu schützen. 3.2 Schwachpunkte und Angriffsszenarien Bedrohungen der Datensicherheit können aus verschiedenen Richtungen kommen. Sie ergeben sich im Wesentlichen aus Angriffen aus dem Netz, aus fehlerhaften und sorglosen Verhaltensweisen seitens des Personals oder zugangsberechtigter Personen und aus Einflüssen höherer Gewalt. Angriffe aus dem Netz oder Internet haben vielerlei Hintergründe. Es geht für den Angreifer meist darum, für ihn wertvolle Daten auszuspionieren oder Daten und ITSysteme zu zerstören. Auch erpresserische Zwecke (von finanziellen Gewinnen bis hin zur Durchsetzung politischer Interessen) sind immer wieder anzutreffen. Vertrauliche Daten können auf vielen Wegen an Unbefugte gelangen. Ein Angreifer kann eine Schwachstelle nutzen, um von außen in das lokale Netz beziehungsweise in den lokalen Computer einzudringen und die Daten zu kopieren. Oder es kann zum Beispiel ein Trojaner per E-Mail eingeschleust werden, der eine Hintertür öffnet oder die vertraulichen Daten direkt an den Angreifer zurückschickt. Auch von innen ist die Vertraulichkeit gefährdet, wenn zum Beispiel Mitarbeiter unbefugt Daten absichtlich oder unabsichtlich weitergeben. Mögliche Angriffe gegen die Verfügbarkeit sind zum Beispiel auch infizierende, sich vermehrende Computerprogramme, Computerviren, Würmer oder Trojaner, welche die Funktion der Software beeinträchtigen, oder Denial-of-Service-Angriffe auf die Netzwerkverbindung. Auch Angriffe auf die Hardware wie Brandstiftung oder Störungen der Stromversorgung sind möglich. -18- Datenintegritäten können an mehreren Stellen verletzt werden. Auf dem lokalen ITSystem können die gespeicherten Daten direkt verändert oder die zur Verarbeitung verwendeten Anwendungen entsprechend manipuliert werden. Genauso ist eine Veränderung der Daten während der Übertragung zwischen verschiedenen IT-Systemen möglich. Phishing, Cross Site Scripting und SQL-Injection sind einige der meist verbreiteten Gefahren für Fremdzugriffe und Datenklau. Diese werden im Folgenden genauer erläutert. Phishing Ein schwer zu verhindernder Fremdzugriff ist der Zugriff durch Personen, die an ein Passwort für den Zugang durch andere Methoden gelangt sind. Einer dieser Methoden ist beispielsweise das „Phishing“, sinnbildlich „Das Angeln nach Passwörtern mit Ködern“. Diese Personen (Phisher) geben sich meist als vertrauenswürdige Personen aus und versuchen, durch gefälschte elektronische Nachrichten oder Webseiten an sensible Daten wie Benutzernamen und Passwörter zu gelangen. [B_HUSEB1] [Z_RÜTTG1] Cross Site Scripting Die verbreitetste Angriffsform ist das so genannte Cross Site Scripting, abgekürzt CSS oder XSS, bei dem ein Angreifer versucht, die Web-Anwendung so zu manipulieren, dass sie schädlichen Skriptcode (z.B. JavaScript-Code) in die beim Besucher angezeigte Seite einbettet. Der Browser verarbeitet dann den eingeschleusten Code als wäre es ein legitimer Inhalt der Webseite. Ein Angreifer kann dann mit dem eingebetteten Code beispielsweise „falsche“ Informationen als Inhalte der Webseite verkaufen, um Passwörter oder Kontodaten zu erbeuten (Phishing). Es gibt mehrere Haupttypen von XSS, je nach dem, auf welchem Weg der Schadcode in den Browser gelangt. Das am häufigsten anzutreffende Cross Site Scripting ist das so genannte reflektierte XSS. Beim reflektierten XSS muss der Angreifer das Opfer dazu bringen, eine präparierte URL anzuklicken (dieser Link kann z.B. über eine Seite oder per E-Mail an das Opfer gelangen). In Variablenparametern dieser URL versteckt er dabei Codes, welche die -19- fehlerhafte Anwendung auf der Serverseite übernimmt und als vermeintlichen Benutzernamen, E-Mail-Adresse oder Suchausdruck in die dynamisch erzeugte Webseite einbettet. Da der eingebettete Code (z.B. JavaScript-Code) für den Browser des Opfers anscheinend von einer vertrauenswürdigen Webseite stammt, wird er nicht als schädlich bzw. unerwünscht erkannt, sondern ausgeführt. [B_HUSEB1] [Z_RÜTTG1] SQL-Injection Dieser Begriff bezeichnet das Ausnutzen einer Sicherheitslücke bei SQL-Datenbanken, welche aus mangelnder Überprüfung von Metazeichen in Benutzereingaben auf Eingabemasken hervorgeht. Ein großer Teil von Web-Anwendungen arbeitet heutzutage mit einer SQL-Datenbank. Ein Angreifer versucht daher, über die Web-Anwendung eigene Datenbankbefehle einzuschleusen, mit dem Ziel, Daten in seinem Sinne zu verändern oder sogar die Kontrolle über den Server zu erlangen. [B_HUSEB1] [Z_RÜTTG1] 3.3 Schutzmaßnahmen und –techniken 3.3.1 Verhindern von Fremdzugriffen und –übernahmen Es gibt keine Software, die vollkommene Sicherheit vor jeder Art von Angriffen bietet. Daher kann man nur versuchen, mit gegebenen technischen Mitteln und Techniken bekannte und vermeintliche Sicherheitslücken zu schließen. Im Allgemeinen sollten die Maßnahmen zur Verhinderung von Fremdzugriffen und Angriffen im Rahmen der Erstellung eines Sicherheitskonzeptes an den Wert der zu schützenden Daten angepasst werden. Aufwendiger Schutz verursacht hohe Kosten und Akzeptanzprobleme, ein zu geringer Aufwand wiederum führt zu Sicherheitslücken. Zur Bewertung und Zertifizierung der Sicherheit von IT-Systemen existieren internationale Normen und Standards, wie zum Beispiel die amerikanischen TCSEC und -20- die europäischen ITSEC, welche im neueren internationalen Standard Common Criteria vereinigt wurden. [I_COMMO1] Informationsschutz- und Sicherheitsrichtlinien sind in Unternehmen oder Einrichtungen Aufgaben des Managements. Dabei beginnen Maßnahmen gegen die Verletzung von Sicherheitsrichtlinien und Fremdzugriffen in erster Linie schon mit der Ansprache und Sensibilisierung der eigenen Mitarbeiter hinsichtlich möglicher Verstöße gegen die Firmenrichtlinien. Aber auch einfache operative Maßnahmen, wie SoftwareAktualisierungen, Einrichten von Firewalls, Setzen von Passwörtern, Nutzer- und Rechteverwaltung und das Protokollieren von Aktionen in Protokoll-Dateien, schließen mögliche Sicherheitslücken und tragen zum Schutz vor unerwünschtem Zugriff bei. Im Folgenden wird auf einige allgemeine und typische Schutzmaßnahmen bei der Entwicklung webbasierter Anwendungen, Web- und Datenbankservern mit Bezug auf die in Punkt 3.2 aufgezeigten Schwachpunkte und Angriffszenarien eingegangen. Passwörter Um Datenbanken und die darin enthaltenen Informationen vor ungewollten Zugriffen durch Fremde zu sichern, hilft schon ein einfacher Passwortschutz. Nicht-triviale Passwörter herauszufinden oder zu knacken, erfordert sehr viel Fachkenntnis und zum Teil spezielle Programme, die den meisten Computeranwendern nicht zugänglich sind. Deshalb sind Passwörter bei Datenbanken heutzutage bereits bei der Installation oder Einrichtung zwangsläufig mit dem Anlegen des ersten Benutzers zu setzen. Sie stellen eine erste sichere Methode zum Schutz vor Fremdzugriffen dar. Firewalls Eine Firewall dient dazu den Datenverkehr zwischen Netzwerksegmenten mit verschiedenen Vertrauensstufen abzusichern. Sie schützt nicht nur vor unerwünschten Zugriffen auf einen Computer oder auf ein Netzwerk, sondern auch vor unbeabsichtigten Zugriffen vom eigenen Rechner nach außen, die von systemeigenen Anwendungen oder Prozessen ausgehen und oft gar nicht bemerkt werden. Deshalb ist die Installation einer Netzwerk- oder Personal-Firewall unerlässlich. -21- Antivirenprogramme Ebenso unerlässlich ist der Schutz vor Viren und Trojanern, die beispielsweise versuchen, unbemerkt sensible Daten von einem IT-System zu versenden oder durch Zerstörung von Daten erheblichen Schaden anzurichten. Viren oder Trojaner können sehr leicht über das Internet mittels E-Mail oder Kopieren von Daten aus Datenträgern in ein System gelangen. Deshalb ist ein entsprechendes Antivirenprogramm zu installieren und regelmäßig zu aktualisieren. Benutzereingaben Schnittstellen für Benutzereingaben bergen wahrscheinlich die größten Risiken für die Sicherheit einer Web-Anwendung in sich. Bei der Entwicklung von Webseiten oder anderen softwaretechnischen Benutzerschnittstellen mit Anbindung an eine Datenbank sind daher jegliche Eingaben von Nutzern auf Gültigkeit zu prüfen. Hierbei sind alle eingegebenen Daten zu filtern, und es ist festzustellen, ob ein Eingabeparameter gemäß den von einer Anwendung festgesetzten Regeln (zum Beispiel Sonderzeichen, Datentyp, Zeichenlänge, usw.) gültig ist. Dabei gibt es für die Filterung der eingegebenen Daten allgemein zwei Herangehensweisen: Whitelisting und Blacklisting. Beim Blacklisting werden alle bekannten unerwünschten Daten, von denen eine Gefahr angenommen wird, in einer Liste festgehalten und alle anderen Eingaben sind erlaubt. Beim Whitelisting werden alle erlaubten Daten, die für „harmlos“ gehalten werden, in einer Liste aufgenommen und alle anderen Eingaben sind verboten. Das Whitelisting ist der bevorzugte Ansatz im Sicherheitskontext, da er nur Eingaben und Daten zulässt, die der Anwendung bekannt sind. [B_HUSEB1] Ausgabebehandlung Die Behandlung der Ausgaben einer Web-Anwendung auf dem Browser ist ebenso eine wichtige Maßnahme zum Schutz vor Angriffen. Wie im Abschnitt 3.2 erläutert, kann mittels Cross Site Scripting schadhafter Code auf der Seite des Anwenders ausgeführt werden. Auf Seiten des Anwenders (Clients) kann man sich schon mit dem Abschalten von JavaScript im Browser ganz gut gegen XSS-Angriffe schützen. Jedoch bieten einige Browser noch andere Schwachstellen und Angriffsvektoren, weshalb es auch schon softwaretechnische Erweiterungen gibt, mit denen man gezielt mögliche XSS- -22- Angriffe erkennt und verhindern kann. Um eine Web-Anwendung serverseitig vor einem Angriff zu schützen, müssen alle eingehenden Parameterwerte und Eingaben als unsicher betrachtet werden und am besten anhand einer Whitelist vor einer weiteren Verarbeitung geprüft werden. Bei HTML-Ausgaben sollte man zum Beispiel Metazeichen durch entsprechende Zeichenreferenzen entwerten, damit sie als normale Zeichen und nicht mehr als Metazeichen behandelt werden. [B_HUSEB1] 3.3.2 Verschlüsselungsstrategien Das Verschlüsseln von Daten hat eine lange Tradition. Mit der elektronischen Datenverarbeitung und dem Internet erlangt es jedoch eine neue Qualität und Bedeutung. Daten zu verschlüsseln, ergibt sich aus der Notwendigkeit, sie bei der Übertragung in lokalen Netzwerken oder im Internet zu schützen aber auch, um Passwörter oder ähnlich geheime Daten auf der Datenbank selbst nicht lesbar abzuspeichern. Daten können mittels verschiedenster Methoden verschlüsselt werden. Dabei werden immer ein klar lesbarer Text (Klartext) oder auch Informationen anderer Art, wie Ton- oder Bildaufzeichnungen, mit Hilfe eines Verschlüsselungsverfahrens in einen unlesbaren (kryptischen) Text umgewandelt. [B_HUSEB1] Für die Datenübertragung im Internet wird sehr häufig das „Secure Socket Layer“ (SSL) Verschlüsselungs-Protokoll eingesetzt, welches heutzutage von jedem gängigen Webserver unterstützt wird. Mit SSL kann man jedes höhere Protokoll auf Basis des SSL-Protokolls implementieren, da es oberhalb der Transportschicht im „OSI-Modell“ und unter Anwendungsprotokollen wie „http“ und „smtp“ angesiedelt ist. Damit ist eine Unabhängigkeit von Anwendungen und Systemen gewährleistet. [B_STEIN1] [I_ELEKT1] Für die Übertragung und für das Abspeichern von Daten werden im Allgemeinen unterschiedliche Methoden angewandt. PGP ist eine Verschlüsselungstechnik, die für die Übertragung von Daten in einem Netzwerk benutzt wird. MD5 und SHA-1 sind -23- hingegen zwei Methoden, die Daten und Klartext für das Abspeichern in der Datenbank verschlüsseln. Diese 3 Beispiele werden im Folgenden genauer dargestellt: - PGP Pretty Good Privacy (PGP) ist ein von Phil Zimmermann entwickeltes Programm zur Verschlüsselung von Daten. Es benutzt ein so genanntes „PublicKey“-Verfahren, d.h. es gibt ein eindeutig zugeordnetes Schlüsselpaar. Bei diesem asymmetrischen Verfahren verwenden der Sender und Empfänger zwei unterschiedliche Schlüssel. Jeder besitzt einen öffentlichen Schlüssel, mit dem die zu versendenden Daten für den Empfänger verschlüsselt werden können, und einen geheimen privaten Schlüssel zu Entschlüsselung der Daten, den nur der Empfänger besitzt und der durch ein Kennwort geschützt ist. [I_DATEN1] - MD5 und SHA-1 MD5 (Message-Digest-Algorithm 5) und SHA (secure hash algorithm) bezeichnen kryptographische Hash-Funktionen mit einer Einweg- Verschlüsselung. Das heißt, dass eine beliebig große Zeichenfolge auf eine bestimmte Zielmenge abgebildet wird. Aus der Zielmenge, auch Hash- oder Prüfsumme genannt, soll sich die ursprüngliche Zeichenfolge nicht zurückrechnen lassen. Es soll also unmöglich sein, zwei verschiedene Informationen mit dem gleichen Wert zu finden. Dies wird auch als Kollisionsfreiheit bezeichnet. MD5 ist eine Funktion die einen 128-Bit-Hash-Wert erzeugt. Diese aus einem Text errechneten MD5-Summen werden zum Beispiel zur Integritätsprüfung von Dateien, unter anderem auch von PGP, eingesetzt. SHA-1 erzeugt einen Hash-Wert mit 160 Bit Länge für beliebige digitale Daten. Mit dem längeren Hash-Wert ist SHA etwas widerstandsfähiger als MD5. Für SHA gibt es inzwischen auch zahlreiche Erweiterungen wie SHA- 256, -384 oder -512. [B_STEIN1] [I_JAKL1] -24- Beide Versschlüsselungsverfahren MD5 und SHA-1 sind jedoch nach neuesten Erkenntnissen nicht hundertprozentig sicher und können mit gewissem Aufwand entschlüsselt werden. -25- 4. Administration von Datenbanken im Web In diesem Kapitel geht es um die grundlegenden Aufgaben der DatenbankAdministration, die sich auch auf Datenbanken im Web beziehen lassen. 4.1 Grundlegende Konzepte der Datenbank-Administration Ein Datenbank-Administrator (DBA) ist für die Verwaltung eines Datenbankmanagementsystems verantwortlich und beherrscht Datenbanksprachen und diverse Datenbank-Tools. Dabei ist der Begriff des Datenbank-Administrators eher als Rolle zu verstehen und muss keine einzelne Person verkörpern. Die Aufgaben können auch auf mehrere Administratoren verteilt sein. Nachfolgend werden zunächst die grundlegenden Aufgaben des DatenbankAdministrators aufgezählt. Wichtige Punkte, besonders mit Bezug auf Datenbanken im Web, werden in den folgenden Kapiteln genauer erläutert. Zu den Hauptaufgaben eines DBA zählen: Einrichten und Konfigurieren von Hard- und Software Hier spielt die Architektur des Datenbankmodells und der Datenbank eine wichtige Rolle. Wie viele Rechner mit welcher Kapazität (Laufwerke, Hauptspeicher, usw.) werden benötigt, auf welcher Plattform soll das DBMS mit wie vielen DatenbankServern (Instanzen) laufen, sind nur einige Fragen bei der Konfiguration und Einrichtung des Datenbankmanagementsystems. Administration des Datenbankmodells Das Datenbankmodell stellt die Grundlage für eine Datenbank dar und bestimmt wie die Daten auf der Datenbank gespeichert werden. Dies ist maßgebend für die Qualität der Datenbank, bedeutend für den logischen Aufbau der Daten sowie für die Datenbank- -26- Performance. Eine Optimierung und Anpassung des Modells ist ein ständiger Prozess und für ein effektives Arbeiten mit der Datenbank notwendig. Planung und Verwaltung von Tablespaces Ein Tablespace ist eine physische Datenstruktur, ein Speicherort, an dem die Datenbankobjekte, wie zum Beispiel Tabellen und Indizes, abgelegt werden. Eine Datenbank besteht in der Regel aus mehreren Tablespaces. Für jedes Objekt ist beim Anlegen zu entscheiden, in welchem Tablespace es liegen soll. Diese logische Konfiguration einer Datenbank und die Auswahl des richtigen Tablespace-Layouts sind entscheidend für die spätere Performance und die anfallenden Verwaltungsaufgaben. [B_LONEY1] Überwachung des Speicherplatzes Neben der Überwachung der Performance, Transaktionen und der Sicherheitsprüfungen müssen auch ständig alle kritischen Faktoren beobachtet werden, die für den effektiven Betrieb der Datenbank verantwortlich sind. Hierbei spielt die Überwachung des Speicherplatzes eine nicht unwesentliche Rolle, um die Verfügbarkeit und effektive Verwaltung einer Datenbank zu gewährleisten. Aufgabe der Administration ist es also, permanente Probleme beim Speicherplatz zu vermeiden. [B_LONEY1] Verwaltung von Transaktionen Um die ACID-Eigenschaften (Atomarität, Konsistenz, Isolation, Dauerhaftigkeit) in einem Transaktionssystem bei Transaktionen zu garantieren, müssen diese verwaltet werden. Hierbei spielen zum Beispiel die Administration von Rollback-Segmenten und Undo-Methoden eine große Rolle. Transaktionsfehler und Maßnahmen sind genauer im folgenden Kapitel 4.3 (Datensicherung) beschrieben. [B_LONEY1] Tuning und Abfrageoptimierung Das Tuning von Datenbankanwendungen setzt zunächst die Planung, Implementierung und Überwachung voraus und steht am Ende dieses vierstufigen Prozesses. Gerade bei Datenbanken im Web jedoch kann dieses Performance-Tuning noch bedeutungsvoller -27- sein. Im Kapitel 4.4 wird deswegen darauf genauer eingegangen und verschiedene Aktivitäten in diesem Bereich beschrieben. [B_LONEY1] Überwachung der Datensicherheit Eine der wichtigsten Aufgaben ist die Überwachung der Datensicherheit. Dabei spielt der Schutz von nicht autorisierten Zugriffen eine große Rolle. Diese Zugriffsversuche gilt es zu erkennen und zu verhindern. Das Auditing oder Protokollieren hilft dabei, alle Aktionen, die auf der Datenbank oder auf einem IT-System allgemein ausgeführt wurden, zu überblicken, auszuwerten und ggf. Maßnahmen zu ergreifen. Mehr dazu im Kapitel 4.5 (Auditing und Protokollierung). Datensicherung Um den Verlust von Daten zu verhindern, ist es unbedingt notwendig, eine Datensicherung der Datenbank anzulegen und diese bei Auftreten eines Fehlers möglichst verlustfrei wiederherzustellen. Hierfür stehen dem Administrator verschiedenste Möglichkeiten und Funktionen der Datenbank zur Verfügung. Im Kapitel 4.3 wird hierzu näher eingegangen. Sicherung der operationalen Integrität Greifen mehrere Nutzer auf ein und dieselben Daten auf der Datenbank zu, kann es zu Fehlern im Datenbestand kommen, obwohl jeder Nutzer für sich fehlerfrei arbeitet. Die Synchronisation dieser Nutzer bzw. Transaktionen ist Aufgabe des Datenbankmanagementsystems. Der Administrator muss auf diese Situation mit angepassten Verfahren, zum Beispiel verschiedene Sperrverfahren, reagieren. Gerade bei der Nutzung einer Datenbank mit einer hohen Zugriffsrate ist diese Verletzung der Ablaufintegrität wahrscheinlich und sollte unbedingt behandelt werden. Nutzer- und Rechteverwaltung Eine weitere Aufgabe des Datenbank-Administrators ist das Einrichten und die Vergabe von Rechten auf Nutzergruppen. Im folgenden Kapitel 4.2 ist diese wichtige Einteilung von Gruppen und Rechten im Sinne der Zugriffskontrolle expliziter erläutert. -28- Verbessern des Fehlermanagements Durch eine Verbesserung in der Erkennung und Beseitigung von Fehlerquellen sowie durch schnelle und geeignete Reaktionen auf Fehler, kann die Qualität und Sicherheit des Systems erhöht werden. Kapitel 4.6 beschäftigt sich ausführlicher mit diesem Thema. 4.2 Rechte- und Nutzerverwaltung Auf einer Datenbank liegen meist viele verschiedene Daten: Daten für die Systemverwaltung, Userdaten, geheime Daten, Nutzdaten, usw. Aus Gründen der Daten- und Informationssicherheit (siehe Kapitel 3.1) und zum Schutz der Datenintegrität ist es notwendig, verschiedenen Nutzern der Datenbank verschiedene Rechte für den Zugriff auf Daten zu vergeben. Die Aufgabe des Administrators bei der Rechte- und Nutzerverwaltung besteht darin, ein Konzept für die Einteilung und Einrichtung von Nutzer, Rollen, Profilen sowie zur Verwaltung von Rechten für den Zugriff auf Datenbanken, Tabellen, Spalten oder sogar nur einzelner Informationen zu entwickeln. In der Regel werden bei größeren Datenbanken drei große Nutzergruppen oder -rollen in Betracht gezogen. Der „Administrator“ - besitzt alle Rechte und den Vollzugriff auf das gesamte Datenbanksystem samt Infrastruktur. Er ist für die Planung, Überwachung und Steuerung aller Komponenten zuständig und setzt damit die Voraussetzung für die Nutzung des Systems auf operativer Ebene. Der „dbo“ („database owner“ - Dateneigner) - besitzt meist Rechte und Vollzugriff auf eine spezielle Datenbank. Auf einem Datenbanksystem können durchaus mehrere Datenbankeigner angelegt sein. -29- Der „User“ - arbeitet ausschließlich auf der operativen Ebene und besitzt ausgewählte Rechte meist auf Tabellen einer Datenbank. Er wird allerdings in der Praxis noch in weitere Untergruppen mit verschiedenen Zugriffsrechten aufgegliedert. [B_HEINR1] 4.3 Datensicherung Eine wichtige Aufgabe von Datenbankmanagementsystemen und deren Administration liegt in der Gewährleistung einer weitgehenden Datensicherung. Trotz Auftretens von Fehlern verschiedener Art ist die Konsistenz der Datenbank automatisch zu wahren und Datenverlust zu verhindern. Die Fehlerbehandlung ist meist Aufgabe der „Recovery“Komponente des DBMS, welche neben den eigentlichen Datenbankinhalten redundante Informationen benötigt und durch „Logging“ zu protokollieren sind. Angelehnt an „Datenbanksysteme“ von Härder und Rahm [B_HÄRDE1] werden im Folgenden zunächst die zu behandelnden Fehlerarten eines Datenbanksystems betrachtet und die sich daraus ableitenden Recovery-Arten beschrieben. Transaktionsfehler Transaktionsfehler sind die mit Abstand häufigste Fehlerart, bei der meist eine Transaktion oder einige wenige Transaktionen betroffen sind. Beispiele für das Auftreten solcher Fehler sind unter anderem: - Rollback-Anweisung bei freiwilligem Transaktionsabbruch (z.B. aufgrund unzulässiger Dateneingabe oder nicht erfolgreicher Datenbank-Operationen) - Fehler im Transaktionsprogramm (z.B. Adressierungsfehler oder Division durch Null) - Abbruch einer Transaktion vom System (z.B. aufgrund Verletzungen von Integritätsbedingungen oder Zugriffsbeschränkungen) - Systemseitiger Abbruch von einer oder mehreren Transaktionen zur Auflösung von Verklemmungen, zur Behandlung von Systemüberlastungen (z.B. Sperroder Speicherengpässen) oder aufgrund einer geplanten Systemschließung usw. -30- Aufgrund der Atomarität, daher, dass eine Transaktion entweder ganz oder gar nicht ausgeführt wird, verlangt die Behandlung solcher Fehler das isolierte Zurücksetzen der betroffenen Transaktion im laufenden Betrieb. Es handelt sich um das „UndoRecovery“, welches durch die relative Häufigkeit von auftretenden Transaktionsfehlern einer schnellen Ausführung bedarf. Systemfehler Ein Systemfehler liegt vor, wenn der weitere Betrieb des DBS nicht mehr möglich ist. Dies kann durch Fehler der Hardware (z.B. Rechnerausfall) oder Software (z.B. Absturz des Datenbank- oder Betriebssystems) sowie durch Umgebungsfehler (z.B. Stromausfall) verursacht sein. Alle Änderungen und Inhalte, die zum Zeitpunkt des Absturzes im Hauptspeicher vorlagen, gehen verloren und müssen ggf. rekonstruiert werden. Die Behandlung von Systemfehlern erfolgt durch das so genannte „Crash-Recovery“, welches zum Ziel hat, den jüngsten transaktionskonsistenten Datenbankzustand herzustellen. Hierzu sind - im Rahmen einer „Undo-Recovery“ Änderungen von nicht erfolgreich zu Ende gekommenen Transaktionen, welche vor dem Fehler in die Datenbank gelangten, zurückzusetzen sowie - durch eine „Redo-Recovery“ für erfolgreich beendete Transaktionen deren Änderungen zu wiederholen, falls sie aufgrund des Systemfehlers noch nicht in die Datenbank gelangten. Die Durchführung dieser Recovery-Aktionen erfolgt mit der permanenten Datenbank sowie der temporären Log-Datei. Geräte- bzw. Externspeicherfehler Hiermit ist vor allem der Ausfall von Magnetplatten (z.B. durch einen „Head Crash“) gemeint. Bei der Behandlung solcher Fehler kommt in erster Linie das „RedoRecovery“ zum Wiederherstellen der durch den Ausfall verloren gegangenen Änderungen zum Einsatz. Grundlage für die Rekonstruktion sind regelmäßig angelegte -31- Archivkopien der Datenbank (Backups), welche zunächst eingespielt werden, um den Grunddatenbestand wiederherzustellen. Danach werden zusätzlich alle Änderungen erfolgreicher Transaktionen, die nach der Erstellung des Backups gemacht wurden, mit dem Archiv-Log ergänzt. Bei höherer Gewalt oder Katastrophen, bei denen beispielsweise gleich ein ganzes Rechenzentrum samt Verarbeitungsrechner und Externspeicher betroffen ist, kann ein Datenverlust nur über einen verteilten Systemansatz verhindert werden. Dazu müssten die Daten an zwei oder mehr geographisch weit entfernten Knoten repliziert gespeichert werden. 4.4 Tuning und Abfrageoptimierung Bei Datenbanken in Netzwerken und besonders Datenbanken, die vom Internet aus erreichbar und somit einer hohen Abfragefrequenz ausgesetzt sind, entsteht schnell der Bedarf von Performance-Tuning. Dabei ist das Tuning in erster Linie nicht nur das Aufrüsten der Hardware, sondern eher das Optimieren des Anwendungs- und Tabellendesigns, der Fehlerbehandlung sowie der SQL-Abfragen. Tabellendesign Die Qualität der Datenbank ist äußerst wichtig für die Performance und setzt ein sauberes effektives Design der Tabellen voraus. Auch das volle relationale Tabellendesign (dritte Normalform) ist gerade bei großen und langen Abfragen nicht immer die optimale Lösung. Hier sollten die Entwickler beim Design der Tabellen sogar eine Denormalisierung der Daten in Betracht ziehen, zum Beispiel mit dem Anlegen kleiner zusammenfassender Tabellen aus großen statischen Tabellen. CPU-Belastung Begrenzte CPU-Ressourcen können ebenfalls mit gezielten Maßnahmen optimiert werden. Die Belastung der CPU(s) sollte sorgfältig geplant werden. Update-Programme -32- oder große Batch-Abfragen sollten beispielsweise nicht in der Hauptkernzeit laufen. Lässt man diese Prozesse zum richtigen Zeitpunkt laufen, minimiert man Konflikte bei der CPU oder bei eventuell entstehenden Sperren und Rollbacks. Eine weitere Option wäre die Verteilung der Abfragen und Datenbankzugriffe auf mehrere Instanzen (daher Datenbank-Server), wenn es die gegebene Technologie zulässt. SQL-Tuning Neben dem Anwendungsdesign ist das Tuning von SQL-Abfragen ganz entscheidend für die Performance einer guten Anwendung mit Datenbankzugriff. Dabei ist die Minimierung des Suchpfades, den die Datenbank zum Auffinden der Daten einsetzt, das eigentliche Ziel beim SQL-Tuning. Für die schnellere Suche nach Abfrage eines SQLStatements werden auf der Datenbank auch Indizes eingesetzt. Diese bilden die logischen Werte in einer Tabelle ab und verweisen auf eine oder mehrere Spalten. Eine von der Datenstruktur getrennte Indexstruktur sorgt für die rasche Sortierung und Suche von Feldern. Dies ist vor allem für die Nutzung bei Datenbanken im Web mit vielen Nutzerzugriffen von Bedeutung. Speicher-Tuning Einen weiteren Gewinn an Performance der Datenbank erhält man mit der Optimierung beim Speichern von Daten. Wie die Daten auf der Datenbank eigentlich gespeichert sind, hat vor allem bei Abfragen einen Einfluss. Sind die Daten fragmentiert gespeichert, d.h. beispielsweise auf mehreren physischen Standorten, kann ein Einfügen oder Suchen von Datensätze schon sehr viel länger dauern und die Performance reduzieren. Also sollten Daten und Segmente defragmentiert und ähnliche Objekte zusammen gespeichert werden. Speicher-Tuning beinhaltet auch das Tuning des physischen Speichers. Hierbei spielt das physische Layout der Datenbank eine wichtige Rolle für die Verteilung der Daten auf die Laufwerke. Dabei muss die physische Ein- und Ausgabe der Datenbanken gleichmäßig verteilt und korrekt bedient werden. Ein Implementieren einer RAIDTechnologie (z.B. RAID 0+1) bringt allgemein eine sehr gute Performance. -33- Replikation Die mehrfache Speicherung der Daten an verschiedenen Orten (Replikation) hat gleich mehrere Vorteile. Durch Kopieren und Verteilen der Daten verringert sich die Belastung des Netzwerkes. Eine potenzielle Quelle für Performance-Probleme kann somit gleich umgangen werden. Weiterhin werden die Antwortzeiten, gerade bei lesendem Zugriff, verkürzt. Ein weiterer Vorteil der Replikation ist die gleichzeitige Datensicherung, die das Kopieren der Daten mit sich bringt. [B_LONEY1] 4.5 Auditing und Protokollierung Um bestimmte Aktionen von Prozessen und Abläufen auf einem System zurückzuverfolgen, wird in den meisten Fällen eine Protokolldatei (oder auch Log-Datei genannt) angelegt. Auditing bezeichnet hier das Überwachen von ausgeführten Aktionen auf einer Datenbank. Der Grund für die Überwachung kann sehr vielfältig sein. Ein Protokoll ermöglicht in erster Linie, Vorgänge zu rekonstruieren, um Fehler oder Fehlfunktionen im System zu analysieren oder zu vermeiden. Protokolle dienen aber auch der Kontrolle der Abläufe bzw. Operationen und Entitäten, entweder im Voraus, gegenwärtig oder im Nachhinein. Daher werden an die Protokollierung im Sinne einer beweisfesten und revisionssicheren Aufzeichnung hohe Anforderungen im Bezug auf Relevanz, Gültigkeit und Zuverlässigkeit, Fälschungssicherheit (Integrität), Authentizität und Vertraulichkeit gestellt. Datenbankensysteme können in der Regel auch alle ausgeführten Aktionen überwachen. Dies beinhaltet meistens Anmeldeversuche, Objektzugriffe und Datenbankaktionen. Die Audit-Datensätze werden entweder im Datenbanksystem gespeichert oder ins Prüfprotokoll des Betriebssystems geschrieben. Die Speicherung in ein Prüfprotokoll auf Systemebene hängt jedoch vom jeweiligen Betriebssystem ab. [B_LONEY1] -34- Log- und Protokolldateien werden also oft schon von verschiedensten Servern automatisch erstellt. Sie können aber auch zusätzlich angelegt werden und bei der Untersuchung der Benutzerfreundlichkeit von Programmen oder des allgemeinen Nutzerverhaltens in einem System angewandt werden. Dazu helfen statistische Erhebungen und Histogramme über Herkunft, Verhaltensweisen, Zugriffsfrequenz der Nutzer, die bei der Auswertung von Protokollen für die Optimierung der Seite erstellt und analysiert werden können. Hierbei kann beispielsweise festgestellt werden, ob der Nutzer mit der Seitenführung und Navigation klarkommt, oder ob er in Sackgassen geraten ist. Ferner können Nutzerzugriffe, erzeugte Fehler und weitere Ergebnisse erkannt und ggf. darauf reagiert werden. 4.6 Fehlermanagement Einer der wichtigsten Tätigkeiten bei der Administration jeglicher IT-Systeme ist das Fehlermanagement. In ihm werden alle möglichen auftretenden Fehler und Reaktionsmöglichkeiten festgehalten, um einen Fehler zu beheben oder zunächst seine Auswirkungen zu begrenzen. Das Auftreten von Fehlern in einem Mensch-Maschine-System kann verschiedene Ursachen haben. Potentielle Fehler können unter anderem sein: - Fehler bei der Eingabe des Nutzers (Evaluierung von Eingabefeldern) - Fehler in der Anwendung (Softwarefehler z.B. Laufzeitfehler) - Fehler in der Hardware (z.B. Systemausfall, Serverausfall, Katastrophen) - Fehler im Netzwerk (z.B. durch Ausfall des Netzes oder zu hohe Netzlast) - Fehler im Betriebssystem (auch Absturz des DBMS oder andere Komponenten) - Begrenzte Rechte (z.B. Zugriffsrechte, keine Schreib- oder Leserechte) Ein gutes Fehlermanagement sollte mehrere Ziele anstreben. Bei „leichten“ Fehlern sollte die Anwendung dem Nutzer hilfreiche und verständliche Hinweise geben. Bei ernsthaften Fehlern sollte der Entwickler oder Administrator möglichst automatisch -35- über die Fehler und ggf. über die Zusammenhänge und Ursachen, die den Fehler ausgelöst haben, informiert werden. [B_LOESE1] Hierzu stehen verschiedene Vorgehensweisen zur Verfügung. Zum einen können Meldungen, Warnungen und Fehlerbeschreibungen in eine Protokolldatei (Log-Datei) geschrieben werden, die regelmäßig von den zuständigen Personen zu überwachen ist. Eine weitere Möglichkeit besteht in der automatischen Mitteilung an den Administrator per E-Mail oder anderer Alarmierungsdienste durch die Softwareanwendung selbst oder durch benutzerdefinierte Funktionen im Datenbanksystem. Sieht man von kompletten Systemabstürzen ab, sollte dies in den meisten Fehlersituationen möglich sein. -36- 5. ISDA: Ausgangssituation und Ist-Analyse 5.1 Das Verbundprojekt ISDA zur Verwaltung chemischer Stoffdaten ISDA („Integriertes Sorptions-Datenbankensystem für Wechselwirkungen chemischtoxischer und radioaktiver Kontaminanten mit mineralischen Systemen.“) bezeichnet ein Projekt, welches zwei bereits bestehende Datenbanken im Bereich der Deponierung von chemisch-toxischen und radioaktiven Stoffen zu einem gemeinsamen Datenbanksystem zusammenführt. Bei jeglichen Entsorgungseinrichtungen von gefährlichen Abfällen, sei es untertägig oder in oberirdischen Deponien, ist die Gewährleistung der Sicherheit von entscheidender Bedeutung. Insbesondere ist die Ausbreitung der toxischen Abfallbestandteile in die Biosphäre zu vermeiden. Hierbei ist sowohl die Aufnahme von Schadstoffen über Boden und Grundwasser durch Pflanzen und Tiere, und damit in die menschliche Nahrungskette, als auch eine direkte Aufnahme durch den Menschen über Trinkwasser oder Schwebteilchen in der Luft (Aerosole) zu beachten. Für das Ausbreitungsverhalten von Schadstoffen in der Umwelt gibt es verschiedenen Modelle, welche in so genannten Langzeitsicherheitsprognosen für Schadstoffdeponien eingesetzt werden. Solche Modelle benötigen natürlich eine entsprechende Parametrisierung. Für den wichtigen Teilaspekt der Sorption, d.h. der chemischen Wechselwirkung von im Wasser gelösten Schadstoffen und dem umgebenden Gesteinsmaterial, wurden mit Förderung des Bundesministeriums für Bildung und Forschung (BMBF) und des Bundesministeriums für Wirtschaft (BMWi) in den vergangenen Jahren zwei Datenbanken entwickelt. Dies ist zum einen die Sorptions-Datenbank SODA [Z_BREND1], welche von der Gesellschaft für Anlagen- und Reaktorsicherheit (GRS), Braunschweig, in Zusammenarbeit mit der Dr. Veerhoff und Scherschel GbR, Bonn, erstellt wurde. Der Schwerpunkt lag dabei auf dem Rückhalteverhalten von nicht radioaktiven, überwiegend anorganischen Schadstoffen (z. B. Schwermetalle) im tiefen Untergrund. Das zu Grunde liegende Modell ist rein empirischer Natur. Bei der zweiten -37- Datenbank handelt es sich um die beim Forschungszentrum Dresden-Rossendorf (FZD) entwickelte Sorptions-Datenbank RES³T (Rossendorf Expert System for Surface and Sorption Thermodynamics) [Z_BRASS1]. Hier werden im Wesentlichen Daten zu radioaktiven berücksichtigt Schadstoffen abgelegt. chemische Reaktionen Der an zu Grunde liegende Gesteinsoberflächen Modellansatz und wird als mechanistisches Modell bezeichnet. Beide Datenbanken sind im Hinblick auf die Modellkonzepte und die stoffliche Basis zueinander komplementär und ergänzen sich somit. ISDA basiert auf diesen beiden bereits abgeschlossenen Vorhaben SODA und RES3T, soll diese integrieren und einem weiten Nutzerbereich zugängig machen. Partner im Verbundprojekt ISDA sind die GRS mbH, Fachbereich Endlagersicherheitsforschung, Braunschweig; das Forschungszentrum Dresden-Rossendorf e.V. (FZD), Institut für Radiochemie; die Deutsche Montan Technologie GmbH, Safe Ground Division, Essen sowie die Dr. Veerhoff und Scherschel GbR, Bonn. 5.2 Ziele und Nutzen von ISDA Die beiden bereits existierenden Datenbanken SODA und RES3T sind durch folgende gemeinsamen Eigenschaften charakterisiert: • Reine Access-Datenbanken, Einzelarbeitsplatz-orientiert • Mechanistische und empirische Modelle der Sorption werden separat behandelt • Starre Tabellen/Felder-Struktur o Wenig flexibel o Anpassung nur über Strukturänderung SODA und RES3T unterscheiden sich stark in ihren Nutzerschnittstellen, sowohl in der Herangehensweise als auch das Layout betreffend. -38- Im Vordergrund des laufenden Vorhabens ISDA steht deshalb die Zusammenführung und Weiterentwicklung der bestehenden Sorptions-Datenbanken zu einem webverfügbaren Datenbank-Tool mit vereinheitlichter Nutzerschnittstelle. In der neuen integrierten Datenbank sollen neben „reinen“ Datensätzen auch eine Vielzahl von recherchierten Publikationen mit teilweise ausführlichen Bewertungen zur Datenerhebung, Versuchsdurchführung etc. abgelegt werden. Ziel ist, über eine komfortable Abfrage der Datenbankinhalte den Nutzer zu einer qualifizierten Datenrecherche und einer kritischen Datenbeurteilung zu befähigen (KnowledgebaseSystem). Durch die Verknüpfung der unterschiedlichen Modellkonzepte und Datenbasen soll ein einheitliches und einfaches Zugreifen auf das akkumulierte Wissen für externe Nutzer ermöglicht werden. Eine Zusammenführung der bisher existenten Datenbanken SODA und RES³T ist zudem Voraussetzung für eine kritische Sichtung und Bewertung der gegenwärtig zugänglichen Sorptionsdaten. Ziel ist es letztlich, Qualitätskriterien für Sorptionsdaten festlegen zu können, die vorhandenen Daten entsprechend zu klassifizieren und Datenlücken zu identifizieren, die durch experimentelle Arbeiten geschlossen werden müssen. Darüber hinaus wird die Datenbasis dahingehend umgeformt und implementiert, dass sie langfristig und kosteneffektiv gesichert, gepflegt und aktualisiert werden kann. Als Nutzerschnittstelle wurde im Verbundprojekt ein Thin Client vorgesehen, basierend auf HTML-Seiten zur Anzeige in einem Browser. Dies bedeutet, dass viele Funktionen, die dem Anwender zum Bedienen der Datenbank zur Verfügung gestellt werden, auf den Server verlagert werden. Auf dem Client werden die Ergebnisse der vom Server durchgeführten Arbeitschritte in Form von Webseiten angezeigt. Hierfür müssen sämtliche Funktionen der bisherigen Access-Oberflächen umgesetzt werden in die Funktionskombination aus Datenbankserver, Skriptinterpreter und dem dynamischen Zusammenbau der letztlich an den Client übermittelten HTML-Webseiten. Letzteres geschieht durch Skripte und/oder ein Content Management System, welches aus -39- Datenbankinhalten und Formatvorlagen HTML-Seiten generiert. Die Vorteile eines solchen webbasierten Frontends sind dabei folgendermaßen zusammenzufassen: - Der Zugriff auf die Datenbank wird drastisch vereinfacht, da keine lokalen Installationen der Datenbank bei den Nutzern mehr notwendig sind (inklusive der nötigen Software MS Access). Es reicht ein standardmäßiger WWWBrowser. Der Nutzerkreis und die Zugangsmöglichkeiten werden aufgrund der geringen Anschlussvoraussetzungen damit deutlich erhöht. - Probleme durch unterschiedliche Softwareversionen (z. B. MS Access 97, MS Access 2000 oder MS Access XP) entfallen, ebenso Probleme aufgrund länderspezifischer Installationen. - Eine Internetversion gestattet über geeignete Nutzer-Autorisierungstools zudem den abgestuften Zugriff auf Daten bis hin zu einer Dateneingabe durch entsprechend qualifizierte Externe in der Perspektive. Damit können mittel- bis langfristig die Geschwindigkeit der Dateneingabe und der Umfang der Datenbasis deutlich gesteigert werden. Bei letzterem ist insbesondere der Bereich der von Institutionen oft nur intern oder in “Grauer Literatur” publizierten Daten vorhabensrelevant. - Das Feedback der Nutzer wird direkter, im Umfang größer, einfacher zu loggen und zu interpretieren. - Durch die zentrale Vorhaltung einer einzigen Datenbankversion wird die Wartung der Datenbank deutlich vereinfacht. Ebenso wird die angestrebte Langlebigkeit der Datenbank bezüglich Administration und Datenpflege unterstützt. - Durch Spiegelung der Datenbank auf mehreren Servern wird eine hohe Ausfallsicherheit realisiert. Ein nicht unerwähnt bleibender Nebeneffekt ist die zumindest teilweise Abkopplung von proprietären Programmen durch den Einsatz von Open Source Software. Hier boten sich bei Projektbeantragung konkret der Apache-Webserver, MySQL oder PostgreSQL als Datenbank-Server, sowie PHP, Perl oder Python als Skript-Sprachen und Joomla oder Zope als Content Management System für die Nutzerschnittstelle an. -40- 5.3 Chemisches Modell und technologische Umsetzung Der integrative Aspekt für die Zusammenführung zweier unterschiedlicher Konzepte der Sorption (empirisches und mechanistisches Modell) erforderte bisher und erfordert im Weiteren Arbeiten sowohl am Inhalt als auch an der Struktur. Insbesondere mussten diejenigen Tabellen, welche in beiden Vorgängerdatenbanken (SODA & RES³T) bereits vorhanden waren, also die Schnittmenge darstellten, in ihrer Struktur aneinander angeglichen werden. Die umfangreichsten Arbeiten betrafen dabei die Tabellen zur Definition der Minerale, zur Definition der chemischen Elemente, zur Probencharakteristik und zur Erfassung bibliografischer Angaben. Weitere kleinere Anpassungen betrafen die Definition von Gasen, von experimentellen Methoden zur Lösungszusammensetzung und den Bearbeitungsstatus. Ein wichtiger neuer Aspekt im Design der ISDA-Datenbank ist deren hohe Flexibilität bezüglich erfassbarer Eigenschaften. Diese Flexibilität war eine Forderung der Projektpartner, aus den Erfahrungen mit SODA heraus. Die Realität bei der Dokumentation von experimentell bestimmten Verteilungskoeffizienten ist so, dass die Beschreibung der Proben (Art und Vorbereitung), der experimentellen Details, der Messergebnisse und deren Interpretation sehr heterogen sind. Hier macht sich die bisher fehlende Vorgabe einer eindeutigen Nomenklatur, z.B. durch entsprechende internationale Konventionen und staatliche Vorschriften, u.a. in Form von Normen, bemerkbar. Die dadurch in den Publikationen zu beobachtende Vielfalt an Begriffen und Größen lässt sich nur schwer vorab in der Datenbank abbilden. Daher kam der Wunsch auf, ISDA so flexibel anzulegen, dass der Nutzer selbst neue Eigenschaften quasi während der Erfassung definieren kann. Die daraus resultierende komplexere Datenbankprogrammierung und die aus der Vielfalt sich ergebenden Schwierigkeiten bei nachfolgenden Suchanfragen wurden dabei in Kauf genommen. Die Struktur der ISDA-Datenbank gliedert sich in drei Teile: Der administrative Teil umfasst alle Tabellen, in denen die ISDA-Hauptelemente, Eigenschaften, Optionen sowie deren Zuordnungen untereinander verwaltet werden. Der produktive Teil stellt die eigentliche Datenbank, bestehend aus den Tabellen für die ISDA-Hauptelemente -41- und ihre jeweiligen Definitionen zur Verfügung. Der Literaturteil ist in seiner Struktur dem Produktivteil identisch, wird aber bedingt durch die komplexe Verknüpfung zu den Tabellen des Produktivteils getrennt behandelt. Unter ISDA-Hauptelemente (Objektkategorien) werden verstanden: Origin, Sample, Mineral, Area, Protolysis, SiteData, Reaction, Complex und Experiment, wobei sich alle auf chemische Stoffdaten beziehen. Weitere ISDA-Hauptelemente sind Property, Option, Journal und Publication. Die Tabelle „isdaelement“ erfasst alle Objektkategorien. Am relativ anschaulichen Beispiel der Definition von Mineralen soll dieses theoretische Konzept nachfolgend grafisch dargestellt werden. Abbildung 3: Flexibilität der Eigenschaften im ISDA-Datenbankmodell am Beispiel eines Minerals Bei jeder Hauptkategorie von Datensätzen (Minerale, Oberflächen, Proben, Reaktionsdaten, Bibliographie etc.) ist eine Gliederung in zwei zueinander korrespondierenden Tabellen umgesetzt: eine Tabelle, welche eine Liste aller der jeweiligen Kategorie zugeordneten Objekte (hier: Minerale) enthält, und eine zweite Tabelle, welche alle Eigenschaften für alle diese Objekte verwaltet. Die Namensgebung -42- der Tabellen ist dabei wie folgt: „mineral“ erfasst alle Objekte (also alle Minerale) und „mineral_definition“ verwaltet alle zugehörigen Eigenschaften jedes Minerals (hier u.a. Formel, Dichte, Mineralogische Gruppe, Kristallsystem, Molare Masse). Für den Namensbestandteil „mineral“ ist bei anderen ISDA-Hauptelementen z.B. „area“, „sample“ „reaction“ oder „publication“ zu substituieren. Alle überhaupt möglichen Objekteigenschaften werden in der Tabelle „Property“ verwaltet. Eine Zuordnung, welche dieser Eigenschaften für eine Objektkategorie (z.B. die Minerale) zulässig sind, erfolgt in einer zusätzlichen Tabelle „isdaelement_property“. Das gesamte Datenbankmodell kann auf der beiliegenden CD betrachtet werden. 5.4 ISDA auf dem Datenbanksystem „PostgreSQL“ 5.4.1 Implementierung in Soft- und Hardware, Installation, Hinweise Das integrierte Sorptions-Datenbanksystem ISDA, welches im vorhergehenden Abschnitt bereits ausführlich beschrieben wurde, liegt derzeit teilweise bereits in Form einer PostgreSQL-Datenbank (Version 8.2.3) vor. Die entsprechende Entscheidung war bereits zu Beginn des Verbundprojektes getroffen worden. Ein Großteil der Sorptionsdaten wurde bereits aus den beiden alten Datenbanken in die neue Datenbank überführt. Für erste Abfragen und Reports von Datensätzen steht momentan eine unter ColdFusion MX Version 6.1 entwickelte Weblösung (ISDA-Quick) zur Verfügung. Diese soll im Laufe der Zeit zu einer zentralen Anlaufstation sowohl für die Dateneingabe als auch für die Datenabfrage ausgebaut werden. ISDA-Quick wiederum soll in eine Webseite eingebunden werden, welche weitere Funktionalitäten zur Verfügung stellt, nicht zuletzt die allgemeinen Informationen über ISDA (Ziele und Partner des Projektes, avisierte Nutzer, Nutzungsbedingungen, usw.). Diese Webseite ist somit im Sinne eines zentralen ISDA-Portals aufzufassen. -43- Bei der Weiterentwicklung dieses Portals wird die Administration der Daten und Nutzer sowie die Absicherung durch ungewollte Fremdzugriffe ein wichtiger Bestandteil sein. Dazu sollen das in der Diplomarbeit enthaltene Konzept und der Prototyp zur Administration einer webbasierten chemischen Stoffdatenbank als Grundlage dienen. Momentan wird sowohl für den Betrieb der Webseite als auch für die Kommunikation zwischen Webserver und Datenbank ein „ColdFusion“ - Applikationsserver als Ergänzung in der Middleware (Geschäftslogiksicht) eingesetzt. Im Folgenden wird die Architektur noch einmal bildlich erläutert. Abbildung 4: Gesamtstruktur des ISDA-Datenbanksystems bei Beginn der Diplomarbeit 1. Der Webbrowser des Clients fordert die Seite vom Webserver an. Dabei können Parameter übergeben werden. 2. Eventuell benötigt die angeforderte Seite Datenbankinhalte oder überträgt neue Inhalte an die Datenbank. Die Anfrage wird an den Applikationsserver geschickt, der eine Software beziehungsweise einen Dienst zur Weiterverarbeitung und zum Datenbankzugriff zur Verfügung stellt. 3. Die Abfrageergebnisse oder Statusmeldungen werden von der Datenbank über den Applikations- und Webserver an den Client zurückgegeben. 4. Der Webbrowser stellt die Seite dar. -44- 5.4.2 Funktionsbeschreibung wichtiger ISDA-Tabellen Die in Abschnitt 5.3 erläuterte Struktur der ISDA-Datenbank führte zur in der nachfolgenden Tabelle erfassten Menge an Tabellen. Tabelle 2: Funktion wichtiger ISDA-Tabellen Tabelle PROPERTY ISDAELEMENT ISDAELEMENT_PROPERTY OPTION PROPERTY_OPTION PROPERTY_DEFINITION PROPERTY_PROPERTY OPTION_DEFINITION OPTION_PROPERTY Hauptelement (s.o.) Hauptelement_DEFINTION SAMPLE_MINERAL GENERIC GENERIC_COMPOSITION REACTION_PARTNERS JOURNAL/J.-DEFINITION PUBLICATION/P._DEFINITION 1) Funktion Speicherung der Gesamtheit aller möglichen Eigenschaften. Benennung der ISDA-Elemente. Festlegung, welche Eigenschaft mit welchem ISDA-Element verwendet werden kann. Hier wird festgelegt, ob eine Eigenschaft pro Eintrag in einer der Hauptelemente (Tabellen) mehrfach verwendet werden kann. Speicherung der Gesamtheit aller möglichen Optionswerte (Nachschlagewerte). Festlegung, welche Option für welche Eigenschaft zur Verfügung steht. Ermöglicht, Eigenschaften selbst näher zu definieren. 1) Festlegung, welche Eigenschaft zur Definition welcher Eigenschaft verfügbar ist. Ermöglicht, Optionswerte näher zu definieren. 2) Festlegung, welche Eigenschaft zur Definition welcher Option verfügbar ist. Speichert ID und Literatur-Referenz für Objekte. Die Doppelreferenz erlaubt den Verweis auf Primär- und Sekundärzitat. Zu jedem in einer der Haupttabellen angelegten Objekte werden Eigenschaften zugeordnet. Jede Eigenschaft wird mit einem alphanumerischen oder numerischen Wert belegt oder mit einem Optionswert versehen. Speicherung der Mineralzusammensetzung einer Probe. Hilfstabelle; ermöglicht die Aufnahme von generischen Proben. Vereinfachung für das Einpflegen wiederkehrender, ähnlicher Proben. Mineral-Zusammensetzung der Generika. Verknüpfung zwischen einer Reaktion und den teilhabenden Liganden. Liganden werden als Optionswerte geführt und in einer Pseudotabelle (View) bereitgestellt. Tabellen zur Verwaltung der in PUBLICATION referenzierten Zeitschriften. Tabellen zur Verwaltung der Zitate. Beispiel: Die Eigenschaft „bulk-density“ hat selbst die Eigenschaft „gehört zu“ mit dem Optionswert „physikalische Eigenschaften“ 2) Beispiel: Die Option „Wasserstoff“ (Eigenschaft „Element“) hat die Eigenschaft „Symbol“ mit dem alphanumerischen Wert „H“, die Eigenschaft „AtomicMass“ mit dem numerischen Wert „1,00794“ und die Eigenschaft AtomicNumber mit dem numerischen Wert „1“. Derart komplexe Zusammenhänge werden in Form von Views als Pseudotabellen leichter zugänglich gemacht -45- 5.5 Ist-Analyse von ISDA Um die Anforderungen an das Projekt zu analysieren ist zunächst eine Ist-Analyse des bestehenden ISDA Systems abzuhandeln. Diese bezieht sich auf den Projektstand von ISDA zum Beginn der Diplomarbeit, d.h. nach bereits 2 ½ Jahren Projektlaufzeit. Ist-Analyse Nutzer- und Rechteverwaltung Für die Nutzer- und Rechteverwaltung wird bisher das im Datenbank- managementsystem „PostgreSQL“ vorhandene Gruppenkonzept genutzt. PostgreSQL unterscheidet dabei zwischen Gruppenrollen und Login-Rollen. Eine Login-Rolle berechtigt angelegte Nutzer, sich an der Datenbank einzuloggen. Login-Rollen können Gruppenrollen zugeordnet sein, die wiederum alle Zugriffsrechte beinhalten. Die eigentliche Administration sowie das Anlegen von Nutzern und deren Rechte zum Zugriff auf die Datenbank werden zurzeit zentral durch einen Datenbankadministrator bewerkstelligt. Hierbei wird jedoch nicht unterschieden, ob der Nutzer nur lesend oder auch schreibend Zugriff auf die Daten hat. Nachdem der Datenbankadministrator einen Nutzer angelegt hat, kann dieser sich zunächst auf der provisorischen Projekt-Webseite „ISDA-Quick“ anmelden, Datensätze suchen und auch ändern. Es existieren also keine unterschiedlichen Rollen mit vorher festgelegten gezielten Berechtigungen. Ist-Analyse Zugriffsschutz Der Zugriff auf die ISDA-Datenbank direkt sowie über die ISDA-Quick Seite ist durch ein Passwort gesichert. Die Übertragung von Daten erfolgt unverschlüsselt, und es sind keine weiteren Sicherheitsvorkehrungen für Angriffe von außen (z.B. Script Site Crossing) zu erkennen. Fehlerhafte Eingaben in Eingabefelder werden größtenteils abgefangen, so dass die Gefahr einer SQL-Injection als gering anzusehen ist. Ernsthafte Tests fanden dazu allerdings noch nicht statt. Ist-Analyse Datenintegrität Im Sinne des Transaktionsmanagement wird lediglich die semantische Integrität abgesichert. Die Richtigkeit, Korrektheit und logische Widerspruchsfreiheit wird bei der -46- ISDA-Datenbank durch einige Methoden bereits sichergestellt. Es existieren Eingabeprüfungen, zahlreiche Trigger, Funktionen und Check-Klauseln. Weiterhin wird die referenzielle Integrität durch Fremdschlüssel sichergestellt. Die Synchronisation parallel laufender Prozesse (Ablaufintegrität) wurde nicht realisiert. Rollback und Undo-Methoden sind nicht zusätzlich eingerichtet. Die Absicherung der physischen Integrität ist noch nicht ausreichend gewährleistet. Gegen den totalen Verlust der Daten geschieht ein tägliches Backup durch den zentralen DB-Administrator. Bei Absturz oder Datenverlust werden diese wieder eingespielt. Andere Methoden zur Sicherung der Daten sind nicht erkennbar. Ist-Analyse Protokollierung Das aktuelle System sieht momentan kein separates Log zur Protokollierung anderer Ereignisse in einer extra Tabelle oder Datei vor. Vielmehr wird derzeit in relevanten Tabellen ein Attribut „last_editor“ mitgeführt, der für einen veränderten Datensatz den letzten Editor in der Datenbank festhält. Ein allgemeines Protokoll des Datenbankmanagementsystems listet alle Anmeldungen an das System von Nutzern auf. Ist-Analyse Fehlerbehandlung Eingaben des Nutzers auf dem Frontend (ISDA-Quick) sind teilweise schon durch Wertvorgaben oder Auswahllisten abgefangen. Die Eingabe von Werten in freie Eingabefelder werden geprüft und Sonderzeichen nicht beachtet. Es erscheinen allerdings auch keine Fehlermeldungen oder Hinweise. Datenbankseitig verhindern Fremdschlüssel Eingaben mit Beziehung auf andere Tabellen (referenzielle Integrität). Bei einem Ausfall des Datenbankservers erscheint auf dem Browser eine von „ColdFusion“ generierte Fehlermeldung. Diese ist für normale Anwender nicht zu verstehen. Weitere Informationen über Maßnahmen zur Fehlerbehandlung im Programm selbst lagen zum Zeitpunkt der Analyse nicht vor. -47- 6. Anforderungsanalyse und Konzeption 6.1 Ziel und Nutzen des Administrationssystems Wesentliches Ziel der Diplomarbeit ist die Erstellung eines Prototyps zur visuellen Darstellung und Veranschaulichung der theoretisch erarbeiteten Grundlagen. Der Prototyp soll aus einer webbasierten Lösung zur Administration der bereits für das ISDA-Projekt bestehenden chemischen Stoffdatenbank in PostgreSQL bestehen. Für die Nutzerverwaltung und für den Schutz vor unerlaubten Zugriffen ist hierzu ein zusätzliches Rollenkonzept zu entwickeln, in dem Nutzer und Rechte verwaltet werden können. Dem Benutzer stehen nach erfolgreicher Anmeldung auf der Webseite verschiedene Funktionen zur Verfügung, in Abhängigkeit von seinen zugewiesenen Nutzerrechten. Ein normaler Nutzer kann beispielsweise über einen Filter bestimmte Datensätze suchen und einsehen, während ein Editor darüber hinaus die Möglichkeit hat, Datensätze zu ändern. Administratoren sollen zusätzlich noch in der Lage sein, über diese Seite Nutzer und Rechte anzulegen beziehungsweise zu verwalten. Da es sich bei diesem Projekt um sensible chemische Daten handelt, ist bei der Umsetzung und Entwicklung der Webseite ein besonders großer Wert auf Datensicherheit und Integrität zu legen. Auf Basis dieses Prototyps wird durch das Forschungszentrum Dresden-Rossendorf im weiteren Verlauf ein Tool zur Administration entwickelt und mit allen weiteren Funktionalitäten von ISDA zum Einsatz kommen. Hierbei entsteht auch ein großer Nutzen für das Institut im Hinblick auf die Erweiterung und Weiterentwicklung des ISDA – Systems. -48- 6.2 Funktionale Anforderungen Im Folgenden werden die funktionalen Anforderungen an das Projekt erläutert. Das heißt, alle Funktionen, die der Nutzer ausführen und das Programm später beinhalten soll, werden vorher festgelegt. Dem Nutzer sollen im Programm später folgende allgemeine Funktionen auf der Webseite zur Verfügung stehen: - Neue Nutzer können sich über ein Formular registrieren und bekommen zur Bestätigung eine E-Mail mit Aktivierung zugesandt. - Registrierte und freigeschaltete Nutzer können sich am System über ein Anmeldeformular einloggen. - Nutzer werden in Rollen mit verschiedenen Rechten eingestuft und bekommen nach dem Anmelden am System eine Hauptseite mit angepassten Optionen angezeigt. Der Optionsumfang reicht von Datensätze anzeigen, suchen und editieren bis zu administrativen Aufgaben wie Nutzer- und Rechte verwalten, Protokolldateien auswerten und Backups der Datenbank anlegen. - Nutzer, die Ihr Passwort vergessen haben können dieses mit ihrer E-MailAdresse neu setzen. Die funktionalen Anforderungen an dieses Projekt unterscheiden sich im Weiteren noch einmal zwischen allgemeinen Systemfunktionen sowie der Beschreibung von Datenstruktur und Attributen der Entity-Typen. 6.2.1 Allgemeine Systemfunktionen Die Anforderungen der allgemeinen Systemfunktionen gliedern sich im Weiteren genauer in Verarbeitungsfunktionen - Verarbeitung der Informationen im System, Prüffunktionen - Überprüfung der Eingaben des Nutzers und Dialogfunktionen - Benutzerschnittstellen des Systems. -49- In den nachfolgenden Tabellen werden nur die wichtigsten Funktionen aufgeführt und beschrieben. Dialogfunktionen sind nicht genauer erläutert. Tabelle 3: Funktionale Anforderungen: Verarbeitungsfunktionen Funktion Registrieren Einloggen/ Anmelden Passwort erneuern Verarbeitungsfunktionen Beschreibung Voraussetzung: keine. Der Nutzer wird zu einem Registrierformular weitergeleitet. Nach Eingabe von Name, Vorname, E-Mail-Adresse und Passwort wird der Nutzer in der Datenbank registriert und bekommt eine Bestätigungs-E-Mail mit Aktivierungslink zur Freischaltung seines neuen Benutzerkontos. Dieser Aktivierungslink hat eine zeitlich begrenzte Gültigkeit. Dabei erhält jede Person, die sich auf diesem Wege registriert und freischaltet, zunächst ausschließlich einfache Leserechte. Voraussetzung: Nutzer muss im System registriert und freigeschalten sein. Nach Eingabe von E-Mail-Adresse und Passwort werden durch eine Prüffunktion die Daten in der Datenbank geprüft. Im Erfolgsfall ist die Person eingeloggt und es erfolgt eine Weiterleitung zur dynamisch generierten Hauptseite. Voraussetzung: Nutzer ist im System registriert und freigeschalten Der Link „Passwort vergessen“ fordert in einem Eingabefeld die E-Mail-Adresse des Nutzers ab. Existiert diese E-Mail-Adresse und ist freigeschalten, wird eine Mail an den Nutzer mit einem Aktualisierungslink gesendet. Klickt der Nutzer auf den Link kann er für sein Konto das Passwort neu setzen. Tabelle 4: Funktionale Anforderungen: Prüffunktionen Funktion Passwort_Check Eingabe_Check Timeout_Check Prüffunktionen Beschreibung Prüft bei der Anmeldung E-Mail-Adresse und Passwort, ob der Nutzer existiert und das Passwort korrekt ist. Im Erfolgsfall: Weiterleitung zur dynamisch generierten Such- und Administrations-Seite (abhängig von der Rolle des Nutzers). Bei Misserfolg: Fehlermeldung in Log-Datei und im Browser. Prüft jegliche Eingaben in Eingabefelder auf Gültigkeit und Plausibilität. Sonderzeichen wie z.B. ’, “, %, $, < oder > werden ggf. entwertet. Maximale Länge der Eingabefelder ist abhängig von den Attributwerten der jeweiligen Tabellen (siehe Datenbankmodell und Attributwerte) Prüft auf Aktivität der Webseite. Nach Ablauf einer vorher festgelegten Zeit ohne Aktivität erfolgt eine automatische Abmeldung vom System (in Form eines „Session-Timeout“) zum Schutz vor ungewollter Fremdbenutzung. -50- 6.2.2 Tabellen, Attribute und Datenstruktur Es werden nur jeweils die zur Administration benötigten Tabellen (Entity-Typen) und Attribute zunächst in einem Entity-Relationship-Diagramm und nachfolgend detaillierter in Tabellenform dargestellt. Die Kurzdarstellung aller Tabellen der chemischen Stoffdatenbank für ISDA erfolgte im Abschnitt 5.4.2, eine ausführlichere Variante ist auf der zu dieser Diplomarbeit beiliegenden CD zu finden. Abbildung 5: Entity-Relationship-Diagramm Tabelle „isda_users“ In dieser Tabelle werden alle Nutzer, die sich auf der ISDA-Webseite registrieren, eingetragen. Dabei bekommt jeder Nutzer eine einzigartige Benutzer ID und wird zu einer Rolle aus der Tabelle „isda_user_roles“ zugewiesen. -51- Tabelle 5: Tabelle "isda_users" Attributname user_id user_firstname user_lastname user_E-Mail Datentyp/Länge Integer Varchar(20) Varchar(50) Varchar(50) Schlüssel Primary-Key NULL Not null null Not null Not null user_password Varchar(20) user_role_id Integer user_active Boolean Not null user_reg_date Date Not null Not null Foreign-Key Not null Bemerkung Auto increment Wird für die Anmeldung benötigt. Wird für die Anmeldung benötigt. MD5verschlüsselt. Zuweisung einer Nutzerrolle aus der Tabelle „isda_user_roles“ Zeigt an, ob User aktiv gesetzt ist und einloggen kann. Datum der Registrierung. Tabelle „isda_user_roles“ Hier werden alle Nutzerrollen angelegt. Vorerst „Administrator“, „Editor“ und „Nutzer“. Tabelle 6: Tabelle "isda_user_roles" Attributname role_id role_name Datentyp/Länge Integer Varchar(20) Schlüssel Primary-Key NULL Not null Not null Bemerkung Auto increment Tabelle „isda_user_activate“ Der Aktivierungslink, der mit einer E-Mail an den Nutzer gesendet wird, besteht zur eindeutigen Identifikation und Sicherheit aus der „user_id“ und einem zufällig generierten Code. Diese Tabelle dient dazu, Datensätze für alle diese versendeten EMails, d.h. für alle registrierten nicht freigeschalteten Nutzer, temporär abzuspeichern. Tabelle 7: Tabelle "isda_user_activate" Attributname user_id Datentyp/Länge Integer Schlüssel Foreign-Key NULL Not null activation_code Integer Not null reg_date Date Not null Bemerkung Referenziert auf user_id in Tabelle “isda_users“. Zufällig generierter Code, der dem Nutzer im Aktivierungslink per Mail gesendet wurde. Datum der Registrierung. -52- 6.3 Nicht-Funktionale Anforderungen In den nicht-funktionalen Anforderungen werden alle Eigenschaften festgelegt, die das Programm später erfüllen soll. Hardware-Anforderungen sind für das vorliegende Projekt generell als nichtkritisch anzusehen und bereits durch die Projektpartner im ISDA Projekt vorgegeben. Daher wird im Rahmen dieser Diplomarbeit darauf nicht näher eingegangen. 6.3.1 Allgemeine Anforderungen (Rahmenbedingung) Architektur Die Webseite für die Administration der chemischen Stoffdatenbank ist modular und erweiterbar aufzubauen und wie eine „Hülle“ auf das vorhandene System zu sehen. Dabei erfolgt eine Unterscheidung zwischen der Administration für die ISDA-Webseite und der Administration der Datenbank selbst. Im Rahmen dieser Arbeit wird nur die Entwicklung und Architektur der Administrations-Webseite betrachtet. Eine genauere Übersicht und kurze Beschreibung der Architektur kann in Kapitel 6.5 (Architektur der ISDA-Umsetzung) gefunden werden. Umsetzung Die Umsetzung und Realisierung der Anforderungen erfolgt auf der Frontend- sowie auf der Datenbankebene. Es ist ein System für Nutzer- und Rechteverwaltung als Zwischenschicht vor Applikationsserver und Datenbank zu entwickeln, in der bereits eine Zugriffskontrolle auf die Webseite und Datenbank stattfindet. Die Verarbeitung der Daten sollte dann auf der Datenbankseite mit Hilfe von Datenbank-Funktionen und Triggern erfolgen. Als Skriptsprache für die Umsetzung der Administrations-Webseite wurde PHP von den ISDA-Projektpartnern vorgegeben. Die Datenbank liegt, wie bereits in Kapitel 5.4 -53- erwähnt, auf einem PostgreSQL-System vor und kann für die erweiterte Rollen- und Nutzerverwaltung genutzt werden. Eine genaue Lösungsstrategie und Realisierung soll über die Betrachtung verschiedener Herangehensweisen in Kapitel 7 erörtert und umgesetzt werden. Protokollierung In Hinblick auf die Optimierung der Seite, der Unterstützung von Nutzern und nicht zuletzt der Kontrolle über Zugriffe im Rahmen der Sicherheitsaspekte soll zusätzlich eine Log-Datei zur Protokollierung wichtiger Aktionen angelegt und mitgeführt werden. Dieses Protokoll wird als Datei beim Webserver gespeichert und soll unter anderem folgende Daten festhalten: - Anmelden und Abmelden von Nutzern (E-Mail-Adresse, Anmelde-/ Abmeldezeit) - Zählen von Nutzeranmeldungen - Fehleingaben des Nutzers - Alle Änderungen an der Datenbank (Tabellen, Datensätze, Nutzer) - Jegliche Systemfehler (z.B. Verbindungsabbrüche zur Datenbank) Teilweise können Informationen über Änderungen von Datensätzen auch mittels Spalten in den jeweiligen Tabellen realisiert werden (z.B. über Flags). 6.3.2 Qualitätsanforderung Funktionserfüllung Dem Nutzer steht eine webbasierte Oberfläche mit Anschluss an die chemische Stoffdatenbank zur Verfügung. Abhängig von seinen Rechten kann der Nutzer Datensätze suchen, verändern und löschen. Nutzer in der Rolle eines Administrators können darüber hinaus u.a. Nutzer und Rechte verwalten oder Log-Dateien der Protokollierung einsehen und auswerten. -54- Benutzerfreundlichkeit Die Weboberfläche ist so zu konzipieren, dass sie jeder Nutzer problemlos bedienen kann. Fehlermeldungen sollen leicht verständlich und allgemein gehalten werden. Für Fragen zur Benutzung der Seite soll eine Hilfe zur Verfügung stehen. Sicherheitsanforderungen Die Seite, und die damit angebundene Datenbank, sollen sicher vor Angriffen von außen und möglichen Fremdzugriffen sein. Dabei sind die in Kapitel 3.1 erwähnten Schutzziele zur Sicherstellung der Vertraulichkeit, Verfügbarkeit und besonders die Integrität entsprechend einzuhalten. Die Problematik der Integrität ist für die Verwaltung der chemischen Stoffdatenbank besonders wichtig. Das deshalb, weil die Stoffdaten in der Anwendung für die Auslegung von Deponien, nuklearen Endlagern oder Sanierungsstrategien unmittelbare Auswirkungen auf Menschen haben können. Sie sind daher unbedingt vor Manipulationen so gut es geht zu schützen. Daten und insbesondere deren strukturellen Zusammenhänge sollen im Rahmen des Schutzes geistigen Eigentums auch nicht ohne weiteres für Dritte zugänglich sein. Gegebenenfalls sind Daten für die Übertragung im Netz mit SSL zu verschlüsseln. Zuverlässigkeit Das System fängt Eingabefehler des Benutzers ab und prüft bei Änderungen an Datensätzen Syntax und Plausibilität. Erweiterbarkeit In Hinblick auf die spätere Weiterverarbeitung und Erweiterung des Prototyps sollen die Entwicklung und der Aufbau der Webseite möglichst modular und erweiterbar erfolgen. Auch die Möglichkeit zur Erweiterung und Zuweisung von Rechten auf Gruppen sollte gegeben sein. Datensicherung Datenbackups sowie das Wiederherstellen von Daten erfolgen nicht über die Administration der Webseite. Diese Funktion geschieht direkt auf der Datenbank- -55- Ebene, wenn möglich mittels Logging und Recovery, und wird durch den dafür zuständigen Datenbankadministrator überwacht. 6.4 Fehlerbehandlung Eingabefehler Syntaktische Eingabefehler sollen so weit es möglich ist schon von vornherein ausgeschlossen werden. Das heißt, es sind jeweils nur die für das Eingabefeld zugelassenen Zeichen über die Tastatur einzugeben (Whitelisting). Logische Eingabefehler, wie zum Beispiel ein fehlendes @-Zeichen bei einer E-MailAdresse, sind weitestgehend abzufangen und mit einer leicht verständlichen Fehlermeldung dem Nutzer über den Browser mitzuteilen. Eingabefehler sind zu statistischen Zwecken und im Sinne der Optimierung der Webseite im System mit einem Eintrag in die Log-Datei zu protokollieren. Systemfehler Tritt während der Benutzung der Seite ein Fehler im System auf, sei es durch Absturz der Server oder durch Verbindungsabbruch zur Datenbank, bekommt der Nutzer eine für ihn verständliche Fehlermeldung am Browser angezeigt. Weiterhin wird ein Protokolleintrag in die Protokoll-Datei geschrieben. Bei Fehlern mit gewissen Prioritätsgrad ist der Administrator automatisch per E-Mail zu informieren. Gegebenenfalls können gleich Maßnahmen zur Behebung des Fehlers mit gesendet werden. -56- 6.5 Architektur der ISDA-Umsetzung Abbildung 4 in Kapitel 5.3 zeigte bereits grafisch die Architektur und Arbeitsweise des vorhandenen ISDA-Systems. Aus dieser vorhandenen Architektur heraus und den neuen Anforderungen der Web-Administration ergibt sich demnach folgende neue Architektur. Abbildung 6: neue Architektur des ISDA-Systems 1. Der Webbrowser des Clients fordert die Seite vom Webserver an. Dabei können Parameter übergeben werden. 2. Der Webserver holt die angeforderte Datei von der Festplatte und reicht sie mit Parametern an den PHP-Interpreter weiter. 3. Der PHP Interpreter liest den Programmcode durch Parsing und führt die Befehle aus. 4. Eventuell benötigt die angeforderte Seite Datenbankinhalte oder überträgt neue Inhalte an die Datenbank. Die Anfrage wird an den Applikationsserver -57- geschickt, der eine Software beziehungsweise einen Dienst zur Weiterverarbeitung und Datenbankzugriff zur Verfügung stellt. 5. Die Abfrageergebnisse oder Statusmeldungen werden von der Datenbank über den Applikationsserver an den PHP Interpreter zurückgegeben. 6. Der PHP Interpreter erstellt eine neue, temporäre Datei im HTML-Format, in der eventuelle Datenbankergebnisse als Text enthalten sind, und gibt sie über den Webserver an den Client zurück. 7. Der Webbrowser interpretiert die Datei und stellt die Seite dar. Der ColdFusion Applikationsserver fungiert nunmehr als reiner Anwendungsserver. Die Aufgabe des Webservers wird an einen zusätzlich eingefügten Apache-Server mit PHPPlugin übergeben. Der Grund liegt in der Anforderung von PHP als zu nutzende Skriptsprache für die Web-Administration der Datenbank. Auf ColdFusion kann jedoch nicht gänzlich verzichtet werden, da bereits viele optimierte Funktionen für die Abfrage von Daten auf der Datenbank realisiert wurden und gleich genutzt werden können. Für diese Architektur ergeben sich nun folgende Anforderungen: WWW-Server und Betriebssystem Als Server für die Bereitstellung der Web-Services und der Datenbank wird ein Apache Webserver Version > 2 verwendet, welcher mindestens PHP 4 und XHTML 1.0 sowie das erforderte Datenbankbetriebssystem unterstützt (Diese Konfiguration ist historisch bedingt und Vorgabe des Forschungszentrum Dresden-Rossendorf). Middelware Middelware bezeichnet hier eine weitere Einrichtung einer Applikation zwischen Datenbankserver und Webserver. Vorraussetzung ist Cold Fusion Version MX6.1 oder höher als Applikationsserver. Die Nutzung von ColdFusion wurde durch den Projektpartner Dr. Veerhoff & Scherschel GbR angeregt, da ein ColdFusionAnwendungsserver durch verständliche Syntax und einfachen Code eine schnellere Anwendungsentwicklung ermöglicht. Eine kurze Erläuterung von ColdFusion als webbasierte serverseitige Technik wurde bereits in Kapitel 2.4 beschrieben. -58- Datenbank Als Datenbankbetriebssystem wird eine PostgreSQL-Datenbank in der Version 8.2. oder höher vorausgesetzt. Die entsprechende Maßgabe erfolgte bereits in einem frühen Stadium des Verbundprojektes ISDA. Für diese Entscheidung sprachen folgende Vorteile von PostgreSQL: - Open Source Software - Anwachsende Community, d.h. relativ weite Verbreitung - Unterstützung von Funktionen, Trigger und Check-Bedingungen - Weitgehende Einhaltung des SQL-Standards 92, 99 und 2003 - Relativ gute Administration und Administrations-Tools Clients Da es sich um eine webbasierte Lösung handelt, wird als Software nur ein plattformunabhängiges 32-Bit-Betriebssystem mit webfähigem Browser vorausgesetzt. Der Browser sollte eine grafische Oberfläche haben und mindestens XHTML 1.0 sowie CSS 1 unterstützen. Zusätzlich sollte der Browser für die Sessions Cookies akzeptieren. Gängige Browser wären beispielsweise „Microsoft Internet Explorer“, „Mozilla Firefox“ und „Opera“. 6.6 Konzeption - Use cases Im Folgenden werden Anwendungsfälle definiert, welche die Interaktion zwischen einem Nutzer und dem System darstellen sollen. Dabei wird immer nur ein möglicher Prozess oder Ablauf im System näher beschrieben und bildlich dazu erklärt. Der Funktionsumfang der dynamisch generierten Hauptseite ist hier nur beispielhaft dargestellt und kann beliebig erweitert bzw. angepasst werden. -59- Tabelle 8: Use case 1: Nutzerregistrierung Nutzerregistrierung 1. Ein Nutzer navigiert mit einem Webbrowser auf die ISDA-Seite. Auf der Startseite wird er nach Anklicken des Login-Buttons zur Eingabe von E-Mail-Adresse und Passwort gebeten, um auf die eigentliche Hauptseite mit allen Funktionen zu gelangen. 2. Dieser Nutzer hat noch keine Zugangsdaten und möchte sich registrieren. Dazu klickt er auf den Link zur Registrierung und wird auf eine weitere Seite geleitet, in der spezifische Nutzerdaten abgefragt werden. 3. Nach Eingabe und Bestätigung der allgemeinen Bedingungen (Lizenzbedingungen) bekommt der neue Nutzer eine E-Mail mit Aktivierungslink zur Freischaltung seines neuen Benutzerkontos zugeschickt. 4. Nun kann der registrierte Nutzer seine Zugangsdaten auf der Seite eingeben und gelangt so zu der eigentlichen ISDA-Homepage, auf der er zunächst eingeschränkt lesenden Zugriff auf chemische Stoffdaten besitzt. Durch den dynamischen Hauptseiten-Aufbau werden alle nutzbaren Funktionen und Hyperlinks an die Rechte des Nutzers angepasst. Funktionen anderer „höherer“ Nutzergruppen (mit mehr Rechten und Funktionen) sind nicht sichtbar. Abbildung 7: Ablaufdiagramm eines allgemeinen Anmeldeprozesses (use case 1) -60- Tabelle 9: Use case 2: Funktionen eines Editors Editoren 1. Ein Nutzer in der Rolle eines „Editors“ hat nach erfolgreicher Anmeldung alle Rechte eines normalen lesenden Nutzers und zusätzlich eingeschränkte Lese- und Schreibrechte auf bestimmte Bereiche der ISDA – Homepage. 2. Editoren haben, je nach Konfiguration und Rechtevergabe, die Möglichkeit, Datensätze zu ändern. Hierbei wird jede Änderung mitprotokolliert und kann ggf. rückgängig gemacht werden. Abbildung 8: Ablaufdiagramm mit den Optionen eine "Editors" nach dem Anmeldeprozess (use case 2) -61- Tabelle 10: Use case 3: Funktionen eines Administrators Administration 1. Meldet sich ein Administrator im System an, das heißt ein Nutzer mit Administrationsrechten, hat dieser grundsätzlich alle Rechte, die ein Nutzer und Editor besitzt und darüber hinaus noch die Möglichkeit, die Nutzer und ihre Rechte selbst zu administrieren, Datensätze zu ändern oder LogDateien zu sehen. Die Optionen, Funktionen und Links können beliebig erweitert und an die Rolle angepasst werden. 2. Alle Datensätze sind für diese Admin-Rolle auch lösch- beziehungsweise veränderbar. Abbildung 9: Ablaufdiagramm mit den Optionen eines "Administrators" nach dem Anmeldeprozess (use case 3) -62- 7. Realisierung eines Prototyps zur Administration einer chemischer Stoffdatenbank Auf Grundlage der in dieser Diplomarbeit erarbeiteten Punkte der Administration, der Datensicherheit und der Anforderungsanalyse wurde ein Prototyp entwickelt. Im Folgenden wird die Realisierung des Prototyps dargestellt. 7.1 Einrichtung und Installation von Web- und Datenbankserver Webserver Die Entwicklung des Prototyps ist in der Skriptsprache PHP (Version 4) realisiert, welche ein PHP-Modul zum Ausführen der PHP-Seiten voraussetzt. Hierfür wurde das Programm XAMPP 2.4, eine Zusammenstellung freier Software durch „Apache Friends“, für den lokalen Einsatz auf dem Entwicklungsrechner installiert. XAMPP zeichnet sich durch eine sehr einfache Installation und Bedienbarkeit aus und hat des Weiteren den Vorteil, dass neben der Webserver-Funktionalität gleich ein Mailserver (Mercury/32) inbegriffen ist. Somit kann gleich das Versenden von Mails lokal für eine Nutzeranmeldung auf der Seite oder bei vergessenem Passwort getestet werden. Datenbankserver Durch das ISDA-Projekt (siehe Kapitel 5) existiert bereits ein Datenbanksystem in PostgreSQL, welches bereits teilweise mit chemischen Stoffdaten gefüllt ist. Zum Zwecke der Entwicklung wurde PostgreSQL lokal auf dem Entwicklungsrechner installiert und ein Dump, d.h. eine Kopie oder ein Speicherauszug der existierenden Stoffdaten, eingespielt. Ebenso wurde der Applikationsserver ColdFusion MX6.1 von Adobe (ehemals Macromedia) lokal installiert, um das Zusammenspiel mit der bei den Projektpartnern bestehenden Umgebung testen zu können. -63- 7.2 Aufbau und Realisierung des Prototyps 7.2.1 Architektur und Aufbau Im Fordergrund steht die Erweiterbarkeit des Programms. Daher soll der Aufbau der Seiten so modular wie möglich gestaltet sein. Abbildung 10 zeigt den Aufbau des Prototyps und die Interaktion zwischen den Seiten, Klassen und der Datenbank. Abbildung 10: Darstellung des Aufbaus der Seiten und Objekte des Prototyps Die Seitenstruktur Im Mittelpunkt für jede Seite steht die Datei „Site_structure.php“. Diese enthält Funktionen über das Grundgerüst einer jeden anzuzeigenden Seite. Die eingebundene Stylesheet-Datei „Isdastyles.css“ sorgt dabei für ein entsprechend einheitliches Layout. -64- Jede PHP-Seite, die im Browser etwas anzeigt und ausgibt, bindet also zunächst die „site_structure.php“ für die Seitenstruktur ein und führt die darin enthaltenen Funktionen aus. Klassen und Objekte Für die Abhandlung von Datenbankzugriffen, Prüffunktionen, Protokollfunktionen und für das Versenden von E-Mails stehen Klassen zur Verfügung. Diese Klassen werden von Seiten, die bestimmte Funktionalitäten benötigen, eingebunden und Objekte erzeugt. Die Klasse „db_functions“ (aus der Datei „db_functions.php“) stellt alle Funktionen für den Zugriff auf die ISDA-Datenbank zur Verfügung. Sie beinhaltet die Zugangsdaten (Host-Adresse, Username, Passwort, usw.) und SQL-Abfragefunktionen. Somit müssen alle Datenbankabfragen über dieses Objekt realisiert werden. Dafür existieren entsprechende Funktionen mit Rückgabewerten. „ISDA_functions“ ist eine Klasse zu Abhandlung aller auf die ISDA-Administration bezogenen Funktionen. Diese beinhaltet vor allem Syntax-Checks von Nutzereingaben, das Überprüfen von Nutzer-Logins, das Zusammenbauen von SQL-Statements, usw. Das Versenden von E-Mails wird ebenfalls durch eine Klasse „email_functions“ abgehandelt. Hier übergibt man einfach der E-Mail-Funktion in der Klasse die Zieladresse, Betreff und Text. Ist ein Mailserver erreichbar, wird mit diversen PHPFunktionen eine E-Mail versendet. Die „logfile_functions“-Klasse dient der Protokollierung von System- und Nutzeraktionen und sorgt für den lesenden und schreibenden Zugriff auf die ProtokollDateien. Diese Daten werden als Textdateien auf dem Webserver gespeichert. -65- Seiten zur Anzeige Hiermit sind die Seiten gemeint, die tatsächlich Ausgaben auf dem Browser erzeugen. Diese Seiten nutzen alle zunächst die gleiche Seitenstruktur über die „Site_structure“Funktionen und weiterhin bestimmte Klassen je nach Anwendungsfall. Als Erstes ist wohl die index-Seite („index.php“) zu nennen. Diese stellt bei PHP, wie auch in vielen anderen Technologien, den Einstiegspunkt dar. Sie beinhaltet lediglich eine Willkommens-Seite mit einer Navigationsleiste (Links) zum Einloggen und Registrieren. Für die Registrierung und das Anmelden existieren weitere einzelne Seiten: „registration.php“ und „login.php“. Weiterhin gibt es eine Seite, um Nutzerpasswörter per E-Mail zurückzusetzen, die „lost_pass.php“. Die Seiten „activation.php“ und auch „lost_pass.php“ beinhalten noch eine spezielle Funktion für die Bearbeitung von Aktivierungslink, die bei der Aktivierung eines neuen Nutzerkontos oder bei dem Zurücksetzen vom Passwort per E-Mail an den Nutzer gesendet wurden. Die dynamische Hauptseite Ist der Anmeldevorgang erfolgreich vonstatten gegangen und sind die Nutzerrechte geprüft, kommt die Seite „page.php“ ins Spiel. Diese Seite stellt die Hauptseite dar und beinhaltet alle Administrations- und ISDA-Funktionalitäten. Jedoch passt sich diese Seite dynamisch an die Rechte des Nutzers an, der sich anmeldet, d.h. der Nutzer sieht nur die Funktionen und Links auf der Seite, die er auch tatsächlich ausführen darf. Ein Administrator mit vollen Rechten bekommt alle Funktionen aufgezeigt. Fehlermeldungen Um Fehlermeldungen und Ausgaben zentral an einem Ort zu verwalten, wird die Seite „error_handling.php“ eingeführt. Diese besteht nur aus einer Funktion mit Rückgabewert. In der Funktion enthalten sind alle Fehlermeldungen, die im Programm auftreten können. -66- 7.2.2 Programmtechnische Realisierung mit PHP und SQL Für die Umsetzung und Programmierung des Prototyps kommt die Entwicklungsumgebung „PHP Designer 2007“ Version 5.02 von „MPSoftware“ zum Einsatz. Für alle Arbeiten an der PostgreSQL-Datenbank wird das Tool „pgAdmin III“ (Version 1.6.2) vom „pgAdmin Development Team“ oder alternativ auch die webbasierte Schnittstelle „phppgadmin“ (Version 4.1.3) genutzt. Layout Das Layout jeder Seite wird ausschließlich durch die PHP-Seite „Site_structure“ vorgegeben. Darin befinden sich Funktionen für das Gerüst und den Aufbau der Seite, wie HTML-Kopf („<head>“), Hauptteil („<body>“), Navigationslinks und Schluss. Seiten, die etwas auf dem Browser anzeigen, importieren einfach diese Funktionalitäten und rufen sie an gegebener Stelle ab. Sessions Die Nutzung von „Sessions“ ist entscheidend für die Frage der Sicherheit im Sinne des Zugriffsschutzes und der unberechtigten Benutzung. Sessions bieten gleich mehrere Vorteile, die bei der Umsetzung der Anforderungen angewandt werden konnte. Der erste Vorteil ist, dass Sessions nach einer gewissen Zeit verfallen. Dies ist sehr nützlich, wenn der Nutzer beispielsweise vergisst sich vom Programm oder Server abzumelden. Sessions können weiterhin verschiedene nutzerbezogene Informationen in Variablen speichern, die dann im Programm wieder abgerufen werden können, wie zum Beispiel User IDs, E-Mail-Adressen oder Zeitstempel, wann ein Benutzer die letzte Aktion auf der Seite ausgeführt hat. PHP beinhaltet hier mehrere recht einfache Möglichkeiten, Sessions zu benutzen. Die Wahl fiel letztendlich auf die Verwendung von Session-Cookies, die auf der Seite des Nutzers gespeichert werden. Voraussetzung ist jedoch, dass der Browser des Nutzers die Speicherung von Cookies akzeptieren muss. -67- Funktionsaufrufe Die Prüfung von Nutzereingaben, E-Mail-Adressen, Logins, und andere „Checks“ auf Gültigkeit werden in der Klasse „isda_functions“ durchgeführt. Diese Klasse ist sozusagen mit Funktionen und Methoden beliebig erweiterbar und ist für alle ISDAtypischen Probleme und Abfragen erstellt worden. Aktivierungslinks Für die Links zur Aktivierung eines neu registrierten Nutzers, die der Nutzer nach der Registrierung per E-Mail zugesandt bekommt, ist in der Datenbank eine eigene Tabelle (siehe Kapitel 6, Tabelle „isda_user_activate“) eingerichtet. Diese Tabelle wird ebenfalls für die Links beim Zurücksetzen des Passwortes verwendet. Der Aktivierungslink beinhaltet Übergabeparameter: die user_id (d.h. das einzigartige Erkennungszeichen des Nutzers – der Primärschlüssel in der User-Tabelle) und einen zufällig generierten einzigartigen numerischen Code. Diese beiden Variablen stehen zusammen mit einem Zeitstempel in der Aktivierungstabelle auf der ISDA-Datenbank. Mit einer Datenbankabfrage wird die Übereinstimmung geprüft und bei Erfolg der Nutzer in der User-Tabelle freigeschaltet. Im Falle einer Passwortzurücksetzung bekommt der Nutzer die Möglichkeit dieses neu einzugeben und zu speichern. Der Grund für diese spezielle Vorgehensweise liegt hauptsächlich im Datenschutz und in der Absicherung gegenüber so genannten Robotern. Dies sind kleine Programme, die zum Beispiel automatisiert Anmeldeprozesse durchführen und somit „Datenmüll“ und Überflutungen von Daten hervorrufen. Abspeichern sensibler Daten Für das Abspeichern sensibler Daten auf der Datenbank, wie zum Beispiel Passwörter, wird die in PostgreSQL enthaltene Hash-Funktion MD5 zur Verschlüsselung verwendet. Somit ist es hier für alle Benutzer, die lesend Zugriff auf die User-Tabelle haben, nicht möglich Passwörter im Klartext zu lesen. Dies ist auch der Grund für das oben beschriebene Zurücksetzen des Passwortes über Aktivierungslink und erneuter Eingabe. -68- Dynamischer Seitenaufbau mit der „page.php“ Am Anfang dieser Hauptseite steht die Überprüfung der aktuellen Session. Ist der Nutzer nicht eingeloggt über die Login-Seite, hat er auch keine gültige Session bzw. Session-Variablen und auch keine Berechtigung, die Seite zu sehen. Er wird in diesem Fall automatisch auf die Login-Seite umgeleitet. Selbiges gilt bei den so genannten Timeouts, d.h. wenn der angemeldete Nutzer eine bestimmte Zeit keine Aktion mehr auf der Seite getätigt hat. Die „page.php“ baut sich dynamisch je nach Rechten des Nutzers zusammen. Dazu bedient sie sich der Session-Variablen. Beim Login wurden diese Session-Variablen, die nun global auch für die page.php abrufbar sind, mit Werten wie Nutzer ID, Nutzerrolle, E-Mail-Adresse und Zeitstempel gesetzt. Alle Links in der Navigation rufen nun rekursiv die eigene Seite „page.php“ mit verschiedenen Übergabeparametern auf. Diese Parameter beinhalten dann zunächst die Aktion, die ausgeführt werden soll und ggf. weitere funktionsspezifische Parameter. Einer der wesentlichen Vorteile für nur eine Seite, über die alle Funktionen abgewickelt werden, besteht in der Zentralisierung und einfachen Kontrolle des Zugriffsschutzes. Würde für jeden Link bzw. für jede Funktion auf der Seite eine neue andere Seite aufgerufen werden, müsste jede einzelne dieser Seiten neu vor Fremdzugriff abgefragt und aufgebaut werden. 7.2.3 Codebeispiel Es folgen zwei Ausschnitte aus dem Prototyp, welche einige zuvor beschriebene Funktionen praktisch verdeutlichen sollen. Der komplette Prototyp mit allen PHPDateien befindet sich auf der dieser Diplomarbeit beiliegenden CD. -69- Abbildung 11: Code-Ausschnitt aus "site_structure.php" Abbildung 11 zeigt einen Ausschnitt aus der Datei „site_structure.php“ mit den Funktionen für den Seitenkopf, -körper und -navigation. Übergabeparameter für die einzelnen Funktionen individualisieren Titel und Überschriften der Seiten. Die Funktion „site_navigation($array_links)“ baut die Navigation dynamisch zusammen. Sie benötigt dazu alle gewünschten Links in einem Array als Übergabeparameter. -70- Abbildung 12: Code-Ausschnitt aus "page.php" Bei diesem Code-Ausschnitt der dynamischen Hauptseite „page.php“ sieht man am Anfang den PHP-Funktionsaufruf „session_start()“, der die Session-Cookies intern verwaltet. Eine wichtige Funktion bei jedem Aufruf dieser Seite ist die Überprüfung der Gültigkeit der aktuellen Nutzer-Session. Bei erfolgreichem Login (d.h. Anmelden auf der Login-Seite – „login.php“) werden für die von PHP erstellte Session nutzerspezifische Variablen gesetzt und abgespeichert. Diese Session-Variablen, im Abbildung 11 erkennbar durch $_SESSION[´Variablen-Name´], werden unter anderem -71- bei Aufruf der Hauptseite abgefragt. Somit kann man beispielsweise den direkten Aufruf dieser Seite im Browser unterbinden oder Timeouts bei „Nichtstun“ auf der Seite realisieren. 7.2.4 Frontend, Layout und Design Bei dem Layout und Design für die einzelnen Seiten gab es eine Vorgabe durch das FZD und den Verbundpartnern des ISDA-Projektes. Nachfolgend drei Screenshots des Prototyps vom Registrieren über das Login zur Hauptseite. Abbildung 13: Screenshot Prototyp - Registrierung -72- Abbildung 14: Screenshot Prototyp - Login Abbildung 15: Screenshot Prototyp - Hauptseite (als Administrator) -73- 8. Fazit In dieser Diplomarbeit werden zunächst die theoretischen Grundlagen für webbasierte Technologien, Informationssicherheit und verschiedenste Administrationsaufgaben webbasierter Datenbanken erörtert. Darauf aufbauend geht es im zweiten Teil darum, die theoretisch erarbeiteten Grundlagen an einem Projekt zur Verwaltung chemischer Stoffdaten in einer Datenbank praktisch umzusetzen. Für den zu entwickelnden webbasierten Prototypen werden dazu zunächst eine Ist-Analyse des bestehenden Systems und eine anschließende Anforderungsanalyse durchgeführt. Dabei kommt es vor allem auf die Sicherheit der Daten im Sinne der Informationssicherheit und des Zugriffsschutzes an. Weiterhin wird ein Nutzer- und Rollenkonzept für den differenzierten Zugriff auf die Webseite entwickelt. Bei der Ist-Analyse und Aufstellung der Anforderungen für das Administrationssystem kam es auf einen engen Kontakt und viel Kommunikation mit den Projektpartnern an. Dabei war es nicht immer leicht, die Ausgangssituation zu überblicken und präzise Antworten für die genauen Anforderungen der Administrations-Seite zu bekommen. Allgemein kann man sagen, dass die Vorabplanung und Kommunikation bei Softwareprojekten mit heterogenen Ausgangslagen viel stärker beachtet werden muss. Die Idee der flexiblen Eigenschaften und Attribute im Datenbankdesign ist in der Praxis schwierig umsetzbar und geht eindeutig zu Lasten der Übersichtlichkeit. Dies betrifft insbesondere die Übersichtlichkeit bei SQL-Abfragen. PHP 4 für die Entwicklung des Prototyps und das Datenbanksystem PostgreSQL sind eine gute Kombination. PHP ist eine relativ einfache Programmiersprache für die Webentwicklung. Sie beinhaltet bereits Funktionen für Zugriff und Abfragen auf PostgreSQL-Datenbanken. Allein die große Community um PHP, die einfache Nutzung von Sessions zur Verwaltung von Sitzungen und die angebotenen Funktionen ermöglichen eine schnelle, einfache Programmierung mit dieser Skriptsprache. Die parallele Nutzung unterschiedlicher Zugriffsarten auf die PostgreSQL-Datenbank ist jedoch ungünstig. -74- Zum Abschluss kann man sagen, dass die Entwicklung eines Administrationssystems, die Gewährleistung von Sicherheit und die Einrichtung einer Nutzerverwaltung mit vertretbarem Aufwand realisierbar sind. Für das Forschungszentrum Dresden-Rossendorf ist diese Diplomarbeit über Architektur und Administration einer webbasierten Datenbank ein wichtiger Wissenszuwachs an Theorie und Vorgehensweisen. Der entwickelte Prototyp gilt als Vorlage und wird im Rahmen des ISDA-Projektes weiterentwickelt und zum Einsatz kommen. -75- Anlagen Anlage A: Im Prototyp verwendete PHP-Klassen, -Seiten und -Stylesheets. Folgende Tabellen zeigen die bei der Realisierung im Prototyp verwendeten PHPKlassen, -Seiten und -Stylesheets. Zu den einzelnen Seiten sind jeweils die enthaltenen Funktion und deren Beschreibung aufgeführt. Tabelle 11: Im Prototyp verwendete PHP-Klassen Name db_functions Funktionen/Methoden db_functions() Pg_db_open() Pg_db_close() Pg_db_query($query) ISDA_functions ISDA_functions() get_userID() get_roleID check_string($str) check_special_characters($str) check_E-Mail($E-Mail_address) Beschreibung Diese Klasse stellt die Verbindung zur Datenbank her und realisiert jegliche Abfragen. Konstruktor. Hier sind die Zugangsdaten für die Datenbank einzugeben. Host, Datenbankname, User, Passwort. Öffnet eine Datenbankverbindung mit den initialisierten Zugangsdaten. Schließt die Datenbankverbindung Führt den im Parameter übergebenen SQL-Query aus. Rückgabewert dieser Funktion ist das Resultset. Diese Klasse enthält alle ISDAtypischen Funktionen, wie Nutzer prüfen, Eingabestrings prüfen, Abfragen aufbereiten, ... Konstruktor. Legt nur ein Objekt von „db_functions“ an für spätere Datenbankabfragen. Methode zum Abruf der aktuellen UserID Methode zum Abruf der aktuellen RoleID Für Abfragen von Eingabefeldern. Hier sind nur Buchstaben (A-Za-z) erlaubt. Rückgabewert ist boolean. FALSE wenn andere Zeichen auftreten, ansonsten TRUE. Für die Entwertung von Sonderzeichen bei Eingaben die in SQL-Statements eingesetzt werden (z.B. Name: O’Shamir wird für SQL ersetzt -> O\’Shamir). Rückgabewert ist der komplette SQL-String mit Entwertungen Prüft ob ein String im E-Mail-Format ([email protected]) vorliegt und -76- check_user($user_E-Mail, $pass) cleanup_users_expired() E-Mail_functions (Temp. Lösung) E-Mail_functions($sender_adresse, $ziel_adresse, $betreff, $text) mail_senden() logfile_functions Logfile_functions() add_log($wer, $wann, $was, $ok, $text) get_log() count_login() nicht mehr als 50 Zeichen enthält. Rückgabewert ist boolean. TRUE im Erfolgsfall, ansonsten FALSE. Prüft anhand der übergebenen EMail-Adresse und Passwort ob ein Nutzer in der DB existiert und das Konto aktiv ist. Rückgabewert ist ein Array mit roleID und userID. Bei Misserfolg bleibt dieses Array leer. Bei jedem Login-Versuch irgendeines Nutzers wird vorher die „isda_users“ Tabelle nach alten Registrierungen durchgegangen. Ist das „user_reg_date“ älter als 3 Tage, wird der Datensatz in der Tabelle „isda_users“ wieder gelöscht. Der dazu passende Eintrag in der Tabelle „isda_user_activate“ wird automatisch mit gelöscht. Nutzt das eZComponents – Modul, welches zusätzlich geladen werden muss. Konstruktor. Übergabeparameter für die Initialisierung dieses Objektes sind die Strings: Sender-Adresse, Ziel-Adresse, Betreff und HauptText. Generiert ein Mail-Objekt und sendet die Mail. Rückgabeparameter ist boolean. TRUE bei Erfolg. Übernimmt das Schreiben und Auslesen der Log-Datei. Konstruktor Fügt einen Log-Eintrag in die LogDatei ein. Übergabparameter sind Nutzer-E-Mail, Datum-Zeit, Aktion, Status und ein Text für weitere Infos. Liest die Log-Datei zeilenweise in ein Array und liefert dieses Array als Rückgabeparameter zurück. Zählt Login-Versuche -77- Seiten Tabelle 12: Im Prototyp verwendete PHP-Seiten Name site_structures Funktionen site_header($seiten_titel) site_body($ueberschrift) site_navigation($array_links) site_footer() index login show_login_form() registration Eingabefelder($last, $first, $E-Mail) activation Beschreibung Hier werden das Layout und die Seitenstruktur (Gerüst) für jede Seite zentral gehalten und kann mittels Funktionen in jede neue ISDA-Seite eingefügt werden. Bildet den Anfang jeder HTML-Seite. Übergabeparameter ist der Seitentitel. Anfang des Bodys mit dem body-tag. Übergabeparameter ist die Überschrift, die über den Hauptseiteninhalt (zur Orientierung) steht. Baut die Navigationsleiste (links) zusammen, je nach Anforderung einer Seite. Übergabeparameter ist ein Array mit den Links. Eine Schleife durchläuft das Array und bildet die Navigationsleiste. Schließt jede HTML-Seite ordentlich ab mit </div>, </body> und </html> Startseite mit Links zu den jeweiligen Seiten (Login, Registrierung, etc.) Beinhaltet den Login-Prozess. Zunächst ein Formular mit Selbstverweis der POST-Variablen EMail und Passwort. Sind die Eingaben semantisch korrekt, werden die Daten in der Datenbank geprüft und der Nutzer im Erfolgsfall eingeloggt. Baut das Formular mit 2 Eingabefeldern für E-Mail und Passwort auf. Beinhaltet den Registrierungs-Prozess. Stellt die Eingabefelder bereit und prüft alle einzelnen Felder auf die jeweilige Gültigkeit. Im Erfolgsfall wird eine E-Mail an die eingegebene Adresse mit einem Aktivierungscode gesendet. Baut das Formular mit den Eingabefeldern auf. Übergabeparameter sind eventuell vorher schon einmal eingegebene Daten, damit diese nicht immer verschwinden bei jedem kleinen Fehler. Wird explizit aufgerufen über den Aktivierungslink, der per Mail bei der Registrierung gesendet wurde. GETVariablen sind userID und Aktivierungscode. Diese werden in der Datenbank verglichen und das Konto -78- error_handling fehler_meldung($fehler_nummer) page site_search, site_logout, ... get_navigation($role_id) lost_pass show_pass_form($E-Mail) Eingabefelder($uid, $code) auf aktiv gesetzt. Zur zentralen Verwaltung von Fehlermeldungen mittels Fehlernummern. Gibt einen bestimmte Fehlermeldung zurück. Übergabeparameter ist die Fehlernummer. Diese Seite stellt die Hauptseite nach dem erfolgreichen Login dar. Sie wird dynamisch zusammengebaut. Seiten-Links in der dynamischen Navigationsleiste rufen immer nur die page.php jeweils mit anderen Parametern auf (z.B. page.php?par=edit) Spezifische Funktionen, die mit den Links aufgerufen werden Die Navigation wird hier dynamisch anhand der Rollen ID zusammengebaut. Diese Funktion ist beliebig erweiterbar. Rückgabeparameter ist ein Array, welches dann mit der „site_structure“Funktion „site_navigation“ die Nav. aufbaut. Wird aufgerufen, wenn man auf „Passwort vergessen“ klickt. Nach Eingabe einer E-Mail-Adresse wird ein Link per Mail versandt. Gleichzeitig reagiert diese Seite ähnlich wie „activation.php“, wenn sie explizit über den Link zum Neusetzen des Passwortes aufgerufen wurde. Anzeige des Eingabefeldes für die EMail-Adresse, an die der Link gesendet werden soll. Diese Felder werden angezeigt, wenn der Link zum Neusetzen (aus der Mail) verwendet wird. Im Link sind die Parameter UserID und der zufällig generierte Code enthalten. Styles (CSS) Tabelle 13: Im Prototyp verwendete Stylesheets Name isdastyles Beschreibung Enthält das Layout der ISDA Seite und wird in der PHP-Seite „site_structure“ in der Funktion für jeden Seitenkopf „site_header“ geladen. -79- Literaturverzeichnis Anmerkung: Das Literaturverzeichnis ist alphabethisch nach Bereichen geordnet. Alle Internetseiten wurden am 01.10.2007 vor Drucklegung der Diplomarbeit auf Gültigkeit und Erreichbarkeit geprüft. Bücher [B_xxxxx9] [B_HÄRDE1] HÄRDER, T. u. E. RAHM: Datenbanksysteme, Konzepte und Techniken der Implementierung, Springer-Verlag Berlin Heidelberg New York, 2001 [B_HEINR1] HEINRICH, L.J. u. F. LEHNER: Informationsmanagement, Oldenbourg, 2005, Auflage 8 [B_HUSEB1] HUSEBY, S.H.: Sicherheitsrisiko Web-Anwendung, Wie WebProgrammierer Sicherheitslücken erkennen und vermeiden, dbpunkt.verlag GmbH, 2004 [B_LOCKE1] LOCKEMANN, P.C. u. K. R. DITTRICH: Architektur von Datenbanksystemen, dbpunkt.verlag GmbH, 2004 [B_LOESE1] LOESER, H.: Web-Datenbanken, Einsatz objekt-relationaler Datenbanken für Web-Informationssysteme, Springer-Verlag Berlin Heidelberg, 2001 [B_LONEY1] LONEY, K. u. M. THERIAULT: Oracle 9i, DBA-Handbuch, Carl Hanser Verlag München Wien, 2002 [B_SPONA1] SPONA, H.: Web-Datenbanken, Das bhv Taschenbuch, verlag moderne industrie, Buch AG & Co. KG, Landsberg, 2002 -80- [B_STEIN1] STEIN, E.: Taschenbuch Rechnernetze und Internet, 2. Auflage, Hanser Fachbuchverlag, 2003 [B_WIGAR1] WIGARD, S.: PHP4 – Das Einsteigerseminar, 3. Auflage, bhv verlag moderne industrie, Buch AG & Co. KG, Landsberg, 2003 Internet [I_xxxxx9] [I_ADOBE1] CHAMBERS, M., Macromedia Flash Artikel http://www.adobe.com/de/devnet/articles/flash_databases/ [I_COMMO1] Common Criteria IT-Sicherheitsportal http://www.commoncriteria.de/ [I_DATEN1] NRW Forschungsverbund Datensicherheit http://www.datensicherheit.nrw.de/Information/pki/pki.html [I_EILER1] EILERS, C., entwickler.com, About Security #1: IT-Sicherheit, http://entwickler.com/itr/news/psecom,id,21135,nodeid,82.html [I_ELEKT1] SCHNABEL, P., Das Elektronik-Kompendium http://www.elektronik-kompendium.de/sites/net/0902281.htm [I_JAKL1] JAKL, M., Kryptographische Hash-Algorithmen, TU-Wien, 2003 http://int-x.org/lib/exe/fetch.php?id=uni%3Aindex& cache=cache&media=uni:hash.pdf [I_WLOKA1] WLOKA, U.: E-Learning Module „Zugriff auf DB über WWW“, Hochschule für Technik und Wirtschaft Dresden (FH), 2004 http://wwwmi.informatik.htw-dresden.de/wbt-webdb/ -81- [I_WLOKA2] WLOKA, U.: E-Learning Module „Datensicherheit/ Datenintegrität in Datenbanken“ , Hochschule für Technik und Wirtschaft Dresden (FH), 2004 http://wwwmi.informatik.htw-dresden.de/wbt-ds2/ Zeitschriften und Reports [Z_xxxxxx] [Z_BRASS1] BRASSER, T., J. MÖNIG, C. SCHERSCHEL, u. M. VEERHOFF: Sorptions-Datenbank SODA - Datenbank zur Bestandsaufnahme und Bewertung geochemischer Informationen zum Verhalten von Abfallinhaltsstoffen im Deckgebirge einer UTD/UTV.- GRS-182, 116 S. + CD, Köln, 2002 [Z_BREND1] BRENDLER, V., A. VAHLE, T. ARNOLD, G. BERNHARD u. T. FANGHÄNEL: RES³T – Rossendorf Expert System for Surface and Sorption Thermodynamics. Journal of Contaminant Hydrology 61, 281-291 S., 2003 [Z_RÜTTG1] RÜTTGEN, C. u. T. GLEMSER, Gesundes Misstrauen – Sicherheit von Web-Anwendungen, Seite 234, c’t, Heft 26, 2006 -82- Glossar ACID-Eigenschaften ACID steht für Atomicity (Atomarität), Consistency (Konsistenz), Isolation (Isolation) und Durability (Dauerhaftigkeit). Diese Eigenschaften werden von Transaktionen in einem Datenbankmanagementsystem oder verteilten Systemen erwünscht. Applikationsserver Bezeichnet allgemein einen Server oder auch eine Software in einem Computernetzwerk, auf dem Anwendungsprogramme ausgeführt werden. In einer mehrschichtigen Architektur befindet er sich zwischen der Daten- und Präsentationsschicht auf der Logikebene und stellt Dienste, wie Transaktionen, Authentifizierungen oder den Zugriff auf Verzeichnisdienste oder Datenbanken zur Verfügung. Array Ist ein ein- oder mehrdimensionales Feld in dem Daten eines gleichen Datentyps gehalten werden. Biosphäre Mit Biosphäre ist ein Teil der Erdoberfläche, der Atmosphäre sowie der lebenden organischen Substanzen und Lebewesen definiert. Check-Klauseln Durch Check-Klauseln auf dem Datenbanksystem kann zum Beispiel der Wertebereich für Tabellen-Attribute eingeschränkt werden. Es können in diesen Klauseln auch vollständige SQL-Anfragen angegeben werden. Common Criteria CC (Common Criteria) sind die gemeinsamen Kriterien für die Bewertung der Sicherheit von Informationstechnologie. Sie sind ein internationaler Standard für -83- Kriterien der Sicherheit von Computersystemen im Hinblick auf Datensicherheit und Datenschutz. Cookies Sind Daten die zum Austausch von Informationen zwischen Computerprogrammen oder der zeitlich beschränkten Archivierung von Informationen dienen. Denial-of-Service-Angriffe Denial-of-Service heißt übersetzt soviel wie Dienstverweigerung und bezeichnet hier einen Angriff auf einen Server oder Rechner mit dem Ziel, diesen arbeitsunfähig zu machen. In Regel wird dies durch Überlastung des Servers erreicht. Entity-Typen Objekte der Real- oder Vorstellungswelt werden als Entitäten bezeichnet. Entitäten mit gleichen Eigenschaften werden zu Entitätstypen zusammengefasst. Eine Tabellen kann also als Entitätstyp (Entity-Typ) aufgefasst werden. Flags Mit Flag wird eine binäre Variable bezeichnet, die als Hilfsmittel zur Kennzeichnung bestimmter Zustände benutzt werden kann. Hash-Funktionen Hash-Funktionen oder auch Streuwertfunktionen sind Funktionen, die zu einer Eingabe aus Quellmengen eine Ausgabe erzeugen. Dabei besteht die Ausgabe aus einer bestimmten Zielmenge, die im Allgemeinen kleiner ist als die Eingabewerte mit beliebiger Größe. Hash-Werte sind meist skalare Werte aus einer Teilmenge der natürlichen Zahlen. Head-Crash Dieser Begriff Head-Crash bezeichnet den mechanischen Ausfall einer Festplatte durch den Lese-/Schreibkopf bei dem meist alle Daten verloren gehen. -84- JDBC-API JDBC ist eine Datenbankschnittstelle (API - Application Programing Interface) der Java-Plattform, die eine einheitliche Schnittstelle zu Datenbanken verschiedener Hersteller bietet. JSP-Compilers JavaServer-Pages ist eine von SUN Microsystems entwickelte Technologie, die zur einfachen dynamischen Erzeugung von HTML- und XML-Ausgaben eines Webservers dient. Knowledgebase-System Damit ist eine spezielle Datenbank für das Wissensmanagement gemeint. Sie stellt die Grundlage für die Sammlung von Daten dar und enthält meist explizites Wissen in schriftlicher Form. Kontaminanten Sind unerwünschte, giftige Stoffe und Verunreinigungen wie zum Beispiel Schwermetalle und verschiedene Umweltgifte. OSI-Modell Das Open Systems Interconnection Reference Model ist ein Schichtenmodell nach dem ISO-Standard. Dieses beschreibt sieben aufeinander aufbauende Schichten und deren Aufgaben der Kommunikation. Für jede Schicht existiert eine Beschreibung, was diese zu leisten hat. Parsing Mit diesem Begriff wird die Umwandlung von Befehlen und Eingaben in einem Computerprogramm durch einen Parser bezeichnet. Dieser Parser wandelt eine beliebige Eingabe in ein für die Weiterverarbeitung brauchbares Format um. -85- PostgreSQL PostgreSQL ist ein freies objektrelationales Datenbanksystem, welches weitestgehend konform ist mit jeglichen SQL-Standards. RAID Ein RAID-System (Redundant Array of Independent Disks) dient zur Organisation mehrerer physischer Festplatten eines Computers zu einem logischen Laufwerk. Dies gewährleistet eine höhere Datensicherheit bei Ausfall einer Platte und/oder erlaubt einen größeren Datendurchsatz als nur eine physische Platte. Reverse-Engineering Ist die Rekonstruierung aus einem bestehenden, fertigen System bzw. Objekt zurück zu einem Plan oder Modell. In der EDV ist dabei meist die Rückgewinnung von einem Quellcode aus einem Programm oder Binärcode gemeint. Rollback Bezeichnet das Zurücksetzen einzelner Verarbeitungsschritte einer Transaktion. Session Eine Session bezeichnet hier eine logische Verbindung zwischen zwei adressierbaren Einheiten in einem Netzwerk, um Daten auszutauschen. In der Client-Servertechnik ist es die zeitweise bestehende Verbindung eines Clients und eines Server. Sorption Bezeichnet die chemische Wechselwirkung von im Wasser gelösten Schadstoffen und dem umgebenden Gesteinsmaterial. Thin Client Ein Thin Client ist ein Endgerät oder Programm in einem Netzwerk, dessen funktionale Ausstattung auf die Ein- und Ausgabe beschränkt ist. Er bezieht seine Daten möglichst vollständig von einem Server. -86- Trigger Hiermit ist ein Datenbanktrigger gemeint. Dieser ist eine Funktionalität von diversen Datenbankmanagementsystemen. Er ruft bei einer bestimmten Art von Änderung in einer Tabelle eine gespeicherte Prozedur auf, die diese Änderung akzeptiert, verhindert oder andere Tätigkeiten ausführt. Änderungen können zum Beispiel bei SQL INSERT, UPDATE oder DELETE sein. -87- Danksagung Ich möchte mich an dieser Stelle bei all denen bedanken, die mich bei der Bearbeitung meines Diplomthemas unterstützt haben. Für die Betreuung meiner Diplomarbeit danke ich Herrn Prof. Gunter Gräfe von der Hochschule für Technik und Wirtschaft Dresden und Herrn Dr. Vinzenz Brendler vom Forschungszentrum Dresden Rossendorf e.V. Des Weiteren gilt mein Dank den Verbundpartnern im Verbundprojekt ISDA, besonders Herrn Scherschel von der Dr. Veerhof und Scherschel GbR und Herrn Brasser von der Gesellschaft für Anlagen- und Reaktorsicherheit (GRS) mbH. -1- 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 benutzt habe. Alexander Ihlau Dresden, den 15.10.2007
