Otto-von-Guericke-Universität Magdeburg

Transkript

1 Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut für Technische und Betriebliche Informationssysteme Master-Thesis Untersuchungen zum aktuellen Forschungsstand von Self-Healing und Self-Protection in Datenbankmanagementsystemen Verfasser : Stefan Barthel Matrikel-Nr.: Betreuer : Dr.-Ing. Eike Schallehn Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik D Magdeburg Betreuer : Prof. Dr.-Ing. Andreas Nürnberger Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik D Magdeburg

2 III Danksagung Barthel, Stefan Untersuchungen zum aktuellen Forschungsstand von Self-Healing und Self-Protection in Datenbankmanagementsystemen Master-Thesis Otto-von-Guericke-Universität Magdeburg, 2012.

3 Danksagung IV Danksagung Eine wissenschaftliche Arbeit wie diese braucht die Unterstützung Vieler, um zum Abschluss zu kommen. Mein Dank gilt daher allen helfenden Händen und Augen, welche ihre Zeit opferten, um mich in meinem Vorhaben zu unterstützen, diese Arbeit zu verfassen. Mein größter Dank gilt Herrn Dr. Eike Schallehn für seine Bereitschaft, mich seit dem ersten Tag mit Ideen und Wissen zu unterstützen. Zudem bin ich sehr dankbar, in ihm einen Betreuer und Freund gefunden zu haben, der auch zu untypischen Tages- und Nachtzeiten aufgekommene Fragen beantwortet und dieses stets als selbstverständlich betrachtete. Weiterhin möchte ich mich bei Prof. Dr. Andreas Nürnberger für die Bereitschaft bedanken, die ehrenvolle Aufgabe des Zweitgutachters zu übernehmen, trotz der relativ kurzen Vorlaufzeit. Zuletzt möchte ich auch meinem ehemaligen Arbeitgeber - COMPAREX - danken, der mir die Wichtigkeit dieser Arbeit nachsah und mich anfangs teilweise freistellte, sowie schlussendlich anstandslos freigab, damit ich die Arbeit bestmöglich beenden konnte.

4 V Inhaltsverzeichnis

5 Inhaltsverzeichnis VI Inhaltsverzeichnis DANKSAGUNG... IV INHALTSVERZEICHNIS... VI ABBILDUNGSVERZEICHNIS... X TABELLENVERZEICHNIS...XII ABKÜRZUNGSVERZEICHNIS... XIV 1. EINLEITUNG ZIELSETZUNG GLIEDERUNG GRUNDLAGEN ZU DATENBANKEN GRUNDLEGENDE BEGRIFFE HISTORISCHE ENTWICKLUNG DER DATENBANKMANAGEMENTSYSTEME ARCHITEKTUR UND EIGENSCHAFTEN EINES DATENBANKSYSTEMS NEUN ANFORDERUNGEN NACH CODD ARCHITEKTUR VON DATENBANKMANAGEMENTSYSTEMEN SCHEMAARCHITEKTUR ANWENDUNGSARCHITEKTUR SYSTEMARCHITEKTUR FÜNF-SCHICHTEN-MODELL SPEICHERHIERARCHIE VERWALTUNG DES HINTERGRUNDSPEICHERS SEITEN, SÄTZE UND ADRESSIERUNGEN TRANSAKTIONEN MARKTANALYSE DERZEITIGER DATENBANKSYSTEME DBMS-BEZUG IN DIESER ARBEIT GRUNDLAGEN ZU SELF-HEALING UND SELF-PROTECTION EINORDNUNG IN DAS AUTONOMIC COMPUTING ABGRENZUNG UND GEMEINSAMKEITEN MIT ANDEREN WISSENSCHAFTSBEREICHEN HERKUNFT UND EINORDNUNG DES SELF-HEALINGS... 36

6 VII Inhaltsverzeichnis 3.4. HERKUNFT UND EINORDNUNG DER SELF-PROTECTION BEDROHUNGEN UND GEFAHREN FÜR DATENBANKMANAGEMENTSYSTEME ANSÄTZE DES SELF-HEALINGS MECHANISMEN IN KONVENTIONELLEN SYSTEMEN SELF-HEALING WÄHREND EINER DATABASE MIRRORING SESSION SELF-HEALING DURCH WARTUNGSARBEITEN SELF-REPAIR DURCH AUTOMATIC FAILOVER STATISTISCHES MANAGEMENT DEADLOCKERKENNUNG GESUNDHEITSCHECKS PER HEALTH MONITOR FEHLERBEHEBUNG BEI DER TRANSAKTIONSVERARBEITUNG AUTOMATISCHES WACHSEN BEI PLATZMANGEL STABILISIERUNG DES SERVERS UND ANPASSUNG AN ARBEITSAUFKOMMEN AUTOMATISCHE INDEX- UND TABELLEN-ORGANISATION ANPASSUNG DES DATENBANKDESIGN BEI WECHSELNDEM ARBEITSAUFKOMMEN AKTUELLE FORSCHUNG UND PROTOTYPEN ITDB - A SELF-HEALING DATABASE SYSTEM [LIU04] OPTIMIZING SECURITY MEASURES IN AN INTRUSION TOLERANT DATABASE SYSTEM [UD08] RAINBOW-PROJEKT [GS02] SHAMAN: A SELF-HEALING DATABASE SYSTEM [DFT08] ACCURATE AND EFfiCIENT INTER-TRANSACTION DEPENDENCY TRACKING [CB08] A PORTABLE IMPLEMENTATION FRAMEWORK FOR INTRUSION-RESILIENT DATABASE MANAGEMENT SYSTEMS [SC04] SELF-HEALING AND HYBRID DIAGNOSIS IN CLOUD COMPUTING [DXZ09] REMUSDB: TRANSPARENT HIGH AVAILABILITY FOR DATABASE SYSTEMS [DXZ09] VERGLEICH UND ZUSAMMENFASSUNG ANSÄTZE DER SELF-PROTECTION MECHANISMEN IN KONVENTIONELLEN SYSTEMEN VERSCHLÜSSELUNG VON PROZEDUREN UND FUNKTIONEN... 87

7 Inhaltsverzeichnis VIII QUERY- UND RESSOURCEN-KONTROLLE IDENTITÄTS- UND ZUGRIFFSSTEUERUNG MODULSIGNIERUNG SELF-AUDITING UND MONITORING ZUM SYSTEMSCHUTZ CLR-INTEGRATION UND CODEZUGRIFFSSICHERHEIT HALBAUTOMATISCHES BACKUP UND RECOVERY EXCEPTION- UND ERROR-BEHANDLUNG BEI SKRIPTAUSFÜHRUNG VERHINDERUNG VON OUT-OF-SPACE-SITUATIONEN AKTUELLE FORSCHUNG UND PROTOTYPEN HOW TO BUILD A TRUSTED DATABASE SYSTEM ON UNTRUSTED STORAGE [MVS06] TOWARDS SELF-PROTECTION UBIQUITOUS SYSTEMS: MONITORING TRUST- BASED INTERACTIONS [ETN05] TOWARDS DATABASE FIREWALL: MINING THE DAMAGE SPREADING PATTERNS [BL07] SELF-PROTECTED SYSTEM: AN EXPERIMENT [DCL06] REDUCING ERRORS IN THE ANOMALY-BASED DETECTION OF WEB-BASED ATTACKS THROUGH THE COMBINED ANALYSIS OF WEB REQUESTS AND SQL QUERIES [VVB09] SQLRAND: PREVENTING SQL INJECTION ATTACKS [BK04] DETECTION OF MALICIOUS TRANSACTIONS IN DBMS [ASB10] DELIVERING SERVICES WITH INTEGRITY GUARANTEES IN SURVIVABLE DATABASE SYSTEMS [ZL04] VERGLEICH UND ZUSAMMENFASSUNG ZUSAMMENFASSUNG UND AUSBLICK LITERATURVERZEICHNIS SELBSTSTÄNDIGKEITSERKLÄRUNG

8 IX Inhaltsverzeichnis

9 Abbildungsverzeichnis X Abbildungsverzeichnis Abbildung 1: Aufbau des Datenbanksystems... 6 Abbildung 2: Aufbau einer Relation... 6 Abbildung 3: Zugriffsarten (vgl. [Wiki02])... 8 Abbildung 4: Drei-Ebenen-Schema-Architektur (vgl. [SSH10]) Abbildung 5: Anwendungsarchitekturen Abbildung 6: Systemarchitektur (vgl. [SHS05]) Abbildung 7: Fünf-Schichten-Modell Abbildung 8: Unterscheidung Primär-, Sekundär-, und Tertiärspeicher Abbildung 9: Festplattenaufbau Abbildung 10: Darstellungen einer Relation (vgl. [SHS05]) Abbildung 11: Tupelidentifikator Abbildung 12: Autonomic Computing-Loop (vgl. [IBM01]) Abbildung 13: Autonomic Computing-Abhängigkeiten Abbildung 14: Bestandteile des Autonomic Computings (vgl. [IBM01]) Abbildung 15: Herkunft Self-Healing Systems Abbildung 16: Self-Healing-Kreislauf (vgl. [PD10]) Abbildung 17: Herkunft Self-Protection Systems Abbildung 18: Problemlösungskreislauf (vgl. [RMS10]) Abbildung 19: Arbeitsweise ITDB [Liu04] Abbildung 20: Modell-basierte Adaptierung (vgl. [GD02]) Abbildung 21: Modell eines verteilten DBMS Abbildung 22: Abhängigkeiten der Transaktionen Abbildung 23: Arbeitsweise Self-Healing and Hybrid Diagnosis in Cloud Computing (vgl. [DXZ09]) Abbildung 24: Architektur RemusDB (vgl. [DXZ09]) Abbildung 25 : Architektur TDB (vgl. [MVS06]) Abbildung 26: One-hop und multi-hop spreading (vgl. [BL07]) Abbildung 27: Komponenten-basierte Jade-Architektur (vgl. [DCL06]) Abbildung 28: Kommunikation zwischen Web Server und Database Server (vgl. [BK04]). 107 Abbildung 29: Einordnung DBMTD (vgl. [ASB10])

10 XI Abbildungsverzeichnis

11 Tabellenverzeichnis XII Tabellenverzeichnis Tabelle 1: Strukturelle Bezeichnungen zu Systemebenen Tabelle 2: Abbildung der Speicherstrukturen Tabelle 3: Top 10-DBMS-Anbieter 2009 (vgl. [IDC09]) Tabelle 4: Gegenüberstellung der technischen und biologischen Systeme Tabelle 5: Gegenüberstellung von Zugriff, Autorisierungsstatus und Angriffsebene Tabelle 6: Gewichtungs-Level Tabelle 7: Auswertung der Self-Healing-Mechanismen und -Systeme Tabelle 8: Auswertung der Self-Protection-Mechanismen und -Systeme

12 XIII Tabellenverzeichnis

13 Abkürzungsverzeichnis XIV Abkürzungsverzeichnis 5SM AC ADDM ADL ADR ANSI ASC ASH ASM ASMM ASP AWR BDE BI CERT CGI CLR CODASYL CPM CPU DB DBA DBS DBMS DBMTD DBTG DCL DCPV DDL DSS DML DoS Fünf-Schichten-Modell Autonomic Computing Automatic Database Diagnostic Monitor Architecture Description Language Automatic Diagnostic Repository American National Standards Institute Automatic Statistics Collection Active Session History Automatic Storage Management Automatic Shared Memory Management Active Server Pages Automatic Workload Repository Backup Data Exposure Business Intelligence Computer Emergency Response Team Common Gateway Interface Common Language Runtime Conference on Data System Language Corporate Performance Management Central Processing Unit Datenbank Datenbankadministrator Datenbanksystem Datenbankmanagementsystem Database Malicious Transactions Detector Data Base Task Group Data Control Language Database Communication Protocol Vulnerabilities Data Definition Language Dateischnittstelle Data Manipulation Language Denial of Service

14 XV Abkürzungsverzeichnis DQL DSS EPA ESoF ESyF HTTP ID IHF IP ISF ISS JSP LDAP LPA LRU MDD MOS NCIRC OODBS OOP PE PGA PHP PV QoIAS RAM RDBMS SGA SIS SOS SPARC SPS SQL SQLI Data Query Language Decision Support System Excessive Privilege Abuse External Software Failure External System Failure Hypertext Transfer Protocol Identifikationsnummer Internal Hardware Failure Internet Protocol Internal System Failure Interne Satzschnittstelle Java Server Pages Lightweight Directory Access Protocol Legitimate Privilege Abuse Least Recently Used Multi-Valued Decision Diagram Mengenorientierte Schnittstelle Nato Computer Incident Response Capability s Technical Center Objektorientiertes Datenbanksystem Objektorientierte Programmierung Privilege Elevation Program Global Area PHP: Hypertext Preprocessor Platform Vulnerabilities Quality of Integrity Assurance Service Random Access Memory Relationales Datenbankmanagementsystem System Global Area Strategische Informationssicherheit Satzorientierte Schnittstelle Standards Planning and Requirements Committee Systempufferschnittstelle Structured Query Language SQL Injection

15 Abkürzungsverzeichnis XVI TID TSQL VM WA WAL WAT XML Tupelidentifikator Transact SQL Virtual Machine Weak Authentication Write Ahead Logging Weak Audit Trail Extensible Markup Language

16

17

18 Einleitung 1 1. Einleitung Computer werden heutzutage in so vielfältiger Art und Weise verwendet, dass es den meisten Menschen sehr schwer fallen wird, einen Bereich zu benennen, welcher vollkommen ohne Computer auskommen kann. Besonders bemerkenswert ist dieses jedoch, wenn in die Überlegung einfließt, dass der erste funktionsfähige Digitalrechner - Z3 - erst 1941 vom deutschen Wissenschaftler Konrad Zuse entworfen und gebaut wurde. Somit hat sich der Computer innerhalb von wenigen Jahrzehnten von einem Helfer zur Auszählung von Wahlstimmen zum wichtigsten technischen Gut des einundzwanzigsten Jahrhundert entwickelt (vgl. [S 12 ff. [Wur02]]). Die Evolution des Computers ist aber keinesfalls bereits abgeschlossen, sondern ein kontinuierlich fortschreitender Prozess. Mit der steigenden Komplexität sinkt jedoch auch die Nachvollziehbarkeit für den Menschen und so müssten entweder fremde Systeme die Prozesse überwachen oder das System eigenständig diese Aufgabe übernehmen. Somit geht mit wachsender Komplexität zwangsweise eine kontinuierliche Abkapselung von menschlichen Einflüssen einher. In fast allen Fällen kommt eine solche Automatisierung dem Menschen sehr entgegen, da ihm auf diese Weise Zeit und Anstrengungen erspart bleiben und auf der anderen Seite Genauigkeit, Effizienz und Verlässlichkeit gesteigert werden können. Darüber hinaus werden Kapazitäten des Systemadministrators freigesetzt, wodurch er sich anderen Problemen annehmen kann. Das Bedürfnis eine Selbstverwaltung des Computers zu etablieren ist somit ein erstrebenswertes Ziel, gerade wenn die Maximierung der Funktionalität, die hohe Komplexität und die umfassenden Strukturen, um große Datenmengen eines DBMS zu bewältigen, betrachtet werden. Zukünftig wird dieses Bedürfnis wahrscheinlich noch weiter zunehmen, da die zu sammelnden Datenmengen stündlich wachsen und damit auch deren Verwaltungsaufwand steigt. So werden Daten heutzutage nur noch sehr selten gelöscht, auch wenn der User das eigentlich verlangt (vgl. [SML07]). Je mehr Daten vorliegen, desto höher auch deren Wert und die Begehrlichkeiten Außenstehender. Des Weiteren sollten bei größeren und wertvolleren Datenbeständen, auch größere und intensivere Schutzmechanismen etabliert werden. Da diese Anstrengungen wiederum einen massiven Verwaltungsaufwand nach sich ziehen, wäre eine Automatisierung auch an dieser Stelle erstrebenswert.

19 2 Einleitung All diese Vorteile und Probleme motivierten die IT-Industrie und viele Forschungsgruppen in der Vergangenheit, die Automatisierung der DBMS voran zu treiben, welche immer weniger äußere, menschliche Einflüsse nötig macht Zielsetzung Ziel dieser Arbeit ist es, den aktuellen Stand der Technik - State of the Art - von Self-Healingund Self-Protection-Mechanismen darzulegen, welche zu den selbstverwaltenden Eigenschaften eines DBMS gehören. Im Zuge dessen werden Grundlagen des Self-Healings und der Self-Protection erläutert und es wird eine Übersicht über existierende Implementierungen in den drei am meisten etablierten DBMS gegeben. Darüber hinaus werden aktuelle Forschungsarbeiten vorgestellt, die noch nicht etablierte Ansätze von Self- Healing und Self-Protection in DBMS erforschen. Die aufgeführten Sicherheitsvorkehrungen sind den im Abschnitt 4 aufgelisteten Gefahren und Bedrohungen gegenübergestellt und es wird verglichen, inwieweit diese eliminiert oder eingedämmt werden können Gliederung Im Zuge dieser Forschungsarbeit werden Self-Healing und Self-Protection-Mechanismen aus Echtzeitsystemen und Forschungsbeiträgen untersucht. Vorausgesetzt wird für die gesamte Arbeit grundsätzliches Wissen über Tabellen und Relationen sowie über Datenbanksysteme. Dennoch sollen die wichtigsten Aspekte für das grundlegende Verständnis von Methoden und Technologien im Grundlagenkapitel 2 erläutert werden. Dazu wird auch auf die geschichtliche Entwicklung des DBMS eingegangen und revolutionäre Meilensteine, wie die von Edgar F. Codd tiefergehend erläutert. Diese sind dem fachkundigen Leser jedoch in der Regel geläufig und können bei Bedarf auch übersprungen werden. Damit die Abstammung und Einordnung der beiden selbstverwaltenden Mechanismen nachgewiesen werden kann, wird umfassend auf das Autonomic Computing sowie dessen Herkunft im Kapitel 3 eingegangen. Die Unterteilung der potentiellen Gefährdungen eines DBMS im Kapitel 4 nach Gefahren und Bedrohungen dient als Einführung für die eigentlichen Ansätze. Die beiden Hauptthemen Self-Healing- und Self-Protection werden ab Kapitel 5 nach Vorkommen in etablierten Systemen und Forschungsbeiträgen unterteilt, wobei die betreffenden Gefährdungen am Anfang jedes Kapitels genannt werden. Schlussendlich dient eine Zusammenfassung am Ende der beiden Kapitel als Resümee sowie eine sich am Ende

20 Einleitung 3 befindende Zusammenfassung aller aufgeführten Mechanismen als Fazit in dem auch ein Ausblick auf zukünftige Entwicklungen gegeben wird. Verwendete Abkürzungen, werden im Abkürzungsverzeichnis erläutert und sind in dieser Arbeit großgeschrieben abgebildet (z.b. PHP). Hervorgehobene Begriffe (Schlagwörter) werden kursiv dargestellt und Angaben zu Literaturquellen befinden sich in [eckigen Klammern]. Dem Leser unbekannte Termini, welche jedoch im weiteren Verlauf dieser Arbeit nicht wieder in Erscheinung treten, sind mit einer Fußnote gekennzeichnet und werden in der Fußzeile erläutert.

21 4 Grundlagen zu Datenbanken

22 Grundlagen zu Datenbanken 5 2. Grundlagen zu Datenbanken Dieses Kapitel dient zur Darlegung der Grundlagen von Datenbanken und dessen Verwaltungssystemen. Es werden zunächst grundlegende Begriffe erläutert und ein geschichtlicher Einblick gegeben, bevor grundlegende theoretische und technische Aspekte genannt werden Grundlegende Begriffe Die nachfolgend aufgeführten Begriffe werden in dieser Forschungsarbeit mehrfach verwendet, können auf Grund ihres häufigen Auftretens jedoch nicht wiederholt erläutert werden. Daher werden die Termini an dieser Stelle aufgegriffen und kurz erläutert, ohne jedoch umfassende und tiefgreifende Grundlagen auszubreiten. Für nähere Ausführungen sei auf das Buch [SSH10] von Saake, Sattler und Heuer verwiesen. Datenbank Eine Datenbank (DB) ist eine organisierte Sammlung von Daten (Datenbestand), welche von einem DBMS verwaltet wird und den darauf operierenden Anwendungssystemen und Benutzern verborgen bleibt. Physisch werden die Daten in einer DB, auf nichtflüchtigen Speichermedien, abgelegt. Datenbankmanagementsystem Ein Datenbankmanagementsystem (DBMS) ist die Verwaltungssoftware einer oder mehrerer Datenbanken. Es ist die zentrale Anlaufstelle, welche alle Anfragen, Änderungs- oder Einfüge-Operationen der DB bearbeitet und durchführt. Zur Übermittlung der Befehle nutzt es Datenbanksprachen, zu dessen Vertreter in relationalen Systemen SQL gehört. Das DBMS entscheidet maßgeblich über Funktionalität und Geschwindigkeit des Gesamtsystems, da es unter anderem für Verschiebungen in der Speicherhierarchie bzw. das Zwischenspeichern (puffern) verantwortlich ist. Darüber hinaus definiert das DBMS das Datenbankmodell, durch das alle Daten einheitlich beschrieben werden. Datenbanksystem Das Datenbanksystem (DBS) ist die Kombination der DB, welche als Datenbasis fungiert und des DBMS, welches das Verwaltungsprogramm darstellt. Es ist ein System zur Beschreibung,

23 6 Grundlagen zu Datenbanken Speicherung und Wiedergewinnung umfangreicher Datenmengen, das von mehreren Anwendungsprogrammen oder Anwendern benutzt wird (vgl. [S 1 [Eng00]]). Abbildung 1: Aufbau des Datenbanksystems Relationale Datenbankmanagementsysteme In dieser Forschungsarbeit wird immer wieder Relationalität als Grundlage des jeweiligen DBMS vorausgesetzt werden, da es derzeit der Industriestandard ist. Das von Edgar Frank Codd 1970 vorgestellte Relationenmodell ist das am weitesten verbreitete Modell, welches sich zudem in der Praxis etabliert hat und den erfolgreichsten DBMS zu Grunde gelegt wurde. Es werden dabei gleichartige Objekte durch n-attribute beschrieben, wobei jedes Attribut durch einen bestimmten Ausprägungstyp (ganzzahlige Zahlen, Fließkommazahlen, Zeichen, Wahrheitswerte) charakterisiert werden kann. Die sequentielle Auflistung dieser Objekte, welche durch ihre Eigenschaften (Attribute) präsentiert werden, stellt die Relation dar. Jedes einzelne Objekt in dieser Relation wird als Tupel bezeichnet. Abbildung 2: Aufbau einer Relation Wie in Abbildung 2 zu erkennen ist, kann eine Relation anschaulich als Tabelle verstanden werden, wobei Attribute als Spaltenüberschriften, die Menge aller Attributnamen als

24 Grundlagen zu Datenbanken 7 Relationenschema, eine Zeile als Tupel und der Verbund aller Tupel als Relation verstanden werden kann. SQL SQL, welches für Structured Query Language steht, ist eine Datenbanksprache für relationale DBMS und vereint vier verschiedene Typen von Datenbanksprachen in sich: Data Manipulation Language (DML), Data Definition Language (DDL), Data Control Language (DCL) und Data Query Language (DQL). Neben den genannten Möglichkeiten Daten zu verändern, definieren und abzufragen sowie Berechtigungen zu vergeben, umfasst SQL die Ausdrucksfähigkeit der Relationenalgebra 1 und zusätzliche Funktionen (min, max, sum, count usw.) zur Aggregation sowie einfache arithmetische Operationen (Addition, Subtraktion, Multiplikation und Division). Cloud Computing Cloud Computing, ein erst seit kurzem weit verbreiteter Terminus, scheint den Weg für zukünftige Computergenerationen zu weisen. Er bezeichnet eine computerbasierende Architektur, welche Software und Plattformen Service-orientiert bereitstellt, damit der informationstechnologische Aufwand und damit einhergehende Kosten innerhalb einer Firma reduziert werden können. Der Unterschied zwischen dem Cloud Computing und den standardmäßig an das Internet angeschlossenen Servern macht vor allem genau die Anforderung an die Robustheit, höchste Skalierbarkeit und äußerst leistungsfähige Infrastruktur aus. Die Cloud betitelt hierbei einen Pool von externen Computerressourcen, welche im Verbund massives Arbeitsaufkommen bewältigen können und dabei ausschließlich benötigte Ressourcen belegen. So können abhängig vom Workload virtualisierte Ressourcen hinzu- oder abgezogen werden. Damit die Ausfallsicherheit und Skalierbarkeit für jeden Kunden, egal ob Privatperson oder Konzern, gewährleistet werden kann, sind die im Hintergrund befindlichen Systeme dementsprechend komplex und pflegebedürftig. Für tiefergehende Informationen zum Cloud Computing sei auf [BKN10] verwiesen Historische Entwicklung der Datenbankmanagementsysteme Datenbanken werden bereits seit den Anfängen des Computers genutzt. Anders als moderne Systeme, welche an fast alle Anwendungen angepasst werden können, wurde die Mehrheit 1 Die Relationenalgebra bietet spezielle Operationen für Relationen, welche die Mengenalgebra nicht abdeckt.

25 8 Grundlagen zu Datenbanken der älteren Systeme jedoch mit einer systemspezifischen Datenbank eng verzahnt. Diese Verzahnung brachte große Performancesteigerungen mit sich, war aber nachteilig für Flexibilität und Portierbarkeit. Ursprünglich konnten Datenbanksysteme auch nur in großen Unternehmen gefunden werden, die sich die dementsprechende Hardware leisten konnten, um die benötigte Rechenkapazität zu nutzen. In den sechziger Jahren, als die Rechenkapazität der Computer anstieg, wurde die Abhängigkeit der DBS von Großrechnern immer geringer, weswegen immer mehr universelle DBS entwickelt wurden. Nachdem immer mehr universelle Systeme ihren Einsatz fanden, wurde der Ruf nach Vereinheitlichung immer lauter. Charles Bachman, welcher selbst Entwickler eines solchen Systems war - Integrated Data Store (IDS) -, gründete auf Grund dessen die Data Base Task Group (DBTG). Die DBTG war unter anderem für die Erschaffung und Standardisierung von COBOL 2 im Rahmen der Conference on Data System Language (CODASYL) verantwortlich. Weitere herausgegebene Standardisierungen dieser Vereinigung waren so einschneidend und wichtig für die gesamte Branche, dass dem Standard folgende DBS als CODASYL-Systeme bezeichnet wurden. Ein großer Nachteil des CODASYL- Ansatzes bestand jedoch bei der manuellen Suche. So waren alle Datensätze nacheinander verkettet und im Falle einer Selektion mussten alle Datensätze sequentiell gelesen werden. Abbildung 3 verdeutlicht die genannten Abhängigkeiten des sequenziellen Zugriffs gegenüber einem wahlfreien Zugriff. Abbildung 3: Zugriffsarten (vgl. [Wiki02]) 2 COBOL ist eine Hardware-unabhängige, standardisierte Programmiersprache, welche stark an die natürliche Sprache angelehnt ist und für die Erstellung von Programmen für betriebswirtschaftliche Bereiche gedacht ist.

26 Grundlagen zu Datenbanken 9 Der sequentielle Zugriff, welcher durch den genannten Nachteil in den meisten modernen Systemen kaum noch zur Anwendung kommt, war damals weniger dramatisch, da der wahlfreie Zugriff auf Magnetbänder ohnehin nicht realisiert werden konnte. Auf Grund dieser Verkettung wurde das DBS, wie auch alle anderen DBS nach CODASYL, dem Netzwerkdatenbankmodell zugeordnet. IBM entwickelte 1968 derweilen ein DBS namens IMS, welches für das Apollo-Programm auf dem System/360 beruhte, im Gegensatz zu CODASYL jedoch eine strikte Hierarchie für die Navigation nutze. IMS gehört folglich auch den hierarchischen Datenbankmodellen an. In den siebziger Jahren war es vor allem Dr. Edgar Frank Codd, welcher an der Entwicklung von Speichersystemen in der IBM arbeitete, der die Entwicklung der DBMS entscheidend veränderte. Auf Grund seiner Unzufriedenheit bezüglich des CODASYL-Ansatzes verfasste er einige Forschungsbeiträge, welche schlussendlich in dem Forschungspapier "A Relational Model of Data for Large Shared Data Banks" [Codd70] ihre Krönung fand und als Grundstein des relationalen Modells gilt. In Codds Forschungsarbeit steht beschrieben, wie ein damals neuerliches System große Datenbanken speichern und verwalten kann, indem es Daten in tabellarische Strukturen verlagert. Es brauchte jedoch einige Zeit bis IBM die Forschungen Codds als ernst zu nehmend einstufte und ein System beruhend auf diesem Modell entwickelte. Die erste Version von System R wurde 1975 veröffentlich wobei diese lediglich als Mono-Tabellen-Systeme ausgelegt war. Zur selben Zeit begann das Team um Eugene Wong und Michael Stonebraker ein Projekt namens INGRES, welches im Grunde eine ähnliche Mächtigkeit wie System R hatte. Bereits 1979 konnte eine Version von System R vorgestellt werden, die Multi-User-kompatibel war und in welcher die standardisierte Abfragesprache SQL implementiert wurde. Durch die unübersehbaren Vorteile des Codd'schen Ansatzes wurde IBM direkt dazu getrieben, eine kommerziell veräußerliche Version des System R am Markt zu platzieren, was durch SQL/DS (später Database 2 - DB2) auch umgesetzt wurde. Einige INGRES-Entwickler waren gegen 1980 davon überzeugt, dass auch eine kommerzielle Version von INGRES heraus gebracht werden müsse und gründeten Firmen, die sich das zur Aufgabe machten. Sybase, Informix, NonStop SQL und Ingres selbst - in der heutigen Form - entstanden auf diese Weise. Sogar Microsofts SQL Server beruht auf einer stark umgebauten

27 10 Grundlagen zu Datenbanken und verbesserten Version von INGRES, da Großteile des INGRES-Ablegers Sybase in ihre Entwicklung einflossen. Nur Larry Ellisons Oracle DBMS startete unabhängig von INGRES-Konzepten. Oracle erschuf ihr DBMS auf den Grundlagen von System R und konnte schon bei der Markteinführung dank dieser Herangehensweise IBMs DB2 in Performance-Angelegenheiten schlagen. Auch Michael Stonebraker, der ein fester Bestandteil des Teams um INGRES war, ging seine eigenen Wege und verließ das INGRES-Team. Er machte sich an eine Neuentwicklung, die heute unter dem Namen "PostgreSQL" bekannt ist. In den 1980er Jahren konnte zudem ein Anwachsen der objektorientierten Datenbanksysteme (OODBS), zusammen mit der objektorientierten Programmierung (OOP), beobachtet werden. Mit OODBS muss die Komplexität vieler Anwendungen, die durch OOP entstanden sind, nicht auf ein relationales Datenbankschema abgebildet werden, sondern kann direkt in die Datenbank übertragen werden. Jedoch haben die OODBS im Gegensatz zu relationalen Datenbanksystemen kein einheitliches Datenmodell, das allen (kommerziellen) OODBS zugrunde liegt. Die OODBS bieten Möglichkeiten wie persistente Speicherung von Objekten, Speicherstrukturen für Mengen von Objekten und wichtige Operatoren für Datenbankanwendungen (vgl. [Dit86], [Dit88], [DK89]). Darüber hinaus entstanden objektrelationale Datenbanksysteme (ORDBS), welche eine Lösung zwischen relationalen und objektorientierten DBS darstellen. So wurde in den meisten Fällen ein relationales Datenmodell um objektorientierte Methoden und Datentypen erweitert, womit anschließend auch komplex strukturierte Daten abgebildet werden konnten. Als eines der letzten Systeme, welche in dem vergangenen Jahrtausend entstand, sollen XML-DBS genannt werden, die Daten im XML-Format abspeichern können. Dabei gilt es zwischen nativen XML-DBS und herkömmlichen DBS zu unterscheiden, welche eine alternative Speicherung oder Umwandlung erlauben. Seit dem Beginn des einundzwanzigstens Jahrhunderts sind es vor allem die NoSQL- Datenbanken, welchen große Aufmerksamkeit erregen. Diese unterscheiden sich jedoch durch ihre Nicht-Relationalität von den "klassischen" Systemen. Sie benötigen nur selten ein festes Tabellen-Schema, meiden JOIN-Operationen und können selbst zusätzliche Ressourcen einholen oder abgeben (Scale-Out).

28 Grundlagen zu Datenbanken Architektur und Eigenschaften eines Datenbanksystems Nachdem auf grundlegende Begriffe und die historische Entwicklung der DBMS bzw. DBS eingegangen wurde, sollen noch grundlegende architektonische, theoretische und technische Eigenschaften aufgeführt werden Neun Anforderungen nach Codd Die in dieser Forschungsarbeit betrachteten selbstverwaltenden Eigenschaften eines DBMS setzten voraus, dass das betreffende DBMS die neun Fähigkeiten besitzt, welche der britische Wissenschaftler Edgar Frank Codd im Jahre 1982 verfasste ([Codd82]). Dr. Edgar Frank Codd war einer der Urväter aller modernen DBMS, da er sowohl das erste relationale DBMS - System R - mitentwickelte, als auch die theoretischen Grundlagen für Datenbankmanagementsysteme, durch seine neun Basis-Funktionalitäten definierte. Zu den neun Fähigkeiten eines DBMS nach [Seite 114 [Codd82]] gehören: 1. Data storage, retrieval and update - Operationen, welche das Einfügen, Löschen, Suchen und Updaten abdecken. 2. A user-accessible catalog for data description - Ein Katalog (Data Dictionary), welcher den Zugriff auf die Datenbeschreibung der Datenbank erlaubt. 3. Transaction support to ensure that all or none of a sequence of database changes are reflected in the pertinent database - Transaktionen als Zusammenschluss von Datenbankänderungen, die nur vollständig ausgeführt werden können und anschließend permanent in der Datenbank gespeichert sind. 4. Recovery services in case of failure - Die Wiederherstellung des Datenbestandes nach etwaigen Fehlern oder Systemausfällen. 5. Concurrency control services to ensure that concurent transactions behave the same way as if run in some sequential order - Die Concurrency Control regelt die Synchronisierung parallel laufender Transaktionen, die auf den selben Datenobjekte arbeiten. 6. Authorization services to ensure that all access to and manipulation of data be in accordance with specified constraints on users and programs - Die Autorisierung stellt sicher, dass Veränderungen und Zugriffe auf Datenobjekte nur im Einklang mit den für das System definierten Systemrichtlinien geschehen.

29 12 Grundlagen zu Datenbanken 7. Integration with support for data communication - Die Integration und einheitliche, redundanzfreie Bereitstellung aller abgelegten Daten. 8. Integrity service to ensure that database states and changes of state conform to specified rules - Die Integritätsüberwachung sichert die Korrektheit der Datenbankinhalte sowie deren Änderungen. 9. Views - Sichten sind als virtuelle Tabellen definiert und bestehen aus einer umfangreicheren Abfrage auf gegebenenfalls mehrere reale Tabellen. Nicht zu verwechseln sind diese neun Basis-Funktionalitäten eines DBMS mit den von Codd 1985 erklärten zwölf Codd'schen Regeln (vgl. [Codd851], [Codd852]), welche darlegen, was ein DBMS zu erfüllen hat, um als relational bezeichnet zu werden. Diese wurden darüber hinaus Anfang 1990 um eine dreizehnte (Regel-0) erweitert und später in diesem Jahr auf achtzehn Regeln ausgebaut. Viele der Regeln sind jedoch so streng, dass kein derzeitig erhältliches DBMS von sich behaupten kann, ein vollständig relationales Datenbankmanagementsystem nach Codd zu sein (vgl. [Seite 4 [Xia11]]) Architektur von Datenbankmanagementsystemen Da viele Passagen dieser Arbeit grundlegendes Wissen über DBMS und DBS voraussetzen und darauf aufbauende Mechanismen näher beschreiben, wird an dieser Stelle die Architektur eines DBS näher erläutert. Die Architektur kann laut [Seite 29 ff. [SSH10]], ausgehend von verschiedenen Aspekten, unterschiedlich betrachtet werden. Zum besseren Verständnis der selbstverwaltenden Konzepte eines DBMS im Zuge dieser Arbeit wird an dieser Stelle sowohl auf die Schema-, System- als auch auf die Anwendungsarchitektur eingegangen Schemaarchitektur Die Schemaarchitektur beschreibt den Zusammenhang zwischen dem konzeptionellen, internen und externen Schema. Sie beruht auf der 1975 vom Standards Planning and Requirements Committee (SPARC) des American National Standards Institute (ANSI) entwickelten Drei-Ebenen-Schema-Architektur und beschreibt die grundlegende Trennung verschiedener Beschreibungsebenen für Datenbanksysteme. Darunter fallen drei unterschiedliche Schemata (vgl. [Seite 29 ff. [SSH10]]): Das externe Schema charakterisiert (anwendungsspezifische) Sichten auf den Gesamtdatenbestand und verweist zumeist auf das lokalere konzeptuelle Schema.

30 Grundlagen zu Datenbanken 13 Dieses wird beispielsweise durch eine View gewährleistet, welche ihre Daten aus zwei unterschiedlichen Tabellen bezieht. Das konzeptuelle Schema ist das Ergebnis der Datenbankmodellierung, des Datenbankentwurfs und der Datendefinition. Es liefert eine anwendungsunabhängige Gesamtsicht auf den Datenbestand. Die konzeptuelle Gesamtsicht erfolgt in relationaler Darstellung. Das interne Schema realisiert die Dateiorganisation und Zugriffspfade auf physische Daten, welche durch das konzeptuelle Schema in abstrakterer Weise genutzt werden. Eine nähere Erläuterung zu den physischen Gegebenheiten findet sich Abschnitt 2.3. Abbildung 4: Drei-Ebenen-Schema-Architektur (vgl. [SSH10]) Sowohl das externe als auch das konzeptuelle Schema sind unabhängig von der jeweils darunter liegenden Schicht. Sie können somit angepasst werden, ohne dass Änderungen an weiteren Schichten vorgenommen werden müssen. Bezüglich der konzeptuellen Ebene wird von einer Implementierungsunabhängigkeit oder physischen Datenunabhängigkeit gesprochen und bei der externen Ebene von einer Anwendungsunabhängigkeit oder logischen Datenunabhängigkeit. Durch diese Unabhängigkeiten müssen sich beispielsweise Anwendungsentwickler nicht daran stören, dass Daten intern spalten- oder zeilenorientiert gespeichert werden. Daten (Anfragen und Änderungstransaktionen), die zwischen den Ebenen weiter gegeben werden, sind in einer formalen Beschreibungssprache mit festgelegter Semantik verfasst. In der Abbildung 4 sind zudem zwei Pfeile dargestellt, welche den Transformationsweg der Datenbankzustände, Anfragen und Änderungstransaktionen zwischen den verschiedenen Schemaebenen dokumentieren:

31 14 Grundlagen zu Datenbanken Die Anfragebearbeitung zeigt den Weg auf, den Anfragen und Änderungsoperationen zu bewältigen haben. Die Aufgabe besteht hierbei darin, eine extern formulierte Operation, in eine interne, auf die Datenstruktur bezogene, Operation umzuwandeln. Die Datendarstellung beschreitet diesen Weg rückwärtig, indem Ergebnisse, die in der internen Datenstruktur gefunden wurden, in die externe Darstellung überführt werden Anwendungsarchitektur Die Anwendungsarchitektur bezieht sich auf die konkreten Aufgaben, Komponenten und Schnittstellen eines Datenbanksystems bei der Verzahnung mit einer Applikation. Heutzutage liegt den meisten Datenbankanwendungen eine Client-Server-Architektur zugrunde. Die Client-Server-Architektur beschreibt dabei den Zustand, dass ein Dienstnehmer (Client), Dienste eines Dienstanbieters (Server) nutzt. Der Client selbst kann darüber hinaus eine Server-Rolle bezüglich anderer Dienste oder zur Weiterverteilung selbst abonnierter Dienste übernehmen. Das DBMS ist unter Einhaltung dieser Aspekte der Server, der Dienste (Datenbankabfragen, -änderungen und -löschungen) anfragenden Clients (Benutzern an Computern) anbietet. Die eigentlichen Funktionalitäten können jedoch variabel verteilt werden und sind von Implementierung zu Implementierung unterschiedlich. [Seite 45 ff. [SSH10]] unterscheidet drei Funktionsgruppen, die stufenlos mehr client- oder serverseitig integriert werden können: 1. Präsentation und Benutzerinteraktion 2. Anwendungslogik 3. Datenmanagementfunktionalität, einschließlich der Anfragebearbeitung und Transaktionskontrolle Neben dieser zweielementigen Client-Server-Architektur existiert auch noch eine Drei- Schicht-Architektur, bei der die Anwendungslogik in einer eigenen Schicht realisiert wird (vgl. Abbildung 5). Diese zusätzliche Instanz, die zwischen Client und Server existiert, wird Applikationsserver genannt. Real existierende Beispiele wären die auf der Java Enterprise Edition basierenden Umgebungen JBoss von Red Hat oder Apples WebOjects.

32 Grundlagen zu Datenbanken Systemarchitektur Abbildung 5: Anwendungsarchitekturen Die Systemarchitektur unterteilt das DBS in Komponenten, Bausteine, Elemente oder auch Werkzeuge und zeigt Schnittstellen sowie den Kommunikationsverlauf zwischen diesen auf. In [Seite 29 ff. [SSH10]] wurden zwei verschiedene Granularitäten einer Systemarchitektur vorgestellt. Zur klaren Abgrenzung werden Objekte der feineren Granularität als Elemente und Objekte mit gröberer Granularität als Komponenten bezeichnet. Die in Abbildung 6 aufgeführten blauen Elemente und orangenen Komponenten wurden zusammen mit den aus der SPARC-Architektur bekannten drei Ebenen übereinander gelegt, um die Zusammenhänge zu verdeutlichen (siehe Abbildung 6). Abbildung 6: Systemarchitektur (vgl. [SHS05]) Nachfolgende Komponenten können unterschieden werden:

33 16 Grundlagen zu Datenbanken Die Definitionskomponente dient zur Datenbestimmung auf der konzeptuellen Ebene, zur Definition der Dateiorganisation auf der internen Ebene und zur Sichtdefinition auf der externen Ebene. Mit der Programmierkomponente werden Datenbankoperationen, Einbettungen und Masken bereitgestellt. Die Benutzerkomponente, die auch als Übergangskomponente bezeichnet werden könnte, beinhaltet Anwendungsprogramme, die auf die Datenbank zugreifen sowie interaktive Anfrage- und Änderungswerkzeuge. Die Transformationskomponente beinhaltet Werkzeuge zur Optimierung, Auswertung und für den Plattenzugriff und wird genutzt für die Transformation der Daten von der internen zur externen Darstellung und vice versa. Das Data Dictionary ist eine zentrale Komponente des Systems, da es sämtliche Daten der Definitionskomponente aufnimmt und alle anderen Komponenten mit diesen Informationen speist Fünf-Schichten-Modell In der Drei-Ebenen-Schema-Architektur (ANSI-SPARC) sind die Transformationsschritte etwas ungenau und schemenhaft beschrieben. In dem Fünf-Schichten-Modell wird hingegen die Transformationskomponenten eines DBS detailiert erklärt. Somit muss für das Verständnis neben der globalen Beschreibung des Gesamtsystems, noch auf das Fünf- Schichten-Modell (5SM) von [Sen73] eingegangen werden, welche 1987 von [Här87] weiterentwickelt wurde. Das 5SM stellt eine detailierte Beschreibung der Transformationskomponente, der im Abschnitt beschriebenen Systemarchitektur dar, und konkretisiert die an der Transformation einer Anfrage oder Änderung teilnehmenden Elemente eines DBMS. Die Transformierung verläuft vom abstrakten konzeptuellen Schema (Datenbankmodell) bis zur physischen, internen Ebene (Speicherzugriff). Die Fünf-Schichten- Architektur ist jedoch kein normierter Standard, sondern lediglich ein Industriestandard, welcher eine vieler möglicher Sichtweisen auf das System widerspiegelt.

34 Grundlagen zu Datenbanken 17 Abbildung 7: Fünf-Schichten-Modell Abbildung 7 zeigt die einzelnen Elemente und Schnittstellen der Transformation sowie abstrakte bzw. physische Speichereinheiten (links), die in den verschiedenen Etappen genutzt werden. Alle in dieser Forschungsarbeit vorgestellten Mechanismen zum Schutz oder zur Heilung von betroffenen DBS setzen an mindestens einer dieser Elemente oder Schnittstellen an, weswegen nachfolgend auf die Objekte eines DBS eingegangen wird. Das Betriebssystem ist kein Teil eines DBS und wird deshalb im weiteren Verlauf nur oberflächlich betrachtet. Einige wichtige, der erwähnten Speicherstrukturen (Seiten, Blöcke usw.) werden im Abschnitt tiefergehende erläutert. Darüber hinausgehende, tiefgreifende Informationen zu den Elementen und Schnittstellen kann zudem aus [S 40 ff. [SHS05]] sowie [S 37 ff. [SSH10]] entnommen werden. Mengenorientierte Schnittstelle (MOS) - Die MOS stellt eine standardisierte Datenabfrage- und Datenmanipulationssprache (SQL) auf ganzen oder Teilen von Tabellen und Sichten zur Verfügung. Datensystem - Es übersetzt und optimiert SQL-Anfragen der MOS für die SOS, unter Ausnutzung der Zugriffspfade und nimmt eine Auswertung der Relationenalgebra-Operatoren

35 18 Grundlagen zu Datenbanken vor, da diese die Antwortzeiten auf eine Anfrage entscheidend beeinflussen. Zwar weist [S 53 [SHS05]] darauf hin, dass vor allem ältere Datenbanksysteme diese Schicht nicht besitzen, für diese Forschungsarbeit ist aber vor allem der neuste Stand der Technik relevant, weshalb diese Tatsache außen vor gelassen werden kann. Satzorientierte Schnittstelle (SOS) - Sie bewerkstelligt den Zugriff auf die innere Darstellung der Relation und nutzt dabei Zugriffspfade (Indexe, Scans) und typisierte Datensätze, sowie interne Relationen. Zugriffssystem - Aufgabe des Zugriffssystems ist es, die konzeptuellen Darstellungen (Relationen, Tupel) auf interne Darstellung (Seiten) abzubilden. Im Zugriffssystem selbst werden nur interne Tupel bzw. logische Datensätze betrachtet. Operationen im Zugriffssystem sind das Einfügen, Löschen, Modifizieren und Suchen von Sätzen in Scans und Indexen. Darüber hinaus übernimmt es die Sortierung und die Mehrbenutzerverwaltung von Transaktionen sowie Transformation auf die ISS. Interne Satzschnittstelle (ISS) - In der ISS werden Tupel ohne Typisierung einheitlich verwaltet. Zudem sind Speicherstrukturen der Zugriffspfade implementiert. Speichersystem - Das Speichersystem setzt die Operationen der ISS auf virtuelle Adressen des Adressraums um. Anwendungsobjekte sind in ihrer internen Speicherdarstellung sichtbar, werden jedoch nicht direkt (physisch) umgesetzt, sondern abstrakt als interne Datensätze beschrieben. Des Weiteren ist es auch für die Sperrverwaltung im Mehrbenutzerbetrieb und das Schreiben des Logbuchs zuständig. Eine Übersicht über die Bezeichnungen je Systemeben findet sich in Tabelle 1. Systemebene Datensystem Zugriffssystem Speichersystem Strukturelle Bezeichnung Tupel Internes Tupel oder logischer Datensatz Interner Datensatz Tabelle 1: Strukturelle Bezeichnungen zu Systemebenen Systempufferschnittstelle (SPS) - Sie manipuliert den virtuellen Adressraum, welcher durch Seiten und Seitenadressen realisiert wird.

36 Grundlagen zu Datenbanken 19 Pufferverwaltung - Sie bildet interne Seiten auf Blöcke der Dateischnittstelle des Betriebssystems ab und speichert Daten im Primärspeicher zwischen. Sie übernimmt die Zuteilung von Speicherplatz für Seiten und das Suchen und Ersetzen von Seiten im Zwischenspeicher (Puffer). Darüber hinaus ist sie für die Optimierung der Lastverteilung zwischen parallel laufenden Transaktionen zuständig. Die Pufferverwaltung bildet die Seiten der SPS auf Blöcke der DSS ab. Dateischnittstelle (DSS) - Die DSS realisiert Operationen auf Blöcken des externen Speichers. Dies ist jedoch Aufgabe des Betriebssystems und unabhängig vom DBMS Speicherhierarchie Um die Vorteile der selbstverwaltenden Eigenschaften eines DBMS zu verstehen, ist ein Verständnis der Speicherhierarchie eines Computers notwendig. [S 83 [SHS05]] geht davon aus, dass der Geschwindigkeitsunterschied zwischen Festplattenspeicher und Cache des Prozessors ca. das fache beträgt. Dieser Unterschied wird auch als Zugriffslücke bezeichnet. Um dieser Zugriffslücke entgegen zu wirken, macht sich das DBMS die Dreiteilung des Speichers zu nutze. Der kleinste und schnellste Speicher (Cache) lädt die gerade benötigten Daten, der Arbeitsspeicher hält die wichtigeren Daten im größeren Sinne und der Festplattenspeicher alle anderen Daten in der Datenbank bis auf die archivierten Daten, welche sich auf Magnetbändern befinden. Durch diese Abstufung der Abhängigkeiten muss bei einer fehlenden Information die Speicherinstanz im optimalen Fall lediglich auf die direkt unter ihr liegende Schicht zugreifen und hat somit einen Geschwindigkeitsvorteil der sich laut [S 83 [SHS05]] um das fache bewegt. Die Zwischenspeicherung wird zudem notwendig, da sich Primär-, Sekundär und Tertiärspeicher neben der Geschwindigkeit, auch in Größe, Preis und Vorhaltezeit unterscheiden.

37 20 Grundlagen zu Datenbanken Abbildung 8: Unterscheidung Primär-, Sekundär-, und Tertiärspeicher Tritt jedoch der ungünstigste Fall ein und eine benötigte Information ist in keiner direkt angrenzenden Speicherinstanz vorhanden, müssen die Informationen dennoch von den langsamsten Medien geladen werden Verwaltung des Hintergrundspeichers Der Hintergrundspeicher umschreibt eine physische Ablage der Daten auf einem externen Speichermedium. Zwar ist die Verwaltung des Hintergrundspeichers Aufgabe des Betriebssystems, der Vollständigkeit halber wird jedoch darauf eingegangen, da sich weiterführende Grundlagen, welche unmittelbar für das Verständnis eines DBMS benötigt werden, damit besser einordnen lassen. Vor allem dient dieses Kapitel dem Verständnis, wie abstrakte Speichereinheiten (Seiten) eines DBMS physisch abgelegt werden. Nur so kann nachvollzogen werden, weshalb beispielsweise eine wiederkehrende Defragmentierung (Wartungsarbeiten) dem System unnötige Arbeit ersparen kann. Das DBMS hat keinen Direktzugriff auf die Festplatte, sondern nutzt vom Betriebssystem angeforderte Dateien um Daten zu speichern. Eine Datei ist eine abstrakte Ordnungseinheit, welche das Betriebssystem verwaltet und über eine Transformation in kleinere, physische Einheiten (Blöcke) auf der Festplatte festschreiben kann. Das Betriebssystem übernimmt somit die Beschreibung der Magnetplattenspeicher für das DBMS, indem es Daten des DBMS in physische Blöcke auf die Festplatte schreibt.

38 Grundlagen zu Datenbanken 21 Abbildung 9: Festplattenaufbau Da die Blöcke der Festplatte jedoch relativ klein sind (512Byte), abhängig von der genutzten Formatierung des Datenträgers, müssen zusammenhängende Daten des DBMS geteilt werden. Aus diesem Grund wird eine eigens für das DBMS entworfene, abstrakte Speichereinheit (Seiten) genutzt, welche physisch vom Betriebssystem umgesetzt werden kann. Die Zuordnung der physischen Blöcke zu Seiten wird mit einem festen Faktor vorgenommen. Es werden häufig 1,2,4 oder 8 Blöcke, die auf der Festplatte hintereinander liegen und damit in einer physischen Spur sind, zu einer Seite vereinigt (siehe Abbildung 9). Das DBMS selbst adressiert die Seiten über Seitennummern. Bei der Allokation von Speicher durch das DBMS werden aufeinanderfolgende Seiten zwar auch physisch aufeinander folgend sein, jedoch werden sich durch Änderungsoperationen im Laufe der Zeit Fragmentierungen (Verstreuungen) einstellen. Eine solche Entartung von zueinander gehörenden Daten kann das System zusätzliche Zeit kosten, da der Lesekopf mehrfach die Position wechseln muss. Die vorgenommene Abbildung der internen, virtuellen Struktur auf die externe, physische Struktur ist in Tabelle 2 aufgeführt.

39 22 Grundlagen zu Datenbanken Konzeptuelle Ebene Relation Tupel Attributwert Interne Ebene Logische Datei Datensätze Felder (Records) Dateisystem/ Festplatte Physische Datei Seiten/ Blöcke Bytes Tabelle 2: Abbildung der Speicherstrukturen Zur besseren Veranschaulichung werden in Abbildung 10 die Abhängigkeiten der konzeptuellen und internen Ebene sowie des Dateisystems ausgehend von einer virtuellen Relation aufgezeigt. Abbildung 10: Darstellungen einer Relation (vgl. [SHS05]) Die darüber hinaus gehenden Blockungstechniken, welche aufzeigen mit welchen Techniken Datensätze auf mehrere Blöcke verteilt werden, sind nicht Bestandteil dieser Forschungsarbeit. Für nähere Informationen sei auf [S 99 [SHS05]] verwiesen.

40 Grundlagen zu Datenbanken Seiten, Sätze und Adressierungen Als vorletzte Grundlagendarlegung dieser Arbeit sollen Seiten, interne Datensätze und ihre Adressierung näher beleuchtet werden. Wie bereits im vorangegangenen Kapitel kurz angerissen, sind Seiten Speicherobjekte, in denen das DBMS Informationen (Tupel, Datensätze) ablegt. Seiten sind ein Zusammenschluss von zumeist 1,2,4 oder 8 Blöcke der Festplatte und das DBMS adressiert diese Seiten über Seitennummern. Nicht genutzte Seiten verwaltet die Freispeicherverwaltung des DBMS und gibt diese, sobald sie angefordert werden, frei. Zusammenhängende Seiten können als eine doppelt-verkettete Liste angesehen werden, da jede Seite einen Eintrag für Vorgänger und Nachfolger enthält. Eine Seite besteht aus einem Header, gegebenenfalls eingetragenen Datensätzen und nicht belegtem Speicherplatz. Der spezifische Aufbau des Seitenkopfes (Page-Header) variiert dabei von DBMS zu DBMS. In den meisten Fällen befinden sich dort jedoch die Angaben zur Seitennummer, die Vorgänger- und Nachfolgerseite sowie die Offset-Werte 3. Ein Offset-Wert referenziert einen Datensatz innerhalb der Seite. Wird der Datensatz verschoben, muss lediglich der Offset-Wert verändert werden. Alle von außerhalb gesetzten Referenzen verweisen nicht direkt auf den Offset-Wert, sondern auf einen Tupelidentifikator (TID). Dieser TID besteht aus einer Seitennummer und einem bestimmten Offset-Wert und wird nicht verändert. Abbildung 11: Tupelidentifikator Darüber hinaus sind die TIDs nützliche Werkzeuge für Verweise bei Veränderungen, wenn z.b. ein Datensatz von einer Seite auf eine andere verschoben werden musste. Der TID bleibt bestehen, der Offset-Wert verweist auf dieselbe Stelle, nur steht an dieser Stelle kein 3 Der Offset-Wert ist dabei gleich der Anzahl der Bytes vom Anfang des Speicherplates auf der Seite bis zum Datensatz. Er spiegelt somit die Position des Datensatzes auf der Seite wieder.

41 24 Grundlagen zu Datenbanken Datensatz mehr, sondern ein weiterer TID, welcher auf die neue Seite und den neuen Offset- Wert verweist Transaktionen Als letzte Grundlagendarlegung dieser Arbeit sollen die bereits mehrfach erwähnten Transaktionen ausgeführt werden. Transaktionen beruhen auf dem Prinzip, dass auf einer Datenbank mehrerer Benutzer, Applikationen oder andere Instanzen potentiell zur gleichen Zeit auf dieselben Daten zugreifen können. Dieses muss geregelt werden, damit anschließend keine fehlerhaften Zustände zurückgelassen werden können. Eine Transaktion vereint eine Serie von einzelnen Operationen, die die DB von einem konsistenten Zustand in einen anderen konsistenten Zustand überführen. Die Überführung muss dem ACID-Prinzip genügen, welches ein Akronym ist und sich aus den Anfangsbuchstaben der vier englisch übersetzten Eigenschaften zusammensetzt. Im Zuge dieser Arbeit werden zwar die vier Eigenschaften genannt und kurz erläutert, jedoch ist das Gebiet der Transaktionsverwaltung weitaus umfangreicher und kann in dieser Forschungsarbeit nur angeschnitten werden. Für tiefergreifende Informationen wird auf [S 22 ff. [SHS05]] verwiesen. Das ACID-Prinzip setzt sich zusammen aus nachfolgenden Eigenschaften: Atomicity (Atomarität) - Die Ununterbrechbarkeit einer Transaktion, spiegelt den Fakt wider, dass eine Transaktion vollkommen oder überhaupt nicht ausgeführt werden darf. Es existieren demnach keine Zwischenzustände, welche eventuell inkonsistent sein könnten. Consistency (Konsistenz) - Die Integritätserhaltung sorgt dafür, dass eine Transaktion das System aus einem konsistenten Zustand nur in einen konsistenten Zustand überführen kann. Isolation - Auch wenn mehrere Transaktionen gleichzeitig ablaufen und deren Schritte ineinander verzahnt sind, muss der Ergebnis einer Transaktion gleich dem Ergebnis sein, als wären alle Transaktionen sequenziell abgelaufen. Durability (Dauerhaftigkeit) - Einmal beendete Transaktionen sind dauerhaft in die Datenbank festgeschrieben. Zwei wichtige Gegebenheiten, die im Zuge der Transaktionen jedoch noch erwähnt werden müssen, sind Sperren (Locks) und Deadlocks. Zur Realisierung des gemeinsamen Zugriffs auf Datenobjekte werden Sperren verwendet, welche eine Exklusivität gegenüber anderen

42 Grundlagen zu Datenbanken 25 zugreifenden Instanzen sicherstellen. Wird somit eine Sperre von einer Transaktion auf ein Objekt gesetzt, kann eine andere Transaktion bis zur Aufhebung der Sperre nicht auf das Objekt zugreifen. Es gilt im Groben, Lese- und Schreibsperren zu unterscheiden. Für weitere Informationen wird auf [S 576 [SHS05]] verwiesen. Deadlocks sind Verklemmungen, welche entstehen, wenn zwei oder mehrere unterschiedliche Transaktionen zwei oder mehrere unterschiedliche Objekte sperren und vor der Endsperrung auf das jeweils bereits gesperrte Objekt der anderen Transaktion zugreifen möchten. In diesem Fall wartet der eine auf den anderen und dieser Umstand muss vom System erkannt und aufgelöst werden Marktanalyse derzeitiger Datenbanksysteme Wie bereits in den frühen siebziger Jahren des letzten Jahrhunderts, sind auch heutzutage viele Hersteller von DBMS am Markt vertreten. Aus diesem Grund spezialisieren sich viele Anbieter auf bestimmte Teilbereiche oder fokussieren einzelne Nischen viel stärker als andere Marktteilnehmer. So wurde mit dem SQL Server 2012 der Columnstore Index 4 eingeführt, um das Produkt im Segment Data Warehouse noch interessanter zu machen (vgl. [BF11]). Oracle erweiterte Oracle Database 11g Release 2 ausschließlich auf Oracle Linux und Oracle Solaris um den Oracle Database Smart Flash Cache 5, damit deren Marktposition im RDBMS unterstützt wird. Andere RDBMS wie Teradata konzentrieren sich fast ausschließlich auf das Data Warehousing und stimmen sämtliche Neuentwicklungen auf den typischen Workload eines solchen ab. Die genaue Bezifferung aller derzeit existierenden DBMS variiert zwischen 54 lt. [FTB12] und 100 lt. [Wiki01] und ist abhängig vom Blickwinkel des Betrachtenden sowie strengen oder weniger strengen Merkmalen, die beschreiben was genau ein DBMS ausmacht und ab wann es eigentlich nicht mehr so genannt werden dürfte. Diese Arbeit hält sich an die 4 Der Columnstore Index speichert die im Index angegebenen Spalten separat auf eigenen Seiten gespeichert. Benötigt eine Anfrage nun spezielle Werte aus einer Spalte, können aus dem Index heraus gezielt die Spaltenseiten geladen werden. 5 Mit dem Oracle Database Smart Flash Cache lässt sich der Pufferspeicher durch einen Flash-Speicher erweitert. Somit kann mit einem größeren Second Level Cache gearbeitet werden, was lese-intensive Datenbankapplikationen unterstützt.

43 26 Grundlagen zu Datenbanken Definition nach Codd, welche im Abschnitt vorgestellt wurde und bezeichnet ein DBMS als genau solches, wenn es die neun Codd'schen Regeln erfüllt. Zu den wohl bekanntesten DBMS gehören der SQL Server von Microsoft, Oracles Oracle Database und IBMs DB2, welche bereits im Abschnitt 2.2 einführend erläutert wurden. Diese drei Datenbanksysteme decken zusammen mehr als 80% des Marktes ab (vgl. [DBR11], [MW11]). In Segmenten wie Business Intelligence (BI) und Corporate Performance Management (CPM) halten sie lt. [DBR11] zusammen eine Zweidrittelmehrheit. Allein Oracle deckte in einer Erhebung (siehe Tabelle 3) aus ,4% des Marktes ab. Diese Marktdominanz konnten sie bis in das Jahr 2011 noch weiter ausbauen, indem sie laut [DBR11] im dritten Quartal ,1% des Marktes beherrschten und sich erst unlängst damit brüsteten, dass sie mehr Marktanteile hätten, als ihre fünf größten Verfolger zusammen (vgl. [Orac01]). Neben diesen drei großen kommerziellen DBMS, sollen noch SAP MaxDB der deutschen Softwareschmiede SAP) sowie Terradata und deren gleichnamiges DBMS genannt werden, welche zusammen die Top 5 der DBMS-Anbieter bilden und in Tabelle 3 orange hinterlegt sind. Tabelle 3 zeigt zudem den prozentualen Anteil der Top 10-Systeme am Gesamt-Umsatz des Jahres 2009 je Betriebssystem ("Worldwide RDBMS 2009 Vendor Analysis: Top 10 Vendor License Revenue by Operating Environment") auf.

44 Total Software Revenue Maintenance Total Licence Revenue Other Server Systems Mainframe Systems Other Entry Systems Linux/ Open Source Systems Windows NT Unix Company Grundlagen zu Datenbanken 27 Oracle Corp. 51,9 22,9 63,8-0,1 2,4 31,8 57,0 43,4 IBM 19,6 13,1 16,7 10,7 90,3 46,3 25,9 15,1 20,9 Microsoft - 55, ,3 14,0 20,6 Sybase (SAP) 7,3 1,8 2,2 30, ,7 3,8 3,2 Teradata 12,4 0,3 6, ,7 2,5 3,1 Fujitsu 1,8 0,9 0,4-1,4-1,0 1,4 1,2 Progress Software 1,6 0,7 0, ,4 0,7 1,1 0,9 Netezza ,6 0,9 0,2 0,6 SAS Institute 0,3 0,3 0,0-2,2 0,3 0,5 0,4 0,5 Hitachi 0,6 0,2 0,2-0,8-0,4 0,3 0,3 Other 4,6 4,2 9,5 58,6 5,0 28,0 6,2 4,0 5,2 Total Tabelle 3: Top 10-DBMS-Anbieter 2009 (vgl. [IDC09]) Neben den kommerziellen Systemen existieren jedoch auch kostenfreie Systeme, welche auch als Open-Source-Systeme bezeichnet werden. Zu deren bekanntesten Vertretern gehören MySQL und PostgreSQL. Eine relativ aussagekräftige Markteinschätzung gab Jelastic, die eine gleichnamige auf Java basierende Entwicklungsumgebung für die Cloud entwickeln, am 19. Oktober 2011 heraus. Sie befragten fünftausend Programmierer ihrer Plattform, welches Open-Source-System sie benutzen würden, wobei MySQL als eindeutiger Gewinner hervorging.

45 28 Grundlagen zu Datenbanken DBMS-Bezug in dieser Arbeit Im Zuge dieser Forschungsarbeit werden die DBMS der drei Branchenriesen Oracle, Microsoft und IBM untersucht und für Vergleiche herangezogen, da deren Position und Präsenz allüberschattend und maßgebend ist. Auch wenn angemerkt werden muss, das viele Impulse und Neuerungen von Open-Source-Systemen kommen. Darüber hinaus sind auf Grund der niedrigeren hierarchischen Ebenen und der demokratischen Struktur der Open- Source-Systeme, die Anpassbarkeit und Variabilität weitaus größer.

46 Grundlagen zu Self-Healing und Self-Protection Grundlagen zu Self-Healing und Self-Protection In diesem zweiten Grundlagenkapitel wird die Herkunft und Entstehung von Self-Healingund Self-Protection-Mechanismen aufgezeigt. Dazu wird das Autonomic Computing als Ursprung identifiziert und es wird eine Abgrenzung gegenüber anderen Wissenschaftsbereichen vorgenommen. Abschließend soll in diesem Kapitel explizit auf die beiden Mechanismen eigegangen werden Einordnung in das Autonomic Computing "Was man heute als Science Fiction beginnt, wird man morgen vielleicht als Reportage zu Ende schreiben müssen." Norman Mailer In fast jedem der heutzutage auf dem Markt befindlichen DBMS (siehe [Wiki01], [FTB12]) werden Funktionen wie Management des flüchtigen Speichers, Festspeichermanagement sowie Backup und Recovery vom System selbst durchgeführt. Zudem werden heutige Systeme nur noch selten heruntergefahren und können neue Hardware dynamisch integrieren, ohne dass es Applikationen in irgendeiner Art beeinflusst. So bietet der SQL Server 2008 beispielsweise ein "Hot-add CPU"-Feature an, welches es ermöglicht, dem System während des Betriebes zusätzliche CPUs hinzuzufügen. Vor nicht allzu langer Zeit mussten jede Art der Konfigurationen oder Systemanpassung noch von den DBAs selbst durchgeführt werden oder zumindest initial eingestellt werden, damit das System lauffähig wurde. Außerdem waren die Wahrung der dauerhaften Betriebsfähigkeit und der daraus resultierende Bedarf in kritischen Situationen zu jeder Uhrzeit Unterstützung beziehen zu können, wichtige Aspekte. All diese administrativen Aufgaben sind nicht nur äußerst zeitaufwendig, sondern erforderten auch ein großes Wissen über das System selbst sowie viel Erfahrung im Umgang mit DBS. Um diesen Umstand zu beseitigen, sollten die Systeme mit Fähigkeiten ausgestattet werden, die eine allumfassende Selbstverwaltung erlauben. Unter anderem aus diesen Überlegungen heraus entstand eine Initiative, welche autonom arbeitende Computer (Autonomic Computing) etablieren wollte. In fast allen sich darauf beziehenden Publikationen wird genau diese Initiative als Ursprung der Idee eines autonom arbeitenden Computersystems gesehen (vgl. [KC03], [GC03], [CPW03]).

47 30 Grundlagen zu Self-Healing und Self-Protection Jedoch erwähnen nur einige wenige Forscher, dass bereits in den achtziger und neunziger Jahren des vergangenen Jahrhunderts verschiedene Konzepte eines Computer-Immunsystems beschrieben wurden. Eine der ersten Analogien zwischen Sicherheitsproblemen eines Computers und biologischen Abwehrmechanismen stammt aus dem Jahre 1987 von Cohen (siehe [Coh87]), der in seinem wissenschaftlichen Beitrag das Verhalten von Computerviren und geeigneten Antikörper erforschte. Aufgrund der unzureichenden Rechenkapazität entwickelte er damals jedoch keine "extrem komplexen und/ oder ressourcenintensiven Techniken" (vgl. [Coh87]), sondern beschränkte sich hauptsächlich auf die Isolation der betroffenen Komponenten. [FHS96] bemerkten 1996 in ihrem Forschungsbeitrag zur Computer-Immunologie, dass bei keiner der damalig aktuellen Methoden ein Erfolg zu erkennen sei, die selbstschützenden und selbstheilenden Mechanismen eines Immunsystems nachzuempfinden. Jedoch betonen die Forscher, dass aufgrund der Ähnlichkeit zwischen lebenden Organismen und einem Computersystem, Verbesserungen der Sicherheit und des Schutzes der Computer, der Natur abgeschaut werden könnten. Sie wiesen sogar direkt darauf hin, dass Computer- Immunsysteme, welche mit grundlegenden Eigenschaften des natürlichen Immunsystems ausgestattet sind, einen bis dato unerreichten Grad an Schutz bieten könnten. Des Weiteren verfassten [SHF98] 1998 die Grundsätze eines Computer-Immunsystems. Auch sie bemerkten, dass das natürliche Immunsystem reichlich Inspirationen zur Verbesserung der Computersicherheit bieten. Zudem identifizierten sie einige Eigenschaften, welche für einen Computer wünschenswert sind, der sich in einer unkontrollierten, offenen und uneingeschränkten Umgebung befindet. Zu diesen Eigenschaften gehören unter anderem Vielfältigkeit, Verfügbarkeit, Anpassungsfähigkeit, Eigenständigkeit, Selbst-Schutz, Anomalie-Erkennung, Vielschichtigkeit und Fehlererkennung. Außerdem merkten sie an, dass Computer-Systeme, die dem Nervensystem nachempfunden sind, autonom, anpassbar, dynamisch, dauerhaft aktiv und mannigfaltig sein müssen. Keiner der damalig aktiven Forscher verfasste jedoch einen Beitrag, der ein System vorstellte, welches die benötigten Eigenschaften besitzt. Dies war erst der Fall, als die bereits genannte AC-Bewegung aktiv wurde. Autonomic Computing bezeichnet Systeme, welche ihre Arbeit mit einer möglichst großen Unabhängigkeit von menschlichen Eingriffen durchführen. Die Autonomic Computing- Bewegung wurde, wie bereits erwähnt, inspiriert durch biologische Systeme und das

48 Grundlagen zu Self-Healing und Self-Protection 31 autonome Nervensystem. So steuert das Nervensystem beispielsweise die eigenen Körperfunktionen ohne äußere Unterstützung und kontrolliert kontinuierlich sämtliche körpereigene Parameter. In der Informatik wurden die ersten Formulierungen zum Autonomic Computing von Jeffrey O. Kephart in Zusammenarbeit mit David M. Chess niedergeschrieben (siehe [S [KC03]]), welche im Auftrag von IBM an Systemen forschten, die die Selbstverwaltung der administrativen Aufgaben übernehmen sollten. Sie hielten fest, dass das Autonomic Computing die Lasten der Verwaltung und der Einflussnahme durch externe Kräfte zu minimieren hat und Komplexität des darunterliegenden Systems vor dem Nutzer verborgen werden soll (vgl. [S 2 [PD10]]). In Folge dessen bestehen AC-Systeme aus Segmenten, die in einer Schleife angeordnet sind, welche dauerhaft die Parameter des Systems in einem bestimmten Bereich halten sollen (vgl. [IBM01]). Der geschlossene Kreislauf benutzt Sensoren (Sensor) bzw. Schnittstellen die Änderungen von externen Komponenten entgegen nehmen (Effector), um das System nach Informationen zu untersuchen (Monitor), die auf einen Zustand hinweisen, welcher analysiert werden soll (Analyze). Die Analyse der Informationen könnte wiederum eine Anpassung des Systems nötig machen, welche geplant (Plan) und durchgeführt (Execute) werden muss. Der gesamte Ablauf ist reglementiert von diversen Regelwerken, Variablen und Strategien (Policy), die vom Initiator des Systems festgelegt wurden (vgl. [IBM01]). Abbildung 12: Autonomic Computing-Loop (vgl. [IBM01])

49 32 Grundlagen zu Self-Healing und Self-Protection Dieser geschlossene Kreislauf (siehe Abbildung 12) stellt sicher, dass das System möglichst viele Informationen sammelt und Parameter abfragt, um sich selbst zu konfigurieren, Probleme zu adaptieren und aus fehlerhaften Zuständen eigenständig zu gesunden. Der Gesamterfolg basiert somit massiv auf einem lückenlosen und umfassenden Wissen des eigenen Zustandes (Self-Awareness) und der Umgebungsvariablen (Context-Awareness). Zudem muss dieses Wissen von ausreichend vielen Sensoren oder als Feedback aus externen Quellen erzeugt bzw. gesammelt werden. Abbildung 13 verdeutlicht diese beiden Abhängigkeiten nochmals und zeigt überdies, dass ein wechselseitiger Datenaustausch (Data- Flow) Grundvoraussetzung ist. Abbildung 13: Autonomic Computing-Abhängigkeiten Aus den genannten Erwägungen entstanden auch die acht Eigenschaften nach dem Autonomic Computing-Manifest (siehe [S [IBM02]) von IBM: Ein Autonomic Computing-System sollte......über den eigenen Zustand umfassend informiert sein (self-aware)....sich selbst konfigurieren (self-reconfigure)....sich selbst optimieren (self-optimizing)....sich selbst heilen (self-healing)....sich selbst schützen (Self-Protection)....sich bewusst sein, in welcher Umgebung und in welchem Kontext es agiert (selfadapting bzw. context-aware)....mit anderen Systemen kommunizieren (open, embedded and interoperable)....autonom und einfach arbeiten (autonomous and simple).

50 Grundlagen zu Self-Healing und Self-Protection 33 Einige andere Autoren setzen an dieser Stelle auf härtere Standards und akzeptieren lediglich die ersten sechs nativen Self-Eigenschaften (vgl. [RMS10]). Bei beiden Ansätzen bedingen sich jedoch einige Eigenschaften und so kristallisierten sich vier Basiseigenschaften nach der Vision von IBM heraus. Diese werden als die vier grundlegenden Self-Eigenschaften des Autonomic Computing (engl. "the four basic self-* properties of AC") bezeichnet und werden auch mit ihrer englischen Übersetzung im Deutschen verwendet (siehe Abbildung 14). Abbildung 14: Bestandteile des Autonomic Computings (vgl. [IBM01]) Es gibt zudem fünf Stufen des AC in dem sich die Autonomie aufsteigend ausgeprägt hat: Basic, Managed, Predictive, Adaptive und Autonomic (vgl. [IBM01]). Das Hauptanliegen der AC-Technologie ist jede Komponente möglichst eigenständig, mit Rücksicht auf externe Einflüsse und externes Verhalten, agieren zu lassen. Besonders zu betonen ist, dass diese Mechanismen zwar unabhängig betrachtet werden können, so auch in dieser Arbeit das Self-Healing und Self-Protection, jedoch agieren sie zumeist als Einheit oder sind zumindest voneinander abhängig. So liegt bei einer Attacke anfänglich die Initiative bei der Self-Protection. Sollte der Mechanismus nicht erfolgreich sein, sollte sich das System dank des Self-Healings rehabilitieren können (vgl. [S 1 [MRM11]]). Die Self-Configuration-Fähigkeiten müssen dabei die minimale Beeinträchtigung des Benutzers sicher stellen, so dass er davon im optimistischsten Fall nicht einmal Notiz nimmt. Durch die Self-Optimization wird sicher gestellt, dass das System eine optimale Performance hat. Schlussendlich ist die Self-Protection wiederum dafür zuständig, den aufgetretenen Fehler zu adaptieren und kommende Ereignisse dieser Art vorläufig zu erkennen und davor zu schützen.

51 34 Grundlagen zu Self-Healing und Self-Protection Trotz des Erstrebens und all dieser Ansätze ist das derzeitig implementierte, autonome Verhalten von Datenbanksystemen noch lange kein unabhängiges Verhalten (vgl. [S 2 [MP05]]). Die Systeme werden von Menschen betrieben und sind auch heutzutage nicht vollkommen unabhängig lauffähig. Der menschliche Faktor, vor allem die menschliche Fehleranfälligkeit, spielt hier noch immer eine wichtige Rolle. So ist davon auszugehen, dass in einem System, welches auch nur teilweise menschlichen Einflüssen ausgesetzt ist, die meisten Fehler von genau diesen Einwirkung rühren. Wobei zu betonen ist, dass auch bei einem Systemadministrator mit dem umfänglichsten Systemwissen stets mit Fehlern gerechnet werden kann, welche von der unüberschaubaren Komplexität des Systems verursacht werden. Die Systeme auf Grund dessen weitergehend zu automatisieren, ist die wohl erstrebenswerteste Lösung Abgrenzung und Gemeinsamkeiten mit anderen Wissenschaftsbereichen Die in dieser Arbeit betrachtenden Mechanismen des Self-Healings, wie auch der Self- Protections treten in sehr vielen Gebieten der Forschung und des täglichen Lebens auf. So beschreiben [CL96] die erhöhte Gewaltbereitschaft der Südamerikaner, wenn es um deren Selbstschutz (Self-Protection) geht, und sei es nur für ihre kulturelle Integrität. [PBS81] zeigen in ihrer Studie, inwiefern Unterricht in Self-Protection (Selbstverteidigung) Kindern dabei hilft, sich vor Entführungen zu schützen. Wohin gegen [LZ04] darlegen, welchen Einfluss Self-Protection-Maßnahmen vor Terroranschlägen auf den Versicherungsmarkt haben, seitdem am 11. September 2001 der weltbekannte Terroranschlag auf New York verübt wurde. [Hea90] belegt, dass Risse an Kanten von tektonischen Platten durch selbstheilende Impulse (Self-Healing Pulses) der nachrutschenden Erdmassen ausgelöst werden und [KSW03] offenbaren, welch großartige Eigenschaften sich selbst verschließende (Self-Healing) fiberglas-verstärkte Polymer-Matrix-Verbundwerkstoffe haben. Das Vorkommen eines solch grob gefassten Wortes wie Selbstschutz oder Selbstheilung ist erdenklich groß, wobei sie in der englischen Sprache wahrscheinlich noch weitaus häufiger benutzt werden, da die Begriffe - Self-Healing und Self-Protection - dort weitläufiger gefasst sind. Dieses kann an den deutschen Übersetzungen Selbstschutz, Selbstsicherung und Selbstverteidigung für das englische Wort Self-Protection verdeutlicht werden. Unter den genannten deutschen Entsprechungen sind bereits bei kurzer Betrachtung Unterschiede im Sinngehalt zu erkennen.

52 Grundlagen zu Self-Healing und Self-Protection 35 In dieser Arbeit wird Self-Protection im Sinne der Maßnahmen gebraucht, die dazu führen, sich bedrohlichen Situationen gar nicht erst auszusetzen oder einen gegenwärtigen Angriff abzuwenden. Selbstheilung wird verwendet, im Sinne einer von außen nicht gesteuerten, systemintern durchgeführten Gesundung des Systemzustandes, mit dem Ziel, den Ausgangszustandes wiederherzustellen. Aufgrund der Wortursprünge und der dem Menschen eigenen Vorstellung, dass das "Ich" die zentrale Instanz (Ich-Bezug) sei, ist davon auszugehen, dass ein besonders großer Anteil der Forschung in dem Gebiet des Autonomic Computing, somit auch Self-Healing und Self- Protection, von der Biologie bzw. dem vegetativen Nervensystem (auch Autonomen Nervensystem) inspiriert wurde. Zu unterscheiden ist das vegetative Nervensystem, das unberührt vom menschlichen Willen seinen Dienst verrichtet und das somatische Nervensystem, welches für die bewusste Aufnahme von Informationen über die Sinnesorgane zuständig ist. Durch das vegetative Nervensystem werden alle wichtigen Funktionen im System kontrolliert und koordiniert. Dazu gehören Atmung, Blutdruck, Herzschlag, Stoffwechsel, Drüsensekretion, Körpertemperatur, Fortpflanzung und Verdauung, sowie andere Organe und Organsysteme. Es ist das zentrale Kommunikationssystem für den Informationsaustausch zwischen den einzelnen Organen des Körpers (vgl. [S [BS06]]). Um die Ähnlichkeiten der auf der einen Seite technisch und der anderen Seite biologisch arbeitenden Systeme zu verdeutlichen, sollen die unmittelbaren als auch längerfristigen Auswirkungen eines Ausdauersport betreibenden Menschen, mit einem zeitweilig stark erhöhten Arbeitsaufkommen eines DBMS, welches über Autonomic Computing- Mechanismen verfügt, gegenübergestellt werden:

53 36 Grundlagen zu Self-Healing und Self-Protection Autonomes Nervensystem Anstieg des Herzzeitvolumens und der Muskeldurchblutung Atmung und Durchblutung wird ökonomischer und kräftiger Blutdruck wird langfristig gesenkt und Ruhepuls verringert Herzmuskel wird langfristig vergrößert Antikörper und Schutz vor Infekten wird erhöht Heilung von Muskelkater und diversen Blessuren Autonomic Computing in DBMS Optimale Verteilung und Auslastung des Systems System "merkt" sich aufgetretene Lastspitzen und Probleme, zudem werden Verbesserungen vom System adaptiert System entdeckt unter Last Optimierungspotential, welches sonst nicht in Erscheinung getreten wäre Effizienteste Methoden zur Bewältigung werden zukünftig vorrangig verwendet Auftretende Probleme werden gespeichert und die "Immunität" diesbezüglich verstärkt System regeneriert sich selbst von etwaigen Schäden Tabelle 4: Gegenüberstellung der technischen und biologischen Systeme Heute und in naher Zukunft werden der menschliche Körper und die Natur die besten Strategien für den Ausbau des Autonomic Computing liefern (vgl. [HTML1]). Dieser Umstand ist der Tatsache geschuldet, dass es mit neuen Technologien auch immer wieder neue Problemstellungen zu entdecken gilt. [S 4 [SB03]] gibt seiner Zuversicht Ausdruck, indem er die Hoffnung äußert, dass die Anpassungsfähigkeit des menschlichen Körpers in ferner Zukunft einmal vollkommen von Computern adaptiert werden kann Herkunft und Einordnung des Self-Healings "Es gibt 1000 Krankheiten, aber nur eine Gesundheit." Arthur Schopenhauer Forschungen zu Self-Healing im technischen Sinne bzw. sich selbst heilenden Systemen sind nicht nur ein integraler Bestandteil des Autonomic Computing, sondern auch als eine Art autonom agierendes Systeme (Autonomously Behaving System) anzusehen, obwohl diese Systeme zumeist in der Robotik entwickelt werden (vgl. [S 1 [HK01]]). Ferner gibt es diverse Kontroversen darüber, wo genau das Self-Healing anzuordnen sei oder ob und wie es in anderen Self-Strategien enthalten ist. So argumentieren [ST09], dass Self-Healing einen elementaren Bestandteil des Self-Adapting darstellt, welcher als Verbund von diagnostischen und instandsetzungs-technischen Methoden angesehen werden kann, die zur systemeigenen Genesung dienen. [KC03] hingegen bezeichnen das Self-Healing als eine eigenständige Maximierung der Systemfunktionalität bezüglich der Zuverlässigkeit, Verfügbarkeit,

54 Grundlagen zu Self-Healing und Self-Protection 37 Wartbarkeit und Überlebensfähigkeit. Die Wissenschaftsbereiche und Systeme, welche die Self-Healing-Systeme in ihrer Entstehung beeinflusst und geprägt haben, sind in Abbildung 15 abgebildet und werden nachfolgend tiefergreifend erläutert. Abbildung 15: Herkunft Self-Healing Systems Das Self-Healing hat seinen technischen Ursprung in der Forschung zu fehlertoleranten Regelsystemen und Self-Stabilizing Systems (vgl. [S 3 ff. [PD10]]. Die fehlertoleranten Regelsysteme sind technische Systeme, welche aufgetretene, flüchtige Fehler verbergen und ihre Funktion fortlaufend erfüllen, indem sie nach einer Fehlerdiagnose die Regeln an den aktuellen Fehlerzustand des Systems anpassen. Die fehlertoleranten Regelsysteme entstammen der Regelungstechnik, welche bereits 300 v. Chr. von Griechen und Ägyptern angewendet wurde, um beispielsweise Wasserkanäle, kombinierte Saug- und Druckpumpen sowie Schwimmschalter zu errichten. Traditionell wird auch nicht davon ausgegangen, dass ein fehlertolerantes Regelsystem bis in alle Ewigkeit lauffähig bleibt. So kann beispielsweise kein fehlertolerantes Regelsystemen aufrecht erhalten werden, wenn es in einem außerhalb der Fehlertoleranz liegenden Status startet oder von einem Eindringling tiefergehend manipuliert wird. Self-Stabilizing Systeme unterscheiden sich von den fehlertoleranten Systemen insofern, dass ein nicht korrekter Zustand des Systems durchaus im Bereich des Möglichen liegt und keinesfalls kaschiert wird (vgl. [S 3 ff. [Dij74]]). Vielmehr noch steht dahinter die Intention, einen korrekten Status des Systems in einer endlichen Anzahl von Schritten zu erreichen. Auch [AG93] beschreiben in ihrem Forschungsbeitrag die Self-Stabilizing Systeme als Einheiten, die einen zulässigen Status in einer endlichen Zeit, unabhängig von jeglichen Interferenzen, garantieren. Dieses erlauben sie aber nur mit dem Zusatz, dass wenn das System sich erst einmal in einer zulässigen Konstellation befinden, es diese nicht wieder verlässt.

55 38 Grundlagen zu Self-Healing und Self-Protection Somit ist festzuhalten, dass fehlertoleranten Regelsystemen und Self-Stabilizing Systems zwar auf einer ähnlichen Basis beruhen, sich jedoch im Detail unterscheiden. Eine weiterhin sehr oft anzutreffende Meinung ist, dass Survivable Systeme gleichzusetzen seien mit Self-Healing-Systemen (vgl. [S 4 ff. [PD10]]). Jedoch können auch Survivable Systeme eindeutig von Self-Healing-Systemen oder gar von Fehlertoleranten Systemen unterschieden werden. So ist ein häufig weit verbreitete falsche Vorstellung, dass eine einfache Integration von fehlertoleranten Mechanismen wie Replikationsstrategien, kryptographische Elemente oder Stabilisationstechniken aus dem Byzantine Quorum System (siehe [MR98]) einem Survivable System genügen (vgl. [S 2 ff. [Zho08]]). Dieses entspricht jedoch nicht der Wahrheit, da die Modelle des fehlertoleranten Systems auf einer Wahrscheinlichkeitsverteilung der anzutreffenden Fehler beruhen. Attacken von Eindringlingen, die Worst-Case-Szenarien ausnutzen, sind aber außerhalb dieser Fehlerschranken statuiert (vgl. [S 1 [Zho08]]). Des Weiteren liegen die Anforderungen an Survivable Systeme weitaus höher, da auch Attacken, die auf die Überlastung des Systems abzielen (DoS), unterbunden werden müssen. Diese finden in fehlertoleranten Systemen hingegen überhaupt keine Beachtung. Die Survivable Systems fallen zwar auch unter die fehlertoleranten Systeme, lassen sich aber von den Self-Healing Systemen abgrenzen, da die Wiederherstellung der Daten (Recovery) bei den Survivable Systems keinerlei Bedeutung zukommt. Survivable Systems entgegnen schadenbringendes Verhalten, indem die betroffenen Komponenten so lange isoliert werden, während die minimale Funktionsfähigkeit des Systems geschützt und gewahrt bleibt, bis die Komponenten wieder einwandfrei funktionieren (vgl. [S 1 [Mer03]]). Komplettiert wird dieser Vergleich mit der Akzentuierung der These, dass Self-Healing Systeme als Spezialisierung der fehlertoleranten Systeme gesehen werden können, mit dem Verweis auf [S 2180 [GSR06]], der diese Ansicht ebenfalls teilt. Bevor auf die Self-Healing-Systeme selbst eigegangen wird, soll ein Auszug aus [S 2164 [GSR06]] zitieren werden, welcher das Verlangen nach einem solchen System Ausdruck verleiht: "... ein Self-Healing-System sollte sich eigenständig von einem anormalen (oder ungesunden) Status heilen und zurück zu einem gesunden Zustand genesen, als wäre dieser Fehler nie aufgetreten."

56 Grundlagen zu Self-Healing und Self-Protection 39 Dieser Ausschnitt legt sehr gut dar, dass beim Self-Healing ein besonderes Augenmerk dem "Heilen" bzw. dem Wiedererlangen eines gesunden Zustandes (Recovery) gilt. So ist der dem Angriff oder Fehlverhalten folgende Zeitraum, die Wirkungsphase des Self-Healings. Aktuelle Implementierungen setzen in dieser Phase vor allem auf das Abtrennen bzw. Offline- Setzten und die anschließende Reparatur der betroffenen Komponente (vgl. [Orac02]). So implementierte Oracle in ihrer neusten Version des Oracle Solaris 10-Betriebssystems einen Fault Manager (Störungsmanager), welcher fortlaufend Daten zu aufgetretenen Softwareund Hardwarefehlern analysiert, den Ursprung identifiziert und anschließend die betreffenden Komponenten vom System abkapselt bzw. offline setzt. Die Aufgabe erledigen Methoden zur Stabilisierung, Sicherung und Isolation. Anschließend kommen Strategien zum Einsatz, die den aufgetretene Fehler reparieren und vor zukünftigen Fehlern dieser Art schützen. [GSR06] unterstreichen in ihrer Arbeit die Wichtigkeit des Wiederherstellungsvorgangs insoweit, dass sie das Self-Healing als Recovery Oriented Computing bezeichnen. Dieses scheint auch der Auslöser dafür zu sein, weshalb einige Forscher das Self-Healing als ein erweitertes Recovery Modell ansehen (vgl. [S 62 ff. [CBF04]]). Bis 2002 war sogar die allgemeine Definition des Self-Healings nicht vereinheitlicht und abhängig vom Ansatz der Forschung und Standpunkt des Forschers (vgl. [S 65 [CBF04]]). So bezeichnete [Ste05] noch 2005 das Autonomic Computing vor allem als evolutionären, bereits geebneten Weg, bei einem System die Funktionsfähigkeit dauerhaft durch Recovery zu gewährleisten. [GC03] belegen 2003 in ihrem IBM System Journal-Beitrag, dass eines der vier Features (Merkmale; Bestandteile) des Autonomic Computing das Self-Healing sei, wobei Self-Healing die Fähigkeit beschreibt, Störungen aufzuspüren und fehlerhaften Komponenten zu isolieren. Die Komponente wird durch das System selbst abgekapselt und repariert, um sie anschließend wieder zu rehabilitieren, ohne dass das System je vom Netz genommen werden musste. Aus heutiger Sicht, soll ein System welches über Self-Healing-Mechanismen verfügt hauptsächlich eine ununterbrochene Verfügbarkeit bzw. einen dauerhaften intakten Betriebszustand gewährleisten. Der dauerhafte Fortbestand beschreibt den Umstand, dass sichergestellt wird, dass eine Resistenz gegen beabsichtigte, notwendige Adaptierung und unbeabsichtigtes, willkürliches Verhalten besteht. Self-Healing-Implementierungen arbeiten, indem sie Störungen erkennen, den Fehlerursprung diagnostizieren und sich strategisch wiederherstellen. Dieses lehnt sich an das Autonomic Computing und ist nur möglich, wenn die Sensoren ausreichend viele und gute Informationen

57 40 Grundlagen zu Self-Healing und Self-Protection über das System liefern. Hinzu kommt, dass sie einen gewissen Spielraum für eigenständig zu treffende Entscheidungen haben. So können sie, da sie wiederherstellungsorientiert arbeiten, selbständig entscheiden, wie sie zu einem voll funktionsfähigen Zustand zurückkehren. Schlussendlich lässt sich die Wechselwirkung wiederum auf einen Kreislauf zurückführen, welcher vom bereits vorgestellten IBM-Modell entnommen und durch [KC03] auf drei Schritte dezimiert wurde. Abbildung 16: Self-Healing-Kreislauf (vgl. [PD10]) Wie auch beim Autonomic Computing ist das System auf Informationen (Samples) angewiesen, welche von den Sensoren aufgenommen werden. Anschließend werden Auffälligkeiten (Degradation) erkannt (Detecting) und weiter behandelt. Die gefundenen Anomalien untersucht das System anschließend weiter (Diagnosing) und versucht den Ursprung des aufgetretenen Fehlers zu finden. Schlussendlich plant es weiterführende Schritte um eigenständig zu gesunden (Recovering). Die Anpassungen (Adaptation) werden dann nur noch an die jeweiligen Komponenten (Actuator) weitergeben, um das System auf die neuen Einstellungen anzupassen und etwaige negative Begleiterscheinungen zu verhindern.

58 Grundlagen zu Self-Healing und Self-Protection Herkunft und Einordnung der Self-Protection "Im engeren Sinne, bezeichnet die Self-Protection alle genutzten Mechanismen und Techniken, die den Zugriff von ausführbaren Programmen auf gespeicherte Informationen regulieren und kontrollieren." Jerome H. Saltzer (siehe [Sal75]) Der Systemschutz (Protection) ist ein sehr wichtiges und zumeist firmenkritisches Anliegen. In den vergangenen Jahren oblag jedoch die Installation, wie auch die fortlaufende Überprüfung, beim DBA und beruhte somit auf menschlichen Fähig- und Fertigkeiten. In den meisten Fällen existierten zwar unterstützende Mechanismen und Systeme, jedoch lag die Verwaltungshoheit beim DBA. Er war dafür zuständig, aufgetretene Fehler einzuordnen und entsprechend zu behandeln, d.h. sowohl die Wiederherstellung (Recovery) als auch die Verhinderung des zukünftigen Auftretens (z.b. Kaskadierung der Fehler) sicher zu stellen ([S 2 [HS06]]). Somit gilt das Augenmerk vor allem der Prävention und der Abwendung misslicher Situationen, weshalb die Wirkungsphase der Self-Protection vor oder während eines Angriffs oder Fehlverhaltens einzuordnen ist und sich somit abgrenzt von der des Self- Healings, welche dem Angriff folgt. Wie bereits im Kapitel 3.1 erläutert, bilden Self-Healing und Self-Protection (zusammen mit den anderen Self-Eigenschaften) keinesfalls konkurrierende Prozesse, sondern sind sich ergänzende Maßnahmen zum Wohle des Gesamtsystems. Aus diesem Grund ist in vielen Fällen ein Übergang fließend und kaum scharf abgrenzbar. Die Wissenschaftsbereiche und andere Systeme, welche die Self-Protection in ihrer Entstehung beeinflusst und geprägt haben, sind in Abbildung 17 aufgeführt. Die Herkunft wird zudem anschließend tiefergreifend erläutert. Abbildung 17: Herkunft Self-Protection Systems

59 42 Grundlagen zu Self-Healing und Self-Protection Mit der Self-Protection, welche, wie im Abschnitt 3.1 aufgeführt, dem Autonomic Computing entstammt bzw. angelehnt an das autonome Nervensystem ist, hat das System die Möglichkeit sich selbst gegen bösartige Attacken zu verteidigen bzw. kaskadierende Fehler zu erkennen. Die Forschung an Self-Protection-Systemen besteht erst seit ungefähr zehn Jahren (vgl. [S 1 [KC03]]) und befindet sich immer noch in der Entwicklung [vgl. [S 1 [DCL06]]). Self- Protection kann ganz allgemein vor zwei Arten von Fehlern schützen. Es behütet das System als Ganzes gegen umfangreiche, in Beziehung stehende Probleme, welche beispielsweise von mutwilligen Attacken rühren und vor Fehlern oder Fehlzuständen, welche von Sensoren aufgenommen oder über diverse Schnittstellen dem System übergeben werden. In jedem Fall kann es Gegenschritte einleiten, um solche Fehler auch zukünftig zu vermeiden oder geeignete Gegenmaßnahmen aufzubauen (vgl. [S 2[KC03]]). In einem DBMS gilt es, Datenobjekte zu schützen, wobei zwar bekannt sein darf, dass ein Datenobjekt existiert, aber die interne Struktur oder die enthaltenen Daten dürfen von außen nicht zugreifbar sein (vgl. [S 2 [Sal75]]). Self-Protection benutzt zudem frühwarnende Mechanismen um sich zeitnah anzupassen und vor wiederkehrenden Systemfehlern zu schützen. Keinen Schutz bietet das System gegen Fehler, welche außerhalb der festgelegten Messwerte liegen und daher nicht erkannt und korrigiert werden können. Die Notwendigkeit des Selbstschutzes soll am Beispiel der ubiquitär arbeitenden Computersysteme vertieft werden, welche besonders intensive Anforderungen an die Self- Protection stellen. So tauschen heterogene Systeme eines stark verteilten (ubiquitäres) Systems Interaktionen spontan und über alle Grenzen hinweg miteinander aus (vgl. [S 2 ff. [GGK01]]). Zusammengefasst werden solche Systeme unter dem Begriff des Ubiquitären Computings, welcher die Allgegenwärtigkeit von Informationstechnik in Alltagsgegenständen beschreibt (vgl. [Tab09]). Praktisch gesehen sind dies zumeist kleinste, miteinander über Funk kommunizierende Mikroprozessorsysteme, die in Hard- und Software von Gegenständen des täglichen Gebrauchs eingebettet sind. Beruhend auf der verteilten Situation und der Autonomie der einzelnen am Ubiquitären Computing teilnehmenden Systeme (Entitäten) besitzt das Gesamtsystem keine globale Kontrollautorität und somit existiert auch kein allgemeiner Schutz für das Gesamtsystem. Somit muss jede Entität selbst einen Schutz für etwaige Missbräuche ausbilden (Self- Protection), um sich vor fremden bzw. externen Gefahren zu schützen (vgl. [S 3 ff. [ETN05]]).

60 Grundlagen zu Self-Healing und Self-Protection 43 [SB92] beschreiben die Self-Protection in ihren Anfängen als den Aufwand eines Systems, die Wahrscheinlichkeit zu verringern, an Ausfällen zu leiden. [Pic03] sieht die Self-Protection als einen Mechanismus, der als ein internes Warn- und Regulierungssystem fungiert, ähnlich der menschlichen Selbsteinschätzung und das eigene System von schädlichen Handlungen abhält. Diese These unterstützen auch [DMS08], welche in ihrer Arbeit die Ansicht von [Pic03] teilen und der Self-Protection eine besondere Gewichtung bei dem Schutz gegenüber bösartigen Attacken sowie fehlgehendem Verhalten des Systems zusprechen. Zur Herkunft der Self-Protection merken [ETN05] an, dass das Trust Management der Urvater der Self-Protection ist, wobei die Funktionen der Self-Protection, die des Trust Managements übersteigen. Bevor auf die Herkunft der Self-Protection und somit auf das Trust Management eingegangen wird, soll noch darauf hingewiesen werden, dass [GS01] bereits 2001 das Trust Management detailiert untersucht haben und in ihrer Studie bemängeln, dass schon die Definition von Trust (Vertrauen) sowie das dazugehörige Managementkonzept, sich in den damals existierenden Systemen sehr unterscheiden und stark abhängig vom Anwendungsfall sind. Wie die Self-Protection größtenteils dem Trust Management entstammt, entstammt dieses wiederum dem Gebiet der Informationssicherheit, welches sich vor allem mit informationsverarbeitenden und -speichernden Systemen befasst. Solche Systeme sollen vor allem die Vertraulichkeit, Verfügbarkeit und Integrität der gespeicherten Daten sicherstellen. Außerdem dient die Informationssicherheit dem Schutz vor Bedrohungen, der Vermeidung und Verminderung von Schäden sowie der Minimierung von Risiken. Ein Teil der Informationssicherheit, welcher auch im Trust Management bzw. bei Self-Protection- Systemen zum Einsatz kommt, ist die Kryptographie. In dieser Arbeit wird das Trust Management nach [BFL96] verstanden, als eine vereinheitliche Herangehensweise, um Sicherheitsrichtlinien (Policies), -berechtigungen (Credentials), und -beziehungen zu spezifizieren und zu interpretieren, welche eine direkte Autorisierung von sicherheitsrelevanten Aktionen erlauben. Es kann auch vereinfacht ausgedrückt werden durch die Aussage, dass das Trust Management die Validierung, Bereitstellung und Verwaltung von Zertifikaten und Sicherheitsmechanismen mehrerer an einem Datenaustausch teilnehmenden Systemen durchführt. Die dafür definierten Standards

61 44 Grundlagen zu Self-Healing und Self-Protection sind systemweit einheitlich und für alle Systeme maßgebend. Ein Trust Management kann sowohl als eigenständiger Server (Trust Management System) als auch durch einem Trust Management-Dienst realisiert werden. Durch seinen maßgebenden Beitrag zur sicheren Kommunikation war es in der Vergangenheit auch von besonderem Interesse in hinreichend vielen Publikationen und Forschungsprojekten sowie begehrt bei diversen größeren Soft- und Hardware-Produzenten (vgl. [S 2 ff. [GS03]]). Der Unterschied zur Self-Protection liegt nun darin, dass das Trust Managements lediglich die Ergebnisse bzw. den Endzustand der letzten Transaktion unter Berücksichtigung aller Richtlinien validieren und auswerten kann, um damit bessere Entscheidungskriterien für kommende Transaktionen zu entwickeln. Es ist aber nicht in der Lage, das System zu überwachen und auch während der Ausführung, also unmittelbar nach dem Auftreten eines Angriffes, einzuschreiten. Durch diesen einseitigen Schutzmechanismus bietet das Trust Management keine wirkliche Sicherheit, indem es beispielsweise die Ressourcen vor bösartigen Veränderungen bewahrt, sondern es ist viel mehr die Absicht implementiert, das in den Transaktionen versteckte Risiko zu verringern. Es fehlt dem Trust Management- Paradigma an unmittelbarer Kontrolle, denn wurde eine Transaktion erst einmal ausgeführt, ist der angerichtete Schaden nicht mehr reversibel. Zudem haben sich Fehler, die dem System in unverdächtigen Transaktionen nicht aufgefallen sind, im System etabliert. Allen zukünftigen Transaktionen mit Fehlern dieser Art wird vertraut und sie werden weiterhin ausgeführt, da sie sich wie erwartet verhalten. Erst nach einer bestimmten Zeit und erst nachdem das System diese Transaktionen als Verursacher entlarvt hat, wird das Vertrauen in eine solche Transaktion gesenkt. Das hat mit der Arbeitsweise des Trust Managements zu tun, welches erst nach der Abarbeitung einer Transaktion das Ergebnis (Outcome) evaluiert und die Transaktion bestraft, indem das Vertrauen in die jeweilige Transaktion verringert wird. Festzuhalten ist aber nochmals, dass das System zukünftig noch einmal mit einer als bösartig oder verseucht angesehenen Transaktion arbeitet ist zwar unwahrscheinlich, die initiale Ausführung kann dem System dennoch bereits geschadet haben. Wie bereits erwähnt, setzt an dieser Stelle der Self-Protection-Mechanismus an, denn anstatt ausschließlich das schlussendliche Ergebnis zu evaluieren, überwacht (Monitoring) das System den Zustand auch während der Ausführung, um unmittelbar nach dem Auftreten von Anzeichen böswilligen Verhaltens in der Lage zu sein, sich selbst zu schützen. Hier schlagen [ETN05] eine Schutzvorrichtung (Safeguard) vor, welche eine Art Korrekturplan

62 Grundlagen zu Self-Healing und Self-Protection 45 implementiert hat. Im schlimmsten anzunehmenden Fall müsste das System eine vorzeitige Beendigung der Transaktion durchführen, um den zu erwartenden Schaden abzuwenden.

63 46 Bedrohungen und Gefahren für Datenbankmanagementsysteme

64 Bedrohungen und Gefahren für Datenbankmanagementsysteme Bedrohungen und Gefahren für Datenbankmanagementsysteme "Hackers Are Not the Biggest Threat to Data: Employees are." J. Mallery Die in diesem Kapitel aufgeführten Bedrohungen und Gefahren werden im weiteren Verlauf dieser Arbeit den vorgestellten Self-Healing- und Self-Protection-Mechanismen aus Echtzeitsystemen und Forschungsbeiträgen gegenübergestellt und es wird aufgezeigt, inwieweit diese eliminiert werden können. Bevor jedoch die eigentlichen Bedrohungen und Gefahren genannt werden, soll eine Einführung sowie eine Beschreibung der Angriffsebenen und eine Gegenüberstellung von Zugriff und Autorisierungsstatus je Angriffsebenen aufgeführt werden. Nicht erst seit dem am durchgeführten Angriff auf die estländische Gesellschaft, an dem Banken, Unternehmen und Behörden tagelang kaum oder gar nicht mehr arbeiten konnten, wird Internetkriminalität eine sehr hohe Beachtung geschenkt. So richtete die Nato bereits 2004 das Nato Computer Incident Response Capability s Technical Center (NCIRC) ein, welches speziell für die Erkennung und Abwehr von sicherheitsrelevanten, ITbasierenden Angriffen gegründet wurde. Auch die Bundeswehr besitzt eine solche spezielle Fachgruppe für IT-Sicherheit namens Computer Emergency Response Team (CERT). Viele Wissenschaftler sprechen, wenn sie von derartigen Bedrohungen reden, von Cyber Attacks, Network Attacks oder Cyber Crime. Falls ganze Nationen oder größere Teile eines Landes in solche Machenschaften verwickelt sind, wird auch der Terminus Cyber War verwendet. Als computerbasierter Angriff wird die Ausnutzung einer Schwachstelle in den meisten Fällen in der Software oder im Betriebssystem des Computersystems verstanden, um Aktionen auszuführen, welche dem Systemnutzer nur selten bekannt und sehr oft schädlich sind. An das Internet angebundene Computer sind ständig mit solchen Angriffen konfrontiert, da diese vorwiegend von infizierten Rechnern ausgehen, ohne dass der Besitzer davon etwas ahnt (vgl. [VS00]). Da die verschiedenen Attacken und Angriffspunkte abhängig von der Art und Verwendung des Systems sind sowie auf Umständen der jeweiligen Situation beruhen, soll an dieser Stelle nur auf Attacken eingegangen werden, welche speziell für DBMS kritisch sein können. Datenbanken sind besonders interessante und oft gewählte Angriffspunkte, da sie eine ganze Sammlung von hochsensiblen Daten enthalten. Für Angreifer, die genau daran

65 48 Bedrohungen und Gefahren für Datenbankmanagementsysteme großes Interesse hegen, sind die Daten in einer Datenbank vergleichbar mit Geld, welches in einer Bank lagert und dieses wird bekanntlich auch besonders stark geschützt und überwacht. Auch die derzeit allumfassende Auslagerung von Daten und Applikationen in die Cloud, um Ausgaben für Computer-Equipment und Personal zu optimieren, bringt zusätzliche Brisanz in das Thema. Ein Angriff auf Datenbanken kann auf vier unterschiedlichen Ebenen geschehen (vgl. [S 2 [Liu04]]): Prozessor-Ebene Betriebssystem-Ebene Datenbankmanagement-Ebene Transaktions- oder Applikations-Ebene Personen, die bereits im System angemeldet sind, tendieren dazu, die Transaktions- bzw. Applikations-Ebene zu attackieren und Angreifer, die sich außerhalb befinden, attackieren bevorzugt die anderen drei Ebenen. Was nicht bedeutet, dass es externen Angreifern nicht auch gelingt, die Transaktions- bzw. Applikations-Ebene attackieren zu können. Angriffe auf diese Ebene können durch eine Vielzahl an Wegen realisiert werden. So berichtete das Open Web Application Security Project (OWAP) in ihrer letzten Untersuchung zu den zehn größten Sicherheitsrisiken für Webapplikationen (siehe [OWASP10]) aus 2010, dass es drei - Injection, Cross-Site Scripting (XSS) und Insufficient Transport Layer Protection - der zehn Gefahren, es einem Angreifer direkt ermöglichen, bösartige Transaktionen an das darunter liegende DBMS zu senden (vgl. [S 3 [BS06]]). [CK96] belegt hingegen, dass die meisten Angriffe von Insidern durchgeführt werden, unabhängig davon, ob die schädliche Einflussnahme (Angriff) beabsichtigt und zufällig ausgelöst wurde. Aus diesem Grund wird in dieser Arbeit auch grundlegend zwischen zwei Systemtypen unterschieden: Der erste Typ versucht die Datenbank vor externen Angriffen zu schützen, damit ein Angreifer nicht in das System gelangen kann. Ein DBMS, welches diesen Systemanforderungen entspricht, wird als Trusted Database (vertrauenswürdige Datenbank) bezeichnet.

66 Bedrohungen und Gefahren für Datenbankmanagementsysteme 49 Der zweite Ansatz geht davon aus, dass Angreifer bereits Zugriff auf das System haben und der Schaden minimiert oder stark eingeschränkt werden soll. An dieser Stelle wird das Verhalten einer Instanz, die Aktionen auf dem DBMS ausführt, zur Evaluation genutzt. Die Systeme, die mit solchen Methoden arbeiten, werden als Intrusion-Tolerant Databases oder Survivable Databases bezeichnet. Diese teilen sich wiederrum in einige Phasen auf, wie z.b. Intrusion Detection, Abschätzung des Schadens, Reparatur und Fehlerbehandlung (vgl. [Liu04]). Des Weiteren soll der Zugriff und der Autorisierungsstatus auf die vier Angriffs-Ebenen abgebildet werden. Eine erste grobe Einteilung ist nachfolgend aufgelistet, welche jedoch anschließend noch fein-granulierter vorgenommen wird: Zugriff Autorisierungsstatus Angriffsebene Direktzugriff Nicht autorisiert Alle vier Ebenen Direktzugriff Autorisiert Vorranging Transaktionsebene Keinen Direktzugriff Autorisiert Prozessor-, Betriebssystem-, Datenbankmanagement- Ebene Tabelle 5: Gegenüberstellung von Zugriff, Autorisierungsstatus und Angriffsebene Darüber hinaus soll unterschieden werden, ob das System mutwillig beeinträchtigt wird oder ob eine Störung unbeabsichtigt bzw. ohne erkennbare Ursache auftritt. Mutwillige Einflüsse werden aus diesem Grund als Bedrohungen und unbeabsichtigte bzw. zufällige Ereignisse als Gefahren klassifiziert. Die zehn größten oder häufigsten Bedrohungen eines DBS werden nachfolgend absteigend aufgelistet und beruhen auf einer Veröffentlichung (siehe [Imp07]) der imperva Inc.: 1. Excessive Privilege Abuse (EPA) - Die durch EPAs entstandenen Sicherheitslücken beruhen auf zu großzügig vergebenen Systemrechten durch Administratoren. Beispiel: Eine Mitarbeiterin des Personalwesens, welche lediglich die Adresstabelle pflegen soll, wurde für die gesamte Personaldatenbank freigeschalten und kann somit auch die Lohntabellen verändern.

67 50 Bedrohungen und Gefahren für Datenbankmanagementsysteme 2. Legitimate Privilege Abuse (LPA) - Bei dem LPA werden Zugriffsrechte missbraucht, welche für Programme oder Software vergeben wurden, falls die eigenen Rechte unzureichend sind. Beispiel: Eine Mitarbeiterin des Personalwesens, welche lediglich die Adresstabelle pflegen soll, benutzt den Vollzugriff von Excel und dessen Importfunktion, um die gesamten Daten der Lohndatenbank auszulesen. 3. Privilege Elevation (PE) - Ein Angreifer nutzt anfällige Funktionen oder Prozeduren des Systems aus, damit er umfassendere Rechten erlangen kann. Beispiel: Eine Mitarbeiterin des Personalwesens, welche lediglich Schreibrechte auf die Adresstabelle und einige Funktionen hat, kann durch eine fehlerhafte Funktion, Rechte eines Administrators erlangen. 4. Platform Vulnerabilities (PV) - Es werden Schwachstellen unterliegender Softwareschichten ausgenutzt, damit das System attackiert oder infiltriert werden kann. Beispiel: Ein Angreifer nutzt Sicherheitslücken des Betriebssystems aus und erlangt Vollzugriff, mit dem er die Festplatten formatieren kann. 5. SQL Injection (SQLI) - Bei dieser Attacke werden die vom Benutzer einzugebenden Parameter einer Anfrage so verändert, dass die daraus entstehende Datenbankabfrage mehr Rechte oder Informationen offenlegt, als eigentlich vorgesehen war (vgl. [S 1 [ASB10]]). Beispiel: In das Passworteingabefeld eines Webservers wird statt des Passwortes der String '" or 1=1' eingetragen. Das an den Datenbankserver gesendete Statement würde somit immer wahr werden und Daten freigeben ('SELECT user FROM table WHERE password="" or 1=1'). 6. Weak Audit Trail (WAT) - Die Unzureichende Auditierung verringert die Qualität der Erkennung sowie Nachvollziehbarkeit während oder nach Angriffen. Beispiel: Eine Mitarbeiterin des Personalwesens verändert diverse Gehälter von Angestellten, da jedoch keine Audit-Maßnahmen implementiert waren, bleibt dieses monatelang unentdeckt. 7. Denial of Service (DoS) - Bei DoS-Angriffen wird das System überlastet oder mit defekten Aufrufen konfrontiert, anschließend stellt es die Arbeit ein. Anfragen an den Server bleiben unbeantwortet oder werden abgewiesen. Ein bekannter Vertreter dieser Art ist der Buffer Overflow-Angriff (siehe [KBO05]).

68 Bedrohungen und Gefahren für Datenbankmanagementsysteme 51 Beispiel: Ein Angreifer nutzt den unrechtmäßig erlangten Zugriff auf einige tausend Computer, um gleichzeitig Anfragen an einen Server zu senden. Der Server ist für dieses Aufkommen jedoch nicht dimensioniert und wird überlastet. Normale Anfragen an den Server werden nicht mehr oder stark verzögert bearbeitet. 8. Database Communication Protocol Vulnerabilities (DCPV) - Angreifer nutzen Schwächen bei Protokollen aus, welche zur Übertragung von Daten zwischen Server und Client genutzt werden. Beispiel: Ein Angreifer nutzt ein Programm, welches TCP-Pakete abfängt und eine Bearbeitung dieser zulässt, bevor diese an den Empfänger weitergeleitet werden. 9. Weak Authentication (WA) - Der Angreifer erlangt die Login-Informationen durch das Testen der häufig genutzten Passwörter (Brute Force), indem er die Daten von Nutzer selbst erlangt oder Passwortdateien stiehlt. Beispiel: Der Angreifer versendet eine in der er den Systemadministrator zur Password Verifikation auffordert. Das Formular wurde jedoch vom Angreifer manipuliert und so erhält er die Daten. 10. Backup Data Exposure (BDE) - Anstatt die Datenbank direkt auszuspähen, versuchen die Angreifer die zumeist vollkommen ungeschützten Backups zu erlangen. Bespiel: Anstatt die Datenbank zu attackieren, kopiert sich der Angreifer ein Backup und spielt dieses auf einen vom ihm administrierbaren Server ein. Neben diesen zehn Bedrohungen, die durch beabsichtige Fremdeinwirkungen von Angreifern auf das System Einfluss nehmen, existieren jedoch auch Gefahren, die durch unbeabsichtigtes Handeln systemnaher Personen (z.b. Mitarbeiter) oder aber auf keinerlei Einwirkungen zurückzuführen sind. Aus diesem Grund soll neben den zehn zuvor genannten Bedrohungen nachfolgend noch auf fünf Gefahren eingegangen werden: 1. Internal Hardware Failure (IHF) - Auf Grund des zeitlichen Verfalls eines jeden physischen Bauteils, kann es zu vorhersehbaren oder unvorhersehbaren Ausfällen von Systemhardware kommen. Beispiel: Ein CPU des Servers fällt aus unvorhersehbaren Gründen aus. 2. Internal System Failure (ISF) - Das DBMS selbst ist nicht frei von Fehlern, kann falsch konfiguriert sein, sich festfahren oder durch unberücksichtigte Umstände einen fehlerhaften Zustand annehmen. Dazu gehören auch Fehler, welche das System nur

69 52 Bedrohungen und Gefahren für Datenbankmanagementsysteme indirekt produziert, wie z.b. Deadlocks oder veraltete Statistiken. Ausgeschlossen sind aber Fehler, welche durch defekte Hardware verursacht werden. Beispiel: Das System kommt ins Stocken aufgrund von fehlender Deadlock- Behandlung. 3. External Software Failure (ESoF) - Jedes existierende Programm entstand direkt oder indirekt (Generative Programmierung) aus menschlicher Hand oder ist zumindest von ihr beeinflusst worden und wie bereits mehrfach erwähnt, sind Menschen nicht fehlerfrei. Somit kann trotz umfänglicher Softwaretests nicht von einer Fehlerfreiheit gesprochen werden. Beispiel: Bei der Programmierung einer Applikation wurde ein Fehler im Code fabriziert, aufgrund dessen im Sekundentakt Anfragen an das DBMS gesendet werden und das DBMS an dessen Belastungsgrenze bringen. 4. External System Failure (ESyF) - Jedes System ist abhängig von diversen fremdbestimmten Faktoren, welche außerhalb des eigentlichen Systems liegen, jedoch den Systemstatus empfindlich beeinflussen können. Diese Faktoren können sowohl die Hardware als auch die angebundene Software betreffen. Beispiel: Die Putzfrau entfernt fälschlicher Weise das Netzwerkkabel oder Stromkabel des Servers. 5. User Error (UE) - Fehler, welche trotz richtiger Rechte und Systembestimmungen, aufgrund fehlerhafter Bedienung oder Unwissenheit des Benutzers generiert werden. Beispiel: Ein Benutzer löscht unbeabsichtigt eine ganze Tabelle, da die Verwaltungsmaske nicht eindeutig ist.

70 Ansätze des Self-Healings Ansätze des Self-Healings In diesem Kapitel werden die erarbeiteten Sicherheitsvorkehrungen aus Echtzeitsystemen oder Forschungsbeiträgen den im Kapitel 4 aufgeführten Bedrohungen und Gefahren gegenübergestellt und es wird aufgezeigt, inwieweit diese eliminiert werden können Mechanismen in konventionellen Systemen In diesem Abschnitt werden Mechanismen der drei verbreitetsten DBMS aufgezeigt, welche im weitesten Sinne dem Self-Healing zugeordnet werden können. Es wird zum Anfang jedes Abschnittes Bezug genommen, vor welchen Bedrohungen und Gefahren der jeweilige Mechanismus schützt (vgl. Kapitel 4). Damit die Beiträge einem spezifischen System zugeordnet werden können, wird vor jedem Inhaltsblock das betreffende DBMS genannt Self-Healing während einer Database Mirroring Session Der nachfolgend aufgeführte Self-Healing-Mechanismus stellt Seiten wieder her, welche auf Grund eines External System Failure (ESyF) bei der Übertragung über das Netzwerk fehlerhaft werden können. SQL Server - Während des Betriebes zweier SQL Server 2008R2-Datenbanken, die redundante Daten durch Spiegelung beherbergen, kann einer der Partner einen Fehlercode erhalten, welcher eine defekte Seite (Corrupt Page) impliziert. Der Partner mit der defekten Seite setzt anschließend ein Gesuch (Request) ab, die Seite nochmalig empfangen zu wollen. Falls die Seite fehlerfrei übertragen wird, ersetzt die Kopie das Original und der aufgetreten Fehlercode erlischt. Die automatische Seiteninstandsetzung beachtet jedoch nur Seiten, die in der Suspect-Pages-Liste die Fehlernummer 823, 824 oder 829 ausweisen (vgl. [MS01]). Den gleichen Mechanismus nutzen auch Hochverfügbarkeitsgruppen - AlwaysOn Availability Groups - von SQL Server-Datenbanken untereinander, die im neuerscheinenden SQL Server 2012 konfiguriert werden können und aus mehreren Datenbanken bestehen, um fehlerfreie Replikate einer anderen SQL Server-Datenbankgruppe vorhalten zu können (vgl. [MS02]) Self-Healing durch Wartungsarbeiten Der nachfolgend aufgeführte Self-Healing-Mechanismus beinhaltet wiederkehrende Aufgaben, die erforderlich sind, um sicherzustellen, dass die Datenbank optimiert ist,

71 54 Ansätze des Self-Healings regelmäßig gesichert wurde, keine fehlerhaften Zustände auftreten und dass sie keine Inkonsistenzen aufweist (vgl. [MS04]). Die Wartungspläne schützen vor allem vor zufällig auftretenden Gefahren (Internal Hardware Failure (IHF); Internal System Failure (ISF); User Error (UE)). Mit ihm können aber auch Bedrohungen (Excessive Privilege Abuse (EPA); Legitimate Privilege Abuse (LPA); Privilege Elevation (PE); Weak Audit Trail (WAT)) eliminiert werden. Oracle Database - Oracle 11g bietet an, Wartungsarbeiten (Jobs) über eine Manager (Scheduler) auszuführen. Dieser Scheduler wurde bereits in der Version 10g eingeführt, wobei der Vorgänger (DBMS-JOB) schon weitaus länger im System integriert war. Der Scheduler in Oracle 11g ist ein weitaus mächtigeres Werkzeug als deren Gegenüber im SQL Server oder in DB2. So können multiple Zeitfenster angegeben werden, in denen Wartungsarbeiten vom System selbst durchgeführt werden. Anders als die anderen beiden Branchenriesen werden die Statistiksammlung und die Reorganisation fragmentierter Tabellen vollautomatisch vom System übernommen, weshalb kein Job erstellt werden muss. Darüber hinaus können interne und externe Skripts (Betriebssystem-Skripte) sowie Skripte die auf externen Oracle Scheduler Agenten laufen, ausgeführt werden (vgl. [Orac04]). Der Agent ist nach der Initialisierung durch den Server für die Ausführung und weitere Kommunikation mit dem Server zuständig. SQL Server - Der SQL Server 2008R2 bietet unter anderem die Möglichkeit über einen Wartungsplanungs-Assistenten Pläne zu erstellen und zu bearbeiten. Mit dem Assistenten ist es sowohl möglich aus einer Liste ausgewählte, systemtypische Wartungsarbeiten zu wählen, als auch eigene Skripts per TSQL zu programmieren und einzubinden. Es kann so ein Service-Paket erstellt werden, welches zyklisch vom SQL Server Agent ausgeführt werden kann. Der SQL Server-Agent ist ein Microsoft Windows-Dienst, der geplante administrative Tasks ausführt, die im SQL Server-Umfeld als Aufträge bezeichnet werden (vgl. [MS05]). Durch die Möglichkeit sämtliche Überprüfungen und Vergleiche in diese Skripts integrieren zu können, automatisiert sich der Vorgang nach der Erstkonfiguration fast vollständig. Nur Fehler oder Fehlzustände die in dem Skript nicht berücksichtigt werden konnten oder bei denen es versäumt wurde, können je nach Konfiguration einer zuständigen Stelle zugesendet werden und ein Fehlerprotokoll erzeugen. Es können mit dem Wartungsplanungs-Assistenten des SQL Servers beispielsweise:

72 Ansätze des Self-Healings 55 Daten auf den Daten- und Indexseiten neu organisiert werden, die logische und physische Integrität aller Datenbankobjekte überprüft und ggf. repariert werden, Datendateien durch Entfernen leerer Datenbankseiten komprimiert werden, Statistiken erneuert werden oder Datenbank und Transaktionsprotokolldateien gesichert werden (vgl. [MS06]). DB2 - IBMs Automatic Maintenance-Konzept hat vergleichbare Fähigkeiten, um Datenbankverwaltungsaktivitäten zu automatisieren, damit diese nur bei Bedarf ausgeführt werden. So können auch Datenbanksicherungen, Datendefragmentierungen und Reorganisationen von Tabellen oder Indizes sowie Datenzugriffsoptimierungen zyklisch festgelegt werden (vgl. [Orac03]). Zur Verwaltung oder Erstellung der Automatic Maintanace Jobs kann der Assistent Automatische Verwaltung konfigurieren genutzt werden Self-Repair durch Automatic Failover Der nachfolgend aufgeführte Self-Healing-Mechanismus sorgt für die Rehabilitierung der Funktionsfähigkeit eines Servers, welcher sowohl zufällig (Internal Hardware Failure (IHF); Internal System Failure (ISF); User Error (UE)), als auch durch mutwillige Absichten (Platform Vulnerabilities (PV); Denial of Service (DoS); Database Communication Protocol Vulnerabilities (DCPV)) beeinträchtigt werden kann. SQL Server - Ein automatisches Failover wird nur in Datenbank-Spiegelungssitzungen unterstützt, die in einem Zeugen-Modus ausgeführt werden. Der Zeugen-Modus birgt sehr hohe Sicherheit, da er einen zusätzlichen Server als Zeugen verwendet, welcher bei Systemausfall einspringt (automatisches Failover). Im Zeugen-Modus wird nach dem Synchronisieren der Datenbank ein automatisches Failover ausgeführt, wenn die Prinzipaldatenbank ausfällt. Bei einem automatischen Failover übernimmt der Spiegelserver die Rolle des Prinzipalservers und schaltet die eigene Datenbankkopie als Prinzipaldatenbank online. Aufgrund der Voraussetzung, dass die Datenbank synchronisiert sein muss, werden Datenverluste während des Failovers verhindert, da jede erfolgreich abgeschlossene Transaktion auf der Prinzipaldatenbank, auch erfolgreich auf der Spiegeldatenbank ausgeführt wurde. Damit das automatische Failover eine Verbesserung der Verfügbarkeit sicherstellt, müssen sich Spiegel- und Prinzipaldatenbank auf verschiedenen Computern befinden (vgl. [MS03]).

73 56 Ansätze des Self-Healings Diese Übergabe an einen zweiten Datenbankserver ist mit dem SQL Server 2012 auch für Hochverfügbarkeitsgruppen - AlwaysOn Availability Groups - möglich, denn die Möglichkeit das Failover für mehrere zusammenarbeitende Datenbankserver durchzuführen, bestand vorher nicht Statistisches Management Der nachfolgend aufgeführte Self-Healing-Mechanismus heilt und schützt das System von einem Internal System Failure (ISF), wobei es die Funktionsfähigkeit des Systems durch die Sammlung und Aufbereitung der Statistiken unterstützt. Bevor auf den eigentlichen Nutzen der Statistiken eingegangen wird, muss darauf hingewiesen werden, dass die Nutzung von Statistiken zwar primär zur Optimierung der Anfragen und damit dem Self-Tuning oder Self-Organisation unterzuordnen ist. Jedoch wäre ohne jede Pflege der Statistiken ein System kaum dauerhaft lauffähig, weshalb das Management der Statistiken auch der Selbsterhaltung und somit auch dem Self-Healing zugeschrieben werden kann. Oracle Database - Oracle besitzt eine Komponente namens Automatic Statistics Collection (ASC), welche verschiedene Typen von Statistiken kennt. Es werden Datenbankstatistiken, Betriebssystemstatistiken und Interpretationsstatistiken generiert und gepflegt, wobei Datenbankstatistiken Wait Events, die Active Session History sowie System- und Session- Statistiken beinhalten. In den Betriebssystemstatistiken finden sich hingegen Statistiken über CPU, virtuellen Speicher, Netzwerk und Festplattenspeicher. Die Vorhersagen für diverse Kardinalitäten (Tabellen, JOINs oder DISTINCT-Anweisung) werden aus den zugrunde liegenden Statistiken durch probabilistische Methoden abgeleitet. Der Monitoring Prozess beobachtet zudem Änderungen in der Datenbank und passt gegebenenfalls die Statistiken an. SQL Server - Der Anfrageoptimierer ist im SQL Server diejenige Komponente, welche Statistiken für die optimierte Ausführung von Querys anlegt. So spezifiziert er eigenständig für welche Objekte Statistiken gesammelt und gepflegt werden, sowie wann und wie dieses initiiert werden sollten. Statistiken können auch automatisiert über Wartungspläne gepflegt werden (siehe Abschnitt 5.1.2).

74 Ansätze des Self-Healings 57 IBM DB2 - Auch IBMs DB2 hat die Sammlung der Statistiken automatisiert. So wird der RUNSTATS-Befehl periodisch ausgeführt, um Statistiken über die physischen Eigenschaften von Tabellen und dazu gehörigen Indexen zu pflegen. Zudem gibt es die Möglichkeit dieses über Wartungspläne explizit auszuführen (siehe Abschnitt 5.1.2) Deadlockerkennung Der nachfolgend aufgeführte Self-Healing-Mechanismus schützt vor oder löst Deadlocks auf, welche aufgrund eines Internal System Failure (ISF) auftreten können. SQL Server - Die Deadlockerkennung, welche bereits im Abschnitt erläutert wurde, findet im SQL Server in umfänglichem Sinne statt. So ist die SQL Server-Deadlockerkennung sowohl für Sperren, Arbeitsprozesse, Transaktionen, Arbeitsspeicherblockierungen und die Ressourcen-Belegungen zuständig. Die Deadlockerkennung wird von einem Sperrüberwachungsprozess autonom ausgeführt, der alle fünf Sekunden alle Aufgaben der Database Engine durchsucht (vgl. [MS07]). Wird ein Deadlock identifiziert, werden die Beobachtungsintervalle dynamisch auf einhundert Millisekunden verkürzt. Wenn die Sperrüberwachung den Deadlockursprung bestimmt hat, wird zuerst die Ressource identifiziert, auf die der Prozess wartet. In der Folge identifiziert die Sperrüberwachung den Besitzer der Ressource und führt rekursiv die Deadlock-Suche für dessen Prozesse fort, bis ein geschlossener Zyklus gefunden wird. Ein auf diese Art identifizierter geschlossener Zyklus wird als Deadlock bezeichnet. Wenn ein Deadlock erkannt wurde, geht der Sperrüberwachungsprozess davon aus, dass zukünftige Prozesse wieder warten müssten, weshalb versucht wird den Deadlock zu beseitigen, bevor sich weitere Prozesse in die Kette der Wartenden einreihen können. Des Weiteren schließt die Database Engine (Datenbankmodul) den Deadlock, indem einer der Prozesse als Deadlockopfer ausgewählt wird. Standardmäßig wird der Prozess gewählt, für den am kostengünstigsten ein Rollback ausgeführt werden kann. Durch das Rollback einer Transaktion werden alle von der Transaktion aufrecht erhaltenen Sperren wieder freigegeben (vgl. [MS07]). Oracle Database - Oracle geht einen anderen Weg und hat unter anderem ein Multi-Version Read Consistency-Modell entwickelt und implementiert, welches sicher stellt, dass lesende und schreibende Transaktionen sich niemals beeinträchtigen. Das kann vom Modell gewährleistet werden, indem es die originalen Datenwerte in Schreibgeschütze Segmente

75 58 Ansätze des Self-Healings (Undo Segments) verlagert, bis eine Transaktion abgeschlossen ist (vgl. [Orac05]). Was jedoch nicht sicherstellt, dass ein Deadlock nicht zwischen zwei schreibenden Transaktionen auftreten kann. Zudem ist das Multi-Version Read Consistency-Modell lediglich eine mögliche Option zur Transaktionsverarbeitung Gesundheitschecks per Health Monitor Der nachfolgend aufgeführte Self-Healing-Mechanismus erarbeitet alle Informationen über verdächtige und für das System unlösbare Problemstellungen. Soweit diese nicht aufgelöst werden können, werden sie an den DBA weitergeleitet. Durch diese Strategie können sowohl Gefahren (User Error (UE); Internal Hardware Failure (IHF); Internal System Failure (ISF), External Software Failure (ESoF)) als auch Bedrohungen durch Denial of Service (DoS) ausfinden gemacht und eliminiert werden. Hingewiesen sei jedoch darauf, dass aufgrund des fehlenden Domainwissens unklare Problemstellungen an den DBA weitergeleitet werden müssen. Oracle Database - Seit dem Release von Oracle Database 11g beinhaltet Oracles Datenbankmanagementsystem ein Framework mit dem Namen Health Monitor. Dieses erkennt defekte oder korrupte Dateien, physische und logische Blöcke, UNDO- und REDO- Informationen, verfälschte Einträge im Data Dictionary und einige andere Unregelmäßigkeiten. Anschließend generiert es Reports, in welchem es die aufgefundenen Probleme und Problemlösungsstrategien auflistet und dem Systemadministrator zur Verfügung stellt (vgl. [Orac06]) Fehlerbehebung bei der Transaktionsverarbeitung Der nachfolgend aufgeführte Self-Healing-Mechanismus behebt Fehler bei der Transaktionsverarbeitung eines DBMS, welche sowohl unbeabsichtigt (Internal Hardware Failure (IHF); Internal System Failure (ISF); User Error (UE)) als auch mutwillig beeinflusst (Denial of Service (DoS)) auftreten können. SQL Server - Wird eine Transaktion aufgrund eines Fehler nicht erfolgreich beendet, führt der SQL Server automatisch ein Rollback der Transaktion aus und gibt alle von der Transaktionen beanspruchten Ressourcen frei. Zu einem Fehler kann es clientseitig kommen, indem die Verbindung des Clients mit der Instanz der Database Engine unterbrochen wird oder die

76 Ansätze des Self-Healings 59 Clientanwendung einen Fehler erzeugt und somit nicht mehr in der Lage ist mit dem Datenbankmodul zu kommunizieren. In all diesen Fällen führt das Datenbankmodul ein Rollback für alle ausstehenden Verbindungen aus. Zudem kann ein Anweisungsfehler zur Laufzeit, wie etwa eine Einschränkungsverletzung, auftreten, wodurch das Datenbankmodul nur für die Anweisungen ein Rollback ausführt, die den Fehler generiert haben (vgl. [MS08]). Im Falle eines Serverausfalls, welcher nicht auf Grund eines Hardwaredefekts (z.b. Festplattencrash), sondern auf einen reinen temporären, physischen Ausfall des Server (Stromausfall) zurückzuführen ist, besitzt der SQL Server auch Automatismen, um die Datenkonsistenz zu gewährleisten. Sollte ein Stromausfall eintreten, bevor eine Transaktion aus dem flüchtigen Speicher in den konsistenten Speicher übernommen wurde, wäre der Inhalt im volatilen Speicher (RAM) verloren und die Datenbank inkonsistent. Das Transaction Log, welches im SQL Server ausschließlich nach dem Prinzip des Write Ahead Loggings (siehe [S 621 [SHS05]]) funktioniert, regelt in diesem Fall die Ausfallsicherheit des Arbeitsspeichers. So ist eine Transaktion, die nicht in die Datenbank übernommen wurde, im Log auch noch als aktiv gekennzeichnet. Startet der Server nach dem Stromausfall wieder, erkennt der SQL Server, dass es noch nicht abgeschlossene Transaktionen im Log existieren und überführt diese zuerst in die Datenbank, bevor er für die Allgemeinheit wieder erreichbar ist (vgl. [Ora10]) Automatisches Wachsen bei Platzmangel Der nachfolgend aufgeführte Self-Healing-Mechanismus korrigiert die Größe des Speichers, welche für eine Datenbank festgelegt wurde. Würde eine solche Vergrößerung nicht durchgeführt werden, könnten keine Daten in die Datenbank eingefügt werden und das System würde nicht weiter seiner Arbeit nachgehen können. Die automatische Vergrößerung schützen somit vor allem vor einem Internal System Failure (ISF). Bei jedem DBMS kann der Datenbankadministrator während der Erstellung der Datenbank festlegen, wie viel Speicherplatz die Datenbank belegen soll. Es unterscheiden sich Systeme jedoch dadurch, ob dieses während des Betriebes vom System selbst nachjustiert werden kann. SQL Server - Im SQL Server ist standardmäßig voreingestellt, dass das System gemäß den Vergrößerungsparametern automatisch wächst. So kann mit den bei der Erstellung festgelegten Vergrößerungsparametern angegeben werden, welche Anfangsgröße die

77 60 Ansätze des Self-Healings Datendatei hat, um wieviel Prozent oder Megabyte sie bei voller Belegung wachsen soll und welche maximale Dateigröße erreicht werden kann. Im SQL Server gibt es zwei verschiedene Datendateitypen, jene für die eigentlichen Daten und Datendateien in die Transaktionsprotokolle geschrieben werden. Das automatische Erweitern des Speicherplatzes ist für beide Datendateitypen möglich. Wenn eine Datendatei dann annähernd vollständig gefüllt ist, erkennt das System diesen Zustand selbständig, erweitert die jeweilige Datendatei um den vorfestgelegten Faktor und bleibt somit voll funktionsfähig Stabilisierung des Servers und Anpassung an Arbeitsaufkommen Der nachfolgend aufgeführte Self-Healing-Mechanismus unterstützt die eigenständige Wiederherstellung der Funktionsfähigkeit eines Servers, welche durch den im Abschnitt 4 als Gefahr eingestuften Internal System Failure (ISF) beeinträchtigt werden kann. Oracle Database - Das Automatic Workload Repository (AWR), welches bereits in Oracle 10g eingeführt wurde, ist ein selbst-organisierendes Archiv, das zur eigenständigen Systemverbesserung und Rehabilitierung bei Fehlerzuständen eingesetzt wird. Es beinhaltet eine Sammlung an Informationen, die den Workload im System umfassend beschreiben. Durch die Analyse der Daten im AWR kann das DBMS selbst identifizieren, an welcher Stelle Wartungsarbeiten durchgeführt werden sollten (vgl. [Orac05]). Eine Komponente, welche ihre Daten in das AWR auslagert, ist die Active Session History (ASH). ASH speichert jede Sekunde Metadaten zu allen aktiven Sessions, womit auch nachträglich der Workload abgebildet und nachvollzogen werden kann. Darüber hinaus ermöglichen es diese Daten vorübergehende Performanceprobleme, Unregelmäßigkeiten beim Sperren, zu lang laufende Transaktionen, teure SQL-Befehle und CPU-intensive Aufgaben zu identifizieren (vgl. [Kur11]). Durch diese Selbsthilfe und Selbstheilung ist die Datenbank eigens in der Lage, sich an Eigenheiten des darunter liegenden Systems anzupassen. Oracles Automatic Database Diagnostic Monitor (ADDM) baut auf diesen Metainformationen auf, analysiert aufgetretene Probleme und stellt sie unter anderem weiteren Tuning-Methoden zur Verfügung. Der ADDM besitzt die zentralisierte Intelligenz um notwendige SQL-Tunings, Fragmentierungen, CPU-Flaschenhälse,

78 Ansätze des Self-Healings 61 unterbesetzte Speicherstrukturen, belastende Anfragen, Datenbankkonfigurations-Probleme und Parallelitäts-Probleme zu erkennen und zu analysieren (vgl. [RMS10]). Des Weiteren werden gefundenen Unstimmigkeiten, soweit sie nicht vom System selbst aufgelöst werden können, an den DBA, zusammen mit einer detaillierten Auswertung, weitergegeben. Oracle spezifiziert die Problemlösung durch Selbsthilfe als dreistufigen Kreislauf, in der der ADDM einen wesentlichen Anteil hat (vgl. [RMS10]). Abbildung 18: Problemlösungskreislauf (vgl. [RMS10]) Automatische Index- und Tabellen-Organisation Der nachfolgend aufgeführte Self-Healing-Mechanismus organisiert die Wiederherstellung und Aufrechterhaltung der Funktionsfähigkeit eines Servers, indem entartete Tabellen oder Indexe reorganisiert werden. Dieser Mechanismus schützt vor einem Internal System Failure (ISF), welcher im Abschnitt 4 als Gefahr eingestuft wurde. DB2 - Das DBMS von IBM besitzt einen automatischen Reorganisations-Mechanismus, welcher Teil der Automatic Maintenance Database-Konfiguration ist. So kontrolliert der Mechanismus acht vom System spezifizierte Parameter. Sollten diese Parameter außerhalb der erlaubten Schwellwerte liegen, wird eine Reorganisation der Tabelle oder des Indexes angestoßen (vgl. [IBM03]). Darüber hinaus besitzt DB2 die Index-Management-Technology, welche eine automatische Index-Seiten-Zusammenführung beinhaltet. Diese erlaubt es, Nachbarseiten zu verschmelzen, um den Speicherverbrauch zu reduzieren und somit das System vor einer Überlastung zu bewahren (vgl. [S 1 ff. [LLZ02]]). Jedes Mal, wenn Daten in Tabellen und in die jeweils dazugehörigen Indexe eingefügt, verändert oder gelöscht werden, kann die jeweilig darunter liegende Tabellen- oder Index-Struktur fragmentieren. Generell

79 62 Ansätze des Self-Healings können in DB2, wie auch allen anderen DBMS, zwei Varianten unterschieden werden, die die Struktur optimieren bzw. vor der vollkommenen Fragmentierung bewahren. Es gibt zum einen die Möglichkeit eine Struktur zu reorganisieren, wobei die bestehende Struktur möglichst beibehalten wird und lediglich verbessert werden soll. Zum anderen ist es möglich, die Struktur vollkommen neu aufzubauen (Rebuilt). Zudem ist zu unterscheiden, ob dies online oder offline geschehen soll. Im Online-Mode können die Nutzer während der Strukturanpassung weiter auf die Struktur zugreifen, wohingegen im Offline-Mode alle Strukturen gesperrt sind und auf sie nicht zugegriffen werden kann Anpassung des Datenbankdesign bei wechselndem Arbeitsaufkommen Der nachfolgend aufgeführte Mechanismus kann nur im weitesten Sinne dem Self-Healing zugeordnet werden. Er unterstützt das System und den DBA, in dem er langlaufende und unperformante Anfragen auf deren Potential überprüft. Er ermöglicht so, den Systemstatus von einem ungesunden, langsamen Status zu heilen. Es kann somit argumentiert werden, dass dieser Mechanismus vor einem Internal System Failure (ISF) schützt. DB2 - Bereits seit 1999 unterstützt der DB2 Design Advisor den Systemadministrator bei diversen Design-Entscheidungen. So erstellt er eigenständig, auf Grundlage des vorhergehendes Arbeitsaufkommens Empfehlungen, Indexe zu ergänzen oder ggf. zu entfernen. Zudem stellt er sicher, dass der empfohlene Index nach seiner Erstellung auch Verwendung findet. Er macht dies, indem er einen vielversprechenden virtuellen Index erstellt und anschließen eine normalen Anfrageoptimierung durchführt. Wenn der Anfrageplan mit dem virtuellen Index als Sieger hervorgeht, schlägt er diesen als zu bevorzugenden Index vor. Zudem ist er in der Lage ähnliche Verbesserungen für materialisierte Sichten und für die Partitionierung einer Tabelle vorzuschlagen (vgl. [S 2 ff. [LLZ02]]) Aktuelle Forschung und Prototypen In diesem Abschnitt werden Mechanismen und Systeme der aktuellen Forschungen aufgezeigt, welche Self-Healing-Eigenschaften implementiert haben. Es wird zum Anfang jedes Abschnittes Bezug genommen, vor welchen Bedrohungen und Gefahren der jeweilige Mechanismus schützt (vgl. Kapitel 4).

80 Ansätze des Self-Healings ITDB - A Self-Healing Database System [Liu04] Das nachfolgend aufgeführte Self-Healing-System schützt vor Bedrohungen (Excessive Privilege Abuse; Legitimate Privilege Abuse; Privilege Elevation; Weak Authentication), welche das System durch unautorisierten Zugriff gefährden sowie gravierenden vor Benutzerfehlern (User Error). Nach [Liu04] wird die Anzahl der Attacken auf Datenbankserver, welche an das Internet angebunden sind, stetig zunehmen. Dies soll vor allem der Fall sein, da immer mehr wertvolle und kritische Informationen an das weltweite Netzwerk angeschlossen werden. Wie im Kapitel 5.1 belegt wird, haben konventionelle DBMS Sicherheitsvorkehrungen implementiert, welche es Eindringlingen unmöglich machen sollen, in das System zu gelangen. Zu solchen Sicherheitsmechanismen gehören Techniken wie die Authentifizierung (vgl. [S [GW76]]), Inferenz-Kontrollmechanismen (vgl. [S 21 [Ada89]]), Mehrschicht- Sicherheitsmechanismen in Datenbanken (vgl. [S 628 [WSQ94]]) und die Mehrschicht- Sicherheitsmechanismen für Transaktionsverarbeitung (vgl. [S 3 ff. [AJG99]]). Jedoch sind die derzeitig auf dem Markt befindlichen Systeme sehr eingeschränkt bei der Tolerierung und nachträglichen Behandlung unautorisierter Eingriffe. Ist es einem Eindringling gelungen, das DBMS zu infiltrieren, indem er beispielsweise die Identität eines vorhandenen Nutzers übernommen hat (Legitimate Privilege Abuse), können die konventionellen Systeme dem kaum etwas entgegensetzen. Den Unterschied zwischen einem konventionellen Datenbanksystem, welches als Hauptanliegen die Prävention hat, und ITDB kann in sofern benannt werden, dass ITDB Attacken auf Transaktions-Ebene unbeschadet überstehen kann. Wenn Angreifer autorisierten Zugriff auf das System erlangen und konventionelle DBMS an ihr Grenze stoßen, widersteht ITDB und schließt diese Lücke. Es erkennt einen unautorisierten Zugriff, isoliert ihn, wertet ihn aus und repariert den entstandenen Schaden (vgl. [S 2 [Liu04]]). ITDB analysiert dazu Transaktionen nach schädlichen Verhalten. Ist eine gefährdende Transaktion erkannt, untersucht ITDB alle weiteren Transaktionen nach eventuellen Folgeschäden (Damage Spreading). Es erkennt alle betroffenen Transaktionen und repariert jedes korrumpierte Datenbankobjekt, ohne jedoch die Ausführung neuer Transaktionen zu behindern. Die Intrusion Detection basiert dabei auf dem Prinzip der Application-Aware Intrusion Detection, welche die Semantik von verschiedensten Applikationen adaptiert, spezifische Trail Collectors je Semantik einsetzt und die extrahierten

81 64 Ansätze des Self-Healings Semantiken dazu nutzt, den besten Intrusion Detection-Algorithmus je Applikation zu finden. Die Trail Collectors sammeln dabei Informationen auf Betriebssystem-, SQL- und Session- Ebene. Damit ein böswilliger Eingriff erkannt werden kann, verwendet ITDB ein auf Regeln basierendes Framework, das es erlaubt, verschiedenste Intrusion Detection-Algorithmen anzuwenden und miteinander zu kombinieren. Es werden sowohl Schwellen-basierende Intrusion Detection-Regeln (vgl. [Coh96]) als auch Regeln, welche auf statistischen Erhebungen basieren, angewendet. Damit die Benutzer auf die Regeln Einfluss nehmen können, besitzt ITDB eine Rule Base, mit der die standardmäßig vorhandenen Regeln erweitert werden können. Dieser modulare Aufbau von ITDB ermöglicht es, ITDB auch nachträglich zu erweitern. Somit können weiterentwickelte oder vollkommen neu erstellt Algorithmen später implementiert werden und die Qualität der Eindringlingserkennung weiter erhöht werden. Darüber hinaus wurde das System auf vier grundlegenden Säulen aufgebaut: 1. Mehrere Eindringungs-Toleranz-Phasen, um auch bei tiefergreifenden Prozessen reagieren zu können 2. Abkapselung und Isolation, um mit weniger guten Eindringlings-Erkennungs- Komponenten arbeiten zu können 3. On-The-Fly-Eindringungs-Transparenz für Applikationen 4. Adaptive Rekonfiguration zur Selbststabilisierung, um Datenintegrität und Verfügbarkeit zu gewährleisten Um die Arbeitsweise von ITDB verdeutlichen zu können, wird nachfolgend ein konkreter Ablauf wiedergegeben, welcher die Komponenten aus Abbildung 19 beinhaltet: 1. Wenn einer Transaktion dem System übergeben wird, untersucht der Policy Enforcement Manager (PEM) als eine Art Proxy jedes Statement innerhalb der Transaktion. Er speichert außerdem Informationen über die Transaktion und die enthaltenen Anweisungen ab. 2. Während der Ausführung einer Transaktion werden Lese- und Schreib-Vorgänge in separierten Log-Dateien gespeichert. Gleichzeitig bewertet der Intrusion Detector das Suspicion Level der betreffenden Transaktion, indem er die Spuren in den Logs und anderen Audit-Tabellen nachverfolgt. 3. Sollte nun der Intrusion Detector einen verdächtigen Benutzer entdecken, startet der Isolation Manager die Isolierung des betreffenden Benutzers. Dazu werden neue

82 Ansätze des Self-Healings 65 Versionen der Datenobjekte erzeugt, die parallel zu den realen Datenobjekten weitergeführt werden. 4. Wird nun eine bösartige Transaktion durch den Intrusion Detector identifiziert, beginnt der Damage Assessor mit der Lokalisierung des Schadens und der Damage Container beginnt den Multi-Phase Damage Containment-Prozess. 5. Wenn der Ursprung identifiziert wurde, beginnt der Damage Repairer kompensierende bzw. säubernde Transaktionen auszuführen. 6. Sollte vom Damage Container ein nicht betroffenes oder unzerstörtes Objekt gefunden werden, wird dieses wieder freigegeben. 7. Stellt der Intrusion Detector fest, dass der verdächtige Benutzer bösartige Absichten verfolgt, werden die isolierten Versionen der Daten verworfen. Stellt sich jedoch heraus, dass der Nutzer harmlos ist, werden die Daten zurück in die Datenbank überführt. 8. Darüber hinaus kann der Self-Stabilization Manager noch einige Rekonfigurations- Anweisungen an andere Komponenten des Systems versenden. Abbildung 19: Arbeitsweise ITDB [Liu04] Neben dem eigentlichen System wurden außerdem zwei Benchmarks konzipiert, um die Kosteneffektivität zu evaluieren.

83 66 Ansätze des Self-Healings Optimizing Security Measures in an Intrusion Tolerant Database System [UD08] Das nachfolgend aufgeführte, verbesserte Self-Healing-System schützt vor Bedrohungen (Excessive Privilege Abuse; Legitimate Privilege Abuse; Privilege Elevation; Weak Authentication), welche das System durch unautorisierten Zugriff gefährden sowie vor gravierenden Benutzerfehlern (User Error). [UD08] entwickelten eine Modell, beruhend auf einer stetigen Semi-Markov-Kette (siehe [Will95]), mit dem sie das stochastische Verhalten eines Intrusion Tolerant Database System anhand dreier Messwerte (Systemverfügbarkeit, Integrität und Rewarding Availability) weiter verbessern konnten. Durch die Verbesserung kann ein stabileres Self-Healing-System etabliert und die Gesamtperformance gesteigert werden. Die Forschungsarbeit baut auf der von [WL06] initiierten Forschung über die Evaluierung und Modellierung der Überlebensfähigkeit von Intrusion Tolerant Database Systems auf. Als Rewarding Availability bezeichnen [UD08] die Zeit, welche das System benötigt, um alle gesäuberten Datenobjekte bereit zu stellen. Die Evaluation der System-Überlebensfähigkeit wird in beiden Arbeiten durchgeführt, um vom Einfluss der Angriffsintensität und bestehender Systemmängel auf die Überlebensfähigkeit des Systems zu schließen (vgl. [WL06]). [UD08] gingen dabei von Forschungsergebnissen von [WL06] aus, der in seiner Thesis eine erste modellbasierte Evaluation von Intrusion Tolerant-Ansätzen bezüglich der Überlebensfähigkeit vorstellte. [WL06] modellierte das Verhalten des DBS als eine Serie von Zustandsdiagrammen, welche, basierend auf stetigen Markov-Ketten (CTMC) und dem Semi- Markow-Prozess (SMP), die Überlebensfähigkeit abbilden (vgl. [WL06]). Wie auch [WL06] beziehen [UD08] ihre Forschungen auf das von [Liu04] konzipierte Intrusion Tolerant Database System ITDB. Durch die Einführung des zusätzlichen Kontrollparameters der Switching Time (Umschaltzeit), entstand ein Sicherheitskontrollmechanismus für ITDB, welcher die Security-Messwerte erweitert und die bereits vorhandenen Messwerte durch dessen Anwendung verbessert. Durch die Verbesserung kann ein stabileres Self-Healing- System etabliert werden und die Gesamtperformance gesteigert werden. Darüber hinaus mussten durch die endliche Größe der Umschaltzeit, dass angewendete Modell angepasst werden, weshalb die Forscher von einer stetigen Semi-Markov-Kette (CTSMC) ausgingen (siehe [S 1 ff. [LO01]], um ein robusteres Framework gegen bösartige Attacken zu schaffen.

84 Ansätze des Self-Healings 67 [UD08] gelang es außerdem, die von [WL06] vorgestellten Messwerte (Integrität und Rewarding Availability) um die Systemverfügbarkeit (System Availability) zu ergänzen. Mit diesen drei Messwerten, ist es nach [UD08] möglich, die Arbeit des Systems umfassend zu bewerten und aufgrund dessen, ein stabileres Self-Healing-System zu gewährleisten Rainbow-Projekt [GS02] Das nachfolgend aufgeführte Self-Healing-System kann für beliebige DBMS oder ganze DBMS-Cluster angepasst werden. Die Kontrollstruktur kann sowohl vor Gefahren (User Error; Internal Hardware Failure; Internal System Failure; External System Failure; External Software Failure), als auch vor Bedrohungen (Excessive Privilege Abuse; Legitimate Privilege Abuse; Privilege Elevation; Denial of Service) schützen, soweit das jeweilige Szenario vom DBA in das Modell integriert wurde. [GS02] entwickelten eine Modell-basierte Kontrollstruktur bzw. Kontrollinstanz, welche auf ein bestehendes System gesetzt werden kann, dieses eigenständig innerhalb von spezifizierten Schwellwerten agieren lässt und bei Verletzung der Schwellenwerte, das System zurück in einen gesunden Zustand überführt (Analysis & Repair). Damit die Kontrollstruktur dauerhaft und unmittelbar über den Zustand des Systems informiert ist, wird das System ununterbrochen überwacht (Monitoring). Diese immer wiederkehrende Kontrollschleife ist in Abbildung 20 abgebildet. Abbildung 20: Modell-basierte Adaptierung (vgl. [GD02]) Ein frei wählbares Modell für jede beliebige Architektur nutzen zu können, ist laut der Autoren äußerst vorteilhaft, da die Kontrollstruktur so sehr allgemeingültig anwendbar ist.

85 68 Ansätze des Self-Healings Die einzelnen Modelle werden implementiert durch architektonisch aufgebaute Beschreibungssprachen (ADL), wie Acme (siehe [GMW00]), xadl (siehe [DHT01]) und SADL (siehe [MR97]). Auf die Darstellung von spezifischen Code-Fragmenten wird an dieser Stelle jedoch verzichtet und auf [S 3 [GS02]] verwiesen. Für die Realisierung der Architekturmodelle nutzen die Forscher ein einfaches abstraktes Schema, welches das Modell als Graph mit interagierenden Knoten abbildet. Die Knoten in diesem Graph sind dabei die Komponenten und repräsentieren die wesentlichen Recheneinheiten und Datenspeicher des Systems. Dazu gehören Clients, Server, aber eben auch Datenbanken oder DBMS. Die Kanten (Connector) hingegen bilden den Informationsverlauf zwischen den Komponenten ab. In der Realität könnte ein solcher Informationsfluss durch komplexe Middleware- oder Verteilte Systeme realisiert sein. Um den verschiedenen Verhalten gerecht zu werden, kann jede Komponente und Kante des Graphen mit einer Eigenschaftsliste (Property List) verknüpft werden, auf der diverse Attribute (Protokoll, Bandbreite, Verzögerungen etc.) festgehalten sind. Zudem können für das System diverse Einschränkungen (Constraints) festgelegt werden. Damit die Funktionsweise verständlicher erscheint, soll das beschriebene Modell exemplarisch für ein verteiltes DBMS 6 angewendet werden. Durch die Wahl eines DBMS sind vor allem Eigenschaften und Constraints, die die Prozessorzeit, Seitenstatistiken, Festplatten I/O und Arbeitsspeicher betreffen einzubinden. Nachfolgend eine unvollständige Auswahl der in Betracht kommenden Parameter, welche mit dem Windows Performancemonitor (Perfmon) überwacht werden können: Memory\Available Mbytes Memory\Page Reads/sec Processor\% Processor Time Processor\% Privileged Time System\Context Switches/sec Physical Disk\% Disk Time PhysicalDisk\Avg. Disk Queue Length 6 Ein verteiltes DBMS zeichnet sich dadurch aus, dass die miteinander verbundenen DBMS einen gewissen Grad an Autonomie haben und somit unabhängig voneinander operieren können.

86 Ansätze des Self-Healings 69 PhysicalDisk\Avg. Disk sec/transfer Da es sich um verteilte DBMS handelt, müssen auch Eigenschaften und Constraints implementiert werden, die die Performance und Konnektivität zwischen den einzelnen Systemen abbilden. Hier wären beispielsweise eine Obergrenze der Antwortzeit, die Bandbreite der Übertragung oder die Ausfallzeit (Downtime) geeignete Kenngrößen. Die Umsetzung des Modells kann mit einer der bereits genannten architektonisch aufgebauten Beschreibungssprachen realisiert werden, in dem Kanten, Komponenten, Eigenschaftslisten und Constraints in ein Modell für DBMS eingebettet werden. Hinzu kommt eine Sammlung von Reparaturstrategien, die in Abhängigkeit mit den definierten Constraints stehen. Die Operatoren und Reparaturstrategien entstehen aus analytischen Untersuchungen, welche formal identifizieren, wo die Architektur verändert oder angepasst werden muss, damit die jeweiligen Parameter zufriedenstellende Werte erlangen. Abbildung 21 zeigt das schematische Modell der genannten Architektur, wobei jeder Server und die Vereinigung aller Server (Verteilte DBMS) Eigenschaftslisten besitzen und zusätzlich Constraints und Reparaturstrategien definiert wurden. Abbildung 21: Modell eines verteilten DBMS Für eine ausführlichere Beschreibung wird auf den betreffenden Forschungsbeitrag (siehe [GS02]) verwiesen.

87 70 Ansätze des Self-Healings Shaman: A Self-Healing Database System [DFT08] Das nachfolgend aufgeführte Self-Healing-System sorgt für die Rehabilitierung der Funktionsfähigkeit eines Servers, welche durch einen Internal System Failure (ISF) beeinträchtigt werden kann. Shaman ist ein Projekt, welches in der Duke University entwickelt wurde (siehe [DFT08]) mit dem Ziel, einen ganzheitlichen Ansatz für das Self-Healing zu liefern. Es unterstützt das DBMS dabei, zu gesunden, indem es den Ursprung eines Fehlers identifiziert, ihn klassifiziert und bewertet und die erforderlichen Maßnahmen zur Behebung einleitet. [DFT08] implementierten einen inkrementellen Ansatz, um das Self-Healing abzubilden, der Fehlerklassen identifiziert und spezifizierte Strategien (Policies) zur Beseitigung nutzt. Ein besonderes Augenmerk wurde bei der ersten Implementierung auf Veränderungen der Arbeitslast (Workload) gelegt, welche häufig als Störung oder Performance Probleme missinterpretiert werden. Somit ist das Projekt zum Zeitpunkt der Veröffentlichung des Forschungsbeitrages vorrangig für Self-Tuning bzw. Self-Optimization ausgelegt. In kommenden Forschungsbeiträgen sollen jedoch auch Sicherheitsprobleme tiefergreifend thematisiert werden. Die Autoren unterscheiden zwei Typen von Workload-Veränderungen: 1. Die Gesamtbelastung variiert um den Faktor zehn bis einhundert. 2. Die Belastungsverteilung eines DBS variiert beispielsweise, wenn Auktionsangebote in einem Onlineshop sehr oft verkauft werden und die darunter liegende DB deshalb überdurchschnittlich viele neue Informationen aufnehmen muss. Dem bisherigen Trend, die Systeme auch für Lastspitzen zu wappnen, indem sie überdimensioniert werden, entgegnet Shaman durch eine intelligente Konfiguration und Verteilung der Ressourcen. Die Maßnahmen werden in der Arbeit verallgemeinert unter dem Begriff "Fix", welches im Deutschen so viel wie Behebung, Reparatur oder Stabilisierung bedeutet. Die Forscher unterscheiden zwei Arten von Fixes: Ressourcen- und Konfigurationsbasierende. Der Erfolg von Shaman ist jedoch grundlegen davon abhängig, bei einer Vielzahl an Fixes, den einen Richtigen bzw. die Verknüpfung der korrekten Fixes zu finden. Zu diesem Zweck implementierten [DFT08] eine bis dato ungenutzte Form, dauerhaft robuste Indexe zu evaluieren. Zudem entwickelten sie ein Performance Modell, welches bei

88 Ansätze des Self-Healings 71 Performanceproblemen eine Liste von möglichen Fixes auswählt, aus welchen das kostenärmste ausgewählt wird Accurate and Efficient Inter-Transaction Dependency Tracking [CB08] Das nachfolgend aufgeführte Self-Healing-System behebt Fehler der Transaktionsverarbeitung eines DBMS, welches durch Bedrohungen (Excessive Privilege Abuse; Legitimate Privilege Abuse; Privilege Elevation; Denial of Service; Database Communication Protocol Vulnerabilities) oder Gefahren (User Error; Internal System Failure; External System Failure; External Software Failure) provoziert werden. Als Reparable Database Management System (Reparables DBMS) bezeichnen [CB08] ein System mit der Fähigkeit, automatisch und selbstständig Transaktionen zurückzurollen, welche direkt durch Benutzerfehler oder bösartige Attacken schädlich verändert worden oder von solchen Transaktionen beeinflusst worden sind. Darüber hinaus sind Reparable Database Management Systems in der Lage, das exakte Set der Transaktionen, welches direkt oder indirekt von einer schädlichen Transaktion betroffen Transaktionen beinhaltet, zu identifizieren und auch nur diese zurückzurollen. Durch die Möglichkeiten Transaktionen auch nachträglich zurückzurollen wird jedoch die Dauerhaftigkeits-Eigenschaft des ACID- Prinzip (siehe Kapital 2.3.6) verletzt. Die Unterscheidung zwischen einem Hardwarefehler und Fehlern, die durch Dritte fabriziert wurden, kann anhand des Verlaufs eindeutig identifiziert werden (vgl. [CB08]). So folgen durch einen Angriff fabrizierte Fehler nie einem Fail-Stop-Paradigma und können somit nicht unmittelbar, sondern erst im Nachhinein erkannt werden. Ein Fail-Stop-Schema beschreibt einen Verlauf, bei dem nach einem Fehler nicht weiter mit dem betreffenden System interagiert wird, sondern die Kommunikation auf Grund des Fehlers stoppt. Bei Hardwarefehlern fällt hingegen das Gesamtsystem aus, was dem Systemadministrator umgehend gemeldet wird. Das Angreifer keinem Fail-Stop-Paradigma folgen, rührt aus der Intension Fehler zu provozieren und provozierte Fehler ausnutzen zu wollen. Die Forscher konstruierten aufbauend auf dieser Theorie einen Mechanismus, welcher Abhängigkeiten von Transaktionen aufzeichnet und die Funktion bestehender Repairable DBMS verbessert. Die Verbesserung tritt ein, da die Inter-Transaction Dependency genauer

89 72 Ansätze des Self-Healings abgebildet werden kann und bisherige Systeme an dieser Stelle viele Abhängigkeiten falsch deklarierten. Der Mechanismus wurde in ein System eingebettet, welches den Namen Blastema trägt. Blastema wurde äußerst systemunabhängig und portabel konstruiert, so dass es adaptierbar für verschiedensten DBMS ist. Von einer Abhängigkeit zwischen Transaktion wird gesprochen, wenn eine nachfolgende Transaktion Daten verwendet, die eine vorhergehende Transaktion verändert hat. Darüber hinaus unterscheiden die Forscher jedoch noch falsch-positive und falsch-negative Abhängigkeiten. Eine falsch-positiv Abhängigkeit würde generiert werden, wenn das System eine Abhängigkeit zweier Transaktionen berechnet, diese aber in Wirklichkeit nicht voneinander abhängig sind. Eine falsch-negative Abhängigkeit tritt hingegen auf, wenn eine real vorhandene Abhängigkeit nicht erkannt wird. Abbildung 22 verdeutlicht diesen Zusammenhang noch einmal. Abbildung 22: Abhängigkeiten der Transaktionen Mit Blastema sind die Forscher in der Lage, auch die kleinsten Abweichungen von falschpositiv, wie auch falsch-negativ deklarierten Abhängigkeiten infizierter Transaktionen zu identifizieren und eine korrekte Struktur abzubilden. Anders als bei den falsch-positiven Abhängigkeiten, die vom System sofort entfernt werden, unterscheiden die Forscher bei den falsch-negativen Abhängigkeiten zwischen Phantom-Abhängigkeiten und solchen, die durch die gemeinsame Nutzung mehrerer Applikationen entstehen. Eine Phantom-Abhängigkeiten besteht zwischen Transaktion T 1 und T 2, wenn T 1 einen Datenwert so verändert hat, dass er durch das Raster von T 2 fällt, T 2 ihn aber ohne Änderungen von T 1 verändert hätte (vgl. [S 2 [CB08]]). Solche Abhängigkeiten wurden bisher von keinen Repairable DBMS erkannt und behandelt. Blastema setzt an dieser Stelle an und erweitert die Funktionalitäten insoweit, dass allen falsch-positiven und falsch-negativen Abhängigkeiten entgegnet werden kann. Die Forscher implementierten aus diesem Grund drei Nachverfolgungsmechanismen, welche die

90 Ansätze des Self-Healings 73 bisher unberücksichtigten Abhängigkeiten abdecken. Die drei Nachverfolgungsmechanismen sind Column-Based Dependency Tracking, Phantom Dependency Tracking und Application- Level Dependency Tracking. Dabei löst das Column-Based Dependency Tracking Abhängigkeiten auf, bei denen verschiedene Transaktionen zwar auf dem selben Datensatz, aber auf unterschiedlichen Attributen arbeiten und das Application-Level Dependency Tracking korrigiert Abhängigkeiten, die auf Grund der Applikationslogik entstanden sind. Schlussendlich ermittelt das Phantom Dependency Tracking die bereits weiter oben beschriebenen Phantom-Abhängigkeiten. Mit dem von [CB08] entwickelten Algorithmus hat das System die Fähigkeit, automatisch und selbstständig Transaktionen zurückzurollen, welche direkt durch Benutzerfehler oder bösartige Attacken schädlich verändert worden oder von solchen Transaktionen beeinflusst worden sind. Dieses ist eine enorme Verbesserung, da Forschungen ergeben haben, dass aufgetretene Fehler, welche von Benutzereingaben rühren, frühestens vierundzwanzig Stunden nach dem Auftreten entdeckt werden (vgl. [S 2 ff. [Bat01]]). Die Beseitigung solcher längerfristig unbekannten Fehler ging bisher mit der Aufgabe der bis dato verarbeiteten Daten einher oder der Systemadministrator war dazu gezwungen, eine intensive Rückverfolgung und Löschung der betroffenen Transaktionen durchzuführen. Die Forscher gehen jedoch nicht darauf ein, wie Attacken identifiziert werden oder wie und ob diese unterschieden werden können A Portable Implementation Framework for Intrusion- Resilient Database Management Systems [SC04] Der nachfolgend aufgeführte Self-Healing-Mechanismus behebt fehlerhafte Veränderungen bei der Transaktionsverarbeitung eines DBMS, welches durch Gefahren (User Error; Internal System Failure; External Software Failure) oder Bedrohungen (Excessive Privilege Abuse; Legitimate Privilege Abuse; Privilege Elevation) entstehen können. Wie bereits im Zuge dieser Forschungsarbeit im Abschnitt 3.3 aufgeführt wurde, unterscheiden auch [SC04] drei Arten von Fehlern, welche die Konsistenz eines DBMS beeinträchtigen können: Hardwarefehler, bösartige Attacken und Benutzerfehler

91 74 Ansätze des Self-Healings Obwohl die meisten der derzeit auf dem Markt erhältlichen DBMS, Hardwarefehler sofort erkennen und behandeln können, existieren bei dem weitaus größten Teil keine Mechanismen, die den schadhaft veränderten Transaktionen entgegen wirken. Wie bereits in Abschnitt erwähnt, sind aber genau diese Transaktionen und alle darauf aufbauenden Transaktionen besonders kritisch und ihnen muss größte Beachtung geschenkt werden. So ist damit zu rechnen, dass einmal erfolgreich ausgeführte, schadhafte Transaktionen, ihre fehlerhaften Informationen weiter streuen (Damage Spreading). Die Zeitspanne, welche zwischen dem Auftreten des Fehlers bzw. der Attacke und ihrer Entdeckung liegt, ist für herkömmliche DBS zu groß, so dass die beiden Events in keiner Beziehung zueinander stehen. Aus diesem Grund ist eine Verschleppung fehlerhafter Informationen unvermeidbar. Eine automatisierte Rückabwicklung solcher Transaktionen ist derzeit in keinem DBMS vorgesehen und somit Aufgabe des DBA. Um diese zeitraubende, von Hand zu vollführende Aufgabe zu erleichtern, haben [SC04] ein adaptierbare Implementierung eines Frameworks erdacht, welches kommerzielle DBS bei Angriffen dieser Art unterstützen soll, ohne dabei den Kern des Systems verändern zu müssen. Ihre Forschungen beruhen auf den Erkenntnissen von Blastema (siehe [CB08]), welches im Abschnitt beschrieben wurden. Mit dem Framework ist es möglich, den Ursprung des Schadens zu identifizieren und alle abhängigen Transaktionen wieder rückgängig zu machen. Systeme, die solche Mechanismen implementiert haben, bezeichnen [SC04] als robust gegen Eindringling (Intrusion-Resilient). Der vorgestellte Mechanismus soll die Verfügbarkeit moderner DBMS verbessern, indem er die Reparatur von absichtlich oder unabsichtlich ausgeführten, schädlichen Transaktionen erleichtert und automatisiert. Das Framework wurde von den Forschern so konzipiert, dass es auf verschiedene DBMS angewendet werden kann. Diese Portierbarkeit wird gewährleistet, da der gesamte Mechanismus in SQL implementiert wurde und SQL systemunabhängig agiert. [SC04] belegen die beschriebene Portierbarkeit, indem sie ihr System auf den Datenbankmanagementsystemen PostgreSQL, Oracle und Sybase testeten und diese Versuche in ihre Arbeit einfließen ließen. Das von den Forschern entwickelte Modell beobachtet Transaktionsabhängigkeiten während des normalen Betriebes, um im Ernstfall die Reparatur schnell durchführen zu können. Die Forscher installierten einen server- und einen clientseitigen Proxy, welche untereinander über eine geschützte Verbindung kommunizieren. Der clientseitige Proxy initialisiert die sichere Verbindung und der serverseitige Proxy sammelt Transaktionsabhängigkeiten, damit

92 Ansätze des Self-Healings 75 gegebenenfalls der Fehlerursprung identifiziert werden kann. Für die Speicherung der Abhängigkeiten existieren zwei Tabellen, die zusätzlich für jedes DBMS angelegt werden müssen. Jede Transaktion bekommt vom Client-Proxy eine eigene, von der internen System- ID unabhängige, Identifikationsnummer. Im Falle einer Rückführung in den Ausgangszustand werden kompensierende Transaktionen eingesetzt. Nur durch die Verkettung der WHERE- Klauseln und den eindeutigen, read-only Row-IDs des Systems, kann für jede Transaktion eine kompensierende Transaktion existieren, ansonsten könnte dies nicht gewährleistet werden. Die Verknüpfung der systeminternen Identifikationsnummer mit der generierten ID wird über die beiden zusätzlichen Tabellen vollzogen. Das System erstellt im Fehlerfall einen Graphen, welcher alle Abhängigkeiten der betreffenden Transaktionen abbildet und schlussendlich dem Administrator vorlegt. Der DBA entscheidet anschließend mit seinem domainspezifischen Wissen, da nur er den aktuellen Nutzen einzelner Konstrukte kennt. So könnten beispielsweise temporäre Tabellen, die keine Rolle spielen, von der Rückführung ausgeschlossen werden und den Arbeitsaufwand bedeutend verkleinern. Das vom Administrator festgelegte UNDO-Transaktionsset übernimmt das System anschließend zur weiteren Verarbeitung. Die eigentliche Reparatur ist jedoch sehr datenbankspezifisch und muss individuell auf das System angepasst werden. Für die drei aufgeführten Systeme, ist eine solche Logik in der Arbeit konstruiert. Der Mechanismus, welcher Abhängigkeiten von Transaktionen abbildet, ist zudem Forschungsschwerpunkt einiger anderer Forschungen (siehe [AJL02]; [Liu02]; [Liu03]) Self-Healing and Hybrid Diagnosis in Cloud Computing [DXZ09] Das nachfolgend aufgeführte Self-Healing-System sichert die ununterbrochene Bereitschaft eines Cloud-Systems ab. Es kann sowohl vor Gefahren (User Error; Internal Hardware Failure; Internal System Failure; External System Failure; External Software Failure), als auch vor Bedrohungen (Platform Vulnerabilities; Database Communication Protocol Vulnerabilities; Denial of Service) schützen, soweit das jeweilige Szenario vom DBA in das Modell integriert wurde. Wie bereits im Kapitel 2.1 erläutert wurde, sind die an einem Cloud Computing teilnehmenden Systeme und Komponenten äußerst komplex, damit die Ausfallsicherheit und

93 76 Ansätze des Self-Healings Skalierbarkeit für jeden Kunden, egal, ob Privatperson oder Konzern, gewährleistet werden kann. Die damit einhergehenden Anforderungen an Wartung und ununterbrochener Bereitschaft sind daher prädestiniert für einen gewissen Grad an Autonomie. Dass die Ressourcen in einer Cloud in der Regel für jedermann und dauerhaft verfügbar sind, ist ein weiterer Aspekt, aus dem sich jedoch auch zusätzliche Gefahren ergeben, welche aufgefangen werden müssen. Die derzeit implementierten Mechanismen des Cloud Computings sind jedoch noch unausgereift und schlagen oft fehl, was sich darin äußert, dass (virtuelle) Knoten innerhalb des Systems abstürzen, in inkonsistente Zustände übergehen oder äußerst unperformant arbeiten (vgl. [DXZ09]). Um eine verlässliche Plattform aufzubauen, welche Cloud Computing-Services anbietet, ist es daher unerlässlich Self-Diagnose- und Self- Healing-Eigenschaften in das System zu integrieren, damit sich das System gegebenenfalls vor Fehlern und Ausfällen schützen kann. An dieser Stelle setzten [DXZ09] an und entwickelten ein System, welches über selbstheilende Mechanismen verfügt und somit die Anforderungen an Verfügbarkeit, Überlebensfähigkeit, Wartbarkeit und Verlässlichkeit erfüllt. Die Forscher konzipierten ihr Tool auf der sich an den Auswirkungen orientierenden Sichtweise, die nicht nur den Ursprung eines Fehlers präzisiert, sondern darüber hinaus die unmittelbare Gegenmaßnahmen für aufgetretene Symptome aufzeigt. Für die schnelle Kategorisierung der Fehler implementierten die Forscher ein Multi-Valued Decision Diagram (MDD), wohingegen zur Findung der bestmöglichen Konsequenz die Naive Bayes Klassifikation herangezogen wurde. Darüber hinaus klassifizieren die Forscher die möglichen Auswirkungen nach Gewichtung. Die Gewichtung bildet dabei umfassend den Aufwand der Konsequenzen ab, welche unternommen werden müssten, um das System zu heilen, sowie die "Entfernung" zu der bedrohlichsten Stufe dieser Gewichtung. Die Entfernung bezeichnet dabei die approximierte Zeit, welche für Diagnose- und Heilungsprozess gebraucht werden würde, damit Systemfehler ausgeschlossen werden können. Darüber hinaus werden Heilungsstrategien kategorisiert und den Gewichtungs-Levels bzw. den Konsequenzen zugeordnet. Die Gewichtung wurde von den Forschern in vier Level mit jeweils einer Heilungskategorie unterschieden:

94 Ansätze des Self-Healings 77 Gewichtungs-Level Minor Severity Level Major Severity Level Serious Level Catastrophic Level Kategorie für Heilung Prozess darf weiterlaufen, nebenbei wird nach Lösungen gesucht Der Prozess wird unverzüglich ausgesetzt und es wird nach möglichen Auswirkungen sowie deren Beseitigung (Heilung) gesucht. Beendigung (KILL) des Prozesses Neustart des Systems Tabelle 6: Gewichtungs-Level Die einzelnen Gewichtungen wurden zwar von den Forschern für das System festgelegt, die Einschätzung und die erforderliche Gegenmaßnahmen für einen aufgetretenen Fehler, übernimmt das System jedoch selbst. Es nutzt dafür einen MDD, welches zur Wahl von mehreren hierarchisch voneinander abhängende Entscheidungen, mehrere Entscheidungsmöglichkeiten je Entscheidungsebene einbezieht. Die Forscher fanden heraus, dass MDD sehr effektiv und effizient die auftretenden Fehler mit den bereits vorgegebenen Gewichtungs-Leveln bzw. deren Kriterien abgleicht. Eine solche rasche Klassifizierung der Fehlerschwere wurde fokussiert, da möglichst schnell entschieden werden muss, wie kurzoder langfristig die Heilungsmaßnahmen ausfallen müssen. Ein elementarer Bestandteil ist somit die Gewichtungs-Level korrekt und durchschnittsfremd zu definieren, sowie die korrekte Auswahl der Gegenmaßnahmen bereitzustellen. Damit auch der Auswahlprozess für die Gegenmaßnahmen erfolgreich und binnen kurzer Zeit abschließt, entschieden sich die Forscher, für die Auswahl der Konsequenzen, einen Klassifizierung per Naive Bayes Netzwerk durchzuführen, welches stetig durch die Evaluierung der Ergebnissen des Heilungsprozesses verbessert werden kann. Die Naive Bayes Klassifizierung kann eine sehr genaue Wahl der am besten geeigneten Heilungskategorie treffen, da Wahrscheinlichkeiten für die einzelnen Kandidaten existieren. Abschließend muss noch betont werden, dass bei der Entwicklung des Tools, vor allem dessen Effizienz, Genauigkeit und Lernfähigkeit fokussiert wurden. Zur Verdeutlichung der Arbeitsweise wird nachfolgend der Ablauf dieses Prozesses aufgezeigt, welches zusätzlich durch die Abbildung 23 verdeutlicht wird:

95 78 Ansätze des Self-Healings 1. Nach dem Auftreten von Symptomen eines Fehlers beginnt das MDD-Modul den Schweregrad des Fehlers zu klassifizieren. 2. Anschließend wird der Schweregrad dem Healing-Modul übermittelt, damit dieses das Gewichtungs-Level festlegen kann. 3. Die aufgetretenen Symptome werden außerdem vorverarbeitet und angepasst, damit sie in das Naive Bayes Klassifikator-Modul eingespeist werden können. 4. Nach der Festlegung des Gewichtungs-Levels geht die Ermittlung der geeigneten Konsequenzen in die zweite Phase über, indem die Kategorie der Konsequenzen durch das bereits bekannte Gewichtungs-Level bestimmt wird. 5. Der Naive Bayes Klassifikator identifiziert abhängig von der bestimmten Konsequenzen-Kategorie die wahrscheinlichste Konsequenz und leitet diese an das Healing-Modul weiter. Zu bemerken ist an dieser Stelle noch, dass jede Konsequenzen-Kategorie ein eigenes unabhängiges Naive Bayes Netzwerk ausgebildet hat. 6. Danach wählt das Healing-Modul geeignete Gegenmaßnahmen unter Berücksichtigung der vorgegebenen Konsequenzen aus. 7. Schlussendlich wird das Ergebnis wiederrum dem jeweiligen Naive Bayes Netzwerk zugeführt, um dieses zu trainieren und die Parameter nachzujustieren. Abbildung 23: Arbeitsweise Self-Healing and Hybrid Diagnosis in Cloud Computing (vgl. [DXZ09])

96 Ansätze des Self-Healings RemusDB: Transparent High Availability for Database Systems [DXZ09] Das nachfolgend aufgeführte Self-Healing-System stellt eine unterbrechungsfreie Arbeit eines in der Cloud befindlichen DBMS sicher. Durch die Verlagerung der Kompetenzen in den Virtualisierungslayer, kann das System vor Gefahren (Internal Hardware Failure; Internal System Failure; User Error) und Bedrohungen (Platform Vulnerabilities; Denial of Service) gleicher Art schützen. Wie bereits in Kapitel 2.1 zusammengefasst wurde, können durch die Konstruktion der Cloud Ressourcen flexibler verteilt, besser ausgenutzt und einfacher administriert werden. Zudem ist es möglich, virtualisierte Maschinen (VM) während des Betriebes auf leistungsfähigere Server zu verlagern (Live-Migration) und die VM selbst zusätzliche Ressourcen einholen oder abgeben (Scale-Out) zu lassen. DBMS die sich in der Cloud befinden, haben daher einen erweiterten Funktionsumfang und werden fast ausschließlich auf virtuellen Maschinen betrieben (vgl. [S 2 [SMA08]]). In ihrem Paper präsentieren [MRC11] eine Architektur mit der die Hochverfügbarkeit eines DBMS gewährleistet werden kann. Die vorgestellte Bauart ist mit jedem System realisierbar und kann durch wenige Anpassungen vollzogen werden. Der Ansatz der Forscher beruht auf Remus (siehe [CLM08]), einer hochverfügbaren Architektur für virtuelle Maschinen. Mit Remus werden asynchron Replikationen zwischen VM verschoben, welches jedoch vor außenstehenden Clients verborgen wird, damit Transparenz, Hochverfügbarkeit, Ausfallsicherheit und nahtlose Fehler-Recovery gewährleistet werden kann. [MRC11] präsentieren in ihrem Forschungsbeitrag eine hochverfügbares DBMS, welches auf mehreren VM arbeitet und somit viel Komplexität vom DBMS auf die virtuelle Schicht übertragen kann. Die Forscher bezeichnen ihre Architektur als eine Active-Standby- Hochverfügbarkeitslösung, wobei mindestens zwei virtuelle Maschinen existieren müssen. Eine arbeitet dabei aktiv und die zweite befindet sich in einer Art Standby-Modus. Der Standby-Modus beschreibt an dieser Stelle einen passiven Zustand der VM, welche ausschließlich vom aktiven System mit Informationen gespeist wird. Die aktive VM koordiniert in zyklischen Abständen die Weitergabe der Informationen an das passive System. Durch die Verlagerung von Kompetenzen ist nicht das DBMS für die Weitergabe der

97 80 Ansätze des Self-Healings Informationen zuständig und somit werden auch keinerlei Transaktionsabschlüsse (Commit) oder -abbrüche (Aborts) weitergegeben. Vielmehr erkennt die Virtualisierungsschicht, welche für die Gastbetriebssysteme die virtuelle Hardware emuliert (vgl. [S 38 [Ahn09]), Änderungen im Gesamtsystem des aktiven Hosts und propagiert sie zyklisch auf das passive System. Die passive VM agiert als Backup-VM. Die Virtualisierungsschicht erkennt auch Fehler und organisiert den Failover vom aktiven zum passiven Host. All das geschieht jedoch transparent und konsistent für das DBMS, da während eines Failovers alle ACID- Eigenschaften (siehe Abschnitt 2.3.6) gewahrt werden. Der Nachteil, dass Systeme die nach dem Prinzip von Remus konzipiert werden, sehr performancelastig agieren, wurde von den Forschern bei der Entwicklung der RemusDB berücksichtigt. Abbildung 24: Architektur RemusDB (vgl. [DXZ09]) Wie auf Abbildung 24 abgebildet, gewährleisten zwei virtuelle Maschinen (VM), die Hochverfügbarkeit des Gesamtsystems. Soweit sich das System im Normalzustand befindet und kein Fehler aufgetreten ist, bearbeitet ausschließlich die aktive VM die ankommenden Client-Anfragen (Request). In der aktiven VM werden außerdem der gesamte Status des Systems (Festspeicher, flüchtiger Speicher, aktive Verbindungen etc.) zyklisch gesichert bzw. Checkpoints erstellt und an das im Standby befindliche System gesendet. In der Sicherung befinden sich zudem sämtliche Daten, die das DBMS betreffen (Inhalt des Buffer Pool, Lock Table, Verbindungen etc.). Somit kann die passive VM, bei einem Ausfall der aktiven VM, sofort mit gefülltem, betriebsbereitem Cache - warmer Cache - die Arbeit übernehmen. An

98 Ansätze des Self-Healings 81 dieser Stelle muss aber betont werden, dass die Standby-VM keinesfalls gespiegelt wird, sondern es sich auf die Installation der Checkpoints beschränkt. Mit dieser Methode kann auch die Belastung der Ressourcen verringert werden. Die zyklisch übertragenen Checkpoints dienen außerdem als Puls oder Lebenzeichen. Wenn also keine Lebenszeichen mehr von der aktiven VM übertragen wird, übernimmt das Standby-System die Arbeit, ausgehend vom letzten, vollkommen übertragenen Checkpoint, bei dem der Fehler noch nicht aufgetreten war. Da es gegenüber dem Client zu Inkonsistenzen kommt, wenn bereits beendete Transaktionen abhanden kommen würden, werden alle ausgehende Informationen, wie beispielsweise die Beendigung einer Transaktion (Commit), so lange zurückgehalten, bis der Checkpoint der dieses Commit beinhaltet, gesendet wurde. Somit unterscheiden sich zur Laufzeit die Zustände der VM zwar zwischen den Checkpoints, aber dem Client bleibt das verborgen. Diese interne Ungleichheit ist jedoch unerheblich, da eine Transaktion, die auf der aktiven VM ausgeführt wurde, so lange nicht als abgeschlossen gilt, bis der nächste Checkpoint an die Standby-VM gesendet wird. Diese Eigenschaft unterstützt die aktive VM, indem sie die Änderungen erst in ihren Festspeicher übertragen, wenn der betreffende Checkpoint in die Standby-VM übernommen wurde. Erst nach der erfolgreichen Übertragung wird die Meldung an die Clients raus gegeben. Beide virtuelle Maschinen treten gegenüber externen Partnern geschlossen als ein System auf. Sie besitzen dieselbe IP und die Virtualisierungsschicht übernimmt die Verteilung der Pakete. Um die Last des Senderverkehrs zu senken, implementierten die Forscher zusätzlich einen LRU-basierten Cache (Least Recently Used), der nur die Übertragung von veränderten Seiten nötig macht. Zudem werden leere Seiten und Seiten, die aus anderen Seiten berechnet werden können, nicht berücksichtigt. In ihrer Arbeit demonstrieren [MRC11] zudem die Funktion ihres Systems an zwei frei verfügbaren Systemen. Schlussendlich muss betont werden, dass der Bezug zum Self-Healing durchaus besteht, jedoch auch Self-Protection- und Self-Configuration-Eigenschaften durch das System sichergestellt werden.

99 82 Ansätze des Self-Healings 5.3. Vergleich und Zusammenfassung In diesem Abschnitt sollen Mechanismen und Systeme, welche Self-Healing-Eigenschaften aufweisen und in dem vergangenen Kapiteln genannt wurden, gesamtheitlich beurteilt werden. Darüber hinaus wird ein Überblick gegeben, welche Bedrohungen und Gefahren aus dem Kapitel 4 mit ihnen eliminiert werden können. Diese Zusammenfassung ist Self-Healingspezifisch und existiert in gleichem Maße für die Self-Protection-Eigenschaften im Kapitel 6.3. Am Ende dieser Arbeit wird im Kapitel 7 zusammenfassend über beide Maßnahmen resümiert sowie ein Ausblick auf zukünftige Mechanismen und Systeme gegeben. Self-Healing, wie es umfassend im Kapitel 3.3 beschrieben wurde, zeichnet sich vor allem dadurch aus, dass durch diese Eigenschaften Systeme sich eigenständig von einem anormalen Status heilen und somit von einem ungesunden Status zurück zu einem gesunden Status genesen sollen, als wäre dieser Fehler nie aufgetreten (vgl. [S 2164 [GSR06]]). Viele der aufgeführten Systeme und Mechanismen tragen diesem Ansinnen auch Rechnung. Zu bemerken ist jedoch, dass die in der Forschung befindlichen Systeme und Mechanismen ihrem Pendant aus etablierten Systemen einiges voraus sind. So haben die derzeitigen Marktführer nur in einigen wenigen Ausnahmen tiefgreifende Abwehrmechanismen für Angreifer implementiert. Sicher entspricht es einer Kausalitätskette, dass aufgrund der Schwächen der vorhandenen DBMS weltweit Forscher Mechanismen und Systeme entwickeln, die diese Mangel zu beseitigen versuchen. Nur sind einige brauchbare Forschungsbeiträge schon länger veröffentlicht, ohne dass einer der Branchenriesen dieses zum Anlass genommen hätte, die Systeme diesbezüglich zu erweitern. Es ist durchaus verständlich, dass eine Erweiterung oder eine Verbesserung tiefgreifender Art nicht unmittelbar ihren Einzug in produktive Systeme finden kann, aber längerfristig oder gänzlich darauf zu verzichten, stellt für keinen Kunden ein zufriedenstellendes Ergebnis dar. Eine Übersicht aller in dieser Arbeit genannter Systeme und Mechanismen des Self-Healings sowie eine Gegenüberstellung mit den im Kapitel 4 aufgeführten Bedrohungen (blau) und Gefahren (orange), wird in Tabelle 7 vorgenommen.

100 User Error External System Failure External Software Failure Internal System Failure Internal Hardware Failure Backup Data Exposure Weak Authentication Database Communication Protocol Vulnerabilities Denial of Service Weak Audit Trail SQL Injection Platform Vulnerabilities Privilege Elevation Legitimate Privilege Abuse Excessive Privilege Abuse Ansätze des Self-Healings Data Mirroring Session X Wartungsarbeiten X X X X X X X Automatic Failover X X X X X X Statistisches Management X Deadlockbeseitigung X Health Monitor X X X X X Fehler bei Transaktionen X X X X Wachsen bei Platzmangel X Workload- X Rehabilitierung Index- u. X Tabellenorganisation Anpassung DB-Design X ITDB X X X X X Optimierung von ITDB X X X X X Rainbow-Projekt X X X X X X X X X Shaman X Inter-Transaction X X X X X X X X X Dependency Intrusion-Resilient DBMS X X X X X X Cloud Computing X X X X X X X RemusDB X X X X X Tabelle 7: Auswertung der Self-Healing-Mechanismen und -Systeme Self-Healing-Mechanismen der drei etablierten Systeme Wie aus Tabelle 7 hervorgeht, setzen die aktuellen Forschungsbeiträge vor allem dort an, wo die etablierten Systeme keine Mechanismen zum Self-Healing ausgebildet haben. Zu berücksichtigen gilt jedoch, dass die abgebildeten Abhängigkeiten unvollständig sind, da es sich lediglich um Self-Healing-Eigenschaften handelt. Aus diesem Grund spiegelt die Tabelle nur einen Teil der wahren Abhängigkeiten wider, welcher beispielsweise durch die Abhängigkeiten der Self-Protection ergänzt werden könnten.

101 84 Ansätze des Self-Healings Des Weiteren ist aus der Tabelle zu ersehen, dass herkömmliche Systeme vor allem auf die Rehabilitierung von den im Abschnitt 4 als Gefahren (orange) bezeichneten Fehlerquellen ausgelegt sind, welche ohne direkten oder nur durch unbeabsichtigten menschlichen Einfluss entstehen (Internal Hardware Failure; Internal System Failure; User Error). Für diese Gefahren wird in einigen wenigen Fällen (siehe Kapitel 5.1.1; 5.1.3; 5.1.5) eine Auflösung durchgeführt, ohne dabei die Datenbank vom Netz trennen zu müssen. In den meisten anderen Fällen, vor allem aber bei fast allen Bedrohungen, muss das DBS offline wiederhergestellt werden. Somit kann der von [GSR06] aufgestellten Thesen, bezogen auf derzeit am Markt befindliche, etablierte Systeme, zugestimmt werden. Sie unterstreichen in ihrer Arbeit die Wichtigkeit des Wiederherstellungsvorgangs insoweit, dass sie das Self-Healing als Recovery Oriented Computing bezeichnen und zudem wie einige andere Forscher auch, dass Self- Healing als ein erweitertes Recovery Modell ansehen (vgl. [S 62 ff. [CBF04]]). Es muss zudem eingeräumt werden, dass einige der vorgestellten Self-Healing-Mechanismen (siehe Kapitel 5.1.2; 5.1.4; 5.1.9) nur indirekt dem Self-Healing zugeordnet werden können. Dieses ist jedoch der Vollständigkeit halber geschehen und wird als alternative Herangehensweise betrachtet. Der Grund für die Zuordnung kann dem jeweiligen Kapitel entnommen werden. Andere Mechanismen (siehe Kapitel 5.1.8; ), die auf der ersten Blick wiederum nicht wirklich passend erscheinen, haben bei genauerer Betrachtung durchaus Self-Healing-Eigenschaften. So erfüllt das automatische Wachsen bei Speichermangel (siehe Kapitel 5.1.8) eigentlich alle Eigenschaften, die einem Self-Healing-Mechanismus genügen. Auf Grund seiner bereits längerfristigen und elementaren Existenz, erscheint dieses jedoch zunächst abwegig. Ein weiterer Teil der vorgestellten Mechanismen (siehe Kapitel 5.1.2; 5.1.4; 5.1.6) hat zwar Self-Healing-Eigenschaften implementiert, arbeitet aber nicht vollkommen autonom, sondern ist immer noch von menschlichen Einwirkungen abhängig. So können Implementierungen unterschieden werden, die den Menschen bei unberücksichtigten Fehlern einbeziehen (siehe Kapitel 5.1.2; 5.1.6) und Informationen sammeln, aufbereiten und darauf aufbauenden Mechanismen und dem domainspezifischen Wissen des DBAs zur Verfügung stellen (siehe Kapitel 5.1.4). Es ist also festzuhalten, dass aus heutiger Sicht die drei etablierten DBMS einen ununterbrochene Verfügbarkeit bzw. einen dauerhaften intakten Betriebszustand vor allem

102 Ansätze des Self-Healings 85 dadurch gewährleisten, dass durch interne oder externe Systemfehler beeinträchtige Komponenten vom System abgetrennt werden und erst nach der Reparatur wieder ins System integriert werden oder das gesamte System zeitweilig vom Netz genommen wird, um es wiederherzustellen (vgl. [Orac02]). Self-Healing-Mechanismen aus Forschungsbeiträgen Bei den aktuellen Forschungsansätzen zeigt sich ein etwas anderes Bild. Wie bereits erwähnt setzen sie vor allem an Stellen an, bei denen etablierte DBMS an ihre Grenzen stoßen. So verfolgen Sie vor allem das Ziel, die vier verschiedene Eben eines DBMS (Prozessor-, Betriebssystem-, Datenbankmanagement- und Transaktions- oder Applikations-Ebene) vor Angriffen zu schützen (siehe Kapitel 4). Welche der Ebenen dabei attackiert wird, hängt elementar von der Verwendung und dem Einsatzgebiet des DBMS ab. Ein DBMS, welches zur Verwaltung von Daten eines Webservers genutzt wird, ist mehrheitlich anderen Gefahren ausgesetzt als das Offline-System einer Personalverwaltung. Darüber hinaus unterscheidet sich auch die Intensität und Quantität der Angriffe je nach Anwendungsfall. Das Self-Healing beschränkt sich in fast allen der aufgeführten Forschungsbeiträge auf die Datenbankmanagement- und Transaktions-Ebene. Nur der Ansatz mittels Remus bzw. RemusDB (siehe Kapitel 5.2.8), welcher virtuelle Maschinen nutzt, bietet die Möglichkeit bei einer Verletzung der Gesamtsystemintegrität, das gesamte System inkl. aller darauf laufenden Programme zurück in einen konsistenten Zustand zu überführen. Die größte Gruppe der aufgeführten Forschungsbeiträge (siehe Kapitel 5.2.1; 5.2.2; 5.2.5; 5.2.6) widmet sich der Intrusion Detection bzw. dem Self-Healing auf Transaktions-Ebene. Neben der reinen Aufdeckung und Heilung schadhaft veränderter Transaktionen, sind es aber auch darauf aufbauenden Transaktionen, die analysiert und ggf. zurückgerollt werden. So ist andernfalls damit zu rechnen, dass einmal erfolgreich ausgeführte, schadhafte Transaktionen, ihre fehlerhaften Informationen weiter streuen (Damage Spreading). Besonders absetzen kann sich an dieser Stelle vor allem das Portable Implementation Framework for Intrusion- Resilient Database Management Systems (siehe Kapitel 5.2.6), welches gegenüber den anderen Systemen über eine Probabilität verfügt und somit übergreifend einsetzbar ist. Die letzte Gruppe der aufgeführten Forschungsbeiträge wird durch die vorkonfigurierten Self- Healing-Systeme gebildet (siehe Kapitel 5.2.3; 5.2.4; 5.2.7). Diese drei Systeme haben ein

103 86 Ansätze des Self-Healings Framework zu Grunde liegen, welches vorkonfigurierte Problemklassen identifizieren kann, um anschließend wiederum voreingestellte Problemlösungen anzuwenden oder verschiedene voreingestellte Lösungsvorschläge miteinander kombinieren lässt, um eine Lösung zu erlangen. Diese drei Arbeiten haben aber gemeinsam, dass die möglichen Probleme und deren Lösungsstrategien vom DBA bedacht werden müssen. Wird ein fehlerhafter Zustand ungenau beschrieben, kann dies zu ungenügenden Lösungen führen. Im Fall des Rainbow-Projekts (siehe Kapitel 5.2.2) und Self-Healing and Hybrid Diagnosis in Cloud Computing (siehe Kapitel 5.2.6) wurde in das System infolge dessen ein Kreislauf integriert, welcher zur ständigen Verbesserung des Gesamtsystems und somit zur Eliminierung unzureichender Lösungen führt.

104 Ansätze der Self-Protection Ansätze der Self-Protection In diesem Kapitel werden die erarbeiteten Sicherheitsvorkehrungen aus Echtzeitsystemen oder Forschungsbeiträgen den im Kapitel 4 aufgeführten Bedrohungen und Gefahren gegenübergestellt und es wird aufgezeigt, inwieweit diese eliminiert werden Mechanismen in konventionellen Systemen In diesem Abschnitt werden Mechanismen der drei verbreitetsten DBMS aufgezeigt, welche im weitesten Sinne der Self-Protection zugeordnet werden können. Es wird zum Anfang jedes Abschnittes Bezug genommen, vor welchen Bedrohungen und Gefahren der jeweilige Mechanismus schützt (vgl. Kapitel 4). Damit die Beiträge einem spezifischen System zugeordnet werden können, wird vor jedem Inhaltsblock das betreffende DBMS genannt Verschlüsselung von Prozeduren und Funktionen Der nachfolgend aufgeführte Self-Protection-Mechanismus schützt Funktionen und Prozeduren vor äußeren Veränderungen und vor äußerer Einsicht Dritter. Dieser Sicherheitsmechanismus schützt somit vor Bedrohungen (Privilege Elevation; Backup Data Exposure), welche im Kapitel 4 genannt wurden. SQL Server - Gespeicherte Prozeduren (Stored Procedures) oder Funktionen (User Defined Functions) können zum Schutz vor Diebstahl oder externer Modifikation vom SQL Server verschlüsselt abgelegt werden. Die Verschlüsselung ist eine Einweg-Funktion und nicht reversibel. Es ist demnach nicht möglich einmal verschlüsselte Methoden mit SQL-Mitteln zu entschlüsseln. Wenn die Methode einmal ausgeführt und der Code an keiner Stelle im Klartext abgelegt wird, ist der Code nicht wiederherstellbar. Für die sichere Verschlüsselung und Ablage ist ausschließlich der SQL Server zuständig, der DBA hat lediglich zu spezifizieren, dass das System mit Verschlüsselung (Encryption) arbeiten soll Query- und Ressourcen-Kontrolle Der im Folgenden aufgeführte Self-Protection-Mechanismus sichert die ununterbrochene Arbeitsfähigkeit eines DBMS ab. Er schützt primär vor Gefahren (User Error; Internal Hardware Failure; Internal System Failure), welche das System beeinträchtigen können.

105 88 Ansätze der Self-Protection IBM DB2 - Der Configuration Advisor dient in DB2 der Verwaltung der Arbeitsauslastung und -Ressourcenfreigabe. Die einzuhaltenden Grenzen werden von den Administratoren anfangs festgelegt und der Configuration Advisor sorgt eigenständig für deren Umsetzung. Es existieren über fünfunddreißig Parameter, welche spezifiziert werden können. Darüber hinaus steuert der Configuration Advisor die Hauptspeicherareale des Systems zentral und autonom. Zudem existiert der DB2 Query Patroller, welcher eine Art Torwächter für den DB2- Datenbankserver darstellt, indem er Datenbankanfragen analysiert, akzeptiert oder ablehnt, priorisiert und den Nutzer benachrichtigt. Geführt von bestehenden Policies, die vom Administrator parametrisiert wurden, versucht er langlaufende Anfragen gleichmäßig zu verteilen und garantiert darüber hinaus ausreichend Ressourcen für bereits laufende Anfragen. Hand in Hand mit Query Patroller und Configuration Advisor arbeitet der Ressourcen Manager, welcher für den Schutz des Systems bei umfassenden Workloads (Arbeitsaufkommen) zuständig ist. Der Ressourcen Manager unterscheidet viele gleichzeitig abzuarbeitende Workloads nach ihrer Art und dem Arbeitsumfang und gibt je nach Art des Workloads vom Nutzer spezifizierte Ressourcen frei (vgl. [TN01]). So ist es möglich eingehende Verbindungen und die Ressourcen-Verwendung zu klassifizieren, Ressourcen zusammenzufassen und Einschränkungen zu setzen, Workloads zu gruppieren und diese Ressourcen-Pools zuzuweisen und Workloads zu identifizieren und zu priorisieren. Außerdem unterscheidet der Ressourcen Manager drei Typen von Ressourcenproblemen vor denen er schützen soll bzw. die er im Stande ist, aufzulösen: Runaway-Abfragen auf dem Server: Eine ressourcenintensive Abfrage will die meisten oder alle Serverressourcen beanspruchen. Unvorhersehbare Workload-Ausführung: Zwei konkurrierende Anwendungen generieren Workloads von verschiedener Größe und Typ, welche nicht voneinander isoliert werden und so verursacht der resultierende Ressourcenkonflikt eine unvorhersehbare Workloadausführung. Das Festlegen von Arbeitsauslastungsprioritäten: Ein Workload kann schneller ausgeführt werden als ein anderer oder wird bei Ressourcenkonflikten garantiert abgeschlossen (vgl. [MS09]).

106 Ansätze der Self-Protection 89 Oracle Database - Seit Oracle 9i beinhaltet das DBMS von Oracle ein automatisiertes Speichermanagement der Globale Programmbereich (Program Global Area - PGA), welche exklusive Daten und Kontrollinformationen des Serverprozesses beinhaltet. Hinzu kam bei Oracle 10g das automatische Management des globalen Systembereichs (System Global Area - SGA), der dem DBMS bei Systemstart zugeordnet wird und Daten und Steuerungsinformationen alle Oracle-Prozesse enthält. Oracle bezeichnete diese Komponente des Speichermanagements als Automatic Shared Memory Management (ASMM), welches die Verteilung des Speichers bezüglich des Arbeitsaufkommens und Anforderungen von Datenbankobjekten zur Aufgabe hat (vgl. [S 2 ff. [RMS10]]). Mit Oracle 11g wurde das Management weiter verbessert, indem nur noch ein Parameter gesetzt werden muss, mit dem das System dynamisch und selbstständig beide Speicherbereiche verwaltet. Durch die Möglichkeit die Speicherbereiche automatisch anzupassen, kann das System sich selbst vor einem Performanceeinbruch durch Speichermangel schützen. Außerdem ist es möglich, Prioritäten für diverse Entitäten zu vergeben, damit diese bei der CPU-Zeit und Speichervergabe bevorzugt oder benachteiligt werden können Identitäts- und Zugriffssteuerung Der nachfolgend aufgeführte Self-Protection-Mechanismus schützt vor Bedrohungen (Excessive Privilege Abuse; Legitimate Privilege Abuse; Privilege Elevation; Weak Authentication), welche das System durch unautorisierten Zugriff gefährden. SQL Server - Um bei der Fülle der vorhandenen Möglichkeiten jedem Benutzer, Dienst oder andere Konten die Zugriff auf das System haben, die richtigen Berechtigungen zu erteilen, hat der SQL Server ein umfassendes Rechtemanagement. Wenn diese Rechte erst einmal vergeben sind, läuft die eigentliche Autorisierung intern und vollkommen autonom ab. Diese Zugriffssteuerung gilt für sämtliche Instanzen, die vom SQL Server Ressourcen anfordern können. Die Entitäten werden von Microsoft mit dem Terminus "Prinzipale" benannt. Zudem unterscheidet der SQL Server nach dem Definitionsbereich des Prinzipals (Windows, Server, Datenbank) und danach, ob der Prinzipal unteilbar ist oder es sich um eine Auflistung handelt (vgl. [MS10]). So ist ein Windows-Anmeldename ein Beispiel eines unteilbaren Prinzipals, wohingegen eine Windows-Gruppe eine teilbare Auflistung darstellt. Neben Prinzipalen, die natürliche Personen abbilden, existieren auch Prinzipale für Anwendung mit eigenen Berechtigungen (Anwendungsrollen) sowie vollkommen losgelöste, abstraktere Datenbankschemata. Wobei Schemata Container von Objekten bezeichnen, die im Besitz

107 90 Ansätze der Self-Protection eines oder mehrerer beliebiger Benutzer sein können und grenzenlos übertragbar sind. Damit nicht jeder Prinzipal einzeln verwaltet werden muss, stellt der SQL Server mehrere Sicherheitsprinzipale zur Verfügung, die andere Prinzipale gruppieren können und als Rollen bezeichnet werden. Neben den vom SQL Server intern verwendeten Prinzipalen und Rollen, existieren auch Anmeldeinformationen zur Verbindung mit externen Ressourcen. Anmeldeinformationen sind in einem Datensatz gespeichert, in dem die Authentifizierungsinformationen enthalten sind und werden intern von SQL Server verwendet. Die meisten Anmeldeinformationen enthalten einen Windows-Benutzernamen und ein Kennwort (vgl. [MS11]). Oracle Database und DB2 - Auch Oracle und DB2 beherbergen Authentifizierung und Sicherheitsmechanismen in denen verschiedenste Privilegien an Benutzer vergeben werden. Einige Features sind Netzwerk-Verschlüsselung, Strong Authenticaton (z.b. Kerberos, Smart Cards oder Digitale Zertifikate), virtuelle und private Datenbanken, LDAP, Spalten- und Reihenverschlüsselung und noch einige andere Modulsignierung Der nachfolgend aufgeführte Self-Protection-Mechanismus schützt vor Bedrohungen (Legitimate Privilege Abuse; Privilege Elevation; Weak Authentication), welche das System durch unautorisierten Zugriff und nicht autorisierte Ausführung von Systemmodulen gefährden. Die Modulsignierung unterscheidet sich grundlegend von der im Kapitel aufgeführten Verschlüsselung, da diese keinerlei Authentifizierung durchführt, sondern lediglich Source Code vor unautorisierter Einsicht bewahrt. SQL Server - Ab der Version 2005 bietet der SQL Server die Möglichkeit, Module innerhalb der Datenbank zu signieren. Ein Modul bezieht sich in diesem Kontext auf eine gespeicherte Prozedur, eine Funktion, einen Trigger oder ein Assembly. Bei einer digitalen Signatur handelt es sich um einen Datenextrakt (Data Digest), das mit dem privaten Schlüssel des Signaturgebers verschlüsselt wurde (vgl. [AJS00]). Durch den privaten Schlüssel ist sichergestellt, dass die digitale Signatur eindeutig vom Träger oder Besitzer der Signatur stammt. Zum Signieren der Daten erstellt der Signaturgeber eine Datenauswahl, verschlüsselt diesen mit einem privaten Schlüssel und fügt den verschlüsselten Digest-Wert an die Daten an. Der Signaturempfänger überprüft die Signatur, indem er den verschlüsselten, an die Daten angefügten Digest-Wert mithilfe des öffentlichen Schlüssels des Signaturgebers entschlüsselt.

108 Ansätze der Self-Protection 91 Der Signaturempfänger vergleicht diesen verschlüsselten Digest-Wert mit dem Digest-Wert, der für die angefügten Daten berechnet wurde. Wichtig ist, dass sowohl der Signaturgeber als auch der Signaturempfänger zum Erstellen des Datendigests dieselbe Funktion verwenden. Wenn ein signiertes Modul ausgeführt wird, werden die erweiterten Rechte eines Prinzipals für die Dauer des Aufrufs mithilfe einer Vereinigung in ihren Laufzeit-Sicherheitstoken aufgenommen. Sobald die Ausführungskontrolle zurückgegeben wird, werden diese Berechtigungen von Ihrem Sicherheitstoken wieder entfernt. Auf diese Weise verfügt der Prinzipal, allerdings nur für die Dauer der Modulausführung, über einen zusätzlichen Satz Berechtigungen (vgl. [MS12]) Self-Auditing und Monitoring zum Systemschutz Der nachfolgend aufgeführte Self-Protection-Mechanismus unterstützt den DBA bei der Sicherstellung der ununterbrochenen Arbeitsfähigkeit eines DBMS. Er schützt primär vor Gefahren (User Error; Internal Hardware Failure; Internal System Failure; External Software Failure; External System Failure), welche das System beeinträchtigen können. Oracle Database - Mit der Version von Oracle 11g wurde das Automatic Diagnostic Repository (ADR) neu eingeführt. Unter ADR ist ein zentrales, auf XML basierendes Repository zu verstehen, welches außerhalb der Datenbank liegt und sich aus diagnostischen Daten zusammensetzt (vgl. [Orac07]). Alle dort zu findenden Informationen musste der Administrator bis dato aus vielen einzelnen Quellen zusammentragen. Zu solchen zählten beispielsweise Core Dumps, Dumps der Hintergrundprozesse, User Trace Files und das Alert- Log. Durch Zusammenfassung der Diagnoseinformationen, auch über mehreren Oracle 11g- Instanzen hinweg, wurde die Fehlerdiagnose bis zu einem gewissen Grad automatisiert. So werden alle benötigten Informationen zentral und automatisch gesammelt und für den Administrator aufbereitet. Der DBA kann so gezielt auf Probleme im System eingehen und das System vor sich ankündigenden Ausfällen schützen oder Flaschenhälsen vorbeugen. Über dies hinaus speichern Automatic Storage Management (ASM), Cluster Ready Service und andere Oracle Produkte und Komponenten ihre Diagnoseinformationen ebenfalls im ADR. Jede Instanz erhält dafür ein eigenes ADR-Verzeichnis, in dem sich dann die Verzeichnisse für Alert-Log, Incident Reports, Problems usw. befinden (vgl. [Orac08]). Neben der Option die Vorfälle direkt vom DBA bearbeiten zu lassen, kann auch der Oracle Support einbezogen werden. Für diesen Zweck verpackt der systeminterne Incident Packaging Service (IPS) alle wichtigen Daten und durchgeführten Testergebnisse selbstständig. Diese können dann ohne

109 92 Ansätze der Self-Protection weiteres Zutun an den Oracle Support versendet werden. Es existiert außerdem der Hang Manager (hangman), welcher Flaschenhälse auf Grundlage des ADR aufzeigt (vgl. [Dba03]). Der Administrator muss sich anschließend solcher Probleme jedoch händisch widmen CLR-Integration und Codezugriffssicherheit Der nachfolgend aufgeführte Self-Protection-Mechanismus schützt vor Bedrohungen (Legitimate Privilege Abuse; Privilege Elevation), welche das System durch Missbrauch externen Programmiersprachen, die an das System angebunden sind, gefährden. SQL Server - Der SQL Server realisiert für eingebetteten Code anderer Programmiersprachen (C#, VB) ein Sicherheitsmodell, das als Codezugriffssicherheit bezeichnet wird. In diesem Modell werden spezielle Berechtigungen auf Grundlage der Identität des Codes gewährt. Der für die Common Language Runtime (CLR) unterstützte Codezugriffssicherheits-Mechanismus basiert auf der Annahme, dass der Server zur Laufzeit sowohl vollständig vertrauenswürdigen als auch einen teilweise vertrauenswürdigen Code beherbergen kann. Die durch die CLR- Codezugriffssicherheit geschützten Ressourcen sind üblicherweise von verwalteten Schnittstellen (API-Schnittstellen) für die Anwendungsprogrammierung umgeben, für die entsprechende Berechtigungen erforderlich sind, bevor ein Zugriff möglich ist. Der Anforderung für diverse Berechtigung kann nur dann statt gegeben werden, wenn alle aufrufenden Prozesse auf Assembly-Ebene in der Aufrufliste über die entsprechende Ressourcenberechtigung verfügen. Die Menge der Codezugriffsberechtigungen, die für verwalteten Code gewährt werden, ist die Schnittmenge der Berechtigungen, die durch Computer-, Benutzer- und Host-Richtlinien erteilt werden (vgl. [MS13]). Auch wenn der SQL Server einer geladenen Assembly einen Berechtigungssatz gewährt, kann der für Benutzercode gewährte Berechtigungssatz durch die Richtlinien auf Computer- und Benutzerebenen weiter eingeschränkt sein. Durch diese vollkommen eigenständig ablaufenden Sicherheitsmechanismen, soll sich der Server selbst vor Kontaminierung durch schädlichen Code schützen Halbautomatisches Backup und Recovery Der nachfolgend aufgeführte Self-Protection-Mechanismus garantiert eine ordnungsgemäße Sicherung und ggf. Wiederherstellung bei Systemfehlern, welche durch Gefahren (Internal

110 Ansätze der Self-Protection 93 Hardware Failure; Internal System Failure; User Error; External Software Failure; External System Failure) verursacht werden. IBM DB2 - In DB2 sind diverse Sicherungs- und Wiederstellungsmodelle integriert, welche eine vollständige Datenbank, einen Teil einer Datenbank, einen Satz von Dateien oder nur Dateigruppen umfassen können. Zudem werden vollständige Sicherungen und differenzielle Sicherungen unterstützt. Mit DB2 ist es möglich, selbstständige Backups in einen Wartungsplan mit niedriger Priorität einzubetten. Das System selbst wird das Backup genau dann anstoßen, wenn die Evaluation des Systemzustandes, auf eine niedrige Systemlast hinweist. Darüber hinaus kann der DBA die Sicherung zyklisch automatisieren. Er muss dafür jedoch im Assistenten jegliche Informationen wie Intervalle, zu sichernde Objekte, Sicherungsmodus und Zielmedium angeben, damit eine periodische oder getriggerte Sicherung möglich ist (siehe dazu Kapitel 5.1.2). Neben den automatisierten Sicherungen können aber auch manuelle Backup- und Recovery-Maßnahmen durchgeführt werden. Die Wiederherstellung der Daten ist jedoch immer manuell durchzuführen Exception- und Error-Behandlung bei Skriptausführung Der nachfolgend aufgeführte Self-Protection-Mechanismus schützt vor Systemausfällen, welche durch Gefahren (User Error; Internal System Failure; Internal Hardware Failure; External Software Failure; External System Failure) provoziert werden können. Bevor auf den eigentlichen Mechanismus eingegangen wird, muss aufgezeigt werden, inwiefern sich Fehler (Error) und Ausnahmen (Exception) unterscheiden. Ein Error tritt auf, wenn etwas während des Betriebes eines Programms gegen die programmierten Richtlinien verläuft. Es ist ein erwarteter, aber nicht erwünschter Umstand. Das gilt auch dann, wenn die auftretende Fehlermeldung nur rein informativ sein sollte. Die Fehlermeldung, dass ein Fragezeichen an einer gewissen Stelle, eine nicht erlaubte Benutzereingabe darstellt, wäre ein Beispiel dafür. Eine Ausnahme hingegen ist ein vom korrekten Betrieb abweichender Umstand, der aufgrund eines exzeptionellen Zustandes eingetreten ist und nicht vorhergesehen werden konnte. So würde ein Exception ausgegeben werden, wenn während einer Übertragung via Netzwerk, der Netzwerkstecker gezogen wird. SQL Server - Anders als viele andere Programmiersprachen, arbeitet der SQL Server (respektive TSQL) mit einem Exception Modell, welches je nach Art der Exception

111 94 Ansätze der Self-Protection verschieden reagieren kann. Der SQL Server abstrahiert zwischen einer Verbindung zu einem Server, einem TSQL-Batch und einzelnen TSQL-Befehlen (vgl. [S 71 ff. [AM09]]). Je nach Typ der Exception wird sie isoliert und kann weiterführend behandelt werden. Dies geschieht, um den Server zu schützen und das Kaskadieren von Fehlern, die im schlimmsten Fall zum Ausfall des DBMS führen, zu vermeiden. Nach der Isolation und Typisierung durch den SQL Server wird dem Systemadministrator eingeräumt, die Exception per CATCH-Block (siehe [TN02]) zu behandeln und ggf. sogar zu ignorieren Verhinderung von Out-Of-Space-Situationen Der nachfolgend aufgeführte Self-Protection-Mechanismus schützt vor Systemausfällen, welche durch Gefahren (Internal System Failure) provoziert werden können. Es ist wichtig darauf hinzuweisen, dass der vorgestellte Mechanismus sich grundlegen von der im Kapitel vorgestellten Query- und Ressourcen-Kontrolle unterscheidet, da er Fehler- und nicht Workload-orientiert seine Arbeit verrichtet. Oracle Database - Während eines Ladevorgangs oder eines Batch-Updates kann es zu Fehlern kommen, welche das System belasten oder gar tiefgreifend behindern. Im ungünstigsten Fall treten solche Fehler erst während des Abschlusses der Operation auf und müssen von Beginn an neu gestartet werden. Durch das Resumable Space Allocation Feature kann Oracle 11g in einer solchen Situation handeln und den aktuellen Status des Batches als ausgesetzt (Suspended) markieren (vgl. [Orac03]). Anschließend muss der Administrator benachrichtigen werden, der sich des Fehlers annimmt. Die ausgesetzte Operation wird anschließend sofort weiter ausgeführt, sobald der aufgetretene Fehler behoben wird. Falls es sich um ein vorübergehendes Problem gehandelt haben sollte, setzt das System die Verarbeitung anschließend automatisch und ohne äußere Einflüsse fort Aktuelle Forschung und Prototypen In diesem Abschnitt werden Mechanismen und Systeme der aktuellen Forschungen aufgezeigt, welche Self-Protection-Eigenschaften implementiert haben. Es wird zum Anfang jedes Abschnittes Bezug genommen, vor welchen Bedrohungen und Gefahren der jeweilige Mechanismus schützt (vgl. Kapitel 4).

112 Ansätze der Self-Protection How to build a trusted database system on untrusted storage [MVS06] Das nachfolgend aufgeführte Self-Protection-System verhindert den externen, unautorisierten Zugriff auf das DBMS. Es schützt vor Bedrohungen (Platform Vulnerabilities; Database Communication Protocol Vulnerabilities), welche im Kapitel 4 beschrieben wurden. In der heutigen Zeit sind die Anwesenheit von Fehlern und Sicherheitslücken durch die hohe Verteilung der Daten (Verteilte Datenbanksysteme) statistisch unvermeidbar (vgl. [S 2 [DCL06]]). Das von [MVS06] entwickelte System TDB implementiert eine Architektur eines vertrauenswürdigen Datenbanksystems (Trusted Database), welches einen minder großen vertrauenswürdigen Speicherplatz dazu benutzt, einen weitaus größeren nicht vertrauenswürdigen Speicher, nämlich den einer Datenbank, zu schützen. Die primäre Intention dabei war, nicht autorisierten Programmen weder lesenden noch schreibenden Zugriff auf die Daten zu gewähren. Die gesamte Datenbank bzw. der Speicher, der für die Datenbank genutzt wird, ist verschlüsselt durch geheime Schlüssel (Keys), welche im vertrauenswürdigen Speicherbereich hinterlegt sind. Würde jedoch ausschließlich der Key zur Verschlüsselung herangezogen werden, könnte jeder Angreifer, der den Schlüssel während einer Kommunikation extrahiert, zu einem späteren Zeitpunkt eine erfolgreiche Autorisierung durchführen können. Jenes ist auch möglich, ohne den Klartext des Schlüssels zu kennen. Einem solchen Replay-Angriff entgegnen die Forscher jedoch, indem sie in TDB einen fälschungssicheren Counter implementierten, welcher nicht dekrementiert werden kann. Der Counter erhöht sich nach jedem Datenbankzugriff und es wird ein Zertifikat erzeugt, welches den aktuellen Stand des Counters und einen Hash des derzeitigen Datenbankzustandes beinhaltet. Dieses Zertifikat wird wiederum im nicht vertrauenswürdigen Speicher abgelegt und mit einem geheimen Schlüssel signiert. Nur mit dem neuesten Zertifikat und im Zusammenspiel mit dem geheimen Schlüssel ist es möglich, Daten zu lesen. Um die Daten verändern zu können, ist ein vertrauenswürdiges (signiertes) Programm unabdingbar. Sollte eine externe, nicht autorisierte Veränderung der Daten stattfinden, wird der fehlerhafte Hash beim nächsten Lese- oder Schreibvorgang von einem autorisierten

113 96 Ansätze der Self-Protection Programm erkannt und die Daten aus dem Archival Store wiederhergestellt. Nachfolgend bildet Abbildung 25 den genannten Sachverhalt ab. Abbildung 25 : Architektur TDB (vgl. [MVS06]) Nach erfolgreichen Schreibvorgängen von vertrauenswürdigen Programmen auf Datenbankobjekte, wird der Datenbankhash immer wieder verändert und validiert, indem TDB eine Baumstruktur von Hashwerten über die Datenbankobjekte führt und pflegt. TDB integriert diese Verschlüsselung durch ein Low-Level Datenmodel, welches gleichzeitig Daten und Metadaten schützt, was bei konventionellen Datenbanksystemen so nicht der Fall ist. Es kann mit dieser Technik somit garantiert werden, dass unbefugte Programme weder lesend noch modifizierend auf die Daten zugreifen können, auch dann nicht, wenn sie eine Kommunikation belauschen und den verschlüsselten Key extrahieren können (vgl. [S 2 [MVS06]]) Towards Self-Protection Ubiquitous Systems: Monitoring trust-based interactions [ETN05] Das nachfolgend aufgeführte Self-Protection-System schützt das DBMS vor böswilligen Angriffen bzw. Benutzerfehlern auf Transaktionsebene. Es bewahrt das System sowohl vor Gefahren (External Software Failure; User Error), als auch vor Bedrohungen (Excessive

114 Ansätze der Self-Protection 97 Privilege Abuse; Legitimate Privilege Abuse; Privilege Elevation; Weak Authentication), welche im Kapitel 4 beschrieben wurden. Die als Informationszeitalter bezeichnete derzeitige Wirtschafts- und Gesellschaftsform (vgl. [S 9 [Spi94]]) ist gekennzeichnet durch die zentrale Bedeutung und die Abhängigkeit von Informationen im alltäglichen Gebrauch. Mit der Bedeutsamkeit der Daten gewinnt jedoch auch der Datenschutz der sensiblen Daten an Gewicht (siehe [Cas01], [PK03]). Des Weiteren kann jeder Partizipant dieses Informationszeitalters mit neuen und verbesserten Technologien, bis dahin unberührte Sachverhalte erforschen oder Wissen vertiefen. Wie bereits im Abschnitt 3.3. Herkunft und Einordnung des Self-Healings ausgeführt wurde, ist unter anderem das Ubiquitäre Computing ein Erfolg versprechender Ansatz für zukünftige Vorhaben (siehe [DB10], [S 189 [FRG19]], [FH01]). Die Sicherung mittels selbstschützenden Mechanismen, der an einer ubiquitären Kommunikation beteiligten Entitäten, beschreiben [ETN05] in ihrer Arbeit ausführlich. Ein besonderes Augenmerk wird auf diese Arbeit gerichtet, da der Datenspeicherung und Weiterverarbeitung, der in einem ubiquitär arbeitenden System massenhaft auftretenden Daten, eine enorm große Bedeutung zukommt und sie deshalb besonders schützenswert machen. [ETN05] heben hervor, dass auf Grund der hohen Verteilung der Systeme und der Heterogenität der Entitäten selbst, sie keinesfalls einer globalen Kontrollautorität unterstehen können, da keine globale Sicht im herkömmlichen Sinne existiert. Der Datenaustausch, mit dem System unbekannten Partnern, erfordert viel mehr einen aktiven Selbstschutz. Des Weiteren sahen die Forscher das Trust Management, was im Abschnitt 3.4 bereits hinreichend erläutert wurde, als ein optimales Ausgangsparadigma an, auf welchem aufgebaut werden konnte. Sie identifizierten jedoch den Nachteil des Trust Managements, dass erst nach Beendigung die Nachweise vorliegen, ob es sich um eine gut- oder bösartige Interaktion handelt, als äußerst kritisch. Aus diesem Grund erweiterten sie das Paradigma um einen Monitor, der zur allgemeinen Nutzung den meisten Anwendungen zur Verfügung steht. Außerdem entwickelten sie ein darunter liegendes Interaktionsmodell, welches die betreffenden Interaktionen und die daraus resultierenden Verrechnungen erkennen können muss. Das Interaktionsmodell beschreibt jede Interaktion durch Parameter, welche zusammen genommen einen Trust-Value ergeben. Diesen Trust-Value nutzt das System zusammen mit einem kostenbasierten Faktor, um eine Risikoanalyse durchzuführen. Darüber hinaus speichert das System Prozessschritte der Verarbeitung, um den Verlauf abbilden zu können.

115 98 Ansätze der Self-Protection Da dieses Modell sowohl die Interaktionen selbst, als auch deren Wirkungsbereich betrachten kann, ist es in der Lage, eine genaue Einschätzung der Interaktion durchzuführen. Dem Monitor wird es mit dem umfassenden, darunter liegenden Modell ermöglicht, die Interaktion an jeder Stelle zu unterbrechen und Schaden vom System abzuwenden. Veränderungen oder Anpassungen des Modells können zu jeder Zeit und sowohl aus den direkten Erkenntnissen des Modells selbst, d.h. von aufgefundenen Anschlägen, die das Modell entlarvt hat, als auch durch die vom Trust Management übernommene Evaluierung des Endzustandes, übernommen werden Towards Database Firewall: Mining the Damage Spreading Patterns [BL07] Das nachfolgend aufgeführte Self-Protection-System setzt auf herkömmlichen DBMS auf und schützt vor schadhafter Verteilung fehlerhafter Daten auf Transaktionsebene, welche durch Gefahren (User Error; External Software Failure) oder Bedrohungen (Excessive Privilege Abuse; Legitimate Privilege Abuse; Privilege Elevation; Weak Authentication) entstehen können. Sicher geglaubte Daten in modernen DBMS werden durch Benutzerfehler, bösartige Absichten von Insidern und durch Schwachstellen des Systems, die von Fremden ausgenutzt werden, immer wieder gefährdet. Herkömmliche Methoden (Backup und Recovery) bedingen jedoch zumeist, dass die Daten zeitweilig vom Netz getrennt werden müssen. Das dies in den meisten Fällen nicht möglich sein wird, wurde bereits mehrfach erwähnt. Eine weitere wichtige Rolle spielen die Bedeutung und die Schutzbedürftigkeit sensibler Daten (Banken, Militär, Forschung etc.)(vgl. [S 253 ff. [KV03]]). [BL07] entwickelten aus diesen Gründen eine Database Firewall, welche Daten vor schadhaftem Einfluss oder unerlaubter Einsichtnahme bewahren soll. Besonders spezialisiert haben sich die Forscher dabei auf die Verhinderung und Erkennung der Streuung von Schaden (Damage Spreading) auf Transaktionsebene. Damage Spreading ist der direkte oder indirekte schädliche Einfluss, den Transaktionen auf ihre Nachfolger ausüben (vgl. [ZL04]), wenn diese auf denselben Daten arbeiten. So ist es in relativ kurzer Zeit möglich, dass der Schaden einer bösartig veränderten Transaktion sich auf viele weitere Datenobjekte überträgt, wenn nachfolgende Transaktionen von der Änderung der ersten Transaktion betroffen sind. Welche Angriffsmöglichkeiten sich auf der Transaktionsebene ergeben und weitere allgemeine Erläuterungen finden sich im Kapitel 4.

116 Ansätze der Self-Protection 99 Forschungen, welche von [BL07] durchgeführt wurden, zeigten, dass das Damage Spreading eindeutige Muster aufweist und sogenannte Damage Spreading Pattern nachzuweisen sind. Die Forscher identifizierten im Zuge dessen zwei Typen von Damage Spreading Patterns - one-hop spreading und multi-hop spreading. Als one-hop spreading bezeichnen die Forscher Veränderungen an Datensätzen, bei denen die Transaktion auf derselben Entität liest, bevor sie eine Veränderung durchführt. Multi-hop spreading kann hingegen neben der gelesenen Entität auch andere Entitäten verändern. Die Forscher deklarieren Veränderungen, die ausschließlich auf eine Entität begrenzt sind, als Island (Insel). Die aus [BL07] entnommene Abbildung 26 soll diese Abhängigkeiten verdeutlichen. Abbildung 26: One-hop und multi-hop spreading (vgl. [BL07]) Darauf aufbauend entwickelten die Forscher einen Algorithmus, der die genannten Muster aufspürt und die Integrität der streuenden Modelle berechnen kann. Die bekannten Muster werden durch diverse Parameter spezifiziert und es wird damit ein Bayessches Netzwerk aufgebaut, welches die Wiedererkennung anhand der Parameter ermöglicht. Es existiert ein Attack Detector, welcher Attacken aufspüren kann, sowie ein Damage Assessor, der betroffene Daten aus Log- und Audit-Dateien identifiziert. Der Integrity Estimator bestimmt