Anwendbarkeit von BSI IT-Grundschutz Standards auf Cloud Computing

Transkript

1 Masterthesis in Advanced Computer Science - Master Anwendbarkeit von BSI IT-Grundschutz Standards auf Cloud Computing Design der Cloud-Sicherheitsumgebung SMMaaS Referent: Korreferent: Prof. Dr. Christoph Reich Frank Dölitzscher M.Sc. vorgelegt am: 28. Juni 2012 vorgelegt von: Marc Thomas Mühlengasse Pfaen-Schwabenheim

2 cb Dieses Werk ist unter einer Creative Commons Lizenz vom Typ Namensnennung 3.0 Unported zugänglich. Um eine Kopie dieser Lizenz einzusehen, konsultieren Sie oder wenden Sie sich brieich an Creative Commons, 444 Castro Street, Suite 900, Mountain View, California, 94041, USA.

3

4 Abstract In dieser Arbeit wird die Anwendbarkeit von BSI IT-Grundschutz auf Cloud Computing untersucht. Dabei wird speziell auf die Gefahren und Maÿnahmen aus dem IT-Grundschutzkatalog eingegangen und in Bezug auf Cloud Computing analysiert. Fehlende Gefahren werden beschrieben. Dieses Analyse soll Vorbereitungen für einen Bausteinentwurf Cloud Computing treen. Die Ergebnisse der Analyse ieÿen in die Security Managment und Monitoring as a Service (SM- MaaS)-Architektur ein. Anhand der Anforderungen die sich durch die Ergebnisse ergeben werden einzelne Module von SMMaaS genauer designt und beschrieben.

5 II Inhaltsverzeichnis Inhaltsverzeichnis Abstract Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Abkürzungsverzeichnis I II IV V VI 1 Einführung Zielsetzung Einordnung in bestehende Architekturen verwandte Arbeiten Grundlagen Cloud Computing Kryptographie Symmetrische Kryptograe Asymmetrische Kryptograe Hash Verfahren Digitale Signatur Hybride Verfahren Public Key Infrastruktur digitale Zertikate Certication Authority Registration Authority Sperrlisten & Validation Authority Logging Truststufenmodell BSI IT-Grundschutz Analyse BSI IT-Grundschutz Gefahren für die Cloud nach IT-Grundschutzkatalog Vorhandene Gefahren Gefahren aus Bausteinentwürfen Neue Gefahren Zusammenarbeit mit dem BSI SMMaaS Architektur

6 Inhaltsverzeichnis III 4.1 SMMaaS Architektur Anwendbarkeit von IT-Grundschutz Maÿnahmen auf SMMaaS SMMaaS Architektur erweitern Modul: Logging Anforderungen aus dem BSI IT-Grundschutzkatalog Architekturdesign Architekturreview Modul: Customer PKI Anforderungen aus dem BSI IT-Grundschutzkatalog Architekturdesign Architekturreview SMMaaS Architekturreview Fazit Zusammenfassung Ausblick Literaturverzeichnis A Anhang A.1 BSI Korrespodenz A.1.1 an das BSI A.1.2 Interessensbekundung vom BSI A.2 IT-Grundschutz Kreuzreferenztabellen A.2.1 M 1 Infrastruktur A.2.2 M 2 Organisation A.2.3 M 3 Personal A.2.4 M 4 Hard- und Software A.2.5 M 5 Kommunikation A.2.6 M 6 Notfallvorsorge

7 IV Abbildungsverzeichnis Abbildungsverzeichnis Abbildung 2.1 Aufbau einer PKI Abbildung 2.2 Der Weg einer Log Nachricht Abbildung 4.1 CloudDataSec-Schichtenarchitektur Abbildung 4.2 ursprüngliche SMaaS-Architekturdiagramm Abbildung 4.3 Übersichtlicheres SMMaaS-Architekturdiagramm Abbildung 4.4 Aktuelles SMMaaS-Architekturdiagramm Abbildung 4.5 erweitertes SMMaaS-Architekturdiagramm Abbildung 4.6 Direkter Angri auf Server in der Cloud Abbildung 4.7 Angri auf Server in der Cloud mit zentralem Log-Server 42 Abbildung 4.8 Architekturdiagramm für das Logging-Modul Abbildung 4.9 Angri auf Server in der Cloud mit zentralem Log-Server und PKI, Kommunikationverschlüsselung Abbildung 4.10 Architekturdiagramm für das PKI-Modul

8 Tabellenverzeichnis V Tabellenverzeichnis Tabelle 2.1 Unterscheidungen zwischen den Truststufen

9 VI Tabellenverzeichnis Abkürzungsverzeichnis AES Advanced Encryption Standard API Application Programming Interface ASP Application Service Provider BSI Bundesamt für Sicherheit in der Informationstechnik CA Certication Authority CEP Complex Event Processing CERT Computer Emergency Response Team CloudIA Cloud Infrastructure & Applications CRL Certication Revocation List CSP Cloud-Service-Provider CSR Certicate Signing Request EV Extended-Validation DES Data Encryption Standard DFS Distributed File System IaaS Infrastructure as a Service ITU International Telecommunication Union KMU kleine und mittlere Unternehmen NIST National Institute of Standards and Technology NTP Network Time Protocol OCSP Online Certicate Status Protocol PaaS Platform as a Service PDA Personal Digital Assistant PKI Public Key Infrastructure PRNG Pseudo Random Number Generator RA Registration Authority

10 Tabellenverzeichnis VII SaaS Software as a Service SAN Storage Area Network SHA Secure Hash Alghorithm SLA Service Level Agreement SMMaaS Security Managment und Monitoring as a Service TRNG True Random Number Generator VA Validation Authority VM Virtual Machine WORM Write-once-read-many

11

12 1 Einführung 1 1. Einführung 1.1. Zielsetzung In dieser Thesis soll dargestellt werden, wie der BSI IT-Grundschutz mit Cloud Computing vereinbar ist. Dazu werden vorhandene Gefahren aus dem IT- Grundschutzkatalog analysiert, wieweit sie auf Cloud Computing zutreen. Ebenso wird analysiert in wieweit die Beschreibung der Gefahren auf Cloud Computing übereinstimmen. Neben der Analyse der vorhanderen Gefahren werden auch neue Gefahren beschrieben für die der IT-Grundschutzkatalog bisher keine Gefahren vorsieht. Für die analysierten Gefahren wird jeweils beschrieben, wie sich die Situation bei Housing und IT-Outsourcing darstellt. Dem Gegenübergestellt wird die Situation bei Cloud Computing. Im weiteren Verlauf der Thesis werden die SMMaaS-Architektur vorgestellt und notwendige Korrekturen beschrieben. Des Weiteren werden für mehrere Module aus der SMMaaS-Architektur die Anforderungen, welche sich aus dem BSI IT-Grundschutz ergeben, erläutert. Darüber hinaus wird die Architektur der einzelnen Module detailiert designt und beschrieben, sodass die Anforderungen, wenn möglich erfüllt werden. Jede Modularchitektur und die SMMaaS-Architektur wird abschlieÿend einem Review unterzogen, welche aufzeigen sollen, ob die Anforderungen erfüllt sind und welche Anforderungen nicht durch die Architekturen gelöst werden können Einordnung in bestehende Architekturen Die Arbeit konkretisiert und deniert einige Module der SMMaaS-Architektur des Cloud Research Lab, einem Forschungsinstitute an der Fakultät Informatik der Hochschule Furtwangen. Die Module werden entsprechend den Anforderungen aus dem BSI IT-Grundschutz sowie den Aufgaben von SMMaaS designt. Desweiteren werden Anpassungen an der SMMaaS-Architektur selbst vorgestellt. SMMaaS ist ein Teil des Sicherheitsmanagements für die Cloud Umgebung Cloud Infrastructure & Applications (CloudIA). CloudIA ist die Cloud Umgebung welche am Cloud Research Lab entwickelt wird. Sie soll speziell für die Bereiche e- Learning, Forschung und für kleine und mittlere Unternehmen (KMU) konzipiert werden. Neben diesen Architekturen verwendet die Thesis weite Teile des IT-Grundschutzkatalogs. Inbesondere die Gefahren und Maÿnahmen werden verwendet und auf die Anwendbarkeit auf Cloud Computing untersucht. Fehlende Gefahren werden neu beschrieben. Die Anforderungen, welche sich durch die Gefahren und Maÿnahmen ergeben, werden dann zum Designen einzelner Module der SMMaaS-Architektur verwendet.

13 2 1 Einführung 1.3. verwandte Arbeiten Es gibt zum jetzigen Zeitpunkt keine wissenschaftlichen Arbeiten welche die Anwendbarkeit von BSI IT-Grundschutz auf Cloud Computing thematisieren. Die einzigen Dokumenten [1], [2] welche diesen Zusammenhang beschreiben sind vom Bundesamt für Sicherheit in der Informationstechnik (BSI) selbst. Die meisten wissenschaftlichen Arbeiten welche sich mit Compliance und Cloud Computing beschäftigen, verwenden Regelungen wie PCI-DSS, HIPAA, SOX oder ISO27001, hier ist z.b. das Paper von Beckers und Jürjens [3] zu nennen. Arbeiten, welche sich allgemein Sicherheit in Cloud Computing befassen, sind zahlreich. Hierbei ist insbesondere das Buch von Mather, Kumaraswamy und Latif [4] zu nennen. Neben diesem ist auch der Guide der Cloud Security Alliance [5] und die Studie vom Frauenhofer SIT zu Cloud-Computing-Sicherheit [6] hilfreich. Gerade für den europäischen Bereich ist noch die Veröentlichung von der European Network and Information Security Agency (ENISA) zu Cloud Computing Risiko Abschätzung [7] wichtig. Einige dieser Arbeiten wie [3] und [8] stellen dabei eine eigene Architektur zur Sicherheit in Cloud Computing vor. Die Arbeit von Thomas zu Datenverschlüsselung in der Cloud [9] hat eine Reihe von Ideen, welche bei der Planung der Module behilich sind. Neben diesen wissenschaftlichen Arbeiten und Veröfentlichungen gibt es noch einige Projekte welche sich mit der Standardisierung in Cloud Computing beschäftigen. Da die Standardisierung eine wichtige Vorrausetzung für eine einheitliche und ein Provider übergreifendes Sicherheitmangement ist, sollen diese Arbeit nicht vergessen werden. Einige dieser Projekte sind OpenCloud und OpenCirrus.

14 2 Grundlagen 3 2. Grundlagen In diesem Kapitel werden die Grundlagen von Cloud Computing, Kryptograe, Public Key Infrastructure (PKI) und Logging vorgestellt. Desweiteren werden das Truststufenmodell des CloudDataSec-Projektes erklärt und eine kurze Einführung in das BSI und die BSI Grundschutzstandards gegeben. Bei Cloud Computing werden die Charakteristiken, die Servicemodelle und Geschäftsmodelle erklärt. Der Abschnitt Kryptograe gibt einen Überblick über die grundlegenden Verfahren der Kryptograe. Im Kapitel PKI wird die Struktur einer PKI sowie alle wichtigen Komponenten erklärt Cloud Computing Für Cloud Computing gibt es bisher noch keine allgemein akzeptierte Denition. Die Denition von dem National Institute of Standards and Technology (NIST) deniert Cloud Computing sehr treend: Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of congurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management eort or service provider interaction. This cloud model promotes availability and is composed of ve essential characteristics, three service models, and four deployment models. Quelle: NIST [10] Wie die Denition vom NIST aussagt, kann Cloud Computing mit fünf grundlegenden Charakteristiken beschrieben werden. Weiterhin lassen sich drei Servicemodelle und vier verschiedene Geschäftsmodell unterscheiden. Die fünf Charakteristiken sind sinngemäÿ laut NIST [10] die folgenden: On-demand self-service Der Kunde kann ohne Eingreifen durch den Cloud-Service-Provider (CSP) selbstständig und nach Bedarf neue Ressourcen, wie mehr Rechenleistung oder neue Serverinstanzen, allokieren. Broad network access Kapazitäten sind über ein Network verfügbar und durch Standards nutzbar. Heterogene Geräte wie Handy, Laptops, Personal Digital Assistant (PDA)s können deshalb die Kapazitäten verwenden. Resource pooling Der CSP bietet Kapazitäten gemeinsam meheren Kunden an. Diese Kapazitäten werden durch die Mandantenfähigkeit dynamisch einem Kunden

15 4 2 Grundlagen zugeordnet oder wieder freigegeben. Ebenso beinhaltet dies eine Lokationstransparenz: Der Kunde hat keine Kenntniss über den Standort der Kapazität. Auf einem höheren Abstraktionsniveau, wie dem Cloudmanagment, kann der Kunde einen Ort denieren an welchem die Kapazitäten zur Verfügung gestellt werden müssen, so z.b. Bundesland, Staat oder Rechenzentrum. Rapid elasticity Kapazitäten können schnell und dynamisch bereitgestellt werden, in manchen Fällen automatisiert. Dadurch können die Kapazitäten schnell gesteigert und ebenso reduziert werden. Für den Kunden hat es oft den Anschein dads die bereitgestellten Kapazitäten bis ins unendliche gesteigert werden können. Ebenso macht es den Anschein als ob diese Kapazitäten in beliebiger Menge und zu jedem Zeitpunkt gekauft werden können. Measured Service Cloud Systeme kontrollieren und optimieren automatisch die Auslastung der Kapazitäten. Dies bezieht sich auf die einzelnen Kapazitätsarten wie z.b. Storage, Rechenleistung, Bandbreite und aktiven Benutzeraccount auf den Systemen. Die Ressourcennutzung kann überwacht, kontrolliert und gemeldet werden; dies passiert transparent für den Kunden und den CSP. Die Servicemodelle welche bei Cloud Computing allgemein bekannt sind, sind Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS). Diese können folgendermaÿen beschrieben werden: IaaS Bei IaaS wird IT-Infrastruktur wie z.b. Server, Storage, Netzwerkbandbreite als Service angeboten. Die Server sind allerdings alles Virtual Machines (VMs). Der Kunde hat vollen Zugang zu den virtuellen Servern, er ist daher für die Installation, Wartung und Administration des Servers und aller Dienste selbst verantwortlich. Für die virtuellen Server gibt es meist vorgefertige VM-Images, welche der Kunde beliebige anpassen kann. PaaS Bei PaaS stellt der CSP eine Umgebung bereit in welcher der Kunde eigene Anwendungen deployen kann. Der Kunde muss die Anwendungen gegen das Application Programming Interface (API) des CSP programmieren. Er ist hierbei nur für die Wartung und Administration seiner eigenen Anwendung zuständig. Die darunter liegende Infrastruktur und die Applikationsserver administriert und wartet der CSP.

16 2 Grundlagen 5 SaaS Bei SaaS nutzt der Kunde eine komplett durch den CSP installierte Umgebung, z.b. Webmail. Der Kunde ist bei SaaS nicht für die Administration zuständig; dies ist alleinig Aufgabe des CSP. SaaS-Anwendungen bieten oft Schnittstellen für verschiedene Client-Geräte an z.b. Smart-Phone, Thin- Client oder Fat-Client. Bei Cloud Computing sind die Geschäftsmodelle Public Cloud, Private Cloud, Community Cloud und Hybrid Cloud bekannt, welche folgendermaÿen beschrieben werden können [10]: Private Cloud Bei Private Cloud wird die Cloud von einem Unternehmen selbst betrieben. Die interne IT wird dabei in einer Cloud organisiert. Dies ist das Modell mit den wenigsten Problemen, insbesondere aus Sicht des Datenschutzes. Community Cloud Eine Community Cloud ist eine spezielle Cloud welche sich mehrere Unternehmen teilen. Alle diese Unternehmen haben die selben Anforderungen und arbeiten oft schon miteinander. Eine solche Cloud entspricht der Auslagerung der IT eines Konzerns in ein selbstständiges Unternehmen. Public Cloud Eine Public Cloud wird von einem CSP betrieben, welcher seine Dienstleisten jeder Person und jedem Unternehmen anbietet. Dies ist eine Modell mit vielen Problemen, insbesondere mit dem Datenschutz, da viele CSP keine Internas bekannt geben und auch nicht immer der Standort der Rechenzentren bekannt ist. Hybrid Cloud Bei einer hybrid Cloud werden mehrere Geschäftsmodelle miteinander verbunden. So kann ein Unternehmen eine eigene Cloud besitzen und bei Bedarf Kapazität aus einer Public Cloud hinzunehmen Kryptographie Kryptograe ist die Wissenschaft des Verschlüsselung von Informationen. Die Kryptograe verfolgt nach [11] vier Ziele, die nachfolgend deniert sind: Vertraulichkeit Nur dazu berechtigte Personen sollen in der Lage sein, die Daten oder die Nachricht zu lesen oder Informationen über ihren Inhalt zu erlangen.

17 6 2 Grundlagen Integrität Die Daten müssen vollständig und unveränderbar sein. Authentizität Der Urheber der Daten oder der Absender der Nachricht soll eindeutig identizierbar sein, und seine Urheberschaft sollte nachprüfbar sein. Nichtabstreitbarkeit Der Urheber der Daten oder Absender einer Nachricht soll nicht in der Lage sein, seine Urheberschaft zu bestreiten, d. h. sie sollte sich gegenüber Dritten nachweisen lassen. Die Kryptograe kann dabei grundlegend in zwei Verfahren geteilt werden: symmetrische Kryptograe und asymmetrische Kryptograe. Diese beiden Verfahren werden in den nächsten Kapiteln kurz beschrieben Symmetrische Kryptograe Bei symmetrischen Verfahren in der Kryptograe wird nur ein Schlüssel zum Verschlüsseln und Entschlüsseln verwendet. Der Vorteil dieser Verfahren liegt in ihrer Geschwindigkeit, weshalb sie meist genutzt werden um groÿe Datenmengen zu Verschlüsseln. Das groÿe Problem bei diesen Verfahren ist allerdings der Schlüsselaustausch. Jeder der den Schlüssel kennt kann die Daten entschlüsseln, es herrscht das Problem des Schlüsselaustauschs. Da ein Angreifer den Schlüssel in Erfahrung gebracht haben kann ist die Authentizität nicht sicher festzustellen. Typische Algorithmen dieses Verfahrens sind Advanced Encryption Standard (AES), Data Encryption Standard (DES) und Triple-DES Asymmetrische Kryptograe Asymmetrische Verfahren sind dadruch charakterisiert, dass es nicht nur einen Schlüssel gibt sondern immer ein Schlüsselpaar. Diese Schlüssepaare bestehen immer aus einem privaten Schlüssel und einem öentlichen Schlüssel. Beide Schlüssel sind zwar mathematisch voneinander abhängig, ein errechnen des privaten Schlüssels aus dem öentlichen und umgekehrt ist aber praktisch ausgeschlossen. Die Sicherheit der Schlüssel beruht bei gängigen Algorithmen auf den mathematisch Problemen der Faktorisierung von Primzahlen und des diskreten Logarithmus. Die beiden Probleme lassen sich nur mit erheblichen Aufwand berechnen. Die Umkehrfunktionen Multiplikation und Exponentialfunktion lassen sich dagegen mit geringem Aufwand berechnen. Der gröÿte Vorteil dieses Verfahrens ist das der Schlüsselaustausch problemlos möglich ist, es ist sogar gewollt den öentlichen Schlüssel zu verbreiten. Daten können mit dem Verfahren einfach mittels des öffentlichen Schlüssels verschlüsselt werden und der Empfanger, Besitzer des privaten Schlüssels, kann diese mit seinem Schlüssel wieder entschlüsseln. Ein Nachteil

18 2 Grundlagen 7 bei diesem Verfahren ist dass es im Gegensatz zu den symmetrische Verfahren sehr viel langsamer ist. Durch die asymmetrischen Verfahren hat sich eine neue Möglichkeit in der Kryptograe aufgetan; das digitale Signieren von Daten. Im folgenden Kapitel wird das Hash Verfahren vorgestellt, es ist ein wichtiges Instrument um die Integrität von Daten zu sichern Hash Verfahren Hash Verfahren werden auch oft als Einwegfunktionen bezeichnet. Dies beruht darauf dass Hash Funktionen nicht umkehrbar sind. Hash Funktionen bilden eine beliebig lange Zeichenfolge auf eine Zeichenfolge fester Länge ab. Diese Zeichenfolge fester Länge wird dann als Hashwert bezeichnet. Eine Anforderung an eine Hash Funktion ist dass sich der Hashwert stark ändert wenn auch nur ein Zeichen der ursprüngen Zeichenfolge geändert wird. Ebenso soll es nicht passieren dass zwei beliebige Zeichenfolgen den selben Hashwert haben. Das Vorkommen wird als Kollision bezeichnet und schwächt die Hash Funktion. Durch Hash Funktionen lässt sich die Integrität von Daten feststellen. Wenn der Hashwert nach der Übertragung der Daten ein anderer ist, ist eindeutig sichergestellt dass die Daten während der Übertragung verändert wurden. Das Hash-Verfahren ist ein wichtiger Teil für digitale Signaturen welche im folgenden Abschnitt erklärt werden Digitale Signatur Digitale Signatur dient dazu die Integrität, Authentizität und Nichtabstreitbarkeit von Nachrichten sicher zustellen. Eine digitale Signatur dient nicht zur Vertraulichkeit einer Nachricht. Das Gegenteil ist eher der Fall, da die eigentliche Nachricht im Klartext übermittelt wird. Gesetze die sich mit Signaturen beschäftigen sind in Deutschland insbesondere das Signaturgesetz [12]. In diesem wird allerdings der Begri elektronische Signatur verwendet. Diese elektronischen Signaturen sind nicht gleichzusetzen mit digitalen Signaturen, obwohl eine elektronische Signatur auf einer digitalen Signatur basieren kann. Der Begri elektronische Signatur ist eine juristischer Begri. Digitale Signatur allerdings ist ein Begri aus der Mathematik. Im Signaturgesetz ist der Einsatz von elektronischen Signaturen geregelt z.b. Sicherheitsanforderungen an Anbieter, Abgrenzungen zwischen Stufen elektronischer Signaturen und die Einsatzmöglichkeiten von elektronischen Signaturen. Für eine digitale Signatur wird ein Schlüsselpaar, eine Hash Funktion und die Nachricht selbst benötigt. Diese Signatur wird berechnet indem zuerst ein Hashwert der Nachricht berechnet wird. Dieser Hashwert wird mit dem privaten Schlüssel verschlüsselt. Der verschlüsselte Hashwert wird dann an die Nachricht ange-

19 8 2 Grundlagen fügt. Der Empfänger kann diesen verschlüsselten Hashwert mit dem öentlichen Schlüssel entschlüsseln und mit dem selbst erstellten Hashwert der Nachricht vergleichen. Wenn beide Werte identisch sind, ist die Integrität der Nachricht sichergestellt und durch die Verwendung des öentlichen Schlüssels des Absenders auch die Authentizität und Nichtabstreitbarkeit. Neben den ersten beiden Verfahren, symmetrisch und asymmetrisch, gibt es noch hybride Verfahren, welche beide Verfahren kombinieren. Diese hybriden Verfahren werden im folgenden Kapitel beschrieben Hybride Verfahren Durch hybride Verfahren lassen sich die Vorteile der symmetrischen und asymmetrischen Verfahren nutzen. Dazu wird der symmetrische Schlüssel mittels des asymmetrische öentlichen Schlüssels verschlüsselt und an den Empfänger übertragen. Dieser kann mit seinem privaten Schlüssel den symmetrischen Schlüssel wieder entschlüsseln. Auf diese Weise kann der symmetrische Schlüssel sicher übertragen werden und nur der richtige Empfänger kann ihn nutzen. Nach dem Transport des symmetrischen Schlüssels, mittels asymmetrischen Verfahren, wird die weitere Kommunikation mit symmetrischen Verfahren durchgeführt. So kann die Geschwindigkeit der symmetrischen Verfahren mit dem sicheren Schlüsselaustausch der asymmetrischen Verfahren kombiniert werden. Im Folgenden Kapitel 2.3 wird aufbauend auf asymmetrische Verfahren die Struktur und Funktionweise einer PKI erklärt Public Key Infrastruktur Eine Public Key Infrastructure (PKI) ist ein System welches digitale Zertikate ausstellt, verteilt und verwaltet. Mittels digitaler Zertikate kann die Kommunikation über Netzwerk sowie Daten abgesichert werden. Eine PKI mit ihren digitalen Zertikaten erfüllt alle Zielw der Kryptograe Vertraulichkeit, Integrität, Authentizität und Nichtabstreitbarkeit. Sie besteht aus mehreren Komponenten z.b. digitale Zertikate, Certication Authority (CA), Registration Authority (RA) und Certication Revocation List (CRL). Abbildung 2.1 zeigt den Aufbau einer PKI mit den Beziehungen zwischen den Komponenten. Die Komponente digitales Zertikat wird in dem folgenden Kapitel genauer erklärt digitale Zertikate Ein digitales Zertikat sind strukturierte Daten. Es enthält eine Reihe von Informationen: 1

20 2 Grundlagen 9 Abbildung 2.1: Aufbau einer PKI Quelle: Wikipedia 1 ˆ Den Namen oder die Bezeichnung des Ausstellers ˆ Den Namen oder die Bezeichnung des Eigentümers ˆ Informationen zum Gültigkeitszeitraum, Beginn und Ende der Gültigkeit ˆ Den öentlichen Schlüssel des Eigentümers ˆ Den Verwendungzweck des Zertikats ˆ Die digitale Signatur des Ausstellers ˆ Die Seriennummer des Zertikates ˆ Version des Zertikates, normalerweise Version drei ˆ Der verwendete Alghorithmus für die Austeller Signatur (meist SHA-1 mit RSA) Neben diesen Informationen können noch eine Reihe weiterer Informationen in die digitalen Zertikate aufgenommen werden, so z.b. Adresse des Eigentümers, URL der Sperrliste, URL zu der Validation Authority und ein Verweis auf die Zertizierungsrichtlinien des Zertizierungsdiensteanbieters. Die Struktur in der Zertikate erstellt sind, ist durch die International Telecommunication Union (ITU) unter der Bezeichnung X.509 festgelegt worden. Die

21 10 2 Grundlagen aktuelle Version dieses Standards ist Version drei, X.509v3. Im Allgemeinen wird, wenn von X.509 oder digitalen Zertikaten gesprochen wird, immer die aktuelle Version X.509v3 gemeint. Da mit dem Standard nicht alle benötigten Attribute eingeführt wurden, gibt es mittlerweile ein Reihe von Erweiterungen, die ihre Information in den Erweiterungsabschnitt des Zertikats schreiben. Mittels der digitalen Zertikate können alle Ziele der Kryptograe erfüllt werden. Aus diesem Grund werden sie in vielen Bereichen eingesetzt z.b. der Authentizierung von Personen, dem Signieren einer Nachricht aber auch für den Aufbau von verschlüsselter Kommunikation. Im nächsten Kapitel werden die Aufgaben einer Certication Authority beschrieben Certication Authority Die Certication Authority (CA) entspricht im Allgemeinen einer Organisation, welche für das Ausstellen von Zertikaten zuständig ist. Bei der Verwendung von digitalen Zertikaten ist sie für das Ausstellen der digitalen Zertikate und der Erstellung von Sperrlisten zuständig. Aus Softwaresicht wird oft auch die Softwarekomponente welche für das Ausstellen der digitalen Zertikate und Sperrlisten zuständig ist, als CA bezeichnet. Zertikatsanträge werden nie direkt an eine CA gesendet, sonder immer an einer RA. Ebenso verschickt eine CA niemals ausgestellte digitale Zertikate an einen Antragsteller sondern immer an die RA. Dies hat den Grund das die Überprüfung der Identität des Antragsstellers nicht Aufgabe der CA ist sondern der RA. Allerdings darf eine CA erst die digitalen Zertikate signieren nachdem die Identität eindeutig geklärt ist. Damit Zerti- kate welche z.b. kompromitiert sind gesperrt werden können generiert die CA Sperrlisten, auch Rückruisten genannt. Details zu Sperrlisten folgen in Kapitel Um eine akkredierte CA betreiben zu können bedarf es einer Reihe von Vorraussetzungen welche technischer, baulicher und organistorischer Natur sind. Die Vorraussetzung sind in Deutschland in dem deutschen Signaturgesetz geregelt [12]. Im folgende Kapitel wird die Aufgabe der Registration Authority beschrieben Registration Authority Eine Registration Authority (RA) stellt die Schnittstelle zwischen den Kunden und der CA dar. Sie sorgt für die Prüfung der Identität des Antragsstellers bei personenbezogenen Zertikaten. Bei Zertikaten für IT-Systeme wie z.b. ein Webserver, muss die RA überprüfen ob der Antragssteller berechtigt ist für diese Do-

22 2 Grundlagen 11 main Zertikate zu beantragen. Bei diesen systembezogenen Zertikaten sind die Prüfungen oft nicht so streng wie bei personenbezogenen Zertikaten. Ausnahmen hier sind sogenante Extended-Validation (EV)-Zertikate. Die RA sendet nach der Prüfung der Berechtigung bzw. Identität die Zertikatsanträge an die CA zum Ausstellen der digitale Zertikate. Nach dem Austellen bekommt die RA die digitalen Zertikate und überprüft nochmal ob der Inhalt des Zertikats mit den Daten des Antragsstellers übereinstimmen. Erst nach dieser Prüfung werden sie dem Antragssteller übergeben. Im nächsten Kapitel werden die Sperrlisten und die Validation Authority erklärt Sperrlisten & Validation Authority Eine Sperrliste, im englischen Certication Revocation List (CRL) ist eine Liste in der gesperrte Zertikate geführt werden. Die Liste beinhaltet die Gründe der Sperrungen sowie die Seriennummer der Zertikate. Die CRLs unterscheiden zwei Formen des Sperrens: Das Sperren selbst und das Widerrufen. Zertikate werden gesperrt wenn der dazugehörige private Schlüssel verloren bzw. eventuell kompromitiert wurde. Allerdings ist eine Sperrung temporär. Wenn der Inhalt des Zertikats nicht mit dem Antragssteller übereinstimmt oder der private Schlüssel sicher kompromitiert wurde sowie die Gültigkeit eines Zertikats abgelaufen ist werden sie widerrrufen. Ein Widderuf ist endgültig. CRLs werden wie digitale Zertikate durch die CA signiert. Die CRL muss veröentlicht werden damit jeder die Gültigkeit eines Zertikats überprüfen kann. Dies passiert meistens indem die CRL Datei über eine Validation Authority (VA) abrufbar ist. Ein Problem mit dieser Art der Veröentlichung ist dass die Clients nur alle paar Tage bzw. Wochen die CRL von der VA anfordern. Deshalb kann es sehr lange dauern, bis die Sperrung an alle Clients verteilt ist. Eine schnellere Lösung ist die Nutzung des Online Certicate Status Protocol (OCSP). Bei diesem Protokoll fordert der Client keine CRL an, sondern fragt jeweils vor der Nutzung eines digitale Zerti- kats den OCSP Service an. Dieser bestätigt die Gültigkeit von dem angefragten digitalen Zertikat bzw. verweigert sie. Es zeigt sich dass der Einsatz einer PKI unerlässilich für den sicheren Umgang mit digitalen Zertikaten ist. Nur durch dieses zentrale Instrument kann die Gültigkeit von Zertikaten sichergestellt werden. Im folgenden Kapitel wird das Thema Logging näher erkärt Logging Bei dem Logging bzw. Protokollieren werden Ereignisse in Logdateien geschrieben. Die Ereignisse können durch Betriebssysteme, Netzwerkkomponen-

23 12 2 Grundlagen ten, Anwendungssoftware usw. erzeugt werden. Das Logging geschieht meist ohne dass ein Nutzer davon Kenntniss erhält bzw. das es seine Arbeit beinträchtig. Bei dem Logging z.b. unter Linux wird meistens ein Log-Daemon verwendet. Dieser kann die Ereignisse anhand der Quellen und von Filtern in unterschiedliche Logdateien schreiben, siehe dazu Abbildung 2.2 Abbildung 2.2: Der Weg einer Log Nachricht Quelle: BalaBit IT Security 1 Ebenso zeigt die Abbildung, das Logereignisse auch auf andere Server geschrieben werden können. Ein lokales Schreiben von Logdateien ist allerdings der am meisten anzutreende Fall. Damit der Log-Daemon die unterschiedlichen Logereignisse von allen Quellen überhaupt verarbeiten kann, wird jedes Logereigniss mit einer Facility sowie einem Prioritätslevel versehen. Neben diesen beiden Werten, welche nicht in Logdateien geschrieben werden, enthält jedes Logereignisse einen Zeitstempel und das Ereigniss selbst. Im nächsten Kapitel wird das Truststufenmodell des Cloud Research Labs vorgestellt Truststufenmodell Das Truststufenmodell ist im Paper [8] vorgestellt. Es handelt sich dabei um ein dreistuges Modell. Jede Stufe umfasst eine Sammlung von Sicherheitmaÿnahmen. Der Kunde kann sich die für sein Angebot passende Sicherheitsstufe auswählen. Die Auswahl soll auf dem Ergebnis einer Risiko-Analyse beruhen guide-admin-en.html/logging01.png

24 2 Grundlagen 13 Durch die stärkeren Sicherheitmaÿnahmen in den höheren Stufen ergibt sich subjektiv auch ein höheres Vertauen in den Betrieb. Tabelle 2.1 zeigt eine Auistung der drei Stufen mit den jeweiligen Maÿnahmen. Basic Advanced Premium VM location Open Pool Domain specic Private host Identication , Credit Card Letter Third party identication VM Firewall Administration Firewall GUI Firewall GUI Firewall GUI Protocol Monitor Application Level Firewall Quarantine for compromised systems Restart of service secure VM gets started (up to 3x) free selection Quarantine access ssh ssh, terminal Tabelle 2.1: Unterscheidungen zwischen den Truststufen Quelle: [8] In dem Paper [8] wird für die einzelnen Stufen ein Verwendungsbeispiel beschrieben: ˆ Basic level for the development of the company's website. No sensitive data are stored on the development web server. If the system gets compromised, it will only have some minor consequences. ˆ Advanced level for hosting the company's website. There are no restrictions of co-located VMs hosted on the same physical VM host, but only domain specic VMs should be allowed. This is because the risk analysis showed that the availability of the company's website has a direct impact in generating its revenue. In the event of a security incident, the compromised VM is moved into a quarantine environment, and a clean web server image gets deployed to provide a high availability. Bob gets informed about the security incident and he can access the compromised VM stored in the quarantine environment by ssh. ˆ Premium level for hosting an online store that contains customer data. The online shop backend contains sensible user data. The risk analysis showed that in an event of data leakage, it will damage the company's reputation. Permanent monitoring and domain specic communication proles detect a possible security incident. To prevent data leakage, the system is moved to a quarantine environment. Since it is likely that the problem leading to the security incident exists on the clean backup image as well, no backup VM is started to prevent the replay of the attack. The integrity of the service has a higher priority than its availability.

25 14 2 Grundlagen 2.6. BSI IT-Grundschutz Das BSI ist eine Bundesbehörde welche dem Bundesministerium des Inneren unterstellt ist. Das BSI wurde 1991 gegründet. Die Aufgaben der Behörde sind Informieren, Beraten, Entwickeln und Zertizieren. Die Angebote richten sich dabei nicht nur an Behörden, Länder und Kommunen sondern auch an die Wirtschaft und Privatanwender. Aufgrund dieser Aufgaben deniert das BSI deutsche IT-Sicherheitsstandards und betreibt das Computer Emergency Response Team (CERT) des Bundes. Des Weiteren ist es für die Sicherheit der Infrastrukturen des Bundes zuständig. Seit 2009 ist das BSI zusätzlich für die Speicherung und Analyse von allen Kommunikationsprotokollen zwischen Verwaltungen und Bürgern sowie für die Reaktion auf Angrie zuständig. Die Behörde besteht aus vier Abteilungen, welche jeweils Fachbereiche und Referate enthält. Das Referat 114 ist für IT-Sicherheitsmanagment und den IT- Grundschutz zuständig. Dieses Referat ist damit zuständig für das Denieren des IT-Grundschutzkatalogs sowie die BSI-Standards 100-1[13], 100-2[14], 100-3[15], 100-4[16]. Nach [17] sind die Standards folgendermaÿen deniert: BSI-Standard 100-1: Managementsysteme für Informationssicherheit Der vorliegende BSI-Standard deniert allgemeine Anforderungen an ein ISMS. Er ist vollständig kompatibel zum ISO-Standard und berücksichtigt weiterhin die Empfehlungen der anderen ISO-Standards der ISO 2700x- Familie wie beispielsweise ISO (früher ISO 17799). Er bietet Lesern eine leicht verständliche und systematische Einführung und Anleitung, unabhängig davon, mit welcher Methode sie die Anforderungen umsetzen möchten. Das BSI stellt den Inhalt dieser ISO-Standards in einem eigenen BSI- Standard dar, um einige Themen ausführlicher beschreiben zu können und so eine didaktischere Darstellung der Inhalte zu ermöglichen. Zudem wurde die Gliederung so gestaltet, dass sie zur IT-Grundschutz-Vorgehensweise kompatibel ist. Durch die einheitlichen Überschriften in beiden Dokumenten ist eine Orientierung für die Leser sehr einfach möglich. BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise Die IT-Grundschutz-Vorgehensweise beschreibt Schritt für Schritt, wie ein Managementsystem für Informationssicherheit in der Praxis aufgebaut und betrieben werden kann. Die Aufgaben des Sicherheitsmanagements und der Aufbau von Organisationsstrukturen für Informationssicherheit sind dabei wichtige

26 2 Grundlagen 15 Themen. Die IT-Grundschutz-Vorgehensweise geht sehr ausführlich darauf ein, wie ein Sicherheitskonzept in der Praxis erstellt werden kann, wie angemessene Sicherheitsmaÿnahmen ausgewählt werden können und was bei der Umsetzung des Sicherheitskonzeptes zu beachten ist. Auch die Frage, wie die Informationssicherheit im laufenden Betrieb aufrecht erhalten und verbessert werden kann, wird beantwortet. IT-Grundschutz interpretiert damit die sehr allgemein gehaltenen Anforderungen der ISO-Standards der 2700x-Reihe und hilft den Anwendern in der Praxis bei der Umsetzung mit vielen Hinweisen, Hintergrundinformationen und Beispielen. Im Zusammenspiel mit den IT-Grundschutz-Katalogen wird in der IT-Grundschutz- Vorgehensweise nicht nur erklärt, was gemacht werden sollte, sondern es werden auch konkrete Hinweise gegeben, wie eine Umsetzung (auch auf technischer Ebene) aussehen kann. Ein Vorgehen nach IT-Grundschutz ist somit eine erprobte und ef- ziente Möglichkeit, allen Anforderungen der oben genannten ISO-Standards nachzukommen. BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grundschutz Die IT-Grundschutz-Kataloge des BSI enthalten Standard- Sicherheitsmaÿnahmen aus den Bereichen Organisation, Personal, Infrastruktur und Technik, die bei normalen Sicherheitsanforderungen in der Regel angemessen und ausreichend zur Absicherung von typischen Geschäftsprozessen und Informationsverbünden sind. Viele Anwender, die bereits erfolgreich mit dem IT-Grundschutz-Ansatz arbeiten, stehen vor der Frage, wie sie mit Bereichen umgehen sollen, deren Sicherheitsanforderungen deutlich über das normale Maÿ hinausgehen. Wichtig ist dabei, dass die zugrundeliegende Methodik möglichst wenig zusätzlichen Aufwand mit sich bringt und möglichst viele Ergebnisse aus der IT-Grundschutz-Vorgehensweise wiederverwendet. Vor diesem Hintergrund hat das BSI einen Standard zur Risikoanalyse auf der Basis von IT-Grundschutz erarbeitet. Diese Vorgehensweise bietet sich an, wenn Unternehmen oder Behörden bereits erfolgreich mit den IT-Grundschutz- Maÿnahmen arbeiten und möglichst nahtlos eine Risikoanalyse an die IT-Grundschutz-Analyse anschlieÿen möchten. Hierfür kann es verschiedene Gründe geben: ˆ Die Sicherheitsanforderungen des Unternehmens bzw. der

27 16 2 Grundlagen Behörde gehen teilweise deutlich über das normale Maÿ hinaus (hoher oder sehr hoher Schutzbedarf). ˆ Die Institution betreibt wichtige Anwendungen oder Komponenten, die (noch) nicht in den IT-Grundschutz-Katalogen des BSI behandelt werden. ˆ Die Zielobjekte werden in Einsatzszenarien (Umgebung, Anwendung) betrieben, die im Rahmen des IT-Grundschutzes nicht vorgesehen sind. Die Vorgehensweise richtet sich sowohl an Anwender der Informationstechnik (Sicherheitsverantwortliche und -beauftragte) als auch an Berater und Experten. Häug ist es allerdings empfehlenswert, bei der Durchführung von Risikoanalysen auf Expertensachverstand zurückzugreifen. BSI-Standard Notfallmanagement Mit dem BSI-Standard wird ein systematischer Weg aufgezeigt, ein Notfallmanagement in einer Behörde oder einem Unternehmen aufzubauen, um die Kontinuität des Geschäftsbetriebs sicherzustellen. Aufgaben eines Notfallmanagements sind daher, die Ausfallsicherheit zu erhöhen und die Institution auf Notfälle und Krisen adäquat vorzubereiten, damit die wichtigsten Geschäftsprozesse bei Ausfall schnell wieder aufgenommen werden können. Es gilt, Schäden durch Notfälle oder Krisen zu minimieren und die Existenz der Behörde oder des Unternehmens auch bei einem gröÿeren Schadensereignis zu sichern. Wie bereits in den Standarddenitionen zu lesen ist, hat das BSI eine eigene IT-Grundschutzzertizierung etabliert, welche mit der ISO2700x-Standardfamilie kompabtibel ist. Zur Vorbereitung der Zertizierung veröentlicht das BSI den IT-Grundschutkatalog. Im IT-Grundschutzkatalog werden Gefahren, welche durch informationstechnische Systeme und die Organisation bestehen, beschrieben. Ebenfalls werden Maÿnahmen deniert, mit dem die Gefahren verringert oder gänzlich beseitig werden können. Um eine gewisse Übersichtlichkeit in der groÿen Anzahl von Gefahren und insbesondere Maÿnahmen zu gewährleisten, sieht der IT-Grundschutzkatalog so genannte Bausteine vor. Diese bestehen aus Gefahren und Maÿnahmen die thematisch zusammen gefasst sind, wie z.b. B1.11 Outsourcing.

28 3 Analyse BSI IT-Grundschutz Analyse BSI IT-Grundschutz Da der BSI IT-Grundschutz bisher die Gefahren und Maÿnahmen aus dem IT- Grundschutzkatalog noch nicht auf die Anwendbarkeit bei Cloud Computing untersucht sind, soll dies in diesem Kapitel passieren. In Kapitel 3.1 werden daher die bestehenden Gefahren, welche durch Cloud-Computing entstehen, analysiert und es werden neue Gefahren aufgezeigt. Diese Analyse nde im Folgenden Kapitel statt Gefahren für die Cloud nach IT-Grundschutzkatalog Dieser Abschnitt behandelt die Gefährdungen für Cloud Computing gemäÿ dem BSI-Grundschutzkatalog und stellt diese den Vorgehensweisen des Housing bzw. Outsourcing gegenüber. Bei Cloud Computing werden die allgemeinen Konzept und die Ideen für SMMaaS betrachtet. Eine Anbieter übergreifende public Cloud wird dabei nicht betrachtet, da zum jetzigen Zeitpunkt ein Vendorlocking vorliegt. Es existieren keine Standards [18], weshalb ein Zusammenschluss nicht möglich ist. Es werden nur Housing-Provider und Outsourcing Dienstleister betrachten, da diese eine ähnlichen Dienstleistungsumfang haben wie Cloud Computing Provider. Application Service Provider (ASP) zählen hierbei mit zu dnn Outsourcing Dienstleistern. Im folgenden Kapitel werden zunächst die Gefahren analysiert, die bereits Bestandteile des IT-Grundschutzkatalogs sind Vorhandene Gefahren G1.10 Ausfall eines Weitverkehrsnetzes ˆ Housing Provider haben meist eine redundanten Anbindung (Peering) an Carrier, oft sogar mehrere Anbindungen. Der Trac von allen Kunden geht über diese Peerings. Ein Ausfall eines Peerings sollte normalerweise durch das Routing zu kompensieren sein. Es kann aber zu einer Senkung der Qualität kommen. Damit ein Kunde betroen ist müssen meist alle Anbindungen defekt sein. Die Server eines Kunden benden sich bei einem Housing Provider meist im selben Rechenzentrum, teilweise sogar im selben Brandabschnitt. Outsourcing Dienstleister haben oft neben eine generellen redundanten Anbindung an Carrier auch noch direkt Point-to-Point Anbindungen für die einzelnen Kunden. Über diesen Anbindungen geht meist der komplette Datenverkehr zwischen den Netzen des Diensleisters und des Kunden. Ein

29 18 3 Analyse BSI IT-Grundschutz Ausfall einer Kundenanbindung hat dadurch auch nur Auswirkungen auf einen Kunden. Der Kunde kann dann eventuell noch über einen VPN-Tunnel über das Internet Verbindung aufbauen. ˆ Bei Cloud Computing ist die Situation ähnlich wie bei einem Housing Provider. Allerdings ist es von der Idee des Cloud Computing her möglich das einzelne Instanzen in ganz Unterschiedlichen Rechenzentren gehosted sind. Dadurch ist es möglich, das der Service vom Kunden weiterhin verfügbar ist, selbst wenn bei einem Rechenzentrum alle Anbindungen ausfallen. G1.15 Beeinträchtigung durch wechselnde Einsatzumgebungen Relevanz: In der Beschreibung zu dieser Gefährdung wird ausschlichlich von mobilen Geräten gesprochen, im Kontext von Cloud Computing passt die Gefährdung allerdings auch, da eine Idde bei Cloud Computing die Lokationstransparenz ist. ˆ Sowohl bei Housing-Providern als auch bei Outsourcing-Dienstleister sind die IT-Systeme welche der Kunde nutzt und ortsfest in einem Rechenzentrum installiert. Ein Wechsel der Systeme in ein anderes Rechenzentrum wird dem Kunden vorher mitgeteilt bzw. mit ihm Besprochen. Daher besteht hierbei dieses Gefährdung nicht. Dem Kunden ist der Ort der IT-Systeme meist bekannt. ˆ Da Cloud Computing die Idee der lokaltionstransparenz theoretisch verwirklicht, ist es dem Kunden nicht mehr bzw. nur eingeschränkt möglich den Ort eines Systems festzulegen bzw. festzustellen. Bereits nach einem neustart eines System kann sich der Standort verändert haben. Durch dies Lokationstransparenz ergibt sich dann auch die Gefahr. So gibt es in einzelnen Ländern bzw. Bundesländern unterschiedlichen Rechtsprechung, welche sich nachteilig auf z.b. die Integrität der Daten auswirken kann. G1.18 Ausfall eines Gebäudes ˆ Hierbei ist die Situation ähnlich wie bei G1.15, allerdings umgekehrt. Da Housing bzw. Outsourcing Provider teilweise überhaupt nur ein Rechenzentrumsgebäude haben. Insbesonderen da bei Housing- Provider meist alle Kundensysteme in einem Gebäude stehen. Der Kunden kann dem allerdings teilweise entgegen wirkt, was oft mit massiven Mehrkosten verbunden sein kann.

30 3 Analyse BSI IT-Grundschutz 19 ˆ Durch die Lokationstransparenz bei Cloud Computing ist es möglich das sich der Ausfall eines Gebäudes nur auf einen Teil der Kundensysteme auswirken. Da hier der Kunde keinen Einuss auf den Standort seiner IT-Systeme hat ist eine Verteilung über meherer Rechenzentren möglich. G2.1 Fehlende oder unzureichende Regelungen ˆ Housing Provider und Outsourcing Dienstleister sind in der IT-Welt schon lange bekannt. Daher gibt es bereits viele Regeln welche die speziellen Situationen der Dienstleister abdecken. Die zeigt sich nicht auch zuletzt z.b. im BSI-Grundschutzkatalog Beusteine B1.11 Outsourcing. ˆ Für Cloud Computing gibt es noch keine angepasste bzw. speziellen Regeln. Viele Regeln, Gesetze und Standards treen zwar auch auf Cloud Computing zu, allerdings gibt es aber auch bei diesen oft Fälle wo die Lage bei Cloud Computing nicht eindeutig ist. G2.19 Unzureichendes Schlüsselmanagment bei Verschlüsselung ˆ Bei Housingprovider sind die Kundensysteme auch Eigentum des Kunden, so das sich die Daten ausschlieÿ lich auf den Systemen des Kunden benden. Hier ist der Kunde für das Schlüsselmanagment und der konkrete Umgang mit Kryptoschlüssel zuständig. Der Housingprovider hat zwar einen physischen Zugang aber keinen Benutzerpasswörter zu den Systemen. Dies schwächt allerdings trotzdem den Schutz der Kryptoschlüssel. Bei Outsourcing-Provider sollten die Systeme eines Kunden isoliert bestrieben werden, sprich es werden keine Ressourcen zwischen den Kunden geteilt. Allerdings ist bei dem Outsourcing der Diensleister für das Schlüsselmanagment und die Kryptoschlüssel zuständig. Der Umgang von Kryptoschlüsseln und den Schlüsselmanagment kann daher von dem Kunden nur schwer überprüft werden. ˆ Bei Cloud Computing werden Ressourcen geteilt, sowohl die CPU, NIC als auch der RAM und die Festplatte. Des Weiteren sind IaaS- Instanzen in der Regel nicht persistent, sprich mit dem herrunterfahren einer Instanz wird diese gelöscht. Persistente Daten werden normal in einem groÿen gemeinsamen Speicher gesichtert, eine physikalische Separierung (eine reale HDD pro Instanz) ist nicht vorgesehen. Hi-

31 20 3 Analyse BSI IT-Grundschutz er gibt es nun eine verteiltes Schlüsselmanagment. Der Kunde kann die Daten auf der lokalen Instanz verschlüsseln und verschlüsselt dem Providerspeicher übergeben. Hierbei muss der Kunde sorge tragen das die Schlüssel nicht ausschlieÿlich in der Instanz liegen, es wird ein gesonderter persistenter Speicher benötigt. Neben dem Kunden kann auch der Cloud Service Provider die Daten auf dem Weg zwischen der Instanz und dem Speichersystem (Data-in-Transit) verschlüsseln. Es ist bekannt das einige groÿe Cloud Provider hierzu lediglich einen einzigen Kryptokey nutzen, dies kann zu Vertrauensverlust führen. Ebenfalls ist es eventuell möglich ein Kryptokey eines anderen Kunden aus dem Arbeitsspeicher bzw. Festplatte des Virtualisierungshost auszulesen, wenn dies nach dem Runterfahren einer Instanz nicht ordentlich entfernt werden oder es eine Schwachstelle in der Virtualisierungslösung gibt. G2.28 Verstöÿe gegen das Uhrheberrecht ˆ Bei Housing Provider bieten den Kunden lediglich denn Rackspace an. Der Provider ist nicht für die Lizenzierung der Kundensysteme verantwortlich. Bei Outsourcing Providern werden Lizenzen für die jeweiligen Kunden durch den Provider besorgt, der Kunde muss daher für jede Lizenz bezahlen. Der Provider ist für die Installation der Systeme verantwortlich. Für die richtige Lizenzierung ist hierbei sowohl der Provider als auch der Kunde verantwortlich, da der Kunden über die Anzahl der Lizenzen und Systeme informiert ist. ˆ Bei Cloud Computing können zusätzlichen Instanzen mit zu lizenzierender Software ohne eingreifen des Providers erzeugt werden. Durch eine starke Zahl von neu deployed und lizenzrechtlich relevanten Systemen kann es zu einer Unterlizenzierung kommen. Desweiteren ist bei Cloud Computing in der Regel der Provider nur für die Lizenzierung des Betriebsystems(IaaS) bzw. der Plattformen (PaaS,SaaS) zuständig. Für die weitere Lizenzierung von Software auf den Systemen ist der Kunde zuständig. Es gibt darüber hinaus Software die spezielle Lizenzierungmodelle benutzen, welche z.b. mit Virtualisierung unverträglich ist. Durch diese getrenten Zuständigkeiten sowie einer potenziellen Unterlizenzierung ist es möglich das der Kunden nicht lizensierte Software nutzt. G2.54 Vertraulichkeitsverlust durch Restinformationen

32 3 Analyse BSI IT-Grundschutz 21 ˆ Bei Housing Provider ist die Gefährdung nur sehr gerring. Da der Kunde selbst für die Wartung, Reparatur und Aussonderung zu sorgen hat. Hier können daher die normalen Prozesse zur Datenträgervernichtung des Kunden greifen. Eine Ausnahme ist es wenn die Housing Provider sogenannte Remote Hands Dienstleistungen anbiete, wie z.b. auswechseln von defekten Festplatten. Hier ist je nach Vereinbarung der Provider für die Entsorgung zuständing, oder der Provider versendet den defekten Datenträger an den Kunden. Dabei kann G2.47 greifen. Bei Outsourcing Dienstleistern ist der Dienstleister für die Entsorgung von z.b. Datenträger zuständig und führt dies im normalfall im einvernehmen mit dem Kunden durch. Eine Fehlerhafte Entsorgung ist dabei natürlich möglich. Eine fachgerechte Entsorgung der Datenträger bei Beendigung des Vertrags ist sicherzustellen. Bei einer Wiederverwendung, sowie einer nicht vollständigen Vernichtung der Daten auf den Datenträger ist eine Wiederherstellung der Daten durch den Dienstleister möglich. ˆ Bei Cloud Computing hat der Kunden keinerlei einuss auf die fachgerechte Entsorgung von Datenträgern bzw. das vollständige Löschen von Daten. Der Kunden muss darauf vertrauen das der Provider dies richtig durchführt. Es ist hierbei auch denkbar das sowohl Speicherbereiche auf den Festplatten als auch im Ram kurzfristig wiederverwendet werden. Dann ist der Kunde unter Umständen in der Lage die vorher nicht richtig gelöschten Daten wiederherzustellen und zu verwenden. Ein sicherer Datenschutz kann daher ohne kryptographische Verfahren nur schwer gewährleisted werden. Ebenso wäre hier eine vertragliche Verpichtung des Provider, sowie entsprechen angepasste Prozesse wünschenswert. G2.60 Fehlende oder unzureichende Strategie für das Netz- und Systemmanagement & G2.61 Unberechtigte Sammlung personenbezogener Daten ˆ Bei Housing Provider ist für das Systemmanagment der Kunde zuständig. Da der Provider ein Zugri auf die Netzwerkkomponenten nicht zulassen kann, da hierdurch die Verfügbarkeit sinkt und die Angreifbar steigt, kann das Netzmanagment nicht durch den Kunden ausgeführt werden. Der Provider kann dem Kunden allerdings konsolidierte Daten für den Netzbereich des Kunden zu Verfügung stellen. Dies geschieht in der Regel über Web-Guis. Da die Daten in keinem Standardformat vorliegen und Managmentsysteme nicht auf die Daten des Web-Guis zugreifen können, ist eine integration in dass Netz-

33 22 3 Analyse BSI IT-Grundschutz und Systemmangment des Kunden nicht möglich. Bei Oursourcing Dienstleistern übernimmer das Netz- und Systemmanagment normalerweise der Dienstleister, damit er zeitnahe auf Probleme reagieren kann und damit die in den SLA's vereinbarten Servicezeiten erreichen kann. Der Outsourcing Provider kann dem Kunden dabei ebenfalls Zugri auf das Netz-Systemmanagment geben. ˆ Bei Cloud Computing hat man ein stark dynamisch Umgebung. Daher ist das Netz- und Systemmanagment für den Kunden schwierig. Der Provider stellt meist auch nur sehr eingeschränkte Managmentinformationen zu Verfügung welche haupsächlich die Abrechung bzw. Nutzung verdeutlichen sollen. Bei Cloud Computing ist ein zusätzliches Problem das bei IaaS der Kunde nur eine virtuelle Instanz überwachen kann, nicht aber die eigentliche Host-Maschine. Mit dem Truststufenmodell und der SMMaaS-Architektur ist es angedacht, das der Kunde Informationen für seine Instanzen und Netzwerksegmente abfragen kann. Sie werden über standardisierte Schnittstellen und Formate zugestellt. Die Daten müssen allerdings unter Umständen von dem Provider vor dem Ausliefern an den Kunden anonymisiert werden, um eventuelle Verweise auf andere Kunden bzw. die interne Struktur zu verbergen. Ebenfalls bestehen z.b. bei Logles ein Datenschutzproblem, da aus Logles unter Umständen Beziehungen und Prole zu Personen oder Organisationen hergestellt werden können. Das Problem besteht insbesondere da bei viele aktuellen Cloud Service Providern eine Addresse sowie die Daten einer Kreditkarte ausreichen. Durch diese Daten ist eine sichere Indetizierung der Person allerdings nicht möglich. G2.62 Ungeeigneter Umgang mit Sicherheitsvorfällen ˆ Bei Housing Provider ist der Kunde für die Erkennung und Reaktion auf Sicherheitsvorfälle zuständig. Der Provider kann bei Netzsicherheitsvorfällen eventuell dem Kunden mit zusätzlichen Informationen und/oder Massnahmen behilich sein. Bei Outsourcing-Dienstleister ist das Erkennen und Reagieren auf Sicherheitsvorfälle Aufgabe der Dienstleisters. Dieser soll allerdings den Kunden über entsprechende Vorfälle Informieren. ˆ Bei Cloud Computing ist ebenfalls der Kunden für Vorfälle die eine Instanz betrit zuständig. Der Provider wird auf alle Sicherheitvorfälle auf seine Infrastruktur reagieren inkl. Sicherheitsvorfälle auf Vir-

34 3 Analyse BSI IT-Grundschutz 23 tualisierungshosts. Aktuell gibt es bei den meisten Cloud-Providern allerdings keine Hilfsstellung bei Sicherheitsvorfällen auf Kundeninstanzen. Mit dem Truststufenmodell ist geplannt das bei denn höheren Truststufen der Provider ebenfalls bei Sicherheitsvorfällen auf Kundeninstanzen aktiv wird. Sei es durch informieren des Kunden und zu Verfügung stellen entsprechender Informationen, als auch event. ein automatisches Verschieben der Instanz in einen Quarantänebereich. Ein automatischen Neuerzeugen der Kundeninstanz, anhand von kundenspezischen Images (z.b. mit neuen SSH-Schlüsseln) ist ebenfalls angedacht um die Verfügbarkeit des Kundendienstes zu gewährleisten. G2.84 Unzulängliche vertragliche Regelungen mit einem externen Dienstleister Bei Cloud Computing gibt es nocht keine eindeutig Regelungen und Rechtsprechungen daher ist eine Vertragsgestaltung schwierig. Vor Allem da bei Cloud-Providen Verträge zwischen auf Basis der Kreditkartedaten stattnden. Eine extra Vertragvereinbarung welche die Regelungen von BSI, ISO, ITIL etc. abdeckt ist meist nicht vorgesehen. Es werden meist Standardverträge abgeschlossen. Hierdurch kann es zu Problemen mit Businesskunden kommen. Insbesonderen Cloud Dienste bei denen geschäftskritische Anwendungen welche Finanz und/oder personenbezogene Daten verarbeiten werden benötigen dringend spezielle Verträge mit dem Kunden. G2.85 Unzureichende Regelungen für das Ende des Outsourcing-Vorhabens Hierbei ist ebenso wie bei G2.84 die Vertraglich Lage zum einen ein Problem, zum anderen ist es dem Kunden nicht möglich zu überprüfen was mit seinen Instanzen und Daten passiert wenn der Vertrag endet. Die meisten Cloud Provider arbeitet dabei wie eine Black Box, es werden Daten und Informationen in die Black Box gelagert, was dann damit passiert ist nicht ersichtlicht. Hiergegen soll die SMMaaS-Architektur etwas unternehmen. Bereits von Anfang an stellt sie sicher, dass der Provider keine bzw. nut mit eindeutiger Authentifzierung an die eigendlichen persistenten Daten gelangt. Die passiert z.b. durch Ende-zu-Ende Verschlüsselung, zusammen mit einem passenden Schlüsselmanagment. Zusätzlich werden dem Kunden die Massnahmen bei einer Vertragsbeendigung im Vorhinein bekannt gegeben. G2.86 Abhängigkeit von einem Outsourcing-Dienstleister ˆ Bei Housing-Provider ist dies meist kein Problem, da der Kunde die Systemen selbst installiert. Hier bei gibt es normalerweise kein Vendor-

35 24 3 Analyse BSI IT-Grundschutz Lockin. Das Vendor-Lockin beschränkt sich meist nur auf die Managment und Loginformationen des Provider. Jeder Provider stellt diese auf eine anderen Art bereit. Bei Outsourcing Dienstleister ist ein Vendor-Lockin sehr schnell gegeben. Bei einem Vendorwechsel wird es sicherlich Probleme bei der Umstellung geben. Des Weitern sind die IT-Systeme meist Eigentum des Outsourcing Dienstleister, wodurch ein einfaches Umziehen zu einem anderen Diensleister schwierig wird. ˆ Cloud Computing ist die Problematik wie bei Outsourcing Dienstleister. Bisher gibt es keine Kompatiblität zwischen einzelnen Cloud Provider, was auch auf fehlende Standards sowie desinteresse der Provider zurück zu führen ist. Ein Umzug von IaaS-Instanz könnte noch am einfachsten passieren, da es nur wenige groÿe Virtualisierungslösungen gibt. Zwischen den Containerformaten der Virtualisierunglösungen gibt es zusätzlich Converter der in das Format einer anderen Virtualisierunglösung konvertiert. Ebenfalls gibt es hierfür einen onen Standard OVF/OVA. Insbesondere die PaaS-Dienste sind proprietär. Jeder Dienstleister hat hier seine eigene API und nutzt eigene properitär DB-Formate und Schnittstellen. Bei SaaS- Anwendungen ist unter Umständen einen Umzug möglich. Bei Cloud Computing wird einem der Provider in den meisten Fälle nicht unterstützen bei einem Wechsel so das normalerweise immer eine Vendor- Lockin vorliegt. Es sind aber bereits Forschungsprojekte am laufen, welche einen oenen Cloud-Stack entwickeln und etablieren wollen, wie z.b. OpenCirrus oder OpenCloud G2.109 Fehlende oder unzureichende Planung des Speichersystems ˆ Wenn ein Speichersystem zu einem Housing-Provider ausgelagert wird, z.b. als zentraler Datenbankstorage, gehört das System dem Kunden und auch nur dieser hat Zugri auf das System. Hier muss der Kunden die Planung des Systems übernehmen. Bei Outsourcing wird in vielen Fällen ebenfalls für einen Kunden ein dediziertes Speichersystem genutzt. Hierbei wird der Dienstleister im Einvernehmen mit dem Kunden das Speichersystem planen. Bei Outsourcing Diensleistern mit einem zentralen Storage, wird einen gewisser Bereich (LUN) für einen Kunden konguriert und nur die Systeme des Kunden haben Zugri darauf. In dem Fall ist der Dienstleister exklusiv für die Planung zuständig. ˆ Bei CloudComputing gibt wird es wahrscheinlich mehrere Speichersys-

36 3 Analyse BSI IT-Grundschutz 25 teme geben. Zum einem der temporär Speicher in Form von lokalen Festplatten in den Virtualisierungshosts. Hier ist die Planung sehr einfach. Darüber hinaus ein zentrales Storagessystem in dem die persistenten Daten gespeichert werden. Wegen der groÿen Anzahl von Kunden und Instanzen ist hierbei eine exklusive Zuweisung eines Bereiches (LUN) nicht möglich. Deshalb werden die Daten von mehreren Kunden auf ein LUN gespeichert. Eine Überbuchung des Speichersystems durch den Cloud Computing ist wahrscheinlich. Durch diese Überbuchung und eventuell sehr schnell ansteigendem Speicherbedarf sowie Bandbreiten und Verfügbarkeiten kann es hier schnell zu einer Fehlplanung kommen, insbesondere bei der Kapazitätplanung. G Unzureichende Kontrolle von VPNs Bei CloudComputing allgemein hat der Kunden keinen Einuss auf die darunterliegenden Netzwerkinfrastruktur. Daher ist es einem Kunden nur möglich das VPN zu kontrollieren wenn der Cloud-Provider entsprechede Informationen bereit stellt. Im Konzept welches für die Nutzung von VPN durch die SMMaaS Architekur entwickelt wurde, wir der komplette VPN-Trac eines Kunden über einen Kunden VPN-EndPoint geführt. Hier ist ein Auslesen der notwendigen Loginformationen möglich. G Mangelhaft festgelegte Verantwortlichkeiten beim Patch- und Änderungsmanagement ˆ Beim Housing die die Verantwortlichkeiten geklärt, der Kunde ist für seine IT-Systeme zuständig und der Provider für seine Systeme. Bei Outsourcing ist die Regelung prinzipell auch recht eindeutig geregelt, hier ist der Dienstleister verantwortlich. ˆ Bei Cloud Computing ist eine klare Trennung nicht komplett zu Erkennen. Natürlich ist der Provider für seine Systeme zuständig. Allgemein sind für die IaaS-Images sowohl der Kunde als auch der Provider für das einspielen von Patchen und Änderungen zuständig. Bei einer laufenden Instanz ist der Kunde für das Patch- und Änderungsmanagement zuständig. Gleichzeitig ist aber der Provider für z.b. den Patchstand der Basis-Images zuständig. Dadurch kann es passieren das der Kunde einen anderen Patchstand bzw. eine geändertes Instanz erhält wenn er eine neue Instanz deployed. G Zerstörung von Beweisspuren bei der Behandlung von Sicherheitsvorfällen

37 26 3 Analyse BSI IT-Grundschutz ˆ Da bei Housing-Providern die Systemen dem Kunden gehören, ist dieser für die Sicherung der Beweisspuren zuständig. Wenn allerdings der Server nicht mehr erreichbar ist, kann durch den Kunden ein Reset des Systems veranlasst werden und dadurch Spuren vernichtet werden. Bei Outsourcing Providern ist der Dienstleister für die Beweissicherung zuständig. Dieser hat eventuell extra dafür geschultes Fachpersonal z.b. aus seinem CERT. ˆ Bei Cloud Computing kann der Kunden selbst nur Beweisspuren bei IaaS sammeln, allerdings auch nur eingeschränkt. Bei PaaS, SaaS, stehen die Systeme unter der Verwaltung des Provider. Dieser kann eventuell Loginformationen dem Kunden bereitstellen, eine extra Beweissicherung bei Kundensystemen wird wahrscheinlich nicht stattnden. G 3.32 Verstoÿ gegen rechtliche Rahmenbedingungen beim Einsatz von kryptographischen Verfahren ˆ Bei Housing und Outsourcing ändert sich der Standort eines System in der Regel nicht bzw. ist eine Standortänderung in ein anderen Land in der Regel geplant. Dadurch ist es möglich die Server bereits im Vorhinein auf die andere Rechtslage anzupassen. ˆ Bei CloudComputing ist es prinzipell möglich, dass eine Instanz innerhalb von Sekunden in ein anderes Land verschoben wird. Dadurch ist eine geplante Anpassung an die Rechtslage nicht möglich. Das zu verhindern ist nur möglich, wenn in der gesamten Cloud, die minimalen Anforderungen herschen, dadurch wird allerdings die Sicherheit in der gesamten Cloud geschwächt. G 3.79 Fehlerhafte Zuordnung von Ressourcen des SAN Bei Cloud Computing ist dieser Fall absehbar. Durch die groÿe Anzahl an Kunden ist eine eindeutige Zuordnung eines LUN zu einer Kundeninstanz nicht möglich. Des Weitern terminieren die SAN-Verbindung in der Regel auf dem Virtualisierungshost und nicht in der VM. Es ist zwar möglich ein LUN mittels NPVI in einer Instanz zu terminiern, aber der Umgang damit wird dem Kunden normalerweise abgenommen. Des Weiteren ist es möglich, dass die Speichersysteme nicht genügend LUN's haben, so das sich verschieden Kunden ein LUN teilen müssen. G 5.20 Missbrauch von Administratorrechten

38 3 Analyse BSI IT-Grundschutz 27 ˆ Bei Housing ist ein Missbrauch von Administratorrechten durch den Provider faktisch ausgeschlossen, da der Provider keinen Shell-Zugang zu den Kundensystemen hat. Ein Angri auf ein System und Erlangung von Administratorrechten ist natürlich weiterhin möglich. Bei Outsourcing haben meist viele User Zugang auf die Systeme, daher ist das Erlangung von Administratorrechten eher möglich. ˆ Bei Cloud Computing werden IaaS-Instanzen oft als eine Art managed Root-Server betrieben. Der Kunden kann durch ein Frontend z.b. sshkeys auf Systeme einspielen. Daher ist es teilweise sodas der Provider ein Zugang zu einer IaaS-Instanz hat, um die Änderungen durch das Frontend einzuspielen. Ein Ausnutzen dieses Zugangs und dadurch ein Missbrauch von Administratorrechten ist hier möglich. Gefahren welche noch auf Bausteinentwürfen stammen und noch nicht oziell im IT-Grundschutzkatalog sind, werden im nächsten Kapitel analysiert Gefahren aus Bausteinentwürfen Die folgenden Gefahren entstammen den Entwürfe der Bausteine Virtualisierung [19] und Terminalserver [20]. G2v8 Fehlerhafte Integration von Gastwerkzeugen in virtuellen IT- Systemen ˆ Bei Housing ist der Kunde selbst für die korrekte Integration von Gastwerkzeugen zuständig. Bei dem IT-Outsourcing hat die fehlerfreie Integration der Dienstleister sicherzustellen. ˆ Bei Cloud Computing wird meist keine Gastwerkzeuge, einer Virtualisierunglösung, installiert. Dies ist insbesondere der Fall bei IaaS Linux-Instanzen welche XEN als Hypervisor nutzen. In dieser Kombination wird die sogenannte Paravirtualisierung genutzt. Dadurch ist der Linux Kernel selbst das Gastwerkzeug. G4v1 Störung der Netzinfrastruktur von Virtualisierungsumgebungen ˆ Bei dem Housing kann der Kunden entscheiden ob er mehrere Virtualisierungshosts zu einer virtuellen Infrastruktur zusammen schaltet. Er hat auch dafür zu sorgen das es nicht zu einer Störung der Netzwerkverbindung z.b. durch Fehlkonguration kommt. Bei dem Outsourcing fallen die Entscheidungen und die Verantwortung dem Diensleister zu.

39 28 3 Analyse BSI IT-Grundschutz ˆ Bei Cloud Computing ist es nicht unwahrscheinlich das der CSP eine Mangementsoftware nutzt um die Virtualisierungshosts zentral administrieren zu können. Ein Zusammenschalten zu einer groÿen virtuellen Infrastruktur ist allerdings unwahrscheinlich. Da durch den Einsatz der virtuellen Infrastruktur Managmentsoftware einige Funktion wie die Verteilung auf die einzelnen Systeme nicht mehr über das Cloud- Management organisiert werden kann. G4v6 Ressourcenengpass durch fehlerhafte Funktion der Gastwerkzeuge in virtuellen Umgebungen & G 5.v7 Missbräuchliche Nutzung von Gastwerkzeugen in virtuellen IT-Systemen ˆ Die Gefahr besteht sowohl bei dem Housing als auch bei dem Outsourcing. Bei dem Housing ist der Kunde selbst für die Administration der Virtualisierungshosts und deren Instanzen zuständig. Bei dem Outsourcing ist es Aufgabe des Diensleisters ein solche Fehlkonguration zu verhindern und zu beseitigen. ˆ Diese Problem kann bei Cloud Computing nicht auftretten, da wie bereit in G2v8 erklärt bei Cloud Computing keine Gastwerkzeuge genutzt werden. Als letzen werden im Folgenden Kapitel noch neue Gefahren analysiert Neue Gefahren Gc1 Lokation von Daten ˆ Bei Housing ist der Ort an dem die Daten gespeichert klar geregelt, sie liegen auf Systemen des Kunden. Der Kunde weiÿ bescheidt in welchen Land und an welchem Ort genau die Systeme sind. Wenn der Housing Provider sein Rechenzentrum verlagert wird der Kunde informiert und der Kunde kann bei z.b. einer Verlagerung ins Ausland entgegen wirken. Bei Outsourcing-Provider wird der Standort der System und Daten zwischen dem Dienstleister und dem Kunden vertraglich festgelegt. Eine Verlagerung an einen anderen Standort muss mit dem Kunden abgestimmt werden. ˆ Bei Cloud Computing hat normal der Kunde kein Einuss auf den Standort der Systeme und Daten. Der CSP kann Rechenzentren in mehrern Ländern haben, wodurch es zu unterschiedliche rechtlichen Geltungsbereichen kommen kann. Verschiedene CSP wollen dem en-

40 3 Analyse BSI IT-Grundschutz 29 gegenwirken in dem Sie verschieden Cloudzonen etablieren in dennen jeweils ähnliche rechtliche Regelungen gelten. Gc2 Fehlerhafte isolierung von Kunden-systemen und -daten ˆ Bei Housing gehören den Systemen dem Kunden, daher sind die Systeme bis auf das Netzwerk des Hounsing-Diensleisters voneinander Isoliert. Bei Outsourcing sind die meisten Systeme exkulsiv einem Kunden zugeordnet. Systeme die durch meherer Outsourcingkunden verwendet werden, sind komplett unter der Verwaltung des Outsourcing- Diensleisters, wodurch eine Isolierung gut sichergestellt werden. ˆ Bei Cloud-Computing ist durch den Einsatz von Virtualisierung ein strikte Trennung schwierig. Dies wird durch die groÿe Anzahl von Kunden zusätzlich erschwert. Persistente Speicher werden bei Cloud- Computing ebenfalls von mehere Kunden verwendet. Ebenfalls ist durch den Root-Zugang bei IAAS-Instanzen eine gröÿere Angrisäche vorhanden um die Isolierung zu durchbrechen. CSP müssen bereits bei der Planung der Infrastruktur und der Softwaresysteme auf Mandantefähigkeit achten. Gc3 Fehlerhafte Konguration von Sicherheitsgateway durch unterschiedlichen Zuständigkeiten ˆ Bei Housing-Dienstleistern ist der Kunde normalerweise selbst für die Konguration von Sicherheitsgateway, Firewalls, IDS etc. zuständig. Der Dienstleister wird nur dann Eingreifen und eventuell einen Kundenserver sperren, wenn sich ein Angri auf ein Kundensystem auf die gesamte Infrastruktur auswirkt. Bei Outsourcing-Dienstleistern ist der Dienstleister alleine für die Sicherheitsgateways zuständig. Der Kunde muss Änderungen an der Konguration bei dem Dienstleister beantragen. ˆ Bei Cloud-Computing muss sicher je nach Art des Services der Kunde mit der Konguration der Gateway abnden. Bei IAAS gibt der CSP ein Konguration des Gateways vor. Der Kunde hat nur bedingt ein- uss auf die Konguration. Dies geschieht weil der CSP seine Infrastruktur und inbesondere die Virtualisierungshost absichern muss. Bei PAAS und SAAS hat der Kunde kein Einuss auf die Konguration des Gateways. Gc4 Fehlende Regelungen für Nutzung von 3. Anbieter durch den Provider

41 30 3 Analyse BSI IT-Grundschutz ˆ Bei Housing-Dienstleistern sind die Kundendaten normalerweise auch nur auf Kundensystemen gespeichert. Für eine Nutzung durch 3. Anbieter muss der Kunde die Daten herausgeben. Der Kunde hat hierbei auch die Möglichkeiten den 3. Anbieter auf den Danteschutz hin zu verpichten. Bei Outsourcing-Dienstleister liegen die Kundendaten meist im Rechenzentrum des Dienstleisters. Dieser kann wiederrum Teile seiner Infrastruktur bzw. seiner Verwaltung an 3. Anbieter auslagern. Die bedarf normal einer vorherigen Vertraglichen Regelung mit den Kunden. Der Kunde muss sich auf Vertraglichen Regeln verlassen. ˆ Bei Cloud Computing besteht in den meisten Fällen keine Vertraglichen Regelungen. Der CSP kann wie der Outsourcing-Diensleister Teile seiner Infrastruktur bzw. Datenverarbeitung an 3. Anbieter auslagern. Der Kunde wird normal nicht über den Einsatz von 3. Anbieter unterrichtet, und er ist meistens auch nicht in der Lage dies Festzustellen. Gc5 Fehlerhafte Zugrisregelungen auf Daten und Systeme ˆ Der Zugrie auf Kundensystem und Kundendaten regelt bei Housing- Dienstleister ausschlieÿlich der Kunde. Administratoren des Dienstleisters haben normal keinen Zugri auf die Kundensysteme, sofern der Kunde den Zugang nicht explizit genehmigt. Bei Outsourcing- Dienstleistern ist dies anders. Hier regeln die Administratoren des Dienstleisters den Zugri auf die Systeme und Daten des Kunden. Der Kunde beantragt Zugrirechte für Mitarbeiter und Partner auf die Systeme und Daten. ˆ Die Zugrie bei Cloud Computing sind sehr viel komplexer, insbesondere bei IAAS. Innerhalb der IAAS-Instanz regelt der Kunden den Zugri, nicht nur der Zugangs zu dem System sondern auch der Zugri auf Dienste welche in dieser Instanz laufen. Der initial Zugri auf eine IAAS-Instanz richtet allerdings der Provider ein. Es besteht auch oft die Möglichkeit das der Consolenzugang zu den IAAS-Instanzen über das Managmentsystem der Providers zusätzlich geregelt wird. Bei PAAS und SAAS wird die Zugri auf den Dienst normal durch den Kunden geregelt, wobei die Konguration teilweise über das Managmentinterface des Providers stattndet. Neben der Zugriregelung durch den Kunden muss der Provider zusätzlich eine eigene Zugriregelung etablieren. Da anderenfalls z.b. ein Administrator welcher für den persistenten Speicher zuständig ist, Zugri auf Kundendaten

42 3 Analyse BSI IT-Grundschutz 31 bekommen kann. Es zeigt sich das Cloud-Computing ein Reihe neuer Gefahren mit sich bringt. Diese Gefahren müssen in dem zukünftigen IT-Grundschut Baustein Cloud-Computing berücksichtigt werden. Ebenfalls sollten ein IT- Sicherheitsmanagmentsystem möglichst viele dieser Gefahren entgegen wirken. Im folgenden Kapitel wird das Cloud-Computing Sicherheitsmanagmentsystem SMMaaS welches von dem Cloud Research Lab entwickelt wurde und im Paper Designing Cloud Services Adhering to Government Privacy Laws [8] veröffentlicht Zusammenarbeit mit dem BSI Um den BSI Grundschutzkatalog um Cloud-spezische Gefahren oder ggf. einen Cloud Comuting Baustein zu erweitern ist eine Zusammenarbeit mit BSI notwendig. Das Cloud Research Lab der Fakultät Informatik, Hochschule Furtwangen hat sich als eines seiner Ziele gesetzt diese Lücke zu füllen. Diese Ergebnisse kann das Cloud Research Lab als neuen Bausteinentwurf in den IT- Grundschutzkatalog einiessen lassen. Deshalb wurde eine Anfrage (siehe A.1.1) zur Zusamenarbeit an das BSI, Referat 114 gesendet. Das BSI stand dieser Zusammenarbeit (siehe A.1.2) positiv gegenüber. Es soll im Zuge dieser Zusammenarbeit zu regelmäÿigen Informationsaustausch zwischen dem BSI und dem Cloud Research Lab kommen.

43

44 4 SMMaaS Architektur SMMaaS Architektur Die Security Managment und Monitoring as a Service (SMMaaS)-Architektur ist eine Entwicklung des Cloud Research Lab. Sie ist Teil des CloudDataSec- Projektes, welches zum Ziel hat die Sicherheit und das Vertrauen in Cloud Computing zu steigern. Diese Ziele sollen dabei mit den europäischen und nationalen Datenschutzgesetzen vereinbar sein. Die Zielgruppe bei diesem Projekt sind KMU. SMMaaS wurde erstmalig in einem Paper von Dölitzscher et al. [8] noch unter der Abkürzung SMaaS vorgestellt. Im folgenden Kapitel wird kurz die Architektur des CloudDataSec-Projektes vorgestellt, sowie ausführlich die darauf aufbauende SMMaaS-Architektur SMMaaS Architektur Das CloudDataSec-Projekt sieht eine sechs Schichtenarchitektur (Abbildung 4.1) vor. Abbildung 4.1: CloudDataSec-Schichtenarchitektur Quelle: [8] Die Schichten sind von oben Benutzer nahe nach unten Technik nahe aufgebaut. Die untersten drei Schichen Data Encryption, Logging und Encrypted Communication repräsentieren die Daten- bzw. Kommunikationsicherheit. Die Datensicherheit wird durch Verschlüsselung der Daten, sowie dem Protokollieren der Datenzugrie sichergestellt. Bei der Kommunikationsicherheit sind Techniken der Kommunikationverschüsselungen im Einsatz, so z.b. IPSEC und SSL. Die oberste Schicht Risk Analysis kann nicht mehr technisch gelöst werden sondern benötigt das Management des Kunden bzw. des CSP. Die Schicht Security Guidelines ist für das Einhalten von gesetzlichen Bestimmungen zuständig. Diese Bestimmungen werden in Regelwerken deniert, den sogenanten Security Guidelines. Die letzte Schicht QoS Monitoring sorgt dafür dass vertragliche

45 34 4 SMMaaS Architektur Regelungen, welche in Service Level Agreement (SLA)'s deniert sind, eingehalten werden. Hierzu muss die Schicht Zugri auf viele Informationen, wie z.b. Loggingdaten, haben. Durch diese Informationen kann ermittelt werden ob die vertraglichen Regelungen erfüllt wurden. Eine zweite Komponente welche durch das CloudDataSec-Projekt entwickelt wurde ist das so genanten Truststufenmodell, welches bereits in Kapitel 2.5 beschrieben ist. Die SMMaaS-Architektur (Abbildung 4.2) soll die Kernkomponenten des CloudDataSec-Projektes darstellen. Es ist ein Architekturentwurf welcher als Vorlage zur Implementierung dient. Abbildung 4.5 zeigt das originale SMaaS- Architekturdiagramm aus dem SMaaS-Paper [8]. Das Architekturdiagramm hat sich seit dem Erscheinen der Papers geändert; dies wird in Kapitel 4.3 erklärt. Abbildung 4.2: ursprüngliche SMaaS-Architekturdiagramm Quelle: [8] SMMaaS besteht selbst aus einer Reihe von Modulen, welche nachfolgende entsprechend [8] sinngemäÿ beschrieben werden: Crypto Modul Ist für das Verschlüsseln der Daten zuständig, wenn es aktiviert wird. Customer PKI Das Modul sorgt für die Benutzerauthentizierung und die Datensegmentierung. Data Leakage Prevention Modul Das Modul überwacht Datenströme. SLA Monitoring Durch dieses Modul werden QoS Attribute garantiert. Policy Modul Ist für das Kongurieren des Monitoring, den Datenzugri und den Zustand der Systeme zuständig. Des Weiteren generiert es Berichte über den Status der durch den Kunden genutzen Umgebung.

46 4 SMMaaS Architektur 35 Logging Das Modul stellt ein nahtloses Logging von Ereignissen und Datenzugrien sicher. Es beinhaltet einen Timestamp Service um die Logeinträge fälschungssicher und den Gesetzen entsprechend zu machen. Intrusion Detection Modul Ist für das Erfassen unberechtiger Zugrie zuständig und arbeitet eng mit dem Data Leakage Prevention Modul zusammen. Die vorgestellen Module kommunizieren untereinander über ein seperates internes Cloud Netzwerk. SMMaaS hat zusätzlich eine direkte Anbindung an den Data Storage des CSP. Zur Administration und Überwachung der SMMaaS-Umgebung bietet dieses einen gesonderten VPN-Zugang für die Kunden an. Durch die Verwendung von VPN dehnt sich die Kommunikationverschlüsselung, welche SMMaaS selbst fordert und anbietet, bis zu dem Kunden aus. Im folgenden Kapitel wird beschrieben wie IT-Grundschutz Maÿnahmen die SMMaaS-Architektur beeinussen Anwendbarkeit von IT-Grundschutz Maÿnahmen auf SMMaaS Die SMMaaS Architektur kann einer Reihe von Gefahren entgegenwirken. Gefahren die hauptsächlich organisatorischer bzw. gesetzlicher Natur sind lassen sich mit der SMMaaS-Architektur nur bedingt verringern. In der folgenden Auistung sind die Gefahren gelistet, welche durch die SMMaaS-Architektur verbessert werden können. G1.15 Beeinträchtigung durch wechselnde Einsatzumgebung Im Managment Modul von SMMaaS kann der Kunde denieren ob seine Systeme auf alle Rechenzentren frei verteilt werden oder ob sich die Instanzen auf ein Rechenzentrum konzentrieren sollen. Die Truststufen Advanced und Premium schränken dies ebenfalls ein: So müssen bei diesen Stufen die Systeme in einem Rechenzentrum laufen. Durch das Einschränken lassen sich Probleme mit unterschiedlichen Umgebungen vermindern. G2.19 Unzureichendes Schlüsselmanagement bei Verschlüsselung Das Schlüsselmanagement wird bei SMMaaS durch das Crypto- und PKI- Modul geregelt. Insbesondere der Schutz der symmetrischen Schlüssel zur Datenverschlüsselung ist stark abgesichert. Die Schlüssel liegen zwar bei

47 36 4 SMMaaS Architektur dem CSP sind aber verschlüsselt. Der CSP hat also keine direkten Zugri auf die Schlüssel. Die SMMaaS-Architektur sieht zusätzlich strenge Zugrisregeln vor. Es ist anzudenken das ein Administator des CSP nur temporär Zugri auf die Schlüssel und Systeme bekommt nach vorheriger Autorisierung durch den Kunden. G2.54 Vertraulichkeitsverlust durch Restinformationen Die Prozesse und Module in SMMaaS sehen ein unwiederbringliches Löschen aller Daten vor. Der Kunde kann das Löschverfahren, z.b. nach DoD-Standard, dabei im Vorhinein festlegen. G2.60 Fehlende oder unzureichende Strategie für das Netz- und Systemmanagement Bei dieser Gefahr kann wie bei weiterrn Gefahren SMMaaS nur unterstüzend helfen. Dies geschieht indem SMMaaS ein ganzheitliches System zur Netz- und Systemüberwachung anbietet. G2.61 Unberechtigte Sammlung personenbezogener Daten Es gibt mittlerweile eine Reihe rechtlicher Bestimmungen die das personalisierte Loggen verbieten. Hier ist z.b. das Telemediengesetz zu nennen. Nach diesem dürfen die personalisierten Logdaten nur zu Abbrechnungzwecken aufbewahrt werden. Um dieser Gefahr entgegenzuwirken wird im Modul Logging eine Funktion zum Anonymisieren von Logdaten vorgesehen. Nähere Informationen dazu folgen im Kapitel G2.62 Ungeeigneter Umgang mit Sicherheitsvorfällen Zur Erkennung von Sicherheitsvorfällen nutzt die SMMaaS-Architektur mehrere Module. Diese sind das Intrusion Detection System-, Data Leakage Prevention sowie das Logging Modul. Alle diese Module überwachen ständig automatisiert sowohl die Kundeninstanzen als auch die Systeme der CSP. Zusätzlich können noch Informationen durch die Security Monitoring VM's gewonnen werden. Durch die Analyse der gewonnen Daten, in Form von Logles, können Sicherheitsvorfälle erkannt und es kann auf diese reagiert werden. G2.85 Unzureichende Regelungen für das Ende des Outsourcing-Vorhabens Diese Gefahr kann durch SMMaaS nicht komplett gelöst werden, da sie zum groÿen Teil aus vertraglichen Problemen besteht. Allerdings können durch SMMaaS technische Probleme gemildert werden. So sind in SMMaaS Prozesse vorgesehen zum Löschen von Daten bzw. dem Sichern

48 4 SMMaaS Architektur 37 der Daten auf externe Datenträger, welche dem Kunden zugesendet werden. SMMaaS kann bei dieser Gefahr also nur ünterstützen. G2.131 Unzureichende Kontrolle von VPNs Die Zugrie mittels VPN auf das Managment von SMMaaS werden durch das Managment Modul sowie das Rechte- und Rollenmangement organisiert. So können nur Personen welche einen Account im Managment besitzen und die entsprechenden Rechte haben das VPN nutzen. G2.142 Zerstörung von Beweisspuren bei der Behandlung von Sicherheitsvorfällen Zur Beweissicherung bei Sicherheitsvorfällen wird oft empfohlen die Systeme nicht runterzufahren und keine Dateien zu löschen. Eine Funktion die dies sicherstellt ist in SMMaaS vorgesehen. Diese Funktion ist bereits in Kapitel 2.5 in dem Truststufenmodell gezeigt. Anhand dieses Modells soll bei Kunden welche Truststufe Advanced bzw. Premium nutzen automatisiert bzw. auf Veranlassung in Quarantäne verschoben werden. In dieser Quarantänenumgebung wird ein Snapshot des kompletten Systems inkl. Arbeitsspeicher erstellt und die Instanz darf desweiteren mit einem Honeypot kommunizieren. G5.20 Missbrauch von Administratorrechten Es ist vorgesehen dass die Administatoren des CSP keinen direkten Zugri auf die Kundeninstanzen bekommen. Um auf diese zugreifen zu können bedarf es der Autorisierung des Kunden. Der Zugri auf die CSP-Systeme ist ebenfalls stark reglementiert. Des Weiteren werden alle Aktionen eines Administators auf den CSP-Systemen protokolliert, sodas ein Missbrauch im Nachhinein festgestellt werden kann. Gc3 Fehlerhafte Konguration von Sicherheitsgateways durch unterschiedliche Zuständigkeiten SMMaaS kann hier wie bei der Gefahr G2.85 hauptsächlich unterstüzen. So können Regeln für die Sicherheitsgateways über einfach zu bedienendes Frontends generiert werden. Desweiteren können diese generierten Regeln sowie individuelle Regeln auf korrekten Syntax sowie auf die richtige Reihenfolge der Regeln überprüft werden. Bei Fehlern kann der Kunde informiert werden. Gc5 Fehlerhafte Zugrisregelungen auf Daten und Systeme Die Zugriregelung auf Daten und Systeme ist eine sehr wichtige Komponente zur Steigerung der Sicherheit. Dementsprechend ist eine fehlerhafte

49 38 4 SMMaaS Architektur Regelung sehr schädlich. So kann es durch fehlerhafte Regelungen dazu kommen dass Anwender aus der Produktion auf Daten des Managments zugreifen können. SMMaaS unterstüzt bei dieser Gefahr indem ein Rollen und Rechte Managment etabliert wird. Die Administration der Rechte- und Rollenverwaltung ist einfach gehalten, was dies noch unterstützt SMMaaS Architektur erweitern Das SMMaaS-Architekturbild (Abbildung 4.2) hat sich seit dem Erscheinen der SMaaS-Papers [8] mehrfach geändert. Die Änderungen sind jeweils auf Anregung von anderen Wissenschaftlern (Abbildung 4.3) entstanden. Die meisten Änderungen dienten lediglich einem besseren Verständnis bzw. einer besseren Übersichtlichkeit und waren keine inhaltlichen Änderungen. Abbildung 4.3: Übersichtlicheres SMMaaS-Architekturdiagramm Durch die weitere Forschung an dem CloudDataSec Projekt und der SMMaaS- Architektur hat das Cloud Research Lab die Architektur (Abbildung 4.4) mittlerweile strukturell verbessert. Es wurde ein neues Modul Management hinzugefügt. Dieses Modul soll in SMMaaS die einzige direkte Schnittstelle zu dem Kunden sein. Dieser kann über dieses Modul die anderen Module kongurieren und Funktionen der andern Module nutzen. Des Weiteren bekommt er mittels des Management Moduls alle Reports sowie Ereignisse von der kompletten SMMaaS-Umgebung übersichtlich dargestellt. Das Management Modul kann dabei auch komplette Prozessabläufe koordinieren und überwachen, so z.b. die Initalisierung einer SMMaaS-Umgebung für einen Kunden. Neben diesem neu hinzu gekommenen Modul haben sich die Beziehungen zwischen Modulen verän-

50 4 SMMaaS Architektur 39 dert, d.h. es gibt mehr Beziehungen. Des Weiteren wurden die Beziehungspfeile durch Beziehungslinien ersetzt. Dies wurde durch Professoren der Faktultät Informatik angeregt, während der Vorbereitung von Frank Dölitzscher auf die 3rd IEEE International Symposium on Trust, Security and Privacy for Emerging Applications Konferenz, auf welcher unter anderem die SMMaaS-Architektur vorgestellt wurde. Abbildung 4.4: Aktuelles SMMaaS-Architekturdiagramm Neben den Änderungen durch das Cloud Research Lab hat sich im Zuge der Erstellung dieser Arbeit gezeigt, dass ein weiteres Modul bei der SMMaaS- Architektur fehlt: Das Rollen- und Rechtemangement. Diese Meinung wird durch das Buch Cloud Security and Privacy [4, Kapitel Fünf] ebenfalls vertreten. In diesem wird ein rollen- und rechte-basiertes Identitätsmangement gefordert. So wird momentan zwar die Authentizierung des Kunden durch das Management- Modul gewährleistet, jedoch ist keine Möglichkeit vorgesehen, den Zugri zu beschränken. Dies ist insbesondere wichtig da es sehr wahrscheinlich ist dass nicht nur ein Mitarbeiter des Kunden für alle Systeme und Instanzen zuständig ist. Es ist ebenfalls wahrscheinlich dass nicht alle Benutzer Zugri auf alle Komponenten und Managmentfunktionen der Cloud Umgebungen haben sollen. Es ist in den meisten Fällen davon auszugehen, dass ein Nutzer bzw. Administrator auch nur für kleine Teile der gesamten IT-Infrastruktur zuständig ist bzw. darauf Zugri hat. Desweiteren gibt es meist z.b. Beschaungsprozesse welche durch den Einkauf erledigt und durch den IT-Leiter genehmigt werden. Dies lässt sich ebenfalls nicht ohne ein Rollen- und Rechte Managment abbilden. So könnte jeder Nutzer z.b. neue Instanzen starten, was direkt mit neuen Kosten verbunden ist. Das Starten einer Instanz kommt in diesem Moment dem Beschaen eines neuen Servers gleich. Demzufolge könnten ohne ein Rollen- und Rechtemange-

51 40 4 SMMaaS Architektur Abbildung 4.5: erweitertes SMMaaS-Architekturdiagramm ment die intern genutzen Prozesse gestört bzw. unterlaufen werden. Von einer Integration des Rollen- und Rechtemangement in das Managment Modul ist abzuraten, da das Managment Modul als Schnittstelle zwischen dem Kunden und den spezialisierten Modulen von SMMaaS fungiert. Bei einer Integration würde das Managment Modul allerdings selbst zu einem der spezialisierten Module. Um die Rechte innerhalb von SMMaaS umsetzen zu können benötigt jedes Modul eine Autorisierungsfunktion. Die empfohlenden Änderungen sind in Abbildung 4.5 dargestellt. In den folgenden Kapiteln werden einige Module der SMMaaS-Architektur detailierter deniert, die Anforderungen an diese durch den IT-Grundschutzkatalog beschrieben und die Modularchitekturen jeweils einem Review unterzogen. Zunächst wird das Modul Logging im nächsten Kapitel beschrieben Modul: Logging Logging ist eines der wichtigsten Methoden um Angrie und Zugrie auf Systeme verfolgen und analysieren zu können. Deshalb sind Logles ein wichtiger Teil der Beweissicherung nach Angrien auf Systeme. Ebenfalls sind sie ein wichtiges Mittel um die Qualtität von Diensten messen zu können. Nur durch dieses Messen ist überhaupt ein Einhalten der Anforderungen aus einem SLA möglich. Die Probleme beim Logging sollen an einem Beispiel erläutert werden: Bei einem einfachen Standalone Server liegen normalerweise sowohl die Daten des Dienstes als auch die Logles auf ein und dem selben Server. Ein Angreifen kann nun den Server kompromitieren und gleichzeitig seine Spuren verschleiern, indem er die Logles modiziert, so dass sein Angri nicht mehr zu erkennen ist. Eine solche Struktur zeigt Abbildung 4.6.

52 4 SMMaaS Architektur 41 Abbildung 4.6: Direkter Angri auf Server in der Cloud Um dem Problem der Veränderung entgegen zu wirken gibt es die Möglichkeit die Logles zentral auf einen seperaten Server zu schreiben. So halten alle Dienstserver keine Logles mehr lokal vor. Eine Veränderung der Logles ist dadurch nur noch sehr schwer möglich. Um die Logles zu modizieren müsste zusätzlich der zentrale Logserver kompromitiert werden. Allerdings kann dieses durch seine spezielle Aufgabe sehr gut abgesichert und abgeschottet werden. In Abbildung 4.7 wird diese Struktur dargestellt. Allerdings ist auch dies noch kein Allheilmittel gegen die Veränderung, so ist es möglich mittels kompromitieren Server die Kommunikation zu dem zentralen Logserver zu verändern. Dies wird erleichtert, indem die Logdaten normal unverschlüsselt übertragen werden. Desweiteren bringt ein dezentraler Server das Problem der Zeitsynchronisation mit sich. Alle Server müssen die selbe Zeit haben um einen Angri auf mehrere Server in einer chronologisch korrekten Reihenfolge verfolgen zu können. Desweiteren löst ein zentraler Logserver nicht das Problem der Datenintegrität. Es ist weiterhin möglich, dass Logles verändert werden, egal ob beabsichtig oder unbeabsichtigt, ohne dass die Änderungen festgestellt werden können. Ein Teil dieser Probleme können mit den nächsten Modulen gelöst bzw. verringert werden. Im Folgenden werden die Anforderungen an Logging, welche durch den BSI IT- Grundschutz vorgegeben werden, aufgezeigt. Ebenso wird die Modularchitektur detailliert beschrieben und einem Review unterzogen.

53 42 4 SMMaaS Architektur Abbildung 4.7: Angri auf Server in der Cloud mit zentralem Log-Server Anforderungen aus dem BSI IT-Grundschutzkatalog Um das Modul detailliert designen zu können müssen zunächst die Anforderungen deniert werden. Diese leiten sich hauptsächlich von den Gefahren aus dem BSI IT-Grundschutzkatalog ab. Nachfolgend sind die Gefahren aus dem IT- Grundschutzkatalog (siehe Kapitel 3.1) aufgelistet, die sich direkt auf das Modul Logging beziehen. ˆ G2.54 Vertraulichkeitsverlust durch Restinformationen ˆ G2.60 Fehlende oder unzureichende Strategie für das Netz- und Systemmanagement ˆ G2.61 Unberechtigte Sammlung personenbezogener Daten ˆ G2.62 Ungeeigneter Umgang mit Sicherheitsvorfällen ˆ G2.85 Unzureichende Regelungen für das Ende des Outsourcing-Vorhabens ˆ G2.142 Zerstörung von Beweisspuren bei der Behandlung von Sicherheitsvorfällen ˆ G5.20 Missbrauch von Administratorrechten Durch diese Gefahren lassen sich direkt, anhand der Kreuzreferenztabelle (siehe A.2), die Massnahmen, welche für dieses Modul zutreen, ablesen. Die folgenden Massnahmen gelten für das Logging Modul.

54 4 SMMaaS Architektur 43 ˆ M2.8 Vergabe von Zugrisrechten ˆ M2.64 Kontrolle der Protokolldateien ˆ M2.145 Anforderungen an ein Netzmanagement-Tool ˆ M2.146 Sicherer Betrieb eines Netzmanagementsystems ˆ M2.167 Auswahl geeigneter Verfahren zur Löschung oder Vernichtung von Daten ˆ M2.169 Entwickeln einer Systemmanagementstrategie ˆ M2.170 Anforderungen an ein Systemmanagementsystem ˆ M2.307 Geordnete Beendigung eines Outsourcing- Dienstleistungsverhältnisses ˆ M2.422 Umgang mit Änderungsanforderungen ˆ M2.431 Regelung der Vorgehensweise für die Löschung oder Vernichtung von Informationen ˆ M2.432 Richtlinie für die Löschung und Vernichtung von Informationen ˆ M2.433 Überblick über Methoden zur Löschung und Vernichtung von Daten ˆ M2.434 Beschaung geeigneter Geräte zur Löschung oder Vernichtung von Daten ˆ M3.2 Verpichtung der Mitarbeiter auf Einhaltung einschlägiger Gesetze, Vorschriften und Regelungen ˆ M3.10 Auswahl eines vertrauenswürdigen Administrators und Vertreters ˆ M3.33 Sicherheitsüberprüfung von Mitarbeitern ˆ M4.32 Physikalisches Löschen der Datenträger vor und nach Verwendung ˆ M4.64 Verizieren der zu übertragenden Daten vor Weitergabe / Beseitigung von Restinformationen ˆ M4.234 Geregelte Auÿerbetriebnahme von IT-Systemen und Datenträgern ˆ M6.59 Festlegung von Verantwortlichkeiten bei Sicherheitsvorfällen ˆ M6.60 Festlegung von Meldewegen für Sicherheitsvorfälle ˆ M6.66 Nachbereitung von Sicherheitsvorfällen

55 44 4 SMMaaS Architektur ˆ M6.127 Etablierung von Beweissicherungsmaÿnahmen bei Sicherheitsvorfällen ˆ M6.128 Schulung an Beweismittelsicherungswerkzeugen Neben den Anforderungen, welche sich aus den Massnahmen des BSI IT- Grundschutzkatalog ableiten, gibt es noch weitere Anforderungen. Diese ergeben sich durch rechtliche Regelungen wie in [21], [22], [23] und [24] beschrieben. Ebenfalls entstehen durch die SMMaaS-Architektur Anforderungen, insbesondere an die Modularisierung. Aus dem Eckpunktepapier [2] des BSI zur Informationssicherheit in Cloud Computing ergeben sich zusätzlich einige Anforderungen, sodass zusammengefasst die folgenden Anforderungen an das Modul und die Architektur gestellt werden kann. Write-once-read-many Datenspeicher Nach [21] dürfen Logles nur auf sogenannten Write-once-read-many (WORM) Speicher gesichert werden. Diese haben die Eigenschaft, dass Dateien nicht nachträglich verändert werden können, sondern neue Informationen nur an Dateien angehängt bzw. in neue Dateien geschrieben werden. Es können also Daten, wie der Name schon aussagt, nur einmal geschrieben, aber mehrmals gelesen werden. Es gibt spezielle WORM-Speichermedien, welche sehr teuer sind. Unter Linux können EXT-Filesysteme in einen reinen Append-Modus geschaltet werden, dadurch fungieren sie wie WORM- Speicher. Verschlüsselter Datenspeicher Zusätzlich zu der vorherigen Anforderung gibt es noch die Anforderung das der Datenspeicher verschlüsselt sein muss. Diese Anforderung ergibt sich aus [23], desweiteren ist diese Möglichkeit in [8] beschrieben. Durch die Verschlüsselung ergibt sich auch gleichzeitig ein Zugrisschutz auf die Logles. Autorisierung Der Zugri auf die Logles muss geregelt sein, dies hat das BSI im IT- Grundschutzkatalog[25] sowie in dem Eckpunktepapier [2] vorgeschrieben. Ebenso ist dies aus Datenschutzsicht unerlässich, weil Logles oft personenbezogene Informationen enthalten. Ein Zugri auf die Logles durch Administratoren des Cloud-Service-Providers muss daher ebenfalls eingeschränkt werden. Schnittstellen zu anderen Modulen Diese Anforderung ergibt sich aus der modularisierten Struktur von SM- MaaS, wie bereits in Kapitel 4.1 beschrieben.

56 4 SMMaaS Architektur 45 Auswertung von Logereignissen Das Auswerten der Logereignisse ist unerlässlich um Angrie auf Systeme zu erkennen, sowie die Qualitätsmerkmale, welche im SLA festgelegt sind, ermitteln zu können. Diese Anforderung ist sowohl in dem Eckpunktepapier [2], als auch in den Massnahmen des IT-Grundschutzkatalogs [25] deniert. Anonymisierung Anonymisierung ergibt sich aus dem Datenschutz. Da je nach Truststufe und Vertragsverhältnis nicht die Identität des Kunden eindeutig bestimmt ist, wäre es aus Sicht des Datenschutzes unvereinbar dem Kunden personenbezogene Daten zukommen zu lassen. Desweiteren gibt es verschiedene Kunden, die keine Logles erzeugen dürfen, hier insbesondere der öentliche Bereich. Zu Abbrechnungzwecken werden die Daten allerdings eventuell trotzdem benötigt. Eine Anonymisierung der Logles vor der Auswertung kann hierbei Abhilfe schaen. Grasches Aufarbeiten der Logereignisse Diese Anforderung ist in keiner Quelle direkt beschrieben, allerdings dient die Anforderung dazu die durch Logles ermittelten Qualitätskennziern leicht verständlich darzustellen. Ebenfalls können durch diese Anforderung die Logereignisse, für Leute welche keine IT-Experten sind übersichtlich und zusammengefasst dargestellt werden. Sichere Umgebung für den Betrieb Diese Anforderung ist ebenfalls nicht direkt in den Quellen beschrieben, allerdings sieht das Eckpunktepapier [2] gewissen Mindestanforderungen an den Betrieb von Cloud Computing Umgebungen vor. Die Anforderung deniert eine isolierte und abgesicherte Umgebunge, auf welcher die Log- les sowie die Auswertung stattndet. Diese Umgebung sollte nur aus dem internen Netz des Cloud Service Providers erreichbar sein. Verschlüsselte Kommunikation Die Kommunikation zwischen den einzelnen Modulen der SMMaaS- Architektur, sowie die Kommunikation zwischen den Kundeninstanzen und dem zentralen Logserver, muss verschlüsselt stattnden, da anderenfalls das Abhören der Kommunikation als auch ein einfaches Verändern der Kommunikation möglich ist. Durch die Verschlüsselung, insbesondere durch das Signieren der zu übertragenden Daten, kann also die Datenintegrität sichergestellt werden. Desweiteren kann durch die Verschlüsselung auch eine Authentizierung zwischen den einzelnen Komponenten stattnden. Diese Anforderung ist in dem Eckpunktepapier des BSI's deniert [2].

57 46 4 SMMaaS Architektur Timestamp Signatur Eine weitere Anforderung ist das Signieren der Logereignisse mit einem qualiziertem Zeitstempel. Diese Anforderung wird in [21] sowie in [9] beschrieben. Durch diese Anforderung kann die Datenintegrität der Logereignisse sichergestellt werden, da durch die Signatur eine Veränderung leicht feststellbar ist. Desweiteren ist eine Identikation der Instanz von der ein Logereigniss kommt eindeutig zu identizieren. Durch das Hinzufügen eines qualizierten Zeitstempels vor dem Signieren ist der Zeitpunkt des Logereigniss eindeutig. Durch diese Zeitstempel kann zuverlässig ein zeitlicher Ablauf von Logereignissen hergestellt werden. Mandantenfähigkeit Mandatenfähigkeit ist eines der wichtigsten Anforderungen, welche direkt durch Cloud Computing entstehen. Nur durch diese Eigenschaft ist eine klare Trennung der Logdaten zwischen den Kunden gewährleistet. Die Anforderung meint, das die Systeme so konzipiert sind, dass auf einem System mehere Kunden komplett voneinander getrennt aggieren können. Eine Software, die dieses Konzept umsetzt, ist z.b. SAP Netweaver. Diese Anforderung ist in den meisten Papers sowie Veröentlichungen zu Cloud Computing zu nden, so z.b. in dem BSI Eckpunktepapier [2] und dem SMMaaS-Paper [8]. Im folgenden Abschnitt werden detailliert alle Bausteine erklärt, aus welcher das Modul Logging der SMMaaS-Architektur bestehen sollen Architekturdesign Anhand der Anforderung ergeben sich ein Reihe von Bausteinen für das Modul Logging. Diese wird in einer Layerarchitektur (Abbildung 4.8) dargestellt. Wobei der oberste Layer Bausteine darstellt, welche mit anderen Modulen aggieren. Die Bausteine auf dem untersten Layer sind techniknahe Bausteine, sie entsprechen meist realen IT-Komponenten, wie z.b. ein Storagesystem oder einer speziellen VM. Die Bausteine, die gleichnamig ebenfalls als Modul in der SMMaaS-Architektur vorkommen, sind in der Regel Schnittstellen zu den entsprechenden Modulen. Manche dieser Bausteine verarbeiten die Daten teilweise und bereiten sie für die Kommunikation mit den entsprechenden Modulen vor. Die Bausteine werden im Folgenden nur aufgelistet und später in diesem Kapitel noch detailliert erklärt. ˆ Storage-Modul

58 4 SMMaaS Architektur 47 ˆ Authorisierung ˆ PKI-Modul ˆ Logereignis-Analysator ˆ Generator von Störmeldungen ˆ Policy-Modul ˆ Ereignisempfänger ˆ Daten-Anonymisierer ˆ Grascher Logereignis-Analysator ˆ Logging Virtual Maschine ˆ Datenverschlüsselung Abbildung 4.8 zeigt, wie bereits erwähnt, das Architekturdiagramm des Modul Logging. Die Gröÿe der Bausteine in der Darstellung steht dabei in keinem Zusammenhang mit dem Funktionsumfang eines Bausteins. Die Bausteine Policy, PKI und Datenverschlüsselung nutzen die Schnittstellen zu den entsprechenden Modulen. Der Baustein zur Kommunikationsverschlüsslung ist keine Schnittstelle für das Krypto-Module sondern es ist ein eigenständiger Baustein. Abbildung 4.8: Architekturdiagramm für das Logging-Modul Im Folgenden werden die einzelnen Bausteine detailliert beschrieben: Storage-Baustein Der Storage-Baustein hat die Aufgabe die Logles persistent zu speichern. Der Speicherbereich für die Logles soll als WORM-Speicher realisiert werden. In welcher Form der Storage realisiert ist muss für den Baustein transparent sein. Es ist also egal, ob der Storage in Form eines Distributed File

59 48 4 SMMaaS Architektur System (DFS), wie z.b. Lustre, oder als Storage Area Network (SAN) oder auch in Form einer Datenbank, realisiert ist. Das Storage-Modul, welches hinter dem Baustein steht kann die Daten ebenfalls verschlüsselt abspeichern, sofern es für den Baustein transparent ist. Die Verschlüsselung der Daten in dem Storage-Modul ist keine zwingende Anforderung. Das Logging- Modul selbst verschlüsselt durch den Datenverschlüsselungs-Baustein die Logdaten, bevor diese an den Storage-Baustein weitergeleitet werden. Autorisierung Der Autorisierungs-Baustein dient dazu den Benutzern, welche bereits durch das Management-Modul identiziert und authentiziert wurden, entsprechende Zugrisrechte auf das Logging-Modul zu ermöglichen. Die Rechte der Benuters werden in der Rollen- und Rechteverwaltung der SM- MaaS-Architektur deniert. Ebenfalls genehmigt dieser Baustein die Zugrie, welche von anderen System bzw. Instanzen kommen. Hierdurch wird auch sichergestellt das nur die Instanzen des Kunden auf den Logserver des Kunden Logereignisse schreiben können. PKI-Baustein Der PKI-Baustein ist wie bereits beschrieben eine Schnittstelle zu dem PKI-Modul. Mit Hilfe dieses Bausteins werden die Logereignisse mit einem Timestamp sowie einer Signatur versehen. Es zeigt sich, dass dieser Baustein eine hohe Netzwerklast erzeugen wird. Da die Logereignisse zuerst an das PKI-Modul gesendet und anschlieÿend wieder von diesem empfangen werden müssen. Ebenfalls ermöglicht dieser Baustein den Zugri auf die Zertikate, welche das PKI-Modul vorhält. Diese werden z.b. für die Kommunikationsverschlüsselung benötigt. Der Baustein bietet andere Bausteine mehrere Schnittstellen an, so z.b. für das Signieren von Logereignissen oder dem Abrufen von Zertikaten. Logereignis-Analysator Der Logereignis-Analysator analysiert Logereignisse, die anhand von Regeln, welche durch den Policy-Baustein vorgegeben werden, deniert sind. Desweiteren werden die Logereignisse zusammengefasst und korreliert. Es werden zusätzlich in diesem Baustein anhand der Logereignisse Messwerte ermittelt, welche für das SLA-Management sowie zu Abbrechnungzwecken verwendet werden können. Damit die Ergebnisse durch die anderen Module und Bausteine weiterverarbeitet werden können, werden sie in einer generischen strukturierten Datenstruktur, wie z.b. XML, gesichtert und weitergeleitet. Die Daten werden z.b. an den Störungsmeldungsgenerator sowie den graschen Logereignis-Analysator weitergeleitet. Der Analysator

60 4 SMMaaS Architektur 49 bietet eine Schnittstelle für den Ereignisempfänger an. Die Daten werden im Logging-Modul direkt verabeitet um die Netzwerklast zu anderen Modulen geringer zu halten. Auÿerdem lässt sich so der Zugri auf die Logles besser regelmentieren und die Logles besser absichern. Generator von Störmeldungen Der Störungsmeldungsgenerator ermittelt anhand der Ergebnisse des Logereignis-Analysator, ob gegen Regeln aus dem Policy-Baustein verstoÿen wird. Wenn dies der Fall ist werden Nachrichten an das Management- Modul versendet, sowie je nach Konguration auch Alarmierungen per E- Mail versandt. Der Generator bietet daher selbst eine Schnittstelle für den Logereignis-Analysator an. Desweiteren nutzt der Baustein Schnittstellen des Management-Moduls sowie des Policy-Baustein. Policy-Baustein Der Policy-Baustein ist für die Analyseregeln der Analysatoren des Logging- Modules zuständig. Er bietet eine Schnittstelle für Management von SM- MaaS. Die Regeln, welche in dem Mangement-Modul deniert sind, werden von dem Baustein vereinheitlicht und normiert. Die Regeln werden dann Analysatoren sowie dem Störungsmeldungsgenerator zur Verfügung gestellt. In welcher Form die Regeln abgesichert werden ist nicht festgelegt, sie muss aber für das ganze Module einheitlich implementiert werden. Verwendung von Complex Event Processing (CEP)-Framework ist hier als sinnvoll zu erachten um auch verteilte Angrie erkennen zu können. Ereignisempfänger Dieser Baustein entspricht einem Log-Daemon. Er bietet die Schnittstelle zum Empfangen der Logereignisse an. Zusammen mit dem Autorisierungs- Baustein ltert dieser Baustein ebenfalls, dass nur Logereignisse von Instanzen angenommen werden, für welche die Instanz des Logging-Moduls zuständig ist. Ebenfalls arbeit der Baustein mit dem Kommunikationsverschlüsselungs-Baustein zusammen, damit die Logereignisse auch verschlüsselt empfangen werden können. Das Empfangen von unverschlüsselten Logereignissen sollte nicht zugelassen werden. Nach dem Empfangen normalisiert der Baustein die Logereignisse und reicht sie an den PKI-Baustein weiter, damit die Logereignisse mit einem Zeitstempel und einer Signatur versehen werden können. Eventuell müssen die Logereignisse vorher noch an den Daten-Anonmysierer weitergereicht um die Logereignisse zu anonymisieren. Daten-Anonymisierer

61 50 4 SMMaaS Architektur Dieser Baustein ist für das Anonymisieren von den Logereignissen zuständig. Der Baustein kann z.b. die IP-Adressen oder die Nutzernamen aus den Logereignissen entfernen. Dies ist wie bereits beschrieben nicht immer notwendig. Ob die Daten anonymisiert werden müssen entscheidet das Management-Modul. Damit die Logereignisse anonymisiert werden können, bietet der Daten-Anonymisierer Schnittstellen für den Bausteinen Ereignisempfänger an. Grascher Logereignis-Analysator Der grasche Logereignis-Analysator wertet die zusammengefassten Ergebnisse des Logereignis-Analysator aus. Die Daten werden weiter zusammengefasst, so dass sie grasch aufbereitet werden können. Der Kunde kann vorher mittels des Management-Moduls festlegen, welche Informationen ihm im Management Interface dargestellt werden soll. Damit die Daten dann nach Kundenwünschen grasch aufbereitet werden könne, müssen die entsprechenden Informationen von dem Policy-Baustein angefragt werden. Die Informationen können in Diagrammen dargestellt werden. Diese Graken und Diagramme werden dann an das Management-Modul versendet, damit der Kunde diese anschauen kann. Der Baustein selbst bietet eine Schnittstelle für den Logereignis-Analysator an und nutzt einige anderen Schnittstellen. Logging Virtual Maschine Das Logging-Modul soll als spezielle VM realisiert werden. Es bendet sich in einer Subcloud des CSP, welche nur für Mangementzwecke genutzt wird. Die VM muss besonders abgesichert sein, diea beinhaltet nicht nur ein gehärtetes System sondern auch eine Abschottung von der restlichen Cloud- Umgebung. Dies kann durch eine restriktive kongurierte Firewall sowie durch den Einsatz eines privaten Managementnetzwerkes passieren. Die Logging-VM enthält dabei die ersten drei Layer des Modules. Die Logles sowie die Kongurationsdateien werden persistent auf einem Storagesystem gesichert. Hierdurch kann die Logging-VM im Falle eines Defekts am Host- System innerhalb kurzer Zeit, durch Starten einer neuen Instanz, wieder mit allen Daten verfügbar sein. Ebenfalls ist es hierdurch leichter möglich die Logging-VM's zu patchen bzw. zu verändern. Datenverschlüsselung Der Baustein Datenverschlüsselung dient der Ver- und Entschlüsselung der Logles bevor sie an den Storage-Baustein weitergegeben werden. Es ist somit neben dem Storage-Baustein der zentrale Baustein für den Zugri auf die Logles. Es werden Schnittstellen für mehrere andere Bausteine des

62 4 SMMaaS Architektur 51 Moduls angeboten. Die Schlüssel, welche der Baustein für die Verschlüsselung nutzen soll, werden von dem Kryptograe-Modul angefragt. Es werden dabei zur besseren Perfomance symmetrische Algorithmen verwendet. Im folgenden Abschnitt wird das Architekturdesign des Modules nochmal einem Review unterzogen und überprüft, ob alle Anforderungen erfüllt wurden Architekturreview Die Architektur deckt alle Anforderungen an das Modul ab. So ist der Einsatz von WORM-Speichern vorgesehen, allerdings kann dieser nicht direkt im Logging-Modul realisiert werden, sondern muss im Storage-Modul verlagert werden. Die Anforderung an einen verschlüsselten Datenspeicher wird durch den Datenverschlüsselungs-Baustein abgedeckt, wobei die tatsächliche Umsetzung nicht im Logging-Modul, sondern im Krypto-Modul stattndet. Die Autorisierung wird direkt durch den Baustein Autorisierung übernommen, jedoch dieser Baustein nur die Autorisierung des Logging-Moduls realisiert. Es werden, wie bereits in Kapitel erwähnt, mehrere Schnittstellen von anderen Bausteinen und Modulen verwendet. Ebenso bieten eine Reihe von Bausteinen Schnittstellen für andere Baustein und Module an. Die Modularisierung, welche im SMMaaS-Paper gefordert wird, ist dadurch ebenfalls sichergestellt. Eine Auswertung von Logereignissen und Logles, welches eine der Kernfunktionen des Logging-Moduls ist, ist durch mehrere Bausteine realisiert. Diese sind der Logereignissen-Analysator, der grasche Logereignissen-Analysator sowie der Generator von Störmeldungen. Alle drei werden dabei direkt durch den Policy Baustein unterstüzt. Das Anonymisieren von Logdaten ist ebenfalls durch den Daten-Anonymisierer-Baustein vorgesehen. Eine weitere Anforderung war die sichere Kommunikation zwischen Modulen, hierfür wurde extra der Baustein Kommunikationverschlüsselung etabliert. Dieser Baustein ist direkt für die Kommunikationsverschlüsselung zuständig und nutzt nicht das Krypto-Modul. Sie hat den Vorteil, dass die Netzwerklast sowie die Last des Kryptograe-Moduls erheblich reduziert wird. Das Signieren von Logereignissen sowie das Versehen der Ereignisse mit einem qualizierten Zeitstempel ist durch den PKI-Baustein sichergestellt. Die Mandatenfähigkeit sowie der Betrieb einer sicheren Umgebung für das Logging-Modul sind gemeinsam durch den Logging-VM-Baustein abgedeckt. So sind die Logging-VM's in einer stark abgesicherten und isolierten Umgebung innerhalb des Netzes des Cloud Service Providers angesiedelt. Desweitern ist es vorgesehen, dass jeder Kunde ab einer entsprechenden Truststufe eine eigene Logging-VM bekommt. Zusätzlich betreibt der Cloud Server Provider noch ein eigenes Loggingsystem. Wie sich zeigt, deckt das Logging-Modul die meis-

63 52 4 SMMaaS Architektur ten Anforderungen aus dem BSI IT-Grundschutzkatalog allerdings nicht alle ab. Insbesondere die Anforderungen, welche sich aus dem Massnahmenkatalog M2 Organisation herleiten, können nicht komplett technisch gelöst werden. Massnahmen wie z.b. M2.431 Regelung der Vorgehensweise für die Löschung oder Vernichtung von Informationen müssen durch eine Anpassung in der Orgnisationsstruktur und den Geschäftabläufen realisiert werden. Bevor das Modul implementiert werden kann müssen die Schnittstellen sowie die Datenformate festgelegt werden. Ebenfalls sollten die Prozesse und Abläufe vor der Implementierung festgelegt und festgehalten werden. Im folgenden Kapitel wird das Modul PKI sowie deren Architektur und Anforderungen näher betrachtet Modul: Customer PKI PKI ist ein wichtiges Element zur Erstellung und Verwaltung von Zertikaten. Zertikate spielt in Cloud Computing eine wichtige Rolle, so dienen sie zur Authentizierung von Personen gegenüber dem Managementsystem. Desweiteren können diese Zertikate mit ihren asymmetrischen Schlüsselpaaren zur Verschlüsselung der Kommunikation zwischen den einzelnen Systemen dienen. Die Vorteile einer PKI soll im Folgenden an dem Beispiel von Kapitel 4.4 erklärt werden, hierzu wird das Beispiel nochmals aufgegrien und weitergeführt: Abbildung 4.9: Angri auf Server in der Cloud mit zentralem Log-Server und PKI, Kommunikationverschlüsselung

64 4 SMMaaS Architektur 53 Nun kennt man die Vorteile von dem zentralen Log-Server, wodurch sich schon weniger Problem ergeben. Durch eine PKI lassen sich die Probleme, welche noch bei dem Logging bestehen, lösen. Man stellt nun die Cloud-Umgebung noch eine PKI zur Seite wie in Abbildung 4.9 zu sehen ist. Diese ist ebenfalls komplett nach auÿen abgeschottet und ist besonders abgesichert. So kann nun feststellen werden ob gespeicherte Logdaten verändert wurden, indem den Logdaten ein Signatur anhängen wird. Wenn es also ein Angreifer dennoch schat die Logdaten zu verändern, kann das System dies feststellen und den Nutzer informieren. Doch die PKI bringt noch mehr Vorteile. So muss eine PKI eine sichere Zeitquelle besitzen damit sie auch qualizierte Zeitstempel erstellen kann. Dadurch, das man nun alle Logdaten direkt bei dem Eintreen mit einem Zeitstempel versehen und die Daten signieren lässt, haben die Logdaten immer die richtige Zeit. Eine Zeitsychronisation der Server ist nicht mehr dringend notwendig, allerdings immer noch wünschenswert. Doch es gibt ein weiteres Problem, das die Kommunikation abgehört und verändert werden kann. Auch dabei hilft eine PKI, denn mittels der Schlüsselpaaren, die die PKI verteilt, kann man die Kommunikation zwischen den Instanzen und dem Logserver verschlüsseln. Ein Angreifer kann zwar die Kommunikation mithören, aber er kann keine Informationen daraus gewinnen. Ebenso wenig kann der Angreifer die Kommunikation verändern, denn die veränderten Daten müsste er zunächst mit dem Originalschlüssel neu verschlüsseln und er müsste wissen, an welcher Stelle in dem Datenstrom er die neuen Informationen einpegen muss. Spätestens die zweite Information, also die Position in dem Datenstrom, kann der Angreifen nicht feststellen. Doch weiterhin existiert eine Problem, denn ein Angreifer, welcher in den Logserver eindringt, kann die Logdaten lesen und eventuell Informationen wie Kundenname etc. daraus ableiten. Dies kann momentan noch nicht sinnvoll gelöst werden. Im folgenden Abschnitt werden die Anforderungen, insbesondere diese, welche sich aus dem IT-Grundschutzkatalog ergeben, an eine PKI beschrieben Anforderungen aus dem BSI IT-Grundschutzkatalog Wie bereits in Kapitel beschrieben werden die Anforderungen an das Modul in diesem Abschnitt beschrieben. Neben den Anforderungen, welche sich durch den BSI IT-Grundschutzkatalog ergeben, gelten hier ebenfalls Anforderungen aus dem deutschen Signaturgesetz [12]. Natürlich ergeben sich auch Anforderungen aus der Architektur von SMMaaS. Im Folgenden werden die Gefahren aus dem IT-Grundschutzkatalog (Beschreibung siehe Kapitel 3.1), welche sich direkt auf das Modul PKI beziehen, aufgelistet. ˆ G1.15 Beeinträchtigung durch wechselnde Einsatzumgebung

65 54 4 SMMaaS Architektur ˆ G2.19 Unzureichendes Schlüsselmanagement bei Verschlüsselung ˆ G2.54 Vertraulichkeitsverlust durch Restinformationen ˆ G2.62 Ungeeigneter Umgang mit Sicherheitsvorfällen ˆ G2.85 Unzureichende Regelungen für das Ende des Outsourcing-Vorhabens ˆ G2.142 Zerstörung von Beweisspuren bei der Behandlung von Sicherheitsvorfällen Die folgenden Massnahmen vermindern bzw. lösen die oben aufgelisteten Gefahren. Sie ergeben sich anhand der erstellten Kreuzreferenztabellen (siehe A.2), wobei die Massnahmen, die sich nicht direkt auf das Modul beziehen, weggelassen sind. ˆ M2.1 Festlegung von Verantwortlichkeiten und Regelungen ˆ M2.12 Betreuung und Beratung von IT-Benutzern ˆ M2.46 Geeignetes Schlüsselmanagement ˆ M2.164 Auswahl eines geeigneten kryptographischen Verfahrens ˆ M2.165 Auswahl eines geeigneten kryptographischen Produktes ˆ M2.307 Geordnete Beendigung eines Outsourcing- Dienstleistungsverhältnisses ˆ M4.64 Verizieren der zu übertragenden Daten vor Weitergabe / Beseitigung von Restinformationen ˆ M4.234 Geregelte Auÿerbetriebnahme von IT-Systemen und Datenträgern ˆ M6.23 Verhaltensregeln bei Auftreten von Schadprogrammen ˆ M6.59 Festlegung von Verantwortlichkeiten bei Sicherheitsvorfällen ˆ M6.60 Festlegung von Meldewegen für Sicherheitsvorfälle ˆ M6.66 Nachbereitung von Sicherheitsvorfällen ˆ M6.127 Etablierung von Beweissicherungsmaÿnahmen bei Sicherheitsvorfällen Es gibt, wie bereits erwähnt, nicht nur Anforderungen, welche sich direkt durch den IT-Grundschutzkatalog ergeben, sondern auch gesetzliche und architektonische Anforderungen. Insbesondere die Anforderungen bzw. Einschränkungen, die das deutsche Signaturgesetz [12] mit einbringen müssen, beachtet werden.

66 4 SMMaaS Architektur 55 True Random Number Generator Zufallszahlen werden in vielen Bereichen der Kryptograe genutzt, so z.b. als Initialvektor oder bei dem Die-Hellmann-Alghorithmus. Deshalb haben alle Betriebssysteme Zufallszahlengeneratoren implementiert. Ein Computer kann allerdings keine echten Zufallszahlen erzeugen. Alle Zufallszahlen beruhen auf Algorithmen, deshalb ist es möglich Zufallszahlen vorherzusagen und damit teilweise auch die kryptograschen Algorithmen zu brechen, die diese verwenden. Daher werden die Zufallszahlengeneratoren in einem Computer immer als Pseudo Random Number Generator (PRNG) bezeicht. Da bei Cloud Computing an sehr vielen Stellen Kryptograe verwendet wird, ist ein echter Zufallszahlengenerator zu bevorzugen. Dieser ist in der Regel durch entsprechende zusätzliche Komponenten, welche meist mittels einem physikalischen Zufall Zufallszahlen erzeuge, realisiert. Diese sogenannten True Random Number Generator (TRNG) können mittlerweile mehrere MB/s an Zufallszahlen erzeugen, so dass wenige dieser Komponenten für ein Einsatz in einer Cloud Computing Umgebung genügen. Ein Einsatz dieser Komponenten wurde bereits im Paper [9] erklärt. Die Massnahmen M2.164, M2.165 des IT-Grundschutzkatalog beschreibt nicht direkt den Einsatz von TRNG. Allerdings können die Massnahmen entsprechend verstanden werden. Sicherer Speicher für die Zertikate Die Zertikate, insbesondere das Wurzelzertikat, müssen abgesichert und persistent gespeichert werden. Durch den Verlust bzw. die Kompromittierung des Wurzelzertikat wird es notwendig die CA mit dem Wurzelzertikat und allen ausgestellten Zertikaten zurückzurufen und anschlieÿend komplett neu auszurollen. Sie beinhaltet einen groÿen personellen und zeitlichen Aufwand. Desweiteren ist es nicht so einfach möglich Zertikate in den Kundeninstanzen ohne das Wissen und das Einverständnis des Kunden auszutauschen. Ein verschlüsseltes abspeichern der Zertikate ist daher dringend zu empfehlen um sie vor dem ungewollten Zugri zu schützen. Diese Anforderung wird im Signaturgesetz [12, Ÿ5 Abs. 4] deniert und kann daher nicht vernachlässigt werden. Autorisierung für die Nutzung der PKI Ebenso wie bei dem Logging-Modul soll auch bei der PKI eine Autorisierung stattnden. Dies ist hier besonders wichtig, da auf die einzelnen Bereiche nur wenige bzw. überhaupt keine Personen zugreifen sollen. Der Zugri auf die CA sowie die RA darf nicht durch natürliche Personen stattnden, sondern ausschlieÿlich automatisiert.

67 56 4 SMMaaS Architektur Sichere Umgebung für die PKI Eine sichere Umgebung ist für dieses Modul ebenso wichtig wie für das Logging-Modul. Die Notwendigkeit, dass das PKI-Modul in einer sicheren Umgebung läuft, zeigt bereits die Anforderung sicherer Speicher für die Zertikate. Nutzung von sicheren Algorithmen Diese Anforderung ist direkt durch den IT-Grundschutzkatalog [25] abgedeckt. Die Anforderung ndet sich direkt in der Massnahme M2.164 wieder. Ebenso verlangt das Signaturgesetz [12, Ÿ5 Abs.5] die Verwendung von zuverlässigen Produkten. Dies kann nur durch den Einsatz von sicheren Algorithmen ermöglicht werden. Es ist allerdings neben der allgemeinen Sicherheit der Algorithmen auch auf die verwendte Schlüssellänge zu achten. Da z.b. die Zertikate teilweise sehr lange Laufzeiten haben kann es durch neue Angrismethoden auf kryptographische Algorithmen sowie die weitere massiv steigende Rechenleistung dazu kommen, dass Algorithmen mit kurzen Schlüsselen als unsicher gelten. Da viele Algorithmen mit verschieden langen Schlüsseln umgehen können, sollen z.b. für Zertikate eher lange Schlüssel verwendet werden. Sichere Kommunikation Im Modul PKI ist die Verschlüsselung ebenso wie bei dem Modul Logging sehr wichtig. Da in diesem Modul auch private Schlüssel zu anderen Instanzen und Modulen versendet werden, ist eine Kommunikationsverschlüsselung unerlässig. Falls dies nicht gegeben ist kann es unter Umständen dazu kommen, dass die Kommunikation abgehört wird und damit ebenfalls kompromitiert wird. Sichere Zeitquelle Eine sichere Zeitquelle ist eine grundlegende Vorrausetzung um qualizierte Zeitstempel erstellen zu können. Da wie bei dem Modul Logging bereits erwähnt alle Logereignisse mit einem Zeitstempel versehen werden, muss diese Anforderung sichergestellt werden. Die Anforderung kann durch entsprechende externe Zeitquelle realisiert werden. Die Anforderung an zuverlässige Zeitquellen entspricht dem Signaturgesetz [12, Ÿ9] um qualizierte Zeitstempel erstellen zu können. Signaturerstellung Wie bereits in der Modularchitektur von dem Module Logging erwähnt muss das Modul PKI Signaturen erstellen können. Diese Signaturen dienen der Identizierung sowie der Datenintegrität. Diese Anforderung ergibt sich

68 4 SMMaaS Architektur 57 aus der Architektur von SMMaaS, sowie allgemein in der Verwendung von Zertikaten, die jeweils mit einer Signatur unterschrieben sind. Lange Laufzeit der Zertikate Diese Anforderung bezieht sich insbesondere auf das Wurzelzertikat. Ein Wechsel dieses Zertikats ist sehr aufwendig und oft problematisch. Für das Managementsystem ist es ebenfalls sinnvoll, da ein Austauschen der Zertikate in allen Modulen und den Instanzen ebenfalls sehr aufwendig ist und die Zusammenarbeit mit den Kunden bedarf. Verwalten von Sub-CA mit Einschränkung auf einen X.500 Teilbaum Dies ist eine Anforderung, welche nach dem Paper [9] nicht auf alle Kunden zutreen muss. Der Cloud Service Provider betreibt selbst eine CA um Zertikate für eigene Systeme und Personen auszustellen. Eine zusätzliche Idee hinter dieser Anforderung ist, dass Kunden, welche nicht die niedrigste Truststufe wählen, eine eigene Sub-CA von der Provider CA bekommen. So kann der Provider bei Beendigung der Verträge das Sub-CA-Zertikat zurückrufen, wodurch gleichzeitig alle von der Sub-CA signierten Zertikate ungültig werden. Desweiteren hat der Kunde eine bessere Kontrolle über seine Zertikate und dadurch einen sicherern Zugri auf Systeme, da die Systeme so bei der Initalisierung so konguriert werden, dass die Sub-CA des Kunden mit in die Zertikatskette aufgenommen wird. Die Nutzung von Zertikaten, die nicht von der Sub-CA kommen, schlagen somit wegen fehlerhaften Zertikatsketten fehl. Für Kunden, welche die niedrigste Truststufe wählen und von daher nur Testsysteme betreiben bzw. Systeme, welche keine Sicherheitsanforderungen haben, werden alle Zertikate direkt von der CA der Providers ausgestellt. Dadurch ist nicht die vorher beschriebene Sicherheit gewährleistet, allerdings kann auch hierbei der Provider alle Zertikate nach der Vertragsbeendigung zurückrufen. Austauschen von Zertikaten und Sub-CA's Der Austausch ist wie bereits beschrieben mit einem hohem Aufwand verbunden. Denoch kann der Fall auftretten, wenn z.b. das Wurzelzertikat kompromittiert wird. Daher muss das Modul PKI diesen Fall abdecken. Diese Anforderung ist eine allgemeine Anforderung an eine PKI. Bei Cloud Computing muss allerdings der Cloud Service Provider in Zusammenarbeit mit den Kunden den Austausch vornehmen. Erstellen, Erneuern und Verteilen von CRL's Die Verwaltung von Rückruisten ist ebenfalls eine allgemeine Anforderung an eine PKI. Zusätzlich ist das Sperren von Zertikaten eine Anforderung

69 58 4 SMMaaS Architektur des Signaturgesetzes [12, Ÿ8]. Es müssen die CRL's erstellt und vor allem veröentlicht werden. Es können hier auch andere Technologien verwendet werden durch die die Sperrung von Zertikaten veröentlicht wird. Schnittstellen für Logging und Krpyto-Module sowie dem Cloud-Management Schnittstellen zu anderen Bausteinen und Modulen sind notwendig um eine modulare Architektur sicherzustellen. Diese Anforderung beruht auf der Architektur von SMMaaS [8]. Das Signaturgesetz bringt, wie die Auistung zeigt, eine Reihe von Anforderungen mit sich. Wenn der Cloud Service Provider eine oziell akkreditierte PKI betreiben will, also als Zertizierungsdiensteanbieter auftritt, gelten eine Reihe weiterer Anforderungen, wie z.b. bauliche Massnahmen, Haftung, sowie das treen einer Deckungsvorsorge für Schäden. Wenn die PKI allerdings nur für den internen Betrieb der Cloud genutzt wird, tritt der Cloud Service Provider nicht als Zertizierungsdiensteanbieter auf. Dies ist ebenso der Fall, da das Geschäftmodell des Cloud Service Providers nicht das Verkaufen von Zertikaten ist. Im folgenden Abschnitt wird die Architektur und die einzelnen Bausteine des PKI-Moduls detailliert beschrieben Architekturdesign Der grundsätzliche Aufbau des Architekturdiagramms (Abbildung 4.10) ist der selbe wie der des Logging-Moduls in Kapitel Allerdings ist der Zertikatsmanagement-Baustein in diesem Modul keine Schnittstelle zu anderen Modulen, sondern ist ein eigenständiger Baustein, welcher Schnittstellen für andere Module zur Verfügung stellt. Die untersten Layer sind wie bei dem Modul Logging technische Komponenten. Das Modul beinhaltet Bausteine, welche in ähnlicher Art und Weise im nächsten Modul Krypto-Modul auftreten werden. Die Bausteine unterscheiden sich hierbei in erster Linie darin das bei dem PKI- Modul nur asymmetrische Kryptoalgorithmen genutzen werden. Dem steht das Krypto-Modul gegenüber, das nur symmetrische Kryptoalgorithmen verwendet. Die Bausteine bauen auf den Anforderungen des voherigen Kapitels auf und werden im Folgenden detailliert erklärt: Storage-Baustein Der Storage-Baustein hat die selben Anforderungen und den Aufbau wie bereits im Kapitel erkärt. Allerdings wird in diesem Modul kein WORM-Speicher gefordert. Bei diesem Baustein steht die Verfügbarkeit und die Datensicherheit im Vordergrund, weshalb eine zusätzliche Sicherung

70 4 SMMaaS Architektur 59 Abbildung 4.10: Architekturdiagramm für das PKI-Modul der Daten wünschenswert ist. Eine zusätzliche Verschlüsselung auf Storageebene dringend notwendig. Eine Sicherung der Daten darf ebenfalls nur verschlüsselt stattnden. Datenverschlüsselungs-Baustein Der Datenverschlüsselungs-Baustein hat die selbe Aufgabe wie bei dem Module Logging. Die Nutzung ist ebenfalls die selbe. Autorisierungs-Modul Der Autorisierungs-Baustein hat ebenfalls die selben Aufgaben wie bei dem Modul Logging, jedoch sind die Autorisierungsmöglichkeiten in diesem Modul weitreichender. So regelt der Baustein nicht nur den Zugri auf Zertikate sondern regelt auch, welche Instanz bzw. Person überhaupt Zerti- kate beantragen darf. Der Baustein übernimmt also zusammen mit dem Management-Modul von SMMaaS die Aufgabe einer RA. Zeit-Baustein Der Zeit-Baustein sorgt dafür, dass das PKI-Modul immer eine zuverlässige Zeit hat. Dies kann mittels Network Time Protocol (NTP) aber auch über Funk (DCF77) passieren. Wobei die letze Methode problematisch sein kann, denn zum einem muss das Funksignal im Rechenzentrum empfangen werden können und zum anderen muss das Empfangsgerät durch die Virtualisierungschicht an die VM's weitergeleitet werden. Dieser Baustein ist auch dafür zuständig den anderen Bausteinen und Modulen die Zeit vorzugeben, dafür besitzt der Baustein eine Schnittstelle. Dieser Baustein wird benötigt um z.b. Logereignisse mit einem Zeitstempel zu versehen. Hash-Baustein Der Baustein dient dem Berechnen der Hashes von Daten. Hierzu muss der Baustein eine Schnittstelle zum Empfangen der Daten anbieten. Welche