Falk Sippach
10.06.2021
Leuchtturmprojekt, Kostengrab, Hoffnungsträger und wichtiger Baustein in der Pandemiebekämpfung — das deutsche Corona-Warn-App-System (kurz CWA) stand in den letzten Monaten immer wieder im Rampenlicht. Während der Politik die Umsetzung nicht weit genug ging, hatte der Chaos Computer Club als großer Datenschutz-Verfechter an der Implementierung tatsächlich wenig auszusetzen. Organisatorisch wurde in kürzester Zeit ein Softwaresystem für viele Millionen Anwender geschaffen. Die Komplexität hielt sich zwar in Grenzen, der Schutz der persönlichen Daten, die Anforderungen an die Last/Performance und die Verfügbarkeit waren dafür um so größer. Preislich war die Umsetzung kein Schnäppchen, im Vergleich zu den allgemein hohen, durch die Corona Pandemie verursachten Kosten, ist das aber irgendwie auch fast wieder vernachlässigbar.
Mein Kollege Stefan Zörner und ich haben in einem Review die Softwarearchitektur der Corona-Warn-App unter die Lupe genommen. Im Rahmen dieses Blog-Posts möchte ich einige unserer Erkenntnisse teilen und auch einen Blick auf ausgewählte Stärken, Kompromisse und Risiken der gewählten Ansätze werfen. Weitere Details gibt es in unseren Vorträgen beim embarc Architektur Midsommar am 24.06.2021:
Auf der offiziellen Webseite steht:
Die Corona-Warn-App ist eine App, die hilft, Infektionsketten des SARS-CoV-2 (COVID-19-Auslöser) in Deutschland nachzuverfolgen und zu unterbrechen. Die App basiert auf Technologien mit einem dezentralisierten Ansatz und informiert Personen, wenn sie mit einer infizierten Person in Kontakt standen. Transparenz ist von entscheidender Bedeutung, um die Bevölkerung zu schützen und die Akzeptanz zu erhöhen.
Dazu tauschen unsere Smartphones über Bluetooth ständig Informationen in Form von Schlüsseln aus und protokollieren so anonym den Kontakt zu anderen Personen. Hat man sich infiziert, kann man über die App alle warnen, denen man in den letzten 14 Tagen näher gekommen ist. Und das, ohne sich gegenseitig zu (er)kennen. Der Schutz der persönlichen Daten steht aus unserer Sicht an höchster Stelle. Technisch basiert diese Vorgehensweise auf einem Paper diverser Universitäten und Forschungseinrichtungen: Decentralized Privacy-Preserving Proximity Tracing.
Darauf aufbauend haben Google und Apple, mit ihren Betriebssystemen Android und iOS die Platzhirsche im Bereich der mobilen Geräte, gemeinsam die Exposure Notification Bluetooth Specification erarbeitet und jeweils ein Framework für Ihre Plattform und auch Referenzimplementierungen zur Verfügung gestellt. Durch die deutsche Bundesregierung gemeinsam mit dem Robert-Koch-Institut wurde daraufhin im April 2020 ein Konsortium aus SAP und Deutsche Telekom damit beauftragt, die nativen Corona-Warn-Apps und die zugehörige Server-Infrastruktur zu entwickeln und in der Open Telekom Cloud zu betreiben. Bereits im Juni 2020 ging das System live und man konnte die CWA aus den App-Stores beziehen.
Für ein IT-Projekt sehr sportlich wurde in wirklich extrem kurzer Zeit ein großes Softwaresystem mit sehr hohen Anforderungen (Qualitätsziele) an die Sicherheit (Schutz persönlicher Daten), die funktionale Eignung (effektive Warnfunktionalität) sowie die Zuverlässigkeit (Skalierbarkeit und Ausfallsicherheit) geschaffen. Durch intuitive Bedienkonzepte, eine aufgeräumte UI und die Unterstützung auch älterer Geräten konnte zudem eine relativ hohe Akzeptanz in der Bevölkerung erreicht werden. Immerhin wurden die Apps bis heute über 28 Millionen mal heruntergeladen. Zum Vergleich, es sind schätzungsweise 60 Millionen Smartphone in Deutschland in Benutzung.
Am Anfang haben viele gehofft, dass die Pandemie nach wenigen Wochen oder Monaten bereits wieder vorüber ist. Nach über einem Jahr wissen wir aber, dass Corona trotz großen Fortschritten bei den Impfungen unser Leben auch in den nächsten Jahren noch beeinflußen wird. Darum ist es bemerkenswert, dass man insbesondere bei der Server-Implementierung der Corona-Warn-App auf eine sinnvolle Modularität in Form von Microservices gesetzt hat. Das zahlt unter anderem auf die Erweiter- und Wartbarkeit ein und so konnten in den letzten Monaten viele weitere, nützliche Funktionen hinzugefügt werden.
Dazu zählen der digitale und automatisierte Abruf und das Speichern von Ergebnissen aus Testlaboren und -zentren (sowohl PCR- als auch Schnell-Tests), so dass man die App als Nachweis vorzeigen kann. Nutzer haben außerdem die Möglichkeit, aktuelle Daten zur Pandemie einzusehen bzw. können selbst anonyme Informationen zur eigenen Person für die statistische Auswertung an das Robert-Koch-Institut übertragen. Bei Besuchen in Restaurants, Geschäften oder bei Veranstaltungen kann man sich zudem anonym per QR-Code registrieren und so helfen, mögliche Infektionsketten zusätzlich zum Mechanismus über Bluetooth (Exposure Notification Framework) nachzuverfolgen. Weitere Features stehen bereits in den Startlöchern, aktuell wird die Integration des digitalen Impfnachweises ausgerollt.
Neben den Qualitätszielen, welche die Treiber für die Wahl der Lösungsansätze sind, gibt es noch Rahmenbedingungen. Das sind organisatorische oder technische Vorgaben, die wie Leitplanken den Lösungsraum einschränken. Technisch vorgegeben waren zum Beispiel der Einsatz des Exposure Notification Frameworks von Google bzw. Apple und die damit notwendige Entwicklung von nativen mobilen Clients für Android und iOS. Um eine hohe Akzeptanz in der Bevölkerung zu erreichen, stand zudem der Schutz der personenbezogenen Daten im Vordergrund. Der dezentrale Ansatz für die Datenspeicherung war aus unserer Sicht dementsprechend ebenfalls eine Vorgabe und keine Entscheidung des Entwicklungs-Teams. Für den Betrieb der Backend-Komponenten hat man sich auf die Open Telekom Cloud und damit auf Werkzeuge wie OpenStack, OpenShift/Kubernetes und Docker festgelegt.
Organisatorisch herausfordernd war neben der enormen Medienaufmerksamkeit bzw. der anfänglichen Skepsis in der Bevölkerung, der hohe politische Druck und natürlich der sehr enge Zeitrahmen (Start der Entwicklung im April, Verfügbarkeit in den App-Stores bereits im Juni 2020). Die Umsetzung wurde zudem von zwei Auftragnehmern (SAP und Deutsche Telekom) übernommen, was einen höheren Koordinationsaufwand nach sich zog.
Der System-Kontext liefert einen ersten High-Level-Überblick auf das Gesamtsystem als Blackbox mitsamt den wichtigsten Akteuren und die Anbindung an Fremdsysteme. Neben den App-Nutzern sind das die Verifikations-Hotline, die Gesundheitsämter bzw. Testlabore/-zentren, das RKI und die Anbindung an die Systeme anderer Staaten. Zukünftig könnten hier beispielsweise noch Impfzentren oder ein zentrales Impfregister hinzukommen.
In der Lösung spiegeln sich natürlich die hoch priorisierten Qualitätsziele wieder. So hat man sich für den Schutz der persönlichen Informationen grundsätzlich für das möglichst sparsame Sammeln von Daten entschieden. Es werden nur die wirklich notwendigen Informationen gespeichert und wieder gelöscht, wenn sie nicht mehr relevant sind. Auf dem Server sind zudem nur die Informationen abgelegt, die für die Warnfunktionalität bzw. für Schnittstellen zu Fremdsystemen benötigt werden. Alles weitere erfolgt dezentral auf unseren Smartphones. Alle personenbezogenen Daten werden außerdem verschlüsselt und das Teilen von Informationen erfolgt nur nach expliziter Zustimmung durch die Anwender. Durch die hohe Transparenz in der Entwicklung (einsehbare Konzepte bzw. Dokumentation und Quellcode auf Github) können sich alle Interessierten entsprechend informieren. Probleme können so öffentlich debattiert und kritische Punkte schnellstmöglich korrigiert werden.
In unserem informellen Überblicksbild finden sich weitere Lösungsansätze wieder. Wir freuen uns darauf, die Details mit Euch bei unseren Vorträgen beim Architektur Midsommar zu diskutieren.
Gut zu erkennen sind die fachlichen Schnitte im Backend. Die folgende Tabelle zeigt die Aufgaben der einzelnen Systemteile:
| Systemteil | Aufgabe |
|---|---|
| CWA Server | Nimmt die Diagnoseschlüssel positiv getesteter Nutzer entgegen und teilt sie mit anderen Nutzern über ein CDN. Interagiert mit den Kontaktverfolgungen anderer Länder („Federation“). |
| Testresult Server | Empfängt und speichert die Testergebnisse von angeschlossenen Laboren. |
| Verification Server | Sichert ab, dass ein Nutzer zugestimmt hat, seinen positiven Test zu melden, und dass das Labor tatsächlich positiv getestet hat. |
| Verification Portal | Ermöglicht die Erzeugung von teleTANs im Verification Server über ein einfaches Browser-Frontend. |
| PPA bzw. Data Donation Server | Nimmt Nutzerdaten bei aktivierter Datenspende entgegen und speichert sie, ohne Rückschlüsse auf individuelle Personen zuzulassen. (PPA = Privacy Preserving Analytics) |
Auf dem öffentlich verfügbarem Quellcode kann man sehr gut verschiedenste Metriken berechnen lassen. Auf der folgenden Treemap entspricht die Fläche der Kacheln der Anzahl der Codezeilen des jeweiligen Repositories und die Farbe verweist auf die Programmiersprache. Interessant ist, dass die Backend-Komponenten im Vergleich zu den Apps deutlich kleiner sind.
Bei unserem Architektur-Review haben wir die Qualitätsmerkmale durch Szenarien konkretisiert. Anhand dieser Szenarien konnten wir dann die Softwarearchitektur-Entscheidungen analysieren und als Ergebnisse die Stärken, mögliche Risiken und Kompromisse herausarbeiten.
Die folgende Tabelle zeigt für ausgewählte Lösungsansatze die interessanten Kompromisse:
| Explizite Freigabe positiver Testergebnisse durch Nutzer/in erforderlich | |
| 👍 erhöht Vertrauen in die Lösung | 👎 reduziert effektive Warnfunktionalität |
| Verteilte Anwendung auf dem Backend | |
| 👍 gut für Datenschutz (Trennung der Daten) | 👎 schwieriger zu entwicklen und zu betreiben |
| 👍 verfügbar(er) im Falle von Teilausfällen | |
| Ausliefern der Diagnoseschlüssel über CDN im Batch, Aktualisierung durch Apps in Intervallen | |
| 👍 spart Ressourcen, vor allen an den Endgeräten | 👎 Zeitverzögerung bei Risikoermittlung |
| 👍 robust, erhöht Zuverlässigkeit | |
explizite Einwilligung der Nutzerin erforderlich (-) Benutzbarkeit (+) Datenschutz
Testlabore können Ergebnisse digital übermitteln (+) schneller und weniger fehleranfällig (-) hoher technischer Aufwand für die Labore, nicht alle sind angeschlossen (-) Verzögerungen/Probleme bei der Übermittlung des Testergebnisses führen ggf. nicht zur Freigabe der Warnmeldung
Offenlegung des Quelltextes (+) schafft Vertrauen (-) zeigt ggf. Schwachstellen auf
Gesundheitsämter haben keinen direkten Zugriff auf personenbezogene Daten (+) keine Bevormundung/Überwachung (-) Staat ist auf freiwillige Mithilfe angewiesen Keine Möglichkeit, in den letzten Tagen getroffene Personen zu ermitteln (Pull, kein Push) (-) Kontakte muss jeder selbst dokumentieren (+) CWA bietet ein digitales Kontakt-Tagebuch an
Wirksamkeit wegen hohen Datenschutzanforderungen zu gering? (+) Chaos Computer Club lobt die CWA explizit (-) Politiker möchten den Datenschutz für eine bessere Wirkung opfern eingeschränkte Möglichkeiten zur Auswertung der Benutzung (+) Datenschutz (-) Interessante Statistiken zur Nutzung nicht möglich
Wenn Euch dieser Artikel neugierig gemacht hat und ihr mehr über die Corona-Warn-App erfahren möchtet, dann schaut sehr gern auf unserem Architektur Midsommar vorbei. Neben den Vorträgen zur Architektur der CWA haben wir natürlich weitere spannende Themen im Programm, z. B. zu Enterprise Architekturen in sich rasch wandelnden Märkten, Daten-Konsistenz in hochskalierenden und -verfügbaren Umgebungen, Machine Learning im Umfeld von Regressionstests, Mitarbeiterbeteiligung für echte Partizipation in New Work, Mob-Programmung zur Unterstützung bei der Entscheidungsfindung in Teams, moderne Analysetechniken zum Aufdecken der Diskrepanz zwischen Anwendungsarchitektur und Kommunikationsstrukturen und natürlich auch klassische bzw. moderne Architekturansätze wie Microservices oder der Schnitt von Domänenmodellen.
Zur Anmeldung für den Architektur-Midsommar 2021
Wir freuen uns auf Euren virtuellen Besuch. Und bei Fragen oder Anmerkungen könnt Ihr uns natürlich auch jederzeit per Email oder über unser Kontakt Formular ansprechen.