Die Digitalisierung im Gesundheitswesen vernetzt Medizinprodukte, In-vitro-Diagnostika und Laborgeräte zunehmend mit Krankenhaus- und Laborinformationssystemen, Cloud-Plattformen und weiteren Anwendungen. Gleichzeitig steigen Anforderungen an Cybersecurity, Interoperabilität und regulatorische Nachweisführung. Besonders anspruchsvoll ist dies bei Legacy-Systemen, die nicht für moderne Sicherheitsarchitekturen entwickelt wurden. Eine Middleware kann hier als Integrations- und Schutzschicht dienen: Als Security Proxy kontrolliert sie Kommunikationsbeziehungen, stellt zentrale Sicherheitsfunktionen bereit und unterstützt die schrittweise Einführung von Zero-Trust-Prinzipien.

Zero Trust als Antwort auf neue Betreiberanforderungen
Mit zunehmender Vernetzung, Cloud-Anbindung, mobilen Endgeräten und externen Dienstleistern reicht das Modell des vertrauenswürdigen internen Netzes nicht mehr aus. Auch interne Geräte oder Services können kompromittiert sein. Der Schutz kritischer Daten und Funktionen muss deshalb unabhängig von klassischen Netzwerkgrenzen greifen.
Zero Trust folgt dem Grundsatz „Never Trust, Always Verify“. Keine Entität gilt automatisch als vertrauenswürdig. Jeder Zugriff muss auf zulässiger Berechtigung und nachvollziehbarem Kontext beruhen. Der Schwerpunkt verschiebt sich von implizitem Netzwerkvertrauen hin zu überprüfbaren Sicherheitsentscheidungen.
Zero Trust ist dabei ein Paradigma, kein einzelnes Produkt und keine isolierte Technologie. Die Prinzipien adressieren Anforderungen, die sich in regulatorischen Vorgaben, Betreibererwartungen und Sicherheitsstandards wiederfinden: Schutz vor unautorisiertem Zugriff, Nachvollziehbarkeit, Segmentierung, minimale Berechtigungen und Absicherung von Kommunikationskanälen. Diese Perspektive passt zunehmend zu den Erwartungen von Betreibern. Krankenhäuser und andere Gesundheitseinrichtungen bevorzugen genau solche Sicherheitsarchitekturen. Zero Trust wird damit auch zum Beschaffungsargument: Betreiber achten zunehmend auf segmentierbare Netzintegration, transparente Services und Ports, feingranulare Rechte, sichere Fernwartung, zeitnahe Sicherheitsupdates und verwertbare Protokolldaten.
Damit wird Zero Trust zur nachweisbaren Architekturaufgabe: Sicherheitsanforderungen müssen aus Bedrohungen abgeleitet, technisch umgesetzt und als Security Capabilities kommuniziert werden. Einen passenden Orientierungsrahmen liefert IEC TR 60601-4-5. Der Technical Report beschreibt technische Sicherheitsfähigkeiten vernetzter medizinischer Systeme und wird später als Brücke zu jenen Anforderungen eingeordnet, die eine Middleware wie zenLAB zentral unterstützen kann.
Middleware als Sicherheitskomponente
Eine Middleware wird häufig auf ihre Integrationsfunktion reduziert. Tatsächlich kann eine auf einem Framework wie zenLAB basierende Middleware deutlich mehr leisten als die Vermittlung von Daten zwischen Geräten und externen Systemen. Werden relevante Datenflüsse konsequent über eine kontrollierte Kommunikationsschicht geführt, entsteht ein zentraler Ort für Sicherheitsfunktionen, die sonst separat umgesetzt werden müssten (insbesondere bei Legacy-Systemen eine Herausforderung).
Als Security Proxy steht die Middleware zwischen Medizinprodukt, Laborsystem und umgebender IT-Infrastruktur. Sie kann Identitäten prüfen, Zugriffsentscheidungen durchsetzen, Nachrichten validieren, sicherheitsrelevante Ereignisse protokollieren und definierte Schnittstellen bereitstellen. Damit adressiert sie bereits zentrale technische Sicherheitsfähigkeiten, wie sie IEC TR 60601-4-5 als Security Capabilities beschreibt.


Verteilte Zugriffskontrolle als Kernbaustein
Eine wirksame Zugriffskontrolle muss Benutzer, Geräte und Anwendungen berücksichtigen. Hier kann die Middleware eine zentrale Rolle übernehmen: Sie bündelt Zugriffe auf angebundene Systeme, prüft Identitäten, vermittelt zwischen Kommunikationspartnern und platziert Kontrollpunkte nahe an Datenflüssen, Services und Schnittstellen. Policy-Based Access Control leitet Entscheidungen nicht nur aus statischen Rollen ab, sondern bezieht Eigenschaften des Subjekts, der Ressource und des Nutzungskontexts ein.
Kern des Musters ist die Trennung von Richtlinienentscheidung und Richtliniendurchsetzung. Der Policy Decision Point (PDP) bewertet eine Anfrage anhand definierter Regeln sowie Identitäts-, Geräte-, Ressourcen- und Kontextinformationen. Der Policy Enforcement Point (PEP) setzt diese Entscheidung an der jeweiligen Schnittstelle durch, erlaubt zulässige Zugriffe und blockiert unzulässige Anfragen. Eine Middleware kann als solcher PEP wirken, indem sie direkte, unkontrollierte Zugriffe auf nachgelagerte Systeme verhindert und Entscheidungen konsistent an mehreren Eintrittspunkten erzwingt.
Sicherheitsentscheidungen dürfen deshalb nicht nur am äußeren Netzwerkrand erfolgen. Jeder Empfänger einer Nachricht muss nachvollziehen können, wer die Anfrage gestellt hat, ob die Nachricht unverändert ist und ob die gewünschte Aktion zulässig ist. Voraussetzung dafür ist eine Bedrohungsmodellierung vor der Technologieauswahl: Systemkomponenten, Datenflüsse, Vertrauensgrenzen, Identitäten und kritische Assets müssen verstanden sein, bevor Policies, Zertifikatsmechanismen oder einzelne Sicherheitsprodukte ausgewählt werden. Methoden wie STRIDE helfen, Bedrohungen strukturiert zu untersuchen und daraus geeignete Maßnahmen abzuleiten.
Zu den zentralen Maßnahmen gehören Nachrichtenintegrität, Verschlüsselung der Kommunikationsbeziehungen, gegenseitige Authentifizierung technischer Komponenten, Autorisierung ausgelöster Aktionen und Validierung der Nachrichteninhalte. Ein Default-Deny-Ansatz reduziert implizite Berechtigungen und unterstützt das Zero-Trust-Prinzip.
Legacy-Systeme mit zenLAB kontrolliert integrieren
Bei bestehenden Medizinprodukten, Laborsystemen und proprietären Geräteplattformen kann eine Middleware als Vermittlungs- und Schutzschicht eingesetzt werden. Das modulare Middleware-Framework zenLAB ist für die Kommunikation mit Geräten, Anwendungen und externen Systemen ausgelegt und kann erreichbare Schnittstellen begrenzen, Kommunikationspartner überprüfen, sicherheitsrelevante Zugriffe protokollieren und einheitliche, abgesicherte Integrationspunkte bereitstellen.
Basiskomponenten können unter anderem Benutzer- und Geräteverwaltung, Audit Trail, Logging, Messaging und Datenzugriff bereitstellen. In einer Zero-Trust-orientierten Ausprägung kann zenLAB Identitäten von Benutzern, Services und Geräten berücksichtigen, Zugriffsanfragen an Richtlinien binden und Entscheidungen an definierten Kontrollpunkten durchsetzen. Eine granulare Rechtevergabe auf Ressourcen- oder Knotenebene ermöglicht es, nicht nur den Zugang zu einem Gesamtsystem, sondern auch einzelne Datenzugriffe und Aktionen zu steuern.
Die Middleware kann unterschiedliche Produkt- und Kommunikationswelten voneinander entkoppeln. Krankenhausinformationssysteme, elektronische Patientenakten, Laborinformationssysteme oder ERP-Systeme können je nach Anwendungsfall über etablierte Standards und Programmierschnittstellen angebunden werden. Die Verwendung von HL7 FHIR, OPC UA oder REST-basierten Services garantiert jedoch noch keine sichere Integration. Authentifizierung, Autorisierung, Verschlüsselung, Eingabevalidierung und sichere Konfiguration müssen zusätzlich umgesetzt und geprüft werden.
Eine Middleware kann Schwachstellen innerhalb eines Legacy-Systems nicht vollständig kompensieren. Nicht über die Middleware geführte Kommunikationspfade entziehen sich ihrer Kontrolle. Hersteller müssen deshalb Systemgrenzen, verbleibende Abhängigkeiten und Restrisiken dokumentieren und im Rahmen der produktspezifischen Bedrohungsanalyse bewerten.
Technische Security Capabilities gezielt unterstützen
IEC TR 60601-4-5 beschreibt technische Security Capabilities für medizinische elektrische Systeme. Der Technical Report ist dabei weniger als isolierte Checkliste zu verstehen, sondern als praxisnaher Orientierungsrahmen: Er zeigt, welche Sicherheitsfähigkeiten ein vernetztes medizinisches System abhängig vom Ziel-Sicherheitsniveau bereitstellen sollte und wie diese Fähigkeiten gegenüber Betreibern, Integratoren und weiteren Beteiligten kommuniziert werden können.
Der Nutzen liegt insbesondere darin, Security nicht nur als abstrakte Risikoanforderung zu beschreiben, sondern in konkrete technische Fähigkeiten zu übersetzen. Damit kann IEC TR 60601-4-5 als Kommunikationsgrundlage gegenüber Dritten und zugleich als Inspirationsquelle für die sichere Gestaltung eigener Systeme im Rahmen einer Cybersecurity-Risikobewertung genutzt werden: die beschriebenen Security Capabilities können als Maßnahmenkatalog in der Cybsecurity-Risikobewertung verwendet werden aber auch bestehende Architekturen bewerten.
Eine zenLAB-basierte Middleware erfüllt hier ausgewählte Anforderungen beziehungsweise Security Capabilities der IEC TR 60601-4-5. Dazu zählen kontrollierte Schnittstellen, gegenseitige Authentifizierung technischer Kommunikationspartner, zentral durchgesetzte Autorisierung, protokollierte Zugriffe und eine klar beschreibbare Segmentierung zwischen Produkt, Middleware und externer IT-Infrastruktur.
Fazit
Vernetzte medizinische Systeme brauchen Sicherheitskonzepte jenseits klassischer Netzwerkgrenzen. Als Security Proxy kann Middleware zentrale Identitätsdienste, Zugriffskontrolle, abgesicherte Kommunikation und Auditierung bereitstellen und Zero-Trust-Prinzipien an mehreren Kontrollpunkten durchsetzen.
Gerade bei Legacy-Systemen ermöglicht dieser Ansatz, moderne Sicherheitsmechanismen schrittweise einzuführen. Entscheidend bleibt die Verbindung aus Bedrohungsmodellierung, überprüfbaren Identitäten, minimalen Berechtigungen, kontrollierten Datenflüssen und nachweisbarer Umsetzung über den Produktlebenszyklus.
Autoren: BSc. Johannes Schnepel, Software Engineer und CySec Specialist, und Dr. Martin Neumann, Senior Consultant Regulatory Affairs und CySec Specialist, infoteam Software AG
Kontakt: infoteam Software AG, Am Bauhof 9, 91088 Bubenreuth, Deutschland, Telefon: +49 9131 78 00-0, E-Mail: info@infoteam.de, Web: www.infoteam.de
Bleiben Sie auf dem Laufenden mit den neuesten Nachrichten aus der Medizintechnik auf unserer Website oder unserem Newsletter.





