Architektur-Porträt: Corona-Warn-App

Mit dem ersten Infektionsfall in Bayern begann Ende Januar 2020 offiziell die Ausbreitung des neuartigen Coronavirus SARS-CoV-2 in Deutschland. Schon früh wurden sogenannte Corona-Apps als eine Möglichkeit der Kontaktverfolgung und damit als ein Mittel zur Unterbrechung von Infektionsketten diskutiert. Die deutsche Corona-Warn-App stand im Juni 2020 zum Download bereit. Dieser Beitrag diskutiert die wesentlichen Ziele und zentralen Lösungsansätze des Systems.

Steckbrief: Corona-Warn-App

Name: Corona-Warn-App
Software-Gattung: Contact-Tracing
Veröffentlicht: Juni 2020
Herkunft/Ursprung: Deutsche Bundesregierung, Open Source
Zielplattform: Native App auf Android und iOS, Backend in Public Cloud
Programmiersprache(n): Kotlin (Android App), Swift (iOS App), Java (Backend)
Homepage: www.coronawarn.app

Nomen est Omen. Im Kern macht die Corona-Warn-App (kurz CWA) genau das, was der Name sagt: sie warnt. Wie funktionieren solche Lösungen? Vereinfacht erkennen die Smartphones der Nutzerinnen und Nutzer Begegnungen untereinander und zeichnen sie auf. Sollte später jemand positiv auf Corona getestet werden, teilt er oder sie diese Information über die App. Frühere Kontakte werden über diese „Risikobegegnungen“ informiert sowie aufgefordert, sich zu isolieren und sich ebenfalls testen zu lassen. Die Warnungen sollen dabei helfen, Infektionsketten zu unterbrechen. Anders als der Name „App“ suggeriert, ist neben den Apps selbst auch noch ein Backend für den Informationsaustausch im Spiel.

Je nach Implementierung wäre bei einer solchen Software im Extremfall das Anfertigen von Bewegungsprofilen oder das Ausspähen von Gesundheitsdaten möglich. Der Chaos-Computer-Club hat entsprechende Systeme daher bereits früh als Risikotechnologie eingestuft und Prüfsteine formuliert, die er als Mindestmaß für solche Anwendungen sieht [CCC20]. In der Diskussion kristallisierte sich für die Umsetzung in Deutschland (wie auch in den meisten anderen europäischen Ländern) ein sogenannter dezentraler Ansatz heraus [Tag20], bei dem (anonyme) Kontaktinformationen nur auf den Endgeräten der Benutzer abgelegt werden, und nicht an einer zentralen Stelle – eine wichtige Forderung in den Prüfsteinen des CCC.

Neben dieser entscheidenden Vorgabe waren die Implementierung nativer Apps für Android und iOS und der Betrieb des Backends in Rechenzentren deutscher Provider innerhalb Deutschlands technische Rahmenbedingungen der Bundesregierung für das beauftragte Projekt-Team von SAP und Telekom. Auch das von Apple und Google entwickelten Exposure Notification Framework [GAEN20] war gesetzt. Hierbei handelt es sich um ein System, das als Teil der jeweiligen Smartphone-Betriebssysteme der beiden großen Hersteller den Austausch von Zufallsschlüsseln über Bluetooth Low Energy (BLE) ermöglicht. Es stellt das Rückgrat für das Erkennen der Begegnungen dar.

Im April 2020 legten die Entwicklungsteams los. Und zwar, für eine deutsche Vergabe aus öffentlicher Hand mehr als ungewöhnlich, in Public Repositories auf GitHub [Git]. Abbildung 1 zeigt die Homepage des Open Source Projektes der Corona-Warn-App.

Tabelle 1 stellt wichtige Architekturziele der Corona-Warn-App vor. Die Reihenfolge gibt eine grobe Orientierung bezüglich ihrer Wichtigkeit. Wie sieht die Lösung aus?

Ziel	Beschreibung (und zugehöriges Software-Qualitätsmerkmal)
Effektive Warnfunktionalität	Die App ist ein effektiver Baustein bei der Pandemie-Bekämpfung. Kontakte positiv getesteter Personen werden umgehend informiert, Infektionsketten so gebrochen. (Funktionale Eignung)
Höchster Datenschutz	Eine IT-gestützte Kontaktverfolgung birgt aufgrund möglicherweise erfasster Kontakt- und Gesundheitsdaten ein hohes Risiko. Der Schutz dieser Daten hat oberste Priorität, Alarmierungen erfolgen grundsätzlich dezentral und anonym. (Sicherheit)
Attraktive Lösung für App-Nutzer	Die App ist auch von technisch wenig versierten Personen leicht zu installieren sowie intuitiv und effizient zu bedienen. Ressourcen des Endgerätes wie Bandbreite, Batterie und Speicherplatz nutzt die App sparsam. (Benutzbarkeit)
Hohe Zuverlässigkeit	Die Lösung geht mit Lastspitzen wegen hoher Nutzer- oder Infektionszahlen ebenso souverän um, wie mit Störungen und böswilligen Angriffen. Die App arbeitet stets ohne Beeinträchtigungen. (Zuverlässigkeit)
Gute Wartbarkeit	Die Software lässt sich leicht anpassen oder um neue Funktionalität erweitern, wenn z. B. Nutzer/-innen, Politik oder neue Forschungsergebnisse es erfordern. Neue Teammitglieder finden sich rasch zurecht. (Wartbarkeit, Erweiterbarkeit)

Abbildung 2 zeigt einen informellen Architekturüberblick der Gesamtlösung. Die Apps auf den Smartphones kommunizieren untereinander mit Bluetooth (BLE) und zusätzlich in Client-Server-Manier mit einem in Java realisierten Backend auf der Open Telekom Cloud. Die App-Nutzer/innen erhalten Informationen über mögliche Begegnungen mit infizierten Personen. Sie verifizieren eigene Testergebnisse und warnen so freiwillig andere. Die Verifikations-Hotline unterstützt App-Nutzer/innen bei der Freischaltung positiver Testergebnisse (“teleTAN”). Gesundheitsämter und Testlabore liefern anonymisierte Testergebnisse an das System. Das Robert Koch-Institut (kurz RKI) stellt Inhalte (“Content”) für die App zur Verfügung und bestimmt Parameter für die Messung der Kontakte (“Risiko-Ermittlung”). Darüber hinaus empfängt das RKI Auswertungen, etwa aus der freiwilligen Datenspende. Der Austausch mit dezentralen Anwendungen anderer Länder ermöglicht die grenzüberschreitende Ermittlung von Begegnungen.

Zentrale Lösungsansätze

Mit welchen Lösungsansätzen erreicht die CWA die Ziele aus Tabelle 1? Die Implementierung nativer Apps für Android-Geräte und iPhones und die Verwendung des Exposure Notification Frameworks von Google und Apple garantiert die Unterstützung der gängigsten Smartphones (mehr als 90% aller Geräte), was für eine effektive Warnfunktionalität mitentscheidend ist. Weiterhin sind digitale Abläufe zur Risikowarnung einer „manuellen“ Kontaktverfolgung durch die Gesundheitsämter naturgemäß überlegen.

Microservices als Architektstil

Der dezentrale Ansatz unterstützt einen hohen Datenschutz. Die Speicherung der (anonymen) Kontaktdaten in Form von Zufallsschlüsseln erfolgt lokal beim App-Nutzer. Und nach dem Prinzip der Datensparsamkeit werden nur die minimal notwendigen Informationen erhoben und verarbeitet. Durch die transparente Entwicklung als Open Source – neben den Quelltexten sind auch Konzepte und Anforderungen (User Journey, Epics, …) auf GitHub einsehbar – ist die Implementierung durch Dritte überprüfbar. Um das Vertrauen der Nutzerinnen und Nutzer zu erhöhen, erfolgt das Teilen von Daten durch die App – insbesondere die Informationen über einen positiven Test – erst nach expliziter Zustimmung.

Native Apps für iOS und Android, verteilt über die jeweiligen Stores, stellen eine niedrige Hürde für viele App-Nutzer/innen dar. Die Oberflächen sind übersichtlich gestaltet, die Bedienung simpel. Die Entwicklungsteams haben auf einen geringen Ressourcen-Verbrauch der Apps (Akku, Netzwerk) geachtet, damit Nutzer sie nicht sofort wieder deinstallieren.

Der dezentrale Ansatz sorgt neben der Vertraulichkeit zusätzlich für ein robustes Gesamtsystem. Denn das wichtige Erfassen der Begegnungen durch die Apps kann ohne Verbindung zum serverseitigen Backend auf der Cloud erfolgen. Darüber hinaus sehen wir in Abbildung 2 die Zerlegung des Backends in unabhängige, separat skalierbare Teile mit jeweils eigener Datenhaltung nach Microservices-Manier. Diese Backend-Anteile sind durchgängig in Java mit Spring Boot realisiert. Diese Entscheidung spielt für die Lösung aber eine untergeordnete Rolle. Orchestriert wird das Ganze in Kubernetes, für die Datenbanken kommt PostgreSQL zum Einsatz. Der CWA-Server verteilt die von den Apps zu lesenden Daten über ein Content Delivery Network. Bei vielen positiven Testergebnissen muss da einiges bewegt werden. Denn wegen des dezentralen Ansatzes geschieht der Abgleich eines jeden positiven Testergebnisses (genauer: der damit verbundenen Schlüssel) auf allen Endgeräten.

Die Corona-Warn-App wurde in kurzer Zeit entwickelt und stand bereits im Juni 2020 zum Download bereit. Das legt die Befürchtung nahe, dass die Software mit der heißen Nadel gestrickt wurde und Änderbarkeit sowie Erweiterbarkeit hintenanstehen mussten. Tatsächlich lassen sich aber auch für die Wartbarkeit Lösungsansätze identifizieren. Die Entwicklung als Open Source ermöglicht hier Einblicke und wirkt sich selbst positiv auf die Quelltext-Qualität aus. Die Verwendung verbreiteter Standard- und Open-Source-Bibliotheken reduziert Entwicklungsaufwände und erleichtert Neuen im Team sowie interessierten Außenstehenden den Einstieg. Die Umsetzung des Backends in separate Server ermöglicht ein kollisionsarmes Hinzufügen weiterer Funktionalität durch neue Vertikalen, wie beispielsweise im März 2021 mit der Datenspende (siehe Data Donation Server in Abbildung 2) geschehen. Tatsächlich haben Updates und neue Features nach anfänglicher Stagnation deutlich zugenommen. Neben dem lokalen Kontakt-Tagebuch und der Anzeige ausgewählter Kennzahlen zum Infektionsgeschehen kamen die Event-Registrierung, das Einchecken mit QR-Code und die Erkennung sogenannter Cluster hinzu. Schnelltestergebnisse (neben PCR) wurden ebenso integriert wie die Anzeige des digitalen Impfnachweises.

Fazit

Die Corona-Warn-App erfüllt ihren Zweck. Aber ist sie ein Erfolg? Die Bewertung ist schwierig. Das RKI und das CWA-Projekt veröffentlichen zwar regelmäßig Statistiken, etwa zu den Download-Zahlen der App oder den eingespielten und geteilten Testergebnissen (Kennzahlen siehe z.B. [CWA]). Aussagen über die Anzahl der von der App ausgesprochenen Warnungen (rote vs. grüne Kacheln, siehe Abbildung 4) sind aufgrund des datenschutzfreundlichen Ansatzes nicht verlässlich möglich. Noch weniger gilt das für unterbrochene Infektionsketten (für eine Schätzung des RKI siehe [Hei21]). Ein häufiger Kritikpunkt sind die hohen Entwicklungs- und Betriebskosten (laut Bundesregierung in den Jahren 2020 und 2021 in Summe ca. 130 Millionen Euro [BR22]).

Gleichwohl rechtfertigt die Strahlkraft des Projektes meiner Meinung nach ein Porträt in dieser Reihe. Das Vertrauen und die Akzeptanz in der Bevölkerung waren entscheidende Faktoren. Die transparente Entwicklung als Open Source – für eine von öffentlicher Seite in Deutschland beauftragte Software in dieser Größenordnung bisher einmalig – und die vorbildliche Umsetzung des Datenschutzes dienen hoffentlich als Modell für die Zukunft.

Weiterführende Informationen

[BR22] Antwort der Bundesregierung, Drucksache 20/431, Januar 2022
[CCC20] Chaos Computer Club: “10 Prüfsteine für die Beurteilung von Contact Tracing-Apps”, April 2020
[CWA] Corona-Warn-App (CWA): Kennzahlen .
[GAEN20] Google, Apple: Exposure Notification Bluetooth Specification, April 2020
[Git] Die Corona-Warn-App auf GitHub: github.com/corona-warn-app
[Hei21] Heise-News vom 14.06.2021: “RKI-Schätzung: Corona-Warn-App hat über 100.000 Infektionsketten unterbrochen”
[Sip+21] Falk Sippach, Stefan Zörner: „So gehen Architektur-Reviews! Die deutsche Corona-Warn-App unter der Lupe”, Vortrag auf der OOP 2021
[Tag20] Beitrag Tagesschau vom 26.04.2020: “Bundesregierung setzt bei Corona-App auf dezentrale Datenspeicherung”, Video (2 min)

Dieses Porträt ist ursprünglich in der IT Spektrum, Ausgabe 6 | 2022 als dritter Teil einer Reihe über Architektur-Ikonen der Softwareentwicklung erschienen. Rückmeldungen aller Art gerne an mich per E-Mail. Insbesondere auch Wünsche für weitere Porträts.

Mehr im embarc-Blog. Das könnte Sie auch interessieren:

Architektur-Porträt: Das Spring Framework
Architektur-Porträt: Die Programmiersprache Go
Architekturikonen in Software Überblick über alle Porträts