Warum kann die Cloud-Sicherheit im Gesundheitswesen nicht wie die übliche Cloud-Sicherheit in Unternehmen behandelt werden?

Wodurch unterscheidet sich die Datensicherheit im Gesundheitswesen von der üblichen Datensicherheit in Unternehmen?

Die Datensicherheit im Gesundheitswesen unterliegt einer Reihe von Sicherheitsaspekten, die in typischen Diskussionen über Datenschutz und Sicherheit in Unternehmen selten zur Sprache kommen. Eine Vielzahl strenger regulatorischer Anforderungen, personenbezogene Daten, die nicht dupliziert oder ersetzt werden können, sowie die Gesundheit eines Patienten als direkte Folge – all dies trägt dazu bei, dass sich die Verpflichtungen zum Schutz von Gesundheitsdaten von jedem anderen Rahmenwerk der allgemeinen Cloud-Sicherheit unterscheiden.

Inwiefern sind geschützte Gesundheitsdaten (Protected Health Information, PHI) besonders sensibel?

Geschützte Gesundheitsdaten (Protected Health Information, PHI) weisen eine andere Sensibilitätsstufe auf als die übrigen Unternehmensdaten einer Organisation. Das Ministerium für Gesundheit und Soziales (Department of Health and Human Services, DHHS) definiert PHI als individuell identifizierbare Gesundheitsdaten, die sich auf den vergangenen, gegenwärtigen oder zukünftigen körperlichen oder psychischen Gesundheitszustand einer Person, die Erbringung von Gesundheitsleistungen oder die Bezahlung von Behandlungen beziehen.

Eine Kreditkarte kann gesperrt werden, sobald ein Missbrauch aufgedeckt wird, woraufhin eine neue Karte ausgestellt wird. Bei Krankheiten, genetischen Faktoren oder psychischen Diagnosen ist dies nicht der Fall – diese Fakten sind tatsächlich dauerhaft.

Wann immer geschützte Gesundheitsdaten (PHI) kompromittiert werden, gehen die damit verbundenen Risiken weit über einfachen Identitätsdiebstahl hinaus. Krankenakten können dazu genutzt werden, Patienten vom Versicherungsschutz auszuschließen, ihre beruflichen Chancen zu beeinträchtigen und gezielten Betrug an älteren und behinderten Menschen zu begehen. Die Vertraulichkeit von PHI wird durch die Bandbreite der Informationen, die als PHI eingestuft werden können, noch weiter verschärft.

Hier sind die prominentesten Beispiele:

• Vollständiger Name und Kontaktdaten in Verbindung mit einer Erkrankung oder Behandlung
• Geburts-, Aufnahme-, Entlassungs- oder Sterbedaten
• Geografische Daten, die unterhalb der Ebene eines Bundeslandes liegen
• Biometrische Identifikatoren wie Fingerabdrücke oder Stimmabdrücke
• Jede andere eindeutige Identifikationsnummer oder jeder Code, der mit der medizinischen Versorgung in Verbindung steht

Warum haben Vertraulichkeit, Integrität und Verfügbarkeit im Gesundheitswesen unterschiedliches Gewicht?

Vertraulichkeit, Integrität und Verfügbarkeit (manchmal auch als „CIA-Triade“ bezeichnet) gelten für alle Sicherheitsprotokolle. In Cloud-Umgebungen des Gesundheitswesens werden diese Säulen jedoch tendenziell anders betrachtet als bei üblichen Unternehmensimplementierungen.

So hat beispielsweise die Verfügbarkeit bereits bei einfachen Ausfällen erhebliche klinische Folgen, die in keinem anderen Bereich der Branche ihresgleichen haben. Ein Ausfall der Dienste bedeutet im Gesundheitswesen nicht lediglich einen Produktivitätsverlust – er führt dazu, dass die Bestellung von Medikamenten blockiert wird, der Zugriff auf Bildgebungsergebnisse verhindert wird oder Rettungssanitäter die Patientenakte nicht einsehen können.

Allgemeinere Informationen zu allen drei der oben genannten Säulen finden Sie im Folgenden:

Inwiefern verändert die Notwendigkeit einer langfristigen Aufbewahrung und Nachvollziehbarkeit die Sicherheitsanforderungen?

Krankenakten und die dazugehörige Sicherheitsdokumentation müssen wesentlich länger aufbewahrt werden als es die üblichen Aufbewahrungsfristen für Unternehmensdaten vorsehen.

HIPAA (Health Insurance Portability and Accountability Act) schreibt vor, dass betroffene Einrichtungen ihre Richtlinien und Verfahren sowie die dazugehörigen Unterlagen für einen Zeitraum von 6 Jahren ab dem Erstellungsdatum oder dem Datum des letzten Inkrafttretens aufbewahren müssen. In bestimmten Bundesstaaten kann dieser Zeitraum bei bestimmten Arten von Unterlagen sogar noch länger sein.

Die Cloud-Sicherheitskontrollen, die diese Daten unterstützen und schützen, müssen ebenfalls über denselben Zeitraum aufrechterhalten werden. Diese Kontrollen müssen während der gesamten sechsjährigen Laufzeit durchsetzbar, überprüfbar und wiederherstellbar sein.

Solche Anforderungen beeinflussen die übergreifende Gestaltung der Cloud-Sicherheitsarchitektur im Gesundheitswesen. Die Schlüsselverwaltung für die Verschlüsselung, Zugriffsprotokolle und die Integrität von Backups – nichts davon darf lediglich als kurzfristiges betriebliches Anliegen betrachtet werden. Ein Prüfpfad, der bei der Untersuchung einer Sicherheitsverletzung oder einer behördlichen Anfrage in fünf Jahren hilft, hängt von den Kontrollen ab, die heute implementiert und betrieben werden.

Wie verändern Compliance- und Gesundheitsvorschriften die Anforderungen an die Cloud-Sicherheit?

Regulatorische Verpflichtungen im Gesundheitswesen sind nicht nur ein zusätzlicher Rahmen für die Cloud-Sicherheit. Diese Verpflichtungen bedeuten auch, dass sich ändert, welche Kontrollmaßnahmen erforderlich sind, wer dafür verantwortlich ist und was geschieht, wenn sie versagen. HIPAA, DSGVO, HITECH und eine wachsende Liste von Vorschriften auf Bundesstaatenebene stellen jeweils ihre eigenen Anforderungen (technischer und vertraglicher Art) an Cloud-Umgebungen, für deren Handhabung standardmäßige Compliance-Rahmenwerke für Unternehmen nicht ausgelegt sind.

Welche konkreten Verpflichtungen erlegen HIPAA, DSGVO und andere Vorschriften im Gesundheitswesen der Cloud-Nutzung auf?

Jedes wichtige regulatorische Rahmenwerk hat seine eigene Perspektive, wenn es um Cloud-Sicherheit geht:

• HIPAA gilt für geschützte Gesundheitsdaten (PHI), die bei den in den USA ansässigen betroffenen Einrichtungen und deren Geschäftspartnern gespeichert sind; dies umfasst auch Cloud-Lösungen, die in deren Auftrag sensible Patientendaten speichern, verarbeiten und übertragen.
• DSGVO gilt für Fälle, in denen Gesundheitsdaten von EU-Bürgern betroffen sind, selbst wenn sich die Cloud-Speicherinfrastruktur an einem anderen Ort befindet.
• HITECH erweitert und verstärkt die Durchsetzungsmöglichkeiten des HIPAA, indem es die Strafstufen erhöht und gleichzeitig die Anforderungen an die Meldepflicht bei Datenschutzverletzungen ausweitet.

Die Verpflichtungen, die jedes Rahmenwerk der Cloud-Umgebung auferlegt, unterscheiden sich hinsichtlich Umfang, Mechanismus und Folgen erheblich voneinander:

Inwiefern unterscheiden sich Zeitpunkt und Umfang der Benachrichtigung bei Datenschutzverletzungen für Organisationen im Gesundheitswesen?

Benachrichtigungen über Datenschutzverletzungen im Zusammenhang mit Gesundheitsdaten sind zudem wesentlich strenger geregelt (und mit höheren Risiken verbunden) als in den meisten anderen Unternehmensbereichen. Die Fristen sind fest vorgegeben, die Adressaten der Meldungen sind vielfältig, und die Schwellenwerte, die unterschiedliche Meldepflichten auslösen, sind sehr spezifisch:

• 60 Tage – maximale Frist, innerhalb derer eine unter HIPAA fallende Einrichtung betroffene Personen nach Feststellung einer Datenschutzverletzung benachrichtigen muss
• 60 Tage – dieselbe Frist gilt für die Benachrichtigung des US-Gesundheitsministeriums (HHS)
• Mehr als 500 betroffene Personen – löst die Verpflichtung aus, führende Medien im betroffenen Bundesstaat oder Zuständigkeitsbereich zu benachrichtigen
• Weniger als 500 betroffene Personen – können protokolliert und jährlich an das HHS gemeldet werden, die Benachrichtigung der einzelnen Betroffenen muss jedoch weiterhin innerhalb von 60 Tagen erfolgen
• DSGVO – schreibt die Benachrichtigung der zuständigen Aufsichtsbehörde innerhalb von 72 Stunden nach Bekanntwerden einer Datenschutzverletzung vor sowie die unverzügliche Benachrichtigung der betroffenen Personen, wenn ein hohes Risiko zu erwarten ist
• Landesgesetze – mehrere Bundesstaaten schreiben kürzere Fristen als die 60 Tage der HIPAA vor; einige verlangen eine Benachrichtigung innerhalb von 30 Tagen oder weniger

All diese Fristen werden im Zusammenhang mit Cloud-Umgebungen noch weiter verkompliziert. Immer dann, wenn geschützte Gesundheitsdaten (PHI) über verschiedene Cloud-Anbieter, Regionen oder Dienste von Drittanbietern verteilt sind, dauert die Ermittlung des gesamten Ausmaßes einer Datenschutzverletzung (für eine genaue Benachrichtigung) wesentlich länger als in abgeschlossenen lokalen Umgebungen.

Warum erfordert die Gesundheitsbranche eine strengere Überprüfung der Cloud-Compliance?

Die größte Schwäche bei der strengen Überprüfung der Cloud-Compliance im Gesundheitswesen besteht darin, dass keine der bestehenden Compliance-Zertifizierungen direkt den gesundheitsspezifischen regulatorischen Anforderungen entspricht, und die Annahme der Gleichwertigkeit setzt Ihre Organisation potenziell einem erheblichen Risiko durch Sicherheitslücken aus.

Wenn ein Cloud-Anbieter beispielsweise über eine SOC-2-Typ-II-Zertifizierung oder eine ISO-27001-Akkreditierung verfügt, erfüllt er damit eine anerkannte Sicherheitsgrundlage. Gleichzeitig wurde keines dieser Rahmenwerke unter Berücksichtigung von PHI, der Notwendigkeit klinischer Zugänglichkeit oder der technischen Schutzmaßnahmen gemäß HIPAA entwickelt.

Eine strengere Überprüfung in Cloud-Umgebungen im Gesundheitswesen bedeutet, über reguläre Zertifizierungsprüfungen hinauszugehen. Dazu gehören:

• Die Überprüfung, ob die BAA die tatsächlichen Datenverarbeitungspraktiken des Anbieters korrekt widerspiegeln
• Die Sicherstellung, dass die Konfigurationen der Audit-Protokolle sowohl die HIPAA-Anforderungen als auch die Aufbewahrungsvorschriften auf Bundesstaatenebene erfüllen
• Die Überprüfung, ob Verschlüsselungsmaßnahmen PHI im Ruhezustand, während der Übertragung und insbesondere während der Verarbeitung abdecken

Warum ist die Patientensicherheit ein Sicherheitsaspekt, den die IT oft übersieht?

In den meisten Branchen kommt es aufgrund von Sicherheitsverletzungen zu finanziellen Verlusten, Datenverlusten oder Reputationsschäden. Sicherheitsprobleme im Gesundheitswesen können jedoch direkt zu Verletzungen der Patienten führen. Allein dieser Unterschied verändert grundlegend, wie Entscheidungen zur Cloud-Sicherheit priorisiert und gesteuert werden.

Warum müssen Organisationen im Gesundheitswesen Patientendaten schützen, um eine sichere Patientenversorgung zu gewährleisten?

Die ständige Verfügbarkeit von Patientendaten ist für die klinische Versorgung unverzichtbar. Die Auswirkungen jeglicher Störung in einer Cloud-Umgebung (eine Sicherheitsverletzung, ein Ausfall, eine Datenbeschädigung) reichen sofort weit über die IT-Abteilung hinaus. Dazu gehören:

• Ärzte, die den Zugriff auf Medikamentenverläufe verlieren
• Pflegekräfte, die nicht mehr auf aktuelle Versorgungspläne zugreifen können
• Notfallteams, die gezwungen sind, Entscheidungen ohne Berücksichtigung des entscheidenden diagnostischen Kontexts zu treffen

Ob Sie auf die Patientendaten zugreifen können und ob diese Daten gültig sind, ist kein Maßstab für die IT-Leistung – es ist ein Maßstab für die Patientensicherheit. Eine Einrichtung im Gesundheitswesen, die Cloud-Sicherheit als „Backoffice“-Thema betrachtet, schafft jedes Mal ein Risiko für die Patienten, wenn ihr System ausfällt oder die Patientenakte ohne Nachweis verändert wird.

Warum müssen Verfügbarkeits-SLAs als klinische Risikokontrollen behandelt werden?

Der Schutz der Geschäftskontinuität ist wohl eines der zentralen Themen eines normalen Unternehmens-SLAs. In Cloud-Umgebungen des Gesundheitswesens muss dieses Dokument als klinische Risikokontrolle fungieren und dabei berücksichtigen, welche Auswirkungen ein Ausfall im Kontext der Patienten hätte.

Allgemeine Verfügbarkeitsgarantien sind nicht in der Lage, den betrieblichen Realitäten klinischer Umgebungen gerecht zu werden. Ein SLA für eine Cloud-Bereitstellung im Gesundheitswesen sollte Folgendes festlegen:

• Recovery Time Objective (RTO), abgestimmt auf die Kritikalität der klinischen Arbeitsabläufe – der Zugriff auf elektronische Patientenakten (EHR) erfordert beispielsweise ein weitaus kürzeres RTO als Abrechnungssysteme
• Recovery Point Objective (RPO), das streng genug ist, um klinisch bedeutsamen Datenverlust zwischen der letzten Sicherung und dem Zeitpunkt des Ausfalls zu verhindern
• Geplante Wartungsfenster, die auf Zeiten mit geringer Auslastung abgestimmt sind, nicht auf die üblichen Nebenzeiten außerhalb der Geschäftszeiten
• Eskalationsverfahren, die kritische Ausfallmeldungen direkt an die Leitung des klinischen Betriebs weiterleiten, nicht nur an die IT
• Unterstützung bei Ausfallverfahren – Dokumentation oder Tools, die manuelle klinische Arbeitsabläufe ermöglichen, wenn Cloud-Systeme nicht verfügbar sind

Inwiefern sollte die Zusammenarbeit zwischen Sicherheits- und Schutzteams anders gestaltet werden als bei der herkömmlichen IT und Sicherheit?

In einer typischen Unternehmensumgebung definiert das Sicherheitsteam die Kontrollmaßnahmen, während IT-Teams diese umsetzen. Klinische Aspekte fließen in keinen dieser Prozesse ein.

Der Einsatz von Cloud-Technologien im Gesundheitswesen erfordert ein völlig neues Betriebsmodell, das die Rolle der Patientensicherheitsbeauftragten, der klinischen Informatikteams und der Biomedizintechniker verändert: Sie sind nicht mehr nur Empfänger des Workflows für Sicherheitsentscheidungen, sondern vollwertige Teilnehmer an eben diesem Workflow.

Dieses Modell verändert zudem die Art und Weise, wie Risiken in ihrer Gesamtheit betrachtet werden. Ein Sicherheitsteam, das darüber entscheidet, ob eine zusätzliche Authentifizierung erforderlich ist, benötigt klinische Informationen darüber, wie sich verstärkte Kontrollen auf den Notfall-Workflow auswirken. Ein Biomedizintechniker, der die Integration der Konnektivität verwalten möchte, muss alle Cloud-Segmentierungen einsehen können, die die Gerätekommunikation beeinflussen.

Sicherheitsrichtlinien, die ohne klinische Überlegungen entworfen wurden, werden häufig umgangen (nicht, weil jemand fahrlässig handelt, sondern weil sie Reibungspunkte verursachen, mit denen die direkte Patientenversorgung nicht ordnungsgemäß umgehen kann). Eine angemessene Zusammenarbeit zwischen Sicherheit und Schutz im Gesundheitswesen ist eine strukturelle Anforderung und keine optionale Best Practice.

Wie verändert die Cloud-Sicherheit im Gesundheitswesen das Modell der geteilten Verantwortung?

Das Modell der geteilten Verantwortung legt in der Regel fest, wie und wo die Sicherheitslast zwischen dem Cloud-Anbieter und dem Kunden verteilt wird. Diese Aufteilung ist in Gesundheitsumgebungen wesentlich komplexer, da das bloße Hosten von PHI die Organisation nicht von ihrer regulatorischen Verantwortung entbindet. Gleichzeitig müssen die vertraglichen Mechanismen, die diese Haftung regeln, weitaus präziser sein als diejenigen, die für Standard-Unternehmensvereinbarungen verwendet werden.

Welche Verantwortlichkeiten obliegen dem Cloud-Dienstleister und welche der Organisation im Gesundheitswesen?

Das übliche Modell der geteilten Verantwortung weist die Sicherheit der Infrastruktur dem Anbieter zu, während die Datensicherheit dem Kunden obliegt. Diese Trennung bleibt in Cloud-Umgebungen im Gesundheitswesen bestehen, doch der Umfang der jeweiligen Verpflichtungen wird erheblich erweitert, wenn es um geschützte Gesundheitsdaten (PHI) geht:

Warum können Annahmen über vom Anbieter verwaltete Schutzmaßnahmen dazu führen, dass sensible Daten und geschützte Gesundheitsdaten (PHI) offengelegt werden?

Überraschenderweise sind komplexe Angriffe nicht die Hauptursache für Sicherheitslücken in der Cloud im Gesundheitswesen. Diese Rolle spielen vielmehr Probleme aufgrund einer falsch konfigurierten Umgebung, die auf der Grundlage ungeprüfter Annahmen aufgebaut wurde.

Es ist nicht ungewöhnlich, dass Organisationen im Gesundheitswesen davon ausgehen, dass ein HIPAA-konformer Cloud-Anbieter automatisch bedeutet, dass auch die darin eingerichtete Umgebung standardmäßig HIPAA-konform ist. Diese Annahme ist falsch. Anbieter können zwar alle notwendigen technischen Funktionen bereitstellen, um die Einhaltung der Compliance-Anforderungen zu gewährleisten, doch die Konfiguration, Durchsetzung und Überprüfung der Ergebnisse dieser Funktionen liegt in der Verantwortung des Kunden.

Nehmen wir als erstes Beispiel die Verschlüsselung im Ruhezustand. Diese mag auf dem Primärspeicher standardmäßig aktiviert sein – nicht jedoch auf Backup-Ebenen, bei Protokoll-Exporten oder in temporären Verarbeitungsumgebungen, durch die geschützte Gesundheitsdaten (PHI) im Rahmen von Analyse-Workflows fließen. Die Audit-Protokollierung könnte standardmäßig aktiviert sein, jedoch nicht mit der erforderlichen Detailgenauigkeit. Objekt-Speicher-Buckets, die geschützte Gesundheitsdaten (PHI) enthalten, könnten während einer Migration mit gelockerten Zugriffsrichtlinien angelegt und anschließend nie wieder verschärft worden sein.

Jede einzelne dieser Lücken wäre im Routinebetrieb nahezu unsichtbar, würde jedoch bei einem behördlichen Audit oder einer Untersuchung von Datenschutzverletzungen deutlich ins Auge fallen.

Welche Sicherheitsmaßnahmen sollten Verträge und SLAs für Cloud-Umgebungen im Gesundheitswesen enthalten?

Eine unterzeichnete Business Associate Agreement (BAA) ist die absolute Mindestanforderung für jede Cloud-Umgebung, die mit PHI interagiert – und selbst dann reicht eine BAA allein nicht aus. Verträge für Cloud-Lösungen im Gesundheitswesen müssen Sicherheitsverpflichtungen regeln, die deutlich über die üblichen Geschäftsbedingungen hinausgehen:

• Geltungsbereich der BAA und Einbeziehung von Unterauftragsverarbeitern – die Vereinbarung muss alle Unterauftragsverarbeiter, die möglicherweise Zugriff auf PHI haben, ausdrücklich nennen oder kategorisch abdecken
• Prüfungsrechte – die Gesundheitsorganisation muss sich das Recht vorbehalten, Sicherheitsbewertungen der Umgebung des Anbieters durchzuführen oder in Auftrag zu geben
• Fristen für die Meldung von Vorfällen – Verträge sollten Benachrichtigungsfristen vom Anbieter an den Kunden festlegen, die kürzer sind als die von der HIPAA festgelegte Obergrenze von 60 Tagen, damit die Gesundheitsorganisation Zeit hat, ihre eigenen Meldepflichten zu erfüllen
• Eigentumsverhältnisse bei Verschlüsselungsschlüsseln – Vereinbarungen sollten klarstellen, ob die Gesundheitsorganisation ihre eigenen Verschlüsselungsschlüssel kontrolliert oder auf vom Anbieter verwaltete Schlüssel zurückgreift, und welchen Zugriff der Anbieter behält
• Datenaufbewahrungsort und Datenhoheit – Verträge müssen geografische Grenzen für die Speicherung und Verarbeitung von PHI festlegen, insbesondere wenn die DSGVO oder datenlokalisierungsbezogene Anforderungen auf Bundesstaatenebene gelten
• Verifizierte Datenlöschung – Kündigungsklauseln müssen eine schriftliche Bestätigung der Löschung von PHI aus allen Speicherebenen vorschreiben, einschließlich Backups und Notfallwiederherstellungsumgebungen
• Verfügbarkeits- und RTO-Verpflichtungen – Verfügbarkeitsgarantien müssen klinisch abgestimmt sein und dürfen nicht allgemeiner Natur sein

Wie verändern Interoperabilität und Datenaustausch das Bedrohungsmodell?

Cloud-Umgebungen im Gesundheitswesen können aufgrund ihrer Natur keine geschlossenen Systeme sein. Regulatorische Vorgaben, Anforderungen an die Versorgungskoordination und Verpflichtungen hinsichtlich des Patientenzugangs erfordern, dass die Daten beweglich sind – zwischen Anbietern, Patienten, Kostenträgern und Anwendungen von Drittanbietern.

Diese Offenheit ist nicht einmal ein Sicherheitsmangel, sondern eine Designanforderung. Leider trägt genau diese Anforderung auch zur massiven Ausweitung der Angriffsfläche bei, die Sicherheitsprogramme im Gesundheitswesen berücksichtigen müssen.

Warum erhöhen APIs, FHIR-Integrationen und die Anbindung an elektronische Patientenakten die Sicherheitsrisiken in der Cloud?

Der „21st Century Cures Act“ sowie die darauf folgenden Interoperabilitätsvorschriften der CMS verpflichten Organisationen im Gesundheitswesen dazu, Patientendaten über standardisierte FHIR-APIs (Fast Healthcare Interoperability Resources) bereitzustellen. Dadurch wird der externe Datenaustausch zu einer gesetzlichen Verpflichtung und ist nicht mehr nur eine architektonische Entscheidung.

Jeder API-Endpunkt, der geschützte Gesundheitsdaten (PHI) an einen autorisierten Nutzer bereitstellt, kann gleichzeitig ein potenzieller Einstiegspunkt für Unbefugte sein. Die durch Interoperabilität geschaffene Angriffsfläche ist kein Zufallsprodukt, sondern strukturell bedingt – und sie wächst mit jeder neuen Integration, die von Organisationen im Gesundheitswesen aktiviert wird.

Die Anbindung an EHR-Systeme verschärft dieses Problem noch weiter. Moderne EHR-Plattformen lassen sich regelmäßig in cloudbasierte Analyseumgebungen, Portale zur Patientenbindung, Tools zur Bevölkerungsgesundheitsanalyse und Kostenträgersysteme integrieren. Jede dieser Verbindungen stellt einen Datenfluss dar, der authentifiziert, verschlüsselt, überwacht und regelmäßig überprüft werden muss.

Das Bedrohungsmodell von Gesundheitsumgebungen ist nicht statisch, sondern erweitert sich mit jeder neu genehmigten Integration – es schrumpft jedoch selten, wenn Integrationen ersetzt oder außer Betrieb genommen werden.

Wie sollten Authentifizierung, Token-Austausch und Datenverschlüsselung für klinische Arbeitsabläufe gesichert werden?

Typische Authentifizierungsmodelle in Unternehmen funktionieren in kontrollierten Umgebungen, in denen sich Benutzer von bekannten Geräten innerhalb verwalteter Netzwerke anmelden. Klinische Arbeitsabläufe funktionieren so nicht. Ärzte müssen von gemeinsam genutzten Arbeitsplätzen, privaten Geräten und entfernten Standorten aus auf cloudbasierte Systeme zugreifen – oft unter Zeitdruck, wodurch eine umständliche Authentifizierung zu einem echten Risiko für die Patientenversorgung wird.

SMART (Substitutable Medical Applications, Reusable Technologies) auf Basis von FHIR ist ein OAuth 2.0-basiertes Autorisierungs-Framework, das speziell für klinische Anwendungskontexte entwickelt wurde und den aktuellen Standard für die Sicherung des tokenbasierten Zugriffs auf FHIR-APIs darstellt.

Die Qualität der Implementierung variiert jedoch je nach Anbieter und Einsatzszenario. Token-Ablaufzeiten, Geltungsbereichsbeschränkungen und die Handhabung von Refresh-Tokens erfordern eine explizite Konfiguration, da die Standardeinstellungen regelmäßig Komfort vor Sicherheit priorisieren.

Über die Authentifizierung hinaus ist die Durchsetzung von TLS für alle PHI-Datenflüsse zwingend erforderlich, und die Verschlüsselung sollte sich auf ruhende Daten in jedem Cloud-System erstrecken, das Informationen aus einer EHR- oder API-Integration empfängt.

Die Schlüsselbereiche, die ausdrückliche Beachtung erfordern, anstatt von Standardwerten auszugehen:

• Auf den unbedingt notwendigen Datenzugriff beschränkter Token-Gültigkeitsbereich
• Kurzlebige Zugriffstoken mit kontrollierten Aktualisierungsrichtlinien
• Gegenseitiges TLS für Server-zu-Server-API-Verbindungen
• Überprüfung der Verschlüsselung auf allen Speicherebenen, die aus APIs stammende PHI-Daten empfangen

Inwiefern erhöht die Anbindung von Drittanbieter-Apps die Risiken in der Lieferkette und durch laterale Bewegungen?

Unternehmen im Gesundheitswesen, die Anwendungen von Drittanbietern an ihre Cloud-Umgebungen anbinden, übernehmen einen Teil der Sicherheitslage jedes Anbieters – unabhängig davon, ob sie diese bewertet haben oder nicht.

Eine patientenorientierte Anwendung mit Schreibzugriff auf elektronische Patientenakten (EHR), ein Tool zur Bevölkerungsgesundheitsanalyse mit weitreichenden Berechtigungen zur Datenabfrage oder eine Abrechnungsintegration mit Zugriff auf Abrechnungs- und demografische Daten stellen jeweils einen potenziellen Einstiegspunkt in die Lieferkette dar. Wird eine Drittanbieteranwendung kompromittiert, kann ein Angreifer alle Zugriffsrechte dieser Anwendung übernehmen. In Cloud-Umgebungen des Gesundheitswesens umfasst dieser Zugriff häufig Zugangswege zu Systemen, die PHI in großem Umfang enthalten.

Regelmäßige Sicherheitsfragebögen für Anbieter reichen selten aus, um die spezifischen Risiken aufzudecken, die klinische API-Integrationen mit sich bringen, und die kontinuierliche Überwachung des Verbindungsverhaltens von Drittanbietern ist branchenweit noch immer keine einheitliche Praxis.

Warum sind Identitäts- und Zugriffskontrollen für die Cloud-Sicherheit im Gesundheitswesen von entscheidender Bedeutung?

Die Kontrolle darüber, wer unter welchen Umständen auf welche Ressourcen zugreifen darf, ist eine der größten Sicherheitsherausforderungen für jede Cloud-Umgebung. Im Gesundheitswesen wird diese Herausforderung durch die schiere Vielfalt der Personen, die Zugriff auf sensible Systeme benötigen, die Dringlichkeit, mit der dieser Zugriff manchmal erforderlich ist, sowie die schwerwiegenden Folgen sowohl einer zu strengen als auch einer zu lockeren Zugriffsbeschränkung noch weiter verstärkt.

Inwiefern unterscheiden sich die rollenbasierten und attributbasierten Zugriffsanforderungen zwischen klinischen und administrativen Nutzern?

Rollenbasierte Zugriffskontrollen (RBAC) basieren auf dem Konzept, Systemberechtigungen entsprechend der beruflichen Funktion eines Nutzers statt seiner individuellen Identität zuzuweisen. Ein Abrechnungskoordinator erhält Zugriff auf Finanzunterlagen. Ein Radiologe erhält Zugriff auf Bildgebungssysteme. Eine Stationsschwester erhält Zugriff auf die Medikamentenverabreichungsprotokolle ihrer zugewiesenen Station.

RBAC bildet die Grundlage für das Zugriffsmanagement in der Gesundheits-Cloud und minimiert erheblich die Wahrscheinlichkeit, dass Nutzer Informationen einsehen müssen, die sie aus klinischer oder betrieblicher Sicht nichts angehen (sofern korrekt implementiert).

Das Hauptproblem hierbei ist, dass Rollen im Gesundheitswesen selten in klar abgegrenzte Kategorien unterteilt werden können. Attributbasierte Zugriffskontrollen (ABAC) erweitern RBAC um verschiedene kontextbezogene Faktoren: die Abteilung, in der ein Benutzer gerade tätig ist, die Tageszeit, den konkreten Patienten, den er behandelt, oder ob er von einem zugelassenen Gerät im internen Netzwerk aus auf das System zugreift.

Ein Arzt, der in mehreren Abteilungen tätig ist, eine Fachkrankenschwester mit Zugriffsrechten in zwei Einrichtungen oder ein Pflegekoordinator, der sowohl im stationären als auch im ambulanten Bereich arbeitet – sie alle haben komplexe Zugriffsanforderungen, denen eine statische Rollendefinition nur schwer gerecht werden könnte. ABAC ermöglicht es, solche Nuancen als Richtlinie festzulegen, anstatt sie als Ausnahmen zu behandeln.

Warum ist kontextbezogener Zugriff nach dem Prinzip der geringsten Berechtigungen für Szenarien am Krankenbett und in der Notfallversorgung entscheidend?

Der Zugriff nach dem Prinzip der geringsten Berechtigungen ist eine etablierte Sicherheitspraxis – das Prinzip, dass jeder Benutzer nur Zugriff auf das absolute Minimum an Daten und Systemen haben sollte, das für seine aktuelle Aufgabe erforderlich ist. In den meisten Unternehmensumgebungen ist die Anwendung dieser Praxis vor allem eine technische und administrative Angelegenheit. Im Gesundheitswesen steht diese Praxis jedoch in erheblichem Widerspruch zur Realität der Notfallversorgung.

Ein Unfallmediziner, der einen bewusstlosen Patienten ohne Ausweis behandelt, benötigt sofortigen Zugriff auf die gesamte Krankenakte des Patienten (seine Allergieanamnese, aktuelle Medikamente und frühere Diagnosen). Die Tatsache, dass dieser Arzt möglicherweise keine vorherige Behandlungsbeziehung zu dem Patienten hatte, bedeutet, dass eine strikte Durchsetzung des Modells der geringsten Berechtigungen genau den Zugriff blockieren wird, den die medizinische Versorgung erfordert.

An dieser Stelle kommt das „Break-Glass“-Zugriffsmodell ins Spiel. Es handelt sich um einen kontrollierten Überbrückungsmechanismus, der es medizinischem Personal ermöglicht, in echten Notfällen die üblichen Zugriffsbeschränkungen zu umgehen, wobei jede während dieser Sitzung durchgeführte Aktion zur späteren Überprüfung protokolliert wird.

Der „Break-Glass“-Zugriff ist keine Sicherheitslücke, sondern ein bewusst eingerichtetes, überprüfbares Sicherheitsventil. Er kann jedoch zu einem Sicherheitsrisiko werden, wenn sein Anwendungsbereich schlecht definiert ist, die Protokollierung uneinheitlich erfolgt oder er so häufig genutzt wird, dass er seine Bedeutung als Ausnahme verliert.

Aus diesem Grund sind kontextbezogene Zugriffsrichtlinien erforderlich. Sie berücksichtigen den Aufenthaltsort des Patienten, die Zuordnung zum Behandlungsteam und die klinische Dringlichkeit, um die Häufigkeit der Nutzung des „Break-Glass“-Modells zu reduzieren, ohne es als Option vollständig auszuschließen.

Wie sollten temporäre, bedingte und Anbieterzugriffe geregelt und geprüft werden?

Cloud-Umgebungen im Gesundheitswesen beherbergen häufig Nutzer, deren Zugriffsbedarf standardmäßig zeitlich begrenzt ist. Dazu gehören reisende Pflegekräfte und Vertretungsärzte, die kurzfristige Ausfälle überbrücken, Drittanbieter, die Systemwartungen durchführen, Implementierungsberater mit temporären Administratorrechten sowie externe Prüfer, die Compliance-Unterlagen überprüfen. Die Gewährung von Zugriffsrechten an einen dieser Nutzer stellt ein Risiko dar, das sich ständig vergrößert, wenn es nicht aktiv verwaltet wird.

Die Kernanforderungen sind klar, auch wenn die konsequente Umsetzung dies nicht immer ist:

• Zugriffsberechtigungen für temporäre Nutzer sollten explizite Ablaufdaten enthalten, die zum Zeitpunkt der Bereitstellung festgelegt werden
• Der Zugriff von Anbietern und Dritten sollte auf die spezifischen Systeme und Daten beschränkt sein, die für den jeweiligen Auftrag erforderlich sind – nicht darüber hinaus
• Alle temporären Zugriffssitzungen sollten mit ausreichenden Details protokolliert werden, um einen lückenlosen Prüfpfad zu gewährleisten
• Zugriffsprüfungen sollten proaktiv geplant werden und nicht erst durch Ereignisse wie das Ausscheiden von Mitarbeitern ausgelöst werden

Die häufigste Fehlerquelle ist nicht einmal böswilliger, sondern administrativer Natur. Dazu gehören temporäre Zugangsdaten, die nie widerrufen wurden, Lieferantenkonten, die über die Dauer des Auftrags hinaus bestanden, und der Zugriff von Auftragnehmern, der sich schrittweise ohne formelle Überprüfung ausweitete.

Wie verändern Medizinprodukte und das Internet der Dinge (IoT) die Anforderungen an die Cloud-Sicherheit?

Medizinprodukte und vernetzte klinische Geräte bilden eine eigene Risikokategorie, die durch Standard-IoT-Richtlinien nicht angemessen abgedeckt werden kann. Bei solchen Geräten handelt es sich nicht um bloße Gebäudesensoren oder intelligente Thermostate, sondern um sicherheitskritische Systeme mit direkten Auswirkungen auf die Patienten – weshalb sich die Sicherheitsauflagen, unter denen sie betrieben werden, erheblich von allen anderen Aspekten einer typischen Cloud-Umgebung unterscheiden.

Warum sind Gerätebeschränkungen (veraltete Betriebssysteme, eingeschränkte Patch-Möglichkeiten) für die Cloud-Integration wichtig?

Viele medizinische Geräte (Infusionspumpen, Bildgebungssysteme, Patientenmonitore, Beatmungsgeräte) verwenden veraltete Betriebssysteme. Windows 7, Windows XP und sogar noch ältere Plattformen sind bis heute im klinischen Einsatz. Dies ist in der Regel dann der Fall, wenn die Gerätehersteller ihre Software für eine bestimmte Betriebssystemversion entwickeln und zertifizieren, was bedeutet, dass ein Austausch oder eine Aktualisierung dieser Software eine erneute vollständige behördliche Prüfung durch die FDA erfordern würde.

Dies ist der Hauptgrund dafür, dass Patches – der grundlegendste Mechanismus zur Behebung von Software-Schwachstellen – für einen Großteil der Geräte, die mit Cloud-Umgebungen im Gesundheitswesen verbunden sind, nicht verfügbar sind.

Ein Gerät, das nicht gepatcht werden kann, kann im herkömmlichen Sinne auch nicht als sicher angesehen werden. Jedes Mal, wenn diese Geräte Telemetriedaten an Cloud-Plattformen übertragen oder Konfigurationsaktualisierungen von in der Cloud gehosteten Managementsystemen empfangen müssen, muss die Sicherheit dieser Verbindung ausschließlich auf der Netzwerk-/Cloud-Seite gewährleistet werden, da das Gerät selbst in dieser Hinsicht kaum etwas beitragen kann.

Wie sollten Telemetrie, Geräteidentität und Segmentierung für sicherheitskritische Geräte gestaltet werden?

Netzwerksegmentierung ist die erste Verteidigungslinie in Umgebungen des Gesundheitswesens. Medizinische Geräte sollten in isolierten Netzwerksegmenten gehalten werden, die nur Zugriff auf die jeweiligen Cloud-Systeme haben, die sie benötigen. Ein Patientenmonitor sollte keine Verbindung zu Cloud-Speichern, Verwaltungsservern, externen Netzwerken oder anderen Zielen als eben jenem bestimmten Cloud-System herstellen können. Die Segmentierung behebt zwar nicht die Schwachstelle des Geräts selbst, kann jedoch zumindest den „Schadensradius“ einer der ausgenutzten Schwachstellen begrenzen.

Geräteidentität ist ebenso wichtig. Jedes Gerät, das eine Verbindung zu einer Cloud-Umgebung herstellt, muss seine Identität anhand einer eindeutigen Berechtigung nachweisen (im Idealfall durch ein am Gerät angebrachtes Zertifikat, nicht nur durch einfache Anmeldedaten). Auf diese Weise können Geräte mit unerwarteten Verhaltensmustern identifiziert und behandelt werden, ohne andere Geräte im selben Netzwerk zu beeinträchtigen. Ein weiterer Vorteil ist die Möglichkeit, zu jedem beliebigen Zeitpunkt ein genaues Bestandsverzeichnis der verbundenen Geräte zu führen.

Telemetrie-Ströme von medizinischen Geräten müssen ebenfalls auf Anomalien überwacht werden. Jede Art von ungewöhnlichem Muster kann ein Hinweis auf eine Kompromittierung oder Fehlkonfiguration sein (sei es ungewöhnliches Datenvolumen, unerwartete Verbindungsziele oder Kommunikationsmuster, die außerhalb des normalen Verhaltens eines Geräts liegen).

Inwiefern können cloudseitige Analysen Datenschutzrisiken für gerätegenerierte Daten mit sich bringen?

Im Zusammenhang mit Gerätetelemetrie herrscht häufig die Annahme, dass solche Daten von Natur aus wenig sensibel seien und eher Maschinenausgaben als geschützte Gesundheitsdaten (PHI) ähnelten. Diese Annahme ist oft falsch.

Kontinuierliche Datenströme von Geräten wie Blutzuckermessgeräten, Herz-Telemetriegeräten oder Atemüberwachungsgeräten können genügend Informationen enthalten, um bestimmte Patienten zu identifizieren, Diagnosen abzuleiten und Behandlungsverläufe zu rekonstruieren (selbst nach Entfernung offensichtlicher Identifikatoren). Wann immer solche Daten an cloudbasierte Analyseplattformen übertragen werden, können sie aggregiert, gespeichert, an externe Analyseanbieter weitergegeben oder sogar auf ungewöhnliche Weise zum Trainieren von Modellen verwendet werden.

Das Risiko einer Re-Identifizierung bei gerätegenerierten Gesundheitsdaten ist erheblich und wird oft unterschätzt. Aufgrund der kritischen Bedeutung dieser Informationen verdienen sie mindestens denselben Umgang wie geschützte Gesundheitsdaten (PHI), der für alle als Krankenakte gekennzeichneten Daten gilt.

Was erkennen Organisationen im Gesundheitswesen in der Regel erst zu spät, nachdem sie sensible Daten in die Cloud verlagert haben?

Im Gesundheitswesen schreitet die Einführung der Cloud oft schneller voran als die Entwicklung der Sicherheitsprogramme, die sie unterstützen sollen. Sicherheitslücken, die infolge dieses Problems entstehen, bleiben oft unbemerkt, bis etwas schiefgeht.

Warum kommt es in technisch konformen Cloud-Umgebungen immer noch zu Datenschutzverletzungen im Gesundheitswesen?

Prüfungen der Einhaltung gesetzlicher Vorschriften können lediglich messen, ob die erforderlichen Sicherheitskontrollen zu einem bestimmten Zeitpunkt vorhanden sind. Solche Tests können nicht feststellen, ob diese Kontrollen auch noch mehrere Monate später, nachdem sich die Umgebung um sie herum verändert hat, korrekt funktionieren werden.

Die Cloud-Infrastruktur selbst ist selten statisch und inaktiv. Entwickler richten neue Speicherressourcen ein, es kommen regelmäßig neue Systemintegrationen hinzu, und Berechtigungen werden oft angepasst, um Zugriffsprobleme schnell zu beheben (und anschließend nie überprüft). Keine dieser Änderungen löst für sich genommen eine Compliance-Prüfung aus, doch jede einzelne dieser Änderungen kann dennoch als Gelegenheit betrachtet werden, dass die Umgebung von dem Zustand abweicht, der beim letzten Audit zum Bestehen geführt hat.

Themen wie diese müssen angesprochen werden, da Fehlkonfigurationen bis heute die Hauptursache für Datenschutzverletzungen in der Cloud bleiben – keine der ausgeklügelten staatlich gestützten Angriffe oder Zero-Day-Exploits kommt auch nur annähernd daran heran. Ein erheblicher Teil der Cloud-Vorfälle im Gesundheitswesen ist auf Folgendes zurückzuführen:

• Ungeschützte Speicher-Buckets
• Zu großzügige Zugriffsrichtlinien
• Deaktivierte Protokollierung

Es kommt nicht selten vor, dass eine Organisation im Gesundheitswesen ein HIPAA-Audit besteht und nur wenige Monate später einen vermeidbaren Datenverstoß erleidet. Zum Zeitpunkt des Audits war an der Umgebung der Organisation nichts auszusetzen, doch die Umgebung selbst hat sich verändert. Aus diesem Grund ist Compliance ein Status und keine Garantie.

Wie schwächen Annahmen zur Cloud-Migration still und leise die Cloud-Sicherheit im Gesundheitswesen?

Der schlimmste Fehler, den man bei einer Migration begehen kann, ist die Annahme, dass Sicherheitskontrollen aus der lokalen Umgebung nach ihrer Übertragung in die Cloud genau so funktionieren werden wie zuvor. Dieser Ansatz wird manchmal als „Lift-and-Shift“ bezeichnet – dabei werden bereits vorhandene Workloads in die Cloud-Infrastruktur verlagert, ohne Änderungen zur Anpassung an die neue Umgebung vorzunehmen. Dies ist zwar eine schnelle Lösung für manche Probleme, birgt jedoch auch ein extrem hohes Risiko.

• Firewall-Regeln, die ein Rechenzentrum geschützt haben, gelten nicht für Cloud-Speicher-Buckets
• Netzwerkperimeter, die laterale Bewegungen vor Ort eindämmten, existieren in einer Cloud-Umgebung nicht in derselben Form
• Zugriffskontrollen, die ein internes IT-Team manuell verwaltet hat, werden nicht zusammen mit den Daten migriert und müssen in der Cloud gezielt neu eingerichtet werden

Die Hauptursache für nahezu alle migrationsbedingten Sicherheitsrisiken liegt letztlich in der Unklarheit hinsichtlich des Modells der geteilten Verantwortung. Unternehmen, die ihre Daten zu einem Cloud-Anbieter migrieren, gehen davon aus, dass die Sicherheitsstandardkonfigurationen des Anbieters das abdecken, was ihr internes Team zuvor vor Ort erledigt hat – dies ist jedoch nicht der Fall.

Eine der am häufigsten dokumentierten Erkenntnisse nach einer Migration betrifft IAM-Rollen (Identity and Access Management) mit übermäßigen Berechtigungen: Konfigurationen, die während der Migration mit weitreichenden Zugriffsrechten erstellt wurden, um Reibungsverluste zu vermeiden, als vorübergehend gekennzeichnet und anschließend nie entfernt wurden. Diese Rollen können lange Zeit passiv in der Umgebung bestehen bleiben und Angreifern, denen der Zugriff darauf gelingt, weitaus mehr Zugriffsmöglichkeiten bieten, als einem einzelnen Benutzer jemals gewährt werden sollten.

Probleme wie diese sind niemals dramatisch oder offensichtlich, da die Systeme weiterlaufen, Protokolle weiterhin erstellt werden und so weiter. Die Probleme treten erst während eines Vorfalls zutage, wenn sich herausstellt, dass auf den falsch konfigurierten Bucket monatelang zugegriffen werden konnte oder dass die Rolle mit übermäßigen Berechtigungen Lesezugriff auf jeden PHI-Datensatz in der Umgebung besitzt.

Warum sind Fehler bei der Datensicherung und -wiederherstellung oft schädlicher als der ursprüngliche Cloud-Angriff?

Viele Cloud-Angriffe können den Betrieb nur vorübergehend stören. Ein fehlgeschlagener Wiederherstellungsvorgang hingegen droht, diese Störung auf unbestimmte Zeit zu verlängern.

Es ist nicht ungewöhnlich, dass Organisationen im Gesundheitswesen während Ransomware-Angriffen – also genau dann, wenn sie es sich am wenigsten leisten können – kritische Probleme mit ihren Cloud-Backups entdecken. Dazu gehören:

• Backups wurden in derselben Umgebung wie die Primärsysteme gespeichert und zusammen mit diesen verschlüsselt
• Backup-Jobs wurden auf dem Dashboard erfolgreich abgeschlossen – doch die wiederhergestellten Daten waren unvollständig oder beschädigt
• Die Wiederherstellung war noch nie in einem realistischen Szenario durchgängig getestet worden
• Die Aufbewahrungsrichtlinien waren falsch festgelegt, sodass die Wiederherstellungspunkte zu weit zurücklagen, um klinisch nutzbar zu sein

Der zweite Punkt bezüglich der Backup-Berichterstattung verdient besondere Beachtung. Backup-Dashboards melden naturgemäß den Abschluss eines Jobs, nicht jedoch den Erfolg der Wiederherstellung. Es ist durchaus möglich, dass ein Auftrag fehlerfrei abgeschlossen wird, während dabei ein Backup erstellt wird, das nicht zur Wiederherstellung eines funktionsfähigen Systems verwendet werden kann. Die einzige Möglichkeit, festzustellen, ob ein Backup funktioniert, besteht darin, es zu testen – doch genau diese Tests werden von viel zu vielen Unternehmen regelmäßig übersprungen.

Unveränderliche Backups sind die direkte Gegenmaßnahme gegen Backup-Risiken im Zeitalter der Ransomware. Dabei handelt es sich um Kopien, die nur einmal geschrieben werden können, ohne dass sie anschließend geändert, gelöscht oder verschlüsselt werden können. Unveränderlichkeit verhindert zwar keinen Angriff, kann aber sicherstellen, dass eine Wiederherstellung nach einem Angriff weiterhin möglich ist.

Das Fehlen unveränderlicher Backups ist ein kritisches Problem, da viele Ransomware-Angreifer, die über ausreichenden Zugriff auf Primärsysteme verfügen, oft auch Zugriff auf Backups haben und damit das Potenzial besitzen, jegliche Backup-Pläne im Kern zu zunichte zu machen.

Wie verläuft typischerweise ein moderner Datenverstoß in der Cloud im Gesundheitswesen?

Sicherheitsverletzungen in Cloud-Umgebungen im Gesundheitswesen beginnen selten mit einem komplexen technischen Exploit. Diese Vorfälle gehen auf eine Person zurück und eskalieren von dort aus rasch.

Wie gelangen Angreifer vom Phishing zur Kompromittierung cloudbasierter Gesundheitssysteme?

Eine einzige E-Mail reicht in der Regel aus, um die gesamte Kette in Gang zu setzen. Jeder Mitarbeiter könnte auf einen Link klicken, der wie eine routinemäßige IT-Identifizierung oder eine Aktualisierung des Patientenportals aussieht. Sobald er seine Anmeldedaten eingibt, wechselt der Angriff in eine andere Phase.

Der Weg vom Phishing zum Zugriff auf die Cloud-Umgebung ist viel kürzer, als die meisten Unternehmen annehmen, da viele Mitarbeiter im Gesundheitswesen nach wie vor dieselben Zugangsdaten für verschiedene Systeme verwenden (während Cloud-Verwaltungskonsolen über jeden Browser zugänglich sind).

Ein Angreifer muss keine Sicherheitsgrenzen überwinden, wenn er über eine gültige Kombination aus Benutzername und Passwort verfügt – er kann sich einfach als eine beliebige andere Person anmelden.

Nach dem Eindringen verlagert sich der Fokus auf Ausweitung und Persistenz. Der Angreifer versucht, Cloud-Speicherumgebungen mit den größten Datenmengen, Dienstkonten mit den weitreichendsten Berechtigungen sowie verbundene Systeme ausfindig zu machen, die zum Erlangen weiterer geschützter Gesundheitsdaten (PHI) genutzt werden könnten.

Die meisten Cloud-Angriffe im Gesundheitswesen erreichen bereits innerhalb weniger Tage nach dem ersten Eindringen das Stadium, in dem geschützte Gesundheitsdaten (PHI) abgezogen werden. Bis das anomale Verhalten erkannt wird, ist es sehr wahrscheinlich, dass der Angreifer sein angestrebtes Ziel bereits erreicht hat.

Warum werden Cloud-Speicherplattformen und APIs im Gesundheitswesen zunehmend ins Visier genommen?

Sowohl APIs im Gesundheitswesen als auch Cloud-Speicherplattformen werden in erster Linie wegen ihrer enormen Rentabilität ins Visier genommen.

Ein einziger falsch konfigurierter Cloud-Speicher-Bucket in einer Gesundheitsumgebung reicht aus, um Millionen von Patientenakten offenzulegen. Gleichzeitig würden kompromittierte API-Zugangsdaten einen kontinuierlichen, authentifizierten Zugriff auf einen Datenstrom ermöglichen, der in Echtzeit aktualisiert wird.

Gesundheitsdaten sind auf kriminellen Märkten ein weitaus wertvolleres Gut als Finanzdaten. Eine vollständige Krankenakte ist um ein Vielfaches mehr wert als eine Kreditkartennummer, da sie Daten enthält, die unveränderlich sind und über einen längeren Zeitraum auf vielfältige Weise genutzt werden können.

Die leichte Zugänglichkeit von APIs macht sie ebenfalls zu attraktiven Zielen. Eine API ist notwendig, um Informationen nahtlos zwischen Systemen auszutauschen, wodurch sie in großem Maßstab erreichbar, funktionsfähig und abfragbar sind, ohne in der Umgebung viele Alarmsignale auszulösen.

Welche betrieblichen Störungen treten auf, nachdem Angreifer Zugriff auf Cloud-Umgebungen im Gesundheitswesen erlangt haben?

Ein Sicherheitsvorfall in einer Cloud-Umgebung im Gesundheitswesen hat weitreichende klinische und betriebliche Auswirkungen, die über die kompromittierten Systeme selbst hinausgehen. Zu den üblichen Störungen zählen:

• Nichtverfügbarkeit der elektronischen Patientenakte (EHR) – Ärzte verlieren den Zugriff auf Medikamentenverläufe, Behandlungspläne und Diagnoseergebnisse, was einen Wechsel zu manuellen, papierbasierten Prozessen erzwingt
• Umgeleitete Rettungswagen – Krankenhäuser, die nach Notfallprozeduren arbeiten, können interne Notfälle ausrufen, wodurch ankommende Patienten an andere Einrichtungen umgeleitet werden
• Abgesagte Eingriffe – elektive und nicht dringende Operationen, Termine für bildgebende Untersuchungen sowie ambulante Besuche werden verschoben, wenn die Systeme, die die Vorabprüfungen unterstützen, offline sind
• Verzögerungen in der Apotheke und bei der Medikamentenausgabe – elektronische Verschreibungssysteme fallen aus, was Risiken bei der Verabreichung von Medikamenten mit sich bringt
• Stillstand bei Abrechnung und Leistungsabrechnung – Systeme des Umsatzzyklus, die auf Cloud-Infrastruktur angewiesen sind, stellen die Verarbeitung ein, was zu finanziellen Rückständen führt, die noch lange nach der Wiederherstellung der klinischen Systeme bestehen bleiben
• Regulatorische und rechtliche Risiken – Meldepflichten bei Datenschutzverletzungen treten sofort in Kraft und verursachen zusätzlichen Compliance-Aufwand, während die Wiederherstellung des Betriebs gleichzeitig die maximale organisatorische Kapazität beansprucht

Die klinischen Störungen könnten innerhalb weniger Tage oder Wochen behoben werden, doch die regulatorischen, rechtlichen und rufschädigenden Folgen eines einzigen Angriffs dauern in der Regel wesentlich länger an.

Warum müssen Incident Response und Forensik speziell auf Cloud-Lösungen im Gesundheitswesen zugeschnitten sein?

Das primäre Ziel der Incident Response in den meisten Branchen ist es, die Bedrohung einzudämmen und die Umgebung wiederherzustellen. Im Gesundheitswesen kommt ein weiteres Ziel hinzu: die Sicherheit der Patienten während des gesamten Prozesses zu gewährleisten. Diese beiden Ziele weisen zudem nicht immer in dieselbe Richtung.

Inwiefern verändert die Notwendigkeit einer schnellen klinischen Kontinuität die Strategien zur Eindämmung von Vorfällen?

Standardmäßige Vorgehensweisen bei der Incident Response stützen sich stark auf Isolierung. Wann immer ein System kompromittiert wird, wird es offline geschaltet und vom Netzwerk getrennt, um eine Ausbreitung des Angriffs zu verhindern. Dies ist ein guter Ansatz für die meisten Systeme, die den Geschäftsbetrieb unterstützen. Leider gilt dies nicht für Systeme, die die aktive Patientenversorgung unterstützen.

Wird eine elektronische Patientenakte (EHR) während eines aktiven Vorfalls offline geschaltet, wird dem medizinischen Personal der Zugriff auf Medikamentenakten, Allergieanamnesen und Live-Überwachungsdaten verwehrt. Der Versuch, eine Cloud-Umgebung zu isolieren, die die Telemetrie auf der Intensivstation oder die Medikamentenausgabe in der Apotheke unterstützt, birgt ein direktes klinisches Risiko. Die Eindämmungsmaßnahme selbst kann Schaden anrichten, weshalb Vorfallreaktionsteams im Gesundheitswesen nicht einfach dem üblichen Leitfaden folgen können, nach dem alle arbeiten.

Hier ist ein gezielterer Ansatz erforderlich. Anstelle einer pauschalen Isolierung benötigen IR-Teams im Gesundheitswesen vordefinierte Eindämmungsstrategien, die zwischen Systemen unterscheiden können, die offline geschaltet werden können, und Umgebungen, die unter allen Umständen verfügbar bleiben müssen. All diese Entscheidungen müssen lange vor dem Eintreten eines Vorfalls getroffen werden, da Echtzeitentscheidungen darüber, welche klinischen Systeme während einer Sicherheitsverletzung sicher unterbrochen werden können, ein hohes Risiko darstellen.

Welche forensischen Kontrollmaßnahmen und Protokollierungen sind erforderlich, um sowohl rechtliche als auch klinische Untersuchungen zu unterstützen?

Die meisten typischen Cloud-Sicherheitsverletzungen im Gesundheitswesen erfordern mindestens zwei parallele Untersuchungen:

1. Die Überprüfung hinsichtlich Compliance und Rechtsstreitigkeiten
2. Die Überprüfung der Auswirkungen auf klinische Daten und Entscheidungen zur Patientenversorgung

Das entscheidende Element, nach dem bei jeder Untersuchung gesucht wird, basiert auf genau denselben Beweisen: den Protokollen. Praktisch der gesamte forensische Wert einer Cloud-Umgebung wird durch Protokollierungsentscheidungen bestimmt, die lange vor dem Vorfall getroffen wurden. Beweise, die nicht erfasst wurden, können auch nachträglich nicht wiederhergestellt werden.

Zu den zentralen Protokollierungsanforderungen für Cloud-Umgebungen im Gesundheitswesen gehören:

• Zugriffsprotokolle, die jede Interaktion mit geschützten Gesundheitsdaten (PHI) erfassen – wer darauf zugegriffen hat, wann, von wo aus und welche Aktionen durchgeführt wurden
• Authentifizierungsprotokolle, einschließlich fehlgeschlagener Anmeldeversuche, Umgehungen der Multi-Faktor-Authentifizierung (MFA) und Privilegienerweiterungen
• API-Aufrufprotokolle, die alle Anfragen an Cloud-Management-Schnittstellen und APIs für Gesundheitsdaten erfassen
• Netzwerkflussprotokolle, die ausreichen, um laterale Bewegungen und Wege der Datenexfiltration zu rekonstruieren
• Konfigurationsänderungsprotokolle, die Änderungen an Speicherberechtigungen, IAM-Rollen und Sicherheitsgruppenregeln nachverfolgen

Die Aufbewahrungsfristen dieser Protokolle sollten sowohl mit der sechsjährigen Dokumentationspflicht gemäß HIPAA als auch mit allen geltenden staatlichen Vorschriften in Einklang stehen. Protokolle sollten getrennt von den Systemen gespeichert werden, die sie überwachen, um zu verhindern, dass ein Angreifer, der sich Zugang zur primären Infrastruktur verschafft hat, die Beweismittel verändert oder löscht.

Inwiefern sollten Tabletop-Übungen und Playbooks sich von reinen Unternehmensszenarien unterscheiden?

An den meisten Tabletop-Übungen zur Incident-Response (IR) in Unternehmen sind in der Regel die IT- und Sicherheitsteams beteiligt (manchmal nehmen auch Rechts- und Kommunikationsteams teil). Tabletop-Übungen im Gesundheitswesen erfordern einen deutlich größeren Rahmen – und deutlich andere Szenarien.

Die Leitung des klinischen Betriebs sollte anwesend sein, da Entscheidungen darüber, welche Systeme offline geschaltet werden sollen, unter klinischer Aufsicht getroffen werden müssen. Die Biomedizintechnik muss einbezogen werden, wann immer Szenarien vernetzte Geräte betreffen. Datenschutzbeauftragte müssen an den Entscheidungsabläufen bezüglich der Meldung von Datenschutzverletzungen beteiligt sein.

Die Szenarien selbst sollten gesundheitsspezifische Bedrohungen widerspiegeln:

• Ransomware, die sowohl primäre EHR-Systeme als auch Cloud-Backups gleichzeitig verschlüsselt
• Kompromittierte API-Anmeldedaten, die über einen längeren Zeitraum stillschweigenden Zugriff auf Patientendaten ermöglichen
• Eine Fehlkonfiguration in der Cloud, durch die geschützte Gesundheitsdaten (PHI) für einen unbekannten Zeitraum öffentlich zugänglich waren
• Eine Sicherheitsverletzung bei einem Drittanbieter, die sich über eine aktive Integration in die Cloud-Umgebung der Gesundheitsorganisation ausbreitet

Ein Playbook kann im Gesundheitswesen nicht als ausreichend angesehen werden, wenn es nicht die Aktivierung von Ausfallprozeduren enthält (manuelle Arbeitsabläufe, auf die das klinische Personal zurückgreift, wenn Systeme nicht verfügbar sind). Dieser Abschnitt der Reaktion birgt das größte Risiko für die Patientensicherheit und fehlt am häufigsten in Plänen, die aus nicht-klinischen Branchen übernommen wurden.

Warum ist Cloud-Sicherheit im Gesundheitswesen schwieriger als herkömmliche Cloud-Sicherheit in Unternehmen?

Alle Branchen stehen in gewissem Maße vor Herausforderungen im Bereich der Cloud-Sicherheit, und das Gesundheitswesen bildet da keine Ausnahme – es bringt sogar eine Reihe von Einschränkungen mit sich, die in keiner anderen Branche vorkommen. Die Schwierigkeit der Cloud-Sicherheit im Gesundheitswesen ist struktureller, nicht technischer Natur.

Warum können Gesundheitsdienstleister nicht einfach den gesamten Cloud-Zugriff einschränken?

Das Gesundheitswesen hat den Punkt bereits überschritten, an dem eine Einschränkung eine tragfähige Strategie wäre. Viele der modernen Elemente einer Gesundheitsumgebung sind ohne Cloud-Speicher nahezu unmöglich. Zum Beispiel:

• Klinische Arbeitsabläufe sind auf in der Cloud gehostete EHR-Plattformen angewiesen
• Patienten erwarten den Zugriff auf ihre Unterlagen über Online-Portale
• Die Telemedizin läuft auf einer Cloud-Infrastruktur
• Bildgebungsdaten werden über die Cloud gespeichert und übertragen, da die damit verbundenen Dateigrößen eine lokale Speicherung in großem Maßstab unpraktisch machen

Eine nennenswerte Einschränkung des Cloud-Zugangs im Gesundheitswesen wird die Sicherheit nicht erhöhen, sondern den Betrieb unmöglich machen. Die Frage ist niemals, ob der Cloud-Zugang erlaubt oder verweigert werden soll – es geht darum, den Cloud-Zugang so sicher wie möglich zu gestalten, ohne die damit unterstützte Versorgung zu beeinträchtigen.

Inwiefern führen Arbeitsabläufe in der Notfallversorgung zu unvermeidbaren Kompromissen bei der Cloud-Sicherheit?

Sicherheitsrichtlinien folgen nicht denselben Zeitvorgaben wie die Notfallversorgung. Ein Traumateam, das sich um einen Patienten in kritischem Zustand kümmert, würde nicht warten, bis ein mehrstufiger Authentifizierungsprozess abgeschlossen ist. Ein Arzt, der um 3 Uhr morgens auf einer ihm unbekannten Station aushilft, wird nicht auf die Genehmigung einer Zugriffsanfrage warten, während er die Krankengeschichte eines Patienten mit sich verschlechterndem Zustand einsehen muss.

Die Natur der Notfallversorgung bringt es mit sich, dass alle Sicherheitskontrollen, die Reibungsverluste verursachen, umgangen und nicht befolgt werden. Im Gesundheitswesen sind diese Umgehungen zudem oft klinisch gerechtfertigt, was es extrem schwierig macht, sie allein durch Richtlinien zu verhindern.

Strengere Sicherheitskontrollen mögen das Risiko unter stabilen Bedingungen verringern, erhöhen es jedoch in Notfallsituationen. Dieser Zielkonflikt ist real und völlig unvermeidbar. Sicherheit in einer Gesundheitseinrichtung sollte nicht als Mittel zum Zweck betrachtet werden, sondern als eine Liste fundierter, dokumentierter Entscheidungen darüber, wo diese Risiken akzeptiert werden können (unter Berücksichtigung klinischer Aspekte, nicht nur der Sicherheit).

Warum birgt der kontinuierliche Datenzugriff besondere Cybersicherheitsrisiken in Gesundheitssystemen?

Die meisten Unternehmenssysteme weisen in der Regel natürliche Rhythmen auf, darunter:

• Nutzungsspitzen während der Geschäftszeiten
• Geringere Aktivität über Nacht
• Wartungsfenster am Wochenende

Dies trifft auf Gesundheitssysteme nicht zu. EHR-Plattformen, in der Cloud gehostete Apothekensysteme und Patientenüberwachungsumgebungen laufen rund um die Uhr, an jedem Tag des Jahres, mit voller Auslastung.

Die kontinuierliche Verfügbarkeit schließt bestimmte Optionen aus, auf die sich Sicherheitsteams in Unternehmen regelmäßig stützen. Die Planung von Ausfallzeiten für das Patch-Management wird im Wesentlichen zu einer Diskussion über das klinische Risikomanagement. Systeme, die darauf ausgelegt sind, Anomalien im normalen Netzwerkverkehr zu erkennen, müssen berücksichtigen, dass es im Gesundheitswesen nur sehr wenige Auslastungsspitzen im herkömmlichen Sinne gibt.

Ein stets aktives System ist ein System, das ständig Angriffen ausgesetzt ist. Der Aufbau von Sicherheit unter diesen Rahmenbedingungen erfordert einen völlig anderen Ansatz als bei der Absicherung der meisten anderen Infrastrukturen in anderen Branchen.

Wie verändert die Cloud-native Architektur die Cloud-Sicherheit in Umgebungen des Gesundheitswesens?

Traditionelle IT-Umgebungen im Gesundheitswesen basierten auf großen, zentralisierten Anwendungen, bei denen sich Daten an erwarteten Speicherorten befanden und Sicherheitsgrenzen leicht zu definieren waren. Das Aufkommen der Cloud-nativen Architektur hat diese beiden Faktoren gleichzeitig verändert.

Warum erfordern Microservices, Container und serverlose Lösungen eine neue Bedrohungsmodellierung für PHI?

In einer traditionellen monolithischen Anwendung findet der Großteil der Funktionalität innerhalb desselben Systems statt. Der Ablauf ist einfach: PHI wird empfangen, verarbeitet und gespeichert. All dies geschieht innerhalb eines einzigen Systems mit relativ gut nachvollziehbaren Sicherheitsgrenzen.

Cloud-native Anwendungen verhalten sich anders. Eine Mikroservices-Architektur zerlegt diese eine Anwendung in Dutzende oder Hunderte kleinerer Dienste, die unabhängig voneinander sind, aber über das Netzwerk miteinander kommunizieren können. Jeder dieser Dienste kann PHI kurzzeitig verarbeiten (empfangen, umwandeln, weiterleiten), ohne sie dauerhaft zu speichern.

Dieser moderne Ansatz ist zwar äußerst effizient, bedeutet aber auch, dass PHI ständig durch eine große Anzahl von Komponenten fließt, wobei jede Komponente einen potenziellen Sicherheitsrisikopunkt darstellt.

Container – kleine, portable Pakete, in denen einzelne Dienste ausgeführt werden – sind von Natur aus kurzlebig, sodass sie entstehen, ihre Aufgabe erfüllen und dann wieder verschwinden können. Gerade diese Eigenschaft von Containern macht sie besonders problematisch, wenn es um eine konsistente Überwachung und das Aufspielen von Sicherheitspatches im herkömmlichen Sinne geht.

Serverlose Funktionen führen diesen Ansatz noch einen Schritt weiter: Der Code wird als Reaktion auf einen Auslöser ausgeführt, läuft kurz und wird dann beendet. Auf diese Weise gibt es keinen persistenten Server, der überwacht oder gesichert werden muss – zumindest nicht auf herkömmliche Weise. Wann immer PHI eine serverlose Funktion durchläuft, bleibt das Zeitfenster für deren Beobachtung und Protokollierung sehr klein.

All diese Merkmale und Ansätze erfordern ein Bedrohungsmodell, das wesentlich verteilter ist als alles, wofür die traditionelle IT-Sicherheit im Gesundheitswesen ursprünglich konzipiert wurde.

Wie sollten CI/CD-Pipelines und DevSecOps an die Compliance-Anforderungen im Gesundheitswesen angepasst werden?

Eine CI/CD-Pipeline (Continuous Integration und Continuous Deployment) ist ein automatisierter Mechanismus, der von Entwicklern geschriebenen Code übernimmt, testet und in die Produktion überführt. Ein solcher Prozess kann im Kontext cloud-nativer Umgebungen sehr schnell ablaufen. Neue Konfigurationen, aktualisierte Dienste und geänderte Zugriffsrichtlinien können innerhalb weniger Minuten in Betrieb genommen werden.

Sind die Sicherheitsprüfungen nicht von Anfang an in die Pipeline integriert, wird diese Geschwindigkeit zu einem Compliance-Risiko. DevSecOps bezeichnet die Praxis, Sicherheitsüberprüfungen in den Entwicklungs- und Bereitstellungsprozess einzubetten, anstatt sie anschließend separat zu überprüfen.

Was dies im Gesundheitswesen bedeutet:

• Automatisches Scannen des Infrastrukturcodes auf Fehlkonfigurationen vor der Bereitstellung
• Kennzeichnung von Speicherressourcen oder API-Endpunkten, die geschützte Gesundheitsdaten (PHI) ohne Verschlüsselung offenlegen würden
• Blockierung von Bereitstellungen, die erforderliche Audit-Protokollierung entfernen würden
• Überprüfung, ob neue Dienste die BAA-relevanten Sicherheitsanforderungen erfüllen, bevor sie in die Produktion gelangen

Das Aufdecken von Compliance-Lücken zu dem Zeitpunkt, zu dem ihre Behebung am kostengünstigsten ist (bevor der Code live geht), ist das vorrangige Ziel dieses Ansatzes, der deutlich effektiver ist, als alle Probleme erst nach einem Vorfall oder während eines Audits aufzudecken.

Welche automatisierten Kontrollen schützen die Cloud-Infrastruktur im Gesundheitswesen vor Fehlkonfigurationen?

Angesichts der Geschwindigkeit, mit der sich cloudnative Umgebungen verändern, reicht eine manuelle Konfigurationsprüfung eindeutig nicht aus. Automatisierte Kontrollen sind praktisch unverzichtbar, um die Umgebung kontinuierlich zu überwachen und Abweichungen sofort zu erkennen.

Zu den wichtigsten Kategorien von Kontrollen, die es zu beachten gilt, gehören:

• Cloud Security Posture Management (CSPM) – Tools, die Cloud-Umgebungen kontinuierlich auf Fehlkonfigurationen scannen und dabei aktuelle Einstellungen in Echtzeit mit Sicherheitsbenchmarks und Compliance-Rahmenwerken abgleichen
• Infrastructure-as-Code (IaC)-Scans – automatisierte Analyse des Codes, der zur Definition der Cloud-Infrastruktur verwendet wird, um unsichere Konfigurationen bereits vor ihrer Bereitstellung zu erkennen
• Abweichungserkennung – Überwachung, die feststellt, wann eine aktive Cloud-Umgebung von ihrer genehmigten Basiskonfiguration abweicht, und unbefugte oder versehentliche Änderungen sofort kennzeichnet
• Durchsetzung von „Policy-as-Code“ – Sicherheitsregeln, die als maschinenlesbare Richtlinien geschrieben sind und automatisch auf alle Cloud-Ressourcen angewendet und durchgesetzt werden, wodurch die Abhängigkeit von manuellen Überprüfungen entfällt

Es ist wichtig zu erwähnen, dass keine dieser Kontrollmaßnahmen die Notwendigkeit menschlicher Aufsicht vollständig beseitigt, doch sie versuchen sicherzustellen, dass das Ausmaß und das Tempo der Veränderungen in Cloud-nativen Umgebungen die Fähigkeiten des Sicherheitsteams, mit ihnen Schritt zu halten, nicht übersteigen.

Wie können Organisationen im Gesundheitswesen die Cloud-Sicherheit während der Cloud-Einführung verbessern?

Das bloße Verständnis dafür, warum Cloud-Sicherheit im Gesundheitswesen eine so große Herausforderung darstellt, ist nur die halbe Miete. Die zweite Hälfte besteht darin, Programme zu entwickeln, die so praxisnah sind, dass sie tatsächlich gleichzeitig vom klinischen Personal, den Sicherheitsteams und der Führungsebene befolgt werden können.

Welche Risiken des Cloud-Computing sollten Organisationen im Gesundheitswesen während der Migration angehen?

Die risikoreichste Phase der Cloud-Einführung ist die Migration – schnelle Entscheidungen unter Projektdruck führen zu jahrelangen Sicherheitsrückständen. Bevor geschützte Gesundheitsdaten (PHI) in eine Cloud-Umgebung übertragen werden, sollten Organisationen folgende Punkte klären:

• Datenklassifizierung – Ermittlung, welche Daten geschützte Gesundheitsdaten (PHI) darstellen, wo sie sich derzeit befinden und welche Cloud-Dienste darauf zugreifen werden
• BAA-Abdeckung – Bestätigung, dass mit jedem Anbieter und Unterauftragsverarbeiter, der geschützte Gesundheitsdaten (PHI) verarbeitet, unterzeichnete Business Associate Agreements (BAA) vorliegen
• Gestaltung der Zugriffskontrolle – Festlegung rollenbasierter Zugriffsrichtlinien für die Cloud-Umgebung vor der Migration, nicht erst danach
• Konfiguration der Protokollierung – Festlegung des Umfangs der Audit-Protokolle, der Aufbewahrungsfristen und der Speicherisolierung als Teil der Erstkonfiguration
• Überprüfung der Verschlüsselung – Sicherstellung, dass die Verschlüsselung alle Speicherebenen, Übertragungswege und Verarbeitungsumgebungen abdeckt, in denen PHI verarbeitet wird
• Tests für Datensicherung und Wiederherstellung – Überprüfung, ob die Sicherungsprozesse in der Cloud-Umgebung ordnungsgemäß funktionieren, bevor die Primärsysteme umgestellt werden
• Abgrenzung der geteilten Verantwortung – explizite Dokumentation, welche Sicherheitsverpflichtungen dem Anbieter und welche der Organisation obliegen

Wie können Organisationen im Gesundheitswesen das Risiko in einer Cloud-Umgebung während einer schrittweisen Einführung reduzieren?

Die sofortige Verlagerung aller Systeme in die Cloud maximiert sowohl die Geschwindigkeit als auch das Risiko. Ein schrittweiser Ansatz ermöglicht es, die Sicherheitskontrollen in jeder Phase zu überprüfen, bevor die nächste beginnt.

Ein sinnvoller Ausgangspunkt ist die Erprobung der Cloud-Einführung mit weniger sensiblen Workloads – Verwaltungssystemen, nicht-klinischen Tools für die Zusammenarbeit oder anonymisierten Analyseumgebungen. Dies gibt Sicherheits- und IT-Teams Zeit, um zu verstehen, wie sich die Kontrollen des Cloud-Anbieters in der Praxis tatsächlich verhalten, Lücken zwischen angenommenen und tatsächlichen Sicherheitsstandards zu identifizieren und operative Vertrautheit aufzubauen, bevor geschützte Gesundheitsdaten (PHI) einbezogen werden.

Jede Phase sollte vor der Erweiterung einen formellen Validierungskontrollpunkt beinhalten. Das bedeutet, Backup und Wiederherstellung zu testen, Zugriffsprotokolle auf unerwartetes Verhalten zu überprüfen, sicherzustellen, dass die Protokollierung die vorgesehenen Daten erfasst, und zu verifizieren, dass die Grenzen der geteilten Verantwortung in der Praxis eingehalten werden.

Eine schrittweise Einführung bedeutet nicht, dass die Cloud-Einführung langsamer verläuft. Es handelt sich vielmehr um eine Cloud-Einführung, die keine Rückstände bei der Fehlerbehebung verursacht, die das Unternehmen über Jahre hinweg begleiten.

Welche Kennzahlen und KPIs sollten Führungskräfte im Gesundheitswesen verfolgen, um den Reifegrad der Cloud-Sicherheit zu messen?

Die Bestimmung des Sicherheitsreifegrads stellt ohne spezifische Messgrößen eine echte Herausforderung dar. Die im Folgenden dargelegten Kennzahlen sollen Führungskräften im Gesundheitswesen dabei helfen, zu erkennen, ob Cloud-Sicherheitsmaßnahmen tatsächlich funktionsfähig sind und nicht nur implementiert wurden.

Wie kann Bacula Systems die Cloud-Sicherheit in Umgebungen des Gesundheitswesens verbessern?

Der Schutz von PHI in der Cloud erfordert mehr als nur präventive Kontrollmaßnahmen – es muss auch sichergestellt sein, dass eine Wiederherstellung möglich ist, wenn diese Kontrollmaßnahmen ordnungsgemäß getestet werden. Bacula Systems bietet Backup-Funktionen auf Unternehmensniveau sowie Wiederherstellungs- und Datenmanagementfunktionen, die speziell unter Berücksichtigung der Komplexität moderner Cloud-Umgebungen im Gesundheitswesen entwickelt wurden.

Wo Bacula Systems einen direkten Unterschied macht:

• Unveränderliche Backups – Backup-Kopien, die von einem Angreifer nicht verändert, gelöscht oder verschlüsselt werden können, selbst wenn dieser über Administratorrechte für die Primärsysteme verfügt
• Granulare Wiederherstellung – Wiederherstellung einzelner Dateien, Datenbanken oder ganzer Systeme, ohne dass alles auf einmal wiederhergestellt werden muss, wodurch klinische Ausfallzeiten während eines Vorfalls reduziert werden
• Kontrolle über Verschlüsselungsschlüssel – Organisationen behalten die Kontrolle über ihre eigenen Verschlüsselungsschlüssel, anstatt diese Verantwortung den Standardeinstellungen eines Cloud-Anbieters zu überlassen
• Auditfähige Protokollierung – detaillierte Backup- und Wiederherstellungsprotokolle, die die HIPAA-Dokumentationsanforderungen erfüllen und die Anforderungen forensischer Untersuchungen unterstützen
• Unterstützung von Hybrid- und Multi-Cloud-Umgebungen – konsistente Datensicherung über lokale, private und öffentliche Cloud-Umgebungen hinweg über eine einzige Verwaltungsschnittstelle
• Flexible Bereitstellung – die Architektur von Bacula passt sich an die bestehende Infrastruktur im Gesundheitswesen an, anstatt einen „Rip-and-Replace“-Ansatz zu erfordern

Letztendlich lassen sich alle Cloud-Sicherheitsprogramme im Gesundheitswesen anhand einer einzigen Frage beurteilen: Wenn etwas schiefgeht, wie schnell und wie gründlich kann der Betrieb wiederhergestellt werden? Bacula Systems wurde entwickelt, um eine eindeutige Antwort darauf zu geben – in realen, hybriden, Multi-Cloud- und älteren IT-Umgebungen im Gesundheitswesen.

FAQ

Warum haben Organisationen im Gesundheitswesen Schwierigkeiten, einheitliche Cloud-Sicherheitsrichtlinien über Multi-Cloud- und hybride Umgebungen hinweg aufrechtzuerhalten?

Die von Organisationen im Gesundheitswesen genutzten Cloud-Umgebungen werden selten von Grund auf neu aufgebaut. Oft sind sie das Ergebnis jahrelanger unabhängiger Anschaffungen, Fusionen, Übernahmen und Lieferantenvereinbarungen. Jede Umgebung verfügt über ein eigenes Zugriffskontrollmodell, einen eigenen Protokollierungsmechanismus und ein eigenes Toolset zur Sicherheitsüberwachung. Die Durchsetzung einer Richtlinie zum Schutz von PHI erfordert eine zentralisierte Verwaltungsebene, die von den meisten Organisationen bislang noch nicht aufgebaut wurde.

Wie sollten Organisationen im Gesundheitswesen Cloud-Sicherheitsvorfälle untersuchen, wenn Protokolle und Beweismittel auf mehrere Anbieter verteilt sind?

Eine Untersuchung eines Sicherheitsvorfalls ist nur so vollständig wie die Protokolle, auf denen sie basiert. Multi-Cloud-Umgebungen speichern Protokolle selten an einem einzigen Ort oder in einem einheitlichen Format. Protokolle sollten aus jeder Cloud-Umgebung in Echtzeit an ein zentralisiertes, separates und sicheres Repository übermittelt werden, anstatt erst reaktiv abgerufen zu werden, nachdem eine Sicherheitsverletzung entdeckt wurde. Die forensischen Vorgehensweisen für jeden Anbieter – einschließlich der Vorgehensweise zur Beschaffung gesicherter Beweismittel – sollten bereits vor einer Sicherheitsverletzung vordefiniert werden, anstatt erst währenddessen entwickelt zu werden.

Warum können cloudnative Automatisierung und DevSecOps-Pipelines versehentlich sensible Gesundheitsdaten in großem Umfang offenlegen?

Wenn sich eine Fehlkonfiguration in einer automatisierten Pipeline verfestigt, betrifft dies nicht nur ein System. Sie breitet sich auf jede Umgebung aus, mit der diese Pipeline interagiert. Ein automatisiertes Bereitstellungssystem, das so konzipiert ist, dass es als Standardkonfiguration eine Speicherressource mit offenen Zugriffsberechtigungen erstellt, kann diesen Fehler hunderte Male reproduzieren, bevor ein Mensch überhaupt bemerkt, dass er existiert. Im Gesundheitswesen ist eine in eine automatisierte Pipeline integrierte Sicherheitsprüfung keine technische Annehmlichkeit, sondern eine Verpflichtung zum Schutz der Privatsphäre der Patienten.