ePA-Sicherheit Vom Flickwerk zur Vertrauensarchitektur

Anbieter zum Thema

Elastic GmbH

Governikus GmbH & Co. KG

Nicht zuletzt aufgrund der vom Chaos Computer Club identifizierten Sicherheitslücken ist das Vertrauen in die elektronische Patientenakte (ePA) angeschlagen. Was genau lief bei der Einführung schief, und wie lässt sich die ePA so aufstellen, dass Bürgerinnen und Bürger ihr dauerhaft vertrauen?

„Wenn ich als Patient nicht sicher bin, ob meine sensiblen Daten in diesem System sicher sind, dann ist das ein Problem“ – mit diesen klaren Worten brachte Tobias Keber, Landesdatenschutzbeauftragter in Baden-Württemberg, die Lage hinsichtlich des schwindenden Vertrauens in die ePA-Sicherheit auf den Punkt . Der Chaos Computer Club (CCC) habe „zu Recht“ auf Schwachstellen hingewiesen.

Bundesärztekammer

ePA als lernendes System

Die Enthüllungen der Sicherheitsforscher offenbarten tieferliegende Mängel – von lückenhaften Identitätsprüfungen bei der Kartenausgabe über unzureichend durchdachte Zugriffskonzepte bis hin zu altbekannten Angriffsmustern wie SQL-Injection. Selbst nach dem sicherheitsverstärkten Start der „ePA 2.0“ gelang es am Tag der bundesweiten Einführung erneut, in das System einzudringen. Zwar reagierten die Betreiber mit kurzfristigen technischen Gegenmaßnahmen, doch das Kernproblem bleibt: eine Architektur, in der Sicherheit zumindest bislang nicht konsequent als Grundprinzip verankert ist.

Architectural Design: Sicherheit in der DNA des Systems

Ein erheblicher Teil der heutigen Angriffsflächen ist nicht durch Einzelfehler entstanden, sondern durch ein Gesamt-Design, das zu wenig auf ganzheitliche Sicherheit abzielte. Viele ePA-Bausteine – etwa Konnektoren oder Apps – wurden nach anerkannten Standards wie Common Criteria geprüft, mit Evaluationsstufen von EAL 3+ oder EAL 2 und jeweils dokumentierter Begründung für die gewählte Einstufung. Diese Prüfungen erfolgten jedoch isoliert auf Komponentenebene. Eine systemweite Sicherheitsbetrachtung, die auch Wechselwirkungen, Schnittstellen und mögliche Verkettungen in den Blick nimmt, fand nicht statt. So konnte die Kombination an sich sicherer Einzelteile in der Praxis zu neuen, bislang unentdeckten Schwachstellen führen.

Die vom CCC gezeigten Angriffe zeigen genau diese Thematik: Durch die Verbindung einer elektronischen Ersatzbescheinigung mit einer SMC-B-Karte und dem Zugang zur Telematikinfrastruktur ließ sich ein Behandlungskontext vortäuschen. Dieser gewährte deutlich mehr Einblick, als in der realen Versorgung jemals erforderlich ist. Ein feingliedriges „Least Privilege“-Modell hätte Zugriffe von vornherein klar eingegrenzt – auf einzelne Patienteneinwilligungen, einen konkreten Behandlungskontext und ein automatisch ablaufendes Zeitfenster.

Auch bei der Entwicklung fehlte eine stringente Umsetzung von „Security by Design“ und klassische Schutzmechanismen kamen nicht zum Einsatz. Angriffe über SQL-Injection oder Social Engineering etwa sind seit Jahrzehnten bekannt. Sie lassen sich durch sauberes Bedrohungsmodellieren, verbindlich durchgesetzte Coding-Standards, automatisierte Tests und unabhängige Red-Team-Übungen wirksam ausschließen – wenn sie von Anfang an verpflichtend in den Prozess integriert werden. Dass einfach angreifbare Fallback-Verfahren wie die Ersatzbescheinigung im ursprünglichen Design nur am Rande betrachtet wurden, erwies sich im Nachhinein als folgenschwer. Ebenso wie die fehlende Transparenz: Ohne öffentliche Prüfberichte und offene Testumgebungen vor dem Rollout fehlte der externe Blick, der solche Lücken hätte aufzeigen können.

Delivery & Implementierung: Anspruch und Realität der Umsetzung

Die Qualität der technischen Umsetzung bestimmte maßgeblich, wie verwundbar die Infrastruktur zum Start war. Der erfolgreiche SQL-Injection-Angriff auf das Kartenausgabeportal ist ein Musterbeispiel dafür, dass das Thema Security im Softwareentwicklungszyklus nicht ausreichend Beachtung fand. Wesentliche Grundsätze wie konsequente Eingabevalidierung, automatisiertes Fuzzing und strikte Code-Reviews wurden offenbar nicht flächendeckend angewandt oder verbindlich eingefordert – weder bei internen Teams noch bei Dienstleistern in der Lieferkette.

Schwachstellen zeigten sich auch bei der Vergabe von Zugangsberechtigungen wie SMC-B-Karten. Die Möglichkeit, solche Identitäten mit vergleichsweise geringem Aufwand und ohne ausreichende Überprüfung zu erlangen, erhöhte das Risiko erheblich. In einem zentralen Vertrauenssystem wie der Telematikinfrastruktur müssen Ausgabeverfahren besonders gesichert sein, etwa durch persönliche Identitätsprüfung, hardwaregebundene Schlüssel und lückenlose Protokollierung. Hinzukam, dass nicht alle Portale und Backend-Dienste, die Teil der ePA-Vertrauensinfrastruktur sind, denselben Sicherheitsstandards unterlagen wie die Kernsysteme. Eine verbindliche Rollout-Governance mit End-to-End-Tests unter realen Bedingungen, Chaos-Tests und klar definierten „Go/No-Go“-Meilensteinen hätte dazu beitragen können, solche Schwächen vor der bundesweiten Einführung zu erkennen und zu beheben.

Betrieb: Sicherheit als Daueraufgabe

Selbst die sicherste Architektur und die beste Implementierung schützen nicht dauerhaft, wenn der Betrieb keine kontinuierliche Kontrolle und Reaktionsbereitschaft sicherstellt. Penetrationstests spielen hier eine wichtige Rolle. Sie entfalten aber nur Wirkung, wenn sie Teil eines strukturierten, wiederkehrenden Auditprogramms sind, das interne wie externe Prüfungen umfasst.

Von zentraler Bedeutung ist die Echtzeiterkennung von Anomalien. Systeme sollten wie in der Finanzbranche in der Lage sein, untypische Zugriffsmuster, verdächtige Behandlungskontexte oder auffällige Nutzung von Identitäten sofort zu identifizieren und automatisch Gegenmaßnahmen einzuleiten. Auch ein funktionierender Incident-Response-Plan ist unverzichtbar. Dieser beschreibt klare Zuständigkeiten, kurze Reaktionszeiten auch an Wochenenden und die Möglichkeit, riskante Fallback-Prozesse unmittelbar auszuschalten.

Nicht zuletzt hängt langfristige Sicherheit auch von einer Kultur der Offenheit ab. Anstatt Vorfälle zu verbergen, sollten Betreiber und Behörden Ursachen transparent machen, Korrekturen dokumentieren und so Vertrauen zurückgewinnen.

Fazit: Vertrauen als Leitwährung

Die ePA kann ihre Rolle als Meilenstein der Digitalisierung im Gesundheitswesen nur erfüllen, wenn sie Sicherheit in allen Phasen konsequent umsetzt – von der Architektur über die Entwicklung bis zum Betrieb. Das beginnt bei einer systemweiten Sicherheitsarchitektur mit klaren Zugriffsgrenzen, setzt sich fort in einer Umsetzung, die sichere Entwicklungsprozesse und geprüfte Lieferketten garantiert, und schließt einen Betrieb ein, der Bedrohungen in Echtzeit erkennt und schnell reagiert. Nur wenn diese Kette lückenlos ist, wird aus dem bisherigen Flickwerk eine tragfähige Vertrauensarchitektur, die als Vorbild für sichere digitale Gesundheitsinfrastrukturen in Europa dienen kann.

Pflichttermin: 1. Oktober

Der breite Start der E-Patientenakte hakt

(ID:50575315)