Mit Sovereign Cloud Stack zu mehr digitaler Souveränität

Corona machts möglich: Im Frühjahr 2020 rückte die Pandemie die Digitalisierung in den Vordergrund. In der Bildung, in der öffentlichen Verwaltung und in vielen Betrieben waren digitale Arbeitsmittel nicht ausreichend eta­bliert oder die vorhandenen nicht auf das geforderte sprunghafte Wachstum vorbereitet. Aber viele Unternehmen nutzten die Zeit seit dem ersten Schock und sind heute besser aufgestellt. Allerorten hat man zum Beispiel Videokonferenzen implementiert. Wo die aus cloudbasierter Infrastruktur geliefert werden, ist auch ein Skalieren, also die dynamische Anpassung an stark schwankende Bedürfnisse, Standard.

Der Preis dafür ist in vielen Fällen aber eine noch stärkere Abhängigkeit von großen Plattformanbietern. Von denen gibt es nur wenige und sie operieren auch noch in Rechtsräumen, die kulturell und rechtlich nicht den Erfordernissen des europäischen Datenschutzes genügen. Das EuGH-Urteil zum Thema Privacy Shield (siehe iX 9/2020) hat das vielen Unternehmen noch einmal schmerzlich klargemacht. Zudem sind starke Abhängigkeiten auch aus wirtschaftlicher und strategischer Sicht wenig wünschenswert.

Die Zukunft des Abendlandes

Daten und ihre Verarbeitung werden in der Industrie mehr und mehr die Basis jedes Fortschritts. Die Wettbewerbsfähigkeit ist in immer mehr Bereichen davon abhängig, wer besonders gut in der Entwicklung innovativer Software zur Verarbeitung der Daten ist und wer Zugriff und Kontrolle über die Daten hat. Gerade auch für die mittelständisch geprägte Wirtschaft in Deutschland wird sich im kommenden Jahrzehnt entscheiden, ob sie die Kon­trolle über ihr Daten behalten kann. Auch die Kompetenz zur datenbasierten Innovation droht verloren zu gehen und damit geriete letztlich auch die Fähigkeit zur Innovation in fremde Hände.

Im Privaten steht nicht weniger auf dem Spiel: Der Datenschutz ist letztlich die Freiheit, nicht bei jeder Handlung der Überwachung durch Daten sammelnde Systeme unterworfen zu sein und somit die Frage stellen zu müssen, welche Informationen über die eigene Person die Datensammler anhäufen. Das westeuropäische System mit der Freiheit des Handelns im Privaten und die Innovationsfähigkeit des Wirtschaftssystems müssen sich gegen andere Entwürfe behaupten – dem ungebremsten Datensammeln der großen Plattformanbieter (mit kaum kontrollierbarem Zugriff durch Geheimdienste) wie in den USA einerseits und dem staatlichen Überwachungsmodell Chinas andererseits. Ohne die Kontrolle über die eigenen ­Daten und die zugehörigen Systeme zur Datenverarbeitung wird das kaum zu erreichen sein. Dies ist der Kern der Diskussion über digitale Souveränität.

Auf dem Digital-Gipfel des BMWi wurde digitale Souveränität als „die ­Fähigkeit zum selbstbestimmten Handeln und Entscheiden im digitalen Raum definiert. Sie umfasst zwingend die vollständige Kontrolle über gespeicherte und verarbeitete Daten sowie die unabhängige Entscheidung darüber, wer darauf zugreifen darf. Diese umfasst auch die Fähigkeit, technologische Komponenten und Systeme eigenständig zu entwickeln, zu verändern, zu kontrollieren und durch ­andere Komponenten zu ergänzen.“

GAIA-X und Sovereign Cloud Stack

Das vom Ministerium initiierte und mittlerweile von Unternehmen, Forschungseinrichtungen und Institutionen aus Deutschland, Frankreich und anderen EU-Ländern getragene Projekt GAIA-X (siehe Artikel auf Seite 45) hat das Ziel, mittels Transparenz und Standards die Souveränität über die Daten zu bewahren oder überhaupt zu erlangen. Eine ­sichere und vernetzte Dateninfrastruktur soll den höchsten Ansprüchen an digitale Souveränität genügen und Innovationen fördern. In einem offenen und transparenten digitalen Ökosystem sollen Daten und Dienste verfügbar gemacht, zusammengeführt und vertrauensvoll geteilt werden können. Mit entsprechenden Standards wird es möglich, dass Daten und ­datenbasierte Anwendungen nicht mehr von einem einzelnen Anbieter abhängig sind. Vielmehr sollen Kunden den Anbieter wechseln und auch Anwendungen aus Bausteinen verschiedener Anbieter zusammensetzen können.

Aber Interoperabilität und Portabilität alleine sind noch kein Garant dafür, dass ein lebendiges Ökosystem von kompati­bler, moderner, agiler Infrastruktur in ­Europa entsteht (siehe Kasten „Agile ­Infrastruktur“). Zwar gibt es viele kleine und mittelgroße Anbieter sowie interne Cloud-Umgebungen in Unternehmen, die auf Open-Source-Software, typischerweise OpenStack und Kubernetes, oder proprietärer Software – häufig VMware – aufbauen. Jedoch sind diese Umgebungen nicht miteinander vernetzt und aufgrund der endlosen Anpassungsmöglichkeiten auch kaum zueinander kompatibel, der Markt ist stark fragmentiert.

Einen Standard setzen

Für Nutzer, die nach einem Ausweg aus der starken Abhängigkeit von einem der großen Cloud-Anbieter suchen, ist die Alter­native – eine ebenso starke Abhängigkeit von einem kleinen europäischen Anbieter – kein offensichtlicher Fortschritt. Kein Admin sollte sich dabei aber der Illusion hingeben, der Betrieb einer hochdynamischen verteilten Umgebung wie einer Cloud-Infrastruktur sei einfach. Gerade kleinere Anbieter tun sich schwer, ein entsprechend qualifiziertes Betriebsteam aufzubauen und die richtige Kultur und Prozesse zu entwickeln, um eine den großen Anbietern vergleichbare Qualität liefern zu können.

Sovereign Cloud Stack (SCS) will das Entstehen eines lebendigen Ökosystems aus vernetzten, föderierbaren Infrastrukturanbietern fördern, die gemeinsam in ­einem offenen Prozess die Standards, die freie Software ebenso wie die Prozesse und Werkzeuge für den Betrieb der Cloud-­Plattformen entwickeln, einem Communityprojekt von GAIA-X. Eine Föderation besteht dabei aus voneinander unabhän­gigen Netzen, die beispielsweise „nur“ eine gemeinsame Authentifizierungsmethode benutzen. Die Infrastrukturan­bieter ­umfassen dabei nicht nur klassische ­Anbieter öffentlicher Clouds, sondern können ebenso Rechenzentren für die öffentliche Hand oder unternehmensinterne IT-Abteilungen sein.

Aber auch Anwender mit sehr eingeschränkten Nutzergruppen, denen die Nutzerföderierung nicht nutzt, sollen davon profitieren, eine Standardlösung einzusetzen.

Standards, Code und Ökosystem

Das Sovereign-Cloud-Stack-Projekt (SCS) will dreierlei liefern: Standards, Software und den Aufbau eines Ökosystems. Die Zersplitterung der verschiedenen kleinen Cloud-Plattformen hat sich für die Akzeptanz am Markt als fatal erwiesen. Es fehlt eine Standardisierung, die Softwareentwicklern, Nutzern und letztlich auch ­Betreibern gegenüber sicherstellt, dass Software, Automatisierung, Wissen, Erfahrung und Testergebnisse ohne nennenswerte Anpassung und doppelte Arbeit übertragbar sind. Diese Standards zu schaffen, ist ein wichtiges Ziel von SCS.

Dabei existieren gerade im Bereich der von SCS eingesetzten Technologien viele Standards. SCS will und wird diese nicht neu erfinden oder gar ersetzen, sondern die am besten passenden auswählen, kombinieren und ergänzen, wo es Lücken gibt. Als Beispiel sei OpenStack erwähnt, dessen Trademark-Zertifizierung (DefCore) allerdings sehr viel Interpretationsspielraum lässt. So ist die Bedeutung von Verfügbarkeitszonen (VZ) dort nicht genau spezifiziert: Ist Block Storage übergreifend oder per VZ definiert? Die gleiche Frage stellt sich rund um den Begriff Netze. Was muss ein Entwickler beachten, der eine Anwendung so konzipieren will, dass sie den Tod einer VZ überlebt?

Auch in der Containerwelt finden sich ähnliche Unklarheiten: Ist die Containerorchestrierung durch Kubernetes noch genau definiert, so fehlt es doch an Standards zur Verwaltung der Kubernetes-­Cluster. Die Kubernetes Cluster API wird nicht von vielen Anwendern eingesetzt, sie gilt als unzureichend und (noch) nicht ausgereift. Und wie sind die SLAs zu ­interpretieren?

GAIA-X-Komponenten

Ob die Standards eingehalten werden, muss durch automatisierte Tests überprüfbar sein. Nutzern und Softwareentwicklern gegenüber wird das dann durch entsprechende Zertifizierung zugesichert. Neben für alle verpflichtenden Standards (vor allem im Containerbereich) wird es auch optionale Standards geben – hier können Anbieter entscheiden, ob sie entsprechende Dienste und Schnittstellen anbieten wollen. Wenn sie es tun, ist es aber zertifizierbar kompatibel machbar, was vor allem für die Schnittstellen auf IaaS-Ebene wie auch für Plattformdienste essenziell ist. Die Standards werden behutsam und rückwärtskompatibel weiterentwickelt, was Investitionen in Infrastruktur, Software und Wissen schützt.

Zweitens liefert SCS eine komplette modulare, offene Softwareumgebung. Eine lange Liste an SCS-Komponenten (siehe Abbildung 1) stellt eine auf Standard­hardware aufbauende, umfassende Cloud- und Containerinfrastruktur automatisch bereit. Zu der gehören Betriebssystem, Virtualisierung, Speichertechnik, Netzwerk, Datenbank auf Infrastrukturebene ebenso wie die IaaS-Schicht (Infrastructure as a Service), die Self-Service-Clusterverwaltung von Kubernetes-Containerinfrastruktur, ein Werkzeugkasten für die Container­nutzer zur Bereitstellung von Service Meshes, Monitoring, Speicher- und Netzwerke aus der Infrastruktur sowie eine vertrauenswürdige Container-Registry und Sicherheitsscans. Ebenso werden Werkzeuge für den Betrieb installiert, die das Testen, die Lebenszyklusverwaltung ­(Installation, Updates und Dekomissionierung), das Überwachen (Monitoring, ­Alerting, Trending), die Kapazitätsplanung und die Fehlerdiagnose unterstützen. Und ­natürlich beherrscht es die Nutzerverwaltung und Nutzerföderierung mit externen Identitätsanbietern und Partnern aus dem GAIA-X-Ökosystem.

Plattformdienste (PaaS) als Bausteine für Anwendungsentwickler sind geplant – ­Datenbanken, Frameworks für Big Data und für künstliche Intelligenz sowie Function as a Service sind hier die ersten Themen. Hier soll bewusst behutsam vorgegangen werden und nur Basisdienste, die allgemein als Standard erwartet werden (etwa ein relationaler Datenbankdienst), sollen mit in die SCS-Basis einfließen. Die Breite des Angebots kommt durch ein Ökosystem von Partnern zustande, die eigene innovative Dienste auf die Beine stellen, um sich von Konkurrenten zu unterscheiden.

Offen in Lizenz, Entwicklung, Community und Design

Jede integrierte Software muss unter­offenen Lizenzen bereitgestellt sein. Mindestanforderung ist dabei eine OSI-kompatible Lizenz. In der Cloud-Welt ist die Apache-2-­Lizenz sehr verbreitet, bei der Nutzung von Projekten ist eine offene ­Lizenz aber nicht ausreichend. SCS orientiert sich an den vier Offenheiten, die sich in der Definition der Open Infra­structure Community finden: offene Lizenzen, ­offene Entwicklung, offene Community und offenes Design. Darüber hinaus wird SCS Projekte bevorzugen, deren Reifegrad überzeugt und die aktiv weiterentwickelt oder zumindest gepflegt werden.

Auch SCS-Clouds werden Selbstbeschreibungen, wie sie GAIA-X erwartet, bereitstellen. Darüber hinaus bringt die Festlegung auf freie Software ein hohes Maß an Transparenz, was die Vertrauenswürdigkeit erhöht und die Nachvollziehbarkeit fördert. SCS wird – soweit möglich – keine Softwarekomponenten selbst entwickeln. Die Entwicklungsarbeit fließt in Automatisierung, Testabdeckung und durch aktive Mitarbeit zurück in offene Softwareprojekte, die in SCS zum Einsatz kommen.

Drittens arbeitet SCS aktiv mit den SCS-Anbietern zusammen, indem es die Kompatibilität prüft und zertifiziert, die Vernetzung herstellt und die Nutzerföderierung etabliert. Das macht es für die Endanwender möglich, ohne Technologiebruch viele Clouds föderiert, ohne große Komplexität auch in Szenarien zu nutzen, wo eine der SCS-Clouds im eigenen ­Rechenzentrum läuft. Das SCS-Projekt ist die neutrale Instanz, um eine gemeinsame Wissensbasis und Inspiration zu Betriebsthemen und modernen Prozessen aufzubauen. Sicherheitszertifizierungen erfolgen in der Regel betreiberspezifisch durch Dritte, SCS will dies durch entsprechendes Softwaredesign und dokumentierte Prozesse deutlich erleichtern und die ­Zusammenarbeit zwischen Betreibern moderieren.

Abbildung 2 zeigt das Ökosystem von SCS. Nicht alle dort erwähnten Anbieter offerieren Public Clouds; nicht alle bieten die Schnittstellen auf IaaS-Ebene an, auch die beiden optionalen PaaS-Komponenten sind nicht überall vorhanden. Die Föderierung kann über Identity-Provider erfolgen; eine Vernetzung wird vom Projekt GAIA-X Interconnection unterstützt. Die Grafik skizziert zwei beispielhafte Third-Party-SaaS-Anwendungen: Die eine nutzt ausschließlich die vorgeschriebenen SCS-Standards und läuft ­daher auf jeder zertifizierten SCS-Umgebung (3rd Party SaaS 1). Die andere nutzt ­optionale Standards – auch sie ist portabel, aber nur über eine Untermenge von SCS-Umgebungen (3rd Party SaaS 2).

Technische Umsetzung

In einem Workshop im Januar 2020 wurde die grundlegende Architektur von Sovereign Cloud Stack entwickelt, mit behutsamer Weiterentwicklung ist zu rechnen. Das SCS-Projekt nutzt den Open Source Infrastructure & Service Manager OSISM und konnte dessen Hauptentwickler ­gewinnen. So stand ein bereits bei vielen Kunden erprobtes System zur Verfügung. Konfiguration und Installation der Basisdienste, der Betriebswerkzeuge und der IaaS-Schicht ließen sich einfach automatisieren.