Der deutsche Staat will in die Public Cloud, weil sich dort die notwendige Digitalisierung schneller und einfacher umsetzen lässt. Allerdings schreckt er vor diesem Schritt seit Jahren zurück, aus Sorge die Kontrolle über seine IT-Infrastruktur zu verlieren und diese in ausländische Hände zu geben.
Die Bundesländer haben 2021 mit einem Positionspapier zur Schaffung einer deutschen Verwaltungscloud einen Vorstoß gewagt und Druck auf die Regierung aufgebaut. In dem Positionspapier wird betont, dass die Nutzung kommerzieller Public-Cloudangebote erforderlich sein könnte. Dementsprechend finden die Bundesländer ein Angebot von Microsoft für die Bereitstellung einer souveränen Cloud für die öffentliche Verwaltung in Deutschland einen Schritt in die richtige Richtung. Auch erwähnt wird, dass das BSI dazu die "Roten Linien" abstecke.
Aber was sind die „roten Linien“ und worum geht es dabei überhaupt? Diese Frage sowie notwendige Voraussetzungen und mögliche Hürden betrachtet dieser Artikel. Auch um zu klären, ob sich die Anforderungen überhaupt umsetzen lassen und welche davon die wirklich Wesentlichen sind.
Der Staat wünscht sich eine souveräne Cloud
Als Basis für die Umsetzung einer Verwaltungscloud hat das BSI die „roten Linien” entwickelt. Anfangs noch nicht frei verfügbar wurden sie im Sommer 2022 durch eine FragDenStaat-Anfrage öffentlich. Das Dokument enthält auf 14 Seiten 121 Anforderungen in drei Kategorien:
Die Anforderungen definieren die wesentlichen Sicherheitsanforderungen der Bundesregierung für Cloud-Plattformen als souveräne Cloud für die öffentliche Verwaltung. Sie sollen die Rahmenbedingungen für potenzielle Anbieter aufzeigen, aber auch eine Identifizierung der wichtigsten Hindernisse ermöglichen.
In dem Dokument definiert das BSI einen Cloud-Plattform-Anbieter als ein kommerzielles Unternehmen, das die Cloud bereitstellt. Die Cloud selbst wird dort als Infrastruktur, inklusive Technologie, Dokumentation und Beschreibung der operativen Prozesse definiert. Zudem solle der Betrieb von einem staatlichen Akteur erbracht werden.
Sortierung der Anforderungen
cloud ahead hat in einem mehrstufigen Modell die 121 Anforderungen kategorisiert und in Excel nutzbar gemacht. Die Datei ist in unseren Downloads verfügbar.
Stufe 1: Die Cloud-Definition des BSI
Das BSI bildet durch seine Anforderungen, ähnlich einem Lastenheft, den Rahmen für die Bereitstellung eines Angebots durch einen Cloud-Anbieter. Über 90% der Anforderungen sind zwingende Anforderungen, die umgesetzt werden müssen. Unabhängig von der Komplexität der Umsetzung einzelner Anforderungen sind diese nicht in Stein gemeißelt. Das BSI bietet in dem Dokument die Möglichkeit geeignete Alternativen vorzuschlagen. Aber nur, sofern die Alternativen die genannten Anforderungen anderweitig erfüllen und zu einem gleichwertigen Sicherheitsniveau führen.
Stufe 2: Die mögliche Umsetzbarkeit der roten Linien
cloud ahead hat für alle Anforderungen die Komplexität einer Umsetzung eingeschätzt. Die meisten Anforderungen wurden mit „einfach“ oder „moderat“ bewertet. Anders sieht das bei 35 Anforderungen aus, die wir mit „Schwer“ eingeschätzt haben. Zwei weitere wurden als „Unklar“ markiert, da sie nicht unbedingt in der Verantwortung eines Cloud-Anbieters liegen. Die letzten beiden Kategorien haben wir im Folgenden einer näheren Betrachtung unterzogen.
Stufe 3: Die 6 Kern-Herausforderungen der roten Linien
Um die Kern-Herausforderungen der roten Linien zu identifizieren haben wir die 35 Anforderungen aus Stufe 2 in Herausforderungstypen gruppiert und bewertet. Basis hierfür ist unser Erfahrungswissen zu aktuellen Cloud-Anbietern und zum aktuellen Stand der Technologie. Im Ergebnis lassen sich sechs Gruppen zusammenfassen.
Gruppe 1 – Staatsverantwortung
Das BSI fordert ein Private-Cloud-Angebot, dass von einem kommerziellen Anbieter in staatlicher Infrastruktur zu Verfügung gestellt und von staatlichen Mitarbeitern betrieben wird.
Drei zwingende Anforderungen, die von kommerziellen Anbietern, wie IONOS oder Delos (SAP/Arvato), kaum leistbar sind. Sie müssten die Infrastruktur bereitstellen und Beamte schulen, die den operativen Betrieb übernehmen. Wer wäre im Falle eines Fehlers verantwortlich: Die Beamten oder der kommerzielle Anbieter?
Diese Art der Umsetzung ist in Deutschland aus diversen Gründen kaum vorstellbar. Ob es fehlende staatliche Kompetenzen, Fachkräftemangel und die, im Vergleich zum IT-Markt, schlechte Bezahlung von Beamten ist. Oder der Fakt, dass praktisch alle großen IT-Projekte (wie z.B. die Corona App) und Fachverfahren von externen Beratern wie Accenture, PwC und co durchgeführt werden.
Gruppe 2 – Individualisierung
Das BSI fordert die Möglichkeit Software-Updates und Patches abzulehnen oder vor der Implementierung individuelle Anpassungen zu erhalten. Ein entsprechender Change-Management-Prozess muss aufgesetzt sein.
Konkret könnte die Umsetzung folgendermaßen aussehen: Das BSI lehnt ein Update ab und verlangt eine Anpassung. Daraufhin bittet der deutsche Cloud-Plattform-Anbieter, zum Beispiel Ionos oder SAP, den Technologie-Anbieter, passend zum Beispiel VMware oder Microsoft, um eine Anpassung. Der Hersteller, bzw. Technologie-Anbieter müsste den Änderungswunsch dann entweder in seine Standard-Technologie übernehmen oder von nun an eine zusätzliche Variante (Fork) seiner Standard-Cloud-Technologie pflegen.
Grundsätzlich ist ein solcher Change-Management-Prozess, abgesehen vom Aufwand, kein Problem, zwingt den Hersteller aber früher oder später zu einem Fork. Dieser führt zu zusätzlichem Aufwand, denn jede Variante muss für sich gepflegt und geupdatet werden. Zudem würde sich die souveräne Cloud aufgrund der erwartbaren Verlangsamung des Entwicklungsprozesses schnell von den leistungsstarken Clouds für die Privatwirtschaft entfernen
Gruppe 3 – Kontrolle und Sicherheit
Nach der Vorstellung des BSI müssen Updates durch den Betreiber überprüfbar sein. Dafür muss der Betreiber vom Hersteller mit Wissen und entsprechenden Tools ausgestattet werden. Außerdem muss das BSI eine Prüfungsmöglichkeit des Source Codes bekommen.
Im Falle von Azure als Cloud-Technologie müssten der Betreiber und das BSI pro Monat bis zu 5000 Updates, bezogen auf mehr als 1000 Services, gegebenenfalls prüfen und freigeben. Diese Herausforderung potenziert sich, wenn, wie in der deutschen Multi-Cloud-Strategie erwünscht, souveräne Clouds auf Basis von AWS, Google, VMware und OpenStack entstehen.
Im Anbetracht der Performance anderer BSI-Projekte, wie des Smart-Meter-Rollouts, und mit Blick auf die notwendige Geschwindigkeit bei kritischen Sicherheitslücken scheint diese Anforderung schwer umsetzbar. Genauso unsicher ist es, ob jeder Hersteller Einblick in seinen Source Code gewährt.
Gruppe 4 – Autarkie und Kontinuität
Die Cloud für den Bund muss einen Autarkie-Modus unterstützen, also für eine nicht näher definierte Zeit ohne Updates oder fremde Unterstützung lauffähig bleiben. Nach einem Wechsel vom Autarkie-Modus in den Normal-Modus muss die Cloud auf einen aktuellen Softwarestand gebracht werden. Außerdem dürfen Exportbeschränkungen oder Änderungen der Lizenzpolitik nicht zu Verfügbarkeitsproblemen führen.
Der erste Teil, der Autarkie-Modus, ist klar definiert. Die Cloud muss sicher und unabhängig betrieben werden können, auch im Kontext einer Auseinandersetzung, zum Beispiel mit den USA. Nach dem Wechsel zurück in den Normal-Modus müssen alle Services, Softwares und Firmwares auf den dann aktuellen Softwarestand gebracht werden. Die Motivation hinter diesen Anforderungen liegt in dem von den USA ausgesprochenen Exportverbot von Chip-Technologien an China oder dem Lizenzentzug für Huawei Handys und Laptops.
Das Kernproblem ist aber, dass mit jedem Monat im Autarkie-Modus die Anzahl der notwendigen Updates steigt, im Falle einer Azure-basierten Cloud um besagte 5000 pro Monat. Technisch ist eine solch große Lücke nach einiger Zeit inkrementell praktisch nicht mehr zu schließen.
Gruppe 5 - Herstelleranforderungen
Das BSI fordert von Herstellern definierte SLAs zur Beantwortung von Betreiberanfragen sowie den Verzicht auf die Übermittlung von Telemetriedaten. Aber auch die Bereitstellung von langfristigen Roadmaps für Änderungen und Anpassungen von Schnittstellen.
Bei Endgeräten oder Software, die mit der souveränen Cloud verbunden sind, muss sichergestellt werden, dass diese Cloud der Endpunkt für alle Telemetriedaten ist. Beispielweise dürften Nutzungsdaten bei O365 nicht zu Microsoft weitergeleitet werden. Ausnahmen hierzu gelten lediglich für anonymisierte Abrechnungsdaten.
Bei engen Partnerschaften zwischen europäischem Cloud-Anbieter und externem Technologie-Hersteller, wie bei Delos (SAP/arvato mit Microsoft) oder T-Systems (mit Google), lassen sich diese Anforderungen umsetzen. Für Anbieter, die auf Standardsoftware setzen und keine vergleichbar enge Beziehung mit dem Technologie-Hersteller haben, wird es schwierig sein an die relevanten Informationen zu gelangen (siehe Roadmaps und Betreiberanfragen) sowie die notwendigen Änderungen an Software-Updates durchzusetzen (siehe Forks und Telemetriedaten).
Gruppe 6 - Interoperabilität
Laut dem BSI muss eine Migration zwischen den verschiedenen Cloud-Angeboten möglich sein. Außerdem müssen Services von Dienstleistern des Bundes in die Cloud integrierbar und umgekehrt die Cloud in die Dienstleister-Services integriert werden können.
Nutzt also eine Behörde das Delos Cloud-Angebot muss sie in der Lage sein mit allen Projekten, Services und Daten in die souveräne Cloud von T-Systems / Google umzuziehen.
Die Motivation liegt in der Vermeidung eines Lock-in-Effekt und der Ermöglichung von Migrationen. Sollte ein solcher Wechsel für komplexe Applikationen so einfach sein, wie der Wechsel zwischen Stromanbietern, dann müssten alle Cloud-Angebote die gleichen Services und Funktionen oder zumindest die gleichen Schnittstellen vorhalten. Dies würde voraussetzen, dass die Cloud-Anbieter sich selbst sehr genau synchronisieren oder der Bund genaue Spezifikationen für Cloud-Services und Schnittstellen vorgibt. Beides scheint unwahrscheinlich und läge in jedem Falle außerhalb des Wirkungsbereichs eines einzelnen Akteurs.
Schlussfolgerung
Wenngleich die veröffentlichten roten Linien sicher nicht der Weisheit letzter Schluss sind, hat das BSI hat mit seinem ersten Wurf eine gute Basis geschaffen, um in Deutschland leistungsfähige und gleichzeitig kontrollierbare Cloud-Lösungen für staatliche Organisationen entstehen zu lassen.
Es zeigt sich aber, wie relevant das Anbietermodell bei der Umsetzung ist. Dementsprechend ergeben sich aus unserer Sicht in Zukunft drei verschiedene Modelle für souveräne Clouds:
- Ein amerikanischer Hyperscaler, der seine Technologie an ein dediziertes deutsches Konsortium abgibt. Beispiele sind T-Systems und Google oder SAP/Arvato und Microsoft.
- Ein deutscher IT-Anbieter mit Nutzung von amerikanischer Standard-Technologien. Beispielsweise IONOS mit VMware.
- Ein deutscher IT-Anbieter mit einer souveränen Cloud, basierend auf europäischer Technologie und/oder Open-Source-Software. Beispielsweise mit SCS.
Fazit
Die Anforderungen des BSI erscheinen bezogen auf die digitale Souveränität und aktuelle Ereignisse grundsätzlich richtig. Allerdings sind einige davon nicht einfach umzusetzen und werden sicher zu Diskussionen führen. Der Bund und das BSI müssten dafür Kompetenzen und Ressourcen aufbauen, die aktuell sicher nicht vorhanden sind. Für Anbieter stellt sich die Frage, ob und wie die Anforderungen in der Form mit ihrem Geschäfts- und Betriebsmodell umsetzbar sind. Interessant wird dementsprechend, wie die ersten Angebote damit umgehen und welche Anbieter sich dazu überhaupt positionieren. Spätestens dann wird auch klar, wie festgeschrieben die roten Linien wirklich sind und wie die nächste Version aussieht.
