Anwendbarkeit von BSI IT-Grundschutz Standards auf Cloud ...

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 10
55546 Pfaen-Schwabenheim

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 http://creativecommons.org/licenses/by/3.0/ oder wenden Sie sich brieich
an Creative Commons, 444 Castro Street, Suite 900, Mountain View, California,
94041, USA.

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.

II
Inhaltsverzeichnis
Inhaltsverzeichnis
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Inhaltsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tabellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Abkürzungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I
II
IV
V
VI
1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Einordnung in bestehende Architekturen . . . . . . . . . . . . . . 1
1.3 verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Kryptographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Symmetrische Kryptograe . . . . . . . . . . . . . . . . . . 6
2.2.2 Asymmetrische Kryptograe . . . . . . . . . . . . . . . . . 6
2.2.3 Hash Verfahren . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.4 Digitale Signatur . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.5 Hybride Verfahren . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Public Key Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 digitale Zertikate . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 Certication Authority . . . . . . . . . . . . . . . . . . . . 10
2.3.3 Registration Authority . . . . . . . . . . . . . . . . . . . . 10
2.3.4 Sperrlisten & Validation Authority . . . . . . . . . . . . . 11
2.4 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Truststufenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.6 BSI IT-Grundschutz . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Analyse BSI IT-Grundschutz . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Gefahren für die Cloud nach IT-Grundschutzkatalog . . . . . . . . 17
3.1.1 Vorhandene Gefahren . . . . . . . . . . . . . . . . . . . . . 17
3.1.2 Gefahren aus Bausteinentwürfen . . . . . . . . . . . . . . . 27
3.1.3 Neue Gefahren . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Zusammenarbeit mit dem BSI . . . . . . . . . . . . . . . . . . . . 31
4 SMMaaS Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Inhaltsverzeichnis
III
4.1 SMMaaS Architektur . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Anwendbarkeit von IT-Grundschutz Maÿnahmen auf SMMaaS . . 35
4.3 SMMaaS Architektur erweitern . . . . . . . . . . . . . . . . . . . 38
4.4 Modul: Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4.1 Anforderungen aus dem BSI IT-Grundschutzkatalog . . . . 42
4.4.2 Architekturdesign . . . . . . . . . . . . . . . . . . . . . . . 46
4.4.3 Architekturreview . . . . . . . . . . . . . . . . . . . . . . . 51
4.5 Modul: Customer PKI . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5.1 Anforderungen aus dem BSI IT-Grundschutzkatalog . . . . 53
4.5.2 Architekturdesign . . . . . . . . . . . . . . . . . . . . . . . 58
4.5.3 Architekturreview . . . . . . . . . . . . . . . . . . . . . . . 62
4.6 SMMaaS Architekturreview . . . . . . . . . . . . . . . . . . . . . 63
5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
A Anhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.1 BSI Korrespodenz . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.1.1 E-Mail an das BSI . . . . . . . . . . . . . . . . . . . . . . 73
A.1.2 Interessensbekundung vom BSI . . . . . . . . . . . . . . . 75
A.2 IT-Grundschutz Kreuzreferenztabellen . . . . . . . . . . . . . . . 77
A.2.1 M 1 Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . 77
A.2.2 M 2 Organisation . . . . . . . . . . . . . . . . . . . . . . . 78
A.2.3 M 3 Personal . . . . . . . . . . . . . . . . . . . . . . . . . 79
A.2.4 M 4 Hard- und Software . . . . . . . . . . . . . . . . . . . 80
A.2.5 M 5 Kommunikation . . . . . . . . . . . . . . . . . . . . . 81
A.2.6 M 6 Notfallvorsorge . . . . . . . . . . . . . . . . . . . . . . 82

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

Tabellenverzeichnis
V
Tabellenverzeichnis
Tabelle 2.1 Unterscheidungen zwischen den Truststufen . . . . . . . . 13

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

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

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.
1.2. 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.

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.

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.
2.1. 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

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.

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.
2.2. 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.

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.
2.2.1. 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.
2.2.2. 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

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.
2.2.3. 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.
2.2.4. 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-

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.
2.2.5. 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.
2.3. 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.
2.3.1. digitale Zertikate
Ein digitales Zertikat sind strukturierte Daten. Es enthält eine Reihe von Informationen:
1 http://de.wikipedia.org/wiki/Datei:Public-Key-Infrastructure.svg

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. E-Mail 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

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.
2.3.2. 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
2.3.4.
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.
2.3.3. 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-

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.
2.3.4. 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.
2.4. Logging
Bei dem Logging bzw. Protokollieren werden Ereignisse in Logdateien
geschrieben. Die Ereignisse können durch Betriebssysteme, Netzwerkkomponen-

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.
2.5. 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.
1 http://www.balabit.com/sites/default/files/documents/syslog-ng-v3.
0-guide-admin-en.html/logging01.png

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 E-Mail, 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.

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 27001 und berücksichtigt weiterhin die
Empfehlungen der anderen ISO-Standards der ISO 2700x-
Familie wie beispielsweise ISO 27002 (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

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

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 100-4 Notfallmanagement
Mit dem BSI-Standard 100-4 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.

3 Analyse BSI IT-Grundschutz 17
3. 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.
3.1. 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.
3.1.1. 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

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.

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-

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

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-

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
E-Mail 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-

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-

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-

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 2.131 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 2.133 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 2.142 Zerstörung von Beweisspuren bei der Behandlung von Sicherheitsvorfällen

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

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.
3.1.2. 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.

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.
3.1.3. 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-

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

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

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.
3.2. 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.

4 SMMaaS Architektur 33
4. 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.
4.1. 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

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.

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.
4.2. 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

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 4.4.2.
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

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

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.
4.3. 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-

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-

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.
4.4. 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.

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.

42 4 SMMaaS Architektur
Abbildung 4.7: Angri auf Server in der Cloud mit zentralem Log-Server
4.4.1. 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.

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

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.

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].

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.
4.4.2. 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

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

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

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

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

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.
4.4.3. 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 4.4.2 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-

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.
4.5. 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

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.
4.5.1. Anforderungen aus dem BSI IT-Grundschutzkatalog
Wie bereits in Kapitel 4.4.2 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

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.

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.

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

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

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.
4.5.2. Architekturdesign
Der grundsätzliche Aufbau des Architekturdiagramms (Abbildung 4.10) ist
der selbe wie der des Logging-Moduls in Kapitel 4.4.2. 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 4.4.2 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

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

60 4 SMMaaS Architektur
Hash-Funktionen verwendet werden, muss durch das Management-Modul
deniert werden. Es sollen mehrere Hash-Algorithmen in verschieden langen
Ausführungen angeboten werden. Dabei muss auf die Verwendung von
sicheren Algorithemen wie z.B. Secure Hash Alghorithm (SHA) geachtet
werden. Da Hash-Funktionen oft in der Kryptograe eingesetzt werden muss
dieser Baustein oft mit anderen Bausteinen zusammenarbeiten.
Asym. Kryptographie-Baustein
In diesem Baustein ndet das Ver- und Entschlüsseln von Daten, sowie
das Berechnen von Signaturen statt. Es werden dazu in diesem Modul
nur asymmetrische Algorithmen verwendet. Der Baustein bietet andern
Bausteinen und Modulen dazu eine Schnittstelle an. Ebenso wie bei dem
Hash-Baustein werden die möglichen Algorithmen durch das Management-
Modul vorgegeben und ebenso ist auch in diesem Baustein auf die Verwendung
von sicheren Algorithmen, z.B. RSA, zu achten. Da dieser Baustein direkt
die kryptographischen Algorithemen verwendet, erstellt dieser Baustein
in Zusammenarbeit mit dem Hash- und Zufallszahlen-Baustein und auf Anforderungen
des Zertikatsmanagements die Zertikate.
Revocation-Baustein
Der Baustein Revocation ist für die Rückruisten der CA zuständig. Er
erstellt und erneuert die Rückruisten. Zusätzlich ist der Baustein auch
für die Veröentlichung zuständig. Die Ruckrüisten sind üblicherweise in
Form von CRL's realisiert. Diese CRL's werden mittels eines Webservers
zur Verfügung gestellt. Die CRL's haben immer einen Zeitraum, in dem
sie gültig sind. Clients beziehen die CRL's in einem regelmäÿigen Abstand,
welcher kleiner sein muss als die Gültigkeitsdauer. Wenn Zertikate während
diesem Zeitraum zurückgerufen werden, bekommen die Clients dies erst mit
dem erneuten Beziehen der CRL mit. Daher gibt es neben dieser gängigen
Technik noch eine zusätzliche, welche eine weite Verbreitung ndet, sie
heiÿt OCSP. Für OCSP benötigt der Server einen extra Daemon, welcher
für die Anfragen zuständig ist. Bei OCSP wird die Gültigkeit eines Zerti-
kates bei jeder Benutzung eines Zertikates online am OCSP-Server erfragt.
Die Clients sind also bereits bei den nächsten Nutzungen eines Zertikates
darüber informiert, dass es zurückgerufen wurde und können die
Benutzung des Zertikates verweigern.
Logging-Baustein
Dieser Baustein ist eine Schnittstelle für das Modul Logging. Der Baustein
protokolliert alle Zugrie und Aktionen, welche in dem PKI-Modul stattnden
und sendet diese an das Logging-Modul. Die Logereignisse werden

4 SMMaaS Architektur 61
nicht, obwohl es möglich wäre, vor dem Versenden an das Logging-Modul
mit einem Zeitstempel und Signatur versehen. Die passiert erst, wenn das
Logging-Modul die Logereignisse an das PKI-Modul schickt zum signieren.
Dies steigert zwar die Netz- und Systemlast, allerdings ist dafür der Prozess
bei allen Modulen der selbe. Desweiteren wäre es nicht sinnvoll direkt die
Logereignisse zu signieren, da das Logging-Modul die Ereignisse erst noch
normalisiert.
Zufallszahlen-Baustein
Der Baustein Zufallszahlen erstellt echte Zufallszahlen, dazu nutzt er einen
zusätzlichen Zufallszahlengenerator. Dieser kann echte Zufallszahlen auf Basis
eines z.B. physikalischen Eektes erzeugen. Andere Baustein können
diese Zufallszahlen über Schnittstellen dieses Bausteins abfragen.
Zertikatsmanagement
Das Zertikatsmanagement ist für das Organsieren, Verwalten der Zertikate,
Certicate Signing Request (CSR) und der CA zuständig. Der
Baustein biete Schnittstellen für andere Bausteine und Module an, über
welche CSR gestellt bzw. erzeugt werden können. Auÿerdem können
über diese Schnittstellen System- und Personenzertikate sowie die CA-
Zertikate abgerufen werden. Ein Exportieren von kompletten Schlüsselpaaren
ist in geschützer Form (PKCS12-Format) ebenfalls möglich. Das
Zertikatsmanagement ist während der Initalisierung des Moduls auch für
das Beantragen und Importieren der Sub-CA zuständig.
PKI-Management-VM
Die PKI-Management-VM ist wie bei dem Modul Logging eine besonders
abgesicherte und isolierte VM, welche direkt einem Kunden zugeordnet ist.
Der Kunde hat allerdings keinen direkten Zugri auf die VM, der Kunde
kann die Funktionen der VM und des darauf laufenden Moduls PKI allerdings
über die Managementschnittstellen nutzen. Die Verwaltung der VM
übernimmt der Cloud Service Provider, dieser kümmert sich auch um das
Patch- und Änderungsmanagement.
Kommunikationsverschlüsselungs-Baustein
Dieser Baustein ist wie bei dem Modul Logging ein eingenständiger
Baustein, welcher für die verschlüsselte Kommunikation zwischen den Modulen
zuständig ist.

62 4 SMMaaS Architektur
4.5.3. Architekturreview
Die Architektur des PKI-Modules deckt die meisten der Anforderungen ab. Die
Anforderung an echte Zufallszahlen kann durch den Zufallszahlen-Baustein erfüllt
werden, da dieser Zugri auf spezielle Zufallszahlengeneratoren hat. Ein sicherer
persistenter Speicher für die Zertikate lässt sich ebenso wie bei dem Module-
Logging problemlos durch den Storage- und Datenverschlüsselungs-Baustein realisieren.
Da die PKI-Managment-VM auch eine absicherte und isolierte Umgebung
bietet und der Zugang zu der VM sehr streng reglementiert ist, wird der Zugri auf
den persistenen Speicher zusätzlich gesichert. Die VM erfüllt auch gleichzeitig die
Anforderung nach einer sicheren Umgebung. Die Autorisierung auf die einzelnen
Funktionen und Bausteine des Moduls lassen sich mittels des Autorisierungs-
Bausteins sicherstellen, wobei die Regeln für die Autorisierung im Rollen- und
Rechtemanagement stattndet. Die Kommunikation zwischen den Modulen wird
ebenfalls, wie bei dem Logging-Modul, komplett verschlüsselt. Dazu dient der
Kommunikationverschlüsselungs-Baustein. Die Anforderungen nach einer korrekten
Zeitangabe, wird komplett erfüllt indem der Zeit-Baustein die korrekte Zeit
bezieht. Dies kann der Baustein sogar über mehrere Wege, so dass ein Angri
auf diese Komponente sehr erschwert wird. Die Erstellung von Signaturen war
die Anforderung an das PKI-Modul, welches selbstverständlich erfüllt wird. Die
Bausteine asymmetrische Kryptograe und Hash stellen sicher, dass Signaturen
erstellt werden können. Die Anforderung Verwaltung von Sub-CA mit
Einschränkung auf einen X.500 Teilbaum wird durch das Modul erfüllt, wobei
die Nutzung eines X.500 Teilbaums von der Truststufe des Kunden abhängt.
Die Verwaltung und auch die Absicherung auf einen X.500 Teilbaum wird durch
das Zertikatsmanagement sichergestellt. Die Anforderung an Schnitte für andere
Modul ist selbstverständlich, da anderenfalls die Interaktion mit andern Modulen
nicht funktionieren würde.
Die Anforderungen lange Laufzeit der Zertikate und Nutzung von sicheren Alghorithmen
lassen sich nicht komplett durch das Modul PKI abdecken. Die Algorithmen
müssen im PKI-Modul implementiert werden um überhaupt genutzen
werden zu können. Aus Kompatiblitätsgründen müssen allerdings nicht nur Algorithmen,
welche momentan als sicher gelten, implementiert werdne, sondern auch
welche, die bereits heute als unsicher gelten. Desweiteren wird im Management
Modul festgelegt bei welcher Aktion welche Algorithmen verwendet werden sollen.
Eine Fehlkonguration an dieser Stelle hat daher ebenfalls Auswirkungen auf die
Anforderung. Die lange Laufzeit bringt ebenfalls einige Probleme mit sich. Wenn
Zertikate mit einer Dauer von zehn Jahren und mehr erstellt werden, kann es
passieren, dass in der Zwischenzeit die verwendeten Algorithmen gebrochen wer-

4 SMMaaS Architektur 63
den können bzw. als unsicher gelten. Auf der anderen Seite muss der Aufwand,
dass Zertikate ausgetauscht werden, bei Zertikaten mit langer Laufzeit nicht
hoch ist. Die Laufzeit wird hierbei ebenfalls durch das Management-Modul festgelegt.
Durch zusätzliche Maÿnahmen im Management-Modul können beide Anforderungen
dann erfüllt werden. Eine weitere Anforderung, welche sich nicht
komplett durch das PKI-Modul lösen lässt, ist der Austausch von Zertikaten.
Der Austausch von Zertikaten für die Kommunikation im Bereich von
SMMaaS lässt sich weitestgehend automatisieren, aber der Austausch der Zertikate
für den Zugang zu Instanzen lässt sich nicht komplett automatisieren.
Dies beruht auf dem Problem, dass der Cloud Service Provider keinen Zugang zu
den Kundeninstanzen haben soll. Daher benötigt das PKI-Modul für den Austausch
eine Autorisierung durch den Kunden. Aus Sicherheitsgründen könnte der
CRL-Baustein noch angepasst werden. Die Veröentlichung der CRL und das
Anbieten eines OCSP-Service können zusätzliche Angripunkte auf die PKI-VM
darstellen. Eine Auslagerung der CRL und des OCSP-Service auf einem gesonderten
Server würde hier Abhilfe schaen. Dieser Server sollte auch nicht in der
selben sicheren Umgebung laufen wie die PKI-VM.
Im Zuge einer Bachelorthesis [26] an der Hochschule Furtwangen, Fakultät Informatik
wurde ein System zur Kommunikationverschlüsselung in Clouds entwickelt.
Ein Bestandteil dieser Entwickelung ist eine PKI-Management Komponenten.
Die Komponente könnte mit ein paar Erweiterungen im Funktionsumfang
als Baustein Zertikatsmanagement genutzt werden.
Im folgenden Kapitel ndet ein Review der SMMaaS-Architektur statt.
4.6. SMMaaS Architekturreview
Die SMMaaS-Architektur mildert, wie die letzen Kapitel zeigen, eine Reihe
der Gefahren ab. Allerdings lassen sich Gefahren wie z.B. G1.10 Ausfall eines
Weitverkehrsnetzes oder G2.1 Fehlende oder unzureichende Regelungen nicht
damit lösen. Bei diesen handelt es sich zum groÿen Teil um Gefahren aus dem
Gefahrenkatalog G2 Organisatorische Mängel. Wie auch schon in Kapitel 4.2
beschrieben kann SMMaaS bei einigen Gefahren nur unterstützend wirken. Die
Module Logging und PKI sind genauer untersucht und decken jeweils die meisten
Anforderungen ab. Dadurch lassen sich die Gefahren welche auf die Module
wirken reduzieren. Um eine endgültige Aussage treen zu können ob SMMaaS wie
beschrieben alle Gefahren beseitigen kann bedarf es noch einer genaueren Untersuchung
der Module. Ebenso müssen die Module detailierter designt werden. Es
deuten sich allerdings schon einige Verbesserungsideen an. So kann durch eine
Erweiterung der Logleanalyse um eine CEP-Engine das Erkennen von Sicher-

64 4 SMMaaS Architektur
heitsvorfällen verbessert werden. Ebenso ist es zu überlegen ob die SMMaaS-
Architektur für den CSP angepasst werden kann, damit SMMaaS als zentrales
Netzwerk und Systemmanagement fungiert. Dies hätte den Vorteil dass sowohl
der Kunde als auch der CSP die selbe Umgebung nutzen. Hierdurch kann das Vertrauen
des Kunden in den CSP und SMMaaS gesteigert werden. Zur leichteren
Umstellung auf eine Providervariante von SMMaaS kann das vorhandene Netzund
Systemmanagement über Schnittstellen und APIs integriert werden. Bisher
sind noch keine Teile von SMMaaS implementiert weshalb sich keine Aussagen treen
lassen ob sich bei der Implementierung weitere Gefahren herausstellen. Eine
Implementierung eines Rollen- und Rechtemangement ist im Zuge einer Bachelorthesis
[27] für CloudIA entstanden. Diese Implementierung kann mit einigen
Anpassungen und Erweiterungen als Modul Rollen- und Rechtemangement in
SMMaaS integriert werden.

5 Fazit 65
5. Fazit
5.1. Zusammenfassung
Nach dem Abschluss dieser Thesis zeigt sich das BSI IT-Grundschutz bereits
viele Gefahren, welche durch Cloud Computing entstehen, kennt. Ebenso hat sich
gezeigt das noch nicht alle Gefahren abgedeckt werden. Diese fehlenden Gefahren
wurden daraufhin beschrieben. Während der Erstellung dieser Thesis entstand
eine Zusammenarbeit zwischen dem BSI und dem Cloud Research Lab mit dem
Ziel einen Bausteinentwurf Cloud Computing zu erstellen.
Desweiteren wurde die Sicherheitarchitektur SMMaaS vorgestellt. Sowohl die
Weiterentwicklungen als auch die Architektur wurde erklärt. Bei der Analyse
der IT-Grundschutz Gefahren, welche durch SMMaaS gelöst werden können, und
den begleitender wissenschaftlicher Arbeiten, stellte sich heraus das die Funktionalität
Rollen- und Rechtemanagement fehlte. Die SMMaaS-Architektur wurde
um diese Funktion erweitert.
Im folgenden wurden detailiert die Module Logging und PKI vorgestellt.
Es wurden die Gefahren und Maÿnahmen, aus dem IT-Grundschutzkatalog,
welche sich auf die Module auswirken dargelegt. Darauf Aufbauend wurden Anforderungen
an die Module deniert. Im Anschluÿ wurden die Module detailiert
designt und erklärt. Alle Module und die SMMaaS-Architektur wurdem jeweils
einem Review unterzogen. Bei diesem wurde besonders auf die Einhaltung
aller Anforderungen geachtet. Während des Erstellens dieser Thesis fand weitere
Bachelor-Thesen statt. Die Implementierung aus diesen Thesen decken bereits
Teilbereich der Module von SMMaaS ab.
5.2. Ausblick
Durch die Analyse der BSI-Gefahren hat sich bereits ein Teil der notwendigen Informationen
für den Baustein Cloud Computing ergeben. Mit Hilfe dieser Informationen
und durch weitere Arbeiten kann ein Bausteinentwurf Cloud Computing
entstehen. Hierzu müssen die Gefahren sowie die Maÿnahmen genau deniert
werden. Dies muss in Zusammenarbeit mit dem BSI geschehen.
Des Weiteren muss die Entwicklung an der SMMaaS-Architektur weitergeführt
werden. Es müssen die restlichen Module genau deniert und designt werden.
Dabei ist auf ein möglichst modulares und exibles Design zu achten. Neben der
Denierung aller Module muss an der Implementierung von neuen Baustein und
der Anpassung vorhandener Bausteine gearbeitet werden.

Literaturverzeichnis 67
Literaturverzeichnis
[1] A. D. Essoh. (2009, Nov.) It-grundschutz und cloud computing.
[Online]. Available: http://www1.gi-ev.de/leadmin/
gliederungen/fb-sec/Dateien_FG_SECMGT/Workshop_2009-11-20/
Essoh_20-11-2009-Cloud-Computing-SECMGT.pdf
[2] BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter,
Draft ed., Bundesamt für Sicherheit in der Informationstechnik,
Godesberger Allee 185-189, 53175 Bonn, 2010. [Online]. Available:
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/
Sonstige/Cloud_Computing_Mindestsicherheitsanforderungen.pdf?__
blob=publicationFile#download=1
[3] K. Beckers and J. Jürjens, Security and compliance in clouds,
Fraunhofer ISST, Tech. Rep., Oct. 2010. [Online]. Available: http:
//inky.cs.tu-dortmund.de/main2/jj/publications/papers/isse10.pdf
[4] T. Mather, S. Kumaraswamy, and S. Latif, Cloud Security and Privacy An
Enterprise Perspective on Risks and Compliance, 1st ed. O'Reilly, Oct.
2009.
[5] (2009) Security guidance for critical areas of focus in cloud computing v2.1.
[Online]. Available: http://www.cloudsecurityalliance.org/csaguide.pdf
[6] D. W. Streitberger. (2009, Nov.) Cloud-computing-sicherheit taxonomie
der sicherheitsaspekte und herausforderungen für die it-sicherheit. [Online].
Available: http://www1.gi-ev.de/leadmin/gliederungen/fb-sec/Dateien_
FG_SECMGT/Workshop_2009-11-20/Streitberger_SIT_MUC_SST_
GI_SECMGT_WS_v3.pdf
[7] (2009) Cloud computing - benets, risks and recommendations for information
security. [Online]. Available: http://www.enisa.europa.eu/act/rm/les/
deliverables/cloud-computing-risk-assessment/at_download/fullReport
[8] F. Doelitzscher, C. Reich, and A. Sulistio, Designing cloud services adhering
to government privacy laws, Cloud Research Lab, Hochschule Furtwangen,
Robert-Gerwig-Platz 1 ,78120 Furtwangen, Tech. Rep. CRL-2010-02,
Mar. 2010. [Online]. Available: http://www.wolke.hs-furtwangen.de/assets/
downloads/CRL-2010-02.pdf
[9] M. Thomas, Sicherheitsmodul zur Datenverschlüsselung in der Cloud,
2010th ed., ser. InformatikJournal. Robert-Gerwig-Platz 1 ,78120 Furtwangen:
Fakultät Informatik, Hochschule Furtwangen, 2010, pp. 1321.

68 Literaturverzeichnis
[10] P. Mell and T. Grance. (2009, Jul.) Nist denition of cloud computing.
[Online]. Available: http://csrc.nist.gov/groups/SNS/cloud-computing/
cloud-def-v15.doc
[11] Wikipedia, Kryptographie wikipedia, die freie enzyklopädie,
2010. [Online]. Available: http://de.wikipedia.org/w/index.php?title=
Kryptographie&oldid=81423628
[12] Signaturgesetz vom 16. mai 2001, BGBl. I S. 876, 2001, zuletzt geändert
durch Artikel 4 des Gesetzes vom 17. Juli 2009 (BGBl. I S. 2091).
[Online]. Available: http://www.gesetze-im-internet.de/bundesrecht/sigg_
2001/gesamt.pdf
[13] BSI-Standard 100-1: Managementsysteme für Informationssicherheit
(ISMS), 1st ed., Bundesamt für Sicherheit in der Informationstechnik,
Godesberger Allee 185-189, 53175 Bonn, 2008. [Online]. Available:
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/
ITGrundschutzstandards/standard_1001.pdf?__blob=publicationFile
[14] BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise, 2nd ed., Bundesamt
für Sicherheit in der Informationstechnik, Godesberger
Allee 185-189, 53175 Bonn, 2008. [Online]. Available:
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/
ITGrundschutzstandards/standard_1002.pdf?__blob=publicationFile
[15] BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grundschutz,
2nd ed., Bundesamt für Sicherheit in der Informationstechnik,
Godesberger Allee 185-189, 53175 Bonn, 2008. [Online]. Available:
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/
ITGrundschutzstandards/standard_1003.pdf?__blob=publicationFile
[16] BSI-Standard 100-4 Notfallmanagement, 1st ed., Bundesamt
für Sicherheit in der Informationstechnik, Godesberger
Allee 185-189, 53175 Bonn, 2008. [Online]. Available:
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/
ITGrundschutzstandards/standard_1004.pdf?__blob=publicationFile
[17] Bsi-standards, [Online; Stand 7. November 2010]. [Online]. Available:
https://www.bsi.bund.de/ContentBSI/Publikationen/BSI_Standard/
it_grundschutzstandards.html
[18] C. Weinhardt, A. Anandasivam, B. Blau et al., Cloud-computing,

Literaturverzeichnis 69
WIRTSCHAFTSINFORMATIK, vol. 51, pp. 453462, 2009. [Online].
Available: http://dx.doi.org/10.1007/s11576-009-0192-8
[19] Baustein virtualisierung, Online, in der Informationstechnik, Bundesamt
für Sicherheit, Tech. Rep., Mar. 2010. [Online]. Available:
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/
Download/Vorabversionen/baustein_virtualisierung_entwurf.pdf?__
blob=publicationFile
[20] Baustein terminalserver, Online, in der Informationstechnik, Bundesamt
für Sicherheit, Tech. Rep., Mar. 2010. [Online]. Available:
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/
Download/Vorabversionen/baustein_terminalserver_entwurf.pdf?__
blob=publicationFile
[21] C. Lammers, Revisionssicheres logging von systemen und anwendungen und
deren auswertung, Master's thesis, Hochschule Furtwangen, Robert-Gerwig-
Platz 1 ,78120 Furtwangen, Dec. 2008.
[22] Cloud computing - evolution in der technik, revolution
im business, Albrechtstraÿe 10 A, 10117 Berlin-Mitte, Oct.
2009. [Online]. Available: http://www.bitkom.org/les/documents/
BITKOM-Leitfaden-CloudComputing_Web.pdf
[23] A. Böken. (2010, Jun.) Cloud computing und auftragsdatenverarbeitung.
[Online]. Available: http://www.linuxtag.org/2010/leadmin/
www.linuxtag.org/slides/Arnd%20Boeken%20-%20Cloud-Computing%
20und%20Auftragsdatenverarbeitung.pdf
[24] T. Weichert. (2010, Jun.) Cloud computing und datenschutz. [Online].
Available: https://www.datenschutzzentrum.de/cloud-computing/
[25] B. für Sicherheit in der Informationstechnik, Ed., IT-Grundschutz-Kataloge,
el. 11 ed. Postfach 10 05 34, 50455 Köln: Bundesanzeiger-Verlag,
Nov. 2009. [Online]. Available: https://www.bsi.bund.de/SharedDocs/
Downloads/DE/BSI/Grundschutz/Download/it-grundschutz-kataloge_
2009_EL11_de.pdf?__blob=publicationFile
[26] P. Seeburger, Kommunikationssicherheit in clouds, Master's thesis,
Hochschule Furtwangen, Robert-Gerwig-Platz 1 ,78120 Furtwangen, Oct.
2010.

70 Literaturverzeichnis
[27] T. Rübsamen, Rechtemanagement in der cloud design und implementierung
eines benutzermanagements für cloudia, Master's thesis, Hochschule
Furtwangen, Robert-Gerwig-Platz 1 ,78120 Furtwangen, Aug. 2010.

Ich versichere, dass ich die vorstehende Arbeit selbständig verfasst und hierzu
keine anderen als die angegebenen Hilfsmittel verwendet habe. Alle Stellen der
Arbeit die wörtlich oder sinngemäÿ aus fremden Quellen entnommen wurden,
sind als solche kenntlich gemacht. Die Arbeit wurde bisher in gleicher oder
ähnlicher Form in keinem anderen Studiengang als Prüfungsleistung vorgelegt
oder an anderer Stelle veröentlicht. Ich bin mir bewusst, dass eine falsche
Erklärung rechtliche Folgen haben kann.
Der Verfasser versichert, dass die beiliegende CD-ROM und alle darauf enthaltenen
Bestandteile (Dateien) auf Viren überprüft und kein schädlicher,
ausführbarer Code enthalten ist.
Ort, Datum, Unterschrift

A Anhang 73
A. Anhang
A.1. BSI Korrespodenz
A.1.1. E-Mail an das BSI
Sehr geehrte Damen und Herren,
wir kontaktieren Sie bezüglich Ihrer aktuellen Erweiterungen
des IT-Grundschutzkataloges.
Die Fakultät Informatik der Hochschule Furtwangen University
besitzt ein Cloud Computing Forschungszentrum
(www.wolke.hs-furtwangen.de). Das Forschungszentrum hat sich
auf den Bereich der Sicherheit in Cloud Computing spezialisiert.
Neben zahlreichen Abschluÿarbeiten (Bachelor- und Masterthesen)
beschäftigt sich momentan auch ein Doktorand mit dem Thema Cloud
Computing Security und Privacy.
Im Zuge einer aktuellen Masterthesis (Start 03/2010), werden
die Gefahren von Cloud Computing unter dem Aspekt des BSI
IT-Grundschutz analysiert und mögliche Lösungen ermittelt.
Daraus resultierend wird gerade eine Sicherheitsmangmentarchitektur
für Cloudinfrastrukturen entworfen. Ziel unserer
Forschungen soll eine mögliche Zertifizierung von Cloud-
Providern als auch Ihren Kunden nach BSI IT-Grundschutz sein.
Es wurden die bisherigen Gefahren aus dem bestehenden
IT-Grundschutz Katalog überprüft und analysiert in wiefern
diese auch für Cloud Computing gelten. Hierbei wurden ebenfalls
die Baustein-Vorabversionen "Virtualisierung" und "Terminalserver"
berücksichtigt. Aktuell werden bestehende IT-Grundschutz
Massnahmen überprüft in wiefern sich diese auch auf Cloud
Computing anwenden lassen. Wir planen neben den bestehenden
Richtlinien aus dem IT-Grundschutzkatalog weitere Gefahren und
daraus resultierende Massnahmen speziell für Cloud Computing zu
entwickeln.
Wir würden gerne in Zusammenarbeit mit ihnen einen neuen
Vorschlag für einen Baustein "Cloud Computing" erarbeiten,

74 A Anhang
in den die neuen Gefahren und Massnahmen einflieÿen können.
Unser Cloud Computing Forschungszentrum arbeitet bereits
mit einem Cloud Povider und verschiedenen IT-Sicherheitsdienstleistern
zusammen, wodurch praxisnahe Anforderungen
sowie zusätzliche Erfahrungen mit in den Baustein und die
Zusammenarbeit einflieÿen könnten.
Wir freuen uns über Ihre Antwort und würden Ihnen gern
unsere bisherigen Ergebnisse in einem persönlichen Gespräch
vorstellen.
Viele Grüÿe,
Prof. Dr. Christoph Reich

A Anhang 75
A.1.2. Interessensbekundung vom BSI
Bundesamt für Sicherheit in der Informationstechnik
Postfach 20 03 63, 53133 Bonn
Hochschule Furtwangen
Prof. Dr.
Christoph Reich
Robert-Gerwig-Platz 1
78120 Furtwangen
Betreff: IT-Grundschutz - Allg. Schriftverkehr
hier: Interessensbekundung zum Thema "Cloud Computing"
Bezug: Ihre E-Mail vom 12.10.2010
Aktenzeichen: 114 - 140 00 00
Datum: 15.10.2010
Seite 1 von 2
Holger Schildt
HAUSANSCHRIFT
Bundesamt für Sicherheit in
der Informationstechnik
Godesberger Allee 185-189
53175 Bonn
POSTANSCHRIFT
Postfach 20 03 63
53133 Bonn
TEL +49 (0) 228 99 9582-5927
FAX +49 (0) 228 99 10 9582-
Grundschutz@bsi.bund.de
https://www.bsi.bund.de
Als nationale Sicherheitsbehörde ist es das Ziel des Bundesamtes für Sicherheit in der
Informationstechnik (BSI), die IT-Sicherheit in Deutschland voran zu bringen. Dabei sind wir in erster
Linie der zentrale IT-Sicherheitsdienstleister des Bundes. Mit unserem Angebot wenden wir uns aber
auch an die Hersteller sowie die privaten und gewerblichen Nutzer und Anbieter von
Informationstechnik, denn nur gemeinsames Handeln kann wirkungsvoll sein. Eine noch engere
Zusammenarbeit mit allen Akteuren der IT- und Internetbranche auf dem Gebiet der IT-Sicherheit ist
daher unser Anliegen.
Das Referat Referat 114, "IT-Sicherheitsmanagement und IT-Grundschutz" des BSI beschäftigt sich
intensiv mit dem Thema Cloud Computing. Wir haben z.B. ein Eckpunktepapier mit den
Mindestsicherheitsanforderungen für Anbieter von Cloud-Lösungen veröffentlicht. Außerdem
erarbeiten wir Studien zum Thema Cloud Computing und Lösungen zur Integration von Cloud
Computing in den IT-Grundschutz.
Da die Hochschule Furtwangen ebenfalls im Bereich Cloud Computing aktiv ist und Studien hierzu
erarbeitet, bietet sich ein regelmäßiger Informationsaustausch an. Auf dieser Weise können sowohl die
Hochschule Furtwangen als auch das BSI voneinander profitieren. Daher würden wir regelmäßige
Treffen im BSI oder Telefonkonferenzen vorschlagen, so dass beide Parteien sich über die erarbeiteten
Ergebnisse austauschen können.
UST-ID/VAT-No: DE 811329482
KONTOVERBINDUNG: Deutsche Bundesbank Filiale Saarbrücken, Konto: 590 010 20, BLZ: 590 000 00,
IBAN: DE81590000000059001020, BIC: MARKDEF1590
ZUSTELL- UND LIEFERANSCHRIFT: Bundesamt für Sicherheit in der Informationstechnik, Godesberger Allee 185-189, 53175 Bonn

76 A Anhang
Seite 2 von 2
Im Weiterem sind wir sehr daran interessiert, den akademischen Nachwuchs zu fördern, indem wir
beispielsweise studentische Arbeiten betreuen. Im Zuständigkeitsbereich des Referats IT-
Sicherheitsmanagement und IT-Grundschutz wären beispielsweise studentische Arbeiten zum Thema
Cloud Computing, Informationssicherheitsmanagement und IT-Grundschutz vorstellbar.
Voraussetzung hierfür ist, dass das vorzuschlagende Thema die Ziele des BSI unterstützt und der zu
betreuende Student hierfür geeignet ist. Sind diese Voraussetzungen erfüllt, wären wir sehr an einer
Zusammenarbeit interessiert.
Im Auftrag
Schildt

A Anhang 77
A.2. IT-Grundschutz Kreuzreferenztabellen
A.2.1. M 1 Infrastruktur
G1.10
G1.15
G1.18
G2.1
G2.19
G2.28
M1.5 X
M1.14 X
M1.20 X
M1.25 X
M1.31 X
M1.49 X
M1.50 X
M1.52 X
M1.54 X
M1.56 X
M1.59 X
M1.66 X
M1.69 X
M1.70 X
G2.54
G2.60
G2.62
G2.84
G2.85
G2.86
G2.109
G2.131
G2.133
G2.142
G3.32
G3.79
G5.20
G2v8
G4v1
G4v6

78 A Anhang
A.2.2. M 2 Organisation
G1.10
G1.15
G1.18
G2.1
G2.19
G2.28
G2.54
G2.60
G2.62
G2.84
M2.1 X X X X
M2.3 X X
M2.8 X
M2.9 X
M2.10 X
M2.11 X
M2.12 X X
M2.35 X
M2.46 X X
M2.64 X
M2.88 X
M2.141 X
M2.143 X
M2.145 X
M2.146 X
M2.162 X
M2.163 X
M2.164 X X
M2.165 X X
M2.166 X
M2.167 X
M2.168 X
M2.169 X
M2.170 X
M2.253 X
M2.273 X
M2.307 X
M2.340 X X X
M2.351 X
M2.353 X
M2.357 X
M2.359 X
M2.361 X X
M2.362 X
M2.392 X
M2.402 X
M2.417 X
M2.418 X
M2.422 X
M2.424 X
M2.426 X
M2.431 X
M2.432 X
M2.433 X
M2.434 X
M2.436 X
G2.85
G2.86
G2.109
G2.131
G2.133
G2.142
G3.32
G3.79
G5.20
G2v8
G4v1
G4v6

A Anhang 79
A.2.3. M 3 Personal
G1.10
G1.15
G1.18
G2.1
G2.19
G2.28
G2.54
G2.60
G2.62
M3.2 X
M3.10 X
M3.33 X
M3.54 X
G2.84
G2.85
G2.86
G2.109
G2.131
G2.133
G2.142
G3.32
G3.79
G5.20
G2v8
G4v1
G4v6

80 A Anhang
A.2.4. M 4 Hard- und Software
G1.10
G1.15
G1.18
G2.1
G2.19
G2.28
G2.54
G2.60
G2.62
M4.24 X
M4.32 X
M4.64 X
M4.89 X
M4.234 X X
M4.305 X
M4.320 X
M4.321 X
M4.322 X
G2.84
G2.85
G2.86
G2.109
G2.131
G2.133
G2.142
G3.32
G3.79
G5.20
G2v8
G4v1
G4v6

A Anhang 81
A.2.5. M 5 Kommunikation
G1.10
G1.15
G1.18
G2.1
G2.19
G2.28
M5.2 X
M5.3 X
M5.130 X
G2.54
G2.60
G2.62
G2.84
G2.85
G2.86
G2.109
G2.131
G2.133
G2.142
G3.32
G3.79
G5.20
G2v8
G4v1
G4v6

82 A Anhang
A.2.6. M 6 Notfallvorsorge
G1.10
G1.15
G1.18
G2.1
G2.19
G2.28
G2.54
M6.17 X
M6.18 X
M6.23 X
M6.53 X
M6.56 X
M6.59 X
M6.60 X
M6.66 X
M6.75 X
M6.83 X
M6.98 X
M6.127 X
M6.128 X
G2.60
G2.62
G2.84
G2.85
G2.86
G2.109
G2.131
G2.133
G2.142
G3.32
G3.79
G5.20
G2v8
G4v1
G4v6