Überlegungen zur Sicherheit in Clouds

Überwiegend heiter?

An Cloud-Computing führt kein Weg vorbei, wenn man Marketing und Analysten glauben will. Doch wie sieht es mit der Sicherheit in der Cloud aus? Einige Gedanken dazu…
Duell der Datenbanken: In einem Shootout messen sich MySQL und PostgreSQL. Der Schwerpunkt vom ADMIN 06/2011 überprüft, wer schneller ist und gibt einen ... (mehr)

Ob man das nun gut findet oder nicht: Cloud-Computing setzt sich auf breiter Front durch und wird uns auch eine lange Zeit erhalten bleiben (darauf zu wetten, ist ziemlich risikolos, angesichts der Tatsache, dass Cobol und Fortran auch noch nach 50 Jahren existieren). Die gute Nachricht ist, dass Linux für die Cloud-Provider wie auch die -Anwender eine hervorragende Plattform ist.

Eine große Herausforderung beim Cloud-Computing besteht darin, dass man keine Kontrolle über die zugrunde liegende Hardware wie das Netzwerk, Storage und so weiter hat. Wer seine Anwendungen in der Cloud laufen lässt, teilt vermutlich die Hardware mit anderen, etwa auf Amazons EC2. Für die Provider ist dieses Modell toll, denn sie können jeden Cent aus ihrer Hardware quetschen, indem sie ungenutzte Ressourcen an Anwender verkaufen, aber für die Enduser kann das gelegentlich zum Problem werden.

Die Bandbreite der Anwendungen für Cloud Computing erweitert sich gleichermaßen ständig. Jeder kann sich plötzlich selbst rechenintensive Aufgaben leisten, etwa das Knacken von WLAN-Passwörtern mit Tesla-Karten von Nvidia. Service-Provider wie Google Apps erlauben es, Webanwendungen bereitzustellen, die mit Traffic-Spitzen umgehen können, ohne dass man sich selbst darum kümmern müsste. Letztlich stehen einem mit den Cloud-Angeboten dieselben Möglichkeiten zur Verfügung wie den großen Webdienstleistern.

Aus Sicherheitsgründen müssen die Provider sicherstellen, dass die Daten der einzelnen Kunden sauber getrennt sind. Im Fall von Infrastructure as a Service (IaaS) haben sich die meisten zugrunde liegenden Virtualisierungstechnologien wie VMware, Xen oder KVM in dieser Hinsicht als zuverlässig erwiesen und trennen von Haus aus die einzelnen Instanzen. Bei Platform as a Service (PaaS) wie Google Apps liegen die Dinge etwas komplizierter. Sehr wenige Programmiersprachen lassen sich auf eine "sichere" Weise für Anwender bereitstellen, die zumindest potenziell Böses im Schilde führen. Ein Beispiel dafür ist Java, das zwar von Anfang an eine Art Sandbox implementierte, in der aber dennoch immer wieder schwerwiegende sicherheitskritische Fehler gefunden werden.

Schließlich gibt es auch noch die Anbieter von Software as a Service (SaaS), die fertige Anwendungen bereitstellen und damit so viele Anwender wie möglich erreichen möchten. Da bleibt nur zu hoffen, dass sie darauf acht geben, dass diese Anwendungen weitgehend frei von den üblichen Sicherheitslücken wie etwa SQL-Injections und so weiter sind.

Verschlüsselt

Daten, die in der Cloud lagern, unterscheiden sich auf vielerlei Art von lokalen Daten, aber der wesentliche Punkt ist, dass sie sich auf Systemen befinden, die man nicht selbst kontrolliert. Noch schlimmer: Sie liegen auf Systemen, die man mit anderen teilt. Wenn nun etwa ein Kunde etwas Illegales auf dem Server anstellt, kann es sein, dass die Ermittlungsbehörden die komplette Maschine mitnehmen. Oder der Provider ist nicht anders in der Lage, den entsprechenden Aufforderungen nachzukommen [1] .

Ein Provider könnte auch eine komplette Festplatten mit sensiblen Daten zur Reparatur außer Haus schicken oder alte Hardware verkaufen, ohne sie vorher zu löschen – falls das überhaupt vollständig möglich ist [2] . Schließlich könnte auch die Server-Infrastruktur so beschaffen sein, dass sie zwar lokal und sicher erscheint, in Wirklichkeit aber die eigenen Daten übers Netzwerk fließen.

Selbst wenn es beim Provider entsprechende Sicherheits-Policies gibt, die solche Dinge abdecken, bringt das wenig, wenn er irgendwann in Konkurs geht. Beispielsweise sicherte Toysmart.com seinen Kunden zu, niemals die persönlichen Daten zu Geschäftszwecken zu verwenden. Nach der Pleite fingen sie aber plötzlich an, genau das zu tun. Die Federal Trade Commission kam ins Spiel und einigte sich mit der Firma darauf, dass "der Verkauf dieser Kundeninformationen verboten sei – außer im Fall sehr spezieller Umstände" [3] .

Der erste Schritt zur Absicherung liegt deshalb darin, die eigenen Daten zu verschlüsseln. Wo auch immer Daten gespeichert werden, sollten sie verschlüsselt werden, und das umfasst mehr als nur Storage und Datenbanken. Wer zum Beispiel bei einer Webanwendung Message Queues verwendet, muss damit rechnen, dass sie auf die Festplatte geschrieben werden, etwa das Binärlog von Beanstalkd. NoSQL-Datenbanken schreiben manchmal selbst Daten auf die Platte, aber auch beim Swappen können sensible Daten auf den Festspeicher gelangen.

Glücklicherweise bietet Linux ausgereifte Verschlüsselungsmechanismen dafür, inklusive der Verschlüsselung kompletter Festplatten, die per Default zur Verfügung steht. Dummerweise bieten nicht alle Provider einen vollwertigen Konsolenzugang, der Vorausetzung dafür ist, die komplette Platte zu verschlüsseln, denn man muss beim Booten ein Passwort eingeben. Bevor man die Verschlüsselung der ganzen Festplatte in Betracht zieht, muss man also erst einmal sicherstellen, dass das überhaupt möglich ist.

Auch die zwischen einzelnen Rechnern in der Cloud übertragenen Netzwerkdaten müssen verschlüsselt werden. Beim Einsatz von VLANs und Tunnels entsteht leicht der Eindruck, es handle sich um direkt nebeneinander stehende Systeme, die sich aber tatsächlich in unterschiedlichen Gebäudeteilen, vielleicht sogar in unterschiedlichen Daten-Centern befinden. Ich bin schon gespannt, wann die erste Geschichte eines Einbruchs publik wird, bei dem Einbrecher die virtuelle Netzwerkinfrastruktur eines Providers gehackt und dann Zugriff auf den Netzwerktraffic aller Kunden erlangt haben.

Je nach Anwendung und Infrastruktur gibt es verschiedene Möglichkeiten, den Netzwerktraffic abzusichern. So lässt sich mit IPsec der komplette Verkehr zwischen Systemen verschlüsseln, während sich SSL und SSH dafür eignen, die Übertragung einzelner Dienste zu verschlüsseln.

Speicher

Letztlich befinden sich sensible Daten immer noch ungeschützt im Speicher. Das war in der Vergangenheit vielleicht kein so großes Problem, als man noch der alleine Benutzer eines Servers war. Auf virtualisierten Systemen kann der Hypervisor die Speicherbereiche aller virtuellen Maschinen lesen. Wenn ein Angreifer sich Zugriff zum Hypervisor verschaffen kann, erlangt er damit auch Zugang zum Speicher aller virtuellen Maschinen. Wer also sensible Daten wie Krypto-Schlüssel, SSL-Zertifikate oder Kreditkartendaten verarbeiten will, sollte in letzter Konsequenz auf den Einsatz in der Cloud verzichten.

Viele Cloud-Computing-Systeme sind so aufgebaut, dass sie so zustandslos wie möglich arbeiten. So beeinträchtigt der Ausfall eines Knotens das Gesamtsystem nicht oder nur wenig. Im Extremfall sind den Anwendern Ausfälle sogar willkommen [4] . Einzelne Komponenten wie Datenbanken (eventuell repliziert), Message Queues oder Storage müssen dennoch zuverlässig funktionieren. Eine Technologie wie Ksplice [5] , die das Patchen des Kernels ohne Reboot erlaubt, macht für Linux im Prinzip den ausfallsicheren Betrieb möglich.

Für Provider ist der zuverlässige Betrieb des Hypervisors von größter Bedeutung. Unter allen Umständen will man es vermeiden, virtuelle Maschinen im großen Stil umzuziehen und ganze Farmen von virtuellen Hosts neu booten zu müssen. Derzeit ist Ksplice für Linux verfügbar, aber mit etwas Glück wird es in Zukunft noch für verbreitete Anwendungen erweitert.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023