Vorbehalte gegen Cloud-Computing – Erwartungen und Realität
Cloud-Computing hat einen nie da gewesenen Weg in die Realität der Menschen in diesem Land genommen. Geprägt über Dienste, die zuerst im privaten Umfeld zur Verfügung standen, hat sich ein Selbstverständnis für die Bereitstellung von IT etabliert, das für die IT-Verantwortlichen in den Unternehmen mit traditionellen Ansätzen schwer zu erreichen ist. Wünsche sollen immer mehr "sofort" erfüllt werden.
Dennoch oder gerade deswegen steigt der weltweite Einsatz von Cloud-Services aller Art rasant, sowohl im privaten Umfeld als auch in den Unternehmen. Die Vorteile durch den Einsatz von Cloud-Technologien sind mittlerweile vielfältig bewiesen und die verschiedenen Lösungen praxiserprobt und im produktiven Einsatz. Im internationalen Vergleich hinkt Deutschland bzw. Europa bei der Adoption von öffentlichen Cloud-Services allerdings hinterher. Woran liegt das?
Speziell im unternehmerischen Umfeld halten sich hartnäckig diverse Vorbehalte, welche die Nutzung von Cloud-Technologien von Anfang an verhindern oder angestoßene Projekte in diese Richtung scheitern lassen. In diesem Artikel zeigen wir auf, welche Vorbehalte in jeder Diskussion zum Thema Cloud-Services in jedem Unternehmen auftauchen und wie Unternehmen bzw. die damit konfrontierten Personen damit umgehen können.
Der größte Vorbehalt: Die Angst vor Kontrollverlust
Die meisten Diskussionen, die über den Datenschutz bzgl. Cloud-Computing geführt werden, sind überschattet von der Angst, die Kontrolle über die eigene Infrastruktur zu verlieren. Es geht häufig nicht darum, was rechtlich notwendig ist und welche Normen angewandt werden. Die Datenschutz-Richtlinien sind von den Beauftragten für Datenschutz des Bundes und der Länder gut aufgearbeitet, aber häufig nicht bekannt genug. Aber das Thema "Governance" ist ein Schutzschild für die Veränderung der IT-Prozesse, für das Bekannte, historisch Gewachsene. Das Ergebnis ist, dass die Diskussion über Datenschutz mit denen geführt wird, die hier ein Laienverständnis haben.
Der Verlust der Kontrolle ist aber längst passiert, wenn die interne IT zu teuer, zu langsam oder zu unflexibel ist. Dann suchen sich die Benutzer einen Ausweg, in dem sie sich einfach im Internet bedienen. Das ist selten arglistig, sondern dient dem Geschäftszweck. So werden die eventuell anfallenden Kosten auch über die Spesenabrechnung geltend gemacht. Es entsteht Schatten-IT, die heute in den allermeisten Firmen vorhanden, wenn auch nicht offensichtlich ist. So stellt sich die Frage: Wie können die Verantwortlichen in der IT wieder ihrer Aufgabe nachkommen, die Governance im Sinne des Unternehmens zu gewährleisten, ohne die Agilität im Unternehmen zu behindern?
Alle großen Hacks gehen auf ein Verfahren zurück: Social Engineering
Die vollständige Kontrolle über die eigenen Daten und Services zu behalten und im Bedarfsfall steuernd eingreifen zu können, ist gerade bei verteilten Infrastrukturen oder Systemen, wie es Cloud-Services von Natur aus sind, eine extreme Herausforderung. Es gibt einfach zu viele Schnittstellen und Einfallstore für potentielle Angreifer, gerade in hybriden Cloud-Szenarien, die eine Vielzahl von Unternehmen aktuell fokussieren. Da erscheint es vielen offensichtlich als sicherste Option, die eigenen IT-Services und Systeme im eigenen Rechenzentrum – hinter hohen Mauern und durch eine eigene Firewall geschützt – zu betreiben. Aber die Firewall als Perimeter für die eigenen IT-Services, das war einmal. Alle großen Hacks/Breaches der letzten Jahre gehen auf ein Verfahren zurück: Social Engineering. Ein unberechtigter Angreifer beschafft sich die Zugangsdaten von einer berechtigten, vertrauenswürdigen Person, passiert damit alle nach außen gerichteten Sicherheits- und Kontrollmechanismen und beginnt dann, einmal im sicheren Bereich angekommen, mit seinen Aktivitäten. Da er sich augenscheinlich als vertrauenswürdig erwiesen hat, werden seine Aktivitäten in diesem Bereich auch nicht weiterverfolgt. In einer digitalisierten Welt, in der Identitätsdiebstahl mittlerweile an der Tagesordnung ist, funktioniert dieses Schutzkonzept genauso offensichtlich nicht mehr. Neue Verteidigungs- und Schutzmechanismen müssen her.
Der erste Schritt, sich effektiv gegen Angriffe auf Basis von Identitätsdiebstahl zu schützen, ist die Etablierung besserer Überwachungs- und Kontrollwerkzeuge. Eine einmalige Kontrolle am Zugangstor ist nicht mehr ausreichend. Es bedarf zusätzlicher, nach innen gerichteter Kontrollen, z. B. immer dann, wenn auf bestimmte Funktionen, Daten oder Systeme zugegriffen werden soll. Vielleicht müssen auch mal bestimmte Berechtigungen dynamisch eingeschränkt werden, bspw. wenn ein Zugriff auf besonders wichtige oder schützenswerte Informationen erfolgt. Diese Aufgabe erledigen bei der Nutzung von Cloud-Services sogenannte Cloud Access Security Broker (CASBs) [1]. Diese, zumeist ebenfalls Cloud-basierten Lösungen, kontrollieren den gesamten Datenstrom, der bei der Nutzung von Cloud-Services entsteht, und ergreifen automatisch entsprechende Maßnahmen, wenn sie einen Angriff erkennen oder vermuten. Sie basieren im Kern typischerweise auf Techniken aus dem Machine-Learning-Umfeld, also intelligenten Algorhythmen, die dynamisch und situationsgesteuert Entscheidungen für zu veranlassende Aktionen treffen. Das kann eine Alarmierung an das Sicherheits-Team sein oder die aktive Beschränkung einer Benutzersitzung, so dass ein Benutzer Daten z. B. ansehen, aber nicht kopieren oder weiterleiten kann.
Vorbehalt Nr. 2: Begebe ich mich in eine maximale Abhängigkeit?
Die Diskussion mit der Abhängigkeit kann man in fast jeder Beratungssituation beobachten. Jede Lösung, die ich nutze, kann mich abhängig von ihr machen. Die Abhängigkeit kommt meistens entweder durch Trägheit oder durch den finanziellen Aufwand von ihr loszukommen. Dabei ist die Diskussion nicht neu. Allein wenn man überlegt, in welches so genannte "Lock-In" man sich bei der Auswahl einer ERP-Lösung begibt. Ja, man kommt auch wieder raus, aber es bedeutet einen enormen Aufwand. Die Abhängigkeit wird in Bezug auf Cloud aber tendenziell eher für IaaS-Lösungen und ein wenig bei PaaS angeführt. SaaS wird oftmals nicht erwähnt, obwohl der Lock-In-Effekt hier am größten ist. Dennoch kann man diesem Vorbehalt proaktiv und mit entsprechenden Argumenten begegnen.
Denn Lock-In kann niemals komplett verhindert werden, da eine Entscheidung für einen bestimmten Service-Anbieter oder eine bestimmte Technologie immer auch eine Bindung, wenn auch nur für einen befristeten Zeitraum, darstellt. Darüber hinaus kann Lock-In wirtschaftlich durchaus sinnvoll sein, gewähren Anbieter bei Bezug von unterschiedlichen Services aus einem Haus doch oftmals größere Rabatte. Gleiches gilt bei Bezug eines Services über einen längeren, festgeschriebenen Zeitraum. Das typische Konterargument zu dem Lock-In-Vorbehalt sind Standards – besser noch: offene Standards. Das Problem mit Standards ist allerdings, dass es meistens mehr als einen gibt. Hier gilt: Augen auf bei der Anbieter-Wahl. Vorsicht ist vor allem dann geboten, wenn ein marktbeherrschender Anbieter versucht, einen Standard zu etablieren. In diesem Fall wird der Standard oft als Lock-In-Werkzeug missbraucht.
Um Lock-In in der Praxis zu verhindern, sollte man sich generell über die Adoption von offenen Standards Gedanken machen, die von einer breiten Masse bzw. von Organisationen und Unternehmen unterschiedlicher Art unterstützt werden und deren Verwaltung durch eine etablierte Organisation übernommen wird, z. B. der Linux oder der Apache Foundation.
Auch kann dem Lock-In-Effekt direkt bei der Applikations-Entwicklung entgegengewirkt werden. Hier hat sich mittlerweile ein Technologie-Ansatz etabliert, der den Lock-In-Effekt stark abmindert: Der Einsatz von Container-Technologien. Mit Hilfe dieser Technologien können Applikationen in kleine, modulare Einzelteile, oftmals auch als Microservices bezeichnet, zerlegt und in einem universellen Container verpackt werden. Die Analogie zum Shipping Container in der Logistik ist hier absolut beabsichtigt. Die IT-Container sind genauso einfach zu transportieren und zu handhaben, wie die Logistik-Container. Und sie können – genau wie diese – fast überall verwendet werden.
Unter dem Dach der Linux Foundation entwickelt sich hier übrigens aktuell ebenfalls ein offener Standard, der durch die Open Container Initiative [2] definiert wird.
Vorbehalt Nr. 3: Die Komplexität
Ein weiterer wichtiger Punkt in der Diskussion ist die Komplexität, die mit hybriden Infrastrukturen einhergeht. Denn faktisch hat heute jedes Unternehmen – mindestens durch die Schatten-IT oder auch gewollt - einen hybriden Ansatz. Wenn jetzt noch IaaS-Anbieter A mit SaaS-Anbieter B auf einer PaaS-Datenbank von Anbieter C gemischt werden, steigen die ersten Verzweifelten gedanklich aus. Dazu kommt, dass es auch in jeder privaten Cloud die verschiedenen Virtualisierungsarten zu kombinieren gilt: Storage-, Netzwerk-, Server-, Desktop- und Applikations-Virtualisierung gehören gemeinsam zur Gesamtarchitektur. Wenn jetzt noch einzelne Komponenten verschoben werden sollen, steigt die Angst vor der Komplexität, vor allem im Fehlerfall.
Wie kann die zusätzliche Komplexität, die durch die Nutzung von Cloud-Services oder den Aufbau eigener Cloud-Infrastrukturen entsteht, beseitigt werden? Die Zauberwörter in diesem Fall lauten "API" und "Automatisierung". Beides sind von jeher Haupteigenschaften von Cloud-Services jeglicher Art.
Eine dynamische Skalierung, wie sie z. B. bei öffentlich nutzbaren Streaming- oder Sharing-Angeboten notwendig ist, kann ohne dahinterliegende Automatisierung und die Nutzung von APIs nicht wirtschaftlich betrieben werden. Gleiches gilt für die Online-Spiele-Industrie, die es ohne entsprechende Automatisierungslösungen und die Cloud-Service-APIs nicht geben würde!
Unter den schicken Oberflächen der Portale von Amazon AWS oder Microsoft Azure verrichten deshalb zahlreiche Automatisierungslösungen und Controller-Services ihre Dienste, welche wiederum die vorhandenen APIs für die eigentliche Arbeit benutzen. Händische oder manuelle Eingriffe in die verschiedenen Abläufe sind eine absolute Ausnahme bzw. finden nur noch im Fehlerfall statt. Die Erfahrungen, Methoden und Werkzeuge der großen Anbieter halten mittlerweile auch Einzug in das Private Cloud-Umfeld, nicht zuletzt, da viele Lösungen im Open Source-Umfeld geboren werden bzw. von Unternehmen auch bewusst dahin überführt werden.
So genannte Configuration-Management-Lösungen wie Puppet, Chef, Ansible oder Salt sind die Musterbeispiele dieser Entwicklung und ermöglichen eine Automatisierung auf allen Ebenen von IT-Services, von der Infrastruktur bis zur Applikation (Full-Stack-Automation).
Dabei verfolgen diese Werkzeuge – entgegen der klassischen Script-Automatisierung – einen deklarativen Ansatz. Als Verantwortlicher für die Konfiguration einer Lösung definieren Sie also nicht mehr die einzelnen Schritte, um zu einem Ergebnis zu kommen, sondern das gewünschte Ergebnis selbst (Microsoft z. B. bezeichnet dies als Desired State) und treffen eine Zuordnung zwischen Zielsystem und Wunschkonfiguration. Den Rest übernimmt dann das Configuration Management System: sämtliche notwendigen Schritte, um das gewünschte Ergebnis zu erreichen, werden automatisch ausgeführt. Natürlich können Sie auch den Vorgang der Zuordnung des Zielsystems automatisieren. Die Vorteile dieser Herangehensweise: Geschwindigkeit, Nachvollziehbarkeit und Compliance, vor allem im täglichen Betrieb komplexer Cloud-Infrastrukturen.
Vorbehalt 4: Die Konkurrenz im eigenen Hause
Gerade die internen IT-Abteilungen mittelständischer und großer Unternehmen stehen heute immer mehr im Wettbewerb mit öffentlichen Cloud-Services und somit unter erhöhtem Leistungsdruck. Gab es in der Vergangenheit oftmals keinen Weg an ihnen vorbei, bestimmen heute immer öfter die Fachabteilungen, unterstützt durch Dienstleister mit entsprechendem Branchenfokus, in welche IT-Services das Geld investiert wird. Und diese kommen immer öfter aus der Public-Cloud. Gerade die internen IT-Abteilungen sollten sich deshalb den öffentlichen Cloud-Angeboten stärker öffnen, um ihre Sinnhaftigkeit und die Integrationsfähigkeit in die vorhandene IT-Service-Lieferkette zumindest überprüfen, bewerten oder ggf. eigene Alternativen anbieten zu können. Hinzukommt, dass die IT es nicht gewohnt war, die eigene Leistung zu bewerben. Es gibt zwar mehr oder weniger bekannte SLAs für die angebotenen Dienste, aber ein vergleichbarer Preis in einer Art wie "pro Benutzer pro Monat" oder "pro Gigabyte pro Monat" ist weitgehend unbekannt. Auch die Leistungen werden nicht aktiv vermarktet. So sind Postfach-Quota einfach gesetzt. Aber sind sie hoch oder niedrig? Unterscheidet sich die Quota im Preis? Solche und ähnliche Fragen sorgen für eine unnötige Intransparenz, die bei den "Konkurrenten" der Public Cloud wesentlich besser adressiert ist.
Cloud-Services Brokerage-Lösungen adressieren genau diesen kritischen Bereich, indem sie Unternehmen die Möglichkeit geben, öffentliche Cloud-Services mit bereits etablierten Services unter einer Oberfläche zu kombinieren bzw. öffentliche Cloud-Services als eigene Services über einen standardisierten Katalog anzubieten. Die Unternehmen behalten die Kontrolle über die Nutzung von IT-Services, vorhandene Service-Management-Prozesse können um Public-Cloud-Angebote erweitert und somit z. B. im Rahmen des Service-Design-Prozesses berücksichtigt werden. Die Brokerage-Plattform ruft dabei über die vorhandenen Schnittstellen der Public-Cloud-Services die verfügbaren Angebote und Preise stets aktuell ab und integriert diese in die entsprechenden Planungs- und Design-Prozesse der Cloud-Brokerage-Plattform. Somit lassen sich sehr einfach umfangreiche, auf realen Daten basierende Business Cases erstellen, anhand derer bergründete Entscheidungen für oder gegen den Einsatz von Cloud-Services getroffen werden können. Darüber hinaus sind natürlich auch Vergleiche zwischen unterschiedlichen Cloud-Services gleicher Art (z. B. Amazon AWS vs. Microsoft Azure) möglich.
Und auch noch wichtig: Die richtige Methodik
Cloud-Services sind in den Unternehmen angekommen, zentralisierte IT-Services als strategisches Asset der IT-Abteilung geraten immer stärker unter Druck bzw. sind auf dem Rückzug. Strategie- und Unternehmensberater forcieren Benchmarks interner IT-Services gegenüber öffentlichen Cloud-Services, Vorbehalte, z. B. im Datenschutz-Umfeld, konnten in den letzten Jahren durch regionale und funktionale Erweiterungen der Cloud-Services und positive Praxiserfahrungen abgebaut werden. Auf der technischen Ebene sind die meisten Herausforderungen bereits gelöst, entsprechende Best Practices sind reichhaltig vorhanden und gut dokumentiert. Die meisten Cloud-Services sind bzgl. ihres Reifegrades in einem Stadium angelangt, das bei einem entsprechenden Design hervorragende SLAs ermöglicht.
Ab sofort sollte es für die Unternehmen also nicht mehr darum gehen, die Ja-oder-Nein-Frage bzgl. des Einsatzes von Cloud-Services zu stellen, stattdessen sollte der Fokus auf die W-Fragen gelegt werden:
- Welche Services kann ich sinnvoll aus der Cloud beziehen? Welche eher nicht?
- Wie erfolgt die Integration bzw. wie gestalte ich den Übergang?
- Was wird an Ressourcen und Skills in der Zukunft benötigt? In welchen Bereichen meines Unternehmens?
- Und wer ist zukünftig für die IT-Services verantwortlich?
Dazu kommt die Frage nach der richtigen Strategie, wie die betroffenen Personen im Unternehmen (Administratoren wie auch Benutzer) richtig über die Veränderung informiert werden. Denn beim Einsatz von Technologie wurde in der Vergangenheit immer der Fehler gemacht, dass sie dem Benutzer hingeworfen wurde, ohne den Vorteil für die tägliche Arbeit herauszuarbeiten. Oder es wurden Prozesse in der IT entworfen, die von den EDV-Mitarbeitern nicht akzeptiert und damit ignoriert wurden. Bei der Einführung von neuen Cloud-Angeboten oder auch optimierten hybriden Szenarien ist es wichtig, die Menschen mitzunehmen, ihnen die Scheu vor der Veränderung zu nehmen und die Chancen durch die Nutzung aufzuzeigen. Dazu hat in diesem Jahr der Branchenverbrand EuroCloud einen Leitfaden zu den Best Practices im Bereich Cloud Projektmarketing herausgebracht [3].
Während die Unternehmenskommunikation die Technik nicht aufbereiten kann, ist die IT häufig nicht in der Lage, entsprechende Botschaften zu formulieren. Genau zwischen diese Bereiche platziert sich der Leitfaden, der zum Ziel hat, durch eine optimale Kommunikation des Vorhabens das Risiko eines Projektscheiterns zu minimieren und die Nutzung schnell nach oben zu treiben. Insofern lässt sich festhalten, dass es gegen die Vorbehalte, die es heute noch gibt, valide Lösungen gibt. Die Cloud-Welt ist voller Chancen, die nur intelligent kombiniert und kommuniziert werden müssen, um für die individuelle Anforderung die besten Lösungen zu bieten.
- Cloud Access Security Broker (CASBs)
- Open Container Initiative
- EuroCloud Deutschland: Leitfaden Cloud-Projektmarketing: Bewährte Praxistipps für die erfolgreiche Einführung eines Cloud Services
