„log4j“: Was die Sicherheitslücke für das E-Rezept bedeutet

Berlin -

Es hätte kaum unpassender kommen können: Die Gematik hat kurz vor der gesetzlich verpflichtenden E-Rezept-Einführung bereits mit massiven Widerständen zu kämpfen, da kommt auch noch ein technischer Alarm hinzu. Die „log4j“-Schwachstelle, die das Bundesamt für Sicherheit in der Informationstechnik (BSI) am Wochenende öffentlich gemacht hat, hat auch Teile der Telematikinfrastruktur (TI) betroffen. Der E-Rezept-Fachdienst war nicht betroffen – aber der Fall zeigt, wie verwundbar das System ist.

In den IT-Abteilungen von Behörden und Unternehmen gibt es gerade viel zu tun: Am Wochenende hatte das BSI wegen der „Log4Shell“ genannten Server-Schwachstelle die höchste Warnstufe ausgerufen. Das Sicherheitsleck befindet sich in einer Java-Codebibliothek namens „Log4j“, Logging for Java. Wenn Angreifer die Lücke ausnutzen, erhalten sie die Möglichkeit, eigenen Code einzuschleusen und damit de facto Kommandogewalt in fremden Systemen zu erhalten – vom Datendiebstahl über die Manipulation bis zur kompletten Übernahme des jeweiligen Systems.

Besonders kritisch an der Sicherheitslücke ist, dass es sich um eine sogenannte „Zero-Day-Lücke“ handelt, also einen Sicherheitsfehler, der dokumentiert wird, bevor ein Patch dagegen zur Verfügung steht. Auf der Entwicklerplattform GitHub wurde zudem das Proof of Concept (PoC) veröffentlicht und das Problem damit weltweit bekannt, noch bevor es behoben werden konnte. Das BSI hat also allen Grund, von einer „extrem kritischen Bedrohungslage“ auszugehen, wie es schreibt.

Auch die TI war davon am Montag betroffen, drei der vier Komponenten des Versichertenstammdatenmanagements (VSDM) waren am Morgen und Vormittag nur eingeschränkt zu erreichen: Der Versichertenstammdatendienst, das Kartenmanagement und der Update Flag Service funktionierten nicht richtig. Lediglich der sogenannte Intermediär lief korrekt. Die Versicherten einiger Betriebskrankenkassen, der KKH sowie der AOKen Bremen, Niedersachsen und Sachsen-Anhalt konnten ihre elektronischen Gesundheitskarten (eGK) nicht richtig nutzen – beim Stecken in die Kartenlesegeräte erschien die Meldung „Prüfnachweis 3“. Ein reibungsloser Abgleich der Versichertenstammdaten konnte nicht gewährleistet werden.

Auch bei der elektronischen Patientenakte kam es zu erheblichen Einschränkungen: Die Aktensysteme der ePA-Apps einiger Krankenkassen wurden laut Gematik in den Wartungsmodus versetzt und sind zurzeit nicht nutzbar. Betroffen sind die ePA der AOK, HKK, DAK, KKH, LKK und alle Betriebskrankenkassen.

Der Großteil der Probleme in der TI waren bereits Montagmittag überwunden. „Die ursprüngliche Ursache der Störung konnte behoben werden“, so die Gematik. „Allerdings ist die Anwendung auf Wunsch der Kassen aufgrund der aktuellen ‚log4j‘-Thematik weiterhin offline.“

Das E-Rezept selbst – bestehend aus dem E-Rezept-Fachdienst, dem Identity Provider sowie dem Apotheken-Verzeichnisdienst – war von dem Sicherheitsrisiko nach aktuellem Wissensstand nicht betroffen. „Wenn dieser konkrete Vorfall im Produktivbetrieb aufgetreten wäre, hätte er keine konkreten Auswirkungen auf den E-Rezept-Dienst gehabt“, erklärt IT-Sicherheitsexperte Martin Tschirsich, der im Sommer zusammen mit seinem Partner Dr. André Zilch die massiven Sicherheitsmängel des Impfzertifikate-Dienstes des Deutschen Apothekerverbands (DAV) publik gemacht hatte.

Alles gut also? Mitnichten. Denn auch wenn die Gematik keinerlei Schuld an der aktuellen Sicherheitslücke trifft und ein anderer Teil der TI betroffen war, verdeutlicht der Ausfall die Schwächen des Aufbaus des vermeintlich hochsicheren Systems. „Dass eine oder mehrere bestimmte Komponenten ausfallen, kann immer passieren, auch beim E-Rezept“, sagt Zilch und Tschirsich fährt fort: „Im Grunde kann man so etwas wie die aktuelle Sicherheitslücke nicht antizipieren. Aber man kann ein System so konzipieren, dass der Schaden geringgehalten wird, wenn eine Komponente kompromittiert wird. Man muss damit leben lernen.“

Plan B für E-Rezept

Die momentane Situation bringe deshalb auch keinen Erkenntnisgewinn bezüglich der Sicherheit der TI als solcher. Dafür verdeutliche es eindrücklich grundsätzliche Probleme der Gematik-Konstruktion: „Das E-Rezept leidet an der Tatsache, dass es mit einer zentralen Komponente arbeitet. Wenn die angegriffen wird oder anderweitig eingeschränkt ist, müssen wir deutschlandweit auf Ersatzverfahren ausweichen“, sagt Tschirsich.

Eine mögliche Folge: Nicht nur könnten eventuell keine E-Rezepte ausgestellt werden, sondern bereits generierte E-Rezepte könnten in einem bestimmten Zeitraum nicht bedient oder abgerechnet werden. Patienten müssten entweder warten, bis das System wieder geht – was schlimmstenfalls unbekannt sein könnte – oder aber sie müssten sich beim Arzt das Rezept auf einem Muster-16-Formular neu ausstellen lassen. Welches Chaos das im Versorgungsalltag auslösen würde, ist leicht vorstellbar. Das Verfahren ist allerdings gesetzlich für den Ausfall einer oder mehrerer Komponenten des E-Rezepts vorgesehen – und wird als Hintertür genutzt, um zu ermöglichen, dass Arztpraxen, deren Praxisverwaltungssysteme technisch noch nicht bereit für den E-Rezept-Betrieb sind, noch bis Jahresmitte weiter Muster-16-Verordnungen ausstellen können.

E-Rezept auf eGK

Zilch und Tschirisch sehen das als vertane Chance, denn andere Ausweichmechanismen wären sicherer gewesen. „Es ist kein Warnschuss, da das Problem seit langem bekannt ist. Man kann nicht sagen, dass die Gematik da etwas nicht bedacht oder verpasst hätte. Aber was man hinterfragen muss, ist, ob die Ersatzverfahren praktikabel sind“, so Tschirsich. „Wenn keine Redundanz sichergestellt ist, ist man darauf angewiesen, dass Patienten für einen bestimmten Zeitraum auf solche Ersatzverfahren ausweichen“, sagt Zilch. „Bereits 2003/2004 hatte zur Diskussion gestanden, auch eine dezentrale Komponente einzuführen, indem das E-Rezept auch auf der eGK des Versicherten gespeichert wird.“ Diese Idee habe man aber verworfen und später nicht wieder aufgegriffen, obwohl sie technisch umsetzbar wäre. Auf der eGK wäre jedenfalls Platz für die geringen Datenmengen, die E-Rezepte benötigen. „Es wäre eine Möglichkeit, zu überlegen, ob es sinnvoller ist, ein E-Rezept auszudrucken und jemandem in die Hand zu geben oder es einfach auf der eGK abzuspeichern. Dafür war die eGK schließlich irgendwann mal vorgesehen“, so Zilch.

Ausfallszenarien gehören dazu

Auch die beiden IT-Spezialisten kritisieren vor diesem Hintergrund die unzureichende Erprobung des E-Rezepts durch die Gematik. Denn zentrale Komponenten, die ausfallen können, werde es immer geben. Auch große Rechenzentren würden standardmäßig Ausfallszenarien erproben, um zu eruieren, wie ihre Systeme damit umgehen können. Bei einer so großen Massenanwendung wie dem E-Rezept müsste das demnach eigentlich ebenso der Fall sein. „Das E-Rezept müsste nicht nur auf der technischen, sondern auch auf der organisatorischen Ebene getestet werden – zu der auch diese Ausfallszenarien gehören. Dazu müsste aber eine entsprechend große Auslastung erreicht werden“, so Tschirsich. Davon ist der E-Rezept-Testlauf aber nach wie vor weit entfernt. „Die Versorgungs- und Patientensicherheit hängen hier von der IT-Sicherheit ab.“