fotogestoeber - Fotolia

Dem Risiko vergessener Cloud-Instanzen richtig begegnen

Ein seit der Migration vergessener Datenbankserver oder eine ehemalige Testumgebung, nicht mehr wirklich genutzte, aber aktive Cloud-Instanzen können ein Sicherheitsrisiko sein.

Zweifelsohne ist einer der größten Vorteile von Cloud-Instanzen im Vergleich zu herkömmlichen Umgebungen, dass sich ein neues System buchstäblich mit wenigen Klicks in kurzer Zeit einrichten lässt. Das hat die erforderliche Zeit, die notwendig ist, um ein Testsystem oder aber auch einen neuen Produktivserver aufzusetzen, dramatisch reduziert. Und sowohl aus technischer Sicht, wie auch im Hinblick auf die Kosten, bietet der Cloud-Ansatz hier die größere Flexibilität.

Und so schön einfach und schnell es geht, neue Systeme aufzusetzen, so komplex kann es sein, bestehende Systeme wieder stillzulegen. Und besonders in großen Organisationen scheut man da unter Umständen das Risiko. Da gilt es erst sicherzustellen, dass das betroffene System weder jetzt noch in Zukunft einen bestimmten Zweck erfüllen muss, bevor der virtuelle Stecker gezogen wird. Und diesen Nachweis zu erlangen, kann sich je nach Organisation beinahe beliebig komplex gestalten. Meist will dann niemand verantwortlich sein, wenn es darum geht, ein an sich laufendes System aus dem Rennen zu nehmen, das unter Umständen nur einmal monatlich einen wichtigen Bericht erstellt oder eine bestimmte Aufgabe ausführt.

Dies sorgt in Sachen Sicherheit für eine kritische Situation: die Zombie-Cloud-Infrastruktur. Damit sind Systeme gemeint, die nur noch vorhanden sind, weil es am sichersten erscheint, sie einfach laufen zu lassen.

Sicherheitsfaktor Zombie-Cloud-Systeme

Unter Umständen unterliegen diese Systeme nicht mehr in den vorhandenen Wartungs- und Update-Mechanismen, da sie nicht mehr als relevant betrachtet werden oder nicht (mehr) zu den eigentlichen Produktivsystemen zählen. Damit geraten sie zunehmend in Vergessenheit. Wenn diese Systeme gar nur für sehr kurze Zeit benötigt wurden, ist ihre Existenz womöglich nur sehr rudimentär oder schlimmstenfalls gar nicht dokumentiert.

Damit können derlei Instanzen der Albtraum eines jeden Sicherheitsverantwortlichen sein. Denn funktionell kann ja auf diese Systemen vom einfachen Server über die Firewall bis hin zu Datenbankumgebungen ja alles aufgesetzt worden sein.

Werden diese Systeme nicht mehr gewartet, erhalten sie auch keine Sicherheits-Updates, um den neuesten Bedrohungen zu begegnen. Ließe sich bei einer Neuauflage einer Sicherheitslücke wie ShellShock auf Anhieb sagen, welche Systeme betroffen wären? Wenn diese Systeme nicht den normalen Wartungs- und Patch-Mechanismen unterliegen, ist dann überhaupt sichergestellt, dass ihre Existenz und ihr Patch-Level transparent sind? Und wer stellt sicher, dass diese Systeme Updates erhalten?

Klassisches Schwachstellen-Management und der Scan von IP-Adressbereichen können hier Abhilfe schaffen. Damit lassen sich zumindest undokumentierte und ungepatchte Systeme aufspüren. Nachfolgend könnte man die Systeme stilllegen oder updaten, bis die Aufgabe der Instanzen intern geklärt ist.

Längst nicht alle Systeme werden einen entsprechend sicherheitsrelevanten Feed an eine Monitoring-Plattformen liefern. Insbesondere jene Testumgebungen die „mal eben schnell“ und „eigentlich“ nur für kurze Zeit aufgesetzt wurden. Auf denen läuft dann natürlich auch kein Antimalware-Agent, geschweige denn ein hostbasiertes Intrusion Detection System.

Im Hinblick auf die mangelnde Sicherbarkeit der Systeme, hat ein Angreifer, dem es gelingt, ein derartiges System zu kompromittieren, einen trefflichen Ausgangspunkt beziehungsweise eine Hintertür, um weiter ins Unternehmensnetzwerk einzutauchen. Der bereits erwähnte mutmaßlich geringe Patch-Level der betroffenen Einheiten erhöht dieses Risiko noch.

Netzwerkbasierte Kontrolleinheiten wie NGFW (Next-Generation Firewall) oder netzwerkbasierte IDS-Lösungen sollten in der Lage sein, derlei Angriffe zu erkennen. Beispielsweise an dem verdächtigen Traffic von und zu so einem System – unabhängig von der fehlenden Host-basierten Überwachung.

Datenschutz und Datensicherheit berücksichtigen

Abseits des Systems selbst, können diese eine weitere potenzielle Gefahr bergen. Möglicherweise befinden sich auf dem System wichtige, oder gar vertrauliche Daten. Welche Daten sind dies, wer hat Zugriff darauf und wird darauf noch zugegriffen? Diese Fragen sind nicht nur wichtig, wenn man ein entsprechendes System stilllegen will, sondern sie haben auch nachhaltige Auswirkungen auf die Sicherheit, wenn die Maschine noch läuft. Sollten sich beispielsweise personenbezogene Daten auf einem solchen System befinden, dann dürfte in jedem Fall Handlungsbedarf herrschen.

Solche Zombie-Systeme können beispielsweise auch im Zuge einer Dateiserver-Migration entstehen. Bei dieser werden die Benutzerdaten von dem alten Server auf den neuen kopiert. Der alte Server wird aber niemals ordentlich stillgelegt. Und natürlich werden die Zugriffsberechtigungen zwischen altem und neuem Server nach der Migration nicht mehr synchronisiert. Wenn die alten Daten so noch irgendwie zugänglich sind, kann ein erhebliches Sicherheitsrisiko entstehen.

Dem Risiko Zombie-Instanzen richtig begegnen

Es gibt eine ganze Reihe von Ansätzen, wie sich entsprechende Risiken reduzieren lassen. Das Netzwerk auf entsprechende Systeme mit den richtigen Tools zu durchforsten, ist zumindest nachträglich eine hilfreiche Maßnahme. In Sachen Prävention ist es ratsam, dass die Prozesse und Richtlinien im Hinblick auf das Anlegen, Ändern, Dokumentieren und Stilllegen von Systemen sehr genau definiert sind. Eine Kombination aus NGFW sowie IDS-Lösungen sollte in der Lage sein, verdächtigen Netzwerk-Traffic unabhängig von Quelle und Ziel zu identifizieren.

So ganz neu sind weder die Problematik noch die zu treffenden Gegenmaßnahmen. Prinzipiell existierte dieses Risiko auch bei rein physischen Umgebungen schon vor 20 Jahren. Die Verlagerung in die Cloud macht es nur erforderlich, bestehende Best Practices in Sachen Sicherheit entsprechend auf die Cloud-Instanzen anzuwenden.

Folgen Sie SearchSecurity.de auch auf Twitter, Google+, Xing und Facebook!

Nächste Schritte

Abwehrmaßnahmen bei gängigen Angriffen auf die Cloud

Dem Risiko Cloud-Sync-Verzeichnisse begegnen

Personenbezogene Daten aufspüren

Artikel wurde zuletzt im August 2017 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Enterprise-Vulnerability-Management

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close