Es lohnt sich, sich hierzu eine klare Vorstellung zu eigen zu machen! Insbesondere bei innerbetrieblichen Diskussionen zu Themen wie „selbstbetriebenes Rechenzentrum“, „Private Cloud“ und „Ist in der Cloud nicht alles billiger?“ muss man sich als RZ-Verantwortlicher klar positionieren.

Zur Definition des Begriffs „Cloud Computing“ wird die Begriffsbestimmung des NIST (National Institute of Standards and Technology, U.S. Department of Commerce, Special Publication 800-145, siehe https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf) bzw. des BSI (Bundesamt für Sicherheit in der Informationstechnik, siehe https://www.bsi.bund.de/DE/Themen/DigitaleGesellschaft/CloudComputing/Grundlagen/Grundlagen_node.html) mittlerweile allgemein anerkannt. In der Publikation des NIST werden dabei die fünf bekannten Merkmale des Cloud Computings genannt:

• On-demand Self Service
• Broad Network Access
• Resource Pooling
• Rapid Elasticity
• Measured Services

Zur Beurteilung eines SaaS-Angebots ist hieraus im Wesentlichen der Punkt „Broad Network Access“ wichtig. Broad Network Access bedeutet, „Die Services sind mit Standard-Mechanismen über das Netz verfügbar und nicht an einen bestimmten Client gebunden.“ (aus dem oben genannten BSI-Dokument). Natürlich spielt hierbei die Natur der Anwendung eine wesentliche Rolle. Ein Client für eine Telefonieanwendung sieht anders aus und bedient sich anderer Mechanismen (sprich Protokolle) als ein Client für eine Office-Anwendung, mit der man klassisch Dokumente über eine grafische Benutzeroberfläche bearbeitet.

Gemeinsam bleibt trotzdem die Forderung, dass der Zugriff von einer breiten Palette von Endgeräten aus möglich ist, und dass die Anwendung über „das Netz“ vom Service-Provider zentral zur Verfügung gestellt wird. Beides hat nämlich Konsequenzen auf die Anwendung, deren Architektur und deren Leistungsumfang!

Zunächst einmal muss man feststellen, dass Cloud Services streng standardisiert sind – es gibt hierfür das schöne Wort „Software von der Stange“, denn auch kundenspezifische Anpassungen sind meist nur in sehr beschränktem Umfang möglich. Das bedeutet, man erhält einen klar abgegrenzten Leistungsumfang. Wo spezielles Customizing bei selbst betriebenen Lösungen meist zwar teuer, aber umsetzbar ist, sind vergleichbare Anpassungen bei Cloud-Anwendungen schlicht nicht möglich. Hier gilt: Wenn’s passt, passt’s, wenn nicht, dann nicht.

Klar, das fällt bei einem Service, der eine Datenbank übers Web zur Verfügung stellt, weniger ins Gewicht als bei einer Telefonanlage aus der Cloud – das Prinzip bleibt aber. Und was ich oben mit „Leistungsumfang“ bezeichnet habe, ist nicht allein der Funktionsumfang der Lösung selbst, sondern beispielsweise auch der Support für die Lösung, Verfügbarkeitszusagen etc.!

Der zweite Aspekt, der sich aus „Broad Network Access“ ergibt, ist eine veränderte Software-Architektur der Lösungen. Cloud-Anwendungen sind nicht einfach herkömmliche Client-Server-Anwendungen, die jetzt auf einem entfernten Computer gehostet werden. Cloud-Anwendungen sind andere Anwendungen.

Das liegt natürlich zum einen an den veränderten Anforderungen, denen sich eine Cloud-Anwendung stellen muss: unzuverlässige Netzanbindung, Verbindungsabbrüche, wechselnde IP-Adressen, schwankende Verbindungsgüte und Bandbreite, etc. Zum andern bedeuten die „Standard-Mechanismen“ des BSI in den aller meisten Fällen, webbasierende Schnittstellen wie REST oder SOAP. Wenn der Client einer Cloud-Anwendung aber ein Browser ist bzw. im Browser dargestellt wird, muss der Großteil der Anwendungslogik auf der Serverseite in der Cloud liegen. Beachten Sie in dem Zusammenhang, dass die meisten „Apps“, insbesondere diejenigen, die unter Android oder iOS laufen, nichts anderes als abgespeckte Browser mit anwendungsspezifischer Oberfläche sind.

Und last but not least: Anwendungen, die aus der Cloud zur Verfügung gestellt werden, können nur auf Daten zugreifen, die ebenfalls über Standardprotokolle erreicht werden können. Kurz: Cloud-Anwendungen können nur auf Cloud-Daten zugreifen.

Alle diese Aspekte haben zur Folge, dass Cloud-Anwendungen eine andere Software-Architektur zugrunde liegt. Und das wiederum bedeutet, dass Cloud-Anwendungen andere Funktionen haben als vergleichbare Anwendungen, die lokal installiert werden. So gibt es bei den Office-Online-Anwendungen aus Office 365 keine „Speichern“-Funktion, da jede Änderung am Dokument direkt in die Cloud geschrieben wird. Ein Speichern beim Beenden ist überflüssig, das Cloud-Dokument wird zu jeder Zeit aktuell gehalten. Oder: Office-Dokumente in der Cloud können gleichzeitig von mehreren Personen bearbeitet werden. Das geht bei einem lokal gespeicherten Dokument nicht und auch nicht, wenn man via SMB oder einem ähnlichen Protokoll auf ein entferntes Dateisystem zugreift. Ganz einfach, weil weder das lokale noch das entfernte Dateisystem weiß, wie beispielsweise ein Word-Dokument aufgebaut ist und wie mit konkurrierenden Zugriffen umgegangen werden soll. In der Cloud geht das – mit gravierenden Folgen für das Thema Kollaboration mit Office-Anwendungen. Kollaboration wurde damit zu einem der größten Treiber für Cloud-Anwendungen.

Was sind jetzt also die Basisaufgaben beim Gang in die Cloud, bei der Entscheidung über eine Cloud-Anwendung und deren Einführung?

1. Sie brauchen eine klare Zielvorgabe.
2. Sie müssen über eine möglichst einheitliche Administration und Benutzerverwaltung entscheiden.
3. Sie müssen entscheiden, wo Ihre Daten liegen und wie darauf zugegriffen wird.
4. Es sind eine ganz Reihe von Sicherheits- und Compliance-Fragen zu klären:a. Wer darf auf welche Daten zugreifen?
   b. Welche Daten dürfen in die Cloud und welche gegebenenfalls nicht?
   c. Welche Daten dürfen weitergegeben oder Dritten zugänglich gemacht werden?
   d. Von wo aus darf auf welche Daten zugegriffen werden?
   e. Müssen die Daten gegebenenfalls verschlüsselt werden?
5. Sie müssen klären, welche Auswirkungen die Einführung der Cloud-Anwendung auf Ihre Infrastruktur, insbesondere auf Ihr internes Netzwerk hat.

Beginnen wir mit Punkt 1, einer Zielvorgabe

Sie sollten die Einführung einer Cloud-Anwendung keineswegs unterschätzen oder auf die leichte Schulter nehmen. Ja, eine Cloud-Anwendung ist schnell beschafft und allen Benutzern zur Verfügung gestellt, insbesondere wenn es eine browserbasierende Clientschnittstelle gibt. Ein Browser dürfte auf den meisten Endgeräten bereits installiert sein und die meisten Firewalls stellen auch keine unüberwindliche Hürde dar. Ok, ein moderner Browser sollte es schon sein. Mit dem Internet Explorer 6 kommen Sie in der neuen Welt nicht besonders weit und auch ein Safari hakt bei Cloud-Anwendungen doch vergleichsweise häufig.

Und auch finanziell machen einem die meisten Service-Anbieter mit kostenlosen Teststellung oder kostenloser Privatnutzung den Einstieg oft genug verflixt einfach.

Trotzdem dürfen Sie nicht vergessen, dass eine Anwendung einen Zweck hat, eine Aufgabe erfüllt. Selbst wenn eine Anwendung zunächst nur von wenigen Mitarbeitern produktiv genutzt wird, werden dadurch Geschäftsprozesse verändert. Und ehe Sie sich versehen, ist die Anwendung unverzichtbar, wird sie von weiteren Mitarbeitern in völlig anderem Kontext genutzt, und es fehlen in der IT Knowhow und Ressourcen, um die „nur mal nebenbei“ eingeführte Anwendung vernünftig zu betreuen.

Das heißt, Sie brauchen eine klare Vorstellung, wie die neue Anwendung genutzt und was mit ihr erreicht werden soll. Basierend hierauf kann dann eine Zielvorgabe und gegebenenfalls auch ein Kriterienkatalog entwickelt werden, der zur Auswahl vergleichbarer Anwendung herangezogen wird. Die Erstellung eines Kriterienkatalogs macht jedoch nur dann Sinn, wenn es gelingt, die Kriterien aus vorhandenen oder zukünftig gewünschten, konkreten Geschäftsprozessen produktneutral abzuleiten. Zum Beispiel: „Details und Termine zu neuen Produkten sollen allen Sales-Mitarbeitern zur Verfügung stehen.“ oder „Die Teilnahme an internen Telefonkonferenzen soll allen Mitarbeitern von ihrem Arbeitsplatz möglich sein.“. Wenn Sie beginnen, Leistungsmerkmale aus Produktprospekten abzuschreiben, lügen Sie sich in die eigene Tasche und konzentrieren sich auf toll klingende Alleinstellungsmerkmale einzelner Hersteller, die unterm Strich eine produktneutrale Auswahl zwischen Anwendungen verschiedener Hersteller eher verhindert.

Jenseits der konkreten Anwendungen, über die Sie diskutieren, gibt es jedoch einige Standardziele, die praktisch immer mit Cloud-Anwendungen verbunden sind:

• mehr Flexibilität
  • Nutzung unterschiedlicher Endgeräte
  • Zugriff auf stets aktuelle Daten von überall
• höhere Agilität
  • schneller und einfacher Zugriff auf Informationen
  • integrierte Nutzung mit vorhandenen Anwendungen
  • einfache Erweiterungsfähigkeit um weitere Anwendungen bzw. Anwendungsblöcken
• Kommunikation & Kollaboration
  • einfache und direkte Kommunikationsmöglichkeiten
  • auch mit Externen

Auch diese eher generellen Ziele des Cloud Computings sollten nicht ignoriert werden. Ich will hier nur drei Punkte hervorheben.

Erstens, eine „Nutzung unterschiedlicher Endgeräte“ führt zwangsläufig zu Fragen wie

• Welche Endgeräte sollen konkret unterstützt werden?
• In wessen Zuständigkeit bzw. Besitz befinden sich diese Endgeräte?
• Muss ein Mobile Device Management (MDM) eingeführt werden?
  (Und schon haben wir ein neues, sicherlich nicht triviales Projekt aus der Taufe gehoben.)

Zweitens, eine „integrierte Nutzung von Anwendungen“ ist dringend zu empfehlen und muss als eigener Punkt auf einer Kriterienliste bewertet werden. Die Nutzung isolierter, nicht integrierter Tools führt zur Verwirrung und Frustration Ihrer Anwender, insbesondere im Bereich Kommunikation und Kollaboration. So muss beispielsweise ein Kommunikationstool, falls es über eine Präsenzanzeige verfügt, dazu in der Lage sein, den eigenen Präsenzstatus mit dem des zentralen Kommunikationstool zu synchronisieren. Unterschiedliche Präsenzstatus je nach gerade verwendetem Tool sind nicht akzeptabel. Genauso sollten Funktionsfelder wie Terminplanung oder Aufgaben nur in begründeten Ausnahmefällen mehrfach nebeneinander in unterschiedlichen Tools existieren. Typische Fragen, die in diesem Zusammenhang beantwortet werden müssen, sind:

• Sind Sie bereit für eine weitgehend integrierte Gesamtlösung wie beispielsweise Office 365 mit Schwächen in Teilbereichen zu leben?
• Und in welchem Umfang akzeptieren Sie weitere SaaS-Produkte, „nur“ um einige dieser Schwächen zu kompensieren? Zu beachten ist hierbei in jedem Fall, dass in aller Regel durch Drittprodukte zusätzliche Kosten entstehen. Außerdem wird das Drittprodukt meist nicht so hoch in die große Lösung integriert sein.

Der dritte Punkt betrifft die „Integration von Externen“: Eine aktive Zusammenarbeit mit externen Partnern ist immer ein wichtiger Punkt bei Projekten aller Art. Da wir hier über Cloud-Anwendungen sprechen, die sich ja dadurch auszeichnen, von überall aus genutzt werden zu können, steht einer gemeinsamen Nutzung solcher Anwendungen rein technisch nichts im Wege. Trotzdem gibt es hierbei einige Fallstricke zu bedenken:

1. Aus dem Consumer-Markt sind Produkte bekannt, die eine anonyme Teilnahme weitere Nutzer erlauben, so können beispielsweise Bilder und Dokumente oft allein über die Weitergabe eines speziellen Links freigegeben bzw. „geteilt“ werden. Vergleichbare Möglichkeiten haben auch einige Enterprise-Produkte.Da bei geschäftlichen Projekten jedoch in der Regel mit sensiblen Daten umgegangen werden muss, ist eine solche unkontrollierbare Freigabe meist nicht erwünscht. Insbesondere wenn der externe Partner die Berechtigung erhält, Daten zu ändern oder Dokumente hochzuladen, muss er eindeutig identifiziert werden können. Gleiches gilt, wenn es nachvollziehbar sein soll, wer wann an dem Projekt gearbeitet hat.
2. Soll ein externer Partner/Mitarbeiter identifizierbar sein, bedeutet das, er muss sich mit Benutzernamen und Passwort anmelden. Dies zieht jedoch eine Reihe weiterer Fragen nach sich:a.Ist der Partner bereit sich eigene Anmeldedaten für dieses Projekt zu merken und damit umzugehen? Gegebenenfalls muss der Partner sich ja hierfür beim Service Provider registrieren, was nicht immer mit Begeisterung akzeptiert wird.
   b. Wie sehen die Lizenzbedingungen und insbesondere die Lizenzkosten für externe Mitarbeiter aus? Oder muss der Partner wie ein interner Mitarbeiter lizenziert werden?
   c. Falls Kosten anfallen, wer trägt diese?
   d. Auf welcher Ebene können Zugriffsrechte für Externe vergeben werden?
   e. Können Zugriffs- bzw. Zugangsrechte zeitlich begrenzt werden?
   f. Wird die Anwesenheit Externer signalisiert – und wenn ja, wie?
   g. Existieren weitere Akzeptanzhemmnisse wie zum Beispiel Schulungsbedarf?

Eine sehr komfortable und weitgehende Lösung zur Integration Externer hat übrigens Microsoft bei Office 365 und Teams geschaffen. Externe können einfach via E-Mail zu einem Team eingeladen werden und müssen dann eine sehr einfache und reduzierte Registrierung durchlaufen, wo sie lediglich ein Passwort und einen Klartextnamen für ihren Account festlegen müssen. Der Status „Externer“ wird hierbei über die E-Mail-Domäne festgestellt. Solche Accounts sind vollständig kostenfrei, werden aber trotzdem transparent als eigenes Benutzerkonto im Active Directory geführt. Damit sind alle Aktionen und Richtlinien wie für normale Benutzerkonten möglich. Hierzu zählen:

• Kennwortrichtlinien
• Richtlinien zu Data Loss Prevention
• Zuordnung zu Gruppen
• Sperren des Kontos
• u. m.

Punkt 2: Administration und Benutzerverwaltung

Jede Cloud-Anwendung muss getrennt administriert werden und jeder Cloud Provider kommt mit einer eigenen Benutzerverwaltung in der Cloud daher. Letzteres ist natürlich dem Anspruch von Cloud-Anwendungen geschuldet, ohne besondere Anforderungen an die Umgebung, in der sie gestartet werden, zu funktionieren (anywhere, anytime, any device). „Any device“ wird hierbei, wie oben bereits erwähnt, typischerweise dadurch erreicht, dass auf Web-Technologien und Zugriff via Browser gesetzt wird. „Anywhere“ bedeutet jedoch, dass die Anwendungen über das Internet mehr oder weniger öffentlich erreichbar sind und damit natürlich hohen Sicherheitsanforderungen unterliegen: Jeder Zugriff muss authentifiziert werden und oft wird Sicherheit seitens der Provider dadurch vorgegaukelt, dass für die Zugangspasswörter eine hohe Komplexität gefordert wird.

Da diese Authentifizierung natürlich auf der Cloud-Seite, also beim Provider selbst erfolgen muss, muss jeder Provider eine eigene Zugangslösung mit eigener Benutzerdatenbank und oft zusätzlich mit eigenem Rechtekonzept betreiben. Dies birgt ein hohes Konfliktpotential in sich, insbesondere wenn Sie mehrere Cloud-Anwendungen verschiedener Provider im Einsatz haben:

1. Die Benutzer müssen sich mehrere Benutzernamen-Passwort-Kombinationen merken, deren Passwörter möglichst komplex sein sollen – wobei unterschiedliche Provider gerne unterschiedliche Vorstellungen von „komplex“ haben und daher mit unterschiedlichen Vorgaben für die Passwörter daherkommen.
   Hier öffnet sich schnell ein riesiges Sicherheitsproblem, wenn die Benutzer beispielsweise anfangen, sich ihre Passwörter aufzuschreiben, nach Ablauf von Passwörtern nur an der letzten Stelle einen Zähler zu erhöhen, einheitliche Passwörter über verschiedene Provider hinweg zu nutzen (die dann aber zu unterschiedlichen Zeiten ablaufen und dann eben schnell eben nicht mehr einheitlich sind) etc. pp.
   Wenn sich dann auch noch die Benutzernamen bei verschiedenen Produkten unterscheiden, ist die Akzeptanz bei den Mitarbeitern schnell völlig am Ende. Und der direkt beim Passwort aufgeschrieben Benutzername führt jedes Sicherheitskonzept ad absurdem.
2. Aber auch für die IT und die Benutzeradministration explodieren plötzlich die Aufgaben: Nicht allein, dass verschiedene Cloud-Anwendungen über unterschiedliche Portale mit meist völlig unterschiedlicher Benutzeroberfläche und Bedienlogik gesteuert werden müssen, es müssen über diese unterschiedliche Portale Benutzerkonten für alle Benutzer angelegt werden und diese ganzen Konten müssen für die gesamte Nutzungszeit der Anwendung aktuell gehalten werden. Das heißt: Gesperrte Benutzerkonten wieder freischalten, Benutzerkonten für neue Mitarbeiter anlegen und – ganz wichtig – für ausgeschiedene Mitarbeiter die Konten löschen oder zumindest sperren. Vergessen Sie nicht, wir sprechen hier über Cloud-Anwendungen! Das heißt, der ausgeschiedene Mitarbeiter hat in der Regel auch außerhalb des Unternehmens Zugriff auf die Anwendung!
3. Zugriffsrechte und andere anwendungsspezifische Rechte lassen sich besser und einfacher in den Griff bekommen, wenn sie auf einem Gruppenkonzept basieren als wenn sie einzelnen Benutzern zugeordnet werden. Aber auch diese Gruppen müssen dann natürlich über die verschiedenen Provider hinweg gleich gehalten werden.
4. In der Regel gibt es zusätzlich auch noch weiterhin ein lokales Benutzerverzeichnis, meist ein Active Directory, welches weiterhin den Zugriff auf alle internen Ressourcen steuert.

Dieser gesamte Komplex ist offensichtlich äußerst sicherheitsrelevant. Fehler in diesem Umfeld führen schnell zu signifikanten Sicherheitsproblemen. Wie bereits erwähnt, ist ein wesentlicher Mehrwert von Cloud-Anwendungen die Möglichkeit, von überall auf die Anwendung zugreifen zu können. Umso sensibler muss aber mit den Zugriffsrechten umgegangen werden. Mehrfach redundante Daten wie gleiche Benutzerkonten bei verschiedenen Providern und eine damit verbundene mehrfache manuelle Synchronisation sind aus Sicherheitssicht verheerend, inkonsistente Daten praktisch vorherbestimmt.
Eine automatisierte Lösung ist daher bei der Einführung von Cloud-Anwendungen unumgänglich!

Es gibt hier zwei Ansätze, die meist miteinander kombiniert werden:

1. Single Sign-On (SSO): Es wird ein Provider als führender Identity-Provider in der Cloud ausgewählt, der die Aufgabe übernimmt, alle Authentifizierungen in der Cloud zu koordinieren und damit alle Benutzerkonten eines Benutzers bei allen (verbundenen) Service-Providern zu einer einzigen Cloud Identität zusammenführt.
   Der Anwender muss sich damit nur noch ein einziges Mal beim Identity-Provider anmelden, dieser sorgt im Hintergrund und transparent für den Benutzer dafür, dass er alle Anwendungen, die für ihn freigegeben sind, ohne erneute Authentifizierung nutzen kann.
2. Synchronisation zwischen diesem Identity-Provider und dem lokalen Active Directory, um auch die lokale Identität mit der Cloud-Identität der Benutzer (in Teilen) zusammenzuführen.

Diese Lösungen im Detail vorzustellen, würde den Rahmen dieses Artikels deutlich sprengen, daher habe ich im Folgenden nur einige wichtige Punkte aufgeführt:

• Single Sign-On muss von beiden Seiten durch das jeweils selbe Protokoll unterstützt und konfiguriert werden. Übliche Protokolle sind SAML, WS-Federation und OpenID Connect (OAuth 2.0), wobei sich SAML im Markt weitgehend durchgesetzt hat.
• Viele Service-Provider bieten rudimentäre SSO-Funktionalität auch als Identity-Provider an, Unterschiede zeigen sich in erweiterten Funktionsmerkmalen wie automatisches Anlegen neuer Konten, automatisches Sperren von Konten, Übertragen von Gruppenzugehörigkeit etc.
• SSO ist gerade bei der Integration von Funktionsbereichen Dritter in eine Cloud-Anwendung unverzichtbar.
• Die Anbindung eines lokalen Active Directory wird meist nur von hierauf spezialisierten Providern angeboten (Microsoft Azure, OneLogin, Okta, PingIdentity, …). Da seitens der Unternehmen meist ein von außen initiierter Zugang auf das interne Active Directory nicht gewünscht ist, setzen moderne Lösungen zum Teil auf interne Agenten, die die notwendigen Daten von innen aus dem internen AD zum Identity-Provider synchronisieren. Hier gibt es eine Reihe unterschiedlicher Spielarten:
• Synchronisation nur der Benutzerdaten, aber ohne Passwörter:
  Der Benutzer muss sich zweimal authentifizieren, einmal nach innen und einmal in der Cloud – gegebenenfalls mit unterschiedlichen Passwörtern.
• Synchronisation der Benutzerdaten inkl. Passwort:
  Auch hier muss sich der Benutzer eventuell zweimal authentifizieren.
• SSO zum internen AD im Zusammenspiel mit Active Directory Federation Services:
  Der Benutzer muss sich nur noch einmal anmelden.

Typische Problemfelder in diesem Umfeld sind:

• Will man über SSO und den Identity-Provider den Zugriff auf die Cloud-Anwendungen vollständig steuern (zum Beispiel durch Sperren des Zugangs und zusätzlicher Multi-Faktor Authentifizierung (MFA)), muss beim Service-Providern die Möglichkeit, sich direkt mit Benutzername und Passwort anzumelden, unterbunden werden.
• Bei manchen Providern funktioniert SSO nur, wenn die Benutzernamen auf beiden Seiten gleich lauten. Die ist übrigens ein Punkt, den wir sowieso dringend empfehlen. Es erleichtert die Zuordnung der verschiedenen Benutzerkonten nicht nur dem SSO-Protokoll sondern auch der eigenen Rechteverwaltung und Fehlersuche. Da viele Produkte als Benutzername eine E-Mail-Adresse fordern und praktisch alle diese Form unterstützen, ist es angeraten, alle Benutzername in dieser Form anzulegen.
• Können anwendungsspezifische Rechte auf der Seite des Service-Providers auf vorhandene Gruppenzugehörigkeit auf der Seite des Identity-Providers abgebildet werden?
• Die Verfügbarkeit des Identity-Providers schlägt natürlich unmittelbar auf die Verfügbarkeit der Cloud-Anwendung durch. Gleiches gilt bei einer Synchronisation mit dem lokalen AD. Hier sind geeignete Redundanzverfahren vorzusehen.