Linux-Magazin_-_Januar_2019

anbietern mit standardisierter Produktpa-

lette und festen Preisen. Kunden suchen

sich aus, wie viel Verantwortung sie an

den Anbieter abtreten wollen, indem sie

wahlweise IaaS oder ein anderes Modell

wie PaaS verwenden.

Die AaS-Angebote vieler Unternehmen

unterscheiden sich in erster Linie im Maß

an Verantwortung, das ein Kunde in der

Cloud noch zu übernehmen bereit ist. Je

weiter er in den As-a-Service-Bereich vor-

dringt, desto einfacher wird die Wartung

eines Setups – aber desto seltener werden

auch die Schrauben, an denen der Kunde

selbst noch drehen kann. Und das hat

handfeste Konsequenzen.

Denn aus Kundensicht ist ein Einbruch

in ein virtuelles Setup, das stark auf AaS-

Dienste setzt, eine mittelgroße Katastro-

phe. Um zu verstehen, warum das so ist,

ist ein kleiner Ausflug in die Technik nö-

tig, die AaS-Dienste in der Regel antreibt.

Open Stack als

Versuchsobjekt

Open Stack eignet sich zur Verdeutli-

chung des technischen Konzeptes sehr

gut, weil es einerseits Open-Source-Soft-

ware ist und andererseits auch die Open

Stack zugrunde liegenden Standards öf-

fentlich und gut dokumentiert sind. Am

Anfang steht die Frage: Was ist eigent-

lich die Motivation hinter As-a-Service-

Diensten?

Zunächst geht es Kunden darum, weni-

ger Wartungsarbeit zu haben. Geht man

von der Anforderung „Ich brauche eine

funktionierende Maria-DB-Datenbank“

aus, gibt es ja grundsätzlich mehrere

Wege, dieses Ziel zu erreichen. Die ganz

klassische Variante wäre, eine virtuelle

Maschine auf Linux-Basis zu starten und

darin Maria DB zu installieren. Dann hin-

Von den Cloud-Apologeten, die landauf,

landab die frohe Botschaft von „Every-

thing as a Service“ und „Serverless Com-

puting“ verbreiten, ist bekannt, dass ihre

Lösungen auf dem Papier zwar oft her-

vorragend aussehen, doch im Alltag nicht

selten Probleme bereiten, deren Lösung

gar nicht so leicht zu finden ist.

Auch bei der Frage, wie man nach ei-

nem Einbruch vorgeht, ergeben sich im

Cloudkontext spezielle Fragen. Denn

während der Admin in einer klassischen

Umgebung die betroffenen Systeme übli-

cherweise sofort vom Strom trennt und

die vorhandenen Datenträger sorgfältig

prüft, ist in der Cloud alles virtuell – vom

System, in dem ein Dienst läuft, bis zum

Volume, auf dem er Daten ablegt. Mehr

noch: Wer sich für die Nutzung von As-a-

Service-Angeboten entscheidet, gibt noch

mehr Kontrolle ab und kommt oft noch

nicht einmal an die Systeme heran, auf

denen seine Dienste laufen.

Was können Anwender in einer Cloud

überhaupt nach einem Angriff tun? Gibt

es bei klassischen AaS-Angeboten fo-

rensische Maßnahmen? Und wie sieht

die Sache aus Sicht des Admin aus? Wie

reagiert er im Falle eines Falles und wie

kann er Kunden beim Thema Forensik

unterstützen?

Wenige Optionen

Die Idee hinter Everything as a Service

und Serverless Computing ist ja schnell

durchschaut: ISPs werden zu Plattform-

Die Spurensuche nach einem Einbruch auf physischen Systemen ist Fleißarbeit, und das ist auch in der Cloud

nicht anders. Nur dass hier besondere Effekte die Arbeit noch deutlich verkomplizieren. Martin Loschwitz

Wie Forensik in Cloudumgebungen funktionieren kann

Schwierige Spurensuche

Titelthema

46

http://www.linux-magazin.de

Cloud-Forensik

© belchonock, 123RF

Der Autor

In seiner Freizeit Debian-

Entwickler arbeitet Martin

Gerhard Loschwitz beruf-

lich als Telekom Public

Cloud Architect bei T-Sys-

tems und beschäftigt sich

beruflich vorrangig mit Themen wie Open Stack,

Ceph und Kubernetes.