Die Schweizer Bundesverwaltung verfügt seit 5 Jahren Verträge mit 5 amerikanischen und chinesischen Tech-Konzernen: Alibaba, Amazon, Oracle, IBM und Microsoft.
In der Vergangeheit habe ich herausgefunden, wo genau die amerikanische Public Cloud-Anbieter genau im Einsatz sind.
Die Bundesämter nutzen nur zaghaft die Cloud-Angebote. Kein Wunder: Sie sind verunsichert, weil sie auch den Datenschutz für die Projekte verantworten. Alle Ämter wollen ausserdem «nur» mit Microsoft und Amazon zusammenarbeiten. So laufen wichtige, täglich tausendfach genutzte Zoll-Apps auf der Cloud von Amazon und das Organ-Widerspruchsregister bei Microsoft Azure Cloud. Und diese werden noch eine Weile dort bestehen bleiben.
Der Grund: Die vom Bundesamt für Informatik und Telekommunikation BIT geplante grosse neue Swiss Government Cloud-Infrastruktur ist noch nirgends, nicht einmal ist die Ausschreibung bisher erfolgt. Damit die Zoll-Apps und weitere Applikationen nicht plötzlich in diesem Jahr einfach von heute auf morgen ausgeschaltet werden, hat die Bundeskanzlei die Rahmenverträge mit den globalen Playern deshalb nochmals um fünf Jahre bis 2031 verlängert.
Von den vorgesehenen 110 Millionen Franken sind insgesamt erst 61 Millionen «reserviert» – Jargon für eine Art Vorbuchung – und 8,1 Millionen Franken an Cloud-Dienstleistungen genutzt worden, wie interne Unterlagen zeigen, die mir vorliegen (und ich aus Quellenschutzgründen nicht publizieren kann). Das bedeutet auch: Die Ämter können noch viel «Cloud-Dienstleistungen» vom bereits gesprochenen Budget buchen.
Über die Rahmenverträge werde ich demnächst bei der Republik.ch wieder etwas veröffentlichen (was bisher geschah: wir konnten die Veröffentlichung von Alibaba, Oracle, IBM und Microsoft erwirken (Amazon steht noch aus).
Im Rahmen meiner Recherchen habe ich noch herausgefunden, dass Amazon und Microsoft höher klassifizierte Daten (damit sind oberen Schutz- bzw. Geheimhaltungsstufen, deren Bekanntwerden die Sicherheit oder Handlungsfähigkeit des Bundes erheblich oder schwerwiegend beeinträchtigen könnte, zum Beispiel operative Lage- und Einsatzpläne von Armee oder Nachrichtendiensts) und besonders schützenswerte Daten (wie beispielsweise Gesundheitsinformationen) verarbeiten.
Und zwar im Fall der Auftraggeberinnen Bundesamt für Grenzsicherheit BAZG, Bundesamt für Gesundheit BAG (interessant übrigens, dass die Zürcher Gesundheitsdirektion zu einem ganz anderen Schluss kam bei diesen Fragen und auf keinen Fall ihre Anwendung an eine Public Cloud auslagern will) und auch beim Bundesamt für Bevölkerungsschutz BABS.
Dies geht aus internen Unterlagen hervor, die mir vorliegen.
Was bisher nicht bekannt war: das BABS hat eine wichtige Anwendung entweder auf Amazon oder Microsoft laufen.
Nachfrage bei der Medienstelle:
„Im BABS wird aktuell ausschliesslich die Fachapplikation IES NG auf einer Cloud-Infrastruktur betrieben.
Im Rahmen einer internen Evaluation wurde geprüft, welche Lösung sowohl aus sicherheitstechnischer als auch aus wirtschaftlicher Sicht geeignet ist. Dabei hat sich Microsoft Azure als die zweckmässigste und kosteneffizienteste Option erwiesen.
Das System IES NG befindet sich derzeit im Aufbau in der Cloud und wird noch nicht produktiv eingesetzt.“
Was ist jetzt genau diese Anwendung mit dem sperrigen Namen „IES NG“?
Das steht für Informations- und Einsatzsystem und ist somit ein digitales Koordinations- und Einsatzleitsystem für den Sanitätsdienst.
Das IES NG ermöglicht bei Unfällen, Grossereignissen und Katastrophen eine Patienten- und Personenverfolgung sowie die Zuweisung von Patienten an Spitäler und den Informationsaustausch zwischen Blaulichtorganisationen.
Auf der Website steht dazu:
Die Software soll insbesondere bei der Beantwortung folgender Fragen unterstützen:
- Wie viele Verletzte gibt es?
- Was ist deren Zustand?
- Wo sind die Verletzten?
- Welche Gefahren bestehen auf dem Schadensplatz?
- Welche Einsatzkräfte stehen zur Verfügung?
- Welche Einsatzkräfte können in gegebener Frist in den Einsatz gebracht werden?
- Welche Partnerorganisationen können zur Ereignisbewältigung beigezogen werden?
- Welche Spitäler können die Patienten optimal versorgen?
- Welche Spitäler haben verfügbare Kapazitäten zur optimalen Versorgung der Verletzten?
Die Nutzer reichen von Rettungsdiensten über Kantonspolizeien bis hin zu Spitälern und Kantonalen Führungsstäben.
Die Software wird also auf Microsoft Azure betrieben und deren Daten in den Microsoft-Rechenzentren gespeichert.
Die Medienstelle des BABS hat gleich ihre Überlegungen zum Thema Sicherheit mitgeschickt:
„Beim Aufbau der Umgebung wurden umfassende Sicherheitsmassnahmen umgesetzt. So wird IES NG ausschliesslich auf Servern in der Schweiz betrieben. Zudem verfügt das System über ein eigenes Key-Management. Die kryptographischen Schlüssel werden vom BABS selbst generiert und verwaltet. Dadurch wird sichergestellt, dass ausschliesslich das BABS Zugriff auf die entschlüsselten Daten hat. Auch der Cloud-Anbieter selbst hat keinen Zugriff auf diese Inhalte.
Im Rahmen der Projektarbeiten wurden mögliche Risiken identifiziert und entsprechende Massnahmen definiert. Diese werden in den kommenden Monaten schrittweise umgesetzt. Insgesamt wird das Risikoprofil derzeit als gering eingeschätzt.“
Empfehlung an alle mitlesenden Journalist:innen an dieser Stelle: das Risikoprofil via Öffentlichekeitsgesetz verlangen.
Das IES NG verarbeitet also hochsensible Daten:
- Patientendaten (Verletzte, Triage-Status, Diagnosen)
- Einsatzdaten von Polizei, Rettungsdiensten, Armee
- Kapazitäten von Schweizer Spitälern
- Lagebilder bei Katastrophen und Grossereignissen
Die gute Nachricht dabei:
Das BABS arbeitet bei IES NG nicht mit der Microsoft EntraID.
Microsoft Entra ID (früher: Azure Active Directory / Azure AD) ist der cloudbasierte Identitäts- und Zugangsdienst von Microsoft. Vereinfacht gesagt: Es ist das System, das verwaltet, wer sich wo einloggen darf – in Firmen, Behörden, Apps und Systemen.
Wenn eine Behörde Entra ID nutzt, läuft ihre gesamte Identitätsverwaltung über Microsoft-Server in der Cloud.
Entra ID ist der Türsteher des Systems. Fällt er aus – ob durch technischen Ausfall, politischen Druck oder bewusste Abschaltung – kann sich niemand mehr einloggen. (Wenn Azure ausfällt, natürlich auch niemand).
Der stellvertretende Kommunikationschef des BABS sagt auf Anfrage:
Wie ist das Thema Identity/IAM geregelt?
„Das System IES NG ist an eIAM des Bundes angebunden (eIAM, das zentrale Zugriffs- und Berechtigungssystem der Bundesverwaltung — eIAM, Identity & Access Management des Bundes). Es unterstützt aktuell alle Bundesidentitäten.“
Einen Einsatz der EntraID hat der stellvertretende Kommunikationschef explizit verneint.
Dennoch bleiben natürlich viele Risiken bestehen. Microsoft hat als Infrastrukturbetreiber auf Azure immer den Masterschlüssel über Azure Key Vault (sofern genutzt), Zugang zu den virtuellen Maschinen, Zugang zu den Speichersysteme, Kontrolle über Netzwerk, Routing, Backups, und natürlich Möglichkeit zur Abschaltung via Kill Switch auf Infrastrukturebene.
Wie die Verschlüsselung vonstatten geht, wollte die Medienstelle nicht beantworten.
Beim IES-NG geht es um besonders schützenswerte Personendaten aus Katastrophensituationen. Eine Public-Cloud-Architektur schafft hier ja zusätzliche Abhängigkeiten – technisch, juristisch und operativ. Für ein nationales Einsatzsystem wäre aus Sicht von Souveränität und Resilienz eine stärker kontrollierte Infrastruktur naheliegender. Hat man sich hierzu keine Gedanken gemacht?
„Ja, diesem Aspekt wurde Rechnung getragen.
Beim Aufbau der Cloud-Umgebung wurden verschiedene zusätzliche Sicherheitsvorkehrungen umgesetzt. Beispielsweise werden sämtliche Daten verschlüsselt gespeichert und der Zugriff ist eingeschränkt. Wir bitten an der Stelle um Verständnis, dass wir die technischen Details gerade aus Sicherheitsüberlegungen nicht umfassend teilen.“
Wir erfahren nicht, ob die Schlüssel beim BABS liegen oder allein von Microsoft verwaltet werden. So oder so kann sich das Amt für Bevölkerungsschutz den klassischen US-amerikanischen Überwachungsgesetzen und Dekreten (Executive Order 12333, FISA Section 702 und den Cloud Act) damit NICHT entziehen.
Auch weitere Informationen zum Thema Betriebsausfall sind eher spärlich:
„Das gesamte System ist hochverfügbar ausgelegt. Aktuell verzeichnen wir auf unseren Vor-Produktiv System eine Verfügbarkeit von 100% für die letzten 90 Tagen. Bei einem Betriebsausfall werden vorbereitete Wiederherstellungsprozesse aktiviert.“
Und was passiert, wenn Microsoft anordnet, die Anwendung IES NG auf Azure auszuschalten für die Schweiz?
Die Antwort des BABS dazu folgt.
Übrigens: Wer noch Motivation für mehr Souveränität braucht: Der US-Präsident hat vor wenigen Tagen Spanien offen gedroht, alle Wirtschaftsbeziehungen abzubrechen. Das würde auch bedeuten, dass alle Cloud-Beziehungen gekappt würden. Das Szenario ist mit dieser Drohung nicht mehr so hypothetisch wie auch schon. Leider. Noch einmal ein Verweis auf das Briefing von letzter Woche: DNIP Briefing #63: Feldstecher und Angeln – Das Netz ist politisch
Update 30.3: Das BABS antwortete:
„Sollte Microsoft den Betrieb von IES NG auf Azure aus politischen oder technischen Gründen einstellen, ist die Kontinuität des Systems durch verschiedene Massnahmen sichergestellt, u.a. durch eine erfolgreich erprobte Exit-Strategie.
Die Anwendung basiert konsequent auf nicht-proprietären Technologien. Da keine Microsoft-spezifischen Spezialdienste verwendet werden, ist die Applikation technologisch nicht an Azure gebunden. Ein Wechsel zu einem anderen Cloud-Anbieter ist daher grundsätzlich ohne strukturelle Anpassungen möglich.
Der Aufbau und die Konfiguration des Systems sind vollständig automatisiert. Mittels Helm Charts kann das System in jedem kompatiblen Kubernetes-Cluster – auch bei anderen Cloud-Anbietern – automatisiert neu aufgebaut und gestartet werden.
Aufgrund der Sensibilität der zugrunde liegenden Sicherheitsarchitektur können derzeit keine weiterführenden technischen Details öffentlich gemacht werden.„
Auf die weitere Frage wie jetzt genau die ganze Schlüsselverwaltung vonstatten geht (selber generieren, und verwalten, doppelt verschlüsseln?), schrieb das BABS nochmals:
„Beim Aufbau der Umgebung wurden umfassende Sicherheitsmassnahmen umgesetzt. So wird IES NG ausschliesslich auf Servern in der Schweiz betrieben. Zudem verfügt das System über ein eigenes Key-Management. Die kryptographischen Schlüssel werden vom BABS selbst generiert und verwaltet. Dadurch wird sichergestellt, dass ausschliesslich das BABS Zugriff auf die entschlüsselten Daten hat. Auch der Cloud-Anbieter selbst hat keinen Zugriff auf diese Inhalte.„
11 Kommentare
Sollte das E-ID-Zeugs nicht in der Swiss Government Cloud laufen? Gibt es die noch gar nicht? Das soll doch noch dieses Jahr live gehen.
Sollte, gibt es aber noch nicht, Ausschreibung folgt erst im Sommer…dazu schreibe ich in einem Monat ungefähr auf republik.ch (was da los ist und zur E-ID generell)
Verstehe das Dilemma mit den Hyperscalern und den damit verbundenen Risiken einer Abschaltung aufgrund von US “Gesetzen”. Allerdings stellt sich mir die Frage, wie es denn aussähe, wenn alles Onprem betrieben würde. Bei dieser Betriebsvariante bestünden ja die gleichen Risiken, wenn US Hard- und Software eingesetzt würden. Oder wie siehst du das, Fabienne?
Woher die Hardware kommt, ist relativ egal. Je nach Software auch. Also, wenn die Software gekauft ist und nicht nur mit einer restriktiven Mietlizenz (und regelmässigem „Call-Home“) kommt, sollte sie auch gut weiterbetreibbar sein, wenn es den Hersteller nicht mehr gibt oder er nicht mehr willig ist.
Die Schweiz hat mit pCloud u.a einen top Cloud Anbieter (alles in der Schweiz). Bei einem Trump ist auch Microsoft nicht sicher.
pCloud gibt sich sehr bedeckt, was seine Eigentümer und Sicherheitsmassnahmen betrifft. Es ist ganz viel „Trust me!“ dabei. Für eine IT-Sicherheitslösung, der ich vertrauen soll, muss dieses Vertrauen auch geschaffen werden. Typische Mechanismen sind Transparenz und Verantwortungsübernahme. Beides war mangelhaft, als ich pCloud 2023 unter die Lupe nahm.
Falls sich da was geändert hat, wäre ich um Informationen froh.
In solchen Projekten ist der Speicher, bzw. „wo die Daten abgelegt sind“ nur eine Facette des ganzen Unterfangens.
Es geht vorallem auch darum, wo die ausgewählte Applikation läuft. Azure, AWS und co. sind sehr stark auf diesen Aspekt optimiert. Es ist dort vergleichsweise einfach eine Applikation mit hoher Redundanz und mit viel Leistung zu betreiben. (Eine Applikation ist heutzutage meistens eine „Website“ oder der Server einer App.)
D. h. die Daten würden somit auch in Azure verarbeitet, nicht, wie das mit pCloud der Fall zu sein scheint (ich kenn’s nicht), auf dem eigenen Notebook und danach in die Cloud gesynct.
Danke. Habe alles gelesen, auch wenn mein Hirn bald kaum mehr Kapazität hat… Es ist überwältigend, was heute alles gemacht wird, was wir eigentlich alles wissen sollten. Wahnsinn. Danke Dir!
Herzlichen Dank, liebe Christine!
Sehr gut geschrieben und interessant zum lesen. Gibt es hier aber vllt. ein Missverständnis?
Die Medienstelle sagt:
“ Zudem verfügt das System über ein eigenes Key-Management. Die kryptographischen Schlüssel werden vom BABS selbst generiert und verwaltet.”
Später schreiben Sie aber:
“ Wir erfahren nicht, ob die Schlüssel beim BABS liegen oder allein von Microsoft verwaltet werden.”
Ein beliebter Mechanismus ist die Nutzung von „Customer-Managed (Encryption) Keys“, abgekürzt CMK (Microsoft) oder CMEK (Google). Da werden die Schlüssel im Auftrag des Kunden oder durch den Kunden erzeugt (und können auch vom Nutzer jederzeit geändert werden), also „selbst generiert und verwaltet“. Sie liegen aber trotzdem in der Infrastruktur des Cloudproviders (durch Software oder Hardware geschützt) und der Cloudprovider kann sie bzw. daraus abgeleitete Schlüssel jederzeit auslesen, was auch zum korrekten Funktionieren nötig ist.
Zusätzlich gibt es noch die Funktion „Bring Your Own Key“ (BYOK), bei der der Kunde den Schlüssel selbst erzeugt und in Hardware des Cloudproviders importiert. Bei anderen Providern kann man auch sein eigenes Hardware Security Module (HSM) zur Schlüsselverwaltung einbinden. Aber auch in diesen Fällen kann der Cloudprovider jederzeit auf die Schlüssel zugreifen, die zur Ver- und Entschlüsselung der eigentlichen Daten notwendig sind.
Welche dieser Methoden gewählt wurde, verrät das BABS nicht. Aber ja, das könnte man vielleicht etwas klarer beschreiben. Aber dafür ist auch schon seit längerem ein eigener DNIP-Artikel geplant, der aber noch geschrieben werden muss. In der Zwischenzeit findet man z.B. hier mehr Informationen.