Entwurf und prototypische Realisierung von Maßnahmen

Transcription

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

Entwurf und prototypische Realisierung von Maßnahmen

Transcription

Similar documents

2. Typische Angriffe

Ethernet Basics - Phoenix Contact

Möglichkeiten und Grenzen von J2ME

Ventile

Sicherheitstechniken in Kommunikationsnetzen

Konzeptioneller Entwurf und prototypische Realisierung einer

1 Relationale Datenbanken (DB): Das Relationenmodell

LeMo: a Learning Analytics Application Focussing on User Path