© 06photo , 123RF

Das Thema Sicherheit ist ein Evergreen in der IT – das gilt auch für die Cloud. Doch wie sichern Admins sich in der Wolke effizient gegen Attacken ab? Das Linux-Magazin zeigt Wege und Lösungen.

Wenn es ein IT-Thema mal in die Tagesschau schafft, hat das selten Gutes zu bedeuten: In der Regel geht es dann um Angriffe auf Websites oder Institutionen, um Passwortklau und ganz generell um Skandale. Das zeigt, dass Sicherheit zu den wichtigsten IT-Themen überhaupt gehört. Geht etwas schief, wird aus dem Admin im schlechtesten Fall ein Beschuldigter, wenn man ihm grobe Fahrlässigkeit nachweist.

Und verliert die eigene Klientel das Vertrauen in die Fähigkeit, ein System gut und sicher zu betreiben, geht das mit erheblichen finanziellen Einbußen einher, die gerade nach einem erfolgreichen Großangriff potenziell tödlich für eine Firma sein können.

Die Cloud ändert daran übrigens wenig. Zugegeben, die Herausforderung liegt hier anders als bei konventionellen Setups nicht mehr alleine beim Anbieter. Früher verkaufte der dem Kunden ein schlüsselfertiges Setup, in das dieser höchstens noch seine Website einspielen musste. Heute ist er eher ein Plattformanbieter. Und der Kunde betreibt seine Infrastruktur auf solchen Plattformen wahlweise selbst oder er beauftragt jemand anderen damit – der wiederum nicht zwangsläufig zugleich der Plattformanbieter sein muss.

Alle Beteiligten teilen sich also die Verantwortung für die Security: Aus der Perspektive der Plattform achten deren Admins darauf, dass Standards wie sinnvolle Netzwerksegmentierung, Software-Defined Networking, Security Policy Enforcement und andere Funktionen implementiert sind und auch wie gewünscht funktionieren, um so auf Plattformebene Sicherheit herbeizuführen. Beim Ausrollen der eigenen Applikation in der Cloud achten dann Kunden und externe Dienstleister ebenso darauf, dass sie die Best Practices in Sachen Security einhalten.

Doch was sind diese Best Practices im Kontext der Cloud? Wie schützen Kunden und externe Dienstleister ihre virtuellen Umgebungen vor der riesigen Fülle verschiedener Angriffe, die denkbar sind? Und wie merken sie überhaupt, dass etwas nicht stimmt? Viele konventionelle Lösungen aus der Vergangenheit funktionieren in Clouds nicht mehr – da stellt sich die Frage: Welche Konzepte und Werkzeuge stehen zur Verfügung, um Ganoven von vornherein die lange Nase zu zeigen? Das Linux-Magazin versetzt sich in diesem Beitrag in die Perspektive eines Cloudkunden und geht eben diesen Fragen nach.

Was ist das Bedrohungsszenario?

Wer sich mit Security im IT-Kontext bereits befasst hat, der weiß, dass die erste relevante Frage immer die nach dem Bedrohungsszenario ist, dem man widerstehen möchte. Daraus ergeben sich individuelle Sicherheitskonzepte, die im schlechtesten Fall keine gemeinsamen Komponenten aufweisen. Wer umfassende Sicherheit will, kommt um diese Arbeit nicht herum. Bedrohungsszenarien gibt es auch aus Sicht des Cloudkunden mehr als genug.

Das geht bereits bei der Wahl der richtigen Plattform los. Wo hat die Firma, der man die eigenen Daten anvertraut, ihren Sitz, und wen muss sie qua Gesetz dort gegebenenfalls an ihre Kundendaten heranlassen? Folgt der Anbieter den gängigen Best Practices auf der Hardware-ebene und kann er das nachweisen, etwa in Form entsprechender Zertifikate? Und welche Cloudsoftware nutzt der Anbieter? Hält er sie aktuell?

Hat sich der Kunde für einen Anbieter entschieden, ist die nächste Frage, welche Funktionen er in seiner Plattform bietet, um die Sicherheit zu erhöhen. Gibt es etwa die Option, Firewallregeln auf Plattformebene zu installieren? Gibt es Features wie VPN as a Service oder andere mit Sicherheitsbezug? Ist es möglich, Volumes zu verschlüsseln?

Dann gibt es noch eine Menge Software, die der Admin direkt auf der Ebene seiner virtuellen Maschinen installieren kann: Klassische Honeypots sind ein Beispiel. Schließlich kann auch eine andere Art der Bedrohung ein echtes Problem sein: manipulierte Abrechnungsdaten. Wie misst ein Kunde also selber nach, was er verbraucht, um ein Mittel gegen offenbar falsche Abrechnungen zu haben?.

So ein Blech

Eine entscheidende Frage auf dem Weg in die Cloud ist die nach dem Anbieter des Vertrauens. Besonders bequem ist es, sich einfach bei einem der großen Anbieter einzumieten – in Deutschland sind das AWS, Azure und Googles Cloudplattform. Wobei Azure und Google kaum ins Gewicht fallen – das mit weitem Abstand größte Stück des globalen Cloudkuchens hält aktuell Amazon.

Aus nachvollziehbaren Gründen: Jeden Tag erweitert der Anbieter sein Portfolio um mehrere As-a-Service-Features. Komponenten wie Datenbanken oder Load Balancer betreiben Kunden in AWS schon seit Jahren nicht mehr selbst, sondern als As-a-Service-Anwendung. AWS ist bequem, AWS ist stabil und zuverlässig und obendrein vergleichsweise günstig – damit ist, so möchte man meinen, ja im Grunde alles klar.

Doch so leicht ist es dann doch nicht. Amazon, Microsoft und Google sind amerikanische Unternehmen, die vorrangig US-amerikanischem Recht unterliegen. Da helfen alle Beteuerungen nicht, dass man Daten auf Servern in anderen Ländern nicht herausgibt: Klopfen FBI und CIA an die Türen der Firmen, werden sie wohl kooperieren (müssen). Das tun sie schon, um nicht dauerhaft in den Fokus der Behörden zu geraten. Microsoft ist zudem in den USA etliche Male vor Gericht baden gegangen und zur Kooperation gezwungen worden.

Mehr noch: Als Cloudkunde von AWS & Co. hat man quasi keine Chance, sich gegen das Abschnorcheln von Daten durch Dritte effektiv zu wehren. Denn es ist schwierig bis unmöglich, ein System sinnvoll abzusichern, auf das ein potenzieller Angreifer im Falle eines Falles physischen Zugriff hat. Klar: Ein Werkzeug der Wahl sind verschlüsselte Volumes, doch auch die helfen kaum. Denn solange sie aktiv und eingehängt sind, kann jeder mit Zugriff auf die Hardware sie auslesen, ohne dass der Kunde etwas davon merkt.

Wer seine Daten in die Obhut von AWS & Co. gibt, muss nach deren Regeln spielen. Zumindest für kritische Daten, etwa Geschäftsgeheimnisse, verbietet sich daher deren Nutzung – es gibt hier schlicht keinen Weg, sich effektiv zu schützen.

Woran erkennt man gute Anbieter?

Nun ist es zum Glück nicht so, dass AWS, Azure und Google die einzigen aktiven Anbieter für Public Clouds sind. T-Systems mit seiner Open Telekom Cloud betreibt diese ausschließlich in Deutschland und unterliegt insofern auch nur deutschen Datenschutzrichtlinien. Auch noch weitere Anbieter buhlen um die Gunst der Nutzer. Stellt sich nur die Frage: Woran erkennt ein Kunde eigentlich, dass seine Cloud gut gewartet wird? Die etwas ernüchternde Antwort lautet allerdings: Ad hoc erst mal gar nicht. Doch gibt es Indikatoren, aus denen sich Rückschlüsse ziehen lassen.

Wer selbst Kunde einer Cloudplattform ist, sollte auf die Zertifikate, die der Anbieter vorweisen kann, penibel achten. Doch Vorsicht: Zertifikate sagen in der Regel nichts darüber, ob eine Cloud tatsächlich sicher ist. Sie dokumentieren jedoch, inwieweit die Abläufe bei einem Anbieter standardisiert und dokumentiert sind und den Best Practices des jeweiligen Zertifizierers entsprechen.

ISO27001 ist ein Beispiel, das viele aus eigener Erfahrung kennen dürften. Hinzu gesellt sich SOC2 C5 vom BSI, das ebenfalls vor allem grundsätzliche Prozesse nachweist. Deutlich umfangreicher ist PCI-DSS, das entsprechend schwerer zu bekommen ist.

Es gilt wie üblich: Kann ein Anbieter etwaige Zertifikate nachweisen, so bedeutet das in jedem Fall, dass er seine Plattform entsprechend der jeweiligen Regeln auf Herz und Nieren hat prüfen lassen und er diese Prüfung bestanden hat. Auf der Suche nach einem in Deutschland beheimateten Cloudanbieter, sind solche Zertifikate ein Fingerzeig (Abbildung 1).

Abbildung 1: Zertifizierungen – hier SOC2 C5 vom BSI – bescheinigen keine Sicherheit, aber Standards, die Sicherheit ermöglichen.

Die Basics in der Cloud

Wer sich für einen Anbieter entschieden hat, setzt im nächsten Schritt meist erst mal die grundsätzliche virtuelle Umgebung auf, in der er seine Dienste betreiben möchte. Hier sind ein paar Basics zu beachten, die implizite Sicherheit ermöglichen und auf der Annahme “Vorsicht ist besser als Nachsicht” beruhen.

Denn leider sieht man bis heute selbst Public-Cloud-Setups, die Admins einfach und stur aus konventionellen Umgebungen in die Cloud kopiert haben. Das ist nicht verwerflich, lässt den größten Teil der Vorteile aber außen vor, die Nutzer beim Umstieg in die Cloud eigentlich mitnehmen wollen.

Grundsätzlich gilt: Virtuelle Umgebungen in der Cloud haben im Idealfall so wenige persistente Daten wie nötig. Das erreicht der Admin einerseits durch einen hohen Automationsgrad – bevorzugt durch Orchestrierung, die jede moderne Cloud anbietet. Und andererseits durch die konsequente Umsetzung einer funktionalen CI/CD-Umgebung, die virtuelle Maschinen oder Container völlig automatisch erstellen kann.

Konkret bedeutet das: Ist bei einer VM oder einem Container in einer Cloud ein Update durchzuführen, gibt es idealerweise einen Automatismus, der gleich eine neue VM erzeugt oder einen neuen Container baut. Der tritt dann an die Stelle der alten Instanz, was beinahe ohne Downtime möglich ist, und der Admin hantiert nicht mit einzelnen Systemen herum, deren Versionsstände er händisch nachhalten muss.

Nützlich ist es auch, wenn sich ein Setup in wenigen Minuten per Orchestrierung und Automation aus der Dose erneut bauen lässt, sodass anschließend nur die Daten – etwa in Form einer Datenbank – wieder einzuspielen sind. Das ist effektive, gelebte Sicherheit auf der Höhe der Zeit, die Probleme durch veraltete Software auszuschließen hilft.

Firewalls verwenden

Natürlich entbindet ein solches Setup den Admin aber nicht davon, auch die Basics in Sachen Sicherheit im Fokus zu behalten. Wie auf physischen Systemen auch ist es in Clouds eine gute Idee, das eigene Setup vor Angreifern zu schützen, beispielsweise durch die Verwendung von Firewalls. Dazu sollte sich der Admin allerdings vor Augen halten, dass Netzwerke in Clouds etwas anders funktionieren als in konventionellen Setups. Denn in Clouds sind die VMs oder Container nie direkt an das Internet angeschlossen.

Um das Ziel zentraler Verwaltbarkeit zu erreichen und ressourcenschonend vorzugehen, existieren in Clouds stattdessen die so genannten Network Nodes, über die Netzwerkverkehr umgeleitet wird. Je nach Software-Defined-Networking-Spielart kann auch jeder Knoten einer Cloud ein Netzwerkknoten sein – dass der Traffic umgeleitet wird, ändert sich dadurch zunächst nicht.

Nun wäre es denkbar, seine Firewallregeln direkt in den VMs zu hinterlegen, also quasi an der Cloud vorbei. Damit beraubt sich der Admin jedoch der Managementwerkzeuge, die die meisten Clouds API-gesteuert anbieten und die die entsprechenden Firewallregeln stattdessen auf Plattform-Ebene etablieren.

Im Fachjargon heißt das üblicherweise Security Group: Jeder virtuelle Netzwerkport ist mit mindestens einer Security Group verbunden, und pro Gruppe legt der Admin fest, welche Zugriffsregeln gelten. Die Cloud setzt diese Regeln dann in Netfilter-Anweisungen um und aktiviert sie an der richten Stelle im (physischen) Underlay.

Admins tun gut daran, einmal eine funktionale Security-Group-Konfiguration für ihre virtuellen Umgebungen zu bauen und diese anschließend in einem Template für den Orchestrierer der jeweiligen Plattform abzubilden (Abbildungen 2 und 3). Denn so lassen sich die Regeln jederzeit recyceln und sogar auch von außen modifizieren.

Abbildung 2: Security Groups steuern in Clouds häufig, welche Pakete es bis zu den VMs schaffen – dazu legt der Admin erst eine Security Group an …

Abbildung 3: … und versorgt sie hinterher mit konkreten Regeln im Hinblick auf die erlaubten Verbindungen.

Ein weiterer Vorteil: Schafft ein Angreifer es doch – auf welchem Wege auch immer – in die virtuelle Umgebung einzubrechen, greifen die gesetzten Firewallregeln noch immer. Der Angreifer kann also nicht etwa den Port 22 nach außen durch Löschen der entsprechenden Netfilter-Regel öffnen, um sich per SSH selbst ins System zu lassen.

Wie Security Groups sich in AWS nutzen lassen, erläutert [1]. Für Open Stack findet sich eine Anleitung unter [2].

Scherereien mit IDS

Der eine oder andere Admin ist aus seinen konventionellen Setups womöglich die Arbeit mit Intrusion Detection Systems gewöhnt. Diese lassen sich aus den erwähnten Gründen in einer Cloud allerdings meist nicht ad hoc einsetzen. In einem Setup mit echtem Blech konfigurieren Admins sie meist so, dass ein Port am Switch den ganzen Traffic aller anderen Ports gespiegelt bekommt und ihn auswertet. Der Traffic geht also nicht durch das IDS hindurch, bevor er die eigentlichen Zielsysteme erreicht.

Ein solches Setup lässt sich in Clouds wegen der erwähnten Network Nodes nicht realisieren, denn auf jene haben die Nutzer im Regelfall keinen Zugriff. Möchten Nutzer trotzdem in einer Cloud ein IDS betreiben, sind sie auf die Kooperation ihres Cloudproviders angewiesen. Wenn der eine SDN-Lösung wie Open Contrail einsetzt, bietet sich unter Umständen die Möglichkeit, virtuelle Netzwerkfunktionen (VNF) in der eigenen virtuellen Umgebung zu verwenden. In der Praxis hinterlegt der Nutzer dann ein Betriebssystem-Abbild mit Suricata im Imagespeicher der Cloud und startet anschließend eine VNF-Instanz auf Basis eben jenes Suricata-Abbilds.

Wie VNF konkret umgesetzt sind, unterscheidet sich zwischen den einzelnen SDN-Implementationen stark. Gemeinsam ist hingegen fast allen Umgebungen, dass der direkte Zugriff auf den virtuellen Router der Pakete nicht möglich ist. Bietet der Cloudprovider also keine VNF-Funktionalität, guckt der Kunde in die sprichwörtliche Röhre.

Security Appliances

Vorsicht ist auch geboten, bevor der Kunde eine Appliance für den Betrieb in der Cloud kauft, die Funktionen wie IDS angeblich out of the Box enthält. Prominent vertreten auf diesem Markt ist Kaspersky, das sein Hybrid-Cloud-Security-Produkt gerne unters Volk bringen möchte. Prinzipiell liest sich die Produktbeschreibung gut: Wer ein hybrides Cloudkonzept verfolge, solle mit dem Produkt in der Lage sein, die eigene Cloud ebenso wie die eigenen Daten in einer großen Public Cloud gut und zuverlässig gegen Angriffe abzusichern.

Dazu enthält das konkrete Kaspersky-Produkt im Beispiel etwa ein IDS und ein IPS (Intrusion Prevention System) sowie verschiedene weitere Funktionen, die das Steuern und Blockieren von Netzwerkverkehr ermöglichen. Die Leistung von Kaspersky besteht hier wohl eher in der Bündelung verschiedener Komponenten zu einem fertigen Produkt, das sich im Stil einer Appliance schnell ausrollen und nutzen lässt.

Trotzdem ist bei solchen Angeboten Vorsicht geboten, denn oft unterscheidet sich die Definition der Cloud bei solchen Anbietern von der Definition, von der etwa Amazon ausgeht. Bei Kaspersky etwa kommt Open Stack, die am weitesten verbreitete Open-Source-Lösung für Cloudumgebungen, gar nicht vor. Hier ist die Annahme, dass die Private Cloud des Kunden auf Produkten wie VMware basiert und als Public Cloud AWS, Azure & Co. zum Einsatz kommen.

McAffee bietet mit seinem Public-Cloud-Server Security immerhin die Möglichkeit, sich per Connector-Modul in Open Stack einzuklinken und dort Features wie Intrusion Detection anzubieten.

Allerdings: Wenn die Plattform VNF-Features ab Werk beherrscht, lassen sich jene eben auch händisch ohne den Umweg einer proprietären Lösung nutzen. Ob der Kunde einem Hersteller letztlich Geld dafür zahlen möchte, weniger Arbeit bei der Implementierung der Cloud zu haben, entscheidet er für sich selbst. Eine technische Notwendigkeit dafür gibt es jedenfalls nicht.

Verschlüsselte Volumes

Einen kleinen Beitrag zum Thema Datensicherheit leisten immerhin die bereits erwähnten verschlüsselten Volumes. Snapshots von Volumes lassen sich in den meisten Cloudumgebungen ebenfalls verschlüsseln, sodass die dort gelagerten Daten gegen die Blicke oder Finger Dritter geschützt sind.

Beim tatsächlichen Volume, das gerade in Benutzung ist, ist das aus den beschriebenen Gründen nicht so leicht: Im laufenden Betrieb muss das Volume schließlich in aller Regel beschreibbar in das Dateisystem eingehängt sein, und das geht nur entschlüsselt.

Übrigens: Wer Backups seiner Umgebung in einem Objektspeicher ablegt, sei es Amazons S3 oder ein privater Speicher, etwa auf der Basis von Ceph, der tut gut daran, die Verschlüsselungsfunktion seiner Backup-Software zu nutzen. Fast jedes moderne Backup-Programm bietet entsprechende Features, doch bisher sind sich noch zu wenige Admins dieser Tatsache bewusst.

Vorsicht bei Pentests

Wie bereits erwähnt, lassen sich bei einer Cloud mehrere Ebenen im Hinblick auf Security unter die Lupe nehmen. Da sind einerseits das blanke Blech und die fest zur Cloud gehörenden APIs – hierfür trägt der Anbieter die Verantwortung. Auf dieser Infrastruktur laufen die virtuellen Maschinen der Kunden, für die jene zuständig sind. Üblicherweise ist als Übergabepunkt die einzelne VM und dort im Detail deren Linux-Kernel definiert.

Wer sich ein Setup gebaut hat und es auf Herz und Nieren testen oder nachsehen will, wie es in Sachen Security um eine Cloud bestellt ist, der kann dafür grundsätzlich Kali Linux nutzen. Die Distribution hat sich in den vergangenen Jahren einen Namen als auf Pentests spezialisiertes System gemacht.

Wer Kali Linux auf Hardware betreiben möchte, braucht dafür in der Regel ein eher potentes System, das er für diesen Zweck abstellt. Das widerspricht allerdings dem Konzept der Cloud, die insbesondere den Kunden ja von jeder Notwendigkeit befreien soll, Hardware vorzuhalten. Es hat sich deshalb in den vergangenen Jahren als ein Konzept etabliert, Penetration Tests in VMs in Clouds zu betreiben.

Phasenweise haben das jedoch so viele Admins getan, dass die großen Public Clouds beinahe wie Botnetze daherkamen – Kali Linux etwa fährt diverse (schwere) Angriffe gegen die Infrastruktur. Gerät eine Kali-Linux-Instanz in falsche Hände, lässt sich damit, kombiniert mit der Power virtueller Instanzen, in der Cloud einiger Unsinn anstellen.

Aus diesem Grund geben alle größeren Public-Cloud-Anbieter strikt vor, ob und unter welchen Umständen Kali Linux in einer VM auf einer Plattform betrieben werden darf. Für AWS beispielsweise gilt, dass der Passwort-basierte Login für VMs mit Kali Linux ausgeschaltet sein muss, sodass nur der Login per SSH-Schlüssel in eine VM möglich ist.

Ferner – aber das versteht sich fast von selbst – ist es natürlich untersagt, Kali Linux zu anderen Zwecken einzusetzen, als für die eigene Umgebung einen Penetration Test durchzuführen. Nutzer tun gut daran, die Grundregeln der Cloudanbieter zu befolgen, denn im schlimmsten Fall war es das ansonsten mit dem jeweiligen Account in der Cloud (Abbildung 4). Es gilt aber trotzdem: Wer sich an die von dem Anbieter aufgestellten Regeln hält, findet in Kali Linux ein potentes Werkzeug.

Abbildung 4: Kali Linux gilt als Hacker-Distribution, ist in Wahrheit aber ein effizientes Pen-Testing-Tool.

Das leidige Thema Abrechnung

Ein letztes Bedrohungsszenario in der Cloud dreht sich weniger um eine konkrete technische Bedrohung und eher um eine kaufmännische: Wie verhindert der Kunde einer Cloud, dass er bei der Abrechnung über den Tisch gezogen wird? Alle Anbieter versprechen schließlich die “minutengenaue Abrechnung” und die Verrechnung ausschließlich der genutzten Ressourcen.

Der Kunde ist zumindest in der Standardsituation allerdings darauf angewiesen, den auf der Rechnung angegebenen Zahlen zu glauben. Denn an die Systeme im Inneren der Cloud, die etwaige Nutzdaten erheben, kommt er in aller Regel nicht heran. Wie schützt er sich an dieser Stelle effektiv und effizient gegen Missbrauch der Abrechnungshoheit?

Die Antwort darauf ist so simpel wie frustrierend: Effektiv gelingt das nur, wenn Leute ihre eigenen Messungen anstellen und sie regelmäßig mit den Zahlen des Anbieters vergleichen. Leichte Unterschiede werden sich nicht vermeiden lassen, doch grobe Differenzen fallen schnell auf und erlauben es, Rückfragen beim Anbieter zu stellen.

Leider kann nur nachmessen, wer eine Software wie Prometheus oder Influx DB nutzt, die Zeitreihendaten verarbeiten und für lange Zeit speichern kann. Zusätzlich braucht es Software, die auf den Zielsystemen jene Metrikdaten einsammelt – beides zusammen verursacht einigen administrativen Aufwand.

Immerhin: Abbilder und Container mit Prometheus & Co. existieren und lassen sich in allen Umgebungen schnell in Betrieb nehmen. Das Ausrollen des Node Exporter von Prometheus oder von Telegraf aus dem TICK-Stack geht ebenfalls leicht von der Hand. Der Mühe Lohn ist eine verlässliche Datenbasis, die Ungereimtheiten schnell aufzudecken erlaubt (Abbildung 5).

Abbildung 5: Mit Prometheus lassen sich Metrikdaten etwa von laufenden Kubernetes-Clustern aufzeichnen – so werden Rechnungsdaten prüfbar.