IaaS und SaaS: verbinden, ohne zu verhindern

«Infrastructure-as-a-Service» (IaaS) oder «Software-as-a-Service» (SaaS) gehen nicht einher mit on-premises IT? Keineswegs! In diesem Blogbeitrag erfahren Sie, wie sich eine IaaS- oder SaaS-Cloud-Umgebung mit der on-premises IT eines Unternehmens verbinden lässt – eine klassische hybride Situation. Der Fokus liegt auf netzwerktechnischen Aspekten, ohne jedoch andere aus den Augen zu verlieren. Um Ihnen den Sachverhalt besser zu illustrieren, schauen wir uns das Szenario anhand eines fiktiven Unternehmens an. So hat wieder einmal die Igel Winterschlaf AG eine Herausforderung zu meistern und wir sind eingeladen, dabei zuzuschauen…

Die Igel Winterschlaf AG in Wachstumsnöten – ein neues ERP und PPS müssen her

Bei der Igel Winterschlaf AG brummt das Geschäft. Die Nachfrage nach Igel-Behausungen geht jeden Herbst, befeuert durch die saisonale Nachfrage, sprichwörtlich durch die Decke. Dieses Jahr entwickelt sich zusätzlich das Geschäft mit mobilen Fertig-Laubhaufen sehr positiv.

Vor diesem Hintergrund hat Frau Stachelig (CEO der Igel Winterschlaf AG) strategische Massnahmen beschlossen. Neue Lösungen für das Enterprise-Resource-Planning (ERP) und das Produktions-Planungs-System (PPS) sollen beschafft werden mit dem Ziel, die auftretenden Performance- und Qualitätsprobleme zu beheben.

Die Wahl fiel auf ein integriertes System, das beide Funktionen vereint: «Sorglos ERP&PPS». Das Produkt besticht mit verschiedenen Betriebsmodellen:

• Betrieb on-premises in einer Kunden Container-Umgebung
• Betrieb in einer Cloud-Infrastruktur (IaaS)
• Bezug als Softwares-as-a-Service (SaaS) aus der Cloud

Das IT-Team der Igel Winterschlaf AG benötigt externe Unterstützung zur Architektur-Integration und Sicherheit der Lösung. Frau Stachelig fragte die InfoGuard an, ob das Architektur-Team sich der folgenden Fragestellungen annehmen könnte:

• Wie soll die Igel Winterschlaf AG Sorglos ERP&PPS an die interne IT anbinden?
• Auf welche Aspekte muss dabei speziell geachtet werden?

Für meine Kolleg*innen bei der InfoGuard war der Fall klar und sie begannen umgehend, das Architektur-Team in gewohnt strukturierter Manier zu unterstützen.

Als erstes gilt: Zusammenhänge erkennen

Als erstes verschaffte sich das Architektur-Team eine Übersicht. Die Igel Winterschlaf AG war über die letzten Jahre stark gewachsen, sodass wenig Zeit blieb für das Architektur-Design. Das Netzwerk der Igel Winterschlaf AG unterscheidet folgende Bereiche:

• Office: Desktop-Arbeitsumgebung für die Kundenbetreuung und Administration
• Fertigung: Produktion der Igel-Häuser und Fertig-Laubhaufen
• Server: Sammeltopf für alle Client-/Server-basierten Anwendungen, inklusive Webshop
• Management: Management-Netzwerk zur Administration der IT-Komponenten
• Entry DMZ Zone: Zentraler Ein-/Ausgangspunkt zum Internet. Zugriff von Kunden auf den Webshop, Remote Access für Mitarbeitende sowie Zugriff von der Igel Winterschlaf AG auf das Internet und auf externe Services

Diese Bereiche sind über eine Firewall miteinander verbunden. Die so geschützten Bereiche werden auch als Zonen bezeichnet. Firewall-Regeln schränken den Verkehr zwischen den Bereichen resp. Zonen sinnvoll ein, beispielsweise kein Zugriff aus der Office-Zone in die Fertigung.

Falsche Fährte: Anforderungen an das zukünftige Cloud-Setup prüfen!

In einem ersten Anlauf fokussierte sich das Architektur-Team auf das bestehende Netzwerk und suchte nach Verbesserungsmöglichkeiten. Schnell wurde jedoch klar, dass dies für die zu bearbeitende Problemstellung nicht zielführend ist. Die Frage ist nicht, ob das aktuelle Netzwerk-Design genügt, sondern was die Anforderungen im zukünftigen Cloud-Setup sind. Dies erfordert unter anderem, das künftige Betriebsmodell des Sorglos ERP&PPS zu definieren.

(Nicht-)Entscheid Nr. 1 – IaaS versus SaaS

Es gab verschiedene Diskussionen mit den Ansprechpersonen der Igel Winterschlaf AG. Es wurde klar, dass ein on-premises-Betrieb von Sorglos ERP&PPS keine sinnvolle Option ist. Die Igel Winterschlaf AG möchte die lokale IT reduzieren, nicht ausbauen. Die Stimmen für den Betrieb von Sorglos ERP&PPS in einer Cloud-Infrastruktur (IaaS) wie für den Service-Bezug von einem SaaS-Provider waren ausgewogen. Letztlich wurde das Architektur-Team beauftragt, für beide Varianten eine Lösung zu skizzieren, damit ein fundierter Entscheid gefällt werden kann.

Das Architektur-Team machte sich an die Arbeit und erstellte folgende Einschätzung:

Tabelle 1: Vergleich Sorglos ERP&PPS IaaS vs. SaaS

Stretched-Netzwerk oder abgegrenzte Umgebung

In einem Stretched Network werden die on-premises-Netzwerkbereiche soweit notwendig zum IaaS-Provider verlängert («stretched»). Dies hat den Vorteil, dass gleichartige Systeme (egal ob on-premises und/oder IaaS) sich im gleichen Netzwerkbereich befinden können.

Das Szenario ist in Abbildung 1 und Abbildung 2 dargestellt. Die Office-Zone mit den Arbeitsstationen für Kundenbetreuung und Administration sowie die Entry-Zonen werden nur bei der Igel Winterschlaf AG benötigt und demnach nicht «stretched».

Abbildung 1: «Stretched Network» bei IaaS

Die Auswirkung von Angriffen steigt in einem Stretched Network. Ein Angriff, zum Beispiel auf das Fertigungs-Netz, würde ebenfalls die direkt verbundene «Gegenseite» kompromittieren. Dies ist in Abbildung 2 durch die rot gestrichelte Linie dargestellt.

Abbildung 2: Auswirkungen einer Kompromittierung

Die abgegrenzte Umgebung ist das Gegenstück zum Stretched Network. Dabei wird die abgegrenzte Umgebung als Ganzes in das Unternehmensnetzwerk integriert. Damit wird eine maximale Isolierung zwischen der Igel Winterschlaf AG und dem Software-as-a-Service-(SaaS-)Provider erreicht. Abbildung 3 veranschaulicht dieses Szenario für die Anbindung:Abbildung 3: Abgegrenzte Umgebung bei SaaS

Ebenso ist ein abgegrenztes Setup für einen Infrastructure-as-a-Service-(IaaS-)Provider möglich. Dies wird in Abbildung 4 gezeigt:

Abbildung 4: Abgegrenzte Umgebung bei IaaS

Noch ein Auftrag für InfoGuard: Provider-Analyse

Frau Stachelig möchte sicherstellen, dass der IaaS-Provider wie auch der SaaS-Provider über ein angemessenes Sicherheitsniveau verfügen. Dazu erteilte sie InfoGuard den Auftrag, eine Provider-Analyse durchzuführen. In dieser soll das Architektur-Team mittels Interviews und Dokumentenstudium eine Einschätzung über das Sicherheitsbewusstsein bei den genannten Providern erstellen. Die Provider-Analyse enthält unter anderem folgende Punkte:

Tabelle 2: Mögliche Farben für die Provider-Analyse

Die Analyse der InfoGuard hat ergeben, dass beide Provider über die notwendigen Zertifizierungen und Sicherheitsmassnahmen verfügen.

IaaS UND SaaS für eine zukunftsweisende Architektur

Frau Stachelig diskutierte die Zusammenstellung aus Tabelle 1 mit der InfoGuard. Kern der Diskussion war, dass die Igel Winterschlaf AG bestimmte Anwendungen braucht und diese am Markt nur als SaaS oder IaaS erhältlich sein könnten. Dadurch wird die Igel Winterschlaf AG in Zukunft Services beziehen, die nach dem IaaS- oder SaaS-Betriebsmodell erbracht werden müssen.

Frau Stachelig folgerte daraus: «Es ist für die Igel Winterschlaf AG nicht zukunftweisend, sich wegen der aktuellen Fragestellung für das Sorglos ERP&PPS nur auf eine der beiden Varianten IaaS oder SaaS als zukünftiges Betriebsmodell festzulegen.» Das Architektur-Team berücksichtigte diesen Umstand in den weiteren Überlegungen.

Sicherheit an erster Stelle

Zu den Kernkompetenzen der InfoGuard AG gehören – klar – Sicherheitsfragen. Das Architektur-Team machte mit Frau Stachelig eine Risikoanalyse, woraus sich ein hoher Schutzbedarf für das Sorglos ERP&PPS ergab. Als «Gold» der Igel Winterschlaf AG zeigte sich das fundierte Wissen, wie hochwertige Igel-Behausungen mit schlanken Fertigungsprozessen produziert werden. Dadurch können Mitbewerber preislich unterboten werden. Dieses im Sorglos ERP&PPS abgebildete Prozesswissen möchte Frau Stachelig besonders gut schützen. Das Architektur-Team suchte nach Möglichkeiten, um die Anforderung zu erfüllen.

Ein Security Device für die Cloud: CASB

Cloud Security Access Broker (CASB) überwachen den ein- und ausgehenden Verkehr von und zum Internet. Spezifisch zum Thema CASB gibt es einen InfoGuard Blogbeitrag. Der CASB erhöht das Sicherheitsniveau der Igel Winterschlaf AG durch:

Tabelle 3: Nutzen eines Cloud Access Security Brokers CASB

Neben dem CASB als spezifischen Cloud Security Device gibt es weitere Schutzmassnahmen, die bei einer Cloud-Anbindung zu berücksichtigen sind. Dabei erweisen sich für das Architektur-Team die Abklärungen aus der Provider-Analyse als hilfreich:

Tabelle 4: Abklärungen Schutzmassnahmen IaaS und SaaS 

Die Aufstellung in Tabelle 4 zeigt, dass die Igel Winterschlaf AG bei einem IaaS-Provider gegenüber dem Servicebezug in Form von SaaS mehr Handlungsoptionen hat. Dafür entsteht der Igel Winterschlaf AG bei IaaS substanziell mehr Aufwand für die Installation, Konfiguration und den Betrieb von Sorglos ERP&PPS als bei einem IaaS-Service-Bezug.

Ein fundierter Entscheid

Die Provider-Analyse zeigte, dass aus Sicherheitssicht Sorglos ERP&PPS beim IaaS-Provider in einem «Stretched Network»-Szenario betrieben werden kann. Weil die Igel Winterschlaf AG die notwendigen Ressourcen und Skills für den Betrieb von Sorglos ERP&PPS in der IaaS-Umgebung fehlen, entscheidet sich Frau Stachelig für das SaaS-Angebot.

Frau Stachelig wünscht eine Visualisierung durch das Architektur-Team, damit für weitere SaaS- oder IaaS-basierte Services das Rad nicht neu erfunden werden muss. Mit Vorteil werden diese Architektur-Blue-Prints im Intranet publiziert, damit sich aktuelle und künftige Projekte und Mitarbeitende daran orientieren können. In der Praxis spart dies Zeit und Nerven.

Blue-Print-Anbindung des SaaS Providers

Die Abbildung 5 zeigt das Setup im SaaS-Modell. Die Igel Winterschlaf AG und der SaaS-Provider sind über zwei Firewalls und das Bastion Virtual Network in Form einer VPN-Verbindung miteinander verbunden. Ein entscheidender Faktor ist, dass der Verkehr zwischen der Igel Winterschlaf AG und dem SaaS-Provider über die Entry-Zone und den sich darin befindlichen CASB geleitet wird. Die SaaS-Umgebung des SaaS-Providers ist nach aussen eine Blackbox.

Abbildung 5: Anbindung SaaS

Da Frau Stachelig auch Architektur-Blue-Prints für zukünftige Anbindungen der Igel Winterschlaf AG an einen IaaS Provider wünschte, lieferte das Architektur-Team zusätzlich weitere (nachfolgende) Grafiken.

Blue-Print-Anbindung des IaaS Providers «Stretched»

Weil die Igel Winterschlaf AG im IaaS-Setup die Sorglos ERP&PPS-Software selbst betreibt, ist dieses in Abbildung 6 dargestellte Setup komplexer. Gut zu erkennen sind die Stretched Networks für Fertigung, Server und Management, die sich über die Igel Winterschlaf AG und den IaaS-Provider erstrecken. Auch hier wird der Verkehr zwischen der Igel Winterschlaf AG und dem IaaS-Provider über die Entry-Zone und den CASB umgeleitet.

Abbildung 6: Anbindung IaaS «Stretched Network»

Blue-Print-Anbindung des IaaS-Providers «Blackbox»

Ein IaaS-Provider kann auch als Blackbox angebunden werden. Dieses in Abbildung 7 dargestellte Vorgehen könnte zum Einsatz kommen, wenn auf der IaaS-Plattform nur eine einzige Anwendung betrieben wird oder Bedenken bestehen, das on-premises-Netzwerk zum IaaS-Provider zu stretchen. Der Verkehr zwischen der Igel Winterschlaf AG und dem IaaS-Provider wird über die Entry-Zone und den CASB umgeleitet.

Abbildung 7: Anbindung IaaS als Blackbox

IaaS oder SaaS als Service Modell: Eine Zusammenfassung

Folgende Punkte gilt es bei der Anbindung von Infrastructure-as-a-Service (IaaS) bzw. Software-as-a-Service (SaaS) an ein Unternehmen zu beachten:

• Das IaaS-Setup lässt einem Unternehmen mehr Freiheiten, ist dafür komplexer.
• Bei SaaS gibt der Service-Provider vieles vor, dafür ist die Komplexität geringer. Die vorgängige Klärung der Frage, welches Modell für ein Unternehmen passt, ist für das Architekturdesign entscheidend.
• Eine gute Architektur erlaubt die nachträgliche Integration unterschiedlicher Betriebsmodelle (IaaS Blackbox, IaaS «Stretched», SaaS).
• Den Fokus nicht verlieren: Wichtig ist, was das Netzwerk in Zukunft leisten soll und welche Schutzmassnahmen dafür aufgrund der Risikoanalyse etabliert werden sollen.
• Ob eine abgegrenzte Umgebung oder ein Stretched Network implementiert wird, hängt von verschiedenen Faktoren ab, unter anderem:
  • Ob nur ein Service in der IaaS-Umgebung betrieben wird
  • Ob genug Vertrauen in die Sicherheitsmassnahmen eines Cloud-Providers besteht, um das on-premises Netzwerk zum Cloud-Provider zu «stretchen»
  • Ob die notwendigen Ressourcen und Skills im Unternehmen vorhanden sind
  • Ob das Unternehmen bereits eine IaaS-Plattform nutzt

Dürfen wir unterstützen?

Die Beantwortung der Fragestellung IaaS oder SaaS liegt je nach Kunde mehr oder weniger auf der Hand. In Zweifelsfällen schätzen unsere Kunden eine fundierte (Zweit-)Meinung, weil der gefällte Entscheid für den Kunden eine langfristige Auswirkung hat. InfoGuard hält für Sie folgende Angebote bereit:

• Architekturreviews mit Sicherheitsfokus: Beurteilung bestehender oder geplanter Architekturen (Cloud, on-premises, hybrid) mit Fokus auf Sicherheit
• Moderation von Workshops zur Klärung offener Fragen

Dank unserer Erfahrung aus vergangenen Kundenprojekten können wir einschätzen, was für Ihre Bedürfnisse die zielführendste Lösung ist. Unser Architekturteam freut sich auf die Zusammenarbeit mit Ihnen!

1) Unter Shared Responsability im Cloud-Umfeld wird die gemeinsame Verantwortung von Cloud-Service-Anbieter und Cloud-Service-Bezüger verstanden. Einzelne Bereiche, wie beispielsweise der Betrieb oder das Patchen, können dabei in der Verantwortung des Cloud-Service-Anbieters, des Cloud-Service-Bezügers oder bei beiden liegen.

2) Zum Beispiel werden alle Transaktionen von User A, unabhängig der auf den verwendeten Systemen unterschiedlichen Login-IDs so normalisiert, dass die Transaktionen als Einheit abgefragt werden können.