Souverän in die Cloud – ohne souveräne Cloud

Wo ist die souveräne Cloud?

Eine Google-Suche nach einer souveränen Cloud ergibt 70.000 Treffer. Der Versuch aber, eine souveräne Cloud nach dem Vorbild der Public Cloud zu nutzen, bleibt fruchtlos. Hier einige Beispiele:

• GaiaX: Datenräume nach dem Modell der Fraunhofer´schen “International Data Spaces” gibt es tatsächlich, der klassische Cloud-Teil von GaiaX aber ist im Scheitern begriffen.
• Microsoft: Die souveräne Cloud nach dem Modell von SAP/arvato ist angekündigt, konkrete Aussagen zum Starttermin sind der Pressemitteilungen nicht zu entnehmen.
• Google: Die Variante von T-Systems ist laut eigener Aussage funktionsfähig, eine Nutzeroberfläche wie bei Azure, AWS oder Google-Cloud aber ist nicht zu finden.
• Lidl: Unter dem Namen StackIT baut die Muttergesellschaft des Lidl-Konzerns, ebenfalls eine souveräne Cloud auf. In Messegesprächen erfährt man, dass es für die Nutzung eine Art Warteliste gibt.

Die souveränen Clouds stecken also weitestgehend in ihren Kinderschuhen oder existieren nur in Gedanken.

Mehr digitale Selbstbestimmung ist heute schon möglich

Ist also jeglicher Versuch eines Unternehmens oder einer Behörde, digital souveräner zu werden, hoffnungslos und zum Scheitern verurteilt? Die Antwort ist ein klares Nein. Im Gegensatz zur Autarkie ist Souveränität ein relativer und subjektiver Begriff.

Der Grad der digitalen Selbstbestimmung hängt davon ab, welche individuellen Souveränitätsziele eine Organisation verfolgt. Wie leistungsfähig soll das Unternehmen sein? Wie viel Kontrolle in welchen Szenarien ist nötig?

1. Souveränitätsziele kennen und priorisieren

In der Metapher gesprochen: Der Koch muss sich Gedanken machen, ob er für seine Familie in der Pandemie kocht, für sein Sterne-Restaurant an Weihnachten oder für ein Bataillon im Krieg.

Übertragen auf die IT bedeutet dies: Organisationen müssen individuell für sich definieren, in welchen Szenarien sie digital leistungsfähig bleiben wollen und welchen Grad an Kontrolle bis zu welcher Tiefe der IT-Wertschöpfung sie einfordern.

2. Wertschöpfung und Abhängigkeiten verstehen

Der o.g. Koch stellt sich nun die Frage: Wie kann ich weiter erfolgreich meine Gäste bekochen in den wichtigen Szenarien? Welche Lieferanten können auch während einer Pandemie weiterhin liefern? Wie muss ich im Kriegsfall das Menü anpassen? Welche Zutaten lassen sich auf welche Weise am Besten wie lange lagern? Welche Zutaten baue ich selbst an, welche Kochgeräte benötige ich, wie stelle ich die Stromversorgung sicher?

Analog dazu verhält es sich in der IT. Die Organisation bedarf eines detaillierten Verständnisses der Zusammenhänge in der eigenen IT-Wertschöpfung: Welche Komponenten stammen aus welchen Ländern? Welche sind besonders leistungsfähig? Welche sind einfach austauschbar? Welche Lizenzbedingungen gelten? Wie kann ich den Source-Code selbst kontrollieren und verändern? Welche Lieferanten nutzen welche Betriebsmodelle? Wo liegen die Rechenzentren, wie kann ich Daten doppelt speichern und synchron halten?

3. Wertschöpfung entsprechend der Souveränitätsziele gestalten

Die argumentativ einfachste Möglichkeit, digital souverän zu werden, ist es, alle Leistungen selbst zu erbringen - also die Autarkie. In der Realität hätte dies enorme Investitionen in eigenen Rohstoff-Abbau, Chip-Produktion, Rechenzentren, Software und Betrieb zu folge - oder einen krassen Einschnitt in die digitale Leistungsfähigkeit.

Komplexer zu erklären, aber gleichwohl wesentlich kostengünstiger, sind Veränderungen in den folgenden drei Stellhebeln:

1. Software-Architektur und Betrieb: Software-Anwendungen können in ihrer Architektur so verändert werden, dass Lieferanten einfacher ausgetauscht und Infrastrukturen schnell gewechselt werden können. Zudem können Experten Softwares so konstruieren, dass ausfallende Einzelteile nicht zu einem Ausfall der vollständigen Anwendung führen. Entsprechend der Änderungen der Software muss im Betrieb sichergestellt werden, dass diese Wechsel auch tatsächlich schnell durchgeführt werden können.
2. Organisation und Prozesse: Um das notwendige Verständnis über die Souveränitätsziele und deren Auswirkungen auf die IT-Wertschöpfung zu verstehen und zu gestalten, müssen Unternehmen ihre Aufbauorganisation und die Prozesse anpassen. Meist bedeutet dies eine deutliche Ausweitung der Software- und IT-Infrastruktur-Kompetenzen. Dies gilt insbesondere für Fachabteilungen und Management. Hilfreich ist es zudem, Prozess-Abläufe so vorauszudenken, dass das Unternehmen im laufenden Betrieb Rechenzentren oder Lieferanten auswechseln können.
3. Make-or-Buy-Mix: Schlüssel zur aktiven Steuerung der Wertschöpfung ist die Internalisierung von IT-Steuerungs-Know-how. Dazu gehören Software- und Infrastruktur-Architekten, die Eigenentwicklung von Schlüssel-Softwares sowie der Aufbau einer aktiven, kompetenzintensiven Lieferanten-Steuerung. Auch Aufbau und Betrieb von eigenen Rechenzentren für Kernanwendungen können dazu gehören.

Digitale Souveränität durch moderne IT

In der Praxis haben sich - neben der Erhöhung der Fähigkeit zur Eigenleistung - drei Best Practices herausgebildet, um Leistungsfähigkeit und Kontrolle in Summe zu steigern.

Verschlüsselungstechnologien

Die Nutzung von Verschlüsselungstechnologien bringt insbesondere an drei Stellen mehr Kontrolle:

• In Transit: Grundsätzlich werden Datenpakete zwischen Endgerät und Service im Internet als Postkarte versandt. Jeder Beteiligte auf dem Weg könnte sie kurz anhalten und lesen. Eine Verschlüsselung “in Transit” verhindert dies und erhöht damit insbesondere den Schutz vorKriminelle. Auch Regulierungsvorgaben werden damit erfüllt und Zertifizierungen werden möglich.
• At Rest: Traditionell ist auch die Speicherung der Daten im Rechenzentrum erst einmal unverschlüsselt. Mit der Verschlüsselung der Daten “at Rest” ist auch bei einem Einbruch durch Kriminelle das Lesen nicht einfach möglich. Auch die Herausgabe von Daten durch den Cloud-Provider an Behörden wird dadurch deutlich erschwert.
• Auf der CPU: Üblicherweise erfolgt die Zwischenablage von Daten im Arbeitsspeicher der CPU unverschlüsselt. Mit bestimmten CPUs wird auch dieser - nur sehr kurz erfolgende - Schritt verschlüsselt. Auf diese Weise wird die Herausgabe der Daten durch den Provider noch weiter erschwert. Auch Geheimdiensten wird dadurch der Zugriff an dieser Stelle praktisch verunmöglicht.

Zusätzlich erschwert wird jegliche Form des Zugriffs durch Varianten des Schlüsselmanagements:

• Bring-your-own-Key (BYOK): Üblicherweise nutzen Kunden zur Verschlüsselung ihrer Daten Schlüssel (“Keys”) des Cloud-Providers. Sollen die Daten aber genau vor diesem geheim gehalten werden (insb. aus Sorge vor der Herausgabe der Daten an Behörden), liegt es nahe, einen eigenen Schlüssel mitzubringen.
• Hold-your-own-Key (HYOK): Noch weiter erschwert wird der Zugriff durch den Cloud-Provider, wenn der Schlüssel auch in einem weiteren Rechenzentrum gehalten wird. Nachteilig wirken sich HYOK/BYOK allerdings auf den Leistungsumfang der genutzten Clouds aus. In der Regel können nur wenige Services von AWS, Google und Azure auf diese Weise weiter genutzt werden.

Verschlüsselungstechnologien erhöhen nicht nur den Grad an Kontrolle über die eigenen Daten, sie ermöglichen es auch Unternehmen mit hochkritischen Daten (wie etwa Banken oder Gesundheitsdienstleistern), die Angebote der Public Cloud überhaupt zu nutzen. Denn: Azure, AWS und Google ist es damit praktisch kaum möglich, Anfragen amerikanischer Behörden zur Herausgabe von Daten gemäß des Cloud ACTs nachzukommen.

Theoretisch möglich bleibt es dennoch, denn die Cloud-Anbieter könnten natürlich ihre eigenen Systeme - einem Kriminellen gleich - mit Wanzen versehen oder hacken. Daher sehen aktuell auch staatliche Organisationen von einer Nutzung der Public Cloud weitestgehend ab.

Multi-Cloud-Architektur

Software-Anwendungen können auf eine Weise umgebaut werden, dass sowohl Infrastruktur als auch Software-Services unkompliziert und schnell ausgetauscht werden können. So wird die Abhängigkeit des Unternehmens von einzelnen Anbietern, Softwares oder ganzen Ländern relevant reduziert. Hierzu gibt es unterschiedliche Wege:

• Container: Software-Anwendungen können in sogenannte “Container” verpackt und mit dessen Hilfe flexibel auf verschiedene “Schiffe” (Infrastrukturen) verladen werden. Ins Innere des Verpackung werden alle Spezifika der Anwendung (Individuelle Versionen von Runtime, Betriebssystem, Programmiersprache) gepackt, nach Aussen hin erscheint der Container vollständig austauschbar. Eine entsprechende Container-Management-Umgebung vorausgesetzt, kann die Anwendung nun auf Knopfdruck entweder bei Azure, Google, AWS oder in jeder souveränen oder Private Cloud laufen.
• API-Layer: Innerhalb einer Software können Bereiche mit Hilfe von APIs (Application Programming Interfaces) abgetrennt werden. Vorstellen kann man sich diese Software-Schnittstellen wie Mehrfach-Stromadapter wie sie Vielreisende nutzen. In die eine Richtung kann stets der deutsche DIN-Stecker genutzt werden - in die andere Richtung wird der Stecker des jeweiligen Landes eingesetzt. Eine Beispielanwendung wäre die folgende: Ein deutsches Unternehmen legt auf den virtuellen Assistenten Alexa einen solchen API-Layer. Werden die Nutzungsbedingungen von Amazon zu unattraktiv, wird Alexa im Hintergrund gegen den Google-Assistenten - oder einen zwischenzeitlich selbst programmierten - ausgetauscht. Gegenüber dem Endkunden gibt es keinerlei Änderungen, dank des API-Adapters.
• Graceful Degradation: Wörtlich übersetzt heisst dies “Würdevoller Verfall”. Eine treffendere Formulierung ist: Notbetrieb. Software-Anwendungen werden bei diesem Konzept in unterschiedliche Kritikalitäten eingeteilt. Unverzichtbare Services (Datenbank, Logik, API) werden selbst betrieben, Komfortfunktionen werden in die Public Cloud ausgelagert (Skalierende Oberfläche, Übersetzungs-Service). Auf diese Weise können auch Behörden oder kritische Infrastrukturen Services in die Public Cloud auslagern.

Open-Source-Komponenten

Open Source bedeutet, dass der Software-Code der Anwendung unter bestimmten Bedingungen offengelegt wurde und von Dritten geändert und weiterentwickelt werden darf. Die Bedingungen unterscheiden sich dabei deutlich, im Kern aber führt Open Source dazu, dass sich theoretisch Abhängigkeiten zu bestimmten Softwares und Anbietern deutlich reduzieren. Beispiele hierfür sind:

• Das quelloffene Linux-Betriebssystem kann das proprietäre Windows-Betriebssystem ersetzen. Es ist keine Geschäftsbeziehung zu Microsoft mehr notwendig, ebenso entfallen die Lizenzzahlungen. Fehlen bei Linux bestimmte Funktionen, können Unternehmen diese selbst ergänzen oder gar eine eigene Variante des Betriebssystems auf den Markt bringen.
• Kubernetes wurde von Google als Container-Management-Lösung ursprünglich proprietär entwickelt und dann als Open-Source-Anwendung veröffentlich. Durch seine außerordentliche Beliebtheit konnte es sich dann zum Standard in diesem Segment entwickeln und wird jetzt auch von AWS und Azure genutzt. Somit können Unternehmen ihre Anwendungen relativ unkompliziert zwischen den Anbietern hin- und herschieben.

In der Praxis aber gibt es auch Schattenseiten:

• Eigene Kompetenzen vorhalten: Viele Unternehmen nutzen Kubernetes auf der Google-Cloud in dem Wissen, dass es im Krisenfall den Cluster auch im eigenen Rechenzentrum betreiben könnten. Nur die wenigsten Unternehmen können dies tatsächlich auf ähnlichem Niveau, denn hierfür sind spezialisierte Fachkräfte notwendig sowie entsprechende Hardware.
• Die Fehler anderer ausbügeln: Auch Open-Source-Software enthält Fehler. Treten diese auf und verursachen Schäden, dann ist hier “die Community” verantwortlich, also eine Schar Freiwilliger aus aller Welt. So geschehen ist es im Falle von Log4j, der größten Sicherheitslücke des Jahres 2021. Dank dieser Open-Source-Software waren praktische alle Unternehmen dieser Welt mehrere Monate damit beschäftigt, die Kontrolle über ihre Daten wiederherzustellen - egal ob in der Public oder Private Cloud.

Praktisch alle Souveränitätsziele scheinen möglich

Mit entsprechendem Know-how und Investitionen in gezielte Eigenleistung sind praktisch alle Souveränitätsziele auch heute schon erreichbar. Mit modernen Verschlüsselungstechnologien können die amerikanischen Hyperscaler genutzt und trotzdem Zugriffe unbefugter Dritter pragmatiscg vermieden werden. Mit Multi-Cloud-Architekturen werden Abhängigkeiten zu einzelnen Anbietern und Softwares reduziert. Open Source-Komponenten können sogar die Abhängigkeit von bestimmten Ländern reduzieren.

Lediglich nicht auszuschließen sind Geheimdienste sowie die eigenen Behörden. Aber beides ist Stoff für viele weiteren Artikel in diesem Blog.

Slideshow - dieser Artikel zum Durchklicken