IaaS und SaaS: verbinden, ohne zu verhindern

Geschrieben von Markus Pfister | 24. Okt 2022

«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:

Merkmal	Sorglos ERP&PPS als IaaS bei einem Cloud-Service-Provider	Sorglos ERP&PPS als SaaS
Authentisierung	Federation, Freiheit in der Ausgestaltung sofern diese die Anforderungen von Sorglos ERP&PPS abdecken	Federation nach Vorgabe des SaaS-Providers
Betrieb	Shared Responsability¹: Cloud-Service-Provider ist für die Infrastruktur, die Igel Winterschlaf AG für die darauf laufenden Anwendungen zuständig.	Shared Responsability: Die Verantwortung für Betrieb liegt beim SaaS-Provider.
Monitoring	Erweitern der bestehenden Monitoring-Lösung zum Cloud-Service-Provider. Beim Cloud-Provider entstehende Events werden mit der Monitoring-Lösung der Igel Winterschlaf AG in Beziehung gebracht (korreliert)².	Monitoring-Tool des SaaS-Providers
Stretched Network	Die voraussichtlich benötigten Netzwerkbereiche: Entry, Server und Management werden mit dem entsprechenden Gegenpart bei der Igel Winterschlaf AG verbunden («Stretched Network»)	Nicht verfügbar
Zugehörigkeit	Die IaaS-Umgebung wird als ein Bereich der Igel Winterschlaf AG «Stretched Network» oder als abgegrenzter Bereich betrachtet.	Die SaaS-Umgebung ist ein abgegrenzter Bereich.

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:

Was	Beschreibung möglicher Betrachtungspunkte
Architektur	Zugangskanäle zum Provider Management-Interfaces Monitoring-Lösung und unterstützte Protokolle oder Tools Technischer Aufbau der Plattform
Business Continuity	Massnahmen zur Aufrechterhaltung eines unterbruchfreien Betriebs Datensicherung- und Backup
Erfahrung	Wie lange der Provider im Geschäft ist Vorhandene Referenzen
Kosten	Vergleich mit anderen Anbietern
Legal & Compliance	Datenschutzrechtliche Aspekte, zum Beispiel Geolokation der Datenspeicherung Rechtliche Begebenheiten (Escrow) beim Wechsel zu einem anderen Provider Aktuelle Zertifizierungen
Sicherheit	Etablierte Massnahmen beim Provider, um die Sicherheit von Sorglos ERP&PPS zu gewährleisten (Firewall, Monitoring, Threat Detection and Prevention, Verschlüsselung usw.) Physische Sicherheit
Support-Leistungen	Umfang und Tiefe der angebotenen Support-Leistungen Patch-Management Change-Management

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:

Was	Beschreibung möglicher Betrachtungspunkte
Compliance	Die Nutzung von Cloud-Diensten führt zu Datenschutzfragen wie die geografische Lokation eines Providers. Der CASB unterstützt die Igel Winterschlaf AG bei der Festlegung und Durchsetzung von Datenschutzrichtlinien.
Datensicherheit	Der CASB erlaubt der Igel Winterschlaf AG die Übertragung sensibler Inhalte zu unterbinden. Dadurch haben CASB Funktionalitäten, die sich mit Data-Loss-Prevention-Systemen (DLP) überschneiden. Der Umfang von DLP-Systemen ist jedoch grösser, zum Beispiels das Scannen von Datenablagen oder die automatische Klassifizierung von Dokumenten.
Schutz vor Bedrohungen	Der CASB erlaubt der Igel Winterschlaf AG, sich vor mit der Cloud-Anbindung involvierten Bedrohungen durch Verhaltensanalysen und Malware Detection zu schützen.
Visibilität	Der CASB überwacht die Nutzung von Cloud-Anwendungen durch die Igel Winterschlaf AG und erstellt risikobasierte Berichte, aufgrund derer entschieden werden kann, ob der Zugriff auf eine Cloud-Anwendung gesperrt werden soll. Ein Zusatznutzen dieser Funktionalität besteht darin, dass allfällig bei der Igel Winterschlaf AG vorhandene Shadow-IT entdeckt wird.

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:

Schutzmassnahme		IaaS	SaaS
Administrationszugriff	Wie greifen Administratoren sicher auf die Cloud-Umgebung zu	Durch Igel Winterschlaf AG zu implementieren	Abhängig vom Angebot
Anbindung an Monitoring-Lösung der Igel Winterschlaf AG	Integrieren der Log-Daten aus der Cloud-Umgebung in die Monitoring-Lösung der Igel Winterschlaf AG	Durch Igel Winterschlaf AG zu implementieren	Durch die Igel Winterschlaf AG zu implementieren
Cloud Access Security Broker (CASB)	Siehe Beschreibung zum CASB	Durch Igel Winterschlaf AG zu implementieren	Durch die Igel Winterschlaf AG zu implementieren
Etablierte VPN-Verbindung Igel Winterschlaf AG zum Cloud-Service-Provider	Etablieren einer sicheren und zuverlässigen Verbindung zum Cloud-Provider	Durch Igel Winterschlaf AG zu implementieren	Abhängig vom Angebot
Firewalling auf Seiten Cloud-Provider	Absichern der Zugriffe aus bzw. in die Cloud-Umgebung	Durch Igel Winterschlaf AG zu implementieren	Abhängig vom Angebot
GDPR Compliance	Berücksichtigung der Datenschutzaspekte	Abhängig von Sorglos ERP&PPS-Software und vom IaaS-Angebot	Abhängig von Sorglos ERP&PPS-Software und vom SaaS-Angebot
Hardware-Security-Schutzmassnahme	Sichere Verwahrung von Schlüsseln z.B. für Verschlüsselung-at-Rest oder Datenverschlüsselung im Sorglos ERP&PPS	Abhängig von Sorglos ERP&PPS-Software und vom IaaS-Angebot	Abhängig von Sorglos ERP&PPS-Software und vom SaaS-Angebot
Patching	Zuständigkeit für das Patching und Festlegen, wer den Patching-Zyklus anstösst	Infrastruktur durch den IaaS Provider Sorglos ERP&PPS durch die Igel Winterschlaf AG	Durch den SaaS-Provider
Redundanz	Massnahmen zum unterbruchfreien Betrieb	Durch Igel Winterschlaf AG zu implementieren	Abhängig vom Angebot
Schutz der Verbindung durch eine Firewall bei der Igel Winterschlaf AG	Festlegen der notwendigen Firewall-Regeln	Durch Igel Winterschlaf AG zu implementieren	Durch Igel Winterschlaf AG zu implementieren
Verschlüsselung von Daten-at-Rest	Verhindern, dass sensitive Daten beim Cloud Provider eingesehen werden können	Durch Igel Winterschlaf AG zu implementieren	Abhängig vom Angebot
Zertifizierung	Sicherstellen, dass bei Audits Auskunft über die Cloud-Umgebung gegeben werden kann, ohne dass ein separater Cloud-Audit durchgeführt werden muss.	Möglich für die Infrastruktur und deren Betrieb	Möglich für den erbrachten Service

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.

Vollständigen Beitrag anzeigen