Hier finden Sie die aktualisierte Version der Marktübersicht: Marktübersicht 2023 |
Im Jahr 2020 präsentierte der damalige Wirtschaftsminister Peter Altmaier die Idee der "Europa-Cloud" GaiaX als Schlüssel zur Datensouveränität. Im Jahr 2021 forderten die CIOs der deutschen Bundesländer eine Multi-Cloud-Strategie zur Stärkung der digitalen Souveränität in der IT. Dieses Jahr verkündete die deutsche Telekom die Verfügbarkeit ihrer souveränen Cloud basierend auf Google-Technologie. Aber reden wirklich alle über das Gleiche?
Die folgende Übersicht zeigt die heute bekannten Ansätze zur souveränen Cloud in Deutschland:
Wie unterscheiden sich die Ansätze zu souveränen Clouds?
Private Cloud - der Klassiker
Bei der Private Cloud handelt es sich um die Modernisierung des klassischen Rechenzentrums. Ein Unternehmen investiert in eigene Hardware (Netzwerk, Speicher, Rechenleistung). Darauf betreibt es alle notwendigen IT-Services wie Virtualisierung, Betriebssysteme, Datenbanken und Monitoring sowie Software, welche die Bestell-, Liefer- und Abrechnungsprozesse automatisiert abwickelt. In den meisten Fällen werden für diese IT-Services die Softwares amerikanischer Hersteller wie VMWare, Microsoft, Oracle oder ServiceNow eingesetzt. Mit mehr Know-how und Aufmerksamkeit können Unternehmen viele der außereuropäischen Software durch Open-Source-Alternativen ersetzen.
- Vorteile: Das Unternehmen hat alle Details des Rechenzentrums, des Betriebs und der Integration der Services unter Kontrolle. Es kann bei Bedarf dort individuelle Veränderungen vornehmen und die meisten Datenflüsse selbst steuern.
- Nachteile: Das Unternehmen muss jedes Element seiner Private Cloud selbst aufbauen und betreiben. Dies erfordert hohe Investitionen und hohe laufende Kosten. Selbst große Unternehmen mit hohen IT-Budgets können daher kaum mit der Leistungsfähigkeit der Public Cloud mithalten.
Eine weitere Fußnote: Auch die Private Cloud ist angewiesen auf regelmäßige Updates der genutzten Software amerikanischer Hersteller. Ein dauerhafter Verzicht auf neue Softwarestände bedeutet Einbußen bei IT-Sicherheit und Funktionalität.
Beispiele für dieses Modell sind die deutsche Bundescloud, die deutsche Verwaltungscloud sowie dPhoenix.
Europäische Clouds - eher Superscaler als Hyperscaler?
Europäische Clouds unterscheiden sich von Private Clouds im Wesentlichen durch ihren Fokus auf externe Kunden. Damit eine potentiell unbegrenzte Anzahl von Kunden die Cloud nutzen können, bedarf es einer guten Nutzeroberfläche (GUI) sowie gut funktionierender Bestell-, Liefer- und Abrechnungsprozesse. Bei den angebotenen IT-Services (z.B. Datenbanken, Virtuelle Maschinen, Container-Services) müssen die Cloud-Betreiber jeweils entscheiden: nutzen wir proprietäre Softwares amerikanischer Anbieter (z.B. VMWare zur Virtualisierung) und profitieren von deren Leistungsumfang und Updates oder arbeiten wir uns aufwändig in Open-Source-Software ein mit den Vorteilen der Unabhängigkeit und Gestaltungsfreiheit.
- Vorteil: Der europäische Cloud-Betreiber hat ein hohes Maß an Kontrolle über die Details des Rechenzentrums, des Betriebs und der Integration der Services. Investitions- und Betriebskosten verteilen sich auf mehr Kunden, es entsteht finanzieller Spielraum für Investitionen in eine höhere Leistungsfähigkeit.
- Nachteil: Der Cloud-Betreiber trägt weiterhin die hohen Investitionen und laufenden Kosten für Aufbau und Betrieb der Cloud. Die europäischen Clouds sind für die Breite der Anwendungen denn auch weitaus weniger leistungsfähig als die amerikanischen Hyperscaler.
Auch hier eine Fußnote: Auch den europäischen "Superscalern" wird es schwerfallen, auf jegliche Abhängigkeit von amerikanischen Lieferanten zu verzichten. Zwar können die Betreiber mit entsprechendem Mehraufwand viele IT-Services durch Open-Source-Software ersetzen, aber auch Basiskomponenten wie Speichersysteme und Chips sind meist auf Support aus den USA angewiesen.
Beispiele für dieses Modell sind die OVHCloud, IONOS und StackIT.
Treuhänder mit eigenem Rechenzentrum - die ideale Kopie
In diesem Modell wird die komplette Technologie eines amerikanischen Cloud-Anbieters einschließlich aller IT-Services und Lieferprozesse in das Rechenzentrum des europäischen Datentreuhänders kopiert. Der europäische Cloud-Betreiber besitzt und betreibt lediglich das Rechenzentrum, sichert die Zugänge ab und kontrolliert die Software-Updates.
- Vorteile: Diese Cloud bietet von Beginn an einen großen Leistungsumfang. Dieser unterscheidet sich nur wenig vom amerikanischen Original und bietet den IT-Experten die aus der Public Cloud bekannte Nutzererfahrung.
- Nachteile: Der europäische Cloud-Anbieter kann zwar die Updates sowie den operativen Betrieb des Technologie gesamthaft kontrollieren, hat aber keinen Einfluss die Details der Systemintegration oder die Ausprägung der Leistungen.
Die Fußnote hier: Auch hier gibt es eine starke Abhängigkeit von einem amerikanischen Technologie-Lieferanten. Statt, wie heute üblich, auf verschiedene US-Unternehmen zu setzen und diese selbst zu integrieren sind europäische Unternehmen und Behörden in diesem Modell von einer bereits integrierten Gesamt-Technologie abhängig.
Ein Beispiel für dieses Modell ist die Delos-Cloud. Dort fungieren SAP und Arvato als Betreiber und Datentreuhänder und nutzen dafür Microsoft-Technologie.
Treuhänder mit eigenem Schlüssel - der europäische Portier
Diese Variante nutzt direkt die Public Cloud eines Hyperscalers, der europäische Treuhänder allerdings hält die Schlüssel und kontrolliert die Verschlüsselungstechnologien. Auf diese Weise entgeht das US-amerikanische Unternehmen erfolgreich dem CLOUDAct: Es hat keine Möglichkeit, die Daten zu entschlüsseln und den US-Behörden zu übergeben.
- Vorteile: Diese Cloud kann ebenfalls einen großen Leistungsumfang bieten und ist insbesondere mit wenigen Änderungen am Schlüsselmanagement auf Basis der normalen Public Cloud aufzubauen. Zudem bietet sie den IT-Experten die aus der Public Cloud bekannte Nutzererfahrung.
- Nachteile: Der europäische Cloud-Anbieter hat auch hier keinen Einfluss auf die Details der Systemintegration oder die Ausprägung der Leistungen. Zudem schränkt externes Schlüsselmanagement den Leistungsumfang von Public Cloud meist etwas ein.
Die Fußnote hier: Wie beim klassischen Rechenzentrum, bei der Private Cloud und der Public Cloud auch, die IT-Wertschöpfungskette bleibt im Kern amerikanisch.
Ein Beispiel für dieses Modell ist die souveräne Cloud der T-Systems, basierend auf der Technologie von Google.
Public Cloud mit Spezialkomponenten - European Special Service
Diese Variante basiert vollständig auf den außereuropäischen Public Clouds. Innerhalb dieser werden besondere Mechanismen eingeführt, welche die Verschlüsselungstiefe erhöhen. Praktisch geben die Hyperscaler ihren Kunden Tools an die Hand, deren Daten vor ihnen (und damit den US-Behörden) selbst zu schützen. Anwendungsunternehmen können etwa ihren eigenen Schlüssel mitbringen (BYOK: Bring-your-own-key) und diesen selbst an anderer Stelle lagern (HYOK: Hold-your-own-key). Auch gibt es spezielle Chips, welche die im Arbeitsspeicher zwischengelagerten Daten verschlüsseln (Confidential Computing).
- Vorteile: Diese Cloud setzt auf den bekannten Public Clouds auf und bietet die dort beliebte Nutzererfahrung. Die Anwendungsunternehmen können ihre IT-Landschaft in der Public Cloud belassen und nur für besonders kritische Anwendungen auf die Spezialkomponenten zurückgreifen.
- Nachteile: Die speziellen Verschlüsselungsverfahren sind nur für einen kleinen Teil der Services der Public Cloud nutzbar. Zudem gibt es praktisch keine Kontrolle über die IT-Wertschöpfung und den Betrieb.
Beispiele für dieses Modell sind BYOK/HYOK bei allen drei großen Public Clouds, Confidential Computing bei Google und Azure sowie Nitro bei AWS.
Public Cloud - der Leistungs-Benchmark
Die Vorteile der Public Cloud liegen in ihrer Portfoliobreite, ihrer Skalierbarkeit, ihrer einfachen Nutzbarkeit und ihren niedrigen finanziellen Einstiegshürden. Sie bietet standardmäßig die Option, die Daten während der Übertragung von Endgerät zur Cloud ("in transit") zu verschlüsseln sowie beim Speichern in der Public Cloud ("in rest"). Der Haken: Standardmäßig werden dafür die Verschlüsselungstools der gleichen Cloud genutzt, die Schlüssel werden ebenfalls dort gelagert. Dem Hyperscaler wäre es somit grundsätzlich möglich, alle eigenen Sicherheitsmechanismen zu umgehen ("hacken") und an die Daten zu gelangen. Alternativ könnte er versuchen, die Daten bei deren Verarbeitung auf dem Chip abzugreifen, denn dieser speichert in der Regel unverschlüsselt auf dem Arbeitsspeicher zwischen. Laut einhelliger Aussage aller Vertreter der Public Cloud, erfolgt dieses "selbst-hacken" natürlich nicht. Auf Anfrage würden sie sie den US-Behörden nur die verschlüsselten Daten ausliefern.
- Vorteile: Diese Clouds haben den mit Abstand größten Leistungsumfang, die beste Nutzererfahrung und die niedrigsten Einstiegshürden.
- Nachteile: Anwendungsunternahmen haben keinerlei Kontrolle über die IT-Wertschöpfung und den Betrieb. Zudem können sie die Aussagen der Cloud-Provider bezüglich der Standard-Verschlüsselungsmechanismen sowie ihren Umgang mit dem CLOUDAct nicht kontrollieren.
Beispiele für diese Clouds sind: AWS von Amazon, Azure von Microsoft und GCP von Google.
Und die anderen souveränen Ansätze?
In den hier genannten Varianten fehlen bisher folgende Ansätze, welche auf dem Markt zu finden sind:
- ATOS OneCloud Sovereign Shield
- GaiaX Infrastruktur und Datenräume
- OwnCloud und NextCloud
- Oracle Sovereign Cloud
- Sovereign Cloud Stack
Alle diese Varianten verfolgen Ansätze, die nicht in das hier genutzte Basisschema passen. Sie werden daher in Teil 2 ausgeführt.
Fazit - Der Trade-off aus Kontrolle und Leistungsfähigkeit
In dem geschilderten Spektrum von Private Cloud über europäische Clouds, Treuhandmodelle bis zur Public Cloud lässt sich eine Daumenregel erkennen: Mehr Kontrolle durch einen hohen Grad europäischer Wertschöpfung wird erkauft mit einem Verzicht auf Leistungsfähigkeit, also Skalierbarkeit, Portfoliobreite, Einfachheit der Nutzung und niedrige Einstiegskosten.
In der Übersicht ergibt sich dann für Mitte 2022 das folgende Spektrum: