Aus Linux-Magazin 05/2010

Daten, Netze und Sicherheit in die Cloud auslagern

© elsone, Photocase.com

Anbieter versprechen eitel Sonnenschein bei der Auslagerung von IT-Diensten. Dabei verschweigt mancher, dass aus Wolken Regen, Schnee und Hagel entstehen. Eine Reise durch eine wechselvolle Landschaft .

Einfacher soll alles werden, günstiger und leichter auf wechselnde Anforderungen anzupassen. Auch ohne dass sich Hersteller auf eine gemeinsame Definition einigen könnten, erschließt sich eine Reihe von offenkundigen Vorteilen des Cloud Computing: Service-orientiert sollen die Angebote sein, flexibel und skalierbar.

Wer sich dazu entschließt, diese Vorteile wahrzunehmen, sieht sich mit einer verwirrenden Vielfalt an Angeboten konfrontiert. Wo im Prospekt noch von “Diensten nach Maß” die Rede war, steht plötzlich eine aufwändige Anpassung der eigenen Anwendungen ins Haus. Pries der Dienstleister nebulös “höchste Sicherheitsmaßnahmen” an, stellt sich vielleicht heraus, dass er ein ganz anderes Verständnis von Sicherheit hat.

Insgesamt beklagen 43 Prozent der von IDC im Rahmen einer Studie befragten Systemverantwortlichen, dass jeder Anbieter etwas anderes im Kontext von Cloud Computing kommuniziere [1]. 32 Prozent fehlen technische Informationen und 27 Prozent haben Schwierigkeiten, einen Überblick zum Thema zu erhalten. Genau der ist aber dringend nötig, denn Cloud Computing entbindet Anwender und Architekten nicht davon, über ihre neue IT-Landschaft nachzudenken – und zwar vor dem Umstieg.

Die Mauer muss weg

Wer seine Server in die Cloud stellt, gewinnt eine Menge Freiheit, denn ihre Dienste sind jetzt viel zugänglicher als im kleinkariert geschützten Serversegment des eigenen Rechnerraums. Doch halt: War nicht die Aufgabe der Unternehmensfirewall, genau dies zu vermeiden? Durch eine Verlagerung in die Cloud ergeben sich ganz neue Fragestellungen, die erst einmal nichts mit den Anwendungen und Diensten selbst zu tun haben.

In klassischen IT-Abteilungen schützt eine möglichst aus mehreren, unabhängig agierenden Komponenten wie Paketfiltern und Applikationsproxys bestehende Firewall alle Teile der IT: Anmeldeserver, Verzeichnisdienst, zentraler Dateiserver, die Anwendungsengine und die Datenbank dahinter. So eine Firewall hat den Vorteil, dass sie Zugangswege klar regelt: Bislang hat Zugriff, wer sich physisch im Gebäude befindet (Abbildung 1). Alternativ gibt es dedizierte VPN-Verbindungen für einzelne Mitarbeiter oder andere Unternehmensstandorte.

Abbildung 1: Netzsicherheit in klassischen Umgebungen: Eine Firewall sichert alle relevanten Dienste ab, nur lokal authentifizierte Mitarbeiter erlangen Zugriff.

Abbildung 1: Netzsicherheit in klassischen Umgebungen: Eine Firewall sichert alle relevanten Dienste ab, nur lokal authentifizierte Mitarbeiter erlangen Zugriff.

Sollte tatsächlich einmal ein schwerer Einbruch stattfinden, wären alle (noch verbleibenden) Daten mit dem Ziehen eines einzigen Steckers vom Internet getrennt. Sicherheitsverantwortliche haben die Wachtürme am Rande des Schutzwalls, den Perimeter, meist gut im Griff: Nur wenige Angriffe haben Erfolg auf diesem direkten Wege.

Sind jedoch die aufgezählten Serverdienste – oft erbringen die zentrale Unternehmensfunktionen – erst einmal auf mehrere Dienstleister verteilt, haben es die Verantwortlichen ungleich schwerer, die einzelnen Dienste zu schützen. Dazu gehört auch, diesen Schutz nachvollziehbar zu dokumentieren und seinen Fortbestand ständig zu überwachen (siehe Abbildung 2).

Abbildung 2: Netzsicherheit in virtualisierten Umgebungen: Auf allen Ebenen drohen Gefahren von möglichen Nachbarn.

Abbildung 2: Netzsicherheit in virtualisierten Umgebungen: Auf allen Ebenen drohen Gefahren von möglichen Nachbarn.

Andere Folgen des Auslagerns werden sich wohl erst in der Zukunft unter Beweis stellen, wenn es darum geht, Daten aus einem Dienst zurückzuholen, den jahrelang niemand im eigenen Haus gewartet hat und von dem keine zugängliche Dokumentation vorliegt. Die meisten Daten und Abläufe sind in der Realität nämlich durchaus komplexer als eine Adressenverwaltung. Insofern besteht die Gefahr, dass sich ein Rundum-sorglos-Paket als Vendor-Lock-in entpuppt, denn anerkannte Standards lassen beim Cloud Computing noch auf sich warten.

Monitoring hat auch im Cloud Computing einen großen Stellenwert. Läuft im klassischen Datacenter ein Dienst nicht mehr wie gewünscht, hat der Systemverwalter eine Reihe von Optionen, um dem Fehler auf die Spur zu kommen. Im besten Fall meldet die Anwendung selbst eine Panne: Gelegentlich vorkommende Engpässe bei Festplatten oder Hauptspeicher kann ein Systemmanagement wie Nagios melden. Einen Bug in einer Bibliothek zu finden oder die Auswirkungen eines erfolgreichen Einbruchs aufzudecken erfordert im Regelfall einen direkten Zugang zur Kommandozeile des Rechners – den gibt’s aber nur noch, wenn die Plattform selbst virtualisiert ist, also wie bei klassischen Rootservern.

Cloud-Anbieter weisen zwar zu Recht darauf hin, dass Monitoring viele solcher Aufgaben erledigen kann. Sie verschweigen aber, dass das einen Mehraufwand bedeutet, der vorher nicht in diesem Umfang anfiel. Einige Projekte wie Icinga tragen dieser neuen Sichtweise bereits Rechnung (siehe Abbildung 3).

Abbildung 3: Der Nagios-Klon Icinga eignet sich für den Überblick über viele verteilte Rechner in der Cloud.

Abbildung 3: Der Nagios-Klon Icinga eignet sich für den Überblick über viele verteilte Rechner in der Cloud.

Der Blick in die Wolken

Eine Konsequenz der Verteilung auf viele Schultern ist auch eine Neubewertung der Verfügbarkeit der Gesamtanwendung. Jedem Admin ist bewusst, dass es aus unterschiedlichsten Gründen Downtimes in einzelnen Komponenten gibt. Außerdem bestimmt sich die Ausfallwahrscheinlichkeit des Gesamtsystems aus der kombinierten voraussichtlichen Nichtverfügbarkeit jedes einzelnen Teiles. Und diese Gefahren sind in der Cloud schlicht zahlreicher: Muss heute ein Bagger die Verbindung durchtrennen, um das Netz zu kappen, haben in der Cloud die Bauarbeiter nun die Chance, gleich an mehreren Stellen anzusetzen. Konnte sich ein Admin nicht mehr per SSH auf den Server einloggen, hat er sich direkt an die Konsole gesetzt. Fällt ein Single-Sign-on-Server aus, liegen alle daran angeschlossenen Anwendungen brach. Die Auswirkungen bedürfen also viel intensiverer Planung als bislang.

Vogelfreie Daten

Glaubt man Umfragen unter IT-Entscheidern, sind mindestens zwei Drittel von ihnen gerade in Sicherheitsfragen noch unsicher [2]. Ihnen ist unwohl, dass sie nicht genau wissen, was mit ihren Daten eigentlich passiert. Zwar rühmen sich fast alle Anbieter von Cloud-Lösungen, umfassende Maßnahmen zur Verschlüsselung von Daten und Übertragungen anzubieten. Details sind aber schwerer zu erhalten: Eine Festplattenverschlüsselung nützt wenig, wenn die Schlüssel schlecht gesichert sind, eine SSL-Absicherung ist nutzlos, wenn sich Zertifikate fälschen lassen oder Anwendungen sie nicht nutzen. Die Beteuerung von Sicherheit nützt wenig, ein Nachweis tut not.

Für Public wie Private Clouds stellt sich jeweils die Frage, wer wie nah an welche Daten herankommt. Wenn die Kundenliste bei einem gehosteten System in einem Verzeichnis liegt und der Nachbar auf demselben Rechner nur ein Directory entfernt seine Daten verwaltet, reicht mitunter schon ein User-Exploit, um Verzeichnisberechtigungen zu umgehen. Das Beispiel lässt sich auch auf andere Bereiche der Cloud ausdehnen: Nutzen Anbieter Virtualisierungen, droht der theoretisch und durchaus auch praktisch von Sicherheitsteams nachgewiesene Ausbruch aus dem Container. Wer erst einmal Zugriff auf einen Hypervisor erlangt, darf alle Daten einsehen.

Selbst wenn zwei Wettbewerber ihre Dienste auf unterschiedliche Bare Metals beim selben Hoster auslagern, lässt sich vielleicht der Datenverkehr zum Wettbewerber abhören oder zumindest einer Verkehrsanalyse unterziehen. Solange Unternehmen ihre Mailserver im Haus haben, müssen perfide Konkurrenten einen gemeinsamen Provider in ihre Machenschaften einweihen. In der Cloud reicht ein angemieteter Server mit Root-Rechten im selben Segment.

E-Mail verschlüsseln nach wie vor die wenigsten – selbst wenn Vorsichtige ihre Inhalte schützen, geben in diesem Szenario Kommunikationsmatrizen interessante Einblicke, wer mit welchen Partnern wie oft Nachrichten austauscht.

Neue Netzstrukturen

Egal auf welcher Ebene ein Cloud-Dienst operiert, Sicherheitsverantwortliche sind gut beraten, möglichst viel über die tatsächliche Umgebung zu erfahren. Mag sein, dass eigentlich vorgesehen ist, nur einige Webservices zum Customer-Relations-Management zu nutzen. Vielleicht lassen sich ja auch eigene Softwaremodule hochladen und ausführen? Aber vielleicht sind ja auch Netzwerk-Schnittstellen verfügbar, sodass sich ein eigener Sniffer schreiben lässt? Die Sniffer-Bibliothek Libpcap gibt es beispielsweise auch für Java [3] oder Python [4].

Nicht immer ist transparent, wie Virtualisierungen den Netzverkehr zwischen einzelnen Segmenten trennen. Simulieren die Treiber eigene Ethernet-Segmente oder adressieren sie die Pakete nur so, dass sie dort ankommen, wo sie hingehören? Das wäre nämlich schlecht, da sich so Angreifern das ganze Arsenal von ARP-Angriffen öffnen würde [5]. Insofern ist aus Sicht der Sicherheit weniger wichtig, welche Services ein Cloud-Dienst geschäftsmäßig anbietet, sondern vielmehr, welcher Art die technischen Möglichkeiten sind, die sich dessen Kunden bieten, etwa die eines Promiscous Mode oder anderer Netzstatistiken.

Claims richtig abstecken

Nicht alle Cloud-Angebote sind unsicher – im Gegenteil bieten sie doch die Chance, endlich Sicherheitsfunktionen dort einzubauen, wo die eigenen vier Wände dies nicht notwendig erscheinen ließen. Nutzen etwa viele interne Benutzer eine wichtige Anwendung mit dem gleichen Passwort und erfordert demgegenüber eine gehostete Lösung, dass sich jeder User individuell anmeldet, hat sich die Güte der Maßnahmen schon bestätigt. So lässt sich nämlich im Schadensfall viel besser nachvollziehen, wer der Verantwortliche ist – sei es, dass er Daten stiehlt oder dass er fahrlässig mit seiner Zugangsinfrastruktur wie Passwort oder Token umgeht.

Renaissance der Passwörter

Das wirft jedoch ein bedenkliches Licht auf eine Thematik, die bereits überwunden schien: Der Einsatz von Passwörtern ist bei den meisten Cloud-Angeboten immer noch Authentifikationsmethode Nummer eins. Diese abzuhören ist auf dem Übertragungsweg dank SSL oder TLS keine ernsthafte Gefahr, Keylogger in schlecht gewarteten Clients sind es schon eher. Die Problematik besteht darin, dass es viele Anwender überfordert, viele Passwörter zu verwalten: für private und geschäftliche E-Mail, den Fileserver, drei unabhängige soziale Netzwerke, unzählige Accounts bei Bugtrackern, Newsportalen und -foren sowie gelegentlich gelesenen Newsletter.

In dem Fall hält dann ein Kennwort her oder Anwender benutzen ein Schema. Verbindliche Regelungen, wie Passwörter zu speichern sind, gibt es nicht. Besonders kalt läuft es erfahrenen Anwendern den Rücken herunter, wenn Erinnerungsdienste diese im Klartext zumailen. Das ruft Identity- und Authentication-Management-Dienste (IAM) auf den Plan. Allerdings sind die dazu vorgeschlagenen Protokolle SAML, SPML und XACML ihrerseits so komplex, dass es noch kein Anbieter geschafft hat, dafür eine verständliche und verlässliche Gesamtlösung zu entwickeln.

Wer diese Techniken nämlich halbherzig realisiert, setzt seine Anwender der Gefahr aus, dass beim Verlust eines Notebooks mit gespeichertem Zentralpasswort alle Dienste kompromittiert sind. Dann alle Einzelzugänge zu sperren kann zu einer langatmigen Aufgabe werden, die noch nicht einmal zwingenderweise effektiv ist: Solange Access-Token in Form von Cookies oder Session-IDs auf dem Applikationsserver noch gültig sind, kümmert die Anwendung ein geändertes Passwort wenig.

Dichte Bewölkung, Regen

Cloud Computing bietet manche Chance zur besseren Strukturierung der IT. Ein Selbstläufer mit großen Einsparpotenzialen ist der alte Outsourcing-Wein in neuen Schläuchen jedoch kaum. Firewalls vermögen Clouds nur eingeschränkt zu schützen, ein klassisches VPN verträgt sich konzeptionell nur eingeschränkt mit Public Clouds: Der Zugriff auf moderne IT-Systeme definiert sich neu, weshalb nicht nur die Authentifikation einen noch höheren Stellenwert erhält. Passwörter skalieren nicht, Token und neue Protokolle stecken noch in den Kinderschuhen. Dokumentation und Monitoring gewinnen an Bedeutung, wenn die LEDs am Server keine Auskunft über den Systemzustand geben können.

Kaum jemand lässt Nachbarn in seinen Serverraum, in der Cloud dürfen die jedoch ihr Ohr auf Leitungen legen oder sich durch das dünne Blech der Virtualisierungen bohren. Ein kundiger Blick schätzt ein, ob Wolken schönes Wetter oder einen Regenguss bringen.

Infos

[1] Anika Kehrer, “Noch nebulös”: Linux-Magazin Online: [http://bit.ly/bIUeq0]

[2] Colt-Studie, “Sicherheitsbedenken ausräumen”, 2009: [http://bit.ly/bxeRmY]

[3] Jpcap: [http://netresearch.ics.uci.edu/kfujii/jpcap/doc/]

[4] Pycap: [http://pycap.sourceforge.net]

[5] Achim Leitner, Thomas Demuth, “Angriffstechnik im lokalen Netz: ARP-Spoofing und -Poisoning”: Linux-Magazin 06/04, S. 34

LINUX-MAGAZIN KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS Readly Logo
E-Mail Benachrichtigung
Benachrichtige mich zu:
0 Kommentare
Älteste
Neuste Beste Bewertung
Inline Feedbacks
Alle Kommentare anzeigen
Nach oben