zurück zum Artikel

Die richtige Vorbereitung und systematische Planung sind die Schlüssel zu erfolgreichen Cloud-Projekten, die die Sicherheit nicht vernachlässigen.

Die Autoren dieser Serie zu "Cloud für Unternehmen" begleiten und analysieren seit vielen Jahren Cloud-Projekte. Im ersten Teil erklärten sie die typischen Fehler [1] und wie man diese vermeidet, der zweite illustrierte typische Angriffe auf die Cloud [2]. Der aktuelle Teil zeigt Ihnen, wie Sie ihr Cloud-Projekt sicher auf den Weg bringen.

Egal was man von der Cloud hält – kein Unternehmen kann es sich mehr leisten, das Thema einfach nur zu ignorieren. Denn das führt zwangsläufig zu Wildwuchs und Chaos. Jedes Unternehmen sollte eine Strategie definieren, die globale Richtlinien vorgibt, wozu und wie man die Cloud nutzen will. Denn was nicht geregelt wird, regelt sich selbst und das führt unweigerlich zu Chaos und Sicherheitsproblemen.

Dabei sollte nicht etwa die Geschäftsführung im stillen Kämmerlein mit der IT-Leitung eine Cloud-Strategie aushecken. Das Thema Cloud berührt alle Bereiche. Also sollten an der Entwicklung einer Cloud-Strategie unter anderem auch die Bereiche Einkauf, Personal, Informationssicherheit und Datenschutz mitwirken. Weitere Mitwirkende können beispielsweise aus Finanzen oder den Fachabteilungen kommen.

Eine der bekanntesten Cloud-Strategien ist "Cloud First". Bei dieser Strategie werden bei Neuanschaffungen zuerst Cloud-Dienste betrachtet. Erst wenn die Realisierung in der Cloud ausscheidet wird diese in der lokalen Umgebung umgesetzt. "Cloud First" setzt Prioritäten, bedeutet aber keineswegs "Immer Cloud".

Eine weitere Cloud-Strategie lautet "SaaS First". Dies ist eine von "Cloud-First" abgewandelte Strategie und besagt, dass Software-as-a-Service-Angebote gegenüber lokal betriebenen Anwendungen bevorzugt werden. Die weiteren Ausführungen sind Ihnen hoffentlich dabei behilflich, Ihre eigene Cloud-Strategie zu formulieren.

Das Thema Sicherheit spielt dabei von Beginn an eine tragende Rolle. Damit sich das nicht in abstrakten Lippenbekenntnissen verliert, empfiehlt es sich, frühzeitig eine Konkretisierung der Sicherheitsanforderungen vorzunehmen. Dazu analysiert man beispielsweise einen einzuführenden Cloud-Dienst zunächst grob und leitet daraus Rahmenbedingungen für den sicheren Einsatz ab. Das kann dann etwa die Verwendung von globalen Sicherheitsregeln zur Herstellung eines Mindestsicherheitsstandards in der Cloud sein. Oder eine Festlegung des Gerichtsstandorts auf Deutschland.

Wichtig ist es, dabei zwischen den Anforderungen an den Cloud-Provider und an das eigene Unternehmen zu unterscheiden. Wie das aussehen kann zeigt exemplarisch diese Tabelle:

Exit vor dem Start

Eine wichtige globale Richtlinie ist die Festlegung einer Exit-Strategie. Man sollte vor jedem Start eines Cloud-Projekts klären, welche Fallbacks und Ausstiegsszenarien man hat. So hat man es leichter, wenn nach dem Vertragsabschluss die ersten Tests oder die Pilotierungsphase zeigen, dass die Reaktionsgeschwindigkeit des Cloud-Providers nicht ausreicht. Oder wenn man schlicht ein günstigeres Angebot durch den Mitbewerber erhält. Auch können gesetzliche oder regulatorische Änderungen immer dazu führen, dass man einen Cloud-Dienst nicht weiter nutzen darf.

Bei einer unzureichenden Exit-Strategie drohen Datenverlust und hohen Kosten. Etwa wenn man seine Daten nicht oder nur mit hohem Aufwand aus der Cloud exportieren kann. Auch könnte es passieren, dass für den Datenexport eine zusätzliche Gebühr fällig wird, die man nicht bedacht hatte. Daher sollten die Möglichkeiten zur Beendigung des Vertrags noch vor Vertragsabschluss betrachtet und in einer Exit-Strategie dokumentiert werden.

Vorbereitung

Dann geht es daran, aus den bestehenden Anwendungen die ersten Migrationskandidaten für die Cloud zu identifizieren. Ob eine Anwendung für den Umzug in die Cloud geeignet ist, hängt mit verschiedenen Faktoren zusammen. Dürfen die in der Anwendung verarbeiteten Daten überhaupt in der Cloud verarbeitet werden? Gibt es ein Angebot für Software-as-a-Service, das eine Anwendung ablösen kann? Oder eignet sich die Architektur der Anwendung für das Replatforming?

Die einzelnen Migrationsformen unterscheiden sich hinsichtlich Potential und Anforderungen teilweise beträchtlich. Da die richtige Auswahl den Erfolg des Projekts entscheidend beeinflusst, stellen wir diese Unterschiede im Folgenden etwas konkreter vor.

Die einfachste Migration ist Repurchase – also der Umstieg auf ein passendes Software-as-a-Service-Angebot (SaaS) etwa für Büroanwendungen oder Customer Relationship Management (CRM). Ob das möglich und sinnvoll ist, hängt natürlich davon ab, ob es überhaupt passende SaaS-Angebote gibt und ob sich deren Einsatz "rechnet". Man sollte jedoch unbedingt darauf achten, dass die Daten aus der Cloud-Anwendung auch ohne großen Aufwand exportierbar sind.

Viele Cloud-Projekte starten mit einem sogenannten Rehosting – auch Lift & Shift genannt. Diese Migrationsart ist ebenfalls recht einfach, denn man verschiebt die (virtuellen) Maschinen, die man bisher im eigenen Rechenzentrum gehostet hatte, in die Cloud-Infrastruktur (Infrastructure as a Service, IaaS).

Allerdings profitiert man dabei nur sehr eingeschränkt von den Vorteilen der Cloud. Man spart keine Lizenzkosten. Administration und Pflege vereinfachen sich nicht und skalieren wird die Anwendung in aller Regel auch nicht besser. Auch aus Sicherheitssicht bringt Rehosting oft große Probleme mit sich. Denn zumeist wurden die Anwendungen auf der Basis von Annahmen entwickelt, die in der Cloud nicht mehr gegeben sind; wie der durch Firewalls begrenzte Zugriff auf Dienste. Da werden dann häufig unzureichend gesicherte Schnittstellen im Internet exponiert.

Beim Replatforming bleibt der Kern der Anwendung bestehen; nur Teile wie die Datenbank werden mit cloud-nativen Mitteln betrieben (Plattform as a Service, PaaS). Der Vorteil dieser Migration liegt auf der Hand. Anders als beim Rehosting kann man sofort vom Cloud-nativen Teil profitieren, weil beispielsweise teure Datenbanklizenzen wegfallen. Teile der administrativen Aufgaben übernimmt zukünftig der Provider und der kann im Bedarfsfall auch quasi sofort mehr Durchsatz ermöglichen. Allerdings erfordert diese Migrationsart bereits etwas mehr Wissen über Cloud und ihre Möglichkeiten. Ohne dieses Know-How kann es passieren, dass man es übertreibt und letztlich bei einer sehr exotischen Architektur landet.

Refactoring ist am aufwendigsten und dauert am längsten. Es kommt dann infrage, wenn die Cloud-Vorteile voll ausgenutzt werden sollen und die Anwendung eine langfristige Perspektive hat. Denn die hohen Migrationskosten zu einer eigenen, cloud-nativen Anwendung lohnen sich – wenn überhaupt – dann erst auf lange Sicht.

Dafür kann man die Anwendung gleich generalüberholen und optimal an die aktuellen Bedürfnisse anpassen. Das bringt beträchtliches Einsparpotential und oft auch signifikante Verbesserungen bei der Sicherheit. Allein der Abschied von nicht mehr genutzten Funktionen, veralteten Protokollen und unsicheren Konfigurationen reduziert die Angriffsfläche deutlich.

Doch für das Refactoring benötigt man Wissen – Wissen, das derzeit Mangelware und daher schwer am Markt zu bekommen ist. Außerdem ist die Gefahr eines Vendor-Lock-In groß, da man seine Anwendung auf einen Cloud-Provider ausrichtet und sie nicht einfach bei einem Mitbewerber wieder in Betrieb nehmen kann. In vielen Fällen wird man deshalb einen Kompromiss ansteuern, der sich am ehesten mit Replatform realisieren lässt. Es stellt einen Mittelweg zwischen Rehost und Refactor dar.

Deine Cloud, meine Daten

Bei der Auswahl des Migrationskonzepts und des passenden Providers ist es auch wichtig, die Portabilität der Dienste und Daten im Blick zu behalten. Denn dabei unterscheiden sich die verschiedenen Cloud-Nutzungs-Szenarien zum Teil signifikant. Bei IaaS kann man virtuelle Maschinen in der Regel recht einfach "mitnehmen".

Beim Replatforming und noch mehr beim Refactoring mit PaaS gestaltet es sich deutlich schwerer, eine Cloud-Anwendung von einem Provider zu einem anderen zu übertragen. Denn Datenstrukturen und APIs der Plattformen unterscheiden sich in aller Regel. Oftmals muss die Anwendung zumindest in Teilen neu entwickelt werden.

Ähnlich sieht es bei SaaS aus. Hier sollten insbesondere die Datenformate überprüft werden, um sicherzustellen, dass Dateien später weiter verarbeitet werden können. Spezielle Anwendungsstrukturen können dazu führen, dass ein Importieren der Daten in den neuen Dienst nicht oder nur begrenzt möglich ist.

Von der Planung in den Test

Hat man sich auf einen Migrationspfad für eine Anwendung und einen passenden Cloud-Provider entschieden, folgt der nächste Schritt – der Testbetrieb. Denn meist kann man erst in einem konkreten Testbetrieb der Anwendung feststellen, ob die Vorgaben tatsächlich umsetzbar sind und ob sich bei den Abweichungen vielleicht sogar echte Showstopper ergeben. Im Idealfall kann man da auch bereits Nachbesserungs-, Schulungs- oder Entwicklungsbedarf identifizieren und frühzeitig einplanen.

In besonders kritischen Szenarien empfiehlt sich zusätzlich eine Pilotphase, in der man überprüft, ob der Cloud-Dienst im produktiven Betrieb bestehen kann und beispielsweise die geplanten Kontingente ausreichend sind. Nach einem erfolgreichen Piloten kann die Migration dann abgeschlossen und der Cloud-Dienst in den produktiven Betrieb überführt werden.

Das Sicherheitskonzept

Das Sicherheitskonzept sollte möglichst vor der Testphase in Grundzügen stehen, so dass auch die Sicherheitsmaßnahmen in der Cloud mit getestet werden können. Je später man da feste Regeln vorgibt, desto schwieriger wird es, diese dann auch durchzusetzen.

Die Basis der Sicherheit in der Cloud ist der Schutz der Identitäten. Sie gewährleistet der sogenannte Identitäts-Perimeter, der sich aus Authentifizierung und Zugriffskontrolle zusammensetzt. Wir können nur jedem Unternehmen ans Herz legen, da von Beginn an hohe Missbrauchshürden einzuführen, indem Need-to-Know- beziehungsweise Least-Privilege-Prinzipien und Multifaktorauthentifizierung vorgeschrieben werden (mehr dazu findet sich in Cloud für Unternehmen: Typische Angriffe und wie Sie sich schützen [8]).

Damit der Einstieg in die Cloud schnell gelingt, haben die Cloud-Provider oftmals bereits standardisierte Rollen oder Berechtigungen definiert, die dann entsprechend an die jeweiligen Personen vergeben werden können. So kann man der Gruppe Buchhaltung, die für die Abrechnungen in der Cloud zuständig ist, im Azure AD die Rolle Billing Administrator zuordnen.

In AWS ist für diese Mitarbeiter eine IAM-Richtlinie mit der Berechtigung BillingFullAccess (Vollzugriff) oder BillingViewAccess (Lesender Zugriff) zu erstellen. Diese IAM-Richtlinie wird dann an die Gruppe der Buchhaltungsmitarbeiter angehängt. Denn um den Überblick nicht zu verlieren, sollten IAM-Richtlinien nicht direkt an die Benutzerkonten angefügt werden. Grundsätzlich sind alle Berechtigungen und Rollen dynamisch zu sehen und die Notwendigkeit der jeweiligen Berechtigungen sollte regelmäßig überprüft werden, zum Beispiel einmal im Quartal.

Der zweite Eckpfeiler der Cloud-Security ist das konsequente Monitoring. Dabei muss zum einen sichergestellt werden, dass alle Ecken – auch die Dunkelsten – der Cloud-Umgebung überwacht werden, damit ein Angreifer sich nicht in eine nicht überwachte Region "verkrümeln" kann. Zum anderen muss man dafür sorgen, dass alle generierten Events – also auch die von den Endpunkten – ins Monitoring fließen.

Ordnung ins Chaos

Viele Cloud-Provider ermöglichen die Definition von globalen Sicherheitsregeln, mit denen sich die im Sicherheitskonzept definierten Mindeststandards umsetzen lassen. Eine der Sicherheitsregeln, deren Bedeutung man gar nicht genug betonen kann, stellt sicher, dass sich neue Ressourcen nur dann aktivieren lassen, wenn sie mit Tags versehen sind.

Das klingt nach einer Kleinigkeit für Buchhalterseelen, ist aber ein wichtiges Element einer sicheren Cloud-Strategie. Denn Tags schaffen Ordnung im Chaos und ermöglichen den Überblick, ohne den Security weitgehend nutzloses Stückwerk bleibt. Sie identifizieren etwa den Ressourcen- und damit auch Kosten-Eigentümer. Sie legen Sicherheitseinstufungen fest. Mit Tags kann man Ressourcen gezielt und automatisiert (de-)aktivieren. Damit die dazu verwendeten Tags vom Aufbau und der Benamung auch zueinander passen, sollte es eine globale Namenskonvention für Tags in der Cloud geben, die im Sicherheitskonzept dokumentiert ist.

Und schließlich sollte das Sicherheitskonzept den Einsatz von Verschlüsselung regeln. Also grob gesagt: Welche Daten sind wann wie zu verschlüsseln und wer verwaltet die Schlüssel dazu? Grundlage dieser Festlegung ist die Natur der verarbeiteten Daten und deren jeweiliger Schutzbedarf, die man ja bereits im Rahmen der DSGVO-Konformität dokumentiert haben sollte.

Die meisten Cloud-Provider verschlüsseln im Zuge der Mandantentrennung bereits auf unterschiedlichen Ebenen. In diesen Fällen verwaltet der Cloud-Provider auch das Schlüsselmaterial. Das mag in vielen Fällen ausreichend sein; bei speziellen Compliance-Anforderungen und besonderem Schutzbedarf ist das jedoch nicht zulässig. Dann muss der Kunde das Schlüssel-Management übernehmen. Das erhöht die Sicherheit aber nur dann, wenn es sorgfältig organisiert ist. Wichtig ist dabei unter anderem, den Lebenszyklus von Zertifikaten zu überwachen, damit diese vor ihrem Ablauf ausgetauscht werden. Dieser Vorgang sollte möglichst weit automatisiert stattfinden.

Notfallvorsorge ist besser als Nachsorge

Zwar heben Cloud-Provider gerne ihre hohe Verfügbarkeit hervor. Doch Cloud-Dienste können und werden auch ausfallen. Und Sie sollten darauf vorbereitet sein. Am besten mit einem vorab erstellten Notfallkonzept für den Cloud-Dienst. Das muss insbesondere alle Ansprechpartner, deren Kontaktdaten und Zuständigkeiten enthalten. Es ist fast schon peinlich, aber man muss es immer wieder sagen: Das Notfallkonzept muss unbedingt lokal vorliegen! Am besten ausgedruckt auf Papier.

Da die Cloud auf Redundanz und nicht auf Datensicherheit ausgerichtet ist, sollte man eine separate Datensicherung definieren. Diese kann beim eigenen Cloud-Provider erfolgen, eventuell über einen Cloud-Dienst den man buchen kann. Oder man sichert die Daten zurück in die lokale Datensicherung.

Weiterhin sollte man regelmäßig Notfallübungen durchführen. Diese sollten auch eine Rücksicherung größerer Datenmengen in die Cloud durchexerzieren. Denn Sie wollen nicht erst bei einem echten Notfall feststellen, was da alles schief laufen kann. Also dass beispielsweise die Wiederherstellung deutlich länger dauert, als ein Ausfall tolerierbar ist. Oder dabei Service Level Agreements überschritten werden, so dass hohe Konventionalstrafen anfallen. Das sind keine ausgedachten Fails, sondern ist tatsächlich und sogar mehrfach so geschehen.

Fazit und Ausblick

Überhaupt sollten Sie davon ausgehen, dass Sie Dinge übersehen oder vergessen. Der Knackpunkt dabei ist, das dann möglichst frühzeitig zu bemerken. Also nicht erst wenn das Kind bereits im Brunnen ist, sondern zu einem Zeitpunkt, zu dem Sie noch gegensteuern können.

Ein typisches Beispiel aus unserer Praxis ist eine vergessene Ressourcenbegrenzung pro Cloud-Konto. Deren Überschreitung kann zu einem Ausfall in der Cloud mit sehr unangenehmen und vor allem teuren Folgen führen. Wer das einmal durchgemacht hat, wird zukünftig sein Kapazitätsmonitoring ordentlich aufsetzen.

Hoffentlich hilft Ihnen diese Abhandlung dabei, Ihre eigenen Cloud-Projekte systematisch und geplant anzugehen. Denn nur so lassen sich die Gefahren einer überhasteten Migration vermeiden. Und damit Sie danach nicht übermütig werden, beschäftigt sich der vierte und letzte Teil mit den Dingen, die nach einem erfolgreichen Start des Cloud-Projekts anstehen. Darüber hinaus bereiten die Autoren der Serie ihre Tipps und Konzepte im heise-Security-Webinar In die Cloud - aber sicher [9], gezielt für IT- und Sicherheitsverantwortliche auf und stehen da auch für konkrete Fragen zur Verfügung.

[10]

(ju [11])

URL dieses Artikels:
https://www.heise.de/-4917363

Links in diesem Artikel:
[1] https://www.heise.de/hintergrund/Cloud-fuer-Unternehmen-Typische-Fehler-und-was-man-daraus-lernen-kann-1-4-4912754.html
[2] https://www.heise.de/hintergrund/Cloud-fuer-Unternehmen-Typische-Angriffe-und-wie-Sie-sich-schuetzen-2-4-4913820.html
[3] https://www.heise-events.de/webinare/cloud-aber-sicher
[4] https://www.heise.de/hintergrund/Cloud-fuer-Unternehmen-Typische-Fehler-und-was-man-daraus-lernen-kann-1-4-4912754.html
[5] https://www.heise.de/hintergrund/Cloud-fuer-Unternehmen-Typische-Angriffe-und-wie-Sie-sich-schuetzen-2-4-4913820.html
[6] https://www.heise.de/hintergrund/Cloud-fuer-Unternehmen-Der-sichere-Weg-in-die-Cloud-3-4-4917363.html
[7] https://www.heise.de/hintergrund/Cloud-fuer-Unternehmen-Ich-bin-schon-drin-was-nun-4-4-4918993.html
[8] https://www.heise.de/hintergrund/Cloud-fuer-Unternehmen-Typische-Angriffe-und-wie-Sie-sich-schuetzen-2-4-4913820.html
[9] https://heise.de/s/Q68v
[10] https://pro.heise.de/security/?LPID=39555_HS1L0001_27416_999_0&wt_mc=disp.fd.security-pro.security_pro24.disp.disp.disp
[11] mailto:ju@ct.de

Copyright © 2020 Heise Medien