"Cloud-washed"-Lösungen, also Services, die ursprünglich nicht für die Cloud entwickelt wurden, unterscheiden sich auf den ersten Blick nicht von "Cloud-Native"-Sicherheitsmodellen. Beide Konzepte werden heute als Cloud-Services angeboten, obwohl sie auf zwei verschiedenen Architekturmodellen basieren. Deshalb stellt sich die Frage, welche Aspekte müssen bei der Wahl eines Ansatzes berücksichtigt werden.
Gastbeitrag von Irene Marx, Area Manager Alpine bei Zscaler
Cloud-Native-Lösungen, die speziell im Hinblick auf die Anforderungen im Cloud-Zeitalter entwickelt und optimiert wurden, differieren zu Ansätzen, die auf klassischer Sicherheits-Hardware basieren. Hardware-Lösungen, die für die Cloud umfunktioniert wurden, werden als Cloud-washed bezeichnet. Bei der Implementierung und im Betrieb dieser Modelle gibt es erhebliche Unterschiede zu "Cloud-Native"-Lösungen. Besonderes Augenmerk verdienen im Auswahlprozess deshalb Themen wie Skalierbarkeit, Verwaltungsaufwand und Service Level Agreements.
Nur auf den ersten Blick stellen sich die beiden Ansätze ähnlich dar, denn die Sicherheitsfunktionalität ist in beiden Fällen jenseits des Unternehmensperimeters angesiedelt. Bevor jedoch die Entscheidung für einen Ansatz fällt, tun Unternehmen gut daran, im Vorfeld die richtigen Fragen zu stellen. Sie sollten zunächst ihre Anforderungen an Service-Qualität und die Messbarkeit der Service Level Agreements hinterfragen und anschliessend den Operations-Aufwand eruieren. Während der Implementierung ersparen sie sich auf diese Weise böse Überraschungen. Darüber hinaus ist der Umbau einer bestehenden IT-Architektur eine Kostenfrage.
Aus Alt wird nicht immer neu
Security Appliances, die auf Hardware basieren, wurden ursprünglich entwickelt, um am Perimeter eines Unternehmens die Abschirmung gegen Gefahren aus dem Internet zu übernehmen. Beispiele dafür sind ein Web-Proxy, die Sandbox, DLP-Lösung oder Firewall. Um der wachsenden Nachfrage nach Cloud Security Rechnung zu tragen, funktionieren die Hardware-Anbieter dieses Lösungsmodell um und verlagern ihre Boxen vom Netzwerk des Unternehmens in ein Cloud-Rechenzentrum und verkaufen diesen Ansatz als Cloud-Lösung. Da die Time-to-Market oftmals entscheidet, wird ein vorhandener Ansatz wiederverwendet und als Hybrid-Modell oder Cloud-washed Security angeboten.
Hardware, die ursprünglich nur für das Unternehmensnetzwerk entwickelt wurde, ist allerdings nicht auf Multimandantenfähigkeit ausgelegt. Wenn der Datenverkehr verschiedener Kunden gleichzeitig über eine Hardware im Rechenzentrum des Cloud-Service Anbieters läuft, müssen die geteilten Ressourcen zuverlässig getrennt werden. Darüber hinaus müssen Failover-Konzepte evaluiert werden: Wie wird im Bedarfsfall der Datenverkehr von einem Rechenzentrum auf ein anderes umgelenkt?
Von dieser Vorgehensweise sind diejenigen Cloud-Security Anbieter abzugrenzen, die ihre Lösungen von Grund auf neu entwickeln und dabei von vorneherein auf die Vorteile der Cloud setzen. Diese 100 prozentigen Cloud-Modelle wurden unter Einsatz von Zeit und Ressourcen für die neuen Anforderungen der digitalen Transformation entwickelt. Sie setzen auf die Elastizität der Cloud und berücksichtigt bereits in der Entwicklungsphase moderne Anforderungen an die Servicequalität, Multimandantenfähigkeit oder auch Authentifizierung.
Unternehmen testen in der Regel zunächst verschiedene Konzepte im Proof of Concept, bevor sie Investitionen tätigen. Es empfiehlt sich, beide Lösungsmodelle an mehreren Standorten zu evaluieren und dabei mobile Anwender einzubeziehen, um die Elastizität der unterschiedlichen Cloud-Architekturen zu erleben. Geprüft werden sollte beispielsweise, wie die Log-Daten aus verschiedenen Standorten zusammenfliessen und ob für deren Auswertung gegebenenfalls manueller Aufwand entsteht.
Auch den zeitlichen Ablauf des Rollouts gilt es zu hinterfragen. Bei den Cloud-washed-Ansätzen werden zuerst einmal die zusätzlich nachgefragten Ressourcen für das Cloud-Rechenzentrum angeschafft. Eine von Anfang an nur für die Cloud entwickelte Cloud-Native-Lösung kann aufgrund der gegebenen Skalierbarkeit sofort für alle Nutzer aktiviert werden. Darüber hinaus sollte der Verwaltungsaufwand im laufenden Betrieb beider Modelle verglichen werden.
Am Beispiel einer Next Generation Firewall offenbart sich der Unterschied zwischen reinen Cloud-, virtuellen oder Hardware-basierten Lösungen. Für den Schutz von firmeninternen Rechenzentren haben Hardware-Firewalls, die vor der Server-Farm stehen, noch ihre Berechtigung. Da dort ohnehin ein hoher Verwaltungsaufwand anfällt, wird die Firewall vor Ort mit gewartet. Ist die Anzahl der Rechenzentren auf zwei oder drei Standorte weltweit limitiert, ist auch der Aufwand kalkulierbar.
Aufgrund der Cloudifizierung verlangen Unternehmen allerdings zunehmend mehr Flexibilität von ihrer Firewall. Werden Anwendungen in die Cloud verlagert, ist der Schutz dort erforderlich wo der Zugriff erfolgt. Ein Lösungsansatz, der dieser Anforderung nachkommt, ist das Hosting virtueller Firewalls beispielsweise bei AWS. Bei einer solchen in der Cloud gehosteten Firewall profitiert der Kunde nicht wirklich von den Vorzügen des Cloud-Effekts, denn die Anzahl an Standorten und der Administrationsaufwand ist nach wie vor ein limitierender Faktor.
Fazit
Im Unterschied zu einer virtualisierten Firewall ist bei einer echten Cloud-Firewall der Service-Anbieter für Updates, Upgrades und Patches verantwortlich. Die Aufgabe des Aufsetzens und der Wartung dieser Lösung inklusive der Anforderungen an die Skalierbarkeit geht in dessen Verantwortung über. Zieht ein Unternehmen diesen Ansatz in Betracht, sollten die Service Level Agreements genau geprüft werden. Denn nicht nur der Betrieb, sondern ebenfalls das Trouble Shooting wechselt in den Verantwortungsbereich des Anbieters eines Cloud Services. Ein echter Cloud-nativer Dienst ist also von Grund auf als Security-as-a-Service aufgesetzt.
