Deutschlands Geheimnisse in Googles Cloud: Wie un-souverän ist die geplante ND-Cloud?

Offline, aber abhängig? Der heikle Preis von Googles Technologie für Deutschlands Nachrichtendienste

Googles Cloud für deutsche Geheimdienste: Was passiert, wenn der Anbieter ausfällt?

Eine vom Internet getrennte Cloud kann geheime Informationen wirksam abschirmen – und dennoch eine langfristige Abhängigkeit von ihrem Technologieanbieter schaffen. Genau in diesem Spannungsfeld steht die geplante ND-Cloud für Bundesnachrichtendienst, Bundesamt für Verfassungsschutz und Militärischen Abschirmdienst. Sie soll den sicheren Austausch hochsensibler Informationen ermöglichen und zugleich ohne direkte Verbindung zum öffentlichen Internet betrieben werden. Doch ein sogenannter Air Gap beantwortet nicht alle Fragen: Wer kann die Plattform über Jahre warten, aktualisieren und weiterentwickeln? Und welche Möglichkeiten bleiben dem Staat, wenn sich die technischen oder politischen Rahmenbedingungen ändern?

Bei einem Vorhaben mit einer öffentlich genannten Größenordnung von mindestens 500 Millionen Euro geht es deshalb um mehr als Serverstandorte und Sicherheitsvorkehrungen. Entscheidend ist, ob Deutschland die Plattform langfristig beherrschen und im Bedarfsfall wechseln kann. Dafür müssen neben dem Schutz der Daten auch Softwareversorgung, Fachwissen, Wechselkosten und mögliche Alternativen in den Blick genommen werden. Die geplante Cloud kann einen wichtigen Modernisierungsschritt darstellen – doch echte digitale Souveränität zeigt sich erst, wenn der Staat nicht nur den laufenden Betrieb kontrolliert, sondern auch tragfähige Optionen für die Zukunft hat.

Passend dazu:

• Bundeswehr-Deal mit Google: Wie viel Souveränität gibt Deutschland für die Google-Cloud wirklich auf?

Deutschlands Geheimnisse, Googles Technologie: Der Preis digitaler Souveränität

Offline ist noch lange nicht unabhängig

Eine vom Internet getrennte Cloud kann geheime Informationen wirksam abschirmen und dennoch eine langfristige Abhängigkeit von ihrem Technologiehersteller erzeugen. Genau in diesem Spannungsfeld liegt die geplante gemeinsame Datenplattform von Bundesnachrichtendienst, Bundesamt für Verfassungsschutz und Militärischem Abschirmdienst: Die vorgesehene technische Isolation beantwortet die Frage nach dem äußeren Netzzugang, aber noch nicht die nach dauerhafter technologischer Handlungsfreiheit.

Die ökonomisch entscheidende Frage lautet deshalb nicht, ob ein amerikanisches oder europäisches Firmenlogo auf der Plattform steht. Entscheidend ist, wer über ihren Lebenszyklus die Bedingungen für Weiterentwicklung, Fehlerbehebung, Betrieb und einen möglichen Wechsel bestimmt. Eine überzeugende Souveränitätsstrategie muss Leistungsfähigkeit, Sicherheitsanforderungen und langfristige Wahlfreiheit miteinander verbinden, statt nur den Standort der Server zu betrachten.

Eine Datenplattform mit strategischer Tragweite

Nach dem öffentlich bekannten Planungsstand vom 28. Oktober 2026 soll die sogenannte ND-Cloud den elektronischen Austausch von Informationen bis zum Geheimhaltungsgrad GEHEIM zwischen den drei Nachrichtendiensten des Bundes ermöglichen; später könnten auch die Verfassungsschutzbehörden der Länder hinzukommen. Als technische Grundlage ist offenbar Google Distributed Cloud in einer abgeschotteten Ausführung vorgesehen, wobei die Informationen in Deutschland gespeichert werden sollen und Google keinen unmittelbaren Datenzugriff erhalten soll.

Damit geht es nicht um die Ablage staatlicher Geheimnisse in einem gewöhnlichen Internetdienst. Vorgesehen ist vielmehr eine gesonderte Infrastruktur, die ohne direkte Verbindung zum öffentlichen Internet und zur allgemeinen Google-Cloud betrieben werden kann. Diese Unterscheidung ist wesentlich, weil sie das Bedrohungsbild verändert: Ein technisch isolierter, national betriebener Verbund ist anders zu bewerten als ein von außen administrierter Standard-Clouddienst.

Die öffentlich genannte Größenordnung liegt bei mindestens 500 Millionen Euro; dabei handelt es sich um eine Schätzung und nicht um eine vollständig veröffentlichte Gesamtkostenrechnung. Ein ursprünglich für das erste Quartal 2027 vorgesehener Start dürfte sich verschieben, während zentrale Einzelheiten zu Architektur, Leistungsumfang und laufenden Kosten nicht öffentlich vorliegen. Aus dieser Datenlage lässt sich weder eine belastbare Rendite berechnen noch seriös behaupten, eine bestimmte Alternative wäre um einen festen Prozentsatz günstiger.

Schon die Größenordnung zeigt jedoch, dass die Plattform mehr als ein gewöhnliches IT-System wäre. Sie würde Arbeitsabläufe, Datenmodelle und Qualifikationen über Jahre prägen. Je stärker Behörden ihre Fachverfahren auf gemeinsame technische Dienste zuschneiden, desto mehr wächst die strategische Bedeutung jener Entscheidungen, die anfangs wie reine Infrastrukturfragen erscheinen.

Warum gemeinsame Infrastruktur wirtschaftlich sinnvoll sein kann

Der Modernisierungsbedarf ist grundsätzlich plausibel: Der Austausch höher eingestufter Informationen zwischen abgeschirmten Behördensystemen ist bislang aufwendig, während Speicherbedarf und Anforderungen an die automatisierte Auswertung wachsen. Eine gemeinsame Plattform kann Übertragungen vereinfachen, standardisierte Werkzeuge bereitstellen und die Zusammenarbeit beschleunigen, sofern Berechtigungen und Zuständigkeiten sauber ausgestaltet sind.

Aus ökonomischer Sicht entstehen mögliche Vorteile durch Skaleneffekte. Werden Rechenleistung, Datensicherung, Überwachung und Sicherheitsprozesse gemeinsam bereitgestellt, müssen nicht alle Behörden dieselben Fähigkeiten parallel aufbauen. Das kann die Auslastung verbessern und knappe Fachkräfte entlasten; die BWI beschreibt standardisierte und automatisierte Cloud-Infrastruktur entsprechend als Mittel für flexiblere und effizientere IT-Leistungen.

Hinzu kommt der Nutzen schnellerer Informationsverarbeitung. Eine leistungsfähige technische Umgebung kann verhindern, dass vorhandene Erkenntnisse wegen umständlicher Abläufe zu spät verfügbar werden. Dieser Nutzen ist bei Nachrichtendiensten schwer in Euro auszudrücken, aber deshalb nicht wirtschaftlich bedeutungslos. Allerdings darf ein plausibler Sicherheitsgewinn nicht als beliebig dehnbares Argument dienen, mit dem jede technische Abhängigkeit nachträglich gerechtfertigt wird.

Der richtige Vergleich lautet deshalb nicht moderne Cloud gegen eine risikofreie bestehende Infrastruktur. Auch fragmentierte Altsysteme verursachen Kosten und Sicherheitsrisiken, etwa durch aufwendige Wartung und manuelle Abläufe. Eine sachgerechte Bewertung muss die Risiken des Umstiegs ebenso berücksichtigen wie die Kosten des Nichtstuns; der Modernisierungsbedarf allein beweist aber noch nicht, dass jede dafür angebotene Plattform langfristig wirtschaftlich ist.

Der Luftspalt löst nur einen Teil des Problems

Der Ausdruck Air Gap bezeichnet hier eine Trennung vom öffentlichen Internet und von anderen externen Netzen, nicht zwingend die vollständige Isolation jedes einzelnen Rechners voneinander. Innerhalb eines geschützten behördlichen Netzverbunds können Systeme weiterhin zusammenarbeiten, während nach außen strenge Grenzen bestehen. Google beschreibt die Plattform ausdrücklich als dauerhaft ohne Verbindung zur öffentlichen Google-Cloud betreibbar.

Diese Eigenschaft ist ein erheblicher Sicherheitsvorteil und sollte nicht kleingeredet werden. Fehlende externe Verbindungen begrenzen bestimmte Angriffswege und schaffen bessere Voraussetzungen für einen kontrollierten Betrieb. Daraus folgt jedoch nicht, dass die Plattform ohne weitere Leistungen des Herstellers über beliebig lange Zeit sicher gepflegt oder funktional erweitert werden könnte; technische Netzunabhängigkeit und Unabhängigkeit der Softwareversorgung sind unterschiedliche Eigenschaften.

Anschaulich lässt sich das mit einer Produktionsanlage vergleichen, die vollständig auf einem deutschen Werksgelände steht. Der Standort schützt die räumliche Kontrolle, beantwortet aber nicht, ob Ersatzteile, Steuerungssoftware und Spezialwissen jederzeit verfügbar bleiben. Wer die Anlage selbst bedient, muss sie deshalb noch lange nicht eigenständig weiterentwickeln können. Bei einer hochkomplexen Cloud gilt dieselbe wirtschaftliche Logik.

Souveränität ist deshalb kein einzelner Schalter. Datenhoheit, administrative Kontrolle, rechtliche Sicherheit, Transparenz der Lieferkette und technologische Änderungsfähigkeit müssen getrennt betrachtet werden. Eine Plattform kann in einigen dieser Dimensionen starke Eigenschaften haben und in anderen erhebliche Abhängigkeiten aufweisen; gerade diese Differenzierung macht eine fundierte Bewertung erst möglich.

Updates als Schnittstelle wirtschaftlicher Macht

Die Sicherheitsdokumentation von Google beschreibt einen kontrollierten Aktualisierungsprozess: Der Hersteller signiert Softwarepakete, der Infrastrukturbetreiber prüft sie und bringt sie anschließend in die abgeschottete Umgebung ein. Der Prozess umfasst nicht nur die Cloudsoftware, sondern auch Betriebssysteme, Firmware und weitere sicherheitsrelevante Komponenten. Eine automatische Internetverbindung ist dafür nicht erforderlich, die laufende technische Lieferbeziehung bleibt jedoch bestehen.

Das ist zunächst ein normaler Bestandteil professionellen Softwarebetriebs und kein Beleg für ein Fehlverhalten des Herstellers. Problematisch wird die Konstellation dort, wo nur ein Anbieter zeitnah verlässliche Aktualisierungen bereitstellen kann. Dann hängt die praktische Sicherheit des Systems nicht allein vom nationalen Betreiber ab, sondern auch von einer externen Entwicklungsorganisation und deren rechtlichen und wirtschaftlichen Rahmenbedingungen.

Wie weit solche Abhängigkeiten reichen können, zeigen die öffentlich zugänglichen Standardbedingungen für Google Distributed Cloud air-gapped. Dort ist grundsätzlich vorgesehen, neue Versionen innerhalb von 30 Tagen nach entsprechender Mitteilung zu installieren; außerdem enthalten sie Regeln zur Beendigung von Wartung sowie zum Ende der Softwarenutzung nach Ablauf der Nutzungsdauer. Diese allgemeinen Bedingungen dürfen allerdings nicht mit unbekannten Sonderregelungen der geplanten Nachrichtendienstplattform gleichgesetzt werden.

Gerade diese Abgrenzung ist wichtig. Öffentlich lässt sich nicht belegen, welche individuellen Fortbetriebsrechte, Prüfzeiträume oder zusätzlichen Sicherungen für die ND-Cloud vorgesehen sind. Ebenso wäre es unbegründet, aus einer fortbestehenden Updateabhängigkeit unmittelbar auf einen geheimen Fernzugriff oder einen technischen Abschaltmechanismus zu schließen. Belegt ist die fortdauernde Herstellerrolle bei der Softwareversorgung, nicht ein beliebig nutzbarer äußerer Zugriff.

Der gefährliche Unterschied zwischen Laufzeit und Sicherheit

Bei einem Ausfall der Herstellerunterstützung sind mehrere Situationen auseinanderzuhalten. Ein bereits installiertes System kann technisch zunächst weiterlaufen, während neu entdeckte Sicherheitslücken nicht mehr geschlossen werden. Zugleich können Nutzungsrechte, Ersatzteilversorgung oder Unterstützung für abhängige Anwendungen betroffen sein. Die Frage, wie lange die Rechner noch eingeschaltet bleiben, ist deshalb weniger aussagekräftig als die Frage, wie lange ein verantwortbarer Betrieb möglich wäre.

Eine feste allgemeine Überlebensdauer lässt sich daraus nicht ableiten. Sie hinge unter anderem von vorhandenen Schwachstellen, lokalen Reparaturmöglichkeiten, eingesetzten Zusatzdiensten und der Verfügbarkeit geeigneter Fachkräfte ab. Pauschale Aussagen, eine isolierte Cloud sei nach einer bestimmten Zahl von Monaten zwangsläufig unbrauchbar, wären ebenso unpräzise wie die Behauptung unbegrenzter Unabhängigkeit.

Ökonomisch entsteht hier ein Optionsproblem: Ein Staat benötigt nicht nur die aktuelle Funktionsfähigkeit, sondern die Möglichkeit, bei veränderten Umständen zu handeln. Diese Option hat einen Wert, auch wenn sie jahrelang nicht genutzt wird. Ihre Finanzierung ähnelt einer Versicherung gegen einen seltenen, aber potenziell sehr teuren Verlust technischer Entscheidungsfreiheit.

Eine belastbare Notfallplanung müsste daher zwischen eingeschränktem Weiterbetrieb, vollständiger Wiederherstellung und Übergang auf eine andere Plattform unterscheiden. Für jeden dieser Fälle wären eigene Voraussetzungen zu prüfen. Eine bloße Sicherungskopie der Daten hilft beispielsweise nur begrenzt, wenn die Programme fehlen, mit denen die Informationen sinnvoll verarbeitet und die jeweiligen Zugriffsregeln umgesetzt werden.

Abhängigkeit wächst mit jedem Fachverfahren

Der häufig verwendete Begriff Lock-in beschreibt eine Situation, in der ein Wechsel zwar theoretisch möglich bleibt, praktisch aber immer aufwendiger wird. Bei Cloudsystemen entsteht diese Bindung durch das Zusammenspiel von Plattformfunktionen, Schnittstellen, Datenstrukturen und eingespielten Betriebsabläufen. Je mehr Fachanwendungen spezifische Dienste eines Herstellers voraussetzen, desto größer wird der Aufwand, gleichwertige Funktionen anderswo wiederherzustellen.

Dabei ist nicht jeder Einsatz proprietärer Technik unwirtschaftlich. Ein spezialisiertes Werkzeug kann einen erheblichen Produktivitätsvorteil bieten. Die Schwierigkeit besteht darin, dass der kurzfristige Nutzen häufig gut sichtbar ist, während spätere Wechselkosten ungewiss bleiben. Dadurch droht eine systematische Schieflage: Der aktuelle Komfort wird vollständig berücksichtigt, die künftige Abhängigkeit dagegen nur abstrakt erwähnt.

Besonders relevant ist die Bindung auf der Anwendungsebene. Eine virtuelle Maschine lässt sich unter Umständen vergleichsweise leicht übertragen, ein komplexes Fachverfahren mit herstellerspezifischen Datenbank-, Identitäts- und Analysediensten dagegen nicht. Dass eine Plattform Container unterstützt, genügt daher nicht als Nachweis ihrer Austauschbarkeit. Entscheidend ist, ob die gesamte fachliche Funktion mit vertretbarem Aufwand auf einer anderen Umgebung bereitgestellt werden kann.

Eine konsequente Architektur müsste den Nutzen besonderer Plattformdienste gegen die dadurch entstehenden Wechselhindernisse abwägen. Das Ziel wäre keine vollständige technische Gleichförmigkeit, sondern bewusste Differenzierung: Standardisierte Basisfunktionen sollten möglichst austauschbar bleiben, während unverzichtbare Spezialfunktionen gesondert auf ihren Mehrwert und ihre Abhängigkeiten geprüft werden.

Europas Marktproblem beginnt bei der Größenordnung

Die strukturelle Herausforderung reicht weit über deutsche Nachrichtendienste hinaus. Der europäische Markt für Cloud-Infrastrukturdienste erreichte 2024 ein Volumen von rund 61 Milliarden Euro und war damit etwa sechsmal so groß wie 2017; erfasst sind dabei Infrastruktur- und Plattformdienste sowie gehostete private Clouds, nicht der gesamte Softwaremarkt. Europäische Anbieter konnten ihre entsprechenden regionalen Umsätze in diesem Zeitraum mehr als verdreifachen, verloren aber dennoch relativ an Gewicht.

Ihr gemeinsamer Anteil sank von 29 Prozent im Jahr 2017 auf ungefähr 15 Prozent im Jahr 2022 und blieb anschließend etwa auf diesem Niveau; Amazon, Microsoft und Google kamen in der Mitte 2025 veröffentlichten Marktaufnahme zusammen auf rund 70 Prozent. Diese Zahlen beziehen sich auf den europäischen Markt und dürfen weder mit einem ausschließlich auf die EU begrenzten Markt noch mit dem speziellen Segment abgeschotteter Geheimdienstsysteme gleichgesetzt werden.

Die Entwicklung zeigt, warum Umsatzwachstum allein keine technologische Unabhängigkeit garantiert. Europäische Unternehmen können erfolgreicher werden und gleichzeitig gegenüber den größten Plattformen zurückfallen. Die führenden Anbieter verteilen Entwicklungskosten und Investitionen auf sehr große Kundenbestände; im europäischen Infrastrukturmarkt spielen Skalierung und langfristig finanzierte Investitionen entsprechend eine zentrale Rolle.

Eine realistische europäische Strategie müsste deshalb nicht jede Funktion der größten Hyperscaler kopieren. Plausibler wäre, für besonders kritische Anwendungsfelder belastbare Alternativen aufzubauen und verbreitete technische Grundlagen gemeinsam weiterzuentwickeln. Ein sicherheitsorientierter Spezialmarkt kann andere Erfolgsbedingungen haben als das Massengeschäft mit standardisierten Rechenleistungen. Aus der allgemeinen Marktführerschaft eines Konzerns folgt nicht automatisch seine Überlegenheit für jeden staatlichen Anwendungsfall.

Der Staat als Motor technischer Lernkurven

Wenn viele öffentliche Einrichtungen ähnliche Anforderungen an Datensouveränität und sichere Zusammenarbeit haben, können gemeinsame Standards einen größeren, verlässlicheren Markt entstehen lassen. Unternehmen erhalten dann bessere Voraussetzungen, um in Dokumentation, Sicherheitsprüfungen und professionellen Betrieb zu investieren. Das openDesk-Ökosystem mit mehreren Software- und Betriebspartnern zeigt, dass ein solcher kooperativer Ansatz bereits praktisch verfolgt wird.

Darin liegt ein wirtschaftspolitisches Argument für die gezielte Nutzung geeigneter europäischer Lösungen. Ihr Nutzen erschöpft sich nicht im jeweiligen Arbeitsplatz, sondern kann sich auf spätere Anwendungen und andere Einrichtungen übertragen. Wiederverwendbare Komponenten, qualifizierte Fachkräfte und erprobte Betriebsmodelle senken potenziell die Einstiegskosten weiterer Nutzer. Diese zusätzlichen Effekte werden in einer isolierten Betrachtung der ersten Einführung leicht unterschätzt.

Gleichzeitig darf daraus kein Anspruch auf dauerhafte Schonung entstehen. Auch europäische Anbieter müssen Leistungsfähigkeit, Zuverlässigkeit und wirtschaftliche Tragfähigkeit nachweisen. Eine Politik, die jede lokale Lösung unabhängig von ihrer Qualität schützt, könnte hohe Kosten und neue Abhängigkeiten erzeugen. Entscheidend ist nicht die Abschaffung von Wettbewerb, sondern die Schaffung tatsächlicher technischer und wirtschaftlicher Ausweichmöglichkeiten.

Dabei muss auch verhindert werden, dass an die Stelle eines internationalen Monopols ein kaum überprüfbares nationales Abhängigkeitsverhältnis tritt. Offene Schnittstellen, übertragbares Betriebswissen und mehrere qualifizierte Dienstleister sind deshalb ebenso wichtig wie der Unternehmenssitz. Souveränität sollte am Ende die Handlungsfähigkeit des Anwenders vergrößern und nicht nur die Herkunft seines wichtigsten Lieferanten verändern.

Der Hub für Sicherheit und Verteidigung bietet fundierte Beratung und aktuelle Informationen, um Unternehmen und Organisationen effektiv dabei zu unterstützen, ihre Rolle in der europäischen Sicherheits- und Verteidigungspolitik zu stärken. In enger Verbindung zur Working Group Defence der SME Connect fördert er insbesondere kleine und mittlere Unternehmen (KMU), die ihre Innovationskraft und Wettbewerbsfähigkeit im Bereich Verteidigung weiter ausbauen möchten. Als zentraler Anlaufpunkt schafft der Hub so eine entscheidende Brücke zwischen KMU und europäischer Verteidigungsstrategie.

Passend dazu:

• Die Working Group Defence der SME Connect – Stärkung der KMU in der europäischen Verteidigung

openDesk ist relevant, aber kein Komplettcloud-Ersatz

Die Büro- und Kollaborationssuite openDesk wurde im Oktober 2024 eingeführt und war im Oktober 2026 nach Angaben des zuständigen Zentrums für Digitale Souveränität an rund 100.000 Verwaltungsarbeitsplätzen ausgestattet. Diese Zahl bezeichnet die ausgewiesene Verbreitung, nicht den Nachweis von 100.000 täglich aktiven Nutzern oder einer entsprechenden Zahl hochgeheimer Arbeitsplätze. Sie zeigt dennoch, dass europäische Open-Source-Zusammenarbeit längst über kleine Demonstrationsprojekte hinausgeht.

Technisch muss der Vergleich präzise bleiben. openDesk bündelt Anwendungen für Büroarbeit und Zusammenarbeit, während Google Distributed Cloud eine wesentlich breiter angelegte Infrastruktur- und Dienstplattform ist. Eine Kollaborationssuite ersetzt nicht automatisch Speicherarchitektur, Datenbanken, Rechenressourcen und Spezialdienste einer gesamten Nachrichtendienstumgebung. Wer beide Angebote als unmittelbar austauschbare Komplettlösungen darstellt, verwechselt unterschiedliche technische Ebenen.

Gleichwohl ist openDesk für die Debatte wichtig, weil nicht jede alltägliche Zusammenarbeit eine durchgehend proprietäre Plattform voraussetzen muss. Wo Behörden gemeinsam Dokumente bearbeiten, Projekte koordinieren oder kommunizieren, können offene Anwendungen konkrete Alternativen schaffen. Dadurch lässt sich zumindest ein Teil der Bindung verringern, selbst wenn darunter weiterhin verschiedene Infrastrukturen eingesetzt werden.

Im Oktober 2026 wurde zudem der Betrieb von openDesk in vollständig abgeschotteten Umgebungen demonstriert beziehungsweise erprobt; parallel stand die Absicherung für VS-NUR FÜR DEN DIENSTGEBRAUCH im Fokus. Daraus darf keine bereits nachgewiesene Einsatzreife für jede Verarbeitung bis GEHEIM abgeleitet werden, denn diese Einstufungen sind klar zu unterscheiden. Eine funktionierende Offline-Vorführung ist ein wichtiger technischer Schritt, aber kein pauschaler Nachweis für sämtliche hochsensiblen Einsatzszenarien.

Matrix zeigt den Nutzen offener Kommunikation

Auch Element und das offene Matrix-Protokoll liefern praktische Anknüpfungspunkte. Der BwMessenger basiert auf diesen Komponenten und wird durch die BWI in eigenen Rechenzentren der Bundeswehr betrieben; der BundesMessenger überträgt diesen Ansatz auf die öffentliche Verwaltung. Damit existieren bereits konkrete Erfahrungen mit staatlich kontrollierter Kommunikation auf offener technischer Grundlage.

Der wirtschaftliche Vorteil solcher Grundlagen liegt in der prinzipiellen Trennbarkeit von Software, Betrieb und Dienstleistung. Wenn eine Behörde ihre Infrastruktur selbst betreibt oder zwischen geeigneten Betreibern wählen kann, entstehen bessere Voraussetzungen für Wettbewerb. Die Kontrolle über den laufenden Dienst muss dann nicht zwangsläufig beim ursprünglichen Softwarehersteller verbleiben.

Allerdings ist auch ein Messenger keine vollständige Analyseplattform. Sichere Nachrichten, gemeinsame Dokumentenarbeit und die Verarbeitung großer Datenbestände sind unterschiedliche Aufgaben. Zudem muss jede konkrete Konfiguration die erforderlichen Schutzbedingungen erfüllen; aus einer behördlichen Nutzung folgt nicht automatisch die Eignung für jede Geheimhaltungsstufe. Offene Kommunikation ist deshalb ein wichtiger Baustein einer souveränen Architektur, aber keine universelle Antwort auf sämtliche Infrastrukturprobleme.

Offenheit ersetzt keine eigene Kompetenz

Quelloffene Software kann Kontrollmöglichkeiten erweitern, weil ihr Aufbau einsehbar ist und Weiterentwicklung grundsätzlich auf mehrere Akteure verteilt werden kann. Diese Möglichkeit entfaltet ihren Wert jedoch nur, wenn tatsächlich qualifizierte Fachkräfte, geeignete Entwicklungswerkzeuge und dauerhaft finanzierte Verantwortlichkeiten vorhanden sind. Einsehbarer Quellcode allein schließt Sicherheitslücken oder problematische Abhängigkeiten nicht automatisch aus.

Gerade bei komplexen Systemen genügt es nicht, einzelne Programme theoretisch verändern zu dürfen. Nötig sind Kenntnisse über ihr Zusammenspiel, die Erstellung verlässlicher Installationspakete und die Prüfung neuer Versionen. Die Aufmerksamkeit für gehärtete Basiskomponenten und sichere Lieferketten im staatlichen Open-Source-Ökosystem zeigt, wie wesentlich diese organisatorische Ebene ist.

Offenheit ist deshalb eher eine Voraussetzung für zusätzliche Handlungsoptionen als eine kostenlose Garantie. Ihr ökonomischer Nutzen liegt darin, dass Investitionen in Wissen und Entwicklung leichter zwischen Einrichtungen nachgenutzt werden können. Damit dies gelingt, sollten Anpassungen möglichst in gemeinsam gepflegte Grundlagen zurückfließen. Viele dauerhaft getrennte Sonderversionen würden dagegen Wartungsaufwand und Sicherheitsrisiken erhöhen.

Auch personelle Engpässe müssen realistisch behandelt werden. Eine Behörde wird nicht dadurch souverän, dass sie sämtliche Arbeit selbst übernimmt. Sinnvoller ist ein Modell, in dem der Staat ausreichend eigene Beurteilungs- und Steuerungskompetenz besitzt und zugleich auf mehrere professionelle Dienstleister zurückgreifen kann. Abhängigkeiten verschwinden dadurch nicht vollständig, werden aber besser überprüfbar und beherrschbar.

Die Bundeswehr liefert ein differenzierteres Bild

Für die Einordnung der ND-Cloud ist die private Cloud der Bundeswehr relevant, weil auch dort Google-Technologie vorgesehen ist und die BWI eine zentrale Rolle spielt. Diese Plattform ist allerdings nicht mit einer einzigen Google-Cloud gleichzusetzen: Die Bundeswehr verfolgt einen Ansatz aus mehreren technologisch getrennten Umgebungen, darunter VMware, Google und Open-Source-Software.

Die erste Ausbaustufe wurde 2025 eingeführt; der Aufbau und die Integration des Google-Stacks wurden ab 2026 mit einem vorgesehenen Abschluss bis Ende 2027 beschrieben. Als konkreter Anwendungsfall ist die SAP Business Technology Platform genannt, während zwei getrennte Umgebungen für offene und bis VS-NfD geschützte Informationen vorgesehen sind. Dieser veröffentlichte Zeitplan darf nicht als bereits abgeschlossener Betriebszustand ausgegeben werden.

Das Beispiel verdeutlicht, dass grundlegende Softwareentscheidungen weitere Infrastrukturentscheidungen nach sich ziehen können. Wird eine Fachplattform benötigt, deren unterstützte Betriebsumgebungen eng begrenzt sind, verengt sich die tatsächliche Auswahl bereits vor der Betrachtung einzelner Cloudanbieter. Eine Souveränitätsanalyse muss deshalb die gesamte technische Kette untersuchen und darf nicht an der sichtbaren Infrastrukturmarke enden.

Mehrere Plattformen schaffen allerdings nur dann echte Ausweichfähigkeit, wenn wesentliche Anwendungen tatsächlich zwischen ihnen bewegt werden können. Drei getrennte Umgebungen mit jeweils fest gebundenen Fachverfahren bedeuten zunächst Vielfalt, aber noch keine gegenseitige Ersetzbarkeit. Die BWI nennt die Verringerung von Anbieterabhängigkeiten und die aufwandsarme Verschiebung von Anwendungen ausdrücklich als Ziele ihres Ansatzes.

Rechtsrisiken verlangen technische Präzision

In Debatten über amerikanische Technologie wird häufig auf den CLOUD Act verwiesen. Der rechtliche Ausgangspunkt ist, dass US-rechtlich erfasste Unternehmen zur Herausgabe von Daten verpflichtet werden können, die sich in ihrem Besitz, ihrer Verwahrung oder ihrer Kontrolle befinden, unabhängig vom Speicherort. Der bloße Standort Deutschland beseitigt deshalb nicht automatisch sämtliche Rechtsrisiken.

Umgekehrt schafft eine rechtliche Herausgabebefugnis keinen technischen Zugang, der vorher nicht vorhanden war. Wenn ein Anbieter tatsächlich weder Zugriff auf Daten noch Kontrolle über die hierfür benötigten Schlüssel hat, muss diese Architektur bei der rechtlichen Bewertung berücksichtigt werden. Eine isolierte Plattform lässt sich daher nicht ohne Weiteres mit einem gewöhnlichen, vom Hersteller betriebenen Internetdienst gleichsetzen.

Für die ND-Cloud bleiben öffentlich nicht bekannte Details entscheidend: Welche Rollen sind lokal verfügbar, wie funktionieren Notfallzugänge, welche Informationen werden bei der Fehleranalyse benötigt und wer kontrolliert kryptografische Schlüssel? Die allgemeine Google-Dokumentation sieht getrennte Betriebsrollen und besondere Notfallverfahren vor, beschreibt damit aber nicht automatisch die endgültige deutsche Ausgestaltung. Pauschale Entwarnung wäre daher ebenso wenig angemessen wie die unbelegte Behauptung eines automatischen amerikanischen Datenzugriffs.

Davon zu unterscheiden ist das Versorgungsrisiko. Selbst wenn Datenzugriffe technisch ausgeschlossen sind, könnten rechtliche oder geopolitische Konflikte Leistungen wie Softwarepflege und Unterstützung berühren. Eine umfassende Souveränitätsbewertung muss deshalb sowohl die Kontrolle über Informationen als auch die Kontinuität unverzichtbarer Leistungen untersuchen.

Was eine ehrliche Kostenrechnung enthalten müsste

Eine vollständige Wirtschaftlichkeitsanalyse müsste mehr erfassen als Hardware und anfängliche Softwarekosten. Hinzu gehören Integration, Personal, Energie, Schulung, Sicherheitsüberwachung, Datensicherung, Wiederanlauf und die laufende Anpassung von Fachverfahren. Bei der ND-Cloud fehlen öffentlich zugängliche Detaildaten, um diese Bestandteile belastbar zu beziffern; die bekannte Schätzung von mindestens 500 Millionen Euro ersetzt diese Aufschlüsselung nicht.

Zusätzlich müssten Kosten berücksichtigt werden, die erst bei einem Wechsel auftreten. Dazu zählen die Übertragung von Daten, die Anpassung von Programmen, zeitweiser Parallelbetrieb und erneute Sicherheitsprüfungen. Die europäischen Regeln zum Cloudwechsel unterscheiden entsprechend mehrere technische Schritte von der Datenentnahme bis zur Überführung in eine Zielumgebung. Ein wirtschaftlich relevanter Ausstieg ist damit weit mehr als das Herunterladen eines Dateiarchivs.

Wichtig ist außerdem die Unterscheidung zwischen Haushaltskosten und volkswirtschaftlichen Wirkungen. Leistungen deutscher Rechenzentren und Dienstleister können lokale Wertschöpfung schaffen, auch wenn zentrale Software von einem internationalen Konzern stammt. Umgekehrt ist ein europäischer Anbieter nicht frei von globalen Lieferkettenabhängigkeiten. Eine seriöse Rechnung müsste deshalb die tatsächliche Verteilung von Kompetenzen und Erträgen betrachten, statt sämtliche Ausgaben pauschal einem Herkunftsland zuzuordnen.

Schließlich wären unterschiedliche Krisenszenarien getrennt zu bewerten. Ein kurzzeitiger Supportausfall, ein längerfristiger Wegfall von Updates und ein kurzfristiger Plattformwechsel haben verschiedene Folgen. Statt eine scheinbar präzise Einzahl für alle Risiken zu erzeugen, wäre es sachgerechter, Bandbreiten, Annahmen und besonders schwer tragbare Schadensfolgen transparent zu machen. Für die Festlegung solcher Werte fehlen derzeit öffentlich ausreichende Projektdaten.

Messbare Autonomie statt beruhigender Etiketten

Mit den im April 2026 veröffentlichten Criteria enabling Cloud Computing Autonomy hat das Bundesamt für Sicherheit in der Informationstechnik einen Rahmen vorgelegt, der selbstbestimmte Nutzung von Cloud-Diensten systematischer bewertbar machen soll. Die Kriterien ergänzen die auf Sicherheit ausgerichteten C5-Anforderungen, entfalten aber für sich genommen keine regulative Wirkung. Sicherheit und Souveränität werden damit ausdrücklich als verwandte, jedoch unterschiedliche Bewertungsfragen behandelt.

Der Rahmen unterscheidet strategische, rechtliche, datenbezogene, operative, lieferkettenbezogene und technologische Aspekte. Dazu passen konkrete Prüfgrößen wie die Übertragbarkeit von Betriebswissen, die Verfügbarkeit unabhängiger Wartung oder die Möglichkeit zur Weiterführung bei Ausfall eines Dritten. Solche Eigenschaften sind für eine Hochsicherheitsplattform aussagekräftiger als eine pauschale Selbstbeschreibung als souverän.

Für den praktischen Betrieb wäre ein regelmäßig erprobter Wiederanlauf besonders wertvoll. Dabei müsste sich zeigen, ob vorhandene Sicherungen, Dokumentation und Fachkenntnisse ausreichen, um wesentliche Funktionen unter klar definierten Störbedingungen wiederherzustellen. Ebenso ließe sich prüfen, welche Daten und Anwendungen auf einer zweiten Umgebung tatsächlich nutzbar sind. Ein bestandener Test wäre ein besserer Nachweis als eine bloß theoretische Wechselmöglichkeit.

Auch regulatorische Fortschritte ändern nichts an dieser technischen Aufgabe. Der Data Act sieht für erfasste Datenverarbeitungsdienste ab dem 12. Januar 2027 ein Verbot von Wechselentgelten vor. Daraus folgt jedoch weder, dass jede spezielle Nachrichtendienstumgebung ohne Weiteres darunterfällt, noch dass interne Migrations-, Entwicklungs- und Sicherheitskosten verschwinden. Kostenfreiheit des Wechselvorgangs auf Anbieterseite und tatsächliche technische Austauschbarkeit sind nicht dasselbe.

Mehr Rechenleistung braucht klare Zugriffsgrenzen

Eine gemeinsame Plattform kann die Zusammenarbeit erleichtern, darf aber unterschiedliche gesetzliche Aufgaben und Datenbefugnisse nicht durch technische Vereinfachung einebnen. Aus einer gemeinsamen Infrastruktur folgt keine pauschale Erlaubnis, alle dort vorhandenen Informationen frei zwischen sämtlichen Beteiligten zu nutzen. Besonders beim Austausch zwischen Nachrichtendiensten und Polizei bestehen erhöhte verfassungsrechtliche Anforderungen, die nicht mit dem bloßen Austausch zwischen Nachrichtendiensten verwechselt werden dürfen.

Für die Architektur bedeutet dies, dass Rollen, Zwecke, Herkunft und zulässige Weitergabe von Daten angemessen abgebildet werden müssen. Technische Plattformen können feingranulare Zugriffsregeln und nachvollziehbare Protokollierung unterstützen; die Google-Dokumentation beschreibt dafür rollen- und attributbasierte Berechtigungen sowie die Protokollierung von Zugriffen. Die rechtmäßige konkrete Anwendung bleibt jedoch eine eigenständige Aufgabe der verantwortlichen Stellen.

Hinzu kommt ein Konzentrationsrisiko. Gemeinsame Infrastruktur kann Sicherheitskompetenz bündeln, zugleich aber bei einer schwerwiegenden Störung mehrere Behörden betreffen. Deshalb müssen logische Trennung, Wiederherstellung und unabhängige Kontrollmöglichkeiten gemeinsam betrachtet werden. Die wirtschaftliche Bewertung sollte nicht allein an der Auslastung von Rechenzentren hängen, sondern auch daran, wie gut kritische Funktionen bei Teilstörungen erhalten bleiben.

KI verschiebt die Abhängigkeit zur Modelleebene

Automatisierte Übersetzung, Zusammenfassung und Auswertung großer Datenbestände sind plausible Einsatzfelder einer abgeschotteten Cloud; Google bietet entsprechende KI-Funktionen für diese Produktfamilie an. Damit kann sich die technische Bindung über Infrastruktur hinaus auf Modelle, Schnittstellen und die Organisation analytischer Arbeitsabläufe erstrecken. Je stärker Fachverfahren auf bestimmte KI-Dienste ausgerichtet werden, desto wichtiger wird ihre Austauschbarkeit.

Ein lokal betriebenes Modell ist allerdings nicht automatisch souverän. Relevant sind auch Nutzungsrechte, Aktualisierbarkeit, verfügbare Modellbestandteile und die Möglichkeit, das Werkzeug unter veränderten Bedingungen weiterzuverwenden; die allgemeinen Produktbedingungen unterscheiden ausdrücklich verschiedene Modelle und Nutzungsformen. Ob bestimmte KI-Angebote für die ND-Cloud tatsächlich vorgesehen sind, lässt sich aus der allgemeinen Produktverfügbarkeit nicht ableiten.

Ökonomisch müsste KI deshalb an der Qualität ihrer Ergebnisse gemessen werden und nicht nur an der Zahl verarbeiteter Dokumente. Zusätzliche Ausgaben können wertvoll sein, wenn sie Auswertung beschleunigen und relevante Erkenntnisse besser auffindbar machen. Sie können aber auch Folgeaufwand erzeugen, wenn fehlerhafte Zusammenfassungen oder unzutreffende Verknüpfungen geprüft werden müssen; der Anbieter weist grundsätzlich auf mögliche unrichtige Ausgaben generativer Systeme hin.

Eine strategisch robuste Gestaltung würde daher Datenhaltung, Modelle und Benutzeroberflächen möglichst sauber voneinander trennen. So ließen sich einzelne Analysewerkzeuge erneuern, ohne zwangsläufig die gesamte Plattform austauschen zu müssen. Gerade bei schnell wechselnden KI-Technologien ist die Fähigkeit zur kontrollierten Erneuerung ein wirtschaftlicher Vorteil und nicht bloß eine politische Forderung.

Internationale Zusammenarbeit ohne dauerhafte Kernabhängigkeit

Der Austausch mit Partnerdiensten kann kompatible technische Verfahren erfordern. Daraus folgt jedoch nicht zwingend, dass sämtliche internen Arbeitsprozesse auf derselben Plattform stattfinden müssen. Die Bundeswehr nennt internationale Interoperabilität als wesentliches Ziel ihrer Mehrplattformstrategie und verbindet dies ausdrücklich mit der Verringerung von Anbieterabhängigkeiten.

Ein sinnvoller Ansatz wäre, zwischen nationalem Kernbetrieb und genau abgegrenzten Austauschfunktionen zu unterscheiden. Für internationale Kooperation könnten spezialisierte Schnittstellen und freigegebene Übertragungsverfahren genutzt werden, während zentrale Datenbestände und grundlegende Zusammenarbeit eigenständig beherrschbar bleiben. Die Beteiligung eines internationalen Technologieanbieters wäre damit eine funktional begrenzte Entscheidung und nicht automatisch die Grundlage sämtlicher interner Prozesse.

Allerdings lösen Schnittstellen nicht jedes Problem. Unterschiedliche Geheimhaltungsstufen, Datenmodelle und Freigaberegeln verursachen zusätzlichen Aufwand. Eine stärker entkoppelte Architektur kann deshalb zunächst teurer und komplexer sein. Ihr Vorteil liegt darin, dass einzelne Kooperationsfunktionen verändert werden können, ohne den nationalen Kernbetrieb gleichermaßen zu berühren. Ob dieser Vorteil die Mehrkosten rechtfertigt, müsste anhand konkreter Anforderungen geprüft werden.

Die entscheidende Fähigkeit heißt wechseln können

Die fachlich überzeugendste Perspektive liegt weder in pauschaler Ablehnung amerikanischer Technologie noch in der Annahme, technische Netztrennung erledige jede Souveränitätsfrage. Die geplante ND-Cloud könnte reale Leistungsprobleme adressieren; ihre abgeschottete Architektur und die fortbestehende externe Softwareversorgung müssen jedoch getrennt bewertet werden.

Für allgemeine Zusammenarbeit verdienen geeignete offene Lösungen eine systematische Prüfung, weil openDesk und Matrix-basierte Dienste bereits praktisch eingesetzte Bausteine darstellen. Für hochspezialisierte Verarbeitung können andere technische Anforderungen gelten. Entscheidend wäre, begründete Ausnahmen nicht zu einer pauschalen Dauerabhängigkeit auszudehnen und die jeweils verbleibenden Risiken ausdrücklich zu benennen.

Eine belastbare Strategie müsste daher eigene Bewertungskompetenz, nachvollziehbare Aktualisierungsprozesse und erprobte Ausweichmöglichkeiten miteinander verbinden. Nicht jede Anwendung benötigt eine sofort nutzbare vollständige Zweitplattform. Kritische Funktionen sollten aber so gestaltet sein, dass ein externer Leistungsausfall nicht zwangsläufig zum Verlust staatlicher Handlungsfähigkeit führt. Dafür sind technische Vorkehrungen ebenso erforderlich wie qualifiziertes Personal und langfristige Finanzierung.

Der eigentliche Souveränitätstest findet nicht im störungsfreien Normalbetrieb statt. Er beginnt in dem Moment, in dem ein Hersteller seine Bedingungen ändert, Unterstützung ausfällt oder politische Rahmenbedingungen kippen. Eine leistungsfähige Cloud ist für den Staat wertvoll. Strategisch beherrschbar wird sie erst dann, wenn er nicht nur ihren gegenwärtigen Betrieb kontrolliert, sondern auch über tragfähige Optionen für ihre Zukunft verfügt.

Gerne stehe ich Ihnen als persönlicher Berater zur Verfügung.

Head of Business Development

Chairman SME Connect Defence Working Group

LinkedIn

 

 

Gerne stehe ich Ihnen als persönlicher Berater zur Verfügung.

Sie können mit mir unter wolfenstein∂xpert.digital Kontakt aufnehmen oder

mich einfach unter +49 7348 4088 965 anrufen.

LinkedIn