Der Weg in die Cloud hat einige Tücken [Teil 1]

Clouds – oder besser gesagt cloudbasierte IT-Services von Infrastrukturen (IaaS), Plattformen (PaaS) und Software (SaaS) – sind ohne Zweifel im Unternehmensumfeld angekommen. Mehr noch: In den nächsten Jahren werden Services zunehmend ausschliesslich cloudbasiert angeboten. So wird ein Grossteil der heutigen On-Premise IT-Services in die Cloud migriert. Unternehmen sollten sich also früh genug auf diesen Schritt vorbereiten. Doch wie sieht der sichere Weg in die Cloud aus? Im ersten Teil unserer zweiteiligen Blogreihe liefern wir Ihnen generelle Überlegungen zu den Cloud-Anbietern, -Modellen und -Architekturen sowie den Verantwortlichkeiten. In zweiten Teil erhalten Sie dann praktische Tipps für die Sicherheit Ihrer Cloud-Umgebungen.

Überlegen Sie sich die geeignete Form «Ihrer» Cloud

Um es gleich vorweg zu nehmen: «Die» Cloud gibt es nicht. Viele Unternehmen nutzen bereits heute, mehr oder weniger bewusst, Cloud Services von verschiedenen Anbietern. Jede Dienstleistung, die nicht selber betrieben wird und über das Internet verfügbar ist, ist höchstwahrscheinlich ein Cloud Service. Da die Beschaffungsprozesse nicht überall gleich standardisiert und formalisiert sind, ergibt sich unter Umständen rasch ein Wildwuchs bezüglich Cloud-Nutzung im Unternehmen. Und schnell verliert man dabei den Überblick, welche Anwendungen nun überhaupt im Einsatz sind. Welche Risiken damit verbunden sind, erfahren Sie in einem früheren Beitrag.

Multi-Cloud vs. Hybrid-Cloud

Verschiedene Cloud-Anbieter gleichzeitig zu nutzen, wird als «Multi-Cloud» bezeichnet, da nicht alle Services exklusiv von einem Anbieter bezogen werden. Nicht zu verwechseln ist dies mit dem Architektur-Modell der «Hybrid-Cloud», wo eine Mischung verschiedener Service- und Betriebsmodelle stattfindet. So kann beispielsweise die Infrastruktur als IaaS-Service von einem Anbieter bezogen werden. Selbige Infrastruktur wird hierbei teilweise selber betrieben und zu einem anderen Teil als Back-End verwendet für PaaS- oder SaaS-Services eines anderen Anbieters. Das wichtigste Merkmal einer Hybrid-Cloud ist die Mischung aus On-Premise und Public-Cloud (Off-Premise) Services. Dies führt unweigerlich zum nächsten Thema – die Cloud-Architektur. Nachdem also (hoffentlich) Überlegungen zum passenden Service- und Architekturmodell (Public, Private, Community, Hybrid) gemacht wurden, gilt es, eine Cloud-Architektur festzulegen.

Legen Sie eine angemessene Cloud-Architektur fest

Zur Festlegung der Top-Down-Architektur, kann die Referenzarchitektur von NIST (National Institute of Standards & Technology) gute Dienste leisten. Generell gilt es festzulegen, welche Cloud Service Provider, Technologien und Services für welches Modul mit welchen Kontrollen gelenkt werden. Anders ausgedrückt:

• Wissen Sie über jedes Element in der Referenzarchitektur in allen Ausprägungen und zu jedem Zeitpunkt umfassend Bescheid, wenn es um die Security geht?
• Welche Services bietet der Cloud Service Provider (CSP) überhaupt an, wie werden diese bezogen und wer ist für welchen Teil verantwortlich?
• Was genau bedeuten die verschiedenen Zertifizierungen und Attestierungen überhaupt, die der CSP vorgelegt hat?
• Wie sieht das (Security) Reporting und die (detaillierte) Service-Architektur aus?
• Welchen Zweck sollen die verschiedenen Cloud Services erfüllen – interne Nutzung im Unternehmen oder öffentlich zugängliche Dienste?
• Wer und wo sind die Cloud Consumer (Benutzer)?
• Wie ist das Identity- und Access-Management gelöst und allfällige Federations konzipiert?
• Zu welchen Zeiten und von welchen Standorten aus werden die Cloud Services genutzt?
• Welche Cloud-Auditoren führen welche Prüfungen in welchen Abständen und für welche Services durch?
• Was ist «in scope» resp. «out of scope» bei einer Prüfung/Audit und welche Teile des Service und der zugrundeliegenden Systeme und Infrastruktur wurden überhaupt geprüft? Dies wird in einem Audit-Bericht ausgewiesen und sollte sorgfältig validiert werden.

Cloud Broker vs. Cloud Carrier

Cloud Services bündeln, re-labeln und wiederverkaufen – das sind kurzgefasst die Tätigkeiten von Cloud Brokern. NIST beschreibt einen Cloud Broker als vermittelnde Instanz zwischen den beiden Parteien Cloud-Nutzer und Service Provider. Dabei erfüllt der Cloud Broker verschiedene Rollen. Insbesondere kleinere und mittelgrosse Unternehmen, die Cloud Services nicht direkt bei einem grossen Anbieter beziehen können oder wollen, vertrauen auf die Angebote von Cloud Brokern. Dabei sind die Verantwortlichkeiten klar zu regeln; insbesondere für den Betrieb und einen allfälligen Wechsel oder Ausstieg aus einem Cloud Service.

Abbildung 1 – NIST Cloud Computing Reference Architecture

Cloud Carriers – eine erfahrungsgemäss weniger oft verwendete Bezeichnung – bieten kurz gesagt Netzwerk-Leistungen an (beispielsweise Übertragungskapazität, (Miet)-Leitungen, Content Delivery Networks (CDN)). Teilweise werden die Leistungen aber durch den CSP selber als Service angeboten, ohne dass ein spezifischer / separater Cloud Carrier in Erscheinung tritt. Bei solchen Services ist zu beachten, dass sie sehr oft nicht global in allen Ländern verfügbar sind. Oft kann und muss die Kommunikation zwischen den On-Premise-Endpunkten und den Cloud Services mit Hilfe von dedizierten Verbindungen in der gewünschten Performance geplant und ausgelegt werden. Dieser Punkt geht übrigens gern vergessen. Wenn Cloud Services im grossen Stil genutzt werden, ist die Kapazität der Verbindungen idealerweise besser als «Best Effort» seitens des Internet Service Providers und des Cloud Carriers.

Entscheiden Sie sich für das geeignete Cloud-Service-Modell

Bei den verschiedenen Service-Modellen liegt der Hund – wie bei der Sicherheit von Software und Applikationen eigentlich auch – bei der Schnittstelle und dem damit einhergehenden Wechsel der Verantwortlichkeiten begraben. Im Vergleich zur «traditionellen IT» im Eigenbetrieb, kontrolliert man bei XaaS immer nur einen Teil des Service – beim Rest vertraut man auf den Cloud Service Provider. Diese Vertrauensbeziehung mit formellen Spezifikationen zu unterlegen bzw. genau darauf zu achten, was in den AGB (Allgemeine Geschäftsbedingungen) formuliert ist und welche Dienste ein- sowie ausgeschlossen sind, lohnt sich mehrfach. Überraschungen in diesem Bereich haben gerne das Potenzial, zu veritablen Sicherheits-Schwachstellen auszuarten.

Die Wahl der Service-Modelle hat Einfluss auf die Verantwortlichkeit

Um die Verantwortlichkeiten (und Tücken) zu visualisieren, sehen Sie in der nachfolgenden Grafik die verschiedenen Modelle im Vergleich. Die rot eingefärbten Bereiche visualisieren die Schnittstellen / Übergabe-Punkte der Verantwortung, worauf Sie bei der Umsetzung Ihr Augenmerk richten sollten:

Abbildung 2 – Service-Modelle und Verantwortlichkeiten im Überblick

Die Anbieter resp. Cloud Service Providers verwenden dabei für die Schnittstellen und die darunter oder darüber laufenden Dienste oft verschiedene, nicht immer genau spezifizierte Begriffe. Achten Sie deshalb darauf, dass diese unmissverständlich klar erläutert sind, ebenso wie die Zuständigkeiten. Ebenfalls gut zu wissen: Wer ist «auch noch» zuständig? Will heissen, wenn beispielsweise der CSP für das Patching des Betriebssystems zuständig ist, aber nicht für die Konfiguration und Härtung – welche Zugriffsberechtigungen hat der Cloud Service Provider für diesen Zweck? Kann der CSP dadurch noch andere Tätigkeiten oder Funktionen ausführen als für das Security Patching eigentlich notwendig wären?

Denken Sie bei der Wahl des Cloud Providers auch an das «Kleingedruckte»

Cloud Services werden oft mit Outsourcing gleichgestellt, jedoch gibt es einige wichtige Unterschiede. Generell setzen CSP für die wirtschaftliche Entwicklung und den Betrieb der Services stark auf Standardisierung und Automatisierung. Rechtlich wirkt sich das auf die Beziehung zwischen Anbieter und Kunde dahingehend aus, dass es sich bei den Verträgen nicht um individuelle Vereinbarungen handelt, sondern um AGB. Das bedeutet, dass individuelle Anpassungen und Vereinbarungen weder gewünscht noch möglich sind.

Cloud Services sind zudem meist nach dem «Angebot-Nachfrage-Prinzip» gebaut. Der CSP bietet bestimmte, spezifizierte und standardisierte Dienste an; die Kunden können daraus das Passende beziehen. Eine individuelle Anpassung erfolgt nicht. Passt das Angebot nicht, muss sich der Kunde nach einem anderen Anbieter umschauen oder sich anderweitig helfen. Damit sind seitens des CSP der Service-Level, die eingesetzten Technologien, das Change- und Release-Management, Preismodelle, Vertragsbedingungen sowie Support-Optionen standardisiert und bestenfalls im engen Rahmen verhandelbar – oder eher aus Varianten und Modulen zusammensetzbar.

Legen Sie Verantwortlichkeiten und Zuständigkeiten fest

Haben Sie den geeigneten Partner gefunden, gilt es, die Verantwortlichkeiten zu Regeln. Denken Sie daran: Verantwortung kann nicht delegiert werden – die Erfüllung einer Aufgabe hingegen schon. Wie sich die Verantwortlichkeiten bei den verschiedenen Service-Modellen verteilen, ist in der folgenden Grafik aufgezeichnet:

Abbildung 3

Der Kunde – also Sie – verantwortet letztlich immer, und das «nicht delegierbar», die Gesamtaufsicht und -Kontrolle, sprich die Governance über den bezogenen Service. Ebenfalls ist die Verantwortung der Daten, sozusagen das Eigentumsverhältnis, Sache des Kunden. Das bringt dem CSP den Vorteil, dass er letztlich für die Sicherheit der Daten(-inhalte) nicht umfassend (über eine Sorgfaltspflicht hinaus) haftbar gemacht werden kann. Das ist im Sinne des Datenschutzes vernünftig, denn ansonsten würden sich für den Provider aufgrund (Mit-)Eigentum an den Daten mögliche Rechte ableiten. Diese juristischen Themen und Auslegungen sind im Übrigen nicht ganz trivial, weshalb es klug ist, zu diesem Zweck die vertraglichen Vereinbarungen bezüglich Einhaltung obligationsrechtlicher, datenschutzrechtlicher und anderweitiger gesetzlicher Anforderungen genau zu analysieren. Wenn Sie über keine internen Juristen verfügen, empfehlen wir Ihnen, einen externen Experten hinzuzuziehen.

Die «Shared Responsibility», wie schon im vorhergehenden Abschnitt bei den Schnittstellen erläutert, sollte möglichst genau spezifiziert und abgegrenzt werden. Die Verantwortung für die physische Sicherheit liegt dabei grundsätzlich beim CSP, da selbst bei einem IaaS-Servicemodell die Hardware lediglich gemietet wird und man oft auch keinen direkten (physischen) Zugang zu den Systemen hat.

Daten-Lebenszyklus und die Cloud

Um zwischen Service- und Architekturmodellen und insbesondere zwischen Multi- und Hybrid-Clouds die Übersicht zu behalten, hilft es, den Lebenszyklus der geschäftsrelevanten Daten entlang der Lebenszyklus-Phasen zu strukturieren. Die folgende Grafik (Abbildung 4) zeigt den Lebenszyklus von Daten in einem Geschäftsprozess. Spezifizieren Sie entsprechend (und zwar für jeden Geschäftsprozess bzw. heruntergebrochen auf einzelne Use Cases!) genau, wo, wie, mit welchen Werkzeugen und in welchen Cloud Services die Daten in den einzelnen Lebensphasen bearbeitet werden. Denn von der Entstehung (Create) bis hin zur Entsorgung (Destroy) der Daten liegt die Verantwortung für die Sicherheit bei Ihnen!

Sie sehen – es gibt einiges zu beachten bei der sicheren Migration in die Cloud. Nutzen Sie die oben genannten Punkte als Checkliste und gehen Sie sie Punkt für Punkt durch. Im zweiten Teil dieses Artikels, der in Kürze online geht, erfahren Sie zudem, worauf Sie bei der Umsetzung Ihrer Cloud-Umgebung achten müssen, damit die Business-Anforderungen und die Sicherheit gleichermassen abgedeckt sind.

Sie wollen den Artikel nicht verpassen? Dann abonnieren Sie unsere Blog Updates! So erhalten Sie die neusten Artikel immer bequem in Ihr Postfach.

Übrigens: Auf unserem Cyber Security Blog finden Sie noch viele weitere Blogartikel rund um das Thema Cloud Security!

Abbildungsverzeichnis:

• Abbildung 1 – NIST Cloud Computing Reference Architecture:  https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication500-292.pdf
• Abbildung 2 – Eigene Darstellung; in Anlehnung an diverse bekannte Modelle
• Abbildung 3 – Eigene Darstellung
• Abbildung 4 – Eigene Darstellung; in Anlehnung an https://roaringelephant.org/2019/01/15/episode-123-infrastructure-and-data-lifecycle-part-2/