PACS-uri expuse în Internet: sunt suficiente parola și certificatul SSL?

În ultima perioadă am identificat mai multe sisteme PACS și viewere DICOM web accesibile direct din Internet. Nu erau „deschise" în sensul clasic: aveau o pagină de autentificare cu utilizator și parolă și, cel mai probabil, comunicau prin HTTPS. La prima vedere, configurația pare rezonabilă. Există un ecran de login, există lacătul din bara browserului, deci datele „sunt protejate".

Pentru imagini medicale și pentru obligațiile pe care NIS2 le impune furnizorilor de servicii de sănătate, protecția aceasta este în cele mai multe cazuri insuficientă. Cât de insuficientă depinde de ce anume este expus, cum este expus și ce alternative realiste există. Iar alternativa cea mai des recomandată, tunelul VPN, are și ea limite care merită discutate onest.

Problema este veche și globală

Expunerea serverelor DICOM în Internet este documentată de ani buni. La conferința Black Hat Europe din decembrie 2023, cercetătorii firmei Aplite au prezentat rezultatele unei scanări de șase luni: aproximativ 3.800 de servere DICOM accesibile public, în 111 țări, dintre care circa 30% scurgeau date sensibile. Estimarea lor totală a fost de aproximativ 59 de milioane de înregistrări expuse, iar aproape trei sferturi dintre servere erau găzduite în cloud-uri publice mari sau pe conexiuni DSL.

Alte analize confirmă tendința. SOCRadar a identificat în 2024 servere DICOM configurate greșit care expuneau aproape 1,7 milioane de înregistrări de pacienți din 25 de țări. În 2026, Rapid7 a raportat peste 30 de sisteme doar din Marea Britanie care răspundeau la cereri DICOM pe portul 104, iar Trend Micro a descris mii de sisteme de imagistică accesibile public, multe cu controale de securitate minime sau inexistente.

Ceea ce am observat în România se înscrie în același tipar, cu o nuanță importantă: sistemele pe care le-am identificat nu erau complet neprotejate. Tocmai de aceea merită analizat ce oferă, concret, combinația „utilizator + parolă + SSL".

Trei tipuri de expunere directă, trei niveluri de risc

Când spunem că un PACS este „expus direct în Internet", putem descrie situații foarte diferite. Diferența dintre ele contează.

1. DIMSE clasic, necriptat (porturile 104, 11112, 4242 etc.)

Acesta este cel mai grav caz. Protocolul DICOM nativ (DIMSE) a fost proiectat pentru rețele interne de încredere. Singurul „filtru" de acces este adesea AE Title-ul (Application Entity Title), care nu este un mecanism de autentificare, ci un simplu identificator. Este frecvent ghicibil, apare în documentația producătorilor, iar multe servere acceptă conexiuni de la orice AE Title apelant.

Un server DIMSE expus poate răspunde la C-ECHO (confirmând că există), la C-FIND (returnând liste de pacienți și studii), la C-MOVE sau C-GET (permițând descărcarea imaginilor) și, în cazurile cele mai grave, la C-STORE (permițând injectarea de date). Fără criptare, metadatele (nume, CNP sau alte identificatoare, date de naștere, diagnostic, medic trimițător) circulă în clar. Aici nu există dezbatere: portul trebuie închis.

2. DIMSE peste TLS (portul 2762)

TLS criptează canalul, ceea ce rezolvă problema interceptării. Întrebarea decisivă este însă dacă serverul verifică și certificatul clientului (TLS mutual, mTLS). Dacă da, avem o autentificare puternică a dispozitivului, iar într-un scenariu punct-la-punct între două instituții, cu adrese IP fixe și filtrare strictă pe firewall, configurația poate fi apărată. Dacă serverul nu verifică certificatul clientului, TLS doar ascunde conversația de terți, iar conectarea rămâne posibilă pentru oricine.

Standardul DICOM include un mecanism de negociere a identității utilizatorului (User Identity Negotiation), însă suportul în produsele comerciale este inegal și, în practică, nu oferă autentificare multi-factor.

3. Viewer web / DICOMweb peste HTTPS, cu utilizator și parolă

Este situația întâlnită cel mai des și cea care a motivat acest articol. Interfața web (sau API-ul DICOMweb: QIDO-RS pentru căutare, WADO-RS pentru preluare, STOW-RS pentru stocare) este publicată pe portul 443, cu certificat SSL și pagină de login. Pentru utilizator, experiența este impecabilă: deschide browserul, se autentifică și citește studiul. Pentru un atacator, experiența este aproape la fel de simplă.

Ce face și ce nu face certificatul SSL

Un certificat SSL/TLS valid garantează trei lucruri: că datele nu pot fi citite pe drum, că nu pot fi modificate pe drum și că serverul la care te conectezi este cel care pretinde că este. Atât.

Certificatul nu spune nimic despre cine se autentifică, despre cât de sigură este aplicația din spatele lui sau despre cât de actualizat este serverul web. Lacătul din browser apare la fel de liniștitor pe un PACS perfect întreținut și pe un PACS cu o versiune de Tomcat veche de opt ani și un cont implicit al producătorului încă activ. Mai mult, dacă inspectăm aceste sisteme, vom găsi frecvent certificate autosemnate sau expirate, versiuni TLS învechite și lipsa antetelor de securitate de bază (HSTS, de exemplu), ceea ce slăbește chiar și protecția pe care SSL ar trebui să o ofere.

De ce utilizatorul și parola nu mai sunt suficiente

În configurațiile pe care le-am întâlnit, parola este singura barieră între Internet și arhiva de imagistică a unui spital. Iar această barieră cedează în moduri bine cunoscute.

Parolele sunt refolosite: un medic care folosește aceeași parolă pe un forum compromis și pe portalul PACS devine o țintă pentru credential stuffing, adică testarea automată a perechilor utilizator/parolă scurse din alte breșe. Parolele sunt furate prin phishing, iar mesajele care imită notificări de la „departamentul IT" sau de la producătorul PACS sunt ușor de construit. Parolele sunt colectate de malware de tip infostealer de pe laptopurile personale folosite pentru citiri de gardă, iar jurnalele acestor programe sunt vândute pe piețe specializate, cu tot cu adresa portalului pe care a fost folosită parola.

La acestea se adaugă practicile interne: conturi partajate între mai mulți radiologi, conturi implicite ale producătorului lăsate active, lipsa blocării după încercări eșuate, lipsa oricărui al doilea factor de autentificare.

Există și o problemă mai subtilă. Pagina de login în sine dezvăluie informații: produsul, adesea versiunea, uneori componentele pe care rulează. Pentru un atacator, asta înseamnă că poate căuta direct vulnerabilități cunoscute pentru acea versiune. Iar vulnerabilitățile care pot fi exploatate înainte de autentificare fac parola irelevantă. Faptul că aplicația cere login nu înseamnă că tot codul ei rulează după login.

Alternativa: tunelul VPN

Un tunel VPN (IPsec, WireGuard sau OpenVPN) creează o rețea privată criptată între două puncte. Serverul PACS nu mai este publicat în Internet; din exterior se vede doar gateway-ul VPN, iar accesul la PACS devine posibil numai după ce tunelul a fost stabilit și utilizatorul sau dispozitivul a fost autentificat.

Varianta Site-to-Site

Leagă două locații fixe, de exemplu un spital și un centru de radiologie partener, printr-un tunel configurat direct pe firewall-uri sau routere. Transferul este transparent pentru utilizatori, echipamentele moderne oferă accelerare hardware pentru criptare, iar overhead-ul este mic. Pentru schimbul constant de studii voluminoase între instituții, este soluția cea mai curată.

Varianta Client-to-Site

Este cea relevantă pentru teleradiologie și citiri de gardă de acasă. Medicul pornește un client VPN (WireGuard, FortiClient, Cisco Secure Client etc.), se autentifică cu MFA (notificare push, cod TOTP, cheie hardware), iar abia apoi aplicația PACS sau viewerul devin accesibile. Integrarea cu un furnizor de identitate (Active Directory, Entra ID, Okta) permite gestionarea centralizată a conturilor: plecarea unui medic din colaborare înseamnă dezactivarea unui singur cont, nu căutarea lui prin mai multe sisteme.

Avantajele sunt reale: suprafața de atac a PACS-ului dispare din Internet, MFA devine standard, iar politicile de pe gateway pot restricționa accesul exact la IP-ul și portul necesare.

Ce nu rezolvă VPN-ul

Multe materiale prezintă VPN-ul ca pe un răspuns definitiv. Un articol comparativ onest trebuie să spună și unde se oprește protecția lui.

Gateway-ul VPN devine el însuși ținta

Suprafața de atac nu dispare, se mută. În ultimii ani, echipamentele VPN au fost printre cele mai exploatate puncte de intrare pentru grupările de ransomware: Citrix NetScaler („Citrix Bleed", CVE-2023-4966), Ivanti Connect Secure (vulnerabilități exploatate masiv în ianuarie 2024), Palo Alto GlobalProtect (CVE-2024-3400) sau Fortinet SSL-VPN (CVE-2024-21762). Un gateway VPN neactualizat poate fi mai periculos decât un viewer web bine întreținut, pentru că oferă acces la rețea, nu doar la o aplicație. O excepție notabilă este WireGuard, care nu răspunde deloc pachetelor neautentificate și este, în practică, mult mai greu de detectat prin scanare.

VPN-ul nu înseamnă automat micro-segmentare

Configurat implicit, un VPN pune utilizatorul „în rețea", adesea cu acces mult mai larg decât are nevoie. Tocmai această problemă a dus la apariția conceptului Zero Trust Network Access (ZTNA). Restricția la „doar IP-ul și portul PACS" există numai dacă cineva o configurează explicit.

Un dispozitiv compromis rămâne compromis

Dacă laptopul personal al radiologului este infectat, tunelul VPN duce malware-ul direct în rețeaua spitalului. De aceea, pentru acces la distanță, contează la fel de mult dacă dispozitivul este administrat de instituție și verificat înainte de conectare (device posture).

Fricțiunea generează ocolișuri

Dacă procedura de acces este prea greoaie pentru o citire de urgență la trei dimineața, oamenii găsesc alternative: studii trimise prin WeTransfer, capturi de ecran pe WhatsApp, CD-uri copiate. O arhitectură sigură, dar nefolosită, nu protejează nimic.

Un viewer web poate fi publicat responsabil

Există o variantă intermediară, folosită de multe platforme de teleradiologie: viewerul web rămâne accesibil din Internet, dar exclusiv în spatele unui reverse proxy / Web Application Firewall care impune autentificarea printr-un furnizor de identitate cu MFA (OIDC sau SAML) înainte ca vreun pachet să ajungă la aplicația PACS. Aceasta este o arhitectură complet diferită de un login direct pe viewer.

Comparație directă

Ce spune de fapt NIS2

Directiva NIS2 (UE 2022/2555) a fost transpusă în România prin OUG nr. 155/2024, aprobată cu modificări prin Legea nr. 124/2025, iar autoritatea competentă este Directoratul Național de Securitate Cibernetică (DNSC). Furnizorii de servicii de sănătate se află în Anexa I (sectoare cu grad ridicat de criticitate). În funcție de dimensiune, un spital sau o rețea de clinici poate fi entitate esențială (de regulă, organizațiile mari) sau entitate importantă (de regulă, cele mijlocii), iar autoritățile pot desemna entități și independent de criteriul de mărime, pe baza impactului lor.

Există însă cerințe care fac foarte greu de justificat un PACS publicat în Internet doar cu parolă. Articolul 21 alineatul (2) enumeră, printre altele:

• litera (a): politici de analiză a riscurilor și de securitate a sistemelor informatice;
• litera (d): securitatea lanțului de aprovizionare, relevantă pentru accesul furnizorilor PACS și al centrelor de teleradiologie partenere;
• litera (e): securitatea în achiziția, dezvoltarea și întreținerea sistemelor, inclusiv gestionarea vulnerabilităților;
• litera (h): politici privind utilizarea criptografiei și, după caz, a criptării;
• litera (i): securitatea resurselor umane, politici de control al accesului și gestionarea activelor;
• litera (j): utilizarea autentificării multi-factor sau a autentificării continue, acolo unde este cazul.

Un auditor care găsește un PACS cu date de pacienți accesibil din Internet, protejat de un singur factor de autentificare, va pune întrebări legitime pe cel puțin literele (a), (e), (i) și (j). Pentru acces la distanță la date medicale, argumentul că MFA „nu este cazul" este foarte greu de susținut.

Sancțiunile sunt semnificative. Conform directivei, pentru entitățile esențiale plafonul maxim este de cel puțin 10 milioane de euro sau 2% din cifra de afaceri anuală mondială, iar pentru entitățile importante de cel puțin 7 milioane de euro sau 1,4%, aplicându-se valoarea mai mare. În plus, NIS2 prevede răspunderea conducerii pentru aprobarea și supravegherea măsurilor de securitate.

NIS2 nu vine singur. Imaginile medicale și metadatele lor sunt date privind sănătatea, adică o categorie specială de date conform articolului 9 din GDPR, iar articolul 32 impune măsuri de securitate adecvate riscului. Un incident care implică un PACS compromis declanșează, de regulă, două fluxuri de raportare paralele: către DNSC (NIS2) și către ANSPDCP (GDPR).

Recomandări pe scenarii

Interconectare între instituții (Site-to-Site)

Soluția implicită ar trebui să fie un tunel IPsec IKEv2 sau WireGuard între firewall-urile celor două locații, cu reguli care permit doar traficul DICOM între sistemele care trebuie să comunice. Dacă, din motive practice, se folosește DIMSE TLS direct, minimul acceptabil este TLS mutual (verificarea certificatului ambelor părți), filtrare strictă pe adrese IP, monitorizarea conexiunilor și revizuirea periodică a regulilor de firewall.

Teleradiologie și acces de gardă (Client-to-Site)

Accesul trebuie să treacă printr-un VPN sau o soluție ZTNA cu MFA obligatoriu, integrată cu furnizorul central de identitate, de preferat de pe dispozitive administrate de instituție. Dacă este necesar un viewer în browser, acesta trebuie publicat exclusiv în spatele unui reverse proxy / WAF cu SSO și MFA, niciodată cu login direct pe aplicația PACS.

Partajarea cu medici trimițători și pacienți

Aceștia nu ar trebui să aibă conturi în PACS-ul de producție. Soluțiile potrivite sunt portalurile dedicate, separate de arhivă, cu linkuri limitate în timp și acces doar la studiul relevant.

Dacă aveți astăzi un PACS expus: ordinea în care să acționați

Imediat

Închideți orice port DICOM (104, 11112, 2762, 4242 etc.) publicat prin NAT/PAT pe firewall-ul exterior. Verificați din exterior ce vede efectiv Internetul pe adresele instituției; motoarele de scanare publică indexează aceste servicii oricum, deci merită să știți înaintea altora.

În primele zile

Dacă viewerul web nu poate fi retras imediat, puneți-l în spatele unui reverse proxy cu autentificare MFA. Dezactivați conturile implicite și conturile partajate, resetați parolele, instalați actualizările de securitate disponibile și verificați jurnalele de autentificare pentru conectări neobișnuite (ore, țări, volume de descărcare).

În următoarele săptămâni

Implementați VPN-ul Site-to-Site cu partenerii și accesul Client-to-Site / ZTNA cu MFA pentru medicii la distanță. Restricționați politicile VPN la minimul necesar și actualizați gateway-ul VPN cu aceeași prioritate ca pe orice sistem expus.

Pe termen mediu

Activați și centralizați jurnalele de audit atât pe gateway, cât și pe PACS (DICOM Audit Trail). NIS2 nu fixează o durată exactă de păstrare, dar 12 luni este o practică frecvent întâlnită; verificați și cerințele specifice emise de DNSC. Includeți în contractele cu furnizorii PACS clauze privind accesul lor la distanță, actualizările de securitate și notificarea vulnerabilităților. Testați periodic configurația, inclusiv printr-un test de penetrare extern.

Întrebări frecvente

Avem certificat SSL valid pe viewerul PACS. Nu este suficient pentru NIS2?

Certificatul acoperă criptarea în tranzit, adică litera (h) din articolul 21 alineatul (2). Nu acoperă controlul accesului, autentificarea multi-factor sau gestionarea vulnerabilităților aplicației. Un auditor va cere dovezi și pentru celelalte cerințe.

Cum aflăm dacă avem porturi DICOM publicate în Internet?

Cel mai rapid: verificați regulile de NAT/port forwarding de pe firewall-ul exterior pentru porturile 104, 2762, 4242 și 11112, apoi confirmați printr-o scanare din exterior a adreselor IP publice ale instituției. Motoarele de căutare pentru dispozitive conectate indexează deja aceste servicii.

Medicii se plâng că VPN-ul îi încetinește. Ce variante avem?

WireGuard are overhead mic și reconectare rapidă, ceea ce ajută la citirile de gardă. Alternativa este o soluție ZTNA sau un viewer publicat în spatele unui proxy cu SSO, unde medicul se autentifică o singură dată cu contul instituției. Fricțiunea prea mare duce la ocolișuri (WeTransfer, WhatsApp), care sunt mult mai riscante.

Furnizorul PACS cere acces permanent de la distanță pentru mentenanță. Este acceptabil?

Accesul furnizorilor intră la securitatea lanțului de aprovizionare, litera (d). Practica rezonabilă este acces prin VPN cu conturi nominale și MFA, activat la cerere pentru intervalul intervenției, cu jurnalizare completă și clauze contractuale privind actualizările și notificarea vulnerabilităților.

Suntem o clinică mică. Ne aplică NIS2?

Depinde de dimensiune și de decizia autorității. Entitățile mari intră de regulă ca entități esențiale, cele mijlocii ca entități importante, iar DNSC poate desemna entități și independent de criteriul de mărime, pe baza impactului lor. Independent de NIS2, GDPR se aplică oricum: imaginile medicale sunt date privind sănătatea, categorie specială conform articolului 9.

Concluzie

Un PACS accesibil din Internet cu utilizator, parolă și certificat SSL nu este „deschis", dar nici protejat la nivelul pe care îl cer datele medicale sau NIS2. SSL protejează canalul, parola protejează până la prima scurgere de credențiale, iar nimic din această combinație nu protejează aplicația de propriile vulnerabilități.

Tunelul VPN cu MFA rezolvă majoritatea acestor probleme, cu condiția ca gateway-ul să fie întreținut riguros, politicile de acces să fie restrânse și dispozitivele de la care se conectează medicii să fie sub control. Pentru multe organizații, arhitectura potrivită va fi una hibridă: tuneluri Site-to-Site între instituții, VPN sau ZTNA cu MFA pentru radiologii la distanță și, acolo unde un viewer în browser este indispensabil, publicarea lui exclusiv în spatele unui proxy cu autentificare centralizată.

Întrebarea corectă nu este „VPN sau TLS?", ci „ce ajunge la PACS înainte ca cineva să-și fi dovedit identitatea cu mai mult decât o parolă?". Dacă răspunsul este „orice pachet din Internet", configurația trebuie schimbată.

Notă metodologică

Observațiile prezentate au fost realizate exclusiv prin identificarea pasivă a serviciilor accesibile public, fără încercări de autentificare și fără accesarea datelor. Instituțiile nu sunt nominalizate, iar situațiile identificate vor fi semnalate prin canalele de raportare responsabilă, inclusiv Serviciul de Raportare Vulnerabilități al DNSC.

Surse

• Aplite, prezentare Black Hat Europe 2023, preluată de Dark Reading și CPO Magazine: darkreading.com
• SOCRadar, „Critical DICOM Server Misconfigurations Lead to Exposure of 1.6M Medical Records" (2024): socradar.io
• Rapid7, „Exposed DICOM Servers in UK Healthcare" (2026): rapid7.com
• Trend Micro, „A Hidden Vulnerability in Healthcare: Exposed DICOM Servers and the Risk to Patient Data" (2026): trendmicro.com
• Directiva (UE) 2022/2555 (NIS2), în special articolele 21, 23 și 34
• OUG nr. 155/2024 și Legea nr. 124/2025; Directoratul Național de Securitate Cibernetică: dnsc.ro

Doriți o evaluare gratuită a expunerii sistemului vostru PACS? Contactați-ne la Această adresă de email este protejată contra spambots. Trebuie să activați JavaScript pentru a o vedea. sau +40 369 449 850.