Die Sicherheitslücken bei Prozessoren werden im Rahmen von Public-Cloud-Infrastrukturen noch lange bestehen. Doch selbst wenn die Betreiber dieses Risiko mit immer neuen Patches minimieren, könnten auf Nutzer langfristig Einbußen bei der Performance, eine höhere CPU-Auslastung und insgesamt steigende und schwerer planbare Kosten zukommen. Die Public Cloud wird so nicht nur zum Sicherheits- sondern auch zum Stabilitätsrisiko.
„We have build this internet around the idea that one can safely execute code on a machine and isolate it from other code on the same machine. This is an incredibly fragile assumption.“
Der Journalist Hanno Böck brachte das Dilemma kurz nach Bekanntwerden der massiven Sicherheitslücken bei den meisten in Virtualisierungsumgebungen eingesetzten Prozessoren auf den Punkt. Die Angriffsszenarien Spectre und Meltdown führen zu einer radikalen Wahrnehmungsverschiebung bei der Sicherheit von virtuellen Maschinen. Der Tenor: Unternehmen, die sich gemeinsame IT-Ressourcen teilen (und das ist bei jedem Unternehmen der Fall, das auf einen Public Cloud Service zurückgreift), sind prinzipiell angreifbar, und das so lange, bis eine ganze Prozessorgeneration aus dem aktiven IT-Betrieb verschwunden ist, was gut ein Jahrzehnt dauern kann.
We have build this Internet around the idea that one can safely execute code on a machine and isolate it from other code on the same machine. This is an incredibly fragile assumption.
— hanno (@hanno) 3. Januar 2018
Wie also als Anwender auf die neuen Verhältnisse reagieren? Im Grunde hat sich nichts an der Tatsache geändert, dass Daten, die besonders sensibel sind, auch besonders gesichert werden sollten. Spectre und Meltdown haben uns nur einmal mehr vor Augen geführt, dass das Risiko real ist und weitere Pannen, Datenlecks und Sicherheitslücken mit hoher Wahrscheinlichkeit folgen werden.
Das bedeutet – wenn man nur den Sicherheitsaspekt betrachtet – nicht, dass Nutzer von Public-Cloud-Diensten zwangsläufig ihre gesamte Infrastruktur in eine On-Premise-Umgebung migrieren müssen. Doch gerade bei besonders sensiblen Daten ist es ratsam, eine Neubewertung der Situation vorzunehmen und zumindest eine Teilmenge von Daten zusätzlich zu sichern – beispielsweise auf einem privaten Server mit E2E-Verschlüsselung, also einer hybriden Cloud.
Stabilität und Performance mit On-Premise sicherstellen
Welche Auswirkungen die Meltdown-Patches auf eine Public-Cloud-Infrastruktur haben können, lässt sich am Beispiel der AWS-Umgebung des SaaS-Unternehmens SolarWinds gut beobachten. Die Administratoren bemerkten in den Wochen nach Meltdown hohe Ausfallzeiten, an denen sich ablesen ließ, mit welchen hohen Bemühungen AWS versuchte, die Sicherheitsrisiken einzudämmen. Das Unternehmen veröffentlichte in seinem Blog eine vollständige Dokumentation der negativen Auswirkungen auf die Serverumgebung, die zeigen, dass diese offenbar gravierender ausfielen, als von Intel angekündigt (der Prozessorhersteller erklärte, dass die Performance-Einbußen durch die Patches bei maximal 20 Prozent liegen würden.)
Das Fazit von Solarwinds: Es ist mindestens unsicher, dass es in Zukunft nicht zu vergleichbaren Einbrüchen bei der Performance kommen wird und ziemlich wahrscheinlich, dass jedes Unternehmen mit großen Infrastrukturen, die bei einem Public Cloud Service gehostet werden, irgendwann betroffen sein wird. Das bedeutet einen erhöhten Engineering-Aufwand auf Unternehmensseite und höhere Kosten, um die Performance und Stabilität auf das Niveau vor Entdecken der Sicherheitslücken zu bringen.
Wie sollen Unternehmen also reagieren? Fest steht, dass die Performance in Public Clouds jederzeit unangekündigt sinken kann. Wer sich von einem Drittanbieter abhängig macht, gibt also nicht nur ein Stück weit die Kontrolle über die eigenen Daten ab, sondern begibt sich auch hinsichtlich eines stabilen Betriebs in die Abhängigkeit. Dieser Aspekt mag vor Spectre und Meltdown noch hinnehmbar gewesen sein, für die Zukunft ist es aber mindestens unklar, wieviele Patches nötig sein werden und welchen langfristigen Folgen diese für Anwender mit sich bringen. Was, wenn die nächste Mitigation noch schlimmere Auswirkungen hat? Wie hoch werden die Zusatzkosten sein, um den Betrieb aufrecht zu erhalten?
Absolute Sicherheit für die eigenen Daten und die Performance lassen sich nur im Rahmen einer Infrastruktur realisieren, über die User die vollständige Kontrolle haben, die vor Ort gemanagt werden und bei denen sämtliche Aufgaben in den Händen des Betreibers liegen oder seinem direkten Zugriff unterliegen.
Vielleicht ist das nicht für alle Anwendungen nötig, aber die “own Cloud” sollte nicht nur mit ownCloud beim Thema Enterprise File Sync und Share, sowie der sicheren Zusammenarbeit ein Thema sein, sondern zum festen Bestandteil beim Aufbau von Cloud-Projekten werden, umso mehr nach Spectre und Meltdown. Das liegt in der Tatsache begründet, dass zum aktuellen Zeitpunkt noch niemand wissen kann, wie viele weitere Sicherheitslücken in den bisher nur oberflächlich untersuchten Prozessortechniken verborgen liegen. Wer bei der Sicherheit und der Stabilität keine Abstriche machen will, muss die Private Cloud in seiner Strategie berücksichtigen.
