Schützen Sie Patientendaten, bevor daraus eine Meldung wird

Offenlegung von ePHI löst eine Meldepflicht aus

Nach HIPAA erfordert der unbefugte Zugriff auf die Akte auch nur eines einzigen Patienten eine Breach-Meldung an HHS und gegebenenfalls an den Patienten. Die Fehler in der Zugriffskontrolle, die solche Offenlegungen verursachen, etwa IDOR und fehlerhafte Autorisierung in FHIR-APIs, sind genau das, was Penetrify findet.

Die HIPAA Security Rule verlangt regelmäßige Tests

45 CFR §164.308(a)(8) verlangt regelmäßige technische und nichttechnische Bewertungen Ihrer Sicherheitskontrollen. „Regelmäßig“ heißt mehr als einmal im Jahr, wenn Sie monatlich Code ausliefern, und Penetrify macht kontinuierliches Testen wirtschaftlich praktikabel.

FHIR-APIs schaffen neue Angriffsflächen

Moderne Interoperabilitätsstandards im Gesundheitswesen (FHIR R4, SMART on FHIR) schaffen API-Endpunkte, die Patientendaten in großem Umfang exponieren. Eine fehlkonfigurierte Autorisierung an einem einzigen FHIR-Endpunkt kann Ihre gesamte Patientenpopulation offenlegen.

45 CFR §164.308(a)(8): Regelmäßige Bewertung technischer und nichttechnischer Schutzmaßnahmen

Control 10.m: Penetrationstests als Teil des Schwachstellenmanagement-Programms

CC6.1: Logische Zugriffskontrollen mit Nachweisen über Penetrationstests

A.12.6: Management technischer Schwachstellen mit regelmäßigen Sicherheitstests

HIPAA heute und die geplante Regel, die Pentesting ausdrücklich macht

Die aktuelle HIPAA Security Rule verlangt eine „regelmäßige“ technische und nichttechnische Bewertung der Schutzmaßnahmen (45 CFR §164.308(a)(8)), ohne Penetrationstests ausdrücklich zu nennen, weshalb Sicherheitsprogramme im Gesundheitswesen so stark variieren. Diese Unschärfe verschwindet gerade: die von HHS vorgeschlagene Aktualisierung der Security Rule (NPRM veröffentlicht am 6. Januar 2025) würde die Anforderungen ausdrücklich machen, einschließlich Penetrationstests mindestens alle 12 Monate und Schwachstellenscans mindestens alle sechs Monate.

Stand Mitte 2026 ist die Regel weiterhin vorgeschlagen und nicht final, und OCR setzt weiter die geltende Security Rule durch. Die Richtung ist jedoch eindeutig, und OCR-Untersuchungen werten das Fehlen technischer Tests bereits heute als Beleg für eine unzureichende Risikoanalyse, den am häufigsten genannten Mangel in Durchsetzungsverfahren. Die Testkadenz jetzt aufzubauen heißt, dass die endgültige Regel später ein Nicht-Ereignis ist; Warten heißt, ein Programm unter Fristendruck nachzurüsten.

Kontinuierliches Testen erfüllt den Maßstab „regelmäßig“ zudem schon heute besser als jedes Jahresprojekt: eine dokumentierte Scan-Historie über das Jahr, jeweils mit Findings und Nachweisen zur Behebung, ist genau die Art laufender Bewertung, die §164.308(a)(8) beschreibt.

FHIR und SMART on FHIR: Interoperabilität ist eine Angriffsfläche

US-Interoperabilitätsvorgaben haben Patientendaten hinter standardisierte APIs verlagert: FHIR-R4-Ressourcen, SMART-on-FHIR-Autorisierung, Bulk-Data-Export. Standardisierung hilft auch Angreifern: sie wissen genau, welche Endpunkte existieren (/Patient, /Observation, /DocumentReference) und was ein fehlkonfigurierter davon preisgibt. Ein einzelner FHIR-Endpunkt, der Autorisierung auf Ressourcenebene nicht durchsetzt, kann eine ganze Patientenpopulation offenlegen, und anders als ein gestohlener Laptop tut er das lautlos.

Die wiederkehrenden Fehlermuster sind konkret: Ressourcen-IDs werden akzeptiert, ohne die Behandlungsbeziehung des anfragenden Nutzers zu prüfen (IDOR im Populationsmaßstab), SMART-Scopes werden breit vergeben und nie pro Ressource durchgesetzt, und Bulk-Export-Endpunkte sind mit Zugangsdaten erreichbar, die für den Zugriff auf Einzeldatensätze gedacht waren. Penetrify prüft diese Autorisierungsgrenzen so, wie ein Angreifer sie abtastet: über Rollen, über Patienten, über Scopes hinweg, bei jedem Deployment Ihrer API.

Penetrify prüft Autorisierungsgrenzen über alle Nutzerrollen hinweg (Behandelnde, Admin, Patient) und sucht gezielt nach IDOR-Schwachstellen, die Patientenakten außerhalb autorisierter Behandlungsbeziehungen offenlegen. Das ist die häufigste Ursache für Datenschutzverletzungen im Gesundheitswesen.

Jeder Scan erzeugt einen Bericht mit Zeitstempel und Schweregradbewertung. Wenn OCR Ihr Sicherheitsprogramm prüft, können Sie eine dokumentierte Historie regelmäßiger Sicherheitstests über Ihre gesamte Anwendung vorlegen, nicht einen einzelnen Jahresbericht von einem Zeitpunkt.

Penetrify prüft FHIR-R4- und SMART-on-FHIR-Implementierungen auf die Durchsetzung von Autorisierungsgrenzen, Scope-Validierung und Zugriffskontrolle auf Ressourcenebene: genau die Angriffsflächen, für die Standard-DAST-Tools nicht konfiguriert sind.

Penetrify verändert, löscht und exfiltriert niemals Daten. Es testet durch Beobachtung von Anwendungsantworten, nicht durch Schreiboperationen. Sicher gegen Staging-Umgebungen einsetzbar, die die Struktur produktiver Patientendaten spiegeln.