Java Softwarearchitektur Anwendungssoftware IT-Sicherheit

Microservices unter der Lupe

Das deutsche Corona-Warn-App-System besteht nicht nur aus den prominenten nativen Apps. Zur Umsetzung von Use-Cases wie der persönlichen Risikoermittlung oder dem Melden von (positiven) Testergebnissen gehört auch eine mehrteilige Server-Lösung. Sie basiert auf einem zeitgemäßen Architekturstil, einem aktuellen Technologie-Stack und wurde unter hohem Zeitdruck realisiert. Dieser Artikel diskutiert die prägenden architekturrelevanten Anforderungen, die getroffenen Entscheidungen und bewertet die gewählten Lösungsansätze.

Falk Sippach

Author

24.09.2021
Lesezeit: 13 Minuten
46 Views

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, die Anforderungen an den Schutz der persönlichen Daten, die Last/Performance und die Verfügbarkeit waren dafür umso größer. Gemeinsam mit meinem Kollegen Stefan Zörner habe ich in einem Review die Softwarearchitektur der Corona-Warn-App unter die Lupe genommen.

Ziele der Corona-Warn-App

Auf der offiziellen Webseite [CWA2020] findet sich das Mission Statement:

„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."

Des Weiteren liefert der Systemkontext (s. Abb. 1) 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 beziehungsweise Testlabore/-zentren, das RKI und die Anbindung an die Systeme anderer Staaten. Tabelle 1 erläutert die Akteure des Systemkontextes.

Abb. 1: Systemkontext

Tabelle 1: Erläuterungen zum Systemkontext
App-Nutzer/in	Erhält Informationen über mögliche Begegnungen mit infizierten Personen und eigene Testergebnisse. Verifiziert eigene Testergebnisse und warnt so freiwillig andere.
Verifikations-Hotline	Unterstützt App-Nutzer/innen bei der Freischaltung positiver Testergebnisse ("teleTAN").
Ausländische Kontaktverfolgungen	Austausch mit dezentralen Anwendungen anderer Länder zur grenzüberschreitenden Ermittlung von Kontakten.
Robert Koch-Institut (RKI)	Stellt Content für die App zur Verfügung und bestimmt Parameter für die Risiko-Ermittlung. Empfängt Auswertungen, etwa aus der Datenspende.
Gesundheitsämter und Testlabore	Liefern anonymisierte Testergebnisse an das System.

Funktionsweise

Um die fachliche Hauptanforderung, die Warnfunktionalität, zu erreichen, tauschen Smartphones über Bluetooth ständig Informationen in Form von Schlüsseln aus und protokollieren so anonym Begegnungen mit anderen Personen. Bei einer Infizierung können über die App alle Kontaktpersonen gewarnt werden, die dem Benutzer in den letzten 14 Tagen nähergekommen sind. Und das, ohne sich gegenseitig zu (er)kennen. Der Schutz der persönlichen Daten hat nämlich ebenfalls sehr hohe Priorität. Es sollen keine Rückschlüsse auf personenbezogene Informationen möglich sein.
Die anonymen Schlüssel aller Infizierten, die ihr positives Testergebnis geteilt haben, werden zentral über ein CDN zur Verfügung gestellt, regelmäßig auf die Smartphones heruntergeladen und wiederum mit den gespeicherten Keys der eigenen Begegnungen abgeglichen. Sollte es einen Treffer geben, wird unter Einbezug weiterer Parameter (Entfernung, Dauer des Kontakts) das persönliche Risiko abgeschätzt und in der App angezeigt.

Technisch basiert diese Vorgehensweise auf einem Paper von verschiedenen Universitäten und Forschungseinrichtungen (s. Abb. 2). Im Kasten zum Whitepaper finden sich weitere Informationen zum Decentralized Privacy-Preserving Proximity Tracing [DP3T2020].

Abb. 2: Beteiligte Institutionen am Decentralized Privacy-PreservingProximity Tracing Whitepaper

Aufbauend auf den Forschungsergebnissen haben Google und Apple, mit ihren Betriebssystemen Android beziehungsweise iOS die Platzhirsche im Bereich der mobilen Geräte, gemeinsam die Exposure Notification Bluetooth Specification erarbeitet (siehe [ENBS2020]) und jeweils ein Framework für ihre Plattform und auch Referenzimplementierungen zur Verfügung gestellt. Die deutsche Bundesregierung hat gemeinsam mit dem Robert Koch-Institut im April 2020 ein Konsortium aus SAP und Deutsche Telekom damit beauftragt, die nativen Corona-Warn-Apps sowie 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.

Tabelle 2: Entscheidende Qualitätsmerkmale sortiert nach Wichtigkeit
Ziel	Beschreibung
Höchster Datenschutz	Der Schutz der personenbezogenen Daten hat oberste Priorität. (Sicherheit)
Effektive Warnfunktionalität	Die App ist ein effektiver Baustein bei der Pandemie-Bekämpfung. (Funktionale Eignung)
Attraktive Lösung für App-Nutzer	Die App ist leicht zu installieren sowie intuitiv und effizient zu bedienen. (Benutzbarkeit)
Hohe Zuverlässigkeit	Die Lösung geht mit Lastspitzen wegen hoher Nutzer- oder Infektionszahlen ebenso souverän um wie mit böswilligen Angriffen. (Zuverlässigkeit)
Gute Änderbarkeit	Die Software lässt sich leicht anpassen, wenn z. B. Nutzer/-innen oder neue Forschungsergebnisse es erfordern. (Wartbarkeit/Erweiterbarkeit)

Einflüsse auf Architekturentscheidungen

Für ein IT-Projekt sehr sportlich wurde in extrem kurzer Zeit ein großes Softwaresystem mit äußerst 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äte konnte zudem eine hohe Akzeptanz in der Bevölkerung erreicht werden (s. Tabelle 2). Immerhin wurden die Apps bis Anfang Juli 2021 bereits 30 Millionen Mal heruntergeladen. Zum Vergleich, es sind schätzungsweise 60 Millionen Smartphones in Deutschland in Benutzung.

Am Anfang haben viele gehofft, dass die Pandemie nach wenigen Wochen oder Monaten wieder vorüber ist. Nach über einem Jahr wissen wir aber, dass Corona unser Leben auch in den nächsten Jahren noch begleiten wird. Und dass trotz der großen Fortschritte bei den Impfungen. Darum ist es bemerkenswert, dass man insbesondere bei der Server-Implementierung der Corona-Warn-App auf eine sinnvolle Modularisierung in Form von Microservices gesetzt hat. Das zahlt unter anderem auch 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 Testergebnissen. Die App lässt sich somit wunderbar als Nachweis vorzeigen. Nutzer haben außerdem die Möglichkeit, ein Kontaktverfolgungstagebuch zu pflegen, aktuelle Daten zur Pandemie einzusehen, und 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. Vor den Sommerferien wurde auch noch die Integration des digitalen Impfnachweises ausgerollt. Und weitere Features stehen in den Startlöchern. Außerdem wird aufgrund der Virus-Varianten der Algorithmus zur Berechnung des Risiko-Status regelmäßig angepasst (siehe [CWABLOG2021]).

Neben den Qualitätszielen als wesentliche Treiber für die Architekturentscheidungen waren bei der Entwicklung noch gewisse Rahmenbedingungen zu beachten. Das sind organisatorische oder technische Einflüsse, die wie Leitplanken den Lösungsraum einschränken.

Technische Vorgaben:

Entwicklung von nativen, mobilen Clients für Android- und iOS-Smartphones
Verfolgen eines dezentralen Ansatzes für die Datenspeicherung
Einsatz des Exposure Notification Framework von Google und Apple
Betrieb der Backend-Komponenten in der Open Telekom Cloud

Organisatorischer Rahmen und Umfeld:

Auftraggeber: Deutsche Bundesregierung
Entwicklung und Betrieb durch ein Konsortium aus zwei Auftragnehmern (SAP und Deutsche Telekom)
Start der Entwicklung 04/2020
enger Zeitrahmen (Apps verfügbar ab 06/2020)
hoher politischer Druck
viele Parteien involviert (Ministerien, Behörden, RKI, ...)
große Medienaufmerksamkeit
gewisse Skepsis innerhalb der Bevölkerung

Entscheidende Lösungsansätze

In der Lösung spiegeln sich die hoch priorisierten Qualitätsziele wider. Die nachfolgend genannten Prinzipien, Muster, Konzepte und Technologien begünstigen deren Erreichung. So hat man sich zum Schutz der persönlichen Informationen grundsätzlich für das möglichst sparsame Sammeln von Daten entschieden. Es werden nur die notwendigen Informationen gespeichert und wieder gelöscht, wenn sie nicht mehr relevant sind. Auf dem Server sind zudem nur die Daten abgelegt, die für die Warnfunktionalität beziehungsweise für Schnittstellen zu Fremdsystemen benötigt werden. Alles Weitere erfolgt dezentral auf den 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 zudem alle Interessierten entsprechend informieren. Probleme können so öffentlich debattiert und kritische Punkte schnellstmöglich korrigiert werden.

Durch die digitalen Abläufe zur Risikowarnung konnten laut Hochrechnungen immerhin zwischen 110.000 und 230.000 Personen nach einer roten Warnung positiv getestet, isoliert und die Infektionsketten damit unterbrochen werden (siehe [HEISE2021]). Das entspricht in etwa der Positiv-Rate, die bei der analogen Kontaktnachverfolgung durch alle Gesundheitsämter zusammen beobachtet wurde. Möglich macht dies vor allem der Einsatz der durch das Betriebssystem angebotenen Schnittstelle des Exposure Notification Frameworks. Apple und Google haben durch Rückportierungen dafür gesorgt, dass auch ältere und somit etwa 90 Prozent aller Geräte unterstützt werden.

Durch den geringen Ressourcen-Verbrauch (unter anderem durch Bluetooth Low Energy und die allgemeine Datensparsamkeit), die übersichtliche Gestaltung sowie die einfache Bedienung sind die nativen Apps für möglichst viele Nutzer attraktiv und laufen im normalen Alltag im Hintergrund unauffällig und trotzdem zuverlässig mit. Die Verteilung durch die jeweiligen Stores lässt zudem die Einstiegshürde sinken.

Eine hohe Zuverlässigkeit wird durch die Modularisierung und die damit leicht skalierbare Servicelandschaft sichergestellt. Die Services werden in der Public Cloud (Open Telekom Cloud) als in Kubernetes orchestrierte Docker Container betrieben. Bei bestimmten Anwendungsfällen erfolgt eine entkoppelte oder asynchrone Kommunikation, zum Beispiel beim Abruf der Schlüssel zu Begegnungen mit Infizierten von einem Content Delivery Network (CDN). Die Apps können zudem die Begegnungen vollkommen autark ohne Verbindung zum Backend (offlinefähig) erfassen und somit auch den temporären Ausfall von einzelnen Services verkraften.

Die gute Wartbarkeit wurde durch die fachlich getriebene Zerlegung in Microservices mit jeweils separater Datenhaltung sowie die Verwendung verbreiteter Standard- beziehungsweise Open-Source-Bibliotheken sichergestellt. Zudem wird der Quellcode der CWA selbst quelloffen entwickelt und es wird eine ausführliche Dokumentation zur Verfügung gestellt. Die Code-Qualität wird zudem tool-unterstützt überwacht.

Zerlegung der Backend-Services

Abbildung 3 zeigt die wichtigsten Bausteine auf der obersten Ebene gemäß der Struktur des Quelltextes (siehe Repositories bei [GITHUB]). Die Pfeile zeigen Abhängigkeiten, A -> B bedeutet „A verwendet B". Gut zu erkennen sind die fachlichen Schnitte. Tabelle 3 erklärt die Verantwortlichkeiten der einzelnen Systemteile.

Abb. 3: Bausteinsicht der Ebene 1

Tabelle 3: Aufgaben der Bausteine in Ebene 1
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 Brow ser- 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ügbaren Quellcode kann man verschiedene Metriken ermitteln. In der Treemap in Abbildung 4 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.

Abb. 4: Treemap zum Umfang inkl. Programmiersprachen

Abbildung 5 zeigt die mit dem Analyse-Werkzeug Teamscale ermittelten absoluten Zahlen (Stand vom 01.04.2021). Dabei wurde nur der Quelltext (Kotlin, Swift, Java) inklusive der Tests betrachtet.

Abb. 5: Umfang je Baustein auf Ebene 1

Der größte Backend-Baustein, der CWA-Server, besteht aus weiteren Compilezeit-Modulen und kann dementsprechend weiter aufgeklappt werden (s. Abb. 6).

Abb. 6: Bausteine des CWA-Servers (Ebene 2)

Tatsächlich zeigen sich hier einige Anti-Patterns für Microservices, wie die Vermischung unterschiedlicher Verantwortlichkeiten, die fehlende Trennung in der Datenspeicherung und das auf Wiederverwendung abzielende Common-Modul (s. auch Tabelle 4).

Tabelle 4: Aufgaben der Module des CWA-Servers
Baustein	Wesentliche Aufgabe
Submission Service	Nimmt Diagnoseschlüssel inkl. TAN vom Smartphone entgegen, verifiziert das positive Ergebnis und speichert die Schlüssel in der Datenbank.
Distribution Service	Liefert die Diagnoseschlüssel positiv Getesteter in Form von Dateien an einen S3-kompatiblen Speicher.
Federation Key Download Service	Kümmert sich um Download, Validierung, Extraktion und Speicherung der Schlüssel vom Federation-Gateway.
Federation Key Upload Service	Kümmert sich um den Upload der DE-Schlüssel zum Federation-Gateway. Läuft periodisch (Cron-Job).
Federation Callback Service	Nimmt über einen REST-Service Anfragen zum Download entgegen, die der Federation Key Download Service verarbeitet.
Common	Gemeinsame Klassen für Persistenz (Entitäten), Federation, Protocol Buffer-Definitionen.

Es ist davon auszugehen, dass man bei der Implementierung einen Kompromiss zwischen schnellerer Time-to-Market gegenüber hoher Entwurfsqualität eingehen musste. Entwickelt wird dieser Service genau wie die beiden Frontend-Monolithen (iOS- und Android-App) übrigens von Mitarbeitern der SAP. Alle anderen Backend-Services werden von der Deutschen Telekom gebaut.

Eingesetzte Technologien

Die Lösung verwendet diverse Programmiersprachen, Bibliotheken, Frameworks und Middleware (s. Abb. 7).

Abb. 7: Eingesetzte Technologien (Ausschnitt)

Die rund 200.000 Codezeilen (Stand April 2021) verteilen sich jeweils auf etwa 40 Prozent Swift (iOS) und Kotlin (Android) sowie 20 Prozent Java (Backend). Etwas untypisch verwenden die Backend-Services mit Spring Boot, Spring Cloud, Spring Data, Lombok, Guava, Liquibase, Micrometer, OpenAPI, protobuf alle den nahezu gleichen Technologie-Stack. Vermutlich auch eine Folge, um möglichst schnell und effizient produktiv gehen zu können. Die Persistenz erfolgt in einer PostgreSQL-Datenbank. In der Infrastruktur kommen beim Buildmanagement unter anderem Maven beziehungsweise Gradle zum Einsatz. Die Services werden als Docker Container deployt. Zu Testzwecken kann man Docker-Compose starten, in Produktion kommt Kubernetes zum Einsatz.

Ausgewählte Review-Ergebnisse

Der Entwurf des Corona-Warn-App-Systems geht wie jede Software bewusst Kompromisse (Trade-offs) ein und balanciert Qualitätsziele aus. Eine Möglichkeit, um Stärken, Schwächen und Risiken sichtbar zu machen, ist die Konkretisierung der Architekturziele durch sogenannte Bewertungs- oder Qualitätsszenarien (s. Abb. 8).

Abb. 8: Diverse Qualitätsszenarien zur Corona-Warn-App

Darauf aufbauend können in Analyse-Workshops (typischerweise gemeinsam mit dem Team) die Auswirkungen der Architekturentscheidungen und Lösungsansätze entlang der hoch priorisierten Szenarien diskutiert werden. Tabelle 5 zeigt für ausgewählte Lösungsansätze der CWA exemplarische Kompromisse. Genauso könnte man Stärken, Schwächen beziehungsweise Risiken herausarbeiten und daraus Empfehlungen ableiten. Durch deren Umsetzung kann die Softwarearchitektur dann in Form gehalten und auch Stück für Stück verbessert werden.

Tabelle 5: Kompromisse für ausgewählte Lösungsansätze

Fazit

Für alle Interessierten haben wir einen kompakten Flyer angefertigt, der die Architektur des Corona-Warn-App-Systems zusammenfasst und auch als Beispiel für eigene Dokumentationsvorhaben dienen kann (Download als PDF: [EMBARCFLYER]).
Mit der Corona-Warn-App wurde unter hohem politischem Druck und in sehr kurzer Zeit durch zwei Auftraggeber ein Softwaresystem für viele Millionen Menschen entworfen, umgesetzt und in Betrieb genommen. Die hohe Transparenz in der Entwicklung und der dezentrale Ansatz zum Schutz der persönlichen Daten haben zu einer adäquaten Akzeptanz in der Bevölkerung geführt und die CWA damit zum erhofften wichtigen Baustein bei der Pandemiebekämpfung werden lassen. Die Entwicklung als quelloffene Lösung könnte als Blaupause für weitere Vorhaben der öffentlichen Hand dienen.
Durch die leichte Änderbarkeit konnte die CWA in den vergangenen Monaten zudem um viele neue Funktionen erweitert werden. Sie wurde somit zu einem nützlichen und zuverlässigen Begleiter in der Pandemie. Und wird es vermutlich auch in der nächsten Zeit bleiben.