Gut geplant in die Cloud : Erstellung einer Cloudnutzungsstrategie nach IT-Grundschutz
Egal, ob man Clouddienste während der Pandemie aus der Not heraus schnell zur Aufrechterhaltung benötigter Funktionen benötigt hat, eine gewünschte Anwendung womöglich nur noch aus der Cloud heraus angeboten wird oder es andere Gründe für die Nutzung entsprechender Services gibt: Der IT-Grundschutz fordert, für jede Clouddienstleistung eine Nutzungsstrategie zu erstellen – möglichst bevor der Clouddienst zum Einsatz kommt.
Sobald eine Dienstleistung aus der Cloud im Unternehmen oder der Behörde eingesetzt werden soll, ist der Baustein OPS.2.2 Cloudnutzung anzuwenden – dabei stellt die Erstellung einer Cloudnutzungsstrategie eine Basisanforderung dar und ist damit auf jeden Fall umzusetzen. Im Rahmen dieser Cloudnutzungsstrategie sind Ziele, Chancen und Risiken, die mit dem Einsatz des betrachteten Clouddienstes einhergehen, zu definieren – diese Ergebnisse fließen dann in die grobe Sicherheitsanalyse ein. Diese kann als Grundlage für das in OPS.2.2.A7
„Erstellung eines Sicherheitskonzepts für die Cloudnutzung“ geforderte Dokument dienen.
Auch die vorhandenen Umstände rechtlicher, organisatorischer und technischer Natur sind zu betrachten und zusätzlich ist zu überprüfen, ob sich die Dienstleistung, die aus der Cloud bezogen werden soll, unter den vorhandenen Rahmenbedingungen überhaupt sicher in die institutseigenen Prozesse einbinden lässt. Sowohl dieses Ergebnis als auch die Resultate der groben Sicherheitsanalyse sollten in die Kosten-Nutzen-Planung einfließen – denn aufgrund rechtlicher oder sicherheitstechnischer Anforderungen kann gegebenenfalls ein teureres Lizenzmodell notwendig werden.
Übergreifende Strategie
Die Erstellung einer Cloudnutzungsstrategie für jede einzelne Clouddienstleistung ist nicht nur aufwendig, ein solches Vorgehen birgt auch die Gefahr, nicht alle notwendigen Stakeholder einzubeziehen oder Sicherheitsaspekte und möglicherweise Zusammenhänge zu übersehen. Zudem müssen sich die Beteiligten stets neu in die Aufgabenstellung hineindenken – vor allem dann, wenn diese noch nicht zum Tagesgeschäft gehört.
In der Regel gibt es unternehmensweit anzuwendende Sicherheitsanforderungen, die bei vielen Clouddiensten als Sicherheitsmaßnahme „herauspurzeln“ können: Gerade hierbei kann es passieren, dass die jeweilige Fachabteilung, die einen Clouddienst einführen möchte, diese gar nicht selbst umsetzen kann.
Beispielsweise kann eine Fachabteilung normalerweise nicht die unternehmensweite Sensibilisierung von Mitarbeitern hinsichtlich der Chancen
und Risiken in der Cloud planen und durchführen. Prinzipielle Rahmenbedingungen für die Cloud sollten auch deshalb vorab feststehen, damit die Sensibilisierung der Mitarbeiter nicht für jeden Clouddienst immer wieder neu erfolgen muss.
Der Einsatz von Clouddiensten betrifft letztlich nicht nur die IT-Abteilung, sondern beispielsweise auch den Einkauf, die Informationssicherheit, den Datenschutz und Fachabteilungen – daher sollte jeder seine Interessen mit in die Cloud-Strategie einbringen (vgl. Abb. 1). Auch der Anstoß zur Erstellung einer unternehmensweiten Cloudstrategie kann von unterschiedlichen Abteilungen oder Rollen kommen. Das Projekt sollte aber in jedem Fall die Unterstützung der Geschäftsführung haben, sodass sichergestellt ist, dass genügend Ressourcen vorhanden sind und das Ergebnis auch akzeptiert wird.
Abbildung 1: Von der Idee zur Cloud-Strategie
Da in der Regel die genutzte Technologie für alle an der Cloud-Strategie Beteiligten neu ist, sollte man mit einer gemeinsamen Sammlung von Begriffen rund um Cloud beginnen. Es ist wichtig, Begriffe einheitlich zu verwenden, sodass keine Missverständnisse entstehen können!
Migrations-Gründe
Die Gründe, IT-Anwendungen oder -Systeme in die Cloud zu verlegen sind vielfältig – meist lassen sie sich aber aus der Unternehmensstrategie ableiten: Häufig wird die Kostenersparnis im Zusammenhang mit der Migration in die Cloud genannt. Doch diese gibt es nicht ohne Eigeneinsatz!
Denn damit sich die Kosten reduzieren, muss man das Bezahlmodell der Cloud entsprechend nutzen – und beispielsweise Ressourcen, die von Anwendungen nicht benötigt werden, auch tatsächlich abbestellen. Das kann aber kein Administrator oder Entwickler manuell durchführen. Dieses Vorgehen benötigt Transparenz in der Cloud hinsichtlich des Verbrauchs gebuchter Dienste und eine Automation, um ab einem gewissen Schwellenwert automatisch zusätzliche Dienste zu buchen oder unbenötigte abzubestellen.
Die damit verbundene Skalierbarkeit wird als Vorteil der Cloud gesehen. Auch hier sollte man aber die lokale Situation betrachten: Wurde unlängst erst neue Hardware beschafft, lässt sich eine solche Skalierbarkeit gegebenenfalls auch mit virtuellen Maschinen (VM) verwirklichen.
Auch eine hohe Verfügbarkeit wird im Rahmen von Cloud-Zielen gerne genannt. Cloud-Provider bieten in ihren Service-Level-Agreements (SLAs) entsprechende Zusagen. Dennoch können ein oder mehrere Clouddienste versagen – meist in einer definierten Region – und darüber hinaus besteht auch die Möglichkeit, dass die Anwendung selbst ausfällt. Je nach Risikoappetit kann es sinnvoll sein, Clouddienste daher in mehreren Regionen
zu buchen und eine über zwei oder mehr Dienste redundante Architektur zu betreiben.
Die Unterstützung der Entwickler und Administratoren durch Automation und Pipelines mit automatisierten Softwaretests, um Anwendungen zu aktualisieren, stellt ebenfalls einen Vorteil der Cloud dar: In einer lokalen IT-Umgebung müsste eine solche Funktionalität erst konzipiert, aufgebaut und regelmäßig administriert werden. Es sind jedoch nicht nur Rechenressourcen, welche die Cloud auszeichnen: Anbieter können überdies Dienste anbieten, die man lokal nicht oder nur unter großem Aufwand betreiben könnte – etwa Machine-Learning. Die stetige Weiterentwicklung der Cloud sorgt idealerweise auch dafür, dass Clouddienste stets aktuell und nicht angreifbar sind.
Rahmenbedingungen
Hinsichtlich rechtlicher Anforderungen sollte man auf jeden Fall den Datenschutz betrachten – denn in der Regel werden zumindest personenbeziehbare Daten (z. B. IP-Adressen von Benutzern sowie Benutzernamen) in der Cloud verarbeitet. Im Rahmen der Cloud-Strategie
lassen sich allgemein gültige Rahmenbedingungen abstecken – etwa die Festlegung der Datenlokation, wobei sich in den meisten Fällen Deutschland oder Europa anbieten.
Doch auch Vorgaben von (Aufsichts-) Behörden, wie die Orientierungshilfe zu Auslagerungen an Cloudanbieter der BaFin [1] oder der Mindeststandard des BSI zur Nutzung externer Clouddienste [2], sollten in die Cloud-Strategie einfließen. Zudem kann aufgrund bestehender Strukturen – zum Beispiel einer flachen oder nicht vorhandenen Netzwerksegmentierung – die Anbindung externer Clouddienste eingeschränkt oder ganz verboten werden.
Strategie-Optionen
Wenn es um Cloud-Strategien geht, werden gerne Begriffe wie „Cloud only“ oder „Cloud first“ verwendet. Doch ganz so „schwarz-weiß“ muss es nicht sein: Bei einer generellen Cloud-First-Strategie schaut man zwar bei neuem Bedarf immer zuerst, ob es passende Cloudangebote gibt – eine „SaaS-First-Strategie“ reduziert dieses Vorgehen jedoch beispielsweise nur auf Anwendungen.
Bei der Cloud-only-Strategie werden hingegen auch alle bisherigen Systeme und Anwendungen migriert: Das kann sich beispielsweise lohnen, wenn man hohe Investitionen zur Ertüchtigung eines Rechenzentrums erwartet. Ansonsten ist dies Strategie in Europa eher selten anzutreffen. Häufiger kommt eine „Cloud-too“-Strategie zum Einsatz, die festlegt, lokale Systeme und Anwendungen durch solche in/aus der Cloud zu ergänzen.
All diese Begriffe sind nicht „in Stein gemeißelt“, sondern lassen sich flexibel anpassen, wo beispielsweise nicht alle Betriebs- oder Servicemodelle möglich sind. Wenn ein Unternehmen beispielsweise keine eigenen Anwendungen entwickelt, sondern mit Anwendungen „von der Stange“ arbeitet, kann die Eingrenzung auf Software-as-a-Service (SaaS) ein Ergebnis der Cloud-Strategie sein. Oder man kommt zum Schluss, bestimmte Datenarten nicht auslagern zu dürfen – dann ließe sich für diesen Bereich beispielsweise eine „Private-Cloud-only“-Strategie festlegen. Selbst die Verwendung einzelner Servicearten, wie Backup-as-a-Service, kann durchaus zulässig oder sinnvoll sein, obwohl man Kernanwendungen weiterhin lokal betreibt.
Zusammenfassend lässt sich sagen: Keine Cloud-Strategie gleicht der anderen! Die Cloud-Strategie sollte immer individuell erstellt und auch bei Bedarf oder regelmäßig alle 4–5 Jahre angepasst werden. Wo auch Anwendungen in die Cloud migriert werden sollen, empfiehlt es sich allerdings, bereits im Rahmen der Cloud-Strategie Überlegungen anzustrengen, ob diese Anwendungsmigration per „Lift and Shift“ erfolgen soll – also durch Installation der bisherigen Anwendung auf einer virtuellen Maschine in der Cloud oder Änderung der Anwendungsarchitektur. Alternativ kann man natürlich auch bisherige eigene Anwendungen durch solche ersetzen, die als SaaS angeboten werden.
Sicherheitsprämissen
Während in der für einzelne Clouddienstleistungen erstellten Cloudnutzungs-Strategie bereits eine grobe Sicherheitsanalyse erstellt werden soll, sollte man auf der Cloud-Strategie-Ebene generelle Sicherheitsprämissen definieren, von denen sich dann konkrete Sicherheitsmaßnahmen
ableiten lassen.
Diese Sicherheitsprämissen sollten im Einklang mit der zuvor gewählten Cloud-Strategie stehen. So würde die Sicherheitsprämisse „Sichere Entwicklung für die Cloud“ für eine „SaaS-first-Strategie“ bedingt passen – „Multifaktorauthentifizierung für alle Benutzer“ oder „Überblick wahren durch Security-Monitoring“ sind hingegen Sicherheitsprämissen die in der Regel immer passen können.
Die Cloud ist anders
Allen beteiligten Parteien sollte klar sein, dass „die Cloud“ und die damit einhergehenden Prozesse anders sind als das bisher Gewohnte. Das heißt auch: Mit einer Cloud-Strategie wird beziehungsweise sollte auch ein Wandel der Unternehmenskultur einhergehen!
So wird beispielsweise im traditionellen IT-Betrieb Hard- und Software eingekauft, installiert und konfiguriert – doch die Cloud ist kein weiteres Asset das man zum IT-Portfolio einfach dazu packen kann. Der Schritt in die Cloud stellt ein IT-Outsourcing dar und zwar von einer besonderen Sorte: So lässt sich der Schritt in die Cloud in etwa mit der Einführung eines Enterprise-Resource-Planning-(ERP)-Systems vergleichen: Die eigentliche Installation einer ERP Software ist dabei in der Regel keine Herausforderung. Die meisten IT-Mitarbeiter, die an einer ERP-Einführung beteiligt waren, erinnern sich jedoch noch Jahre danach an Aufwand und Irrwege bei Integration und Anpassungen des ERP-Systems.
Traditionell wird die IT häufig als eine Kostenstelle betrachtet und auch als eine solche betrieben – nicht selten schließt man langjährige Lizenzverträge ab, um noch etwas Rabatt mitzunehmen. Doch in der Cloud werden die Dienstleistungen nicht vorab bezahlt. Stattdessen zahlt
man nur, was man auch wirklich gebraucht hat. Das kann in manch traditioneller Finanzplanung für die IT oder den Fachbereich dazu führen, dass dann im nächsten Jahr weniger Budget zur Verfügung steht.
Ein weiterer Unterschied liegt darin, dass in der traditionellen IT Vergleichsangebote eingeholt werden, um den besten Preis für die beste Leistung zu erzielen. Doch auch dieses Vorgehen funktioniert in der Cloud nur bedingt, denn zumindest die großen Cloud-Anbieter stellen ein umfangreiches Sortiment an Clouddiensten bereit, die dann – wenn benötigt – hinzugebucht werden können; und diese Dienste werden stetig weiterentwickelt.
Die Dienstleistung erneuert sich also stetig, sodass ein Schnappschuss ihrer Eigenschaften nicht die gleiche Aussagekraft entwickelt, wie das bei lokalen Anwendungen und Systemen der Fall ist. Stattdessen sollte man sich die Produktstrategie und Philosophie der Anbieter anschauen.
Im Rahmen der IT-Sicherheit wäre auch die Frage wichtig, ob dieser nur Funktionalität weiterentwickelt oder ob er auch auf sinnvolle Sicherheitsdienste und -features Wert legt.
Abbildung 2: Traditionelle IT-Auslagerung versus Auslagerung in die Cloud
Selbst beim Outsourcing unterscheidet sich die Erbringung eines Clouddienstes von den Leistungen eines IT-Dienstleisters, was Abbildung 2 illustriert. Im klassischen IT-Outsourcing herrschen eher starre Strukturen vor – eine Auslagerung in die Cloud hingegen ist agil, skalierbar und „elastisch“. Die Cloud passt so auch zu agilen IT-Entwicklungs- und IT-Administrationsmethoden, die unter sich dem DevOps-Begriff zusammenfassen lassen.
Außerdem bedeutet eine Cloud-Umgebung für Benutzer einen höheren Grad an Kontrolle und Transparenz: So lassen sich normalerweise alle in der Cloud betriebenen Dienste über APIs oder Portale überprüfen – und es stehen aktuelle Daten zu beispielsweise der Verfügbarkeit von Diensten, Systemstatus und Abrechnungsdetails zur Verfügung.
Auch der IT-Grundschutz hatte – schon recht früh – erkannt, dass es sich bei der Cloudnutzung nicht um ein klassisches Outsourcing handelt und hierfür einen eigenen Baustein entwickelt, der mittlerweile in den heutigen OPS.2.2 Cloudnutzung übergegangen ist. Gerade diese Neuerungen
gilt es auch unternehmensweit „einzuspeisen“. Doch Veränderungen werden häufig skeptisch gesehen – man denke nur an die Entwicklung zum (nahezu) papierlosen Büro oder die Verlagerung von Marketingaktionen in Social-Media-Kampagnen. Die Cloud ist anders und unbekannt und aufgrund ihres Automatisierungspotenzials könnte sie – von außen betrachtet – eher Arbeitsplätze vernichten, als neue schaffen. Daher ist es
wichtig, die Belegschaft in die Änderung der Unternehmenskultur mit einzubinden und – mit der Cloud verbundene – Änderungen (z. B. Umstrukturierung von Teams) offen zu kommunizieren.
Exit-Strategie
Auch wenn alle gerne die Cloud nutzen wollen, kann es dennoch sein, dass man im Rahmen der Strategie-Erarbeitung oder später zu dem Schluss kommt, den Weg in die Cloud doch (zumindest erst einmal) nicht oder nicht wie zunächst vorgesehen zu beschreiten. In diesem Fall hilft eine Exit-Strategie, die auch von verschiedenen Aufsichtsbehörden vorgeschrieben wird, beim Rückzug aus der Cloud in die lokale IT oder zu einem anderen
(Cloud-) Provider.
Im Rahmen der Cloud-Strategie ist in der Exit- Strategie das grundlegende „Was?“ und „Warum?“ zu behandeln. Das „Wie?“ sollte man dann dienstspezifisch in der Cloudnutzungsstrategie festhalten. So sollten Rahmenbedingungen dokumentiert werden, aufgrund derer man einen Ausstieg aus der Cloud vornehmen würde. Auf der anderen Seite können auch mögliche alternative Dienste oder Anwendungen im Rahmen der Cloudnutzungsstrategie eruiert werden.
Roadmaps
Die Roadmap der Cloud-Strategie sollte allem voran sicher durch den Wandel der Unternehmenskultur führen – während die Roadmap der Cloudnutzungsstrategie die Umsetzung von Sicherheitsmaßnahmen und anderen (Sicherheits-)Anforderungen aus den IT-Grundschutz-
Bausteinen im Blick haben sollte.
Fazit
Die Erstellung einer prinzipiellen Cloud-Strategie ermöglicht die Festlegung von Rahmenbedingungen, die man dann in die Cloudnutzungsstrategie einbeziehen kann. Dann muss auch die Unternehmens- oder Behördenleitung nicht bei jeder neuen Cloud-Aktivität in die jeweilige Nutzungsstrategie einbezogen werden, sondern dies kann dann im Rahmen des Einführungsprojekts erfolgen – denn die Leitungsebene hatte die prinzipielle Cloud-Strategie ja bereits zuvor bestätigt. Zudem lassen sich generelle Sicherheitsrichtlinien bereits aus der übergeordneten Cloud-Strategie ableiten – und diese können spezifisch auf die erlaubten Bereitstellungsmodelle und Servicemodelle ausgelegt sein.
Inés Atug ist Senior Expert bei der HiSolutions AG.
Literatur
[1] Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin), Orientierungshilfe der BaFin zu Auslagerungen an Cloud-Anbieter, November 2018, www.bafin.de/SharedDocs/Veroeffentlichungen/DE/Meldung/2018/meldung_181108_orientierungshilfe_cloud_anbieter.html
[2] Bundesamt für Sicherheit in der Informationstechnik (BSI), Mindeststandards des BSI zur Nutzung externer Clouddienste, Version 2.0, Juli 2021, www.bsi.bund.de/DE/Themen/Oeffentliche-Verwaltung/Mindeststandards/Externe_Clouddienste/Externe_Clouddienste_node.html