Sie haben Famedly Blog erfolgreich abonniert.
Toll! Schließen Sie als NĂ€chstes die PrĂŒfung ab, um vollen Zugriff auf Famedly Blog zu erhalten.
Willkommen zurĂŒck! Sie haben sich erfolgreich angemeldet.
Erfolg! Ihr Konto ist vollstÀndig aktiviert, Sie haben nun Zugriff auf alle Inhalte.
Erfolg! Ihre Zahlungsinformationen wurden aktualisiert.
Aktualisierung der Rechnungsinformationen fehlgeschlagen.
Zentral vs. dezentral - Technische Vor- und Nachteile

Zentral vs. dezentral - Technische Vor- und Nachteile

Nach wochenlanger Diskussion war klar: die deutsche Corona-Warn-App wird dezentral. Wir erklÀren, was das bedeutet.

Phillipp Kurtz
Phillipp Kurtz

Seit Wochen steht fest: Die deutsche Corona-Tracing-App wird Nutzerdaten dezentral verarbeiten. Grund dafĂŒr ist, dass durch eine dezentrale Verarbeitung Nutzerdaten besser geschĂŒtzt werden. Technisch bedeutet das einen deutlichen Mehraufwand, da keine zentralen out-of-the-box Lösungen verwendet werden können.

Die Debatte ĂŒber die Umsetzung wurde in den Medien lang und ausfĂŒhrlich gefĂŒhrt. EuropĂ€ische Spitzenforscher und -Politiker Ă€ußerten sich. Medienwirksam wurde selbst der Test der ersten Vorab-Version der Corona-App durch Bundeswehr-Soldaten inszeniert. Ein informationstechnologischer Richtungsstreit wurde in der Öffentlichkeit gefĂŒhrt und plötzlich schien jeder Experte fĂŒr Netzwerk-Datenarchitektur zu sein. Aber warum? Was Ă€ndert diese kleine Silbe "de" an dem Wort "zentral" scheinbar so grundlegend, dass eine Grundsatzdebatte notwendig zu sein scheint?

Neben den konkreten technischen Unterschieden hat diese Diskussion fast schon eine philosophische Dimension eingenommen. Wo sind meine Daten gespeichert und wer hat darauf Zugriff? Soll es ein zentrales, staatlich kontrolliertes System geben, dem wir alle genĂŒgend vertrauen? Oder bleibt die Kontrolle bei jeder Person oder zumindest einer Vielzahl kleinerer Organisationen? Wie können wir sicherstellen, dass in diesem Fall alle an einem Strang ziehen und nicht Einzelne das ganze System gefĂ€hrden? Schwierige, aber wichtige Fragen, die wir nur als Gesellschaft insgesamt beantworten können. Wenn es um die Technologie geht, können wir als Famedly unseren Beitrag leisten und ein paar grundlegende Dinge erklĂ€ren.

Zentrale Systeme

Zentrale Systeme haben ein einfaches Grundprinzip. Alle GerĂ€te verbinden sich mit einem zentralen Server. Dieser Server ĂŒbernimmt den Großteil der Funktionen. Bei einem zentralen Ansatz sieht die Architektur fĂŒr fĂŒnf GerĂ€te so aus:

stateDiagram Server --> GerÀt1 GerÀt1 --> Server GerÀt2 --> Server Server --> GerÀt2 Server --> GerÀt3 GerÀt3 --> Server Server --> GerÀt4 GerÀt4 --> Server Server --> GerÀt5 GerÀt5 --> Server

Großer Vorteil bei der BĂŒndelung der Kern-FunktionalitĂ€ten ist, dass neue Funktionen oder auch Korrekturen (Updates) bestehender Funktionen nur an einer Stelle eingespielt werden mĂŒssen. Besonders entscheidend ist das bei sicherheitsrelevanten Funktionen, da man nicht darauf angewiesen ist, dass verschiedene Betreiber unabhĂ€ngig voneinander ihre Systeme aktualisieren. Zentrale Systeme kommen ĂŒberdies mit einer reinen Server-Klient-Architektur aus, die schon seit vielen Jahren Standard in der IT sind. Software-Entwickler und vor allem Systemadministratoren haben viel Erfahrung im Umgang mit solchen Architekturen und können diese in der Regel schnell und einfach bereitstellen.

Es gibt jedoch wie bei jedem System auch Nachteile. Zentrale Systeme mĂŒssen sehr effizient arbeiten, damit FunktionalitĂ€ten fĂŒr eine große Zahl von Nutzern funktioniert. Außerdem ist der zentrale Server technisch ein sogenannter Single Point of Failure. Denn fĂ€llt der zentrale Server aus, kann keinerlei Austausch mehr zwischen den verschiedenen GerĂ€ten stattfinden, da dieser die einzige Verbindung zwischen den GerĂ€ten darstellt. So begibt man sich in eine AbhĂ€ngigkeit vom Betreiber des zentralen Servers. Schaltet dieser den Server ab, bricht das gesamte System zusammen.

Noch grĂ¶ĂŸere Probleme ergeben sich beim Datenschutz. Ähnlich wie bei zentralisierten politischen Systemen besteht auch in zentralen Softwaresystemen eine große Missbrauchsgefahr. Da alle Daten an einem zentralen Ort liegen und der Großteil der Funktionen ebenfalls nur an einer Stelle ablĂ€uft, ist dieser zentrale Ort sehr sensibel. Zum Einen können Angreifer sehr schnell enorme Datenmengen erbeuten und selbst wenn eine extrem hohe Sicherheit erreicht wird und ein Angriff quasi ausgeschlossen ist, mĂŒssen Nutzer dem Betreiber des zentralen Servers vertrauen, da dieser den uneingeschrĂ€nkten (physischen) Zugriff auf den Server hat.

Zentrales System - Vorteile:

  • Das Systeme kann schnell entwickelt und gut instand gehalten werden.
  • Es kann schnell auf eventuelle SicherheitslĂŒcken reagiert werden.

Zentrales System - Nachteile:

  • Wer Zugriff auf den zentralen Server erhĂ€lt, erhĂ€lt Zugriff auf ALLE Daten. Das ist besonders bedenklich, wenn der zentrale Server gehackt werden sollte.
  • Nutzer sind auf den Betreiber des zentralen Servers angewiesen, wenn sie Daten löschen wollen.
  • FĂ€llt der zentrale Server aus, kann kein Nutzer mehr die Funktionen nutzen.

Dezentrale Systeme

Im Vergleich dazu sind dezentrale Systeme deutlich komplexer. Alle Server mĂŒssen sich untereinander verbinden, FunktionalitĂ€ten mĂŒssen verteilt ablaufen und entsprechend koordiniert werden. Man kann sich vorstellen, dass das schnell kompliziert wird. Die Architektur fĂŒr fĂŒnf Server in einem dezentralen System sieht dann schon so aus:

stateDiagram Server1 --> Server2 Server2 --> Server1 Server1 --> Server3 Server3 --> Server1 Server2 --> Server3 Server3 --> Server2 Server1 --> Server4 Server4 --> Server1 Server2 --> Server4 Server4 --> Server2 Server3 --> Server4 Server4 --> Server3 Server1 --> Server5 Server5 --> Server1 Server2 --> Server5 Server5 --> Server2 Server4 --> Server5 Server5 --> Server4 Server3 --> Server5 Server5 --> Server3

Mit jedem dieser dezentralen Server können sich EndgerĂ€te verbinden. So entsteht ein dezentraler Knoten, was wir hier der Einfachheit halber nicht dargestellt haben. Dieser Aufbau zeigt jedoch, dass FunktionalitĂ€ten auf allen Servern entweder redundant oder verteilt ablaufen mĂŒssen. Werden also neue Funktionen hinzugefĂŒgt oder korrigiert, so mĂŒssen die entsprechenden Updates von den Betreibern eines jeden Servers individuell aufgespielt werden. In gewisser Weise besteht somit eine AbhĂ€ngigkeit aller Betreiber untereinander, da eine einwandfreie Funktion nur sichergestellt ist, wenn alle Betreiber an einem Strang ziehen. Besonders kritisch ist das bei sicherheitsrelevanten Funktionen. Auch mĂŒssen die einzelnen Server viele Informationen untereinander austauschen, damit keine Situation entsteht, an der die gleiche Information an unterschiedlicher Stelle in unterschiedlicher AusprĂ€gung vorhanden ist. Doppelungen von Informationen, die so gut es geht vermieden werden sollten, lassen sich somit nicht ganz ausschließen. Das stĂ€ndige "sich absprechen" zwischen den Servern macht die notwendige Software entsprechend komplex. Dezentrale Systeme sind deshalb in der Regel deutlich schwieriger zu entwickeln und neue Funktionen können nur langsamer in diesen Systemen verteilt werden.

Warum sollte man den ganzen Aufwand denn ĂŒberhaupt betreiben?

Ein dezentrales System hat viele Vorteile. Durch die Verwendung vieler Server gibt es keinen Single Point of Failure, bei dessen Ausfall das ganze System zusammenbricht. FĂ€llt ein Server aus, funktionieren die anderen Server immer noch und können Informationen austauschen. Ist der ausgefallene Server wieder verfĂŒgbar, wird er von den anderen Servern wieder auf den neusten Stand gebracht. Ein dezentrales System ist so belastbarer als ein zentrales System.

Auch beim Datenschutz haben dezentrale Systeme Vorteile. Daten einzelner Nutzer werden nur auf den Servern gespeichert auf denen diese aktiv sind. So gibt es nicht einen Server, der ĂŒber sĂ€mtliche Daten aller Nutzer verfĂŒgen kann, sondern die Daten werden auf verschiedene Servern und somit die Macht darĂŒber auf verschiedene Betreiber verteilt. So ist Ă€hnlich einem föderalisierten politischen System, die Macht ist verteilt. Je breiter das System dezentralisiert ist, desto kleiner ist der Datenpool auf den die Betreiber Zugriff haben. Bei maximaler Verteilung liegen die Daten sogar nur auf dem GerĂ€t des Nutzers (verteilte Systeme). Besonders wichtig ist diese Eigenschaft bei unerlaubten Zugriffen. Erlangen Angreifer Zugriff auf einen dezentralen Server, so können nur Nutzerdaten dieses einen Servers entwendet werden und nicht die Daten aller Nutzer. Insgesamt sind Daten in einem dezentralen System besser vor ungewolltem Zugriff Unbefugter geschĂŒtzt.

Dezentrale Vorteile:

  • Nutzer behalten die Datenhoheit ĂŒber Ihre Daten
  • Es gibt keinen Single Point of Failure.
  • Bei erfolgreichen Angriffen werden nur wenige Daten erbeutet
  • Das System ist robuster.

Dezentrale Nachteile:

  • Die Umsetzung und Instandhaltung der Architektur ist komplex und aufwendig.
  • Sicherheitsupdates mĂŒssen an jedem Knotenpunkt eingespielt werden.

Fazit

Der höhere Aufwand eines dezentralen Systems ist nicht in allen FĂ€llen gerechtfertigt. Wenn es jedoch um die Sicherheit von Patientendaten geht, so ist es zwingend notwendig, dass alle Anstrengungen unternommen werden, um höchsten Schutz zu gewĂ€hrleisten. Und deshalb ist es richtig, dass Deutschland auf ein System setzt, fĂŒr dessen Entwicklung zwei der grĂ¶ĂŸten deutschen IT-Konzerne viele Wochen brauchen, anstatt auf schnell umzusetzende zentrale Systeme.

UnverstĂ€ndlich ist jedoch, warum Deutschland in anderen Bereichen nach wie vor auf zentralisierte Systeme setzt, bspw. beim Austausch von Gesundheitsdaten ĂŒber die Gematik.

GlĂŒcklicherweise scheint es ein Umdenken zu geben. Nicht nur die Corona-App wird dezentral organisiert, sondern die Bundeswehr setzt mit ihrem neuen sicheren Messenger auf das dezentrale Protokoll Matrix.

Genau dieses Protokoll nutzt Famedly als Basis fĂŒr unsere Plattform fĂŒr medizinische Zusammenarbeit. Wir glauben, dass die Sicherheit von personenbezogenen Daten insbesondere von Patientendaten oberste PrioritĂ€t hat und nur mit einem dezentralen System gewĂ€hrleistet werden kann. So ermöglicht unsere Plattform eine sichere Zusammenarbeit zwischen Versorgern und eine sichere und unabhĂ€ngige Kommunikation mit Patienten. Die technischen Details zur Architektur der Famedly Plattform stellen wir demnĂ€chst in einem eigenen Blog-Post vor. Es ist aber nicht zu viel verraten, wenn wir sagen, dass der grundlegende Aufbau auf einem Open-Source Protokoll basiert 😊