Die Cloud braucht operative Kontrollmechanismen – insbesondere für die Sicherheit

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Im Januar 2017 wurde das äußerst beliebte MongoDB Opfer einer offenbar immer vorhersehbarer werdenden Angriffstaktik: Daten als Geisel zu nehmen. Die anschließende Untersuchung des Vorfalls ergab, dass die Angreifer größtenteils … nichts ausgenutzt hatten. Das Problem lag nicht an der Software, sondern an der Konfiguration – genauer gesagt an der Standardkonfiguration, die meist auf AWS lief und die Datenbanken für jeden mit einer Internetverbindung frei zugänglich machte.

Dazu gehörte auch das inzwischen berüchtigte CloudPets-Drama, bei dem Sprachnachrichten zwischen Kindern und ihren Eltern, die vermeintlich privat waren, für jeden öffentlich zugänglich waren, der technisch versiert genug war, entweder auf die Datenbank – eine ungesicherte MongoDB-Instanz – zuzugreifen oder die Architektur der App und deren Nutzung von Amazon S3 zu verstehen. Cloud Pets nutzte S3 zum Speichern von Profilbildern und Sprachaufnahmen und verzichtete offenbar auf jegliche Sicherheitsvorkehrungen, sodass jeder mit der entsprechenden Referenz darauf zugreifen konnte.

Damit Sie nun nicht denken, ich hätte es auf CloudPets abgesehen, möchte ich darauf hinweisen, dass das RedLock-CSI-Team kürzlich herausgefunden hat, dass „82 % der Datenbanken in öffentlichen Cloud-Computing-Umgebungen wie Amazon Relational Database Service und Amazon RedShift nicht verschlüsselt sind“.

[dramatische Pause]

Darüber hinaus „akzeptierten 31 % dieser Datenbanken eingehende Verbindungsanfragen aus dem Internet.“

Ich möchte außerdem darauf hinweisen, dass mehr als 27.000 MongoDB-Server kompromittiert wurdenin den ersten Januarwochen 2017. CloudPets war bei Weitem nicht das einzige Unternehmen, das aufgrund seiner eigenen mangelhaften Sicherheitspraktiken von diesem Vorfall betroffen war. Wie in einem Blogbeitrag von MongoDB angemerkt wurde, als die ersten Angriffe öffentlich bekannt wurden: „Diese Angriffe sind vermeidbar – dank der umfassenden, in MongoDB integrierten Sicherheitsvorkehrungen. Sie müssen diese Funktionen korrekt einsetzen, und unsere Sicherheitsdokumentation hilft Ihnen dabei. [Hervorhebung von mir]“

MongoDB war nicht unsicher, sondern schlichtweg überhaupt nicht abgesichert. Das Problem liegt nicht wirklich am Produkt, sondern an den mangelhaften Vorgehensweisen derjenigen, die IoT- und mobile Apps über die Cloud möglichst schnell in die Hände der Verbraucher bringen wollen.

Die Cloud als Katalysator für unsichere Praktiken

Im lokalen Rechenzentrum gibt es sowohl physische Hürden (Firewalls und Ähnliches) als auch betriebliche Hürden (Prozesse und Genehmigungen), die überwunden werden müssen, bevor Software für die Allgemeinheit freigegeben und zur Bereitstellung von Daten eingesetzt wird. Die Cloud weist konzeptbedingt weniger physische Hürden auf und – wie es leider häufig den Anschein hat – auch weniger betriebliche Hürden, die Anwendungen überwinden müssen, bevor sie der breiten Öffentlichkeit zugänglich gemacht werden. Der Abbau betrieblicher Hürden ist im Grunde die heutige Ausprägung des Konzepts der „Rogue IT“ oder „Schatten-IT“. Fachbereichsverantwortliche, die von langen Vorlaufzeiten und Projektlaufzeiten von Jahren statt Monaten frustriert waren, begannen ursprünglich, in die Cloud auszuweichen, um die IT zu „umgehen“. Das bedeutete jedoch auch, dass sie die betrieblichen Hürden umgingen, die eingerichtet worden waren, um die Sicherheit und Leistungsfähigkeit dieser Anwendungen zu gewährleisten.

Das ist kein Problem der Cloud, sondern ein Problem derjenigen, die sie einsetzen. Denn es geht nicht nur um das Argument, das uns seit zehn Jahren aufgetischt wird, nämlich dass „die Bereitstellung physischer Hardware zu lange dauert“; vielmehr ist es die Tatsache, dass „die IT-Genehmigungsprozesse zu lange dauern“, die den Fachverantwortlichen wirklich gegen den Strich geht, wenn sie einfach nur jetzt – noch vor der Konkurrenz – auf den Markt kommen wollen.

Die Teilnehmer einer von Arxan und IBM gesponserten Umfrage aus dem Jahr 2017 zur Sicherheit von Mobil- und IoT-Anwendungen bestätigen dies. Die Befragten machten den Druck auf App-Entwicklungsteams für die mangelhafte Sicherheit von IoT- und Mobilanwendungen verantwortlich. 69 % nannten die überstürzte Entwicklung mobiler Apps als Ursache für anfälligen Code, bei IoT-Anwendungen waren 75 % dieser Ansicht.

Derselbe Druck wirkt sich auch auf die Einrichtung und Absicherung der Datenbanken und Cloud-Speicher aus, die das Ganze überhaupt erst nützlich machen. Das gesamte Konzept von Cloud Pets basiert nicht auf dem Spielzeug selbst, sondern auf dessen Fähigkeit, Daten über das Internet zu senden und zu empfangen. Das bedeutet, dass der Erfolg davon abhängt, dass eine dieser IoT-Apps in aller Eile entwickelt und in der Cloud bereitgestellt wird, um den Veröffentlichungstermin am ersten Weihnachtstag einzuhalten.

Entwickler sind nicht die Einzigen, die für die Sicherheit der Anwendungen verantwortlich sind, deren Bereitstellung ihnen übertragen wurde. Auch diejenigen, die für die Bereitstellung der Cloud-Dienste zuständig sind, auf denen die Anwendung basiert – ob Datenbank-, Dateifreigabe- oder allgemeine Anwendungsdienste –, müssen einen Teil der Verantwortung für deren Absicherung übernehmen. Gleiches gilt für die geschäftlichen Entscheidungsträger, die unrealistische Fristen vorgeben und bei der endgültigen Bereitstellung lediglich ein absolutes Minimum an betrieblichen Freigabekriterien verlangen.

Ja, die IT muss die digitale Transformation vorantreiben und die betrieblichen Freigabeprozesse optimieren, die eine erfolgreiche – und sichere – Bereitstellung von Produkten für Verbraucher ermöglichen. Unternehmen und Entwickler dürfen diese betrieblichen Freigabeprozesse in der Cloud jedoch nicht weiterhin einfach umgehen und durch mangelhafte Sicherheitspraktiken, die auf „Standardkonfigurationen“ beruhen, nicht nur Verbraucher, sondern auch Unternehmensbeteiligte gefährden. Dabei geht es weniger um Produkte als vielmehr um Prozesse: Es muss sichergestellt werden, dass Richtlinien implementiert und Konfigurationen korrekt eingerichtet sind, bevor Apps – und deren Nutzer – vermeidbaren Sicherheitsrisiken ausgesetzt werden.

Wenn Sie einen peinlichen Vorfall vermeiden wollen, müssen Sie zunächst einige grundlegende Sicherheitsvorgaben für die Cloud festlegen und durchsetzen. Dazu gehören zumindest grundlegende betriebliche Kontrollpunkte, die vor der Markteinführung durchlaufen werden müssen.

Unternehmen benötigen diese operativen Kontrollmechanismen heute mehr denn je, da sich die Migration von Anwendungen, die sowohl die Produktivität als auch den Gewinn steigern, in die Public Cloud beschleunigt. Mit dem zunehmenden Migrationstempo wachsen auch die Möglichkeiten für Angreifer, diese Anwendungen auszunutzen.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie