Ein Cloud Starter-Kit oder was ist beim Einstieg in die Cloud zu beachten?

04.11.2018 / Cornelius Höchel-Winter /Referent

Cornelius Höchel-Winter

aus Netzwerk-Insider-Ausgabe November 2018

Cloud Computing ist zweifellos die wichtigste technologische Entwicklung unserer Zeit mit tiefgreifenden Auswirkungen für alle Unternehmen. Wesentliche Formen von Cloud Computing – insbesondere SaaS (Software as a Service) – zeigen alle Merkmale sowohl exponentieller als auch disruptiver Technologien. Oder anders formuliert: Niemand kann sich entziehen und in weiten Bereichen wird die IT, wie wir sie kennen, komplett umgekrempelt werden.

Über die Gründe hierfür, sowie über die Gefahren und Auswirkungen des Gangs in die Cloud wurden in diesem Medium und auch auf unzähliger unserer Veranstaltungen schon oft geschrieben bzw. gesprochen. Das Ziel des vorliegenden Artikels ist es daher nicht, diese Diskussionen erneut aufzuwärmen, sondern Kriterien und Maßnahmen aufzuzeigen, die Unternehmen den Einstieg in die Welt des Cloud Computings erleichtern und einen allzu blauäugigen Umstieg auf Cloud-Anwendungen verhindern sollen – ein Einsteiger-Kit für die Cloud so zu sagen.

Beginnen wir ganz grundlegend: Was bedeutet Cloud Computing? Wie unterscheidet sich Software as a Service von klassischen Anwendungen?

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.

Cloud Security
09.03.-10.03.2020 in Seeheim

Cloud Sicherheit ist der Schwerpunkt dieses Seminars. Cloud Computing ist inzwischen zum entscheidenden Instrument für das Angebot von IT-Diensten geworden. Es gibt immer mehr Produkte, die ausschließlich als Cloud-Dienst angeboten werden. Damit muss auch die Informationssicherheit integraler Bestandteil von Cloud Computing sein. Dieses Seminar liefert das notwendige Wissen, wie Cloud-Infrastrukturen nachhaltig abgesichert und wie Anforderungen der Informationssicherheit bei der Beschaffung von Cloud-Diensten berücksichtigt werden können. Praxisbeispiele runden das Seminar ab.

Punkt 3: Dokumentenverwaltung

Genau wie ein zentrales Benutzerverzeichnis ist auch ein zentrales Repository zur Dokumentenverwaltung gegenüber einer Vielzahl unterschiedlicher Speicher vorzuziehen:

  • einheitliche Bedienbarkeit,
  • Durchsuchbarkeit,
  • weniger Lizenzen / Lizenzkosten,
  • höheres Sicherheitsniveau durch einheitlich Compliance-Regeln, die auf einem System natürlich einfacher durchgesetzt werden können als auf mehreren.

Typische Kriterien zur Auswahl eines Cloud-Datenspeichers sind:

  • Wie erfolgt der Zugriff auf die Daten?
    • Ein browserbasierender Zugriff dürfte Standard sein, für Smartphones und Tablets gibt es meist speziell zugeschnittene Apps.
    • Sind weitere Zugangsprotokolle wie FTP oder WebDAV nötig?
    • Existiert eine Synchronisationslösung für Desktops?

Gerade bei den Synchronisationslösungen gibt es gewaltige Qualitätsunterschiede, die von „sehr flexibel“ bis „funktioniert in einer Mehrbenutzerumgebung einfach nicht“. Insbesondere wenn nur Teile einer Verzeichnisstruktur lokal verfügbar sein sollen, muss man die einzelnen Lösungen genau evaluieren. Insbesondere die Lösungen von Google mit GoogleDrive und von Microsoft mit OneDrive und SharePoint setzen hier Trends, an denen sich die anderen messen müssen.

  • Welche Funktionen zur Dokumentenbearbeitung stehen in der Cloud zur Verfügung?
    • In den meisten Fällen wird sich dies seitens des Speicher-Providers auf eine Voransicht / Leseansicht beschränken. Aber auch hier stellt sich die Frage, welche Formate unterstützt werden.
    • Eine direkte Dokumentenbearbeitung in der Cloud ist derzeit nur für wenige Formate von wenigen Service-Providern möglich. An erster Stelle ist hier natürlich Office 365 zu nennen, womit eine Bearbeitung im Browser von Word-, Excel-, PowerPoint- und Visio-Dokumenten möglich ist. Vergleichbare Funktionen bietet auch Google an, darüber hinaus gibt es eine Hand voll Bildbearbeitungsprogrammen in der Cloud.
    • Ohne Bearbeitungsmöglichkeit in der Cloud muss das Dokument heruntergeladen und mit Standardprogrammen lokal bearbeitet werden. Neben der Möglichkeit zu synchronisieren (siehe oben), bietet zum Beispiel Box mit BoxEdit eine Tool an, über das man beliebige Dokumente in der Cloud (Browser) zum Bearbeiten öffnen kann. Das Dokument wird dann heruntergeladen, lokal mit dem passenden Programm bearbeitet und nach dem Schließen im Hintergrund wieder automatisch in die Cloud hochgeladen.
  • Welche zusätzlichen Informationen bzw. Attribute sind mit dem Cloud-Dokument verbunden?

Weit verbreitet ist hier die Möglichkeit mehrere Versionen desselben Dokuments vorzuhalten und bei Bedarf darauf zurückgreifen zu können. Üblich sind darüber hinaus Möglichkeiten für Kommentare, Informationen über Zugriffe (wer und wann) und Aufbewahrungsregeln wie Mindestaufbewahrungszeit und automatische Löschung nach x Tagen/Jahren.

  • Wie können Dokumente und Verzeichnisse freigegeben werden?
    Hierzu gehört auch die Frage nach der Integration Externer, die oben bereits diskutiert wurde. Erweiterte Funktionen sind die zeitliche Begrenzung von Freigaben sowie reduzierte Berechtigungen wie Read-Only oder kein Upload.
  • Weitere Funktionen:
    • Berechtigungskonzept
    • Unterstützung eines Single Sign-Ons
    • Volltextsuche
    • Verschlüsselung und Watermarking
    • Reporting und Monitoring
    • Erweiterungsmöglichkeiten, APIs

So umfangreich diese Liste erscheinen mag (tatsächlich ist das nur ein grober Ausschnitt der wichtigsten Funktionsfelder), ein Cloud-Datenspeicher bietet im Kern nur diese eine Funktionalität: nämlich Daten zu speichern. Das heißt, genau wie die Benutzerverwaltung ist der Datenspeicher ein Baustein, ein zentraler Baustein zwar, aber nur ein Baustein für die eigentliche Anwendung, wie beispielsweise eine der Office-Online-Anwendungen oder ein UCC-Tool wie Teams oder Slack oder eine CRM-Anwendung wie Salesforce.

Für diese Anwendungen bedeutet dies im Umkehrschluss, dass sie auf den Cloud-Speicher zugreifen muss. Wir brauchen also eine möglichst enge Integration des Cloud-Speichers in unsere Anwendungen. Dies muss von Fall zu Fall geprüft werden, allgemein gültige Kriterien sind hier kaum möglich, da die Form der Integration doch sehr stark von der Natur der jeweiligen Anwendung abhängt. Unterstrichen werden muss nur Forderung, dass die Dokumentenverarbeitung und die Dokumentenablage aller (Cloud-)Anwendungen im zentralen Cloud-Speicher des Unternehmens erfolgen muss. Ein zusätzlicher anwendungsspezifischer Dokumentenspeicher ist unbedingt zu vermeiden.

Punkt 4: Sicherheit und Compliance

Auch dieser Punkt ist viel zu umfangreich und viel zu individuell, als dass man in diesem Rahmen allgemein gültige Ratschläge geben könnte. Viele relevante Punkte wurden außerdem schon erwähnt:

  • Wer darf auf welche Daten zugreifen?
    Hierfür ist ein Berechtigungskonzept zu erarbeiten bzw. das bestehende Konzept auf die Benutzerverwaltung, den Cloud-Speicher und die betroffenen Anwendungen zu übertragen.
  • Welche Daten dürfen in die Cloud und welche gegebenenfalls nicht?
    Die spannende Entscheidung hier ist die, ob das Unternehmen überhaupt zwischen Daten, die in die Cloud dürfen, und solchen, die nicht dürfen, unterscheidet. Wenn Sie nicht unterscheiden, sind Sie fein raus. Wenn Sie für einen Teil Ihrer Daten verhindern wollen, dass er in die Cloud wandert, müssen Sie

    a) diese Daten kennzeichnen und
    b) Ihren Mitarbeitern Hilfsmittel an die Hand geben wie diese Unterscheidung zu treffen ist.

Hierzu gibt es eine große Palette von Lösungen (Stichwort: Data Loss Prevention), die Sie bei der Verwaltung Ihrer Daten unterstützen.

  • Die nächste Ebene beim Thema Data Loss Prevention ist die Frage, ob Daten, die in der Cloud liegen, an Dritte weitergegeben werden dürfen. Hier gibt es eine Reihe von Möglichkeiten, wie Cloud-Datenspeicher eine Weitergabe vermeiden.
    In der Regel wird man jedoch schnell feststellen, dass diese Lösungen unzureichend sind. So kann ein berechtigter Benutzer ein Dokument beispielsweise herunterladen und es dann per E-Mail verschicken. Ob böswillig oder nicht spielt an dieser Stelle überhaupt keine Rolle.
    Man braucht also eine Lösung, die sich möglichst tief auch in andere Anwendungen integriert. Auch hier muss man feststellen, dass Microsoft bei Office 365 eine wirklich gute Lösung entwickelt hat. Das in Office 365 integrierte Data Loss Prevention überwacht nicht nur die Datenspeicher OneDrive und SharePoint und verhindert dort nicht erlaubte Freigaben, sondern verhindert auch die Weitergabe entsprechend markierter Dokumente via E-Mail (Exchange) oder Chat (Teams, Skype for Business).
  • Von wo aus darf auf welche Daten zugegriffen werden?
    Eines der Kernmerkmale von Cloud Computing ist der Zugriff von überall. In der Regel wird das auch so gewollt. Trotzdem gibt es natürlich Szenarien, wo Sie den Zugriff von überall beschränken wollen:

    • Administratoren sollen nur aus dem Unternehmensnetz heraus auf Administrationsportale zugreifen können.
    • Bestimmte Cloud-Anwendungen sollen nur in Europa genutzt werden dürfen.
    • Für Cloud-Anwendungen sollen beim Zugriff von außerhalb des Unternehmensnetzes ein zweites Authentifizierungsmerkmal bestätigt werden.

Dies sind Anforderungen an den Zugangsschutz der Anwendung, idealerweise an die zentrale SSO-Lösung. Gerade die großen Identity-Provider unterstützen Sie in unterschiedlicher Granularität mit gruppenspezifischen Zugangsbeschränkungen und Multi-Faktor Authentifizierung.

  • Müssen die Daten gegebenenfalls verschlüsselt werden?
    Verschlüsselung auf der Clientseite geht immer. Dies ist verbunden mit der größtmöglichen Kontrolle über die Verschlüsselungsart und die Schlüssel selbst. Microsoft unterstützt ein solches Szenario unter dem Begriff „Hold your own Key“ (HyoK). Der Haken dabei: Sie können keine Web-Schnittstellen mehr benutzen, jede Verarbeitung der Daten in der Cloud ist unmöglich, ebenso funktionieren keine Freigaben.
    Einige Provider bieten hier alternative Verfahren an, die aber meist darauf hinauslaufen, dass der Provider den Schlüssel bestimmt (und damit auch kennt). Auch unter dem Begriff „Bring your own Key“ (ByoK) bekannte Verfahren, bedeuten zumeist, dass man den Provider in die Lage versetzt, die Daten in der Cloud zu entschlüsseln.
  • Welche Compliance-Richtlinien müssen eingehalten werden?
    Wie erwähnt werden Compliance-Regeln, insbesondere Aufbewahrungspflichten und Löschpflichten von den Cloud-Speicherlösungen adressiert. Das heißt, Sie müssen hierfür kein teure Speziallösung betreiben wie es der Fall ist, wenn Sie die Daten in einem lokalen Speicher halten. Die (richtige) Cloudlösung bringt solche Funktion automatisch mit, Sie müssen sie nur nutzen – und in wenigen Fällen auch lizenzieren.

Punkt 5: Auswirkungen auf die Infrastruktur

Mit Cloud-Anwendungen ändern sich offensichtlich die Verkehrsströme im internen Netzwerk. Sie betreiben Ihre Anwendungen übers Internet und dementsprechend müssen Sie zumindest Ihren Internetzugang auslegen. Und zwar in zweierlei Hinsicht:

  1. Sie benötigen genügend Bandbreite, um Ihre Anwendungen zu betreiben.
  2. Ihr Zugangspunkt wird gegebenenfalls zum Single Point of Failure: ohne Internetzugang keine Cloud-Anwendung, kein Zugriff auf die Daten in der Cloud.
    Das heißt, Sie müssen gegebenenfalls für Ihren Internetzugang mehr Bandbreite einkaufen und je nach Anforderung Ihren Internetzugang redundant auslegen! Beim zuletzt genannten Punkt kann man unter Umständen noch prüfen, ob ein Notbetrieb über Mobilfunk ausreicht.

So oder so: Das kostet Geld! Sagen Sie das Ihrer Geschäftsführung.

Wieviel Bandbreite wird benötigt? Hüten Sie sich hier vor irgendwelchen Daumenregeln. Jede Aussage „x Mb/s pro User“ ist Quatsch und im Zweifelsfall falsch. Es schützt Sie nicht davor, selbst zu rechnen und zu messen.

Zu einer groben, aber wenigstens begründeten Schätzung kommen Sie wie folgt:

  • Wie viele Anwender arbeiten hinter einem Internetzugangspunkt?
  • Wie viele davon sind durchschnittlich anwesend? (70% ist ein realistischer Wert)
  • Für jede einzelne Anwendung:
    • Wie viel Bandbreite benötigt eine einzelne Aktion pro Zeiteinheit?
      • E-Mail: Wie viele E-Mails pro Tag und User und wie groß ist eine durchschnittliche E-Mail?
      • Dokumentenbearbeitung: wie eben
      • Synchronisation: wie eben
      • Sprachkommunikation: Direkte Gespräche innerhalb des Unternehmens verlassen nicht das interne Netz und können ignoriert werden.
      • Sprachkonferenzen müssen berücksichtigt werden, 25 – 30 kb/s pro Teilnehmer sind realistisch
      • Video ähnlich wie Sprache, Bandbreitenbedarf ist schwieriger abzuschätzen: Erfahrungswerte liegen zwischen 400 kb/s und 800 kb/s pro Teilnehmer
    • Bei Echtzeitanwendungen (Definition: „Der Anwender wartet auf den Abschluss der Aktion.“ Das heißt, hierunter fallen z.B. auch explizite Downloads, die der Benutzer anstößt.): Zu welchem Prozentsatz (Wahrscheinlichkeit) beanspruchen die Anwender die Leitung gleichzeitig?

Hieraus berechnet sich der durchschnittliche Bandbreitenbedarf pro Anwendung und in Summe der Bandbreitenbedarf am Zugangspunkt – vergessen Sie nicht die bereits vorhandene Auslastung zu berücksichtigen. Dies ergibt einen ersten Anhaltspunkt, wo Sie sich befinden. Der nächste Schritt sollte das Aufsetzen von Pilotprojekten und das Monitoring des Zugangspunkts sein.
Streaming-Anwendungen wie Sprache oder Video haben zusätzliche Anforderungen an die Leitungsqualität wie Jitter und Laufzeit. Insbesondere Jitter hat unmittelbare Auswirkungen auf die Gesprächsqualität, Microsoft fordert beispielsweise einen Wert kleiner 30 ms während jedes 15-Sek.-Intervalls. Daher kann es eine lohnende Maßnahme sein, Sprachverbindungen am Internetzugang zu priorisieren.

Generelle Empfehlung zur Netzwerkinfrastruktur sind:

  • Vermeiden Sie zentrale Internetzugänge für weit entfernte Niederlassungen. Lokale Zugänge für solche Niederlassungen verbessert die Laufzeit und damit die Antwortzeit der Anwendungen drastisch.
  • Bei Sicherheitsbedenken können die lokalen Zugänge auf die Cloud-Anwendungen beschränkt werden, ggfls. sogar auf Streaming-Anwendungen.
  • Vermeiden Sie Web-Proxies oder ähnliche Sicherheitsappliances für Cloud-Anwendungen. Viele zu steuern oder filtern gibt es bei Cloud-Anwendungen eh nicht und jede dieser Appliance vergrößert die Laufzeit.

Und vergessen Sie nicht: Cloud-Anwendungen sind anders, Cloud-Anwendungen ändern Ihre Geschäftsprozesse und erfahrungsgemäß ändert sich auch das Benutzerverhalten. Das heißt mit dem Einsatz von Cloud-Anwendungen wird das regelmäßige Monitoring Ihres Internetzugang zur Pflicht.

Der Netzwerk Insider vertritt monatlich mit seinen Artikeln die Sichtweise von Technologie-Anwendern und bewertet Produkte und Technologien im Sinne der wirtschaftlichen und erfolgreichen Umsetzbarkeit in der täglichen Praxis.

Der Bezug des Netzwerk Insiders ist kostenlos und wird Ihnen per E-Mail als PDF-Download und alternativ als Webversion zur Verfügung gestellt.

ComConsult Cloud Forum
25.11.-26.11.19 in Köln

Auf dem Kongress tragen projekterfahrene Referenten zu Nutzung von Software aus der Cloud, zu Nutzung der Cloud (PaaS, IaaS, Hybrid Cloud) für die Entwicklung, Bereitstellung und dem Betrieb eigener Lösungen und zu Cloud-Security vor. Die Fallstricke und Herausforderungen bei der Nutzung von SaaS-Angeboten wie Office 365 werden erklärt. Auf Cloud-basierende Anwendungen für IoT, Digitalisierung und Smart Technologies (zum Beispiel Smart Commercial Building) wird eingegangen. Die Anbindung an externe Clouds und die Konsequenzen für Netze bilden ebenfalls einen der Schwerpunkte des Forums. Anhand von Beispielen wird gezeigt, worin sich Cloud-basierte Bereitstellung und Betrieb von Anwendungen vom bisherigen IT-Betrieb on Premises unterscheidet. Ferner stehen Sicherheitsaspekte wie sicherer Cloud-Zugang, Schutz vor Datenverlust, Datensicherheit und Datenschutz auf der Agenda des Forums.

0 Antworten

Hinterlassen Sie einen Kommentar

Wollen Sie an der Diskussion teilnehmen?
Wir freuen uns über Ihren Beitrag!

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.