Diplomarbeit zur Erlangung des akademischen Grades

Transkript

1 Diplomarbeit zur Erlangung des akademischen Grades Diplom-Informatiker an der Technischen Universität Dresden SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN Technische Universität Dresden Fakultät Informatik Institut für Systemarchitektur Professur Rechnernetze D Dresden, Germany Name: Matrikel-Nr.: Studiengang: Betreuer: T-Systems Multimedia Solutions GmbH Innovation & Internationalisierung New Business Development Riesaer Str. 5 D Dresden, Germany Mario Müller Diplom-Informatik Dr.-Ing. Stephan Groß (TU Dresden) Mario Kretzschmar (T-Systems MMS) Roman Kempter (T-Systems MMS) Verantwortlicher Hochschullehrer: Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill Institut: Systemarchitektur Begonnen am: 01. Februar 2012 Eingereicht am: 04. September 2012

2

3

4

5 Selbständigkeitserklärung Ich erkläre, dass ich die vorliegende Diplomarbeit mit dem Titel Sichere Nutzung von Cloud-Storage in Datenbanken selbständig, unter Angabe aller Zitate und nur unter Verwendung der angegebenen Literatur und Hilfsmittel angefertigt habe. Dresden, den 4. September 2012 Mario Müller

6

7 INHALTSVERZEICHNIS 1 Einleitung Ziele der Arbeit Aufbau der Arbeit Grundlagen Cloud Computing Cloud-Organisationsformen Cloud-Dienstmodelle Mehrseitige Sicherheit Schutzziele Vertrauensbereich Datenbankmanagementsysteme Analyse Sicherheit in Datenbanksystemen Konzelation in Datenbanksystemen Storage Level Encryption Database Level Encryption Application Level Encryption Zusammenfassung Konzelation Cloud-Storage Eventual Consistency Cloud-Storage auf Datenbankebene Cloud-Storage auf Dateisystem-Ebene Vergleich...51

8 3.6 Anforderungsanalyse Systementwurf Proxy-Architektur Schnittstelle Datenbankserver Block Cache Verfügbarkeits-Komponente Integritäts-Komponente Vertraulichkeits-Komponente Schnittstelle Speicherserver Verwaltung der Meta-Daten Arbeitsweise / Verhalten des Proxys Leseanfragen an Proxy durch Datenbanksystem Schreibanfragen an Proxy durch Datenbanksystem Allgemeines Schreib-Verhalten des Proxys Implementation Proxy-Technik Dateisystem (FUSE) Block-Cache Meta-Datenbank (MySQL) Dispersion (Jerasure) Prüfsummenbildung (OpenSSL) Konzelation (OpenSSL) Web-Management (Apache) Evaluation FS - Das System soll übliche Dateisystemfunktionalität bieten FF - Das System soll das Laden und Speichern beliebiger Dateien ermöglichen FD - Datenbanksystemen soll eine einfache Dateisystem-Schnittstelle geboten werden...99

9 6.4 FU - Die Dateisystem-Schnittstelle soll universell sein FC - Alle Datei-Modifikation sollen direkt in der Cloud vorgenommen werden FL - Die Latenz des Systems soll möglichst gering sein FM - Das System soll multiple parallel nutzbare Zugriffspunkte bieten FN - Das System soll gegenüber diesem parallelen Nutzer-Betrieb skalieren können FC - Daten die den eigenen Vertrauensbereich verlassen, müssen ausreichend vor unberechtigten Zugriffen geschützt sein FA - Die lokale Verfügbarkeit der Cloud-Daten muss gewährleistet sein FI - Verletzungen der Daten-Integrität müssen erkannt und behoben werden können FK - Relevante Eigenschaften des Systems sollen konfigurierbar sein FW - Die Adminstration des Proxys soll einfach und grafisch über ein Web-Management möglich sein Zusammenfassung Ausblick...111

10

11 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN 1 EINLEITUNG Cloud-Anbieter träumen davon, dass IT-Ressourcen größtmöglich von ihnen bezogen werden und schlussendlich lokale Geräte nicht viel mehr als Terminals sind, während Programme und Daten tatsächlich in der Cloud liegen und verarbeitet werden. Wie auch auf der letzten CeBIT deutlich wurde, haben die Cloud-Anbieter allerdings erkannt, dass viele potentielle Kunden vor einer generellen oder intensiveren Nutzung der Cloud vor allem aus einem Grund abschrecken: mangelnde Datensicherheit und mangelnder Datenschutz. Dies umso stärker, unter dem regelmäßigen Bekanntwerden kompromittierter Systeme namhafter Konzerne (PSNC 2011), (DB 2011). In die Wolke geschobene Daten unterstehen nicht mehr der physischen Kontrolle ihrer Eigentümer; oft wissen diese nicht einmal, wo ihre Daten liegen. Die Server der CloudAnbieter stehen in riesigen zentralisierten Rechnerfarmen, welche sich in anderen Ländern oder sogar Kontinenten befinden können. So existieren etwa die meisten der CloudRechenzentren in den USA, wo allerdings nur die US-amerikanischen Datenschutz-Gesetze gelten. Auch unterstehen die dort angesiedelten physischen IT-Ressourcen nur dieser Gerichtsbarkeit, und nicht der Justiz der Heimatländer der Cloud-Kunden. Aber selbst außerhalb der USA angesiedelte Rechenzentren sind nicht vor US-behördlichen Zugriffen sicher. So gestand etwa Microsoft, dass sie als US-Unternehmen auf Anfrage von USBehörden auch die Daten europäischer Rechenzentren herausgeben (MU 2012), (Böken 2012). Vor allem Firmen sollten sich also einerseits wegen ihren eigenen Daten Gedanken machen, mit den darin enthaltenen Firmeninterna und besonders schützenswerten Geheimnissen wie Forschungsarbeiten. Andererseits haben sie datenschutzrechtliche Vorgaben zu beachten im Umgang mit Daten, in deren Besitz sie zwar, aber deren Eigentümer sie nicht sind. Darunter zählen etwa private Daten über ihre Mitarbeiter und Kunden. 11

12 KAPITEL 1 - EINLEITUNG 1.1 ZIELE DER ARBEIT Aber natürlich bietet die Nutzung von Cloud-Ressourcen viele Vorteile, so müssen die entsprechenden Ressourcen nicht selbst beschafft, untergebracht, gewartet und administriert werden, sondern können einfach, wie benötigt, angemietet werden. Sicherheit Transparenz Performanz An der Professur Rechnernetze werden deswegen Möglichkeiten erforscht, wie CloudRessourcen sicher genutzt werden können. Insbesondere ist dabei eine Implementierung entstanden, welche es ermöglicht einzelne Dateien sicher in der Cloud abzulegen und nur bei Bedarf lokal vorrätig zu machen (R. Seiger, Gross, et Schill 2011). Aufbauend auf den bereits existierenden Techniken der Professur sollen diese nun so erweitert werden, dass damit auch Datenbanktechnik sicher in der Cloud genutzt werden kann. Das Ziel ist eine Einbindung von Cloud-Ressourcen, insbesondere Speicher, im Datenbankumfeld von Unternehmen. Dies soll allerdings unter der Einschränkung geschehen, dass die in den Daten enthaltenen Informationen auch außerhalb des Firmennetzes vor dem Zugriff Unbefugter sicher sind. Weiterhin soll das Konzept eine möglichst transparente Einbindung des Entwurfs ermöglichen, um diesen unkompliziert in bestehende IT-Strukturen integrieren zu können. Für Nutzer dieses Systems soll die Verwendung von Cloud-Ressourcen und damit verbundenen Techniken, wie etwa bezüglich der Sicherheit, also möglichst unsichtbar sein. Zusätzlich sollen auch Überlegungen bezüglich der Performanz einer solchen Cloud-Lösung mit einbezogen werden. Insbesondere die zu erwartende höhere Latenz gegenüber einer lokalen Lösung und der technische Aufwand, um die Sicherheit zu gewährleisten, werden dabei eine Rolle spielen. 1.2 AUFBAU DER ARBEIT Im folgenden Kapitel werden Grundlagen für die Arbeit, wie Cloud Computing, unter dem Gesichtspunkt von Datenbanksystemen behandelt sowie darauf aufbauend, was dementsprechend für die Sicherheit eines cloud-basierten Systementwurfs zu beachten ist. Daraufhin findet in Kapitel 3 die Problemanalyse statt. Neben einer dominierenden Betrachtung von Sicherheitsaspekten finden auch erste Überlegungen bezüglich Transparenz und Performanz statt. Es wird auch auf verwandte Arbeiten eingegangen, anhand derer existierende Konzepte und Lösungen für die einzelnen Teilprobleme vorgestellt werden. Dabei werden Vorzüge und Schwächen ausgearbeitet, um diese Erkenntnisse im anschließenden 4. Kapitel in den eigenen Systementwurf einfließen lassen zu können. Dem Entwurf werden dann schrittweise Komponenten hinzugefügt, welche die Erfüllung der einzelnen Teilziele sicherstellen sollen. 12

13 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN Im folgenden Kapitel 5 werden dann die technischen Details der tatsächlichen Implementierung des Systementwurfs beschrieben. Inwieweit das System als Lösung für die gestellte Aufgabe geeignet ist, wird im daran anschließenden 6. Kapitel evaluiert. Abschließend erfolgt im 7. und letzten Kapitel eine Zusammenfassung, in der unter anderem auf offene Fragen und Probleme eingegangen wird. 13

14

15 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN 2 GRUNDLAGEN Zunächst gilt es Grundlagen für die Arbeit zu beleuchten, etwa bezüglich des Umfelds innerhalb dessen das Konzept zu entwerfen ist und den Aufgabenzielen, die näher umrissen werden sollen. 2.1 CLOUD COMPUTING Trotz der mittlerweile erreichten Bedeutung der Cloud, gibt es für diesen Begriff keine einheitliche Definition, vor allem da er immer wieder als Schlagwort von MarketingAbteilungen verwässert wird. Eine der häufigeren im akademischen Umfeld herangezogenen Definitionen stammt vom amerikanischen National Institute of Standards and Technology (Mell et Grance 2011), im Folgenden frei aus dem Englischen übersetzt: Cloud Computing ist ein Modell, das es erlaubt bei Bedarf, jederzeit und überall bequem über ein Netz auf einen geteilten Pool von konfigurierbaren Rechnerressourcen (z.b. Netze, Server, Speichersysteme, Anwendungen und Dienste) zuzugreifen, die schnell und mit minimalen Managementaufwand oder geringer Serviceprovider-Interaktion zur Verfügung gestellt werden können. Prinzipiell geht es darum, IT-Ressourcen wie Datenspeicher, Rechenkapazität, sowie darauf aufbauend auch Software in und über Netzwerke zur Verfügung zu stellen. Dabei setzt Cloud Computing auf bereits etablierte Techniken wie zum Beispiel Serviceorientierte 15

16 KAPITEL 2 - GRUNDLAGEN Architekturen (SOA) und Web-Services, sowie Virtualisierung. Dies soll die Notwendigkeit für die Cloud-Nutzer ersetzen eigene entsprechende IT-Infrastruktur zu betreiben. Was einerseits das physische Vorhalten von Rechnersystemen meint, inklusive deren Vernetzung und Redundanz-Systemen; aber auch das für das Betreiben solcher komplexer Systeme notwendige Personal. Um all dies soll sich der spezialisierte Cloud-Betreiber kümmern, während der Nutzer die Ressourcen dann über einfache Schnittstellen abruft. Grundsätzlich wird dabei immer wieder die gute Skalierbarkeit und Verfügbarkeit von Cloud-Ressourcen hervorgehoben. Dies ist aber offensichtlich kein inhärenter Teil des Konzeptes vom Anbieten von Ressourcen über ein Netzwerk, sondern muss jeweils vom Cloud-Anbieter durch entsprechende Architekturkonzepte für seine Ressourcen sichergestellt werden. Die Skalierbarkeit ist für viele Firmenkunden von großer Wichtigkeit, da der für bestimmte Aufgaben notwendige Umfang von IT-Ressourcen über die Zeit gesehen oft nicht konstant ist. Neben Wachstum und Schrumpfung der grundsätzlichen Nutzerbasis schwankt auch kurzfristig die Anzahl gleichzeitiger Nutzer eines Systems. Dabei können Extremsituationen eintreten, in denen die durchschnittliche Anzahl von Nutzern, sowie das damit einhergehende Bearbeitungsaufkommen, um ein Vielfaches überstiegen wird. Einerseits ergeben sich Schwankungen über das Jahr. So besteht im Online-Handel - wie im Einzelhandel - eine große Diskrepanz zwischen Weihnachtszeit und den restlichen Monaten. Andererseits schwankt das Kundenaufkommen auch innerhalb eines jeden Tages, so rufen nachts etwa nur wenige Menschen Internet-Portale auf. Amazon zum Beispiel hatte im Jahr 2006 im Tagesgeschäft eine um den Faktor 10 höhere Spitzen- als Grundlast. Bei Internetfirmen wie Amazon und Google liegen auch die Ursprünge der Cloud. Diese Konzerne haben zum einen riesige Reserven für Spitzenlastzeiten aufgebaut, welche sie aber auch unterhalten müssen, wenn sie gar nicht genutzt werden. Zum anderen mussten sie Techniken entwickeln, welche Skalierungen von Hard- und Software, sowie Lastverteilung bezüglich deren hoher und stark schwankenden Anzahl von parallelen Nutzern ermöglichen. Die wirtschaftliche Lösung war die eigene aufgebaute Infrastruktur, sowie das dazugehörige Fachwissen zu vermarkten, und so auch eine bessere Auslastung der eigenen Ressourcen zu erreichen. Für Kunden solcher Internetfirmen ergibt sich aus diesem Angebot die Möglichkeit, nur die Ressourcen mieten zu müssen, welche sie tatsächlich benötigen. Sie vermeiden so wiederum selbst den Unterhalt für ungenutzte Ressourcen. Sie können einerseits Kosten sparen, da sie diese nur während der Nutzung zahlen; andererseits ist zu erwarten, dass die Nutzung selbst auch günstiger erreicht werden kann, da die Cloud-Anbieter ihre riesigen Serverfarmen insgesamt wesentlich günstiger ausstatten und administrieren, als viele kleine Firmen dies jeweils separat für sich machen können. Insbesondere global gesehen, könnte es so auch zu einer insgesamt ausgeglichenen Auslastung der Cloud-Ressourcen kommen, da die weltweit verteilten und zu unterschiedlichen Zwecken cloud-nutzenden Kunden unterschiedliche Lastverteilungen 16

17 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN haben. Im Endeffekt kann die Cloud weltweit einer effizienten IT-Ressourcennutzung dienen, wenn die durchschnittliche Nutzung dieser nicht zu weit entfernt von ihren Extremen liegt, also global eine ausgeglichene Nachfrage nach Ressourcen erfolgt. Beispiel sind wieder die Serverfarmen global agierender Unternehmen wie Amazon, die nur in wenigen Ländern solche Zentren betreiben müssen, da die Aktivität ihrer Kunden mit der Sonne um die Erde wandert und so nicht in jeder Zeitzone gleichzeitig mit Höchstlasten gerechnet werden muss CLOUD-ORGANISATIONSFORMEN Eine organisatorische Sicht auf die Cloud bietet die Unterteilung der einzelnen CloudEntitäten nach der Breite oder Art ihrer Nutzerbasis (Braun et al. 2011). Private Cloud Eine solche Cloud wird für eine bestimmte Organisation betrieben, entweder durch die Organisation selbst oder durch eine weitere. Deren Infrastruktur kann sich dabei innerhalb oder außerhalb der Organisation befinden. Dementsprechend muss das Netzwerk über das auf die Cloud-Ressourcen zugegriffen wird, nicht Teil des Internets sein, was offensichtliche Sicherheitsvorteile einschließt. Generell sollten sich die Probleme bezüglich der Datensicherheit dann auf dieselben beschränken, welche auch sonst bei Nutzung eines eigenen Rechnernetzes berücksichtigt werden müssen. Dies ist etwa für einzelne Firmen, Behörden oder Vereine geeignet, welche durch die Nutzung von Cloud-Techniken und internes koppeln von Ressourcen Einsparungen erzielen wollen. Community Cloud Diese Art einer Cloud wird für einen Zusammenschluss von Organisationen betrieben, entweder durch den Verbund selbst oder eine weitere Organisation. Die Infrastruktur kann sich dabei innerhalb oder außerhalb der Organisation befinden. Die Teilnehmer des Nutzerkreises sind dabei meist im selben Umfeld tätig und wollen durch die gemeinsame Nutzung ihre Kosten verringern, etwa Firmen ähnlicher Ausrichtung, mehrere Behörden, Forschungseinrichtungen oder Universitäten. Spätestens ab hier steigen auch die Anforderungen bezüglich Datensicherheit und Datenschutz, da keine volle Kontrolle mehr möglich ist, wenn verschiedene Entitäten ihre Daten auf gemeinsamen IT-Ressourcen vorhalten. 17

18 KAPITEL 2 - GRUNDLAGEN Public Cloud Die umfassendste Version einer Cloud wird über das Internet der breiten Öffentlichkeit verfügbar gemacht und von einer Organisation besessen und betrieben, deren Geschäftsmodell auf dem Vermieten der Ressourcen basiert. Deren Kunden sparen sich dabei Investitionen in eine eigene Infrastruktur und bezahlen nur die tatsächliche Ressourcennutzung. Hier werden Daten außerhalb der eigenen Kontrolle auf Systemen hochspezialisierter Anbieter gespeichert oder verarbeitet. Diese Angebote werden nicht mehr für spezifische Organisationen aufgesetzt, sondern einer Vielzahl verschiedener Kunden zur Verfügung stehen. Dies erfordert also auch die Sicherstellung der Mandantenfähigkeit, um den Datenschutz der legitimen Nutzer untereinander zu gewährleisten (Hill 2011). Offensichtlich sind hier die höchsten Anstrengungen notwendig, um die Sicherheit der eigenen Daten zu gewährleisten, da keine durchsetzbare Kontrolle mehr über die gemietete Infrastruktur und ausgelagerte Daten besteht. Hybrid Cloud Dies ist die Komposition aus zwei oder mehreren Cloud-Entitäten unterschiedlichen Typs. Diese bleiben separate Einheiten, werden aber durch gemeinsame Technologie geeint. Dies ermöglicht Daten- und Anwendungsportabilität, um etwa Lastverteilung zwischen den Clouds zu erreichen, zum Beispiel wenn ein privater Cloud-Betreiber bei hoher Belastung Ressourcen aus einer Public Cloud hinzuzieht CLOUD-DIENSTMODELLE Eine technischere Sicht auf die Cloud ist die Betrachtung der Arten von Dienst, welche Anbieter zur Verfügung stellen. Diese werden vom National Institute of Standards and Technology (Mell et Grance 2011) nach 3 Kategorien unterschieden, dargestellt in Abbildung 2.1. Ausschlaggebend für die Einteilung ist das Level der Abstraktion des Dienstes. Diese reicht dabei vom direkten oder virtualisierten Zugriff auf Hardware bis zur Nutzung eines komplett fertigen Softwaresystems, welches allenfalls Eingabeparameter für die Bearbeitung benötigt. Beginnend mit der niedrigsten Abstraktionsstufe sind dies: IaaS, PaaS und SaaS. 18

19 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN IaaS - Infrastructure as a Service Hier werden grundsätzliche Rechnerressourcen zur Verfügung gestellt. Dies umfasst einerseits Zugriff auf spezifische Ressourcentypen, wie Rechenleistung oder Datenspeicher; sowie andererseits das Zurverfügungstellen kompletter virtueller Maschinen und Netzwerktopologien. Ein solcher Dienst bietet damit letztendlich Virtualisierungstechniken auf seiner eigenen Hardware für Außenstehende. Bei diesen hat der Nutzer schließlich für alle Software darauf selbst Sorge zu tragen, inklusive der Betriebssystemebene. Der Vorteil gegenüber einer eigenen physischen Serverkonfiguration ist dabei die leichte Skalierbarkeit, da bei horizontaler (oder auch vertikaler) Skalierung nicht die eigene Hardware umrüstet werden muss, sondern dies einfach virtuell angefordert und vom Anbieter erledigt wird. Angebote dieser Stufe können genutzt werden, um Maschinen für das gewünschte Datenbanksystem zu optimieren, sowie das Gesamtsystem komplett den eigenen Präferenzen entsprechend zu konfigurieren, ohne die physischen Server selbst betreiben zu müssen. Beispiele für Anbieter dieser Ebene sind GoGrid 1 und Linode2 sowie Amazon mit EC2s virtuellen Maschinen3 und dem Speicherdienst S34 (Simple Storage Service). PaaS - Platform as a Service Diese Ebene unterscheidet sich zur unteren Stufe durch die Abstraktion von der Administration einer virtuellen Maschine. Diese Angebote richten sich üblicherweise an Software-Entwickler, welche ein System benötigen, das den Lebenszyklus der eigenen Software unterstützt. Sie müssen sich durch die Abstraktion nicht mehr ein System komplett selbst zusammenstellen, sondern können sich ein dem eigenen Anforderungen genügendes System suchen. Darunter fallen etwa die notwendigen Fähigkeiten zum Erstellen und Hosten der eigenen Anwendungen, zum Beispiel Frameworks und die Unterstützung der zu verwendenden Programmierwerkzeuge und -sprachen. Diese Ebene kann genutzt werden, wenn existierende Standard-Datenbanksoftware speziell konfiguriert oder um zusätzliche Funktionalitäten erweitert werden soll. Dafür muss eine Plattform gefunden werden mit bereits vorinstalliertem Datenbanksystem oder eine Plattform auf der es möglich ist, ein solches selbst aufzusetzen. Generelle Beispiele hierfür sind Google App Engine5 oder Force.com6 von SalesForce

20 KAPITEL 2 - GRUNDLAGEN SaaS - Software as a Service Dies ist die abstrakteste Schicht. Der Nutzer bringt hier keine Anwendungen in die Cloud mehr ein, sondern nutzt bereits angebotene Anwendungen der Cloud. Mit den dahinter liegenden Problematiken zum Hosting oder zur Skalierbarkeit kommt er dabei gar nicht mehr in Kontakt. Die Administration beschränkt sich auf die nutzerspezifische Konfiguration der Anwendung. Diese Dienste sind entweder als Komponenten innerhalb von MashUps oder direkt durch Endkunden nutzbar - üblicherweise über Thin Client Schnittstellen, wie etwa einen Webbrowser. Es wird also meist keine spezielle clientseitige Software benötigt. Bei Angeboten dieser Ebene haben Kunden keinen Einfluss mehr auf das Datenbanksystem sowie die damit angebotenen Funktionalitäten. Sie müssen sich also einen Dienst suchen, welcher möglichst alle gewünschten Eigenschaften bietet. Generelle Beispiele dieser Ebene sind etwa Web-Services wie OpenID 7 oder WebAnwendungen wie Google Docs8. Spezifische Database-as-a-Service-Lösungen (SaaS.DBaaS) bieten etwa Microsofts relationales SQL Azure9 und Amazons NoSQL-Datenbanksystem SimpleDB10. Abbildung 2.1: Cloud-Dienstmodelle

21 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN 2.2 MEHRSEITIGE SICHERHEIT Um eine Architektur für die sichere Nutzung von Cloud-Ressourcen im Datenbankumfeld zu erarbeiten, sei zunächst definiert was diese sichere Nutzung umschließen soll. Dabei müssen alle an einem solchen System beteiligten Parteien berücksichtigt werden. Dies sind einerseits die eigentlichen Cloud-Nutzer, aber auch wiederum deren Kunden, wenn von oder über diese Daten in die Cloud gebracht werden. Andererseits muss nicht nur die CloudInfrastruktur, sondern auch deren Anbieter selbst in die Überlegungen mit einbezogen werden. Das der Anbieter selbst mit in die Überlegungen einbezogen werden muss und nicht nur dessen technische Infrastruktur, liegt in seinen Eigeninteressen begründet. Zum Beispiel kollidieren seine versprochenen und von den Kunden benötigten Systemeigenschaften, wie hohe Verfügbarkeit und absolute Sicherheit mit dessen Bedürfnis, dies mit möglichst geringen Kosten zu erreichen. Das führt zum Begriff der Mehrseitigen Sicherheit (Pfitzmann, Andreas), (Rannenberg, Pfitzmann, et Müller 1996). Mehrseitige Sicherheit bedeutet die Einbeziehung der Schutzinteressen aller Beteiligten, sowie das Austragen daraus resultierender Schutzkonflikte. Das heißt nicht, dass alle Parteien ihre Interessen komplett durchsetzen können. Die Auseinandersetzung damit führt aber zu klaren Verhältnissen zwischen den Parteien innerhalb eines Systems SCHUTZZIELE Üblicherweise werden Bedrohungen von Daten in 3 Hauptkategorien eingeteilt, was nach (Pfitzmann, Andreas) zu den 3 Schutzzielen Vertraulichkeit, Integrität und Verfügbarkeit führt, welche es zu erreichen gilt. Diese Ziele werden nachfolgend genauer beleuchtet, wobei auch deren Definitionen nach Professor Pfitzmann wiedergegeben werden. Während die Vertraulichkeit vor allem durch böswilliges oder grob fahrlässiges Verhalten von Menschen gefährdet wird, bestehen die Gefahren für Integrität und Verfügbarkeit in menschlichen Handeln, technischen Fehlern und in der Unzulänglichkeit verwendeter Systeme. 21

22 KAPITEL 2 - GRUNDLAGEN Vertraulichkeit Informationen werden nur Berechtigten bekannt. Der Verlust von Vertraulichkeit bedeutet also unbefugten Informationsgewinn, das heißt, Personen, welche keine Zugriffsberechtigung auf Daten hatten, haben sich doch Zugriff verschaffen können. Das kein solcher erfolgte, kann nicht bewiesen werden. Zwar gibt es technische Hilfsmittel wie Zugriffslogs etc.; dann aber müsste demnach auch bewiesen werden, dass diese nicht umgangen oder modifiziert wurden sind, also das auch darauf kein unbefugter Zugriff erfolgte. Um dieses Schutzziel zu erreichen, sollte durch diverse Maßnahmen technischer und organisatorischer Natur der unberechtigte Zugriff auf die Informationen möglichst schwer gestaltet werden. Insbesondere fallen darunter solche Mittel wie Zutrittskontrollen, um den physischen Zugang zu Datenspeichern; sowie Zugangskontrollen und Zugriffskontrollen, um den informationstechnischen Zugriff zu kontrollieren, inklusive deren Protokollierung. Letztere allerdings kann höchstens helfen die unberechtigt zugegriffenen Daten zu quantifizieren. Sobald der Zugriff auf die Daten erfolgte, ist die Kontrolle über diese verloren. Es ist dann nicht mehr sicher festzustellen, wie viele Kopien wiederum von diesen erstellt wurden und wo sie sich befinden. Insbesondere beschränkt sich die Speicherung und Weitergabe nicht auf technische Systeme, auch Menschen selbst können sich vertrauliche Daten merken und weitergeben. Während der Übertragung und durch und Speicherung auf nicht vertrauenswürdigen Systemen dienen dagegen hauptsächlich Konzelationssysteme zum vertraulich-halten von Informationen. Integrität Informationen sind richtig, vollständig und aktuell oder aber dies ist erkennbar nicht der Fall. Der Verlust der Integrität ist also die unbefugte oder ungewollte Modifikation von Informationen, so dass diese nicht mehr korrekt oder vollständig sind. Dies kann von technischer Unzulänglichkeiten herrühren, die etwa zu Bitfehlern bei der Übertragung führen oder auch durch Angreifer gezielt bewirkt werden. Es existieren allerdings technische Hilfsmittel, wie Prüfsummen- und Authentifikationssysteme, mithilfe derer solche Modifikationen erkannt werden können. Auch bei der Verarbeitung von Daten kann es zu Integritätsverletzungen kommen. Bei der Abarbeitung von Algorithmen werden üblicherweise eine ganze Reihe Einzelaktionen ausgeführt. Wenn nicht alle dieser Tätigkeiten erfolgreich ausgeführt werden können, kann es zu Verletzungen der Konsistenz eines Datenbestands kommen. Beispielsweise wenn bei 22

23 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN einer Überweisung die Abbuchung vorgenommen wird, das Gutschreiben aufgrund eines unerwarteten Fehlers allerdings nicht erfolgen kann. Relationale Datenbanksysteme arbeiten deswegen nach dem Atomizitätsprinzip: Alle notwendigen Aktionen werden zu einer logischen Transaktion zusammengefasst und nur wenn alle erfolgreich ausgeführt werden konnten, werden die von ihnen vorgenommen Änderungen tatsächlich permanent festgeschrieben. Treten dagegen unbehandelte Probleme auf, werden auch bisher erfolgreiche Transaktionsteile wieder verworfen. Verfügbarkeit Informationen sind dort und dann zugänglich, wo und wann sie von Berechtigten gebraucht werden. Wichtig ist also nicht nur, dass Informationen dort verfügbar sind, wo, sondern auch dann, wenn sie benötigt werden. Schließlich nützen auch integere Informationen nichts, wenn ihr Eintreffen verspätet erfolgt. Und während Angreifer aktiv Verfügbarkeitsprobleme herbeiführen können, ist dies ein ganz grundsätzliches technisches Problem, welches in der Zuverlässigkeit von Geräten begründet liegt. Wenn etwa Daten nur auf einem Permanentspeicher gesichert werden, existiert ein Single Point of Failure. Es gibt also keine alternative Zugriffsmöglichkeit auf die Daten und bei einem technischen Defekt des Speichers können diese Daten nicht mehr abgefragt werden. Sogenannte Hochverfügbarkeitssysteme müssen sich daher von der Abhängigkeit einzelner Komponenten lösen. Dazu werden üblicherweise Verbünde homogener oder zumindest ähnlicher Systeme verwendet, innerhalb welcher Aufgaben dynamisch verteilt und Daten redundant gespeichert werden, um auch bei Ausfall von Komponenten ohne Unterbrechung weiterarbeiten zu können. Gerade Cloud-Dienste rühmen sich dieser Hochverfügbarkeits-Eigenschaft, wonach dieses Schutzziel in der Cloud leicht erreichbar sein sollte. Allerdings löst sich die Problematik nicht komplett, insbesondere wenn Nutzer auf einen bestimmten Dienst oder Anbieter angewiesen sind und sich damit selbst einen neuen Single Point of Failure schaffen. Einerseits kann das Problem darin bestehen, dass Anbieter aus Kostengründen eben nicht optimal redundant arbeiten und es trotzdem zu Verfügbarkeitsproblemen kommt. Anderseits kann auch die Fachkompetenz unzureichend sein, so dass zum Beispiel gezielte Angriffe zu solchen Problemen führen (PSNA 2011). Schließlich können auch der Anbieter oder dessen Dienste als Entität verschwinden, etwa aus wirtschaftlichen Gründen (MSNM 2008), oder auch unangekündigt durch Staatseingriffe (MU 2012). Ebenfalls können unzureichende Ressourcenleistungen eine Ursache für Verfügbarkeitsprobleme sein. Ist etwa ein Datenbankserver unterdimensioniert konzipiert, kann schlicht eine zu große Menge gleichzeitiger Anfragen verursachen, dass Querys zu spät beantwortet werden. Das kann auch in einem Netzwerk passieren, in dem es wegen zu 23

24 KAPITEL 2 - GRUNDLAGEN geringer Bandbreite zu einem Stau von Informationen und damit erhöhten Latenzen und schließlich problematischen Verzögerungen kommt, auch wenn alle Daten korrekt übermittelt werden. Die letzten beiden Schutzziele überschneiden sich teilweise und werden deshalb manchmal zusammengefasst, sie sind allerdings nicht deckungsgleich. Bei Wahrung von Integrität spricht man von partieller Korrektheit, bei zusätzlicher Wahrung der Verfügbarkeit von totaler Korrektheit. Bei partieller Korrektheit ist ein geliefertes Ergebnis korrekt, bei totaler wird ein integeres Datum rechtzeitig geliefert VERTRAUENSBEREICH Dies ist eine IT-Infrastruktur, innerhalb welcher ein Anwender Vertrauen in die Sicherheit seiner Daten hat. In einem solchen Bereich sollen keine Aktionen ablaufen, die vom Anwender nicht autorisiert sind. Das impliziert auch, dass nur autorisierte Daten diesen Bereich verlassen. Die Möglichkeiten so einen Bereich zu schaffen, ergeben sich unter anderem durch die bereits erwähnten Zutritts-, Zugangs- und Zugriffskontrollen (Pfitzmann, Andreas). Diese Techniken sind allerdings nicht Bestandteil dieser Arbeit. Für die Implementierung wird ein vorhandener Vertrauensbereich vorausgesetzt, ohne explizit auszuführen, wie dieser erreicht werden soll. Wenn IT-Ressourcen der eigenen physischen Kontrolle unterliegen, kann der Nutzer sich das Vertrauen in einen solchen Bereich mittels der eigenen Fähigkeiten durch sicherheitsschaffende Maßnahmen erarbeiten. Solch ein Vertrauen in einen Bereich zu erreichen, welcher außerhalb der eigenen Kontrolle liegt, etwa die Rechnersysteme von Cloud-Anbietern ist dagegen schwer zu erreichen. Da selten die Möglichkeit besteht, die Angaben der Dritten zu prüfen, müssen Nutzer sich auf deren Versprechungen einlassen. Wie in der Aufgabenstellung ausgeführt, soll das Vertrauen in diese auch keine Notwendigkeit für das eigene Sicherheitskonzept sein, weswegen für diese Arbeit die Cloudressourcen auch nie Teil des Vertrauensbereichs des eigenen Systems sind. 24

25 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN 2.3 DATENBANKMANAGEMENTSYSTEME Datenbanksysteme (DBS) werden in die SQL-Systeme und ihre Alternativen, die NoSQLSysteme unterschieden. Während SQL-Systeme immer nach dem ACID-Prinzip (Atomicity, Consistency, Isolation, Durability) funktionieren, ist unter den anderen eher die WortspielAlternative BASE (Basically Available, Soft state, Eventual consistency) verbreitet. Ursache für die zunehmende Bekanntheit und Verbreitung der BASE-Systeme ist die schlechtere Skalierbarkeit der ACID-Systeme, insbesondere in Anwendungsszenarien mit hohem Schreibaufkommen. Bei der Entstehung von Unternehmen im Internet mit riesigen Nutzerzahlen, haben sich dahinterstehende SQL-Systeme zunehmend als Flaschenhals erwiesen und wurden dementsprechend aus diesen Feldern verdrängt. Für diese Arbeit findet dennoch eine Konzentration auf die relationalen SQL-Systeme statt, da NoSQL-Datenbanken oft spezialisiert auf sehr bestimmte und verschiedene Anwendungsszenarien sind und in ihrer Häufigkeit wesentlich seltener als SQL-Systeme. Datenbankmanagementsysteme (DBMS) sind komplexe Systeme, die aus zahlreichen spezialisierten Komponenten bestehen, welche sich um unterschiedliche Teilaufgaben kümmern. Im Folgenden wird kurz auf die allgemeine Arbeitsweise eines DBMS eingegangen. Dabei werden die zentralen Bestandteile vorgestellt, welche später in der Arbeit noch Erwähnung finden (siehe Abbildung 2.2). Nutzer senden einem Datenbanksystem entweder direkt Datenbankanfragen sogenannte Querys oder indirekt, indem sie Anwendungen dazu aufrufen, wie etwa bei Nutzung eines Webportals. Querys werden dabei unterschieden zwischen Anfragen, welche die eigentliche Struktur der Datenbank (DB) betreffen (in der DDL - Data Description Language) und solchen, die den Inhalt der Datenbank berühren (DQL - Data Query Language und DML Data Modifikation Language). Die Query wird zunächst in einen internen Query-Plan umgewandelt - einer Abfolge einzelner Aktionen, die das Datenbanksystem abarbeiten soll. Die Optimierung dieser automatisch erstellten Pläne ist eines der wichtigsten Performanzziele von Datenbankanbietern, so wird etwa versucht die Menge der Daten zu minimieren, welche überhaupt in den Arbeitsspeicher geladen und verarbeitet werden muss. Die Execution Engine schließlich arbeitet den Query-Plan ab und lässt sich entsprechend diesem vom Record Manager die benötigten Indizes und Records geben. Der Record-Manager ist die Schnittstelle des Datenbanksystems zwischen der gewünschten internen Wahrnehmung der Daten, als Sammlung von Tupeln in Tabellen; und der Notwendigkeit die Daten auch effizient auffindbar und lesbar auf den Permanentspeicher abzulegen. Der Record-Manager gruppiert die Tupel dafür zur Speicherung in sogenannten Pages. Dies ist dann die Einheit in welcher der Page-Manager die Daten mit dem Dateisystem austauscht. Aufgrund der bei üblichen Permanentspeichers hohen Latenzen 25

26 KAPITEL 2 - GRUNDLAGEN gegenüber Arbeitsspeicher ist auf der Ebene des Page-Managers auch ein Puffer angesiedelt, welcher nach Ersetzungs- und Prefetching-Algorithmen möglichst effizient mit zukünftig vom Record Manager benötigten Pages gefüllt wird. Abbildung 2.2: Datenbankmanagementsysteme nach (Garcia-Molina, Ullman, et Widom 2009) und (Kemper et Eickler 2011) 26

27 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN 3 ANALYSE Sehr naheliegende Lösungen zur Nutzung von Cloud-Ressourcen für Datenbankaufgaben sind etwa die zahlreichen bereits existierenden Datenbankdienste in der Cloud (SaaS.DBaaS), oder wenn diese nicht den eigenen Anforderungen entsprechen, die Nutzung virtueller Maschinen (IaaS) auf denen dann ein Datenbanksystem den eigenen Wünschen gemäß konfiguriert werden kann. Da DBMS üblicherweise bereits Techniken besitzen, um die Sicherheit der ihnen anvertrauten Daten zu gewährleisten, werden diese im kommenden Abschnitt vorgestellt. Dabei soll analysiert werden, inwieweit diese Techniken im CloudUmfeld für das eigene Konzept verwendet werden können. Anschließend wird auf existierende Konzepte zur sicheren Nutzung von Datenbanksystemen in der Cloud eingegangen. 3.1 SICHERHEIT IN DATENBANKSYSTEMEN Im Folgenden wird auf existierende Datenbanktechniken eingegangen, welche zur Umsetzung der Schutzziele dienen können. Replikation Eine Technik um die Verfügbarkeit von Datenbanksystemen inklusive ihrer Datenbestände zu erhöhen, ist die Replikation. Bei Replikation durch Log-Shipping etwa existieren neben dem Primär- oder Master-Knoten weitere Instanzen, die Sekundär- oder Slave-Knoten. Diese erhalten von der primären Instanz Informationen über alle an ihrem Datenbestand 27 Verfügbarkeit

28 KAPITEL 3 - ANALYSE vorgenommen Veränderungen, damit sie diese Modifikationen replizieren und so einen zum Primärknoten konsistenten Datensatz halten können. Fällt die Primärinstanz aus, kann somit einer der Sekundärknoten deren Rolle übernehmen. Diese Funktionalität bietet allerdings nur einen ganzheitlichen Ansatz, bei dem eine Systeminstanz komplett durch eine weitere ersetzt wird, sobald eine elementare Komponente des ursprünglichen Systems ausfällt. Dementsprechend muss aber auch jeder der Sekundärknoten ein komplettes System darstellen, welches alle notwendigen Komponenten unterstützt. Grundsätzlich kann dies auch im Cloud-Umfeld genutzt werden und entsprechende Hochverfügbarkeitslösungen werden sogar explizit als Cloud-Dienst angeboten. Um die Verfügbarkeit zu maximieren, sollten allerdings Lösungen vermieden werden, bei denen alle Instanzen vom selben Cloud-Anbieter betrieben werden. Backup Verfügbarkeit Integrität Eine weitere verbreitete Technik ist das Erstellen von Backups. Dies sind Kopien eines Teils oder des gesamten Datenbestands eines Datenbanksystems. Üblicherweise werden diese Kopien jeweils auf anderen Rechnersystemen als der originale Datenbestand abgelegt und genutzt, um im Bedarfsfall einen vorherigen Zustand der Datenbank wieder herzustellen. Diese Technik eignet sich also dafür die Schutzziele Verfügbarkeit und Integrität zu unterstützen. Beim Ausfall des Original-Systems kann der Datenbestand in ein anderes Datenbanksystem geladen oder bei unerwünschten Änderungen am Datenbestand eine vorherige Version wieder hergestellt werden. Dies sind aber offensichtlich manuelle Lösungen, deren Anwendung erhebliche Zeit in Anspruch nimmt und helfen somit nicht die beiden Schutzziele in einem aktiven System zu erreichen. Des Weiteren ist diese Technik auf technische Probleme ausgelegt, sie hilft nicht zu erkennen, ob Integritätsverletzungen stattfanden, was demnach separat untersucht werden muss. Authentifikation & Autorisierung Vertraulichkeit Bezüglich der Vertraulichkeit nutzen DBMS Authentifikation beim Verbindungsaufbau eines Clients und stellen bei der Anfragebearbeitung anhand einer Autorisierungstechnik fest, ob die einzelnen gewünschten Aktionen auf den Datenbankobjekten dem authentifizierten Nutzer auch erlaubt sind (siehe Abbildung 3.1). 28

29 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN Abbildung 3.1: Authentifikation und Autorisierung in Datenbanksystemen Diese beiden Techniken funktionieren allerdings nur, solange innerhalb des DBMS auf den Daten gearbeitet wird, die Zugriffe also unter dessen Kontrolle erfolgen. Wenn etwa auf Dateisystem-Ebene oder im Hauptspeicher der Datenbestand gelesen oder modifiziert wird, liegt es außerhalb der Möglichkeiten des Datenbanksystems dies selbst zu verhindern. Neben dem Datenbankserver muss also auch das System, auf dem dieser läuft, entsprechend gesichert sein und gewartet werden, so dass Nutzer keine unerwünschten Aktionen durchführen können. Da System- und Datenbankadministratoren die komplette Kontrolle über ihre jeweiligen Systeme haben, können sie technisch nicht davon abgehalten werden, die Sicherheit der Daten zu gefährden. Es ist somit das Vertrauen vom Systemnutzer in diese Personen notwendig. Wenn die Ressourcen allerdings nicht mehr selbst betrieben, sondern von Dritten bereitgestellt werden, befinden sich sowohl Systeme als auch Personal außerhalb der eigenen Kontrolle. Wenn dem Betreiber und seiner Sicherheitskompetenz nicht bedingungslos vertraut werden kann oder darf, stellt sich die Frage inwieweit durch weitere technische Lösungen diese Problematik gelöst werden kann. Eine dafür in Frage kommende Sicherheitstechnik wird separat im nächsten Punkt vorgestellt. 3.2 KONZELATION IN DATENBANKSYSTEMEN Eine übliche Technik um Vertraulichkeit zu sichern, ist der Einsatz von Kryptographie. Auch im Datenbankumfeld wird diese eingesetzt. Wie in (Bouganim et Guo 2009) dargelegt und in Abbildung 3.2 dargestellt, kommen in einer komplexen Software wie einem DBMS mehrere Ebenen in Frage, um Konzelation in das System zu integrieren. Damit gehen aber 29 Vertraulichkeit

30 KAPITEL 3 - ANALYSE weitreichende Konsequenzen bezüglich der effektiven Vertraulichkeit einher, welche erreicht werden kann. Auch hat dies Auswirkungen auf nicht-sicherheitskritische Funktionalitäten, etwa die Transparenz der Verschlüsselungssysteme und Performanz der Datenbanksysteme. Abbildung 3.2: Datenbanksystem-Konzelationsebenen nach (Bouganim et Guo 2009) Da Konzelation eine der zentralen Funktionalitäten der zu entwickelnden Lösung sein wird, sei nachkommend ausführlich auf die zu erwartenden Unterschiede eingegangen. Dabei werden auch entsprechende bereits existierende Konzepte vorgestellt STORAGE LEVEL ENCRYPTION Verschlüsselung in dieser Ebene bedeutet, die Daten werden verschlüsselt auf den Permanentspeicher abgelegt. Sie bleiben vertraulich solange sie ruhen, also nicht in das DBMS geladen werden. Das schützt sie, sollte der Permanentspeicher physisch entwendet werden. Es bietet keinen Schutz vor den System- und Datenbankadministratoren oder Personen, die sich unbefugt die notwendigen Rechte verschaffen, um die Daten direkt vom Permanentspeicher lesen zu können. Da alle durch das DBMS zu verarbeitenden Daten beim Einlesen vom Permanentspeicher in den Datenbank-Arbeitsspeicher entschlüsselt werden, finden sämtliche Arbeiten des DBMS auf Klartextdaten statt. Trojaner können also auch den Hauptspeicher beobachten und so die Klartextdaten erhalten. 30

31 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN Dabei muss weiterhin beachtet werden, dass Datenbanksysteme sowohl temporäre Dateien für die Anfragebearbeitung erstellen und Log-Dateien über ihre Aktionen führen. Und das darüber hinaus üblicherweise auch Backups des Datenbestands erstellt und auf anderen Systemen abgelegt werden. Auch unterliegen die durch ein DBMS eingelesenen Daten nicht dessen kompletter Kontrolle. So kann es etwa durch die Arbeitsspeicherverwaltung des Betriebssystems dazu kommen, dass Klartext-Daten in eine Auslagerungsdatei auf einem Permanentspeicher gelangen. Es muss also sichergestellt werden, dass alle für die Daten verwendeten permanenten und temporären Dateien verschlüsselt werden, oder einfacher alle in Frage kommenden Partitionen, damit tatsächlich alle ruhenden Instanzen der Datenbankdaten vertraulich gespeichert sind. Da DBMS und Dateisystem per Dateiobjekten interagieren, erlangt das Dateisystem keine Kenntnisse darüber, wie die Storage Engine des DBMS die Daten in die Dateien ablegt. So werden ganze Dateien, Verzeichnisse oder gar Partitionen mit einem einzelnen Schlüssel geschützt. Einzelne DB-Objekte wie Tabellen oder Tupel können also nicht mit eigenen Schlüsseln geschützt werden, um so den Zugriff nur für bestimmte Nutzergruppen zu ermöglichen. Die Granularität des Zugriffs bleibt demzufolge auf die vom DBMS erstellten Dateien beschränkt. Die Kryptographie-Komponente liegt hinter einer Dateisystemschnittstelle. Dies ist ein Interface mit dem alle Anwendungen vertraut müssen, welche selbst Dateien lesen und schreiben wollen. Der Vorteil dabei ist also die Transparenz für das Datenbanksystem, so müssen auf dieser Konzelationsstufe weder die Client-Anwendungen, noch die Datenbanksoftware selbst angepasst werden. Praktische Anwendungen sind beispielsweise mit Systemen wie TrueCrypt 11 geschützte Partitionen oder speziell für Cloudlösungen entwickelte Kryptographiesoftware wie Gazzangs ezncrypt12. Bezüglich der zu erreichenden Punkte dieser Arbeit lässt sich sagen, dass durch Einsatz von Kryptographie in dieser Ebene eine hohe Transparenz gegenüber Datenbanksystemen und daraufzugreifende Anwendungen erhalten werden kann, da sie dafür nicht verändert werden müssen. Der Einsatz wird hinter standardisierten Schnittstellen wie der des Dateisystems verborgen, welche das DBMS ohnehin verwenden würden. Abgesehen von der notwendigen Rechenzeit für die Ver- und Entschlüsselung gibt es auch keinen weiteren Leistungseinbußen in einem solchen System, da nicht in bestehende Komponenten eingegriffen wird und diese somit unverändert arbeiten können. Allerdings steht diesen positiven Punkten das Problem gegenüber, nur unzureichend mehr Vertraulichkeit erreichen zu können. Beim Einsatz dieser Technik in der Cloud muss weiterhin dem Anbieter und seiner Sicherheitskompetenz vertraut werden, was laut Aufgabenstellung aber nicht Teil des Sicherheitskonzepts sein soll

32 KAPITEL 3 - ANALYSE DATABASE LEVEL ENCRYPTION In dieser Ebene finden die Ver- und Entschlüsselung innerhalb des Datenbanksystems statt. Als Teil der DBMS kann die Vertraulichkeitskomponente die virtuelle und physikalische Organisation der Daten berücksichtigen und damit Kryptographie gezielt und sehr feingranular anwenden. So kann die Verschlüsselung als Ergänzung der bereits sonstig vorhandenen Sicherheitstechnik der Datenbank verstanden werden und potentiell nicht nur einzelne Tabellen, sondern einzelne Zeilen oder Spalten Zugriffskontrollen unterworfen werden, so dass nur für berechtigte Nutzer diese Daten überhaupt entschlüsselt werden. Es gelten allerdings die selben Problematiken bezüglich nicht ruhender Daten, wie bei der Konzelation auf Dateisystemebene. Damit das DBMS mit den Daten arbeiten kann, werden diese im Klartext in den Hauptspeicher geladen und können dementsprechend dort ausgelesen werden. Ferner können Kopien der unverschlüsselten Daten im Hauptspeicher durch das Betriebssystem entstehen. Schließlich muss auch hier den System- und Datenbanksystem-Administratoren vertraut werden können. Beispiele für Systeme dieser Ebene sind etwa IBMs InfoSphere Guardium Data Encryption 13 für DB2 oder Microsofts Transparent Data Encryption14 (TDE) für deren SQL Server. Offensichtlich ist diese Stufe vor allem für die Vertreiber von DBMS von Interesse. Der Versuch nachträglich an dieser Stelle Konzelation einzuführen, wäre wenig transparent, es müssten jeweils für das spezifische DBMS Modifikationen vorgenommen werden. Dies würde wiederum eine jeweilige Einarbeitung und Wartung erfordern, wenn denn überhaupt diese Möglichkeit besteht, etwa in Bezug auf Closed Source Software. Sofern das Kryptographie-Modul unter Beachtung der weiteren DBMS-Komponenten so eingefügt wird, dass diese nicht unnötig in ihrer Arbeit behindert werden, kommt es lediglich zu Leistungseinbußen durch Konzelationsaufwand. Wie bereits angemerkt, müssen allerdings zumindest Teile des Kryptographie-Moduls an das jeweilige DBMS angepasst werden, so dass keine hohe Transparenz mehr bezüglich der Datenbank-Ebene besteht. Die Anwendungsebene muss sich dafür auch hier nicht um die Problematik der Verschlüsselung kümmern. Da die Daten auf den Datenbankserver auch nicht ununterbrochen verschlüsselt sind, muss weiterhin dem Server und seinem Betreiber vertraut werden ools.dec.doc.ug/decuhome.htm

33 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN APPLICATION LEVEL ENCRYPTION In dieser Stufe finden Ver- und Entschlüsselung in der Anwendungsebene statt. Die Daten werden also von der Anwendung verschlüsselt, bevor diese dem Datenbankserver übergeben werden. Wobei auch der dafür verwendete Schlüssel dem Server nie bekannt gemacht wird. Genauso ist das eigentliche Ergebnis verschlüsselt in der Antwort des Datenbankservers enthalten und muss von der Anwendung erst entschlüsselt werden. Dabei liegt auch dem DBMS die eigentliche Antwort nie im Klartext vor. Somit bestehen auch keine Bedenken bezüglich der Vertrauenswürdigkeit der Datenbankadministratoren oder des Systems auf dem das DBMS läuft. Neben der notwendigen Anpassung von Anwendungen an dieses System ergibt sich ein schwerwiegendes Probleme für das DBMS bei der Bearbeitung von Anfragen. Entsprechend dem Konzelationsziel zu verhindern, dass aus einem Schlüsseltext Informationen über den enthalten Klartext extrahiert werden können, kann das DBMS die Daten also gar nicht richtig verstehen und wird sie entsprechend "falsch" verarbeiten. Die Lösungen in der Praxis bestehen darin, gewisse Abstriche gegenüber der absoluten Vertraulichkeit der Daten einzugehen, um ein zumindest grobes Arbeiten damit zu ermöglichen; oder Konzelationssysteme zu verwenden, mit denen bestimmte Operationen direkt auf den verschlüsselten Daten möglich sind, ohne Einschränkung deren Vertraulichkeit - etwa durch Homomorphe Verschlüsselung (Rivest, Adleman, et Dertouzos 1978), (Gentry 2009). Wobei zu beachten ist, dass diese Art der Konzelation der darauf arbeitenden Software zwar eine sinnvolle Modifikation der enthaltenen Daten ermöglicht, aber nicht selbst entscheiden kann, wann die Modifikation erwünscht ist, da weiterhin keine Informationen über die enthaltenen Daten zur verarbeitenden Software gelangen. Auch die erweiterten Funktionalitäten heutiger Datenbanksysteme zur Erhöhung von Performanz, Usability oder Reduzierung des Datenaustauschs mit den Clients; wie Funktionen, Prozeduren, Trigger etc. werden dadurch eingeschränkt oder gar nutzlos gemacht. So kann auch die sehr wichtige Indizierungstechnik allerhöchstens mit ordnungserhaltenden Kryptographiealgorithmen genutzt werden. Im Folgenden seien zwei Ansätze vorgestellt, in denen Verschlüsselung in dieser Ebene angewandt wird, um trotz des Betreibens der Datenbanksysteme in der Cloud die Vertraulichkeit der enthaltenen Daten gewährleisten zu können (VERWANDTE ARBEIT) PARTITIONDB In Executing SQL over encrypted data in the database-service-provider model (Hacigümüş et al. 2002) wird ein Konzept vorgestellt, in dem ein DBMS Anfragen beantworten kann, ohne die Tupel im Klartext zu benötigen. Genau genommen werden die 33

34 KAPITEL 3 - ANALYSE Antworten aber nicht direkt mittels der verschlüsselten Daten erstellt, sondern durch MetaInformationen, welche dem eigentlichen Tupel hinzugefügt wurden. Für jedes Attribut einer Tabelle, welches später in Bedingungen der Querys verwendet werden können soll, wird dazu ein zusätzliches davon abgeleitetes Attribut geschaffen. Die Domäne der möglichen Werte des Klartextattributes wird dafür in nicht überlappende Partitionen aufgeteilt, welche die Domäne komplett abdecken. Dies sei mit Hilfe einer kleinen Beispiel-Relation verdeutlicht: PNr Name Kunze Müller Krause Gehalt Die Partitionseinteilung für das Name-Attribut könnte etwa nach dem ersten Buchstaben des Namens erfolgen, so dass schließlich A* 1... K* M* Z* 26 gilt. Die Abbildung wird dabei Identification Function genannt, die Elemente des Bildbereichs sind Identifier. Für das PNr-Attribut sei diese folgend: PNr-Identifier = PNr / 50. Das Klartexttupel schließlich wird als Ganzes verschlüsselt und zusammen mit seinen Identifiern dem DBMS als Ciphertupel übergeben. Da alle Attribute des Klartexttupels zusammen in ein neues Attribut verschlüsselt werden, sind später offensichtlich keine serverseitigen Projektionen möglich. enc (PNr, Name, Gehalt) enc (55, Kunze, 30000) enc (111, Müller, 20000) enc (222, Krause, 10000) PNr-Identifier Name-Identifier Die Anwendung muss nun modifizierte Anfragen an das DBMS schicken, indem die eigentlich gewünschten SQL-Anfragen entsprechend der definierten Identification Functions angepasst werden. Das System inklusive der folgenden Beispiel-Query sind in Abbildung 3.3 dargestellt. SELECT AVG(Gehalt) WHERE Name='Krause' 34 SELECT enc WHERE Name-Identifier=11

35 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN Abbildung 3.3: PartitionDB-Konzept mit Beispiel-Query Die Antwort der DBMS würde also die verschlüsselten Tupel enc (55, Kunze, 30000) und enc (222, Krause, 10000) umfassen. Um das tatsächliche Ergebnis zu erhalten, muss clientseitig die ursprüngliche Anfrage noch einmal über die dann entschlüsselten Tupel ausgeführt werden. Eine serverseitige Vorselektionen bezüglich des Gehalts ist in dem angegebenen Beispiel nicht möglich. Das Konzept unterstützt neben der Gleichheitsoperation auch weitere Operatoren, wie <, <=, =>, >. In diesen Fällen müssen Listen aller in Betracht kommenden Identifier erstellt werden. Um etwa alle Personen mit einer PNr zwischen 125 und 200 zu erhalten, müsste dem Server folgende modifizierte Anfrage geschickt werden: SELECT Name WHERE PNr>125 AND PNr<200 SELECT enc WHERE PNr-Identifier=2 OR PNr-Identifier=3 Das serverseitige Ergebnis wäre enc (111, Müller, 20000), welches der Client noch bereinigen müsste. Es sind auch Joins möglich, aber unter dem Vorbehalt, dass die Selektion nur partitionsweise funktioniert und so jeweils auch Tupelverknüpfungen entstehen, welche später vom Client 35

36 KAPITEL 3 - ANALYSE wieder verworfen werden müssen und serverseitig bei kaskadierten Anfragen einen extremen Bearbeitungs- und Übertragungsoverhead entstehen lassen können. Nicht unterstützt werden serverseitig Aggregations-Operationen. Der Server kann zwar wie bei Sortieroperationen eine Vorsortierung nach Partitionen vornehmen, allerdings kennt er die Klartextdaten nicht und kann diese von daher auch nicht zusammenfassen. Entsprechend kann auch keine direkte Aktualisierung von Attributen durch die DBMS vorgenommen werden, à la: SET Gehalt *= 1.05 Der Client muss in einem solchen Fall die entsprechenden Tupel anfordern und entschlüsseln, die Attribute aktualisieren, danach die Identifier neu berechnen, die Klartexttupel wieder verschlüsseln und die Ciphertupel zurück an das DBMS schicken. Dieses Konzept bietet also die serverseitige Speicherung der Daten, aber dort kein komplettes SQL-DBMS. Vielmehr dient es dazu, die Anzahl der Tupel und damit den Arbeitsaufwand des Clients zu reduzieren, indem es serverseitig eine Vorauswahl trifft. Die Granularität der Partitionierung und damit die mögliche Selektivität der Anfragen kann dabei beliebig gewählt werden. Eine Domäne kann etwa auf genau einen Identifier abgebildet werden oder es könnte auch dafür gesorgt werden, dass jede Partition maximal ein Klartextelement abbildet - letzteres würde den Selektionsoverhead eliminieren, allerdings auch die Vertraulichkeit einschränken. So etwas wäre gleichbedeutend mit einer deterministischen Verschlüsselung, wodurch aus der Identifier-Verteilung Rückschlüsse auf die eigentlichen Werte der Attribute möglich wären. Die Vertraulichkeit der Klartextwerte gegenüber dem DBMS wird also durch Zusammenfassung in größere Gruppen und Abbildung auf andere Werte erreicht. Da das Konzelationssystem des eigentlichen Tupels keine Rolle für die Arbeitsfähigkeit des DBMS spielt, kann dieses so sicher wie möglich gewählt werden. Die dafür gewählten Schlüssel müssen nie den Client verlassen. Die Partitionierung kann aber auch dazu führen, dass Tupel an Clients ausgeliefert werden, welche ein standardmäßiges Datenbanksystem nicht zurückgegeben hätte, da auch die Autorisierungstechnik des Systems von der Granularität der Partitionierung eingeschränkt wird. So kann es bei unvorsichtiger Partitionierung zu Vertrauensbrüchen kommen. Wenn beispielsweise Manager einer Business Unit (BU) nur Daten ihrer Mitarbeiter abfragen können sollen, würden die Zugriffsrechte so gesetzt, dass Managern nur Tupel mit der selben BU-Id zurückgegeben werden, die sie auch selbst haben. Falls die Partitionierung allerdings gröber ist, also mehrere BU-Ids auf den selben Identifier abbilden, kann die Autorisierung auch nur noch so grob gesetzt werden und entsprechend werden auch Tupel anderer Abteilungen an den Client ausgeliefert. 36

37 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN Dieses Beispiel ist nicht sonderlich praxisfern. Sollte die Granularität nämlich genau auf die BU-Ids abgestimmt werden, so dass eine Id auf genau einen Identifier abbildet, um so eine korrekte Autorisierung zu ermöglichen, entspräche die Verteilung der Identifier über die Tupel, der Verteilung der Mitarbeiter über die Abteilungen. Somit wird also die Vertraulichkeit eingeschränkt. Bezüglich der eigenen Aufgabenstellung kann gesagt werden, dass das Schutzziel Vertraulichkeit größtenteils erreicht wurde, aber die Möglichkeit statistischer Angriffe besteht. Auf die Schutzziele Verfügbarkeit und Integrität geht der Entwurf nicht ein, ihr Niveau entspricht damit anderen cloud-basierten Datenbanken. Die Performanz ist dagegen eingeschränkt. Durch die Partitionierung kommt sowohl zum Bearbeitungs-, als auch Übertragungsoverhead. Letzterer wird noch verstärkt durch die nicht vorhandene Selektionsfähigkeit und fehlende Möglichkeit serverseitig auf dem Datenbestand arbeiten zu können. Weiterhin werden die Klienten mit Kryptographie und Nachbearbeitung belastet. Schließlich ist auch keine transparente Einbindung gegeben. Es müssen sowohl in Klientanwendungen als auch DBMS eingegriffen werden. Auch die Transparenz bei Arbeiten mit dem System ist nicht vorhanden. Da erweiterte Funktionalitäten der Datenbanksysteme verloren gehen, müssen die Anwendungen das kompensieren und daraufhin angepasst werden (VERWANDTE ARBEIT) RELATIONAL CLOUD / CRYPTDB Ein anderes Konzept mit Verschlüsselung auf Anwendungsebene wird als Teil der Relational Cloud (Curino et al. 2011) in der CryptDB (Popa et al. 2011) angewandt. In diesem wird direkt mit den verschlüsselten Daten gearbeitet, was durch eine Kombination verschiedener Arten von Konzelationssystemen erreicht wird. Jeder Attributwert eines jeden Tupels wird dafür auf 3 verschiedene Arten in sogenannten Onions verschlüsselt, in der Datenbank gespeichert (siehe Abbildung 3.4). Die deterministisch verschlüsselte Variante wird verwendet um Bedingungen auf Gleichheit (=) zu prüfen sowie für GROUP BY und COUNT-Operationen. Die ordnungserhaltende Onion dagegen wird eingesetzt, um Bedingungen auf Bereiche (<, <=, >=, >) zu prüfen und für Sortierungen und MIN/MAXOperationen. Die dritte Variante unterscheidet sich jeweils nach Datentyp. Ein Integer etwa wird homomorph verschlüsselt, um damit rechnen zu können. Ein String dagegen wird nach nach dem Kryptographie-Protokoll aus (Song, Wagner, et Perrig 2000) für Operationen wie LIKE sicher aufbereitet. 37

38 KAPITEL 3 - ANALYSE Abbildung 3.4: CryptDB-Onions (Popa et al. 2011) Um die Anspassung einzelner DB-nutzenden Anwendungen zu vereinfachen, wird zwischen diese und das DBMS ein Proxy gesetzt, welcher die Anfragen und Antworten übersetzt. So muss etwa bei jedem Vorkommen eines Attributes in den Query-Bedingungen entschieden werden, welche der drei verschlüsselten Varianten des Attributes an dieser Stelle genutzt werden soll. Dabei wird auch die benötigte Stufe innerhalb der Onion festgestellt. Der Proxy lässt diese vor der eigentlichen Anfrage in die Datenbank schreiben, indem er den dafür notwendigen Schlüssel an die DBMS schickt und dort von einer benutzerdefinierten Funktion die Werte der Spalte in die gewünschte weniger sichere Stufe entschlüsseln lässt (siehe Abbildung 3.5). Auch die Konstanten einer Query müssen vom Proxy dann jeweils so verschlüsselt werden, dass sie der gewählten Onion-Schicht entsprechen. Außerdem müssen einzelne Operationen durch den Aufruf benutzerdefinierter Funktion ersetzt werden, wie SUM oder +, da für das Ausführen derartiger Operationen auf verschlüsselten Daten die DBMS-eigenen Algorithmen nicht geeignet sind. Danach wird die modifizierte Query an das DBMS geschickt, welches diese auf den verschlüsselten Daten beantwortet und das Ergebnis zurückschickt. Der Proxy entschlüsselt schließlich das Ergebnis, bevor er es der Anwendung übergibt. So kann das System auch für die Datenbankebene relativ transparent implementiert werden, da das DBMS selbst keinerlei Wissen über die Onion-Architektur benötigt. Allerdings müssen die weniger sicheren Schichten deswegen direkt in die Datenbank geschrieben werden und sind nicht etwa nur temporär für die Abarbeitungsdauer im Arbeitsspeicher. Dabei ist weiterhin zu beachten, dass etwa für einen Table-Scan alle in Bedingungen benötigten Spalten vor der eigentlichen Query komplett in die gewünschte Schicht gebracht werden müssen. Siehe zum Beispiel Abbildung vor Abarbeitung der Query muss das Name-Eq-Attribut aller Zeilen in die DET-Schicht entschlüsselt werden, damit die Tupel auf Namensgleichheit getestet werden können. Damit entsteht offensichtlich eine enorme 38

39 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN Vorarbeit für die Query-Ausführung, weswegen geschälte Schichten auch nicht wieder unmittelbar aufgelegt werden. Entsprechend der Aktivität in der Datenbank kann es also dazu kommen, dass ein großer Teil der Daten nicht optimal geschützt in der Datenbank vorliegt. Abbildung 3.5: CryptDB-Konzept mit der Beispiel-Query des PartitionDB-Konzepts Wie beim PartitionDB-Konzept können keine Operationen direkt durch das DBMS auf den verschlüsselten Daten vorgenommen werden. Die HOM-Onions könnten zwar direkt durch das DBMS aktualisiert werden, aber dies würde die Konsistenz aufgrund der zwei anderen nicht modifizierten Onions verletzen. Da deren innerste Verschlüsselung nie innerhalb des DBMS aufgegeben wird, müssen die aktualisierten Onions also clientseitig neu erstellt und dann zurückgeschrieben werden. Bezüglich der eigenen Aufgabenstellung kann gesagt werden, dass die Vertraulichkeit der Daten in der Cloud größtenteils erreicht wird, mit der Einschränkung, dass die Daten über größere Zeiträume nur mit nicht-optimnaler Konzelation geschützt sind, wie deterministischer Verschlüsselung. Die Verfügbarkeit ist nicht Teil des CryptDB-Konzepts, aber des Dachkonzepts der Relational Cloud. Eine Verschlechterung der Performanz ist 39

40 KAPITEL 3 - ANALYSE durch das Arbeiten mit homomorphen Strukturen gegeben, was aktuell außerordentlich langsam und damit produktiv nicht einsetzbar ist. Weiterhin wird die Reaktionsfähigkeit durch das Schälen der Spalten vor der eigentlichen Querybearbeitung verschlechtert. Die Transparenz ist insofern sichergestellt, dass ein Proxy die Kommunikationsvermittlung zwischen Klienten und Datenbankserver übernimmt und nur die Schlüsselverwaltung bei der Anwendung verbleibt. Da die Datenbanksoftware selbst nicht angepasst wird und sich damit nicht gewahr ist, dass die gespeicherten Daten nicht im Klartext vorliegen, müssen für den Erhalt dieser Funktionalitäten DBMS-spezifische Implementation durch benutzerdefinierte Funktionen vorgenommen werden. Dieses Konzept erfordert keine Modifikation der Datenbanksoftware, solange sie die Ausführung benutzerdefinierte Funktionen bietet. Der Proxy muss aber jeweils mit zusätzliche Informationen über die Tabellen ausgestattet werden sowie für die verschiedenen DBMS erweitert werden, um mit diesen kommunizieren zu können. Wie die Beispiele deutlich gemacht haben, ermöglicht der Einsatz von Konzelation in der Anwendungsebene die vertrauliche Nutzung von Datenbanksystemen in der Cloud. Da die Daten auf dem Datenbankserver immer (rest-)verschlüsselt bleiben und die notwendigen Schlüssel auch nicht auf diesem existieren, ist die Vertraulichkeit der Daten weder durch unzureichend gesicherte Systeme noch durch deren Betreiber gefährdet. Diese Verschlüsselungsebene ermöglicht somit dem Cloud-Nutzer den Cloud-Anbieter von seinem Vertrauensbereich auszuschließen. Da die Datenbanksoftware nur noch auf die Schlüsseltexte Zugriff haben, werden so Funktionalitäten der Systeme eingeschränkt und Eingriffe in die Queryabarbeitung notwendig, um dennoch korrekte Ergebnisse zu erhalten. Auch die Anwendungen sind von Eingriffen betroffen, da die Kryptographie in ihrer Ebene stattfindet. Existierende Programme müssen erst entsprechend modifiziert werden, um diese anwenden zu können. Die Arbeit der Systeme wird also erschwert und die Performanz und Transparenz verschlechtert. Es folgt noch ein zusammenfassender Überblick über die verschiedenen generellen Möglichkeiten ein vertrauliches System zu entwerfen. 3.3 ZUSAMMENFASSUNG KONZELATION Bei Konzelation auf Dateisystem- und Datenbank-Ebene müssen die für die Ver- und Entschlüsselung notwendigen Schlüssel auf dem Datenbankserver vorhanden sein, damit 40

41 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN das DBMS zur Laufzeit die notwendigen Klartext-Daten erhalten kann. Wer legitim Zugriff auf den Server besitzt oder sich illegal verschafft, kann also sowohl an die Schlüssel des Kryptosystems als auch an die Klartextdaten gelangen. Wenn der Datenbankserver nun nicht vertrauenswürdig ist, aber Nutzer trotzdem sicher sein möchten, dass niemand an die in der Datenbank enthaltenen Informationen gelangen kann, bleibt nur die Möglichkeit, die Daten bereits verschlüsselt an den Server zu übergeben - also Konzelation auf Anwendungsebene zu betreiben. Das Datenbanksystem kennt somit nur die verschlüsselten Daten und muss auf diesen arbeiten. So können Klartext-Informationen auf die IT-Systeme beschränkt bleiben, welche zum eigenen Vertrauensbereich zählen. Des Weiteren entfallen so auch Bedenken bezüglich der Vertraulichkeit der Daten während der Kanalübertragung. Wie aufgezeigt ist diese Konzelationsebene allerdings intransparenter und technisch wesentlich anspruchsvoller gegenüber anderen, da für existierende DBMS in deren QueryBearbeitung eingegriffen wird, und dies ihre Performanz und Funktionalität negativ beeinflusst. Tabelle 3.1 gibt eine Übersicht über verschiedene wichtige Eigenschaften, welche sich aus den unterschiedlichen Konzelationsebenen für die entsprechenden Datenbanksysteme ergeben, außerdem sind in Abbildung 3.6 die sich ergebenden Vertrauensbereiche für diese Systeme dargestellt. Abbildung 3.6: Vertrauensbereiche verschiedener Datenbanksysteme 41

42 KAPITEL 3 - ANALYSE Konzelationsebene Performanz Vertraulichkeit bei Granularität der Konzelation Funktionalität DBS Transparenz Anwendungen DBS Dateisystem Datenbank Anwendung unverändert unverändert verschlechtert ruhendem System ruhenden Daten aktiven Daten Dateien DB-Objekte abhängig von Implementation bis DB-Objekte unverändert unverändert eingeschränkt gegeben gegeben verloren gegeben verloren verloren Tabelle 3.1: Eigenschaften verschiedener Datenbanksystem-Konzelationsebenen Für das Sicherheitskonzept der eigenen Arbeit soll nicht von der Vertrauenswürdigkeit der Cloud-Anbieter ausgegangen werden, somit können deren Server nicht zum Vertrauensbereich der Nutzer gehören, da diese nie die letztendliche Kontrolle über die Vorgänge auf den Servern haben. Aber nur wenn die Daten den Datenbankserver bereits verschlüsselt erreichen und dort auch nicht entschlüsselt werden können, besteht keine Notwendigkeit diesen in den eigenen Vertrauensbereich einzuschließen. Die Verschlüsselung der Daten müsste dementsprechend also auf Anwendungsebene erfolgen. Wenn allerdings die aufgezeigten damit einhergehenden Einschränkungen nicht in Kauf genommen werden sollen, besteht auch die Möglichkeit das Datenbanksystem nur teilweise in die Cloud zu schieben, um dennoch Cloud-Ressource nutzen zu können. Eine Möglichkeit dazu wird im nächsten Punkt ausgearbeitet. 3.4 CLOUD-STORAGE Prinzipiell werden in der Cloud, neben der offensichtlichen Netzwerk-Bandbreite, zwei elementare IT-Ressourcen angeboten: Rechenleistung und Permanentspeicher, wie bereits in den Vorbetrachtungen dargelegt. Das Auslagern des Rechnens auf Daten ist entweder sicherheitskritisch, wenn unverschlüsselt; oder eingeschränkt und aufwendig, wenn verschlüsselt. Das Ablegen ruhender Daten in die Cloud ist dagegen relativ unproblematisch sicher zu gestalten. Dafür müssen die Daten nur im eigenen Vertrauensbereich verschlüsselt werden, also bevor sie in die Cloud geschoben werden. Verfügbarkeit Die Cloud als Speicher ist sogar einer der erfolgreichsten Cloud-Dienste. Entsprechende Anbieter speichern dabei üblicherweise nicht nur einfach die Daten, sondern kümmern sich etwa mit ihrer Infrastruktur auch um (mehr-seitige) Redundanz durch Replikation, um nach 42

43 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN außen einen fehlertoleranten Dienst anbieten zu können. Nutzer müssen sich also weder um das aufwändige Administrieren von Redundanz-Systemen noch um das ständige Ersetzen ausgefallener Komponenten oder das Anpassen an stetig steigenden Speicherbedarf kümmern - all dies bieten Cloud-Storage-Anbieter als Dienst. Falls also die Möglichkeit besteht, selber dem DBMS ausreichend Rechenressourcen zur Verfügung zu stellen, kann das Datenbanksystem auch in eine separate Rechenkomponente und eine Speicherkomponente zerlegt werden, wie in Abbildung 3.7 dargestellt. Wenn erstere im eigenen Vertrauensbereich verbleibt und die diesen verlassenden Daten verschlüsselt werden, kann so die Vertraulichkeit des Gesamtsystems garantiert werden. Gleichzeitig wird aber zumindest für die Speicherung der Datenbank Cloud-Infrastruktur verwendet und somit wenigstens teilweise von der Cloud profitiert. Abbildung 3.7: Vertrauensbereiche eines 2-Komponenten-Datenbanksystems mit DS-Konzelation Um die Vertraulichkeit der in der Cloud ruhenden Daten zu gewährleisten, kann sowohl Kryptographie auf Dateisystemebene oder auf Datenbankebene genutzt werden. Da die verschiedenen DBMS allesamt mit der Dateisystemschnittstelle vertraut sind, bietet es sich allerdings an, die Vertraulichkeitskomponente hinter dieser zu platzieren. So kann die Konzelation transparent mit verschiedenen Datenbanksystemen genutzt werden. Auf Datenbankebene dagegen müssten systemspezifische Modifikationen der eigenen Lösung 43 Transparenz

44 KAPITEL 3 - ANALYSE vorgenommen werden und im Nachhinein wäre auch die Wartung bezüglich der Softwarezyklen der Datenbanksoftware notwendig. Weiterhin bleibt so auch die Möglichkeit erhalten, die Implementation für NichtDatenbanksysteme vertraulich nutzen zu können. Da allerdings viele Datenbanksysteme selber Verschlüsselungstechniken bieten, soll der Prototyp später auch ermöglichen auf eine eigene Verschlüsselung verzichten zu können, wenn der Nutzer die Vertraulichkeit anderweitig sicherstellen kann. Nachdem die Vertraulichkeit ausgearbeitet wurde, erfolgt nun eine verstärkte Konzentration auf die zwei anderen Schutzziele. Dabei sei zunächst angemerkt, dass auch diese von einem Vertrauensbereich profitieren würden. Wenn etwa auf ein System ungewollter Zugriff erfolgen kann, ist nicht nur die Vertraulichkeit der darauf enthaltenen Daten gefährdet; durch einfaches Löschen oder unberechtigte Modifikation der Daten kann auch deren Verfügbarkeit oder Integrität zerstört werden. Da aber nicht nur Menschen, sondern auch technische Unzulänglichkeiten die beiden letzteren Schutzziele gefährden, ist ein ausreichend zugriffs-gesichertes System noch keine Garantie für das Erreichen dieser beiden Ziele EVENTUAL CONSISTENCY Da der Systementwurf eine starke Konzentration auf die Speicherressourcen der Cloud erfährt, sei auf eine bei der Datenablage in der Cloud häufig anzutreffende Eigenschaft von Speichersystemen eingegangen. Replikationssysteme, die aus Gründen der Verfügbarkeit oder Lastverteilung Kopien desselben Datums halten, müssen sich über Änderungen an diesem synchronisieren, um konsistent zu bleiben. Wenn zu keiner Zeit einzelne Knoten unterschiedliche Daten nutzen, also strikte Konsistenz wahren sollen, müssen Änderungen eines Datums unmittelbar an allen haltenden Knoten vorgenommen werden. Die dafür notwendigen Verfahren verschlechtern allerdings die Leistungsfähigkeit und Skalierbarkeit dieser Systeme. In Umgebungen, wie der Cloud, in denen die Skalierbarkeit aufgrund der hohen notwendigen Concurrency Priorität hat, wird deswegen statt strikter Konsistenz oft nur noch Eventual Consistency zugesichert (Vogels 2009). Diese garantiert nur noch, dass Änderungen letztendlich im ganzen System vorgenommen werden und damit zumindest temporär inkonsistente Datenbestände existieren. Integrität Es gefährdet offensichtlich die Integrität, wenn eine Änderung einem Server mitgeteilt wird und damit die Transaktion vom Client als abgeschlossen angesehen wird, aber danach von anderen Servern des Replikationsverbundes immer noch die nun veralterte Daten eingelesen 44

45 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN werden können. Wird diese dann erneut modifiziert und gespeichert, können damit sogar vorherige Veränderungen überschrieben werden. Dieser Effekt ist besonders relevant bei geografisch verteilten Schreibern und Lesern, da solche wahrscheinlicher verschiedene Server erreichen. Aber auch bei Identität von beiden kann dieses Phänomen auftreten, wenn der Server der letzten Anfrage etwa wegen Überlastung bei der nächsten nicht genutzt wird. Eine genaue quantitative Untersuchung dieser Problematik beispielhaft für S3 bietet (Bermbach et Tai 2011). Von dieser Eigenschaft können in der Cloud alle Formen der Datenspeicherung betroffen sein, etwa Cloud-Datenbanksysteme oder auch simpler Cloud-Storage. Da Integrität eines der zu erreichenden Schutzziele der Aufgabe ist, muss diese Problematik beim Entwurf entsprechend berücksichtigt werden CLOUD-STORAGE AUF DATENBANKEBENE Um einen entsprechenden Systementwurf gestalten zu können, wird nun analysiert auf welche Weise Cloud-Storage als Datenbankspeicher verwendet werden kann. Es scheint naheliegend der Datenbanksoftware beizubringen, statt mit einem üblichen Dateisystem direkt mit einem Cloud-Storage-Interface zu interagieren und so die Interaktion mit einem lokalen Dateisystem zu umgehen. Da für den Austausch der Daten zwischen Datenbank und Softwaresystem spezifische Komponenten zuständig sind (siehe Unterpunkt 2.3), ist zu erwarten, dass Änderungen auf diese beschränkt bleiben. Im nächsten Unterpunkt wird ein entsprechendes Konzept vorgestellt (VERWANDTE ARBEIT) DATABASE ON S3 Ein interessanter Entwurf zur Nutzung von Cloud-Storage als Datenbankspeicher wird in dem Paper Building a Database on S3 (Brantner et al. 2008) vorgestellt. Dieses benutzt einerseits Amazons S3 als Speicherressource für die Datenbank sowie das ebenfalls von Amazon angebotene SQS15 (Simple Queue Service) zur Harmonisierung der auf diesem Datenbestand nebenläufig arbeitenden Clients. Da die Autoren ausdrücklich ein Konzept für webbasierte Anwendungen entwerfen, wonach Skalierbarkeit und Verfügbarkeit die wichtigsten Kriterien seien, konzentrieren sie sich

46 KAPITEL 3 - ANALYSE hauptsächlich auf das Erreichen hoher Nebenläufigkeit und Verfügbarkeit, in dem Sinne, dass einzelne Clients nicht die Arbeitsfähigkeit des DBS gefährden können. So bietet das entworfene Standard-Protokoll keine Atomizität, strenge Konsistenz oder Isolation, da die klassischen ACID-Kriterien im Webumfeld weniger Relevanz als Skalierbarkeit und Verfügbarkeit besitzen und nach dem CAP-Theorem auch nicht alle Eigenschaften gleichzeitig erreicht werden können (aufgezeigt in (Brewer 2000) und bewiesen in (Gilbert et Lynch 2002)). Allerdings wird etwa für das Erreichen von Atomizität eine Erweiterung vorgestellt, deren Einsatz das System allerdings weniger performant macht. Abbildung 3.8: Database on S3-Konzept Das Paper beschreibt das Konzept einer Storage Engine für Datenbanksysteme, welche die zwei unteren Schichten üblicher Systeme umfasst (siehe Abbildung 3.8 und vergleiche Abbildung 2.2). Der Record Manager liefert auch weiterhin die record-basierte Schnittstelle für das DBMS und organisiert die Records in Pages, welche wiederum mit dem Page Manager ausgetauscht werden. Das Zusammenfassen von Records zu Pages ist wie bei standardmäßigen Datenbanksystemen der Latenz zum Permanentspeicher geschuldet. Wie das Paper auch selbst aufzeigt, ist eine gewisse Mindestgröße der Datenpakete bei der Kommunikation mit dem Cloud-Storage sinnvoll, um eine effiziente Bandbreite zu erreichen. 46

47 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN Die einzelnen Records bestehen aus zwei Teilen, einem Schlüsselwert sowie dem eigentlichen Datenbereich. Je nach dem darauf aufgesetzten DBMS könnten darin etwa typische relationale Tupel enthalten sein. Die angebotenen Operationen des Record Managers ermöglichen das Erschaffen, Verändern, Löschen, Einlesen und Durchsuchen von Records (create, update, delete, read, scan). Der Page Manager übernimmt dann die Organisation der Pages in B-Bäumen und die Speichern/Lade-Operationen der Pages in/aus der Cloud sowie das lokale Caching. Das Laden von nicht im Cache gehaltenen Pages erfolgt dabei direkt von S3. Für das Einfügen und Aktualisieren von Pages wird laut dem zweistufigen Commit Protocol des Papers allerdings ein Umweg über den SQS-Dienst genommen. Jedem B-Baum ist da genau eine Queue zugeordnet, welche einen Log-Eintrag über eine gewünschte Änderung erhält (insert, update, delete) - dies ist der erste Teil des Protokolls. Die Log-Einträge sind idempotent. Das bedeutet, auch ein mehrfaches Abarbeiten desselben Log-Eintrags hat den gleichen Effekt wie einmaliges. Dies verhindert etwa Probleme, wenn ein Client während des Bearbeiten eines Log-Eintrags ausfiel, dieser deshalb nicht komplett umgesetzt wurde und später durch einen anderen Client erneut bearbeitet wird. Das Abarbeiten der Log-Einträge ist der zweite Teil des Protokolls und schreibt die Änderungen in S3 fest. Der Grund für den Zwischenschritt ist, dass es beim direkten Schreiben der Änderungen in S3 bei vielen nebenläufigen Clients dazu kommen kann, dass diese sich gegenseitig ihre Änderungen überschreiben. Da aber nur jeweils eine Instanz gleichzeitig die idempotenten Log-Einträge einer Queue in den zugehörigen B-Tree festschreiben darf, entfällt dieses Problem. Die Instanz, welche das Überschreiben vornimmt, kann entweder ein extra zugeordneter Rechner sein, oder ein beliebiger Client. Ist sie ersteres müssen mögliche Ausfälle dieser berücksichtigt werden; ist sie ein beliebiger Client, ist ein Lock pro Queue notwendig, um zu verhindern, dass mehr als ein Client gleichzeitig diese Queue abarbeitet. Dieser zweite Teil des Commit Protocols stellt also einen asynchronen Mechanismus dar, welcher die Schreibaufträge beliebig vieler Clients synchronisiert. Offensichtlich werden allerdings so nicht unmittelbar Änderungen allen Clients zugänglich, diese arbeiten ja solange die Modifikationen anderer Clients nicht in S3 übertragen wurden, mit den dort vorhandenen alten Pages / Records. Das wird aber in Kauf genommen, da ein synchroner Mechanismus zu Blockierungen führt, was das Erreichen des Ziels hoher Skalierbarkeit verhindern würde. Einer der interessantesten Punkte des Konzepts ist, dass hier nicht nur die DBMS-Ebene für die parallele Bearbeitung von Querys genutzt wird, sondern die Nebenläufigkeit vor allem auf Amazons hochskalierenden Speicherdienst verlagert wird. So kann eine hohe Anzahl nebenläufiger Clients und damit parallel arbeitender Querys erreicht werden - wie bereits angemerkt, allerdings ohne strenge Konsistenz. Damit bietet das Paper selbst zwar ein Verfügbarkeitskonzept, aber keines für Integrität oder Vertraulichkeit, welche noch ergänzt werden müssten. Dies dürfte aufgrund der Tatsache, dass auf den einzelnen Clients jeweils 47

48 KAPITEL 3 - ANALYSE eine eigene Datenbanksoftware läuft und es eben keine zentrale Instanz gibt, eine relativ aufwendige Schlüsselverteilung bedingen. Wenn auch die Einbindung des Cloudspeichers sehr gut gelungen wirkt, so ist doch einerseits das Ausrichten auf einen Cloud-Anbieter unvorteilhaft, andererseits ist keine transparente Nutzung mit existierenden DBMS oder gar bestehenden Datenbanksystemen möglich. Transparenz bezüglich verschiedener Anwendungen könnte erreicht werden, indem die Storage Engine für diverse DBMS implementiert wird. Eine Einbindung in sowie Wartung für multiple und vielfältige Systemarchitekturen wirkt allerdings wenig sinnvoll und spätestens bei Closed-Source-Datenbanksoftware ist dies wohl auch nur mit Unterstützung der entsprechenden Vertreiber möglich. Prinzipiell bleiben ACID-basierte DBMS, und damit der bis heute am verbreitetste Datenbanktyp im Firmenumfeld, dabei außen vor. Das Konzept scheint also nur für das ursprüngliche Ziel der Autoren nützlich; ist allerdings nicht praktikabel als genereller Ansatz zur Einbindung von Cloud-Storage in heute existierende Datenbanklandschaften, welche hauptsächlich relationalen Charakter haben. Transparenz Hiermit wird auch das direkte Eingreifen in die Speicherebene eines DBMS für das eigene Konzept ausgeschlossen, also die Speicherung der Daten in der Cloud innerhalb der Datenbanksoftware zu organisieren und so ein klassisches Dateisystem komplett zu umgehen. Dies wäre, wie das Integrieren fremder Konzelationstechnik in der Query-Ebene, wenig transparent bezüglich der Vielzahl möglicher Datenbanksoftware. Damit bleibt für das Einbinden von Cloudspeicher nur die Dateisystemebene CLOUD-STORAGE AUF DATEISYSTEM-EBENE Nun soll analysiert werden, wie der Datenaustausch zwischen DBMS und Cloudspeicher organisiert werden kann. Dafür wird zunächst die klassische Kommunikation zwischen einem relationalen DBMS und einem lokalen Permanentspeicher ausgearbeitet (GarciaMolina, Ullman, et Widom 2009), (Saake, Heuer, et Sattler 2005). Datenorganisation Die interne Sicht eines relationalen DBMS auf seinen Datenbestand sind zu Tabellen gruppierte Tupel (Zeilen). Das Schema der Tupel variiert zwischen den Tabellen aber nicht in ihnen. Falls die einzelnen Attribute (Spalten) der Tupel eine definierte Größe haben, belegen demnach alle Tupel einer Tabelle die gleiche Speichermenge. Dies würde deren Administration einfach halten; so müssten etwa keine Meta-Informationen über die Attribute 48

49 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN der einzelnen Tupel gehalten werden. Zum Adressieren eines spezifischen Attributs muss nur das für alle Tupel der Tabelle gültige Schema herangezogen werden, um den Offset des Attributs vom Tupelanfang zu bestimmen. Wenn der Speicherplatz eines Attributes variabel ist, muss für jedes Tupel vermerkt und gewartet werden, wie viel Speicher das Attribut zur Zeit belegt, um dessen Ende oder das im Speicher darauffolgende Attribut finden zu können. So kann es bei einer naiven Speicherverwaltung zu massiver Fragmentierung der Datenbankdateien kommen, wenn sich die Länge der Attribute beständig ändert, worunter die Performanz des ganzen Datenbanksystems leiden würde. Dennoch werden üblicherweise Tupel mit variablen Attributen definiert, weil feste Vorgaben für bestimmte Stringfelder zu Speicherplatzverschwendung führen. Wenn etwa ein Attribut als Ablage für Adressen dient, muss dieses so dimensioniert sein, dass auch außergewöhnlich lange Adressen komplett gespeichert werden können. Im Schnitt werden diese allerdings wesentlich kürzer sein, trotzdem müssten vom Speicher genauso viel Byte wie bei den wenigen langen Adressen gelesen werden, nur dass ein Großteil des Feldes mit Null-Bytes gefüllt wäre. Abbildung 3.9: Wahrnehmung des Datenbestands durch verschiedene Datenbanksystemkomponenten Die einzelnen Tupel sind aber nun sehr variant in ihrer Länge und oft nur wenige Bytes groß. Dies würde die Kommunikation mit dem Dateisystem bei tupel-weisem Datenaustausch einerseits weiter komplizieren und andererseits wäre dieser wenig effizient, da der Sekundärspeicher in den meisten Fällen aus Magnetplatten besteht, deren Nachteil vor allem in ihrer hohen Latenz durch die notwendige Ansteuerung bestimmte Bereiche der Platte mit 49

50 KAPITEL 3 - ANALYSE dem mechanischen Lese/Schreib-Kopf liegt. Von einem solchen angesteuerten Punkt aus kann dann aber sequentiell sehr zügig gelesen werden. Umso größer die Datenpakete beim Austausch zwischen DBMS und Dateisystem sind, desto höher ist deswegen der Durchsatz. Üblicherweise werden deswegen mehrere Tupel zu Pages fester Größe zusammengefasst (siehe Abbildung 3.9). Es ist Aufgabe des DBMS, das Zusammenlegen der Tupel so zu gestalten, dass schließlich möglichst mehr als das initial benötigte Tupel daraus verwendet und so ein hoher effektiver Durchsatz erreicht wird. In bestimmten Anwendungsgebieten von Datenbanken werden daher auch manchmal nicht die Tupel als Ganzes zu Pages zusammengefasst, sondern jeweils die einzelnen Attribute dieser, zum Beispiel wenn zum Zweck der Datenanalyse oft Anfragen über einzelne Spalten aller Tupel laufen. Tupel Modifikation Tupel einfügen Da die tatsächliche physikalische Speicherung aber abhängig von den eigentlichen Tupeln ist, wird diese natürlich auch durch Modifikation der Tupelmenge beeinflusst. Wenn etwa ein neues Tupel einer Seite hinzugefügt werden soll, kann dies nur geschehen, solange noch entsprechend viel Platz in der Seite übrig ist. Sollte dies nicht mehr der Fall sein, müssen die Tupel der Seite physikalisch neu aufgeteilt werden, und eventuell weitere Seite geschaffen werden (siehe Abbildung 3.10). Abbildung 3.10: Modifikation des Datenbestands durch Tupel-Insertion 50

51 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN Ein Tupel zu entfernen ist selbst unproblematisch - der nun freie Speicherplatz kann inklusive seiner Größe in einer Liste mit verfügbaren Speicherplätzen vermerkt werden, so dass dort später passende neue Tupel abgelegt werden können. Ohne auf genaue technische Details einzugehen, sei aber angemerkt, dass das DBMS intern noch Verweise auf den Tupel also dessen Startadresse - besitzen kann. Deswegen werden neue Tupel nicht genau auf dem alten abgelegt. Stattdessen wird an diese Position ein sogenannter Tombstone gesetzt. Werden Attribute fester Größe aktualisiert oder Attribute variabler Größe mit einem gleich langen Wert ersetzt, hat dies keine weiteren Effekte auf die entsprechende Page. Bei Kürzung eines Tupels ergeben sich dagegen Möglichkeiten zur Defragmentierung, um so kleine freie Flächen zu größeren und damit wahrscheinlicher nutzbaren zusammenzufassen. Falls sich Tupel allerdings vergrößern, können sich die selben Probleme wie beim Einfügen neuer Tupel ergeben, so dass um den entsprechenden freien Speicher zu bekommen, Tupel verschoben oder neue Pages eingebunden werden müssen. Egal ob intern nur einzelne Tupel benötigt, modifiziert, hinzugefügt oder entfernt werden, die Kommunikation mit dem Dateisystem erfolgt page-weise. Es scheint daher logisch, auch den Datenaustausch mit dem Cloudspeicher page-weise zu gestalten, oder auch in Paketen von Pages, um bezüglich der hohen Netz-Latenz eine ähnliche Strategie zu nutzen, wie Datenbanksysteme dies im Umgang mit der hohen Latenz des Sekundärspeichers beim Laden von Tupeln tun. 3.5 VERGLEICH Auf den nächsten beiden Seite erfolgt eine tabellarische Gegenüberstellung verschiedener Datenbanksysteme, um noch einmal direkt die unterschiedlichen Ansätze und deren Vorund Nachteile darzustellen. Dabei wird einerseits zur besseren Vergleichbarkeit vorausgreifend der eigene Systementwurf mit aufgeführt sowie andererseits ein komplett selbst betriebenes und ein in der Cloud gemietetes Datenbanksystem. Bei den beiden Standardsystemen wurde davon ausgegangen, dass sie eine eigene KryptographieKomponente besitzen, also Verschlüsselung auf Datenbankebene ausüben. Eine Erläuterung der einzelnen Vergleichspunkte folgt der Tabelle. 51 Tupel entfernen Tupel aktualisieren

52 lokale DB cloud DB PartitionDB CryptDB DBonS3 SecCSIE lokal lokal + cloud lokal lokal lokal + cloud lokal Schlüsselort lokal (DBMS) cloud (DBMS) lokal (Anwendung) lokal (Anwendung + Proxy) / lokal (Proxy) Vertraulichkeit der Daten gegeben nicht gegenüber Systembetreibern zu kleine / falsche Partitionierungen ermöglichen statistische Angriffe geschälte Spalten ermöglichen statistische Angriffe nicht gegeben gegeben Vertrauensbereich Transparenz der SicherheitsErweiterung ohne Einschränkung ohne Einschränkung starke clientseitige Anpassung Anpassung Anwendung und Erweiterung des DBMS Anpassung DMBSStorage Engine Proxy mit DateisystemSchnittstelle erweiterte DBS Funktionalität ohne Einschränkung oft Einschränkung höherer Funktionalitäten gegenüber lokalen DBMS-Version allerhöchstens sehr eingeschränkt und grob arbeitend möglich durch extra ImplementierungsAufwand eingeschränkt möglich ohne Einschränkung ohne Einschränkung Rechenleistung lokal cloud cloud + lokal cloud lokal lokal Rechenaufwand zusätzliche Kryptographie in DBMS zusätzliche Kryptographie in DBMS zusätzliche Kryptographie + doppelte Queryabarbeitung, aber über Clients verteilt zusätzliche Kryptographie in DBMS und Clients + Berechnung mit homomorphen Strukturen zusätzliche Dispersion, Prüfsummenbildung und Kryptographie in separaten ProxySystem

53 Reaktionsfähigkeit Speicherleistung Speicherbedarf Concurrency-Ebene Konsistenz Cloud-Anbieter LockIn lokale DB cloud DB Kryptographie gut integriert - nur geringe zusätzliche Verzögerung Kryptographie gut integriert - nur geringe zusätzliche Verzögerung lokal cloud cloud einfache Speicherung der Informationen einfache Speicherung der Informationen DBMS (lokal) systemabhängig / DBonS3 SecCSIE erhöht durch Trennung von Verarbeitungs- und Speichersystem erhöht durch Latenz der ProxyKomponenten cloud cloud cloud durch zusätzliche Attribute bis zur Verdopplung dreifache Speicherung jeden Wertes, inklusive stark vergrößernde homomorphe Verschlüsselung von numerischen Werten einfache Speicherung der Informationen lokal erhöht durch Meta-Daten; sowie in Cloud durch Dispersion - letzteres ist allerdings ein VerfügbarkeitsFeature und keine Notwendigkeit des Systems DBMS (cloud) DBMS (cloud) DBMS (cloud) DB (cloud) DBMS (lokal) DBMS (lokal) systemabhängig streng streng eventually streng auf Amazons Dienste und Schnittstellen zugeschnitten Fragmente können einfach direkt zu anderen Anbietern kopiert werden oder inkrementell bei Modifikationen der Blöcke PartitionDB CryptDB verschlechtert durch vor der eigentlichen doppelte QueryQuery-Ausführung Ausführung müssen mitunter ganze Spalten umgeschrieben werden Wechsel des wie cloud DB plus wie cloud DB plus Anbieters nur durch zusätzlicher zusätzlicher aufwendigen Export Notwendigkeit eines Notwendigkeit eines und Import des DBS mit DBS mit gesamten entsprechender entsprechender Datenbestands, mit PartitionDBCryptDBentsprechender Konfiguration Konfiguration Downtime Tabelle 3.2: Vergleich diverser Datenbanksysteme

54 KAPITEL 3 - ANALYSE Rechenleistung lokal: Durch das eigene Betreiben der Systeme entstehen Kosten für die Anschaffung und den Betrieb ausreichender Ressourcen für Stoßzeiten sowie für Energie, Wartung und Personal. cloud: Durch die Nutzung von Cloudsystemen richten sich die Kosten nach der tatsächlich genutzten Rechenkapazität und -zeit. Speicherleistung lokal: Durch das eigene Zurverfügungstellen des Speichers entstehen Kosten für die tatsächlich genutzten Ressourcen sowie auch für Reserve- und Redundanz-Hardware, ebenso für Energie, Wartung und Personal. cloud: Durch die Nutzung von Cloudspeicher richten sich die Kosten nach den tatsächlich genutzten Ressourcen eines spezialisierten Anbieters. Rechenaufwand Offensichtlich führt Kryptographie zu schlechterer Gesamt-Performanz, da für die zusätzliche Ver- und Entschlüsselungs-Algorithmen zusätzlicher Rechenaufwand anfällt. Wenn die Konzelations-Algorithmen auf dem Datenbankserver abgearbeitet werden müssen, ist dies dahingehend problematisch, das relationale Datenbanksysteme schwer über zusätzliche Maschinen zu skalieren sind und so jeglicher zusätzlicher Rechenaufwand pro Client die Concurrency des Datenbanksystems reduziert. Reaktionsfähigkeit Wie in Abbildung 2.2 dargestellt, werden für die Query-Bearbeitung verschiedene Komponenten des Datenbanksystems benötigt. Falls sich der Arbeitsaufwand für beteiligte Komponenten verstärkt, wird sich dadurch die Dauer erhöhen, bis Clients im Besitz der gewünschten Daten sind. Dabei kann die Reaktionsfähigkeit des Gesamtsystems durch dieselbe Funktionserweiterung an verschiedenen Stellen unterschiedlich stark beeinflusst werden. Ob etwa verschlüsselte Daten vom Dateisystem vor der Übergabe an das DBMS oder von diesem unmittelbar danach entschlüsselt werden, macht bezüglich des Rechenaufwands keinen Unterschied. Sofern allerdings Rechen- und Speicherkomponente getrennte Systeme darstellen, bedeutet letzterer Fall, dass damit Rechenkapazität des Datenbankservers verwendet wird und sich dadurch dessen Concurrency verschlechtert. Generell sollte der nötige Rechenaufwand (pro Query) auf Datenbankservern möglichst gering gehalten werden, da relationale Systeme schlecht über multiple Server skalieren. Weswegen der Ansatz die Clients mitarbeiten zu lassen, durchaus zu deren eigenen Vorteil sein kann, wenn damit die Belastung des Servers so stark reduziert wird, dass die Clients ihre Antworten entsprechend früher von diesem 54

55 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN erhalten. Im Falle der Verschlüsselung auf Anwendungsebene erweist sich dies allerdings nicht als Performanz-fördernd. Da dieser Ansatz viele Techniken der Datenbanksysteme so stark einschränkt, dass sich die Antwortdauer des Servers dadurch stattdessen erhöht. Die Antwortdauer des Servers steigt natürlich auch, wenn das Einlesen der Pages durch erhöhte Latenz oder verringerte Bandbreite des Dateisystems verlangsamt werden, etwa bei Einsatz eines separaten Storage-Servers. Transparenz Bezieht sich auf das Hinzufügen neuer Fähigkeiten in existierende Systeme und gibt an, welcher Aufwand für das Einbinden dieser Konzepte betrieben werden muss. Für diese Arbeit stellt sich die Frage nach der Transparenz, insbesondere in Bezug auf Sicherheitserweiterungen. erweiterte Funktionalitäten des DBS, wie Trigger, Funktionen, Prozeduren etc. Dies stellt einen besonderen Unterpunkt der Transparenz dar. Solche Funktionalitäten weisen alle heute üblichen Datenbanksysteme auf. Sie dienen vor allem dazu, die zu übertragende Datenmenge zu reduzieren, indem direkt auf dem Datenbankserver mit den Daten gearbeitet wird. Das Fehlen oder Ausfallen solcher Funktionen erhöht damit die Bearbeitungsdauer und notwendige Anwendungslogik. LockIn Werden Funktionalitäten durch die Nutzung von Komponenten anderer Anbieter erledigt, besteht die Gefahr, sich von diesen abhängig zu machen. Bei intensiver Nutzung werden eigene Vorgänge und Komponenten immer stärker darauf ausgerichtet, so dass die Kosten für eine Ersetzung dieser Komponenten eben einen solchen Wechsel immer unattraktiver machen und so zu einer Bindung an den Anbieter führen. Diese Abhängigkeiten können somit zu Opportunitätskosten führen und sollten deswegen vermieden werden, etwa durch die Nutzung standardisierter Schnittstellen, damit eingebundene Komponenten problemlos getauscht werden können. 55

56 KAPITEL 3 - ANALYSE 3.6 ANFORDERUNGSANALYSE Abschließend soll aus der Aufgabenstellung und den bisherigen Kapiteln eine Liste der Anforderungen an den zu erstellenden Prototypen abgeleitet werden. FD Datenbanksystemen soll eine einfache Dateisystem-Schnittstelle geboten werden, um diesen das Halten des Datenbestands in der Cloud zu ermöglichen. FU Diese Dateisystem-Schnittstelle soll universell sein, um ein breites Feld an Datenbanksoftware abzudecken. FF Das System soll weiterhin das Laden und Speichern beliebiger Dateien ermöglichen. FV Alle Datei-Modifikation sollen direkt in der Cloud vorgenommen werden. FS Das System soll übliche Dateisystemfunktionalität bieten. FL Die Latenz des Systems soll möglichst gering sein, um die Performanz der aufsetzenden Systeme zu erhalten. FM Das System soll multiple parallel nutzbare Zugriffspunkte bieten, so dass für verschiedene Anwender oder Anwendungsfälle separate Konfigurationen genutzt werden können. FN Das System soll gegenüber diesem parallelen Nutzer-Betrieb skalieren können. FC Daten, die den eigenen Vertrauensbereich verlassen, müssen ausreichend vor unberechtigten Zugriffen geschützt sein. FA Die lokale Verfügbarkeit der Cloud-Daten muss gewährleistet sein, dafür soll insbesondere nicht die Architektur einzelner Cloud-Anbieter als Grundlage dienen. FI Verletzungen der Daten-Integrität müssen erkannt und behoben werden können. FK Relevante Eigenschaften des Systems sollen konfigurierbar sein. FW Die Administration des Proxys soll einfach und grafisch über ein Web-Management möglich sein. Eine Darstellung der Anwendungsfälle des Proxys ist in der Abbildung 3.11 zu finden. 56

57 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN Abbildung 3.11: Anwendungsfälle des Proxys 57

58

59 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN 4 SYSTEMENTWURF Auf Grundlage der Analyse im vorherigen Kapitel sowie den Erkenntnissen der Vorarbeit (Ronny Seiger 2011) soll in diesem Kapitel ein vollständiges Konzept zur sicheren Nutzung von Cloudspeicher als Datenbankspeicher entwickelt werden, welches auch die Nebenbedingungen aus der Anforderungsanalyse erfüllt. Zunächst wird ein kurzer Abriss über die prinzipielle Funktionsweise des notwendigen Systems gegeben. Dann folgt eine schrittweise Spezifizierung und Erweiterung, um die einzelnen Anforderungen zu erfüllen. 4.1 PROXY-ARCHITEKTUR Da auf der einen Seite für Datenbanksysteme eine vertraute Dateisystemsicht geboten und auf der anderen Seite deren Daten in der Cloud gespeichert werden sollen, scheint es sinnvoll einen Proxy mit diesen beiden entsprechenden Schnittstellen zwischen DBMS und Cloud-Storage zu setzen. Mittels dieser Architektur können dann auch erweiterte und komplexere Fähigkeiten an einer zentralen Stelle integriert werden; um so etwa die Sicherheit der Daten in der Cloud sicherzustellen oder ein sinnvolles Verhalten bezüglich der zu Abbildung 4.1: System-Entwurf nach Abbildung

60 KAPITEL 4 - SYSTEMENTWURF erwartenden hohen Latenzen durch den Netztransfer zu erreichen. Somit ist das grundlegende Designprinzip der Vorarbeit auch für die Anforderungen dieser Arbeit geeignet und kann daher beibehalten werden. Abbildung 4.1 greift das 2-Komponenten-Modell aus dem Analyse-Kapitel auf, wobei anstelle des abstrakten virtuellen Datenspeichers ein Proxy als Vermittler zwischen DBMS und Speicher gesetzt ist. Abbildung 4.2: Proxy-Sichtweise des System-Entwurfs Wie bereits angemerkt, erfolgt nun pro kommendem Unterpunkt eine Spezifizierung oder Erweiterung des Konzepts um einzelne Komponenten. Dabei wird jeweils vorgestellt, wofür diese benötigt und genutzt werden können und was bei deren Implementierung zu beachten ist. Ein erster Entwurf aus Sicht des Proxys ist in Abbildung 4.2 dargestellt, inklusive der Schnittstellen zu Datenbanksoftware und externem Speicher Performanz SCHNITTSTELLE DATENBANKSERVER Es ist nicht sinnvoll jeweils den gesamten Datenbestand eines Datenbanksystems aus der Cloud zu ziehen, wenn dieses gestartet wird. Dann müsste lokal entsprechend viel Speicherplatz vorgehalten werden und der Cloudspeicher wäre nicht mehr als ein BackupSpeicher. Auch die einzelnen Dateien der Datenbanken können Gigabytes und mehr umfassen. Alleine die Latenz eine solche Datei als Ganzes je nach Anforderung in die oder aus der Cloud zu laden, würde zu einem äußerst trägen System führen. Genau aus diesem Grund kommunizieren Datenbanksysteme auch nicht datei-weise mit dem Dateisystem. Wie bereits vorher aufgezeigt, werden die Dateien nur als Container 60

61 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN genutzt, innerhalb derer ein page-weiser Datenaustausch stattfindet. Der Proxy soll von daher die einzelnen Dateien intern ebenfalls als eine Ansammlung separater Speicherbereiche behandeln und seine internen Operationen auf diese ausrichten, um trotz variabler Dateigröße mit bekannten und planbaren Datenmengen hantieren zu können. Wenn das DBMS mit dem Proxy seine Pages austauscht, kann dieser so wiederum intern beschränkt auf seinen betroffenen Blöcken arbeiten. Siehe Abbildung 4.3 für eine Gegenüberstellung der verschiedenen Sichtweisen der beteiligten Systeme auf die selben Dateien. In Anlehnung an physikalische Permanentspeicher werden diese Speicherbereiche fortan als Blöcke bezeichnet. Abbildung 4.3: Sichtweise von DBMS und Proxy auf die virtuellen Dateien an der Dateisystem-Schnittstelle Am performantesten wäre es mit genau diesen Pages zu arbeiten und sich somit möglichst an den Bedürfnissen des Datenbanksystems auszurichten. So könnten zum Beispiel leichter Alignment-Probleme und damit unnötiger Rechenaufwand und Datenaustausch mit den Cloudspeichern verhindert werden (vergleiche Abbildung 4.3 linke und rechte Datei). Allerdings können DBMS das Dateisystem nicht explizit mit entsprechenden Informationen versorgen, da die Dateisystemschnittstelle historisch nicht auf eine solche Aufgabe ausgelegt wurde. Dateisysteme können allerdings Nutzer über die von ihnen bevorzugte Arbeitsgröße informieren ihre Block Size. Der Beginn von Dateien wird dabei immer an einen Blockanfang gelegt und jeder begonnene Block komplett der entsprechenden Datei zur Verfügung gestellt, so dass die Byteposition innerhalb einer Datei immer klarstellt, an welcher Stelle eines Blockes sich diese befindet. Die Blocksystematik wird dieser Arbeit ebenfalls zugrunde gelegt. Es bleibt damit wie bisher Aufgabe des DBMS sich nach dem Speicher zu richten und die Pages möglichst effizient auf dessen Blöcken auszurichten. Da es im Gegensatz zu Magnetplatten allerdings keinen physikalisch-technischen Grund für eine 61

62 KAPITEL 4 - SYSTEMENTWURF bestimmte Blockgröße des Proxys gibt, soll dieser frei gewählt werden können, um so Datenbanksystemen und anderen Anwendungen entgegen zu kommen. Bis hierher war allerdings nur die Arbeitsweise in Bezug auf Datenbanksystem von Relevanz; da der Proxy aber möglichst nicht seine bisherige Fähigkeit verlieren soll, generell Dateien in der Cloud ablegen zu können, sei überlegt zu welcher Wirkung eine solche Umstellung in anderen Anwendungsszenarien führt. Wenn etwa ein Textverarbeitungsprogramm ein Dokument lädt, muss der Proxy auch bei einer blockbasierten Arbeitsweise alle Blöcke sofort besorgen, da die gesamte Datei angefordert wird. Beim Abspielen einer Mediendatei laden Programme dagegen nur jeweils eine gewisse Zeitspanne voraus, statt unmittelbar die gesamte Datei. Der Proxy muss so sequentiell und nicht zeitgleich die Blöcke liefern. Da dadurch für die Startanfrage nur einige Blöcke statt der gesamten Datei vom Cloudspeicher geladen werden muss, führt dies zu einer besseren initialen Reaktionszeit gegenüber dem datei-basierten Proxy. Allerdings besteht dafür bei der block-basierten Arbeitsweise die Gefahr, dass es durch das ständig notwendige Laden des nächsten Abschnitts zu einer stockenden Wiedergabe kommt. Insbesondere beim Springen innerhalb der Mediendatei kann es durch die um Dimensionen höherer Latenz des Netzspeichers gegenüber eines lokalen Sekundärspeichers zu auffälligen Verzögerungen kommen. Maßgeblich wäre somit wohl die Fähigkeit des Players oder Proxys entsprechend der festgestellten Latenz vorauszuladen. Blockgröße Performanz Datenbanksysteme verwenden üblicherweise Pages im Umfang von wenigen KB, wobei dies oft in einem Bereich zwischen 512 Byte bis 32 KB konfigurierbar ist. Wie in Building a Database on S3 (Brantner et al. 2008) aufgezeigt, ergibt sich aber nur ein geringer Durchsatz, wenn bei der hohen Netzlatenz jeweils nur sehr kleine Datenpakete angefordert werden. Deswegen wurden in dieser Arbeit Pages von 100 KB genutzt. Dies könnte im eigenen Systementwurf erreicht werden, indem einfach mit entsprechend großen Blöcken gearbeitet wird. Es ist allerdings fraglich, ob so wirklich das erwünschte Ziel erreicht wird. Die Kommunikation mit größeren Datensätzen ist nur dann effizienter, wenn auch mehr Byte aus dem größeren Block verwendet werden, als bei einem kleineren Block worden wären. Wenn nur jeweils ein kleiner Teil der übertragenen Daten tatsächlich genutzt wird, hätte das System mit dem scheinbar höheren Durchsatz einen Pyrrhussieg errungen, da die StorageAnbieter üblicherweise nicht nur den in Anspruch genommenen Gesamtspeicher abrechnen, sondern auch die übertragenen Datenmenge. Allerdings wäre auch ein flexibleres Systeme mit größeren Übertragungspaketen möglich, wenn nicht einfach ein entsprechender sequenzieller Speicherbereich, sondern kleine Blöcke beliebig, aber sinnvoll zu Paketen zusammengefasst würden. So könnten häufig gemeinsam genutzte Blöcke zusammengepackt und damit die Anzahl der Transfers verringert werden 62

63 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN (vergleiche linke und rechte Cloud-Storage-Anfrage in Abbildung 4.4). Algorithmen, welche solche Muster automatisch erkennen können, würden allerdings zusätzlichen Rechen- und Implementationsaufwand erfordern. Abbildung 4.4: Paketierung von Blöcken für die Ablage auf Cloud-Storage Mountpoints Das Ermöglichen separater Mountpoints durch den Proxy soll die Sicherheit bezüglich verschiedener Anwender erhöhen, also für die Mandantenfähigkeit des Systems sorgen; sowie unterschiedliche Konfigurationen für verschiedene Anwendungsfälle gestatten. Der Proxy selbst wird die Verzeichnisse lokal mounten. Um diese über ein Netzwerk zur Verfügung zu stellen, kann eine weitere Technik wie CIFS genutzt werden Vertraulichkeit Performanz BLOCK CACHE Caching Der größte erwartete Performanzverlust des Proxys ist die Transferlatenz zum CloudStorage. Um diesen Effekt zu verringern, soll ein Cache auf dem Proxy genutzt werden, 63 Performanz

64 KAPITEL 4 - SYSTEMENTWURF welcher häufig benötigte Blöcke vorhält, so dass Anfragen nach diesen mit einer niedrigen Latenz beantwortet werden können. Damit der Cache intelligent befüllt werden kann, muss das System Block-Statistiken führen, die etwa Informationen über die generelle Nachfrage nach den einzelnen Blöcken und deren letzten Zugriff enthalten. Integrität Durability Performanz Integrität Um den tatsächlichen Datenbestand in der Cloud integer zu halten, soll der Cache mit einem Write-Trough-Mechanismus genutzt werden, also Modifikation trotzdem unmittelbar auf die Cloudspeicher übertragen werden. Eine positive Rückmeldung des Proxys an den Client soll dabei erst nach der Sicherung der Daten stattfinden. Dies verhindert bei der prototypischen Implementation, dass durch Systemfehler des Proxys erfolgreich gemeldete Aktualisierungen doch noch verloren gehen. In einem ausreichend geprüften Produktivsystem könnte durch asynchrone Speicherung der Daten dagegen eine verringerte Latenz gegenüber den Proxy-Nutzern erreicht und bei häufig modifizierten Blöcken Bandbreite eingespart werden. Auch gegen die Problematik der Eventual Consistency kann der Cache eingesetzt werden. Indem alle in die Cloud zu schreibenden Blöcke in den Cache gelegt werden, können kurz darauffolgende, passende Leseanfragen direkt beantwortet werden, so dass auch eine erhöhte Replikationslatenz der Storage-Provider keinen Einfluss auf die Arbeit des Proxys hat. Prefetching Performanz Neben dem Halten häufig genutzter Daten, wäre auch das Vorausladen noch nicht im Cache befindlicher, aber bald benötigter Blöcke der Latenzverringerung förderlich. Übliche Datenbanksysteme besitzen bereits Prefetching-Techniken. Wenn etwa für eine Query über eine Relation kein Index-Scan möglich ist, muss dementsprechend ein Table-Scan ausgeführt werden. Das bedeutet, jedes einzelne Tupel der Relation wird mit der Query-Bedingung abgeglichen. Deswegen lädt das Datenbanksystem nicht nur das gerade benötigte Tupel, sondern kann die folgenden Tupel antizipieren und fordert diese bereits im Voraus an. Diese Zusammenhänge zu erkennen ist für das System unkompliziert, da es die Daten selbst strukturiert. Im Falle von Datenbanksystemen kann der Proxy ein sinnvolles Prefetching also realisieren, indem er einfach die entsprechenden Anfragen des DBMS erfüllt. Da sich das nicht von der generellen Beantwortung von Leseanfragen unterscheidet, ist dafür keine erweiterte Implementation notwendig. Einem entsprechenden Algorithmus könnten die Anforderungsmuster eines nicht prefetchenden Systems ebenfalls ersichtlich werden. Zu den zusätzlichen Rechenressourcen, welche eine Mustererkennung und Vorhersage benötigt, kommt natürlich auch der erhöhte Implementierungsaufwand. Aus diesen Gründen und der geringen Relevanz im Falle von Datenbanksystemen wird dieser Punkt außen vor gelassen. Weitergehende Überlegung für die Vorhersage der Nutzung ganzer Dateien sind etwa in (Gibson, Smith, et Miller 1999) zu finden. 64

65 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN VERFÜGBARKEITS-KOMPONENTE Um die Verfügbarkeit der Daten sicherzustellen, soll deren Abhängigkeit von einem einzelnen Speicher gelöst werden. Im ersten Unterpunkt wird untersucht, inwieweit der Proxy dies softwaremäßig erreichen kann. Information Dispersal Algorithmen (IDA) IDAs gehen auf das Shamir's Secret Sharing (Shamir 1979) von Adi Shamir zurück. Der Algorithmus ermöglicht es ein Geheimnis auf mehrere Entitäten zu verteilen, ohne das im späteren alle Instanzen benötigt werden, um es zu rekonstruieren. Da erst ab einer vorher gewählten Anzahl an Teilen das Geheimnis wiederherstellbar ist, mit wenigern dies aber auch teilweise nicht gelingt, wird das Verfahren auch Schwellwertschema genannt. Kombiniert mit Wissen aus der Informations- und Kodierungstheorie wurden daraus die IDAs entwickelt (Rabin 1989). In der Kanalkodierung wird die Kodierungstheorie verwendet, um die zu übertragenden Daten so mit Redundanz zu erweitern, dass diese auch bei Störung des Übertragungskanals erfolgreich empfangen werden können. Ähnlich wurde hier ein System entwickelt, dass aus einer unvollständigen Nachricht die ursprünglichen Informationen rekonstruieren kann. Dabei wird der ursprüngliche Datensatz in k Elemente zerlegt und um m weitere Elemente berechneter Redundanz erweitert. Sowohl k als auch m können dabei, abhängig vom tatsächlich verwendeten Dispersion-Algorithmus, relativ frei gewählt werden. Um den Original-Datensatz zurückrechnen zu können, werden nur beliebige k der k + m Elemente benötigt. Die einzelnen durch die Dispersion entstandenen Elemente werden fortan als Fragmente bezeichnet. Durch das Hinzufügen von Redundanz sind mit Dispersal Algorithmen Informationen also auch dann noch bis zu einer gewählten Grenze korrekt rekonstruierbar, wenn nicht alle Fragmente wiedererlangt werden können. Durch Verteilung der Fragmente ist es also möglich, die Verfügbarkeit der enthalten Daten zu erhöhen - ähnlich einer einfachen Replikation der Daten. Je nachdem wie viel Redundanz hinzugefügt wird, kann damit die potentielle Verfügbarkeit gesteuert werden. Natürlich ist dies auch mit Nachteilen verbunden. Mehr Redundanz bedeutet, dass die Datenmenge erhöht wird. Die Informationen benötigen also sowohl mehr Speicherplatz, als auch längere Übertragungsdauern sowie mehr Zeit bei ihrer Verarbeitung. Bei Anwendung von Konzelationssystemen kommt es etwa zu längeren Verschlüsselungs- und Entschlüsselungszeiten. 65 Verfügbarkeit Performanz

66 KAPITEL 4 - SYSTEMENTWURF Daten-Verteilung über multiple Storage-Anbieter Verfügbarkeit Dispersion ermöglicht softwarebasiert nur eine potentielle Erhöhung der Verfügbarkeit. Allerdings muss dieser potentielle Vorteil physikalisch auch genutzt werden. Es ist also absolut notwendig die einzelnen Fragmente über verschiedene Permanentspeicher-Systeme zu verteilen, damit bei technischem Defekten eines einzelnen Systems nicht bereits die Wiederherstellung des in den Fragmenten enthaltenen Datensatzes unmöglich gemacht wird. Außerdem sollten die verschiedenen Storage-Server von verschiedenen Anbietern gestellt werden, um die Auswirkungen organisatorischer Probleme möglichst gering zu halten (MU 2012). Die Dispersion wird also durch die Disperser-Komponente ermöglicht, muss aber an der Proxy-Schnittstelle zu den Storage-Anbietern auch beachtet werden. Cloud-Storage-Replikation Verfügbarkeit Wie bereits im Analyse-Kapitel aufgezeigt, ist eines der wichtigsten Argumente von StorageProvidern, der Schutz der Kundendaten vor Verlust durch Redundanz. Auch wenn diese Eigenschaft keine Notwendigkeit des eigenen Verfügbarkeitskonzepts sein soll, wirkt die Nutzung solcher Anbieter unterstützend. Durch die hohe Verfügbarkeit von Cloud-Storage sinkt bei Verteilung über diese Hochverfügbarkeitssysteme die Wahrscheinlichkeit, dass zu viele Fragmente gleichzeitig nicht erreichbar sind INTEGRITÄTS-KOMPONENTE Um die Integrität von Daten zu testen, werden Prüfsummenverfahren eingesetzt. Dies sind Funktionen, welche die Bitfolge einer Datei auf eine wesentlich kürzere Bitfolge abbilden. Dabei sind diese so konstruiert, dass minimale Änderungen des Eingabewerts zur Veränderung des Ausgabewertes führen. Wenn also beim Wiedereinlesen der Datei auch nur ein Bit verändert ist, kann dies an der veränderten Prüfsumme erkannt werden. Sollen Daten außerhalb des eigenen Vertrauensbereichs gespeichert werden, können solche Prüfsummen für die Dateien erstellt und im eigenen Vertrauensbereich belassen werden. Beim Wiedereinladen der Daten können diese so auf Veränderungen getestet werden, indem erneut die Abbildungen nach dem selben Verfahren gebildet und mit den gespeicherten Prüfsummen abgeglichen werden. 66

67 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN In diesem Entwurf sollen Prüfsummen für die einzelnen Fragmente gebildet und gespeichert werden. Die Fragmente können so nach dem Wiedereinladen von ihren Speichern auf Modifikationen getestet werden, so dass nur integere Fragmente zur Rekonstruktion ihres Blockes genutzt werden. Dabei sollen die Prüfsummen für alle Fragmente erstellt werden, nicht nur für die auf nicht vertrauenswürdigen Storage-Servern abgelegten. Auch wenn die im eigenen Vertrauensbereich abgelegten Daten vor böswilligen Veränderungen geschützt sein sollten, können so trotzdem Veränderungen durch technische Probleme entdeckt werden. Die Prüfsummen sollen weiterhin vor einer Verschlüsselung der Fragmente erstellt werden, so dass die Cloud-Form der Fragmente sich von deren Hash-Form unterscheidet. Bei einem zu schwachen Hash-Verfahren, könnten Angreifer sonst dem Proxy durch Kollision nichtintegere Fragmente als integere unterschieben, welcher daraus inkorrekte Blöcke rekonstruieren würde. Durch die Verschlüsselung kann ein Angreifer weder die eigentliche Prüfsumme berechnen, noch welche verschlüsselten Bitfolgen entschlüsselt darauf abbilden. So kann intern ein simpleres Verfahren mit kürzeren Prüfsummen genutzt werden, was weniger rechenintensiv ist und weniger Hash-Speicherplatz benötigt. Auch bezüglich der Eventual Consistency können diese Hashwerte genutzt werden. Da lokal jeweils der aktuelle Hash des Fragments gespeichert ist, werden alte Versionen des Fragments wegen ihrer Nicht-Integrität aussortiert und beeinflussen so nicht die Blockbildung. Solange genügend integere Fragmente für den Disperser aus der Cloud geladen wurden, muss dementsprechend auch nicht erneut versucht werden, die aktuelle Version des Fragments zu laden, was die Latenz bezüglich Eventual Consistency eliminiert Integrität Integrität Performanz Integrität VERTRAULICHKEITS-KOMPONENTE Vertraulichkeit der Daten auf dem Cloudspeicher Da die Daten vom selben System wieder entschlüsselt werden sollen, welches sie verschlüsselt hat, ist kein Schlüsselaustausch notwendig. Es genügt also ein symmetrisches Konzelationssystem, dessen verwendete Schlüssel lokal gespeichert werden. Für die Verschlüsselung soll eine Blockchiffre / Stromchiffre über die einzelnen Fragmente verwendet werden. Eine Stromchiffre über alle Fragmente eines Blockes würde die Verfügbarkeit gefährden, falls nicht alle Fragmente geladen werden können. Eine Stromchiffre über Fragmente aller Blöcke würde das Laden nicht benötigter Blöcke erfordern 67 Vertraulichkeit

68 KAPITEL 4 - SYSTEMENTWURF - je nach Ausprägung des Systems - bis zum Einladen der gesamten Datei. Um dennoch bei gleichem Klartext nicht immer den selben Schlüsseltext zu erhalten, sollen für die Fragmente Salts oder individuelle Schlüssel verwendet werden. Vertraulichkeit bei der Kommunikation mit dem Cloudspeicher Es ist keine zusätzliche Verbindungsverschlüsselung für die Kommunikation mit den Speicher-Servern notwendig, da die ausgetauschten Daten bereits vor dem Verlassen des Vertrauensbereiches verschlüsselt sein werden - also eine Ende-zu-Ende-Verschlüsselung stattfindet. Vertrauensbereich / Zugangs- / Zugriffskontrollen Vertraulichkeit Damit die Vertraulichkeit der Daten gewährleistet werden kann, müssen alle Systeme auf denen die zu sichernden Daten auch nur temporär in einem unverschlüsselten Zustand existieren, zum eigenen Vertrauensbereich gehören. Ohne Frage gehört auch das entworfene Proxy-System in diesen Transparenz SCHNITTSTELLE SPEICHERSERVER Wie bereits dargestellt, werden zum Zwecke der Verfügbarkeit die in die Cloud zu ladenden Objekte vom Proxy in Fragmente zerlegt. Diese Fragmente sollen dann über mehrere Anbieter verteilt werden, um die Abhängigkeit von einem einzelnen Anbieter und dessen Infrastruktur und somit Verfügbarkeitsprobleme zu verhindern. Da die verschiedenen Anbieter allerdings unterschiedliche Schnittstellen und Protokolle nutzen, muss an dieser Stelle eine Funktion implementiert werden, welche dieses heterogene Umfeld nach innen homogen abbildet, damit sich die internen Proxy-Funktionen nicht um diese Problematik kümmern müssen. So ein Adapter wurde bereits in der Vorarbeit entwickelt und soll hier weiterverwendet werden. Dabei wird er auch weiterhin in einer datei-basierten Arbeitsweise verwendet, indem die einzelnen Fragmente an dieser Stelle wie Dateien ausgetauscht werden. Eine physische block-basierte Speichereinbindung des Cloud-Storage wird nur von wenigen Providern angeboten (Ronny Seiger 2011) und erscheint auch nicht sinnvoll, da die 68

69 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN Fragmentierung und Blockbildung durch Dispersion und Konzelation sowieso ein einfaches Durchreichen der lokalen Anfrage verhindern. Es sei angemerkt, dass auch lokale Speicher des Proxys oder aus dem Intranet eingebunden werden können. Da dieser Speicherplatz im eigenen Vertrauensbereich liegt, kann auf die Verschlüsselung der dort abgelegten Fragmente verzichtet werden. Scheduler Der einfachste und auch bisher verwendete Algorithmus um die Verteilung der Fragmente über die Cloud-Storages zu entscheiden, ist das Round-Robin-Verfahren. Dieses kommt ohne detailiertes Wissen über die möglichen Optionen aus. Komplexere, aber potentiell effizientere Algorithmen können verwendet werden, wenn Informationen über die verschiedenen Speicher zur Verfügung stehen. Wenn etwa Daten über das Transfer-Verhalten der Cloud-Anbieter gesammelt werden, kann der Scheduler sie nutzen, um die Schutzziele Verfügbarkeit und Integrität zu unterstützen. So können zum Beispiel Anbieter, welche häufiger Fragmente nicht oder fehlerhaft liefern mit einer niedrigeren Priorität bei der Zuweisung künftiger Fragmente bedacht werden. Auch die Reaktionszeit des Systems kann so verbessert werden, wenn die Gewichtung der Anbieter entsprechend ihrer statistischen Latenz und ihres Durchsatzes erfolgt. Abbildung 4.5: Proxy-Systementwurf 69 Verfügbarkeit Integrität Performanz

70 KAPITEL 4 - SYSTEMENTWURF In Abbildung 4.5 ist der gesamte Systementwurf mit den bisher vorgestellten Funktionalitäten grafisch dargestellt. 4.2 VERWALTUNG DER META-DATEN Neben den Meta-Daten, welche die DBMS-Schnittstelle über die in der Cloud liegenden Dateien benötigt, um lokal die erschaffene Ordner- und Dateistruktur simulieren zu können, ist es auch notwendig Informationen über die weiteren Module des Proxys sowie deren Aktionen zu speichern, um etwa Verschlüsselungen und Dispersionen wieder rückgängig machen oder die einzelnen Fragmente überhaupt in der Cloud lokalisieren und den entsprechenden Blöcken zuordnen zu können. Dies reduziert offensichtlich die effektive lokale Speicherplatzeinsparung, so dass überlegt werden sollte, ob diese Meta-Daten ebenso in der Cloud gespeichert werden könnten. Allerdings befinden sich darunter viele sensible Daten, etwa die Dateinamen, CloudAdressen sowie natürlich Kryptographieschlüssel und Dispersionsparameter logischerweise alle Informationen um den kompletten Datenbestand wiederherstellen zu können. Diese Daten müssten also wiederum selbst geschützt werden. Etwas unsicher, aber möglich wäre es, alles mit dem selben Schlüssel zu verschlüsseln - dann müsste nur dieser, eine URL als Einstiegspunkt zu den Meta-Daten sowie die dafür notwendigen LoginInformationen lokal gespeichert werden. Die Meta-Daten wären bei diesem simplen Konzept dann aber weniger geschützt, als die Daten selbst. Weiterhin müssten auch Integrität und Verfügbarkeit der Meta-Daten sichergestellt werden, wenn der Proxy auch garantiert arbeitsfähig bleiben soll. Für die Integrität der Meta-Daten ist dann auch erneut die Problematik der Eventual Consistency zu beachten. Performanz Auch würde natürlich die Reaktionsfähigkeit des Proxys und damit seiner Clients weiter verschlechtert. So kommen zusätzlicher Kryptographieaufwand für die Meta-Daten hinzu, sowie weitere Netzlatenz, welche sich im Gegensatz zu den eigentlichen Daten nicht nur auf den Up- und Download der Fragmente beschränkt, sondern bei nahezu allen Aktionen des Proxys auftreten kann (siehe Abbildung 4.6). Im Vorgriff auf das nächste Kapitel sei auch auf die Tabelle 5.1 verwiesen. Diese gibt alle Aufrufe wieder, welche an die DateisystemSchnittstelle gerichtet werden können. Sämtliche Funktionen, welche nach dieser Auflistung SQL-Querys nutzen, sind nicht ohne Meta-Daten und damit potentiell nicht mehr lokal bearbeitbar. 70

71 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN Abbildung 4.6: Komponenten-Abhängigkeit von der Cloud-Meta-Datenbank Um den Prototypen nicht unnötig kompliziert für die Erfüllung der Aufgabenstellung zu machen, wird das Konzept deswegen nur eine lokale Datenbank für die Meta-Informationen umfassen. Von daher gibt es auch kein erweitertes Verfügbarkeitskonzept für die Meta-Daten selbst. Wenn die proxy-eigene Datenbank beschädigt wird, können die Fragmente vielleicht noch manuell wiedergefunden, aber sicher nicht entschlüsselt oder Blöcken und Dateien zugeordnet werden. Allerdings bieten Datenbanksysteme, wie bereits im Analyse-Kapitel vorgestellt, standardmäßig eigene Verfügbarkeits- und Integritäts-Funktionalitäten, zum Beispiel das Erstellen von Backups oder auch Replikation, welche auch von den ProxyAdministratoren genutzt werden können. Concurrency Neben der zentralen Funktionalität von Datenbanken Daten zu verwalten, ist eine der relevantesten Fähigkeiten Clients nebenläufig auf diesem Datenbestand arbeiten lassen zu können. Während paralleles Lesen nur durch die zur Verfügung stehenden technischen Ressourcen wie Rechenkapazität und Bandbreite begrenzt wird, ergibt sich bei der Modifikation von Daten bei parallel schreibenden und lesenden Clients ein logisches Problem. Wenn diese sich nicht koordinieren oder koordiniert werden, können Änderungen ohne Berücksichtigung wieder überschrieben werden, oder temporäre Daten von lesenden Clients fälschlicherweise erlangt werden. Damit wäre also die Konsistenz des Datenbestands gefährdet - eine zentrale Garantie relationaler Datenbanksysteme. Diese verwenden deswegen Locks, um Datenbankobjekte für den einzelnen Client zu isolieren und soweit wie notwendig eine sequentielle Abarbeitung der Anfragen durchzuführen. Klassische relationale Datenbanksysteme profitieren daher auch nur beschränkt von horizontaler Aufrüstung - eine der wichtigsten Eigenschaften der Cloud. Professionelle Systeme etwa bieten die Möglichkeit parallel mehrere Instanzen auf verschiedenen Rechnern zu einem identischen Datenbestand laufen zu lassen. Damit die Daten über die Systeme hinweg aber konsistent bleiben, müssen dementsprechend nicht nur die Clients eines Systems koordiniert werden, sondern die Clients aller Systeme. Aufgrund dieser 71

72 KAPITEL 4 - SYSTEMENTWURF Komplexität unterstützt heutige Datenbanksoftware oft nur einen Knoten mit Schreibrecht neben einigen Leseknoten. Aber auch die Anzahl letzterer wird beschränkt, da deren Synchronisation die Schreibvorgänge jeweils weiter verzögert. Der aktuelle SQL Server 2012 von Microsoft etwa gestattet zu einem einzelnen Schreibknoten nur zwei synchrone Leseknoten (LeRoy Tuttle, Jr 2012). Für die zwei weiteren möglichen, asynchronen Leseknoten kann keine strikte Konsistenz zum Primärknoten garantiert werden, weswegen sie nur zum Erstellen von Backups und ähnlichen Verwaltungsaufgaben verwendet werden dürfen. Auch der Proxy-Entwurf kann natürlich innerhalb eines Verbunds synchronisierender Datenbanksysteme genutzt werden. Die einzelnen Systeme würden schließlich jeweils einen separaten Proxy als Cloudspeicher-Zugang für ihren jeweiligen Datenbestand nutzen (siehe linkes System in Abbildung 4.7). Abbildung 4.7: Concurrency auf Datenbank- und Speicherebene Neben der Concurrency auf Datenbankebene existiert diese auch auf Speicherebene. Das im Analyse-Kapitel vorgestellte Speicherkonzept erreicht seine hohe Nebenläufigkeit dann auch aufgrund der hohen Skalierbarkeit des S3-Speichers. Wie andere BASE-Systeme garantiert dieses Konzept allerdings keine strikte Konsistenz mehr. Möchte man mehrere Clients auf dem selben Datenbestand arbeiten lassen, müsste der Proxy-Entwurf um entsprechende Konsistenz-erhaltende Mechanismen erweitert werden, etwa Lock-Technik wie in Datenbanksystemen. Dabei ist aber zu beachten, dass dennoch unerwünschte Effekte eintreten werden, solange die nutzenden Systeme sich über dieses Vorgehen nicht bewusst sind. Wenn das DBMS davon ausgeht, dass es alleinig auf dem Datenbestand arbeitet, prüft es nicht auf 72

73 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN Änderungen der Tupel auf dem Sekundärspeicher, sondern verwendet einfach eventuell im lokalen Puffer befindliche Version. Für die Nutzung des Proxys als einfache Datenablage könnte diese Concurrency-Ebene durchaus verwendet werden. Solange keine komplexeren Mechanismen implementiert werden, sollte allerdings ein sehr striktes Locking erfolgen, so dass über mehrere Proxy, genauso wie über einen einzelnen, stets nur ein Client das Schreibrecht für eine Datei besitzt. Damit lässt sich aber trotzdem kein System von Datenbank-Leseknoten betreiben, da sie aufgrund ihrer Puffertechnik erneut veralterte Tupel verwenden könnten. Da die relationalen ACID-Systeme das übliche Datenbankformat im Firmenumfeld sind und ein System mit strikter Konsistenz auch letztendliche Konsistenz einschließt, aber nicht umgekehrt, wird die Nebenläufigkeit der Datenbanksoftware überlassen und keine weitere Concurrency-Ebene durch den Cloudspeicher für Datenbanksysteme zu erreichen versucht. 4.3 ARBEITSWEISE / VERHALTEN DES PROXYS Zum Abschluß des Kapitels wird das Verhalten des aktuellen Proxy-Entwurfs in verschiedenen Situationen dargelegt. Dabei wird zunächst auf Lese und Schreib-Anfragen von Datenbanksystem eingegangen, bevor Überlegungen bezüglich der allgemeinen Arbeitsweise angestellt werden LESEANFRAGEN AN PROXY DURCH DATENBANKSYSTEM Es ergibt sich folgende Aktivitätsfolge (siehe Abbildung 4.8) eines Datenbanksystems in Zusammenarbeit mit dem Proxy bei einer rein lesenden Anfrage an den Datenbankserver. Wenn als Speicherort für die Datenbank eines der Proxy-Verzeichnisse gewählt wurde, passiert bei einer nicht-modifizierenden Query-Anfrage an den Datenbankserver Folgendes: Das DBMS identifiziert zunächst einmal die betroffenen Tupel. Entweder kann das mit Hilfe von Index-Strukturen erledigt werden oder es müssen dafür die eigentlichen Relationen herangezogen werden, um einen individuellen Abgleich jeden Tupels vorzunehmen. Die Anfrage nach den benötigten Tupeln wird dann von der Execution Engine an den Record / Index Manager weitergereicht, welche die betroffenen Pages identifiziert und vom Page Manager anfordert. Dieser befriedigt die Anfrage soweit wie möglich aus seinem Puffer und fordert nur die Speicherbereiche der Datenbank-Dateien mit den nicht im Puffer befindlichen Pages vom Dateisystem / Proxy an. 73

74 KAPITEL 4 - SYSTEMENTWURF Der Proxy muss durch die eigene Meta-Datenbank die dafür notwendigen Blöcke identifizieren. Entweder kann er die Anfrage anhand der gecachten Blöcke bedienen oder er muss aus den Blöcken folgernd die entsprechenden in der Cloud liegenden Block-Fragmente identifizieren und diese über den Protokoll-Adapter von den verschiedenen Anbietern laden lassen. Die einzelnen Fragmente werden dann, falls verschlüsselt, entsprechend der MetaInformation über ihre Konzelation wieder entschlüsselt. Anschließend werden sie einer Integritäts-Kontrolle unterzogen, indem die erhaltenen Fragmente mit dem vor dem Upload erzeugten Prüfsummen abgeglichen werden. Die integeren Fragmente werden dann vom Disperser wieder zu ihren Blöcken vereint. Danach wird der Cache um diese Blöcke erweitert, wofür unter Umständen existierende Blöcke entfernt werden müssen. Abschließend wird vom Proxy die eigentliche Anfrage des DBMS / Page-Managers erfüllt. Wenn wiederum die Execution Engine alle benötigten Tupel erhalten hat, kann die Datenbankanfrage über ihnen ausgeführt werden. Das Ergebnis wird dann an den Datenbank-Client ausgeliefert. Abbildung 4.8: Aktivitäts-Diagramm des Gesamtsystems für eine DQL-Query SCHREIBANFRAGEN AN PROXY DURCH DATENBANKSYSTEM Im Fall einer modifizierenden Anfrage umschließt die schreibende Aktivitätsfolge (siehe Abbildung 4.9) normalerweise eine lesende, da üblicherweise bereits existierende Pages für die Modifikationen geladen werden müssen. 74

75 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN Abbildung 4.9: Aktivitäts-Diagramm des Gesamtsystems für eine DML-Query Wenn als Speicherort für die Datenbank eines der Proxy-Verzeichnisse gewählt wurde, passiert bei einer modifizierenden Query-Anfrage an den Datenbankserver Folgendes: Falls eine Aktualisierung existierender Tupel vorgenommen werden soll, müssen diese wie im vorherigen Abschnitt beschrieben, zunächst einmal der Execution Engine zur Verfügung gestellt werden. Nachdem diese die Tupel erhalten hat, werden schließlich die gewünschten Änderungen vollzogen. Die modifizierten sowie komplett neue Tupel werden dann wieder dem Record-Manager übergeben. Dieser muss die Tupel entsprechend der verwendeten Systematik auf Pages verteilen. Wenn dafür existierende Pages modifiziert werden müssen, sind diese durch den Page-Manager zu besorgen. Nachdem der Record-Manager wiederum seine Aktualisierungen vorgenommen hat, übergibt er die modifizierten und neuen Pages dem Page-Manager. Der Page-Manager lässt die Pages schließlich vom Dateisystem festschreiben, indem er diesem mitteilt, in welche Speicherbereiche der Datenbank-Dateien die Page-Daten geschrieben werden sollen. Der Proxy wiederum legt eine Kopie der modifizierten Blöcke in den Cache. Dann werden die Blöcke dem Disperser übergeben, welcher sie entsprechend der gewählten Parameter zerlegt. Für die daraus entstandenen Fragmente werden erst einmal deren Prüfsummen bestimmt. Abhängig von der Vertrauenswürdigkeit ihres Ziel-Storages verschlüsselt das Kryptographie-Modul dann die Fragmente. Die Zuordnung der Fragmente über die zur Verfügung stehenden Anbieter muss demnach vor dem Kryptographie-Modul erfolgen. Abschließend werden die Fragmente auf den für sie gewählten Speicher geschoben. Die Meta-Informationen, welche beim Durchlaufen der einzelnen Proxy-Komponenten anfallen, wie die Hash-Ergebnisse und verwendeten Kryptographie-Schlüssel, werden in der MetaDatenbank abgelegt. 75

76 KAPITEL 4 - SYSTEMENTWURF ALLGEMEINES SCHREIB-VERHALTEN DES PROXYS Auch wenn das Ziel der Arbeit vor allem ist, Datenbankensystemen Speicher zur Verfügung zu stellen, funktioniert der Systementwurf grundsätzlich mit jeder Software, die StandardDateisysteme nutzen kann. Der Vorteil des geringeren Datentransfers, den die block-basierte Arbeitsweise des Proxys gegenüber der vorherigen datei-basierten Version bei lokal beschränkten Änderungen von Dateien bietet, kann allerdings nur durch Software genutzt werden, welche Dateien wie Datenbanksysteme in einzelne Bereiche unterteilt und nur diese dem Dateisystem bei Änderungen übergibt. Der Proxy selbst nutzt keinerlei DeltaDifferenzierung oder Ähnliches, um tatsächliche Veränderungen zu lokalisieren und entsprechend nur diese Bereiche weiter zu verarbeiten. Ein typischer Text-Editor etwa lädt eine zu bearbeitende Datei komplett in den Arbeitsspeicher und übergibt sie aus diesem beim Speichern wieder komplett dem Dateisystem. Selbst wenn zwischen Laden und Speichern kein Byte geändert wurde, übergeben übliche Dateisysteme den Inhalt des erhaltenen Bytebuffers dem Permanentspeicher, welcher damit die ursprünglichen Sektoren der Datei in Ermangelung dieses Wissens identisch überschreibt. Falls das Dateisystem tatsächlich änderungsbezogen arbeiten soll, um etwa unnötigen Upload zu vermeiden, muss es die Modifikationen durch einen Vergleich der neuen Version mit der aktuell gespeicherten lokalisieren. Nur das modifizierende Programm kann ohne expliziten Vergleich die veränderten Bytes bestimmen, indem es diese Informationen beim Abarbeiten der Befehle erfasst. Für einen Vergleich mit den in der Cloud liegenden Dateien müssten diese also vom Proxy auch nach dem Laden und Ausliefern an den anfragenden Client weiterhin komplett aufbewahrt werden. Alternativ könnten auch weitere Meta-Informationen über den Inhalt der in der Cloud liegenden Dateien lokal gehalten werden - etwa ein block-weiser Hash-Wert. Allerdings kann damit nur auf absolute Gleichheit innerhalb dieser festen Abschnitte geprüft werden. Bei dem Austausch vollständiger Dateien zwischen Anwendung und Proxy würde dies aber nur bis zur ersten Byte-Position-Änderung zufriedenstellend funktionieren. Wenn zum Beispiel genau der erste Byte einer Datei entfernt wird, würde trotzdem die gesamte Datei - also alle Blöcke - neu verarbeitet. Da die folgenden Bytes nun um eine Position nach vorn geschoben sind, ändert sich bei einer festen Abbildung von Datei-Speicherbereichen auf die Blöcke deren aller Inhalt. Immer noch nützlich sein kann dies in speziellen Fällen, wie etwa bei großen MultimediaDateien, deren am Dateiende liegende Tags geändert werden oder die vorallokierte Bereiche dafür nutzen, wie MP3s. Auch bei Dateien, denen neue Informationen immer nur an die bisherigen angefügt werden, wie etwa Log-Dateien, werden davon profitieren. 76

77 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN 5 IMPLEMENTATION Zwar hatte die bereits erwähnte Vorarbeit eine stark ähnliche Aufgabe zu lösen, doch verhinderte deren Ausrichtung auf eine datei-basierte Arbeitsweise eine direkte Übernahme von Quellkode. Unter anderem war es notwendig zu berücksichtigen, dass diese blockbasierte Version Teil eines aktiven Systems ist, also immer unmittelbar bei den Arbeiten am Datenbestand einbezogen wird. In der Vorversion wurde auf Anfrage jeweils eine komplette Datei aus der Cloud in einen lokalen Cache geladen und erst wenn alle Arbeiten an der lokalen Version vorgenommen waren, wieder der Cloud übergeben. Die eigentlichen Anfragen an den Datenbestand wurden dagegen vom FUSE-Modul direkt an das Dateisystem des Caches weitergeleitet und demnach komplett lokal vorgenommen. Da so nur relativ selten die Sicherheitskomponenten des Proxys und zwar jeweils für eine ganze und womöglich sehr umfangreiche Datei genutzt wurden, war eine Übergabe der Datei und deren Fragmente von Komponente zu Komponente über den Sekundärspeicher sinnvoll. So war auch die Zeit für die individuelle Initialisierung der Sicherheits-Komponent des Proxys gegenüber der Bearbeitungsdauer der gesamten Datei wenig relevant. Für die KB-großen Blöcke kam dagegen nur ein Durchreichen über den Primärspeicher in Frage. Das und der Umstand, dass ein jeweiliges Initialisieren der Sicherheitskomponenten gegenüber der kurzen Verarbeitungsdauer der kleinen Blöcke ineffizient wäre, führte zur direkten Integration aller notwendigen Komponenten in das FUSE-Modul. Auch die in der Vorarbeit genutzten Java-Bibliotheken wurden deswegen durch C-Varianten ersetzt. 77

78 KAPITEL 5 - IMPLEMENTATION 5.1 PROXY-TECHNIK Die folgende Proxy-Darstellung stellt die Gesamtheit des implementierten Prototypen dar. Auf die dabei verwendeten Techniken und Bibliotheken wird in den jeweiligen Unterpunkten eingegangen. Abbildung 5.1: Proxy-System Der Prototyp in seiner jetzigen Form ist nur unter einem Linux-System lauffähig. Dies liegt vor allem an der Verwendung des im nächsten Punkt erläuterten FUSE-Moduls. Die OpenSSL und Jerasure-Bibliotheken sind auch unter anderen Systemen verfügbar oder kompilierbar, und sowohl der Apache HTTP-Server als auch der MySQL-Server existieren ebenfalls für andere Platformen. Die beiden Server könnten aber generell leicht durch andere SQL- und Web-Server ausgetauscht werden. Der Protokoll-Adapter wiederum wäre etwas aufwendiger zu ersetzen, da er eine Vielzahl verschiedener fertiger Techniken für die unterschiedlichen Protokolle der Cloud-Storages verwendet. Da deren Aufgabe darin liegt, die einzelnen Cloudspeicher in die lokale Verzeichnisstruktur einzubinden, besteht aber keine unmittelbare Notwendigkeit für die zur Zeit genutzten Anwendungen. Somit können auch diese durch beliebige Alternativen ersetzt werden. 78

79 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN DATEISYSTEM (FUSE) Ein Dateisystem (DS) für die DBMS-Schnittstelle zu implementieren stehen gewisse Schwierigkeiten gegenüber. Insbesondere die umfangreiche und komplexe API eines solchen und der Umstand, dass die Dateisystemtreiber im Kernel-Space liegen, erschweren die Implementation und deren Debugging. Um den Implementationsprozess zu beschleunigen, wurde deswegen auf FUSE16 (File System in User Space) zurückgegriffen. Dies ist ein LinuxKernel-Modul und Framework, welches das Erstellen eines Dateisystems vereinfacht. Zum einen bietet FUSE eine unkomplizierte API mit homogener Parameterlogik. Zum anderen erleichtert es Programmieren und Debuggen, indem es den eigentlichen Dateisystem-Treiber im User-Space laufen lässt. Das verhindert, dass bei Fehlern der Kernel und damit das ganze System abstürzen. Auch entfallen viele Einschränkungen, welche für das Programmieren im Kernel-Space gelten (Salzman, Burian, et Pomerantz). Diese so ermöglichte einfache und betriebssichere Implementierung ist daher gut geeignet, um prototypisch die Konzepttauglichkeit zu testen. Wie in Abbildung 5.2 dargestellt, arbeitet FUSE als Vermittler innerhalb des Kernel-Space zwischen dem VFS (Virtual File System) des Linux-Kernels und dem eigentlichen Dateisystem. Das VFS ist eine Abstraktion des Linux-Kernels über den tatsächlichen Dateisystemen, mit welchem die Anwendungen per Systemaufrufen kommunizieren. Abbildung 5.2: Kommunikationsweg zwischen DBMS und Proxy-Dateisystem nach Natürlich gibt es Gründe dafür, dass die verbreitetsten Dateisysteme dennoch direkt für den Kernel geschrieben werden. Am relevantesten dabei ist die Performanz. So sind aus Performanz

80 KAPITEL 5 - IMPLEMENTATION Sicherheitsgründen nicht alle Funktionalitäten des Kernels im User-Space verfügbar. Um diese in Programmen im User-Space nutzen zu können, müssen Systemaufrufe an den Kernel gerichtet werden. Dieser erledigt die Aufgabe dann und gibt entsprechende Ergebnisse zurück. Dabei findet aber jeweils ein Wechsel vom User- in den Kernel-Space und zurück statt, sogenannte Kontextwechsel. Kontextwechsel allerdings sind sehr aufwendig. Umso öfter eine Anwendung diese nutzt, desto stärker sind demnach die Leistungseinbußen gegenüber einem Arbeiten des Programms im Kernel-Space. Im Evaluations-Kapitel gibt es eine quantitative Betrachtung dazu, wie stark die Einbußen im Falle von FUSE sind. FUSE-API / Dateisystem-Funktionalität Die meisten Funktionen der Dateisystem-API dienen dazu Meta-Informationen über Dateien und Dateisystem auszutauschen und benötigen entsprechend nur die Meta-Datenbank für ihre Ausführung. Nur bei den beiden zentralen Funktionen read und write kommt es zu einem tatsächlichen inhaltlichen Datenaustausch. Dies sind dadurch auch die einzigen beiden Funktionen in denen ein Datentransfer mit den Cloudspeichern notwendig wird und die dementsprechend die Sicherheitskomponenten des Proxys nutzen. Da nicht alle Methoden der FUSE-API für ein funktionierendes Dateisystem notwendig sind, wurden die Funktions-Prototypen nur soweit umgesetzt, wie dies für die Ausführbarkeit des Systementwurfs notwendig war. Es folgt eine Übersicht über alle Dateisystem-Funktionen, ihre Bedeutung und ob sie implementiert wurden. Dabei gibt die lokal-spalte an, ob der Aufruf ausschließlich durch lokal verfügbarer Informationen bearbeitet wird; und SQL, ob innerhalb der Funktion die Meta-Datenbank genutzt wird - ohne Berücksichtigung von Debug-Logging. Funktion Funktionalität implementiert lokal SQL main Startpunkt des FUSE-Dateisystems x x x init Aufruf beim Starten des FUSE-Moduls um Initiationsarbeiten vornehmen zu können x x x destroy Aufruf beim Beenden des FUSE-Moduls um Aufräumarbeiten vornehmen zu können x x - statfs gibt Informationen über das Dateisystem zurück x x x chown ändert Datei-Eigentümer x x x chmod ändert Datei-Zugriffsrechte x x x rename ändert Dateipfad x x x utime setzt Modifikation- und Zugriffs-Zeitstempel x x x 80

81 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN Funktion Funktionalität implementiert lokal SQL getattr gibt standardisierten Satz an Informationen über das DS-Objekt zurück x x x fgetattr wie getattr, allerdings für geöffnete (open) Dateien x x x listxattr gibt Liste erweiterter Attribute des DS-Objekts zurück - setxattr setzt den Wert eines erweiterten Attributes - getxattr gibt Wert des erweiterten Attributes zurück - readdir gibt DS-Objekt-Liste des Verzeichnisses zurück x x x opendir gibt Verzeichnis-Handler zurück, wenn möglich und erlaubt - releasedir löst Verzeichnis-Handler wieder auf - mkdir erzeugt ein Verzeichnis x x x rmdir entfernt ein Verzeichnis x x x open gibt Datei-Handler zurück, wenn möglich und erlaubt - release löst Datei-Handler wieder auf - create erzeugt eine Datei x x x truncate ändert die Größe einer Datei x x x ftruncate wie truncate, allerdings für geöffnete (open) Dateien x x x unlink entfernt eine Datei x x x read liest aus einer Datei x - x write schreibt in eine Datei x - x flush fordert das Festschreiben gecachter Daten und wird beim Schließen der Datei automatisch aufgerufen - fsync fordert das Festschreiben gecachter Inhalts- und Meta-Daten - fsyndir fordert das Festschreiben gecachter Meta-Daten - link erzeugt einen harten Link x x x symlink erzeugt einen symbolischen Link - readlink gibt den Original-Pfad hinter einem symbolischen Link zurück - Tabelle 5.1: FUSE-API 81

82 KAPITEL 5 - IMPLEMENTATION Zustandsloses FUSE-Dateisystem Von einigen Funktionen existieren 2 Varianten - manchmal nach dem Prinzip <Funktion> und f<funktion> benannt. Letztere werden mit bereits geöffneten Dateien verwendet, weswegen als ein Parameter die möglicherweise dabei erhaltene Handler-Struktur mit übergeben wird. Neben den weiteren notwendigen Informationen wird aber generell bei jeder Interaktion über DS-Objekte deren absolute Pfadadresse innerhalb des Dateisystems mit angegeben. Somit besteht keine Notwendigkeit tatsächlich intern Handler-Strukturen zu verwalten und damit die Möglichkeit ein zustandsloses FUSE-Dateisystem zu implementieren, welches ohne Session-Verwaltung auskommt - was in dieser FUSEImplementation auch getan wurde. Die Handler-Funktionen der API sind dementsprechend auch nur Stubs, welche auf ihre Nicht-Handler-Version umleiten. Performanz Aufgrund des Verzichts auf internen Meta-Daten-Vorhalt müssen allerdings bei jedem Aufruf erneut alle notwendigen Informationen mittels der Pfadangabe aus der MetaDatenbank extrahiert werden, um die Anfrage bearbeiten zu können. Offensichtlich wäre das Halten einmal erlangter Informationen im Hauptspeicher und das Arbeiten mit diesen wesentlich performanter, insbesondere da so die Anzahl der sehr aufwendigen Anfragen an den MySQL-Server reduziert werden könnten. Der Grund für dieses Vorgehen liegt erneut in dem Versuch die Implementation des Prototypen nicht unnötig zu erschweren. Die Verwaltung der intern gehaltenen Daten, also Caching und asynchrones sichern wäre insbesondere in einer Multithreading-Umgebung sehr aufwendig gewurden. Des Weiteren besteht bei einer nicht-ständigen permanenten Sicherung der Meta-Daten die Gefahr von Verlust elementarer Informationen bei Abstürzen des Prototypen. Bei einem produktiven Einsatz wäre wegen der hohen Aufruffrequenz, insbesondere der read/write-funktionen, allerdings das interne Halten dieser Daten zu empfehlen. Multithreading FUSE selbst kann single- oder multithreaded (Voreinstellung) arbeiten, letzteres bedeutet, dass verschiedene Anfragen an das Dateisystem parallel abgearbeitet werden. Da erwartet wird, dass es aufgrund der internen Konsistenzsysteme des DBMS nicht zu parallelen Schreibzugriffen auf die selben Datei-Speicherbereiche kommt - oder dass, wenn keine solchen existieren, eine entsprechende Absicherung für das Datenbanksystem schlicht nicht von Bedeutung ist - wurden für diesen Prototypen auch keine weiteren Maßnahmen wegen der Multithread-Funktionalität des FUSE-Moduls ergriffen. Performanz Neben dem generellen Multithread-Betrieb des FUSE-Moduls bezüglich verschiedener Anfragen wurde das vorgestellte Konzept um zusätzliche Threading-Funktionalität innerhalb eines FUSE-Aufrufe erweitert. Die einzelnen Anfragen des DBMS an das Dateisystem können jeweils verschiedene Blöcke und diese wiederum mehrere Fragmente 82

83 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN betreffen. Das Zerlegen oder Zusammenfügen, Ver- oder Entschlüsseln, Hoch- oder Herunterladen der Daten kann natürlich simpel iterativ und sequentiell erfolgen. Allerdings ist es effizienter die unabhängigen Teile parallel auszuführen (siehe Abbildung 5.3). Arbeitsschritte wie Konzelation und Dispersion, welche sich hauptsächlich aus Berechnungen zusammensetzen, werden von der Parallelisierung allerdings nur beim Einsatz des Proxys auf einem Mehrkern-System profitieren. Die Download-Ergebnisse von Fragmenten werden dagegen generell verbessert, da die Threads nach DownloadInitialisierung vom System pausiert werden können bis die Antwort vom Storage-Server eintrifft. So können die einzelnen Fragment-Anfragen nahezu parallel abgesetzt und die Latenz des Netztransfers gegenüber sequentieller Ausführung scheinbar stark verringert werden. Abbildung 5.3: beispielhafte Thread-Entwicklung BLOCK-CACHE Blockersetzung Wenn der Cache seine erlaubte Größe erreicht oder der Speicherplatz generell ausgeht, müssen existierende Blöcke aus diesem entfernt werden, um Platz für aktuell benötigte Blöcke zu machen. Hierfür war ein asynchroner Prozess sinnvoll, der à la GarbageCollector längere Zeit nicht benötigte Blöcke entfernt und dafür sorgt, dass der verfügbare Platz gar nicht erst komplett ausgeht. Somit wird die Beantwortung der aktuellen Anfragen nicht unnötig durch Nebenaufgaben verzögert. Dies ist im FUSE-Modul durch die workcachefunktion implementiert, welche als Thread beim Initialisieren des Mountpoints gestartet wird. Durch Logging werden in der blocks-tabelle dafür folgende sinnvoll verwendbare Attribute gesetzt: created, reads, lastread, writes, lastwrite (siehe Abbildung 5.4). Implementiert 83 Performanz

84 KAPITEL 5 - IMPLEMENTATION wurde das iterative Entfernen des am längsten nicht mehr genutzten Blockes, also der Least Recently Used-Algorithmus (LRU). Mit den zur Zeit gesammelten Informationen wäre auch die Umsetzung von Least Frequently Used (LFU) oder einer Kombination aus LRU und FLU, wie Adaptive Replacement Cache (ARC) (Megiddo et Modha 2003) META-DATENBANK (MYSQL) Für die Verwaltung der Meta-Daten wurde das weit verbreitete Open-SourceDatenbanksystem MySQL17 verwendet. Da dies ein relationales System unter Einhaltung des ACID-Prinzips ist, kann so eine konsistente und dauerhafte Sicherung der Meta-Daten erreicht werden. Auf die praktischen Nützlichkeit dieser Entscheidung wird ausführlich im Evaluations-Kapitel eingegangen. Da sowohl FUSE selbst standardmäßig multithreaded arbeitet, als auch einige der erweiterten Funktionaliäten des Proxy jeweils über parallele Threads verteilt werden, ist es absolut notwendig, dass die Einbindung der Meta-Datenbank thread-safe erfolgt. Im Falle der hier verwendeten MySQL-Software muss deswegen einerseits libmysqlclient_r.so anstelle von libmysqlclient.so verlinkt werden. Überdies dürfen zur Datenbank erstellte Verbindungen nur mit Lock-Vorkehrungen verwendet werden. Die interne Möglichkeit von MySQL für Threads separate Verbindungen aufzubauen, wurde allerdings nicht genutzt. Server-Verbindungen aufzubauen, ist sehr zeitintensiv und damit für die kurzen ThreadLaufzeiten zu aufwendig. Auch gab es das Problem, dass MySQL die Verbindung nicht direkt auf Befehl wieder schließt, sondern dafür das Thread-Ende abwartet. Da FUSE aber offensichtlich einen Thread-Pool betreibt, muss es somit immer zum Erreichen der maximalen Verbindungsanzahl des SQL-Servers kommen. Dem könnte wohl nur mit einem eigenen Thread-Pool begegnet werden, was auch das Problem des Verbindungsaufbaus beseitigen würde. Meta-Tabellen Die Umstellung des Proxys auf eine Blockarbeitsweise erforderte auch eine Anpassung von der alten Meta-Datenbank, in welcher die Verwaltungsinformationen gesammelt werden. Abbildung 5.4 gibt einen Überlick über die Relationen, während eine detaillierte Vorstellung im Anhang zu finden ist. Tabellen, die bereits in der Vorarbeit existierten, blieben auch weiterhin erhalten. Allerdings waren darin Änderungen wegen der Umstellung auf die Blocklogik notwendig. Unter anderem hat sich die Zuordnung einiger Attribute zu den Tabellen verschoben, wenn diese Informationen nun entweder einzelne Blöcke, statt ganzen Dateien betrafen; oder wenn

85 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN dieser Detailgrad unnötig war, dem Mountpoint als Ganzem zugeordnet wurden. Überdies wurden Redundanzen durch strikte Fremdschlüssel-Nutzung aufgelöst und kleinere Optimierungen vorgenommen, um Teile der ehemaligen Programmlogik durch automatisch arbeitende Datenbanktechniken zu ersetzen. Abbildung 5.4: Meta-Tabellen der Proxy-Datenbank Log-Tabellen Die Log-Tabellen sollen einerseits die Möglichkeit bieten für Debugging-Zwecke auch noch aus einem laufenden System mit vielen und parallelen Anfragen notwendige Informationen zu extrahieren. Andererseits können daran allgemeines Verhalten und Performanz analysiert werden, was auch für die Evaluation genutzt wurde. So wurde überdies im Web-Management die Abfrage fester Querys implementiert, welche aus den Daten nützliche Informationen filtern und diese etwa nach Storage-Anbietern oder den Latenzen der spezifischer Teil-Aktionen aufbereiten. Solche Informationen können weiterhin genutzt werden, um dem Scheduler bei der Entscheidung zu helfen, die einzelnen Fragmente über die möglichen Anbieter zu verteilen, oder auch, ob wenig zuverlässige Cloudspeicher überhaupt weiterhin genutzt werden 85

86 KAPITEL 5 - IMPLEMENTATION sollten. Demnach sind diese Daten auch dafür geeignet, von Monitoring-Software verwendet zu werden, welche die Einhaltung der vereinbarten Dienstgüte durch den Dienstanbieter überwacht DISPERSION (JERASURE) Wie in der Vorarbeit wurde für die Dispersion die in C geschriebene IDA-Bibliothek Jerasure verwendet (Plank, J. S., Simmerman, S, et Schuman, C. D 2008). Die unmodifizierte Version von Jerasure ermöglicht einerseits das Einbinden einzelner Dispersions-Algorithmen, wobei dann im eigenen Quelltext die notwendigen Vorarbeiten für deren Aufruf erledigt werden müssen; und andererseits das Kompilieren des kompletten Pakets, woraus eine ausführbare Datei entsteht, welche bei Aufruf mittels der angegebenen Parameter für den gewünschten Algorithmus die Vorarbeiten selbst erledigt und danach die angebene Datei verarbeitet. In der Vorarbeit wurde die selbstständig ausführbare Version von Jerasure genutzt, welche jedes Mal für eine Datei vor dem Upload oder ihre Fragmente nach deren Download aufgerufen wurde. Dabei fand also jeweils eine Initialisierung des Dispersers statt, so dass die einzelnen Dateien theoretisch mit verschiedenen Parametern verarbeitet werden konnten. Da es nur eine proxy-weite Konfiguration des Dispersers gab, wurde dies zwar nicht genutzt, allerdings konnte diese globale Vorgabe geändert werden. Ab der nächsten Dispersion würden dann die neuen Parameter verwendet werden. Bereits in der Cloud abgelegte, also vor dem Wechsel zerlegte Dateien konnten aber trotzdem wieder zusammengefügt werden, da die bei ihrer Dispersion genutzten Parameter in der MetaDatenbank gespeichert wurden. Bei der block-basierten Arbeitsweise erfolgt allerdings eine wesentlich höhere Aufruffrequenz bei gleichzeitig kleineren Datensätzen. Eine jeweilige Initialisierung von Jerasure würde einen viel größeren Teil der Gesamtverarbeitungsdauer ausmachen als es bei der datei-basierten Arbeitsweise der Fall ist. Weiterhin wäre generell bei den im KilobyteBereich liegenden Blöcken eine Weitergabe an den Disperser über den Hauptspeicher gegenüber einem Sekundärspeicher zu bevorzugen. Jerasure sollte deswegen als Teil der Programmlogik des FUSE-Moduls verwendet werden und nicht als selbstständige Anwendung. Da der Proxy aber weiterhin die Möglichkeit der Wahl der Disperser-Methode besitzen sollte, statt nur eine spezifische fest eingebunden zu bekommen, wurde der Quelltext der main-funktion so abgeändert, dass Jerasure als Bibliothek verwendet werden kann. Es wurde aber ein Wechseln der Dispersal-Parameter inklusive der Dispersal-Methode für die einzelnen Mountpoints über das Web-Management unterbunden. In der block-basierten 86

87 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN Version wäre ansonsten eine direkte oder referenzierte Speicherung dieser Parameter pro Block notwendig, statt pro Datei wie in der Vorversion. Der dementsprechend erhöhte notwendige Speicherbedarf sowie der Parameter-Abfrageaufwand und die unablässigen Reinitialisierungen des Dispersers sind diesen Aufwand gegenüber einem fraglichen Nutzen einer solchen Möglichkeit nicht wert. Das System wurde also so umgesetzt, dass alle Blöcke eines Mountpoints dieselben Dispersion-Parameter nutzen werden. Die Jerasure-Bibliothek wird beim Start des FUSE-Moduls mit eingebunden und entsprechend der Parameter des Mountpoints erfolgt pro Session eine einmalige Initialisierung des Dispersers, so dass im laufenden Betrieb der Rechenaufwand der Dispersion auf den jeweiligen Aufruf des eigentlichen Dispersal-Algorithmus über den jeweiligen Block beschränkt bleibt. Dies bedeutet, dass keine nachträgliche Änderung dieser Parameter eines Mountpoints möglich ist. In einem solchen Fall müssten nämlich alle Blöcke neu disperst werden, um die vorangegangene Beschränkung der Uniformität zu erfüllen. Wenn allerdings ein Parameterwechsel notwendig sein sollte, kann dies "manuell" erreicht werden, indem ein neuer Mountpoint mit den veränderten Parametern angelegt wird, und dann der gesamte Datenbestand des alten in diesen kopiert wird. Dispersion-Dekodierung Der übergebene Datensatz wird vom IDA wie gewählt in k Fragmente zerlegt und um m Fragmente Redundanz erweitert. Die Erzeugung der m-fragmente erfolgt anhand der kfragmente, welche mit für die verschiedenen verfügbaren Algorithmen spezifischen Matrizen verrechnet werden. Von den k+m=n Fragmenten werden dann maximal k beliebige Fragmente benötigt, um den ursprünglichen Datensatz zu rekonstruieren. Im Fall dieser Proxy-Implementierung entspricht der dem Disperser übergebene Datensatz immer einem Block. Wie in Abbildung 5.5 dargestellt, enthalten die k-fragmente sequentiell und beginnend mit dem ersten Byte die kompletten Blockdaten, aufgefüllt mit einem eventuell notwendigen Padding, um eine mit den Matrizen korrelierende Byteanzahl zu erhalten. In den mfragmenten befindet sich die vom Disperser hinzugefügte Redundanz. Um den Original-Block wiederherstellen zu können, benötigt der Disperser für die Umkehrfunktionen nur k der k+m Blöcke. Da bei einer Blockgröße von n Byte aber die ersten n Byte der Fragmente dem ursprünglichen Block entsprechen, gibt das FUSE-Modul diese einfach direkt zurück, solange sie komplett heruntergeladen werden konnten. In diesem Fall wird der Disperser also überhaupt nicht bemüht. Nur wenn Fragmente so fehlen, dass der Block nicht einfach herauskopiert werden kann, werden die übrigen Fragmente dem Disperser übergeben, damit dieser den Block rekonstruieren kann. 87 Performanz

88 KAPITEL 5 - IMPLEMENTATION Abbildung 5.5: Dispersionsergebnis Schlussfolgernd sollte der Provider-Scheduler den k-fragmenten eine höhere Priorität geben. Das heißt beim Ablegen in der Cloud sollten diese den schnelleren, integereren und verfügbareren Providern übergeben und beim Zurückholen als erstes ihr Download initiert werden. Letzteres würde ermöglichen, dass nach Eintreffen aller k-fragmente bereits mit der Ausführung fortgefahren wird und nicht auf die restlichen Fragmente gewartet werden muss. Das wäre dann nur notwendig wenn nicht alle k-fragmente verfügbar sind PRÜFSUMMENBILDUNG (OPENSSL) Da ein direktes Integrieren in das FUSE-Modul erfolgen sollte, wurde mit OpenSSL 18 eine CBibliothek für die Prüfsummenbildung eingesetzt. Für den Proxy wurden die beiden Verfahren MD5 und SHA-256 (Chaves et al. 2006) eingebunden und können im WebManagement je Mountpoint gewählt werden. Diese beiden Verfahren erstellen eine 16 beziehungsweise 32 Byte-Prüfsumme. OpenSSL bietet noch weit mehr PrüfsummenAlgorithmen, allerdings sind darunter auch viele stark veraltete, welche nicht mehr genutzt werden sollten. Integrität Die Prüfsummen werden vor der Verschlüsselung für alle Fragmente generiert und in der Meta-Datenbank gespeichert. Nach der Entschlüsselung werden diese herangezogen, um die Integrität der wieder eingeladenen Fragmente zu verifizieren. Nur erfolgreich getestete Fragmente werden für die Block-Rekonstruktion herangezogen. So wird unterbunden, dass eingeladene, aber modifizierte Fragmente die Bildung korrekter Blöcke verhindern. Blöcke können vom Proxy also wiederhergestellt werden, solange wenigstens k geladene Fragmente integer sind

89 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN KONZELATION (OPENSSL) Zur Verschlüsselung der in der Cloud liegenden Fragmente wird AES verwendet, ein etabliertes und als sicher geltendes kryptografisches Verfahren, das auch in Techniken wie SSL und WPA2 Verwendung findet. Für den Proxy wird die AES-Implementation der OpenSSL-Bibliothek genutzt. Die gwünschte Schlüssellänge kann im Web-Management pro Mountpoint gewählt werden, der Operationsmodus ist CBC (Cipher-Block-Chaining). Die Konzelation ist die letzte Aktion über den Daten vor ihrem Upload und die erste nach ihrem Wiedereinladen. Sie stellt die Vertraulichkeit der Daten auf ihrem Permanentspeicher sicher und wird deswegen ausgelassen, wenn der Zielspeicher eines Fragments im WebManagement als vertrauenswürdig gesetzt ist. 5.2 WEB-MANAGEMENT (APACHE) Das Web-Management wird über den Aufruf von Python-CGI-Skripten durch einen Apache Webserver realisiert. Die Webseiten sind in XHTML 1.1 geschrieben und nutzen AJAX für einen dynamischen Informationsaustausch. Die Python-Skripte kommunizieren ebenfalls mit der Meta-Datenbank und ermöglichen so die grafische Konfiguration von Cloud-Storage, Nutzern und Mountpoints. Für die Mountpoints kann dabei das Verhalten der einzelnen Proxy-Komponenten gesteuert werden. Auf der zentralen Seite des Web-Managements (siehe Abbildung 5.6) können Eigenschaften der jeweiligen Mountpoints konfiguriert werden. Alle in der Abbildung ausgegrauten Bereiche können aber nicht verändert werden, solange auch nur eine Datei dem Mountpoint zugeordnet ist. 89 Vertraulichkeit

90 KAPITEL 5 - IMPLEMENTATION Abbildung 5.6: Web-Management 90

91 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN 6 EVALUATION Neben einer jeweiligen qualitativen Betrachtung der Anforderungserfüllung erfolgt soweit sinnvoll eine quantitative Evaluation dieser und der System-Komponenten. 6.1 FS - DAS SYSTEM SOLL ÜBLICHE DATEISYSTEMFUNKTIONALITÄT BIETEN Diese Anforderung ist sehr weitreichend umgesetzt wurden (siehe Tabelle 5.1). Einige der nicht umgesetzten Funktionen der FUSE-API sind für Leistungs-Optimierungen gedacht, welche aber eine komplexe interne Cache-Verwaltung des Dateisystems erfordern. Indem es dem Dateisystem das Freigeben der Dateien signalisiert, dient flush etwa der Unterstütztung des Cachings. Diese Operationen bieten also keine direkte Funktionalität für die Nutzer des Dateisystems. Die nicht umgesetzten Extended Attribute-Funktionen dagegen dienen der Nutzbarkeit nicht-standardisierter Dateisystem-Metainformationen und unterscheiden sich zwischen Dateisystemen. Falls es notwendig wird, Anwendungen diese Funktionalität zur Verfügung zu stellen, müssen diese noch implementiert werden. Da es in Zusammenarbeit mit CIFS zu Problemen kam, war es etwa notwendig SELinux auf dem Testsystem zu deaktivieren. Es ist zu vermuten, dass die fehlende Möglichkeit ACL-Attribute zu setzen, dafür verantwortlich war. Speicherkapazität des Proxys In der aktuellen Version nutzen alle Mountpoints dieselbe Datenbank und damit Tabellen. Die folgenden Berechnungen gelten also für den Proxy als Ganzes. Nur wenn jeder 91

92 KAPITEL 6 - EVALUATION Mountpoint seine eigenen Relationen nutzen würde, wären diese Angaben pro FUSE-Instanz gültig. Das id-attribut der Blöcke und Fragmente ist ein 4-Byte UNSIGNED INT-Wert. Damit können theoretisch 2^32 = Fragmente verwaltet werden. Die maximale Anzahl der Blöcke richtet sich allerdings nach den Disperser-Parametern, bei k=4 und m=4, also 8 Fragmenten pro Block wären davon 2^29 = möglich. Der damit verwendbare Speicherplatz ist wiederum von der Blockgröße abhängig und erreicht beispielsweise bei 4 und 64 KB-Blöcken 2 beziehungsweise 32 TB. Speicherbedarf der Meta-Daten Da über die in der Cloud liegenden Daten lokal Meta-Daten gehalten werden, soll die relative Einsparung pro Block evaluiert werden. Der entsprechende benötigte Speicherplatz richtet sich nach dem jeweiligen Eintrag in der blocks-tabelle und den Einträgen der zugehörigen Fragmente in der fragments-tabelle (siehe Anhang). Der Meta-Speicherplatz pro Fragment beträgt mindestens 44 Byte = id (4 B) + block (4 B) + pos (1 B) + uuid (32 B) + provider (1 B) + encryption (1 B) + healthy (1 B). Hinzu kommen die Attribute mit variablen Speicherplatzbedarf. Die Prüfsumme (checksum) kann im jetzigen System nach MD5 (16 Byte) oder SHA-256 (32 Byte) berechnet werden. Dazu können Schlüssel (crypt_pass) und Salt (crypt_salt) für die Kryptographie kommen. Für AES mit 128 Bit-Schlüssel betrügen beide 16 Byte. Da zur Zeit nur ein Salt pro Fragment zum Mountweiten Schlüssel genutzt wird, erreicht ein MD5+AES128-Fragment eine Größe von 132 Byte. Der Meta-Bedarf eines Blocks beläuft sich auf mindestens 57 Byte = id (4 B) + file (4 B) + pos (3 B) + start (8 B) + end (8 B) + exists (1 B) + cached (1 B) und jeweils 4 Byte für created, lastread, reads, downloads, lastwrite, writes, uploads. Hinzu kommt erneut ein variables Prüfsummen-Attribut (checksum), welches den Speicherplatz bei Verwendung von MD5 auf 73 Byte bringt. Fixgröße Block + Checksum +(k +m) ( Fixgröße Fragment + Checksum + Schlüssel + Salt ) Bei der Verwendung einer 8-Fragment + MD5 + AES128 - Konfiguration ergibt sich also ein Meta-Speicherplatz-Bedarf von 1129 Byte pro Block. Da diese Menge unabhängig von der verwendeten Blockgröße entsteht, richtet sich die relative lokale Speichereinsparung nur nach dieser eine Übersicht darüber gibt Tabelle 6.1. Hierzu sei angemerkt, dass die Ersparnis bereits den Meta-Daten-Bedarf der diversen Sicherheits-Komponenten beinhaltet. Ein simples lokales Zerlegen der Dateien in Blöcke und direktes Speichern dieser könnte mit 30 Byte vollbracht werden. Denn zum einfachen Auffinden der notwendigen Blöcke, ohne erweiterte Fähigkeiten bezüglich Vertraulichkeit, Integrität und Verfügbarkeit, wären nur folgende Attribute notwendig: id (4 B), file (4 B), pos (3 B), start (8 B), end (8 B), provider (1 B), exists (1 B), cached (1 B). Bei einem solch 92

93 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN simplen Vorgehen würden bereits 4 KB-Blöcke eine relative lokale Erparnis von 99,27% ermöglichen. Blockgröße in KB (B) absolute lokale Ersparnis in B relative lokale Ersparnis in % 4 (4.096) ,44 8 (8.192) ,21 16 (16.384) ,10 32 (32.768) ,55 64 (65.536) , ( ) , ( ) , ( ) , ( ) ,89 Tabelle 6.1: lokale Speicherplatzersparnis pro Block bei einer 8-Fragment + MD5 + AES128 - Konfiguration 6.2 FF - DAS SYSTEM SOLL DAS LADEN UND SPEICHERN BELIEBIGER DATEIEN ERMÖGLICHEN Diese Anforderung ist erfüllt wurden. Der erreichbare Durchsatz ist dabei stark abhängig von der verwendeten Blockgröße. Das liegt am Verwaltungsaufwand des Proxys. Für die folgenden Tests wurde jeweils eine 20 MB große Datei benutzt. Der Kopiervorgang wurde mit dem dd-befehl ausgeführt, wobei die Größe des Buffers auf jeweils von 4 KB 1024 KB gesetzt war, so das entsprechend große Chunks ausgetauscht wurden. Der erste Test wurde mit BBFS 19 (Big Brother File System) vorgenommen, einer AnalyseImplementierung der FUSE-API. Das bedeutet es stellt kein wirkliches Dateisystem dar, sondern reicht alle Befehle nur an ein tatsächliches weiter, in diesem Fall das Ext3-System der ersten Messung. Es erstellt dabei ausführliche Logs, um das FUSE-Verhalten analysieren und kennen lernen zu können. Die Implementation der write-funktion etwa, ruft mit den ihr übergebenen Parametern nur selbst die C-Funktion fwrite auf und reicht den Aufruf damit durch. BBFS wurde deshalb mit in die Testreihe aufgenommen, um die Verzögerung durch das FUSE-Modul aufzuzeigen. In Abbildung 6.1 ist diese dargestellt. Der Ext3-Teil gibt an, wieviel Zeit das tatsächliche

94 KAPITEL 6 - EVALUATION Dateisystem benötigte, um die Datei zu speichern. Der Rest der Zeit wird durch den Umweg über FUSE verbraucht. Abbildung 6.1: Verteilung des Rechenaufwands bei Nutzung eines BBFS-Mountpoints Im zweiten Test wurde ein Vergleich verschiedener Dateisysteme vorgenommen (siehe Abbildung 6.2). Die erste Messreihe erfolgte mit einem Ext3-System auf einer Magnetplatte. Die Ergebnisse geben dabei wieder, wie viel Zeit Ext3 bis zur einer positiven Rückmeldung benötigte. Da sowohl Dateisysteme als auch Permanentspeicher mit Caches arbeiten, sind die Änderungen zu dieser Zeit noch nicht wirklich alle festgeschrieben und geben deswegen einen höheren Durchsatz wieder als die Festplatte eigentlich leisten kann. Die zweite Messreihe wurde mit BBFS vorgenommen. Die restlichen Werte stammen von der ProxyImplementierung und geben deren Leistung bei Verwendung von Mountpoints verschiedener Blockgrößen wieder. Die Blockgröße des Proxys war dabei auf die dd-chunks abgestimmt. Dabei war allerdings der local-parameter gesetzt, so dass nur eine Zuordnung der übergebenen Speicherbereiche auf Blöcke und deren lokale Speicherung erfolgte, und zwar ebenfalls auf das System der ersten Messung. Es wurde also keine der SicherheitsKomponenten des Proxys bei den Tests ausgeführt, außer dem Hashing der Blöcke. 94

95 SICHERE NUTZUNG VON CLOUD-STORAGE IN DATENBANKEN Abbildung 6.2: Vergleich Standard-, BigBrother- und Proxy-Dateisystem Abbildung 6.3: Aufwand einzelner Tätigkeiten des Proxys beim Speichern 95

96 KAPITEL 6 - EVALUATION Der Durchsatz des Proxy-Dateisystems ohne Nutzung der Sicherheits-Komponenten beginnt bei etwa 200 KB/s für 4 KB-Blöcke und steigert sich auf 2,7 MB/s für 1 MB-Blöcke. Die folgende Grafik gibt wieder, wie sich die benötigte Zeit beim Speichern auf die einzelnen Teilabläufe verteilt. Der Aufwand für die Kommunikation mit der Meta-Datenbank übersteigt alle anderen Aktionen um ein Vielfaches. Da die anderen Tätigkeiten in dieser Darstellung kaum noch auszumachen sind, wird deren Einfluss mit einer relativen Präsentation deutlicher gemacht. Abbildung 6.4: relativer Aufwand einzelner Tätigkeiten des Proxys beim Speichern Auch relativ gesehen dominiert natürlich die SQL-Kommunikation. Allerdings zeigt sich, dass mit zunehmender Blockgröße deren relativer Einfluss sinkt. Dies liegt daran, dass pro Anfrage der prinzipiell selbe Informationsaustausch mit dem SQL-Server stattfindet: Erst werden die Meta-Informationen über die beteiligten Blöcke und Fragmente eingeholt; dann wird die Änderung der Dateigröße vermerkt; schließlich werden die neuen Prüfsummen abgespeichert, in diesem Beispiel nur die des Blocks. Die einzelnen UPDATE-Query fallen dabei mit bis zu 40 ms zu Buche und übertreffen den Aufwand der initialen beiden SELECTAnfrage nach den betroffenen Blöcken und Fragmenten bei weitem. Diese bleiben meist weit unter 1 ms. Da aber bei gleichbleibender Dateigröße mit zunehmender Blockgröße die Anzahl der notwendigen write-aufrufe sinkt, sinkt auch die absolute Anzahl der ausgetauschten SQLQuerys, während der Aufwand für den Prüfsummengenerator und den unterliegenden 96