Ochraňte data pacientů dřív, než se z nich stane hlášení o úniku

Odhalení ePHI spouští povinné hlášení úniku

Podle HIPAA vyžaduje neoprávněný přístup byť jen k záznamům jediného pacienta hlášení úniku na HHS a případně i samotnému pacientovi. Chyby v řízení přístupu, které tyto úniky způsobují, jako IDOR a narušená autorizace ve FHIR API, jsou přesně to, co Penetrify hledá.

HIPAA Security Rule vyžaduje pravidelné testování

45 CFR §164.308(a)(8) vyžaduje pravidelné technické i netechnické vyhodnocování vašich bezpečnostních kontrol. „Pravidelně“ znamená víc než jednou ročně, pokud nasazujete kód každý měsíc, a Penetrify dělá průběžné testování ekonomicky únosným.

FHIR API přinášejí nové plochy útoku

Moderní standardy interoperability ve zdravotnictví (FHIR R4, SMART on FHIR) vytvářejí API endpointy, které vystavují data pacientů ve velkém. Špatně nastavená autorizace na jediném FHIR endpointu může odhalit celou vaši pacientskou populaci.

45 CFR §164.308(a)(8): Pravidelné vyhodnocování technických i netechnických opatření

Kontrola 10.m: Penetrační testování jako součást programu řízení zranitelností

CC6.1: Logické řízení přístupu s doklady o penetračním testování

A.12.6: Řízení technických zranitelností s pravidelným bezpečnostním testováním

HIPAA dnes a navrhovaná úprava, která penetrační testování konečně pojmenuje

Současné HIPAA Security Rule vyžaduje „pravidelné“ technické a netechnické vyhodnocování opatření (45 CFR §164.308(a)(8)), aniž by penetrační testování výslovně jmenovalo, což je důvod, proč se bezpečnostní programy ve zdravotnictví tak liší. Tahle nejednoznačnost se chýlí ke konci: navrhovaná aktualizace Security Rule od HHS (NPRM zveřejněné 6. ledna 2025) by požadavky pojmenovala výslovně, včetně penetračního testování minimálně jednou za 12 měsíců a skenování zranitelností minimálně jednou za šest měsíců.

K polovině roku 2026 je pravidlo stále jen navržené, ne finální, a OCR nadále vymáhá současné Security Rule. Směr je ale jednoznačný a vyšetřování OCR už dnes berou absenci technického testování jako důkaz nedostatečné analýzy rizik, což je nejčastěji citovaný nedostatek v sankčních řízeních. Zavést kadenci testování teď znamená, že finální pravidlo bude nakonec nezajímavá formalita; čekání znamená dodělávat program pod tlakem termínu.

Průběžné testování navíc odpovídá standardu „pravidelně“ lépe než jakákoli roční zakázka už dnes: zdokumentovaná historie skenů za celý rok, každý s nálezy a důkazy o nápravě, je přesně tím druhem průběžného vyhodnocování, který §164.308(a)(8) popisuje.

FHIR a SMART on FHIR: interoperabilita je plocha útoku

Americké mandáty na interoperabilitu posunuly data pacientů za standardizovaná API: zdroje FHIR R4, autorizaci SMART on FHIR, hromadný export dat. Standardizace ale pomáhá i útočníkům: přesně vědí, které endpointy existují (/Patient, /Observation, /DocumentReference) a co přesně ten špatně nastavený vyzradí. Jediný FHIR endpoint, který nevynutí autorizaci na úrovni zdroje, může odhalit celou pacientskou populaci, a na rozdíl od ukradeného notebooku to udělá potichu.

Opakující se selhání jsou konkrétní: ID zdrojů přijímaná bez ověření, zda má žádající uživatel k pacientovi vztah péče (IDOR v populačním měřítku), SMART scopes vydávané široce a nikdy nevynucované na úrovni zdroje a endpointy hromadného exportu dosažitelné s údaji určenými pro přístup k jednomu záznamu. Penetrify testuje tyhle autorizační hranice tak, jak je zkouší útočník: napříč rolemi, napříč pacienty, napříč scopes, při každém nasazení vašeho API.

Penetrify testuje autorizační hranice napříč všemi uživatelskými rolemi (lékař, administrátor, pacient) a cíleně hledá zranitelnosti typu IDOR, které odhalují záznamy pacientů mimo povolené vztahy péče. Jde o příčinu číslo jedna úniků dat ve zdravotnictví.

Každý sken vytvoří zprávu s časovým razítkem a řazením podle závažnosti. Až bude OCR auditovat váš bezpečnostní program, doložíte zdokumentovanou historii pravidelného bezpečnostního testování celé aplikace, ne jedinou roční zprávu z jednoho okamžiku.

Penetrify testuje implementace FHIR R4 a SMART on FHIR na vynucování autorizačních hranic, validaci scopes a řízení přístupu ke zdrojům: konkrétní plochy útoku, na které standardní DAST nástroje nejsou nastavené.

Penetrify nikdy nemění, nemaže ani neodesílá data pryč. Testuje pozorováním odpovědí aplikace, ne prováděním zápisů. Bezpečně ho pustíte proti stagingu, který kopíruje strukturu produkčních dat pacientů.