Cloud

NIST CSF Glenfis Banner

NIST – Next Generation Cyber Security Framework CSF 1.1

Cloud, Cyber Security, Governance, ITSM / Von

Die Unternehmen fangen an, so richtig in die Industrie 4.0 durchzustarten. Machine Learning, Internet of Things und grenzenlose Mobilität sollen es ermöglichen, von überall mit Maschinen und Verarbeitungsprozessen zu kommunizieren und auszutauschen. Der Besteller beeinflusst den Produktionsprozess und ist laufend über den Status informiert. Mit

NIST – Next Generation Cyber Security Framework CSF 1.1 weiterlesen »

Cloud Sourcing Lifecycle Operation

Cloud Sourcing LifeCycle – Part 5: Cloud Sourcing Operation

Agile, Architektur, Cloud, ITSM / Von

Es gibt verschiedene Adaption-Strategien, wie eine Cloud in Betrieb genommen werden kann. Ob virtuelle Maschinen quasi 1:1 (V2V) migriert, Applikationen mit «Lift and Shift» verschoben oder die gesamte IT Architektur den neuen Möglichkeiten der Cloud angepasst und somit transformiert wurde. Am Ende sind diese Cloud-Umgebungen

Cloud Sourcing LifeCycle – Part 5: Cloud Sourcing Operation weiterlesen »

Der Cloud Sourcing LifeCycle ist ein methodischer Ansatz, die Reise in die Cloud sicher und strukturiert anzugehen und damit den Business Mehrwert zu optimieren. Der Einsatz eines Hypervisors mit Verwaltung virtueller Maschinen ist noch keine Cloud, obwohl das viele System-Administratoren gerne behaupten und ihrer Organisation vorgaukeln, schon lange in der Cloud zu sein. Ein Übersicht des Cloud Sourcing LifeCycle sowie die Bedeutung der Cloud Sourcing Strategie wurden bereits beschrieben. In diesem Blog fokussiere ich mich auf das Cloud Sourcing Design. Es ist wichtig zu verstehen, was Cloud ist und was diese von den traditionellen IT Service Delivery Modellen oder IT Outsourcing Modellen unterscheidet. Gerade diese Unterschiede sind für Unternehmen entscheidend, um den Mehrwert der IT zu steigern, die Kosten zu senken und die Qualität der Service Levels zu versbessern. Dieses Verständnis ist auch wichtig, um die Risiken und Chancen der Cloud für das Unternehmen optimal auszubalancieren. Die Grundlagen dazu sind in der Cloud Sourcing Strategie definiert worden (Siehe dazu auch: Cloud Adaption Strategie). Es gibt im Grunde zwei wesentliche Treiber für die Nutzung der Cloud im Unternehmen: - Need for Speed: die Agilität des Internets muss für das Unternehmen genutzt werden, um mit den Veränderungen im Netz Schritt halten zu können. Anstelle Lösungen mit Projekten über Laufzeiten von Jahren liefern zu können, soll die Elastizität und Skalierbarkeit der Cloud genutzt werden, rasch neue Lösungen den Kunden anbieten zu können. Denn der nächste Konkurrent ist womöglich eine App eines Startups - Kostenmodell Optimierung: Die Kostenmodelle verändern sich mit der Cloud massiv. Während man in traditionellen Umgebungen grosse Investitionsprojekte gestemmt hat (Cap-Ex) verschiebt sich mit der Cloud die Kosten nur noch in die operativen Bücher (Op-Ex). Man ist nicht mehr an langjährige Abschreibe-Zyklen oder IT-Outsourcing-Verträge gebunden, sondern bezahlt nur noch was man tatsächlich braucht. Gerade letzteres hat einen massiven Einfluss auf die traditionellen Governance-Strukturen eines Unternehmens. Während bei traditionellen Projekten und Beschaffungen die Lösungs-Konzepte hinsichtlich Architektur, Informations-System, Sicherheit und Compliance in diversen Gremien und Review-Zyklen besprochen und über die Investition bereit abgestimmt wurden, sind Cloud nur noch operative Services, welche kein Investitionsbudget mehr tangieren. Daher verschwinden sie auch oft aus dem Blickwinkel der Governance bei der Beschaffung. Das Cloud Sourcing Design beschafft sich mit den Design-Aspekten einer Cloud-Lösung und Cloud-Integration ins Unternehmen. Folgende fünf Aspekte werden hier hervorgehoben: - Cloud Architektur Prinzipien - Cloud Solution Design - Cloud Management Plattform - Cloud Target Operation Modell - Cloud Transformation Plan Cloud Architektur Prinzipien Die Cloud-Lösung soll in die Architektur des Unternehmens integriert werden. Es gilt insbesondere sicherzustellen, dass keine isolierten Lösungen beschafft und unnötige Abhängigkeiten (Vendor Lock-In) geschaffen werden, wenn insbesondere kritische Business-Assets involviert sind. Ein Architekturschaubild ist hierzu hilfreich, um zu erkennen, welche Business Prozesse involviert sind, welche Datenflüsse betroffen sind und welche System-Schnittstellen (APIs) zu berücksichtigen sind. Folgende, nicht abschliessenden Architekturprinzipien sollten berücksichtigt werden: - Cloud Schnittstellen und Formate hinsichtlich Connectivity, Skalierbarkeit, Portabilität, Interoperabilität und Sicherheit müssen sich an den gängigen Industrie Standards ausrichten (NIST, ENISA, ISO) - Beschränken der auszutauschenden Daten auf das absolute Minimum: nur die Daten, welche zur Verarbeitung zwingend notwendig sind - Bereitstellen eines Monitorings bezüglich Ressourcen-Verbrauch, Nutzer und alle Aspekte, welche Bestandteile der Cloud-Kostenverrechnung sind - Alle zugesagten Ansprüche des Cloud-Kunden hinsichtlich Zuverlässigkeit, Sicherheit, Verfügbarkeit und Performance müssen überprüfbar sein. Insbesondere müssen die Messpunkte geklärt sein. Verfügbarkeit darf sich nicht auf die System-Verfügbarkeit im Rechenzentrum des Providers beziehen, sondern muss inklusive den darauf implementierten Diensten gemessen werden. - Klare und verlässliche Trennung der Identitäts-Domänen: Die verschiedenen Kunden des Cloud-Service dürfen keine Auswirkungen auf andere Kundendienste haben. - Transparenz bezüglich design der Cloud-Lösung, deren Standorte, beteiligte Unterlieferanten und Organisation des Betriebes - Transparent Architecture and Control – consumers have visibility into the design and operation of the system. - Datenschutz-Lösungen müssen den nationalen und internationalen Standards genügen – insbesondere der aktuell geforderten GDPR der EU. Diese Liste ist nicht abschliessend zu verstehen, sondern eher als Startpunkt für die Design-Überlegungen beim Einsatz der Cloud im Unternehmen. Bevor eine Cloud-Lösung identifiziert und beschafft werden kann, ist es auch sinnvoll und für die spätere Überprüfung (PoC, Proof of concept) wichtig, Cloud-Use-Cases zu entwickeln, welche für den Einsatz der Cloud notwendig sind. Mögliche Use-Cases sind: - Migration einer eigenen, bestehenden Applikation von zu einem IaaS-Provider oder einer privaten Cloud - Migration einer Reihe von Business-Funktionen von lokalen Anwendungen zu einem SaaS-Provider - Erweiterung eines älteren Legacy-Softwareprodukts, um diese Cloud-native mit Container-verpackter und dynamisch verwalteter Microservices-Architektur einzusetzen - Implementierung neuer Cloud-Anwendungen auf einer public oder privaten PaaS-Plattform - Implementierung neuer Cloud-Anwendungen in einer public oder privaten IaaS-Cloud - Verwenden von Cloud für alle Entwicklungs-, Test-, Staging-, Produktions- und Disaster Recovery-Workloads - Verwenden von Cloud für Entwicklung und Test - Verwenden von Cloud für Notfallwiederherstellung (Disaster-Recovery) - Identity & Access Management in der Cloud (Propagierung von Identitäten, Rechten; Änderungen von Profilen etc, siehe dazu mein Blog: Identity - der neue Perimeter). Auf Basis der vorhandenen Architektur muss auch auf die Technologie-Stacks Rücksicht genommen werden. Dies ist insbesondere wichtig für im Bereich - Server, Netzwerk, Storage und der automatisierten Anbindung - Datenbank-Technologien - Entwicklungsplattformen für PaaS-Umgebungen, inklusive den Stacks hinsichtlich Security, Messaging, Queuing, Notifikation, Orchestration, API-Management, Log-Management - Domänen spezifische Stacks hinsichtlich Anbindung an CRM, ERP, IoT ec. Cloud Solution Design Abhängig von der Cloud Sourcing Strategie und den vorhandenen Architektur-Prinzipien, gilt es eine geeignete Cloud-Lösung zu entwickeln, respektive im Markt auszuwählen. Nur – wie geht man genau vor? Welche Anforderungen definiert man und was kann man, soll man oder muss man gar bei einer Cloud-Lösung überprüfen? Ein Vertrag ist schnell abgeschlossen und der Click auf die AGBs des Cloud Service Providers wird gerne schnell getätigt, um möglichst rasch in den Genuss des Dienstes zu gelangen. Im Enterprise-Cloud Bereich für strategisch wichtige und sensible Dienste sollte die Organisation nicht so blauäugig einen Cloud Vertrag abschliessen. Es lohnt sich, hier die Anforderungen besser zu strukturieren. Insbesondere sollten Anforderungen definiert werden, welche folgende Themenbereiche abdecken: - Datensouveränität, Datenschutz: wie werden meine Anforderungen abgedeckt - Standorte – Gesetze: Welche Gesetzte gelten an den Standorten des Providers und seinen Sublieferanten? - Beteiligte Lieferanten: wer ist beteiligt an der Supply-Chain und wie ist das Verhältnis untereinander? - Vertragliche Zusicherungen: wie sehen die Verträge aus und welche Qualitätslevels werden zugesichert? - Vertragsbeendigung: Wie steige ich aus dem Vertrag aus – und unter welchen Bedingungen kann der Cloud Service Provider kündigen? - Sicherheit und Kontinuität: Was für Informations-Sicherheitsanforderungen erfüllt der Provider und wie ist er für ein Desaster gerüstet? - Service Leistungen und Überwachung: wie erbringt er den Service und wie reagiert er bei Störungen und Problemen? Bei der Auswahl des Cloud-Dienstes geht es nicht nur um den Cloud-Service alleine, sondern insbesondere auch um den Cloud Service Provider und seine Flexibilität auf die Bedürfnisse der Kunden. Eine Möglichkeit die Cloud-Anforderungen strukturiert anzubieten ist StarAudit. StarAudit ist eine unabhängige Non-Profit-Organisation mit einem internationalen Netzwerk von akkreditierten Partnern wie die Glenfis und Fachleuten. StarAudit unterstützt das Wachstum von Cloudbasierten Diensten und Innovationen weltweit. Die Tätigkeitsbereiche von StarAudit sind: Trust in Cloud, Bewusstseinsbildung, Datenschutzkonformität, Wissenstransfer, Start-up-Unterstützung, Standards und Interoperabilität, Harmonisierung rechtlicher Rahmenbedingungen. Der Vorteil bei StarAudit ist auch in der Möglichkeit, die Anforderungen bei allen potentiellen Cloud Service Providern direkt im Online-Tool zu beantworten. Das erleichtert die Vergleichbarkeit zwischen den Angeboten enorm. Nach der Evaluation und Bewertung von Cloud Services und Cloud Service Provider gilt es die Verträge zu prüfen und zu verhandeln. Dabei ist der Integration der Cloud Lösung und des Managements der Lösung in das Betriebsmodell der IT-Organisation (Siehe Cloud Target Operation Modell) zwingend Rechnung zu tragen. Cloud Management Plattform Die Erfahrung zeigt: Eine Cloud kommt selten alleine (Siehe dazu den Netzwoche-Beitrag zum Cloud-Talk in Zürich). Das Managen der Cloud, deren Provisionierung, Orchestrierung und Überwachung sind wesentliche Aufgaben der verbleibenden IT-Organisation. Cloud-Lösungen werden gemäss Nutzungsvereinbarungen verrechnet und diese sind in aller Regel Benutzer- und Kapazitätsabhängig. Es gilt also, die Nutzung transparent zu gestalten und die Verrechnung überprüfen zu können. All dies soll über eine möglichst Cloud-Anbieter neutrale Plattform, einer Cloud Management Plattform ermöglicht werden. Eine weitere Funktion bildet das Self-Service Portal, um den Zugang zur Cloud sollte nach der Einführung möglichst einfach zu gestalten. Auch Unterstützung bei der Optimierung von Cloud-Workloads sind essentielle Funktionen einer solchen Plattform. Die Angebote sind heute noch sehr unterschiedlich und jeder Cloud-Service-Provider kommt mit seiner, proprietären Lösung. Nur der Kunde kann nicht für jede Cloud ein isoliertes Management System einsetzen. Der Markt wird sich hier weiter entwickeln und neue Lösungen offerieren. Lesen Sie dazu den Beitrag im TechTarget: Is 2017 the year of the hybrid cloud management platform? Wenn eine Cloud-Lösung beschafft wird, so ist es zwingend wichtig, auch die notwendigen Instrumente und Tools für die Steuerung und Überwachung der Cloud innerhalb des Cloud Sourcing Designs zu berücksichtigen. Cloud Target Operation Modell Mit dem Einsatz der Cloud verändert sich zwangsläufig auch das Betriebsmodell der bestehenden IT-Organisation. Dabei ist Betriebsmodell nicht als «Produktionsbetrieb» von IT-Systemen oder Cloud-Diensten zu verstehen. Das Betriebsmodell ist das Rückgrat des Business- oder Geschäftsmodell, welches die Business Prozesse mit geforderten Lösungen versorgt: von der Idee, zur Umsetzung und Entwicklung, zur Bereitstellung bis hin zum technischen Betrieb und Support. Wie bereits eingangs erläutert, werden IT-Lösungen nicht mehr über Investitionsprogramme beschafft, sondern im operativen Betrieb bezogen, orchestriert und in den Betrieb integriert. Dazu braucht es Änderungen am gesamten Betriebsmodell der IT-Organisation. Das alte bewährte «Plan, Build, Run» Modell hat ausgedient. Neu gilt «Brokerage-Integration-Orchestration». Dies hat Einfluss auf bestehende Richtlinien und Policies, die Prozesse, die Rollen und Verantwortlichkeiten, die Fähigkeiten der Mitarbeiter, die Kultur im Unternehmen sowie der Umgang mit Lieferanten und seinen Services. Es ist nun wichtig, im Cloud Sourcing Design auch das künftige Cloud Betriebsmodell, das Target Operation Model zu definieren und die Organisation entsprechend zu verändern. Was das Cloud Target Operation Model alles beinhaltet, haben wir in einer Blog-Beitragsreihe ausführlich beschrieben: - Part I Target Operation Model – Technology - Part II Target Operation Model – Governance - Part III Target Operation Model – Services - Part IV Target Operation Model – Processes - Part V Target Operation Model – Organization - Part VI Target Operation Model – People Das neue Betriebsmodell muss den agilen Anforderungen des Business Rechnung tragen. Es werden nicht mehr alle heutigen Funktionen in diesem Umfang bereitstehen. Dafür werden neue Perspektiven eröffnet. Es ist wichtig, in diesem Veränderungsprozess gegenüber den Mitarbeitern, Partnern und Business-Fachabteilungen transparent zu sein. Die Cloud wird nicht nur die Bereitstellung von IT-Services verändern, sondern wird die Agilität in allen Abläufen des Unternehmens beeinflussen. DevOps oder bi-modale IT-Organisationen entstehen mit Cloud als Treiber. Mit der zunehmenden Reife und dem Cloud-Nutzungsgrad, wird sich auch das Betriebsmodell der IT in Zukunft wandeln. Lesen Sie dazu meinen Blogbeitrag «Das IT-Betriebsmodell der Zukunft – Blueprint auf Basis von IT4IT» Es gehört zum Cloud Sourcing Design, die künftige Arbeitsweise, Prozesse, Werkzeuge und Richtlinien zu entwickeln und in der Organisation abzustimmen. Diese müssen vorliegen, wenn das Onboarding des Cloud-Dienstes beginnt. Cloud Transformation Plan Ein Cloud-Lösung im Enterprise-Umfeld lässt sich nicht mit Drag & Drop auf dem Bildschirm bewerkstelligen. Abhängig vom Umfang und der Lösung des Cloud Sourcing Designs ist es nun wichtig die Transformation zu planen und die notwendigen Ressourcen bereitzustellen. Es braucht dazu ein Einführungs- und Migrationskonzept für: - Onboarding Cloud Service Provider und dessen Management System - Onboarding des Cloud Services und Migration der Daten, Applikationen und Schnittstellen - Implementation neues Cloud Target Operation Modell - Schulung der Benutzer und der Betriebsorganisation - Abbau von Infrastrukturen und Anwendungen, welche durch die Cloud-Lösung ersetzt wurden Entsprechend sind die WAN-Zugriffe, das Netzwerk-Zonenkonzept sowie die Integration in bestehende Lösungen genauso zu planen wie die Veränderung der Betriebsorganisation. Wenn bestehende Applikationen neu auf eine PaaS oder IaaS Plattform migriert werden sollen, ist teilweise mit einem Re-Design der Applikation zu rechnen – insbesondere dann, wenn nicht konsequent nach Standards entwickelt wurde. Der Cloud Transformation Plan ist die Basis für die nächste Phase des Cloud Sourcing LifeCycle, welchen ich im nächsten Blog beschreiben werde: Cloud Sourcing Transformation. Review Cloud Sourcing Strategie und Business Case Die in dieser Phase ermittelten Lösungen und Erkenntnisse müssen an der Cloud Sourcing Strategie gespiegelt und bezüglich Business Ziele abgeglichen werden. Es ist auch zu prüfen, ob sich zwischenzeitlich Veränderungen aus Strategiesicht ergeben haben, welche im Cloud Sourcing Design berücksichtigt werden müssen. Insbesondere muss der Cloud Business Case nun mit konkreten Werten bezüglich der Cloud Lösung und der damit verbundenen Kosten im Betriebsmodell kalkuliert werden. Die verschiedenen Faktoren sowie die Cloud-Betriebs-Szenarien sind mit dem erwarteten Business-Mehrwert abzugleichen. Dabei werden insbesondere die operativen Kosten (Op-Ex) stärker ins Gewicht fallen. Während Investitionsprojekte häufig auf gut kalkulierbaren Offert-Grundlagen berechnet wurden, müssen mit der Cloud-Lösung auf Basis von Annahmen im operativen Betrieb gerechnet werden. Hierzu empfiehlt es sich mit unterschiedlichen Szenarien zu arbeiten: ein Best-Case, Worst-Case sowie Wahrscheinlicher-Case. Bei der Bestimmung des Cloud Business Case muss auch berücksichtigt werden, dass der Wechsel in die Cloud unter Umständen eine Dualität von Infrastrukturen, Lizenzen und Applikationen beinhaltet – insbesondere, wenn die Transformation nicht konsequent und schnell genug durchgesetzt werden kann.

Cloud Sourcing LifeCycle – Part 3: Cloud Sourcing Design

Agile, Cloud, ITSM / Von

Der Cloud Sourcing LifeCycle ist ein methodischer Ansatz, die Reise in die Cloud sicher und strukturiert anzugehen, negative Überraschungen zu vermeiden und damit den Business Mehrwert zu optimieren.  Ein Übersicht des Cloud Sourcing LifeCycle sowie die Bedeutung der Cloud Sourcing Strategie wurden bereits beschrieben. In

Cloud Sourcing LifeCycle – Part 3: Cloud Sourcing Design weiterlesen »

Cloud Sourcing Strategie

Cloud Sourcing Lifecycle – Part 2: Cloud Sourcing Strategie

Agile, Architektur, Cloud, ITSM / Von

Cloud ist im Grunde nichts anderes als die industrialisierte Bereitstellung von Infrastruktur-Ressourcen und IT-Services. Doch dahinter steckt viel mehr. Cloud ist ein «Game Changer», ein Veränderer der bis anhin vertrauten Spielregeln im IT-Umfeld und damit kritisch für Unternehmen, welche im «Spiel» bleiben wollen. Im Rahmen

Cloud Sourcing Lifecycle – Part 2: Cloud Sourcing Strategie weiterlesen »