Architettura di sicurezza dei dispositivi medici
Sytance · Aggiornato
Un’architettura di sicurezza mostra come sono protetti il dispositivo medico e i sistemi connessi. Identifica le interfacce raggiungibili da un attaccante e spiega dove i controlli limitano l’accesso, proteggono i dati o verificano gli aggiornamenti software.
L’architettura come evidenza
La FDA raccomanda viste architetturali che aiutino i revisori a comprendere l’esposizione del dispositivo agli attacchi e le protezioni integrate nel sistema. In un fascicolo tecnico UE, le stesse informazioni progettuali supportano i requisiti MDR o IVDR applicabili. La spiegazione normativa può variare, ma l’architettura sottostante dovrebbe descrivere il dispositivo effettivo e il suo ambiente previsto.
Ad esempio, una connessione di assistenza remota può attraversare la rete di un fornitore di servizi per raggiungere un ospedale. L’architettura dovrebbe mostrare quale endpoint autentica il tecnico e quale parte del dispositivo limita le operazioni di manutenzione.
Perimetro del sistema
Identificare il dispositivo e i sistemi esterni da cui dipende. Indicare quali parti sono controllate dal fabbricante e quali dipendono dall’organizzazione sanitaria o da un altro fornitore.
Confine di fiducia
Segnalare i cambiamenti di fiducia o autorità. Ad esempio, un comando ricevuto da un’app mobile deve essere verificato prima che il dispositivo ne consenta l’applicazione a un’impostazione clinica.
Viste architetturali FDA
La guida definitiva FDA di febbraio 2026 raccomanda viste architetturali proporzionate all’architettura del dispositivo e al rischio di cibersicurezza. Ogni vista illustra un aspetto diverso del modo in cui il sistema può essere attaccato e protetto.
Mostrare il dispositivo nel sistema completo utilizzato per svolgere la funzione prevista. Includere i servizi connessi e la rete ospedaliera o domestica quando incidono sulla sicurezza. Per i sistemi complessi, usare diagrammi di supporto per illustrare i protocolli e i flussi di dati che sarebbero illeggibili nella vista complessiva.
Spiegare come un singolo compromesso possa interessare più dispositivi o pazienti. Ad esempio, la compromissione di un servizio di monitoraggio centralizzato può interrompere gli allarmi di molti monitor al letto del paziente. Mostrare come il sistema limiti la propagazione e mantenga o ripristini le funzioni interessate.
Seguire un aggiornamento software dalla fonte approvata fino all’installazione sul dispositivo. Mostrare come il dispositivo verifichi autenticità e integrità, quali azioni debba compiere l’utente e cosa accada in caso di errore d’installazione. Identificare ogni passaggio che dipende da tecnologie non controllate dal fabbricante.
Descrivere un’operazione specifica che possa incidere sulla sicurezza o sull’efficacia. Per la configurazione remota, mostrare l’utente richiedente, il percorso del comando e le verifiche delle autorizzazioni prima della modifica di un’impostazione. Usare viste aggiuntive per operazioni con attori o controlli diversi.
Viste del fascicolo tecnico UE
MDR e IVDR non prescrivono i nomi delle viste FDA. Le informazioni architetturali supportano la valutazione della sicurezza del software e dell’interazione del dispositivo con l’ambiente IT previsto. Dovrebbero spiegare le ipotesi progettuali alla base della valutazione dei rischi e le condizioni che l’utilizzatore deve mantenere.
- Una vista dei flussi di dati mostra dove i dati clinici possono essere letti o modificati e quali controlli li proteggono lungo il percorso.
- Una vista delle interfacce identifica le connessioni consentite e le verifiche che ne limitano l’uso. Questi dettagli supportano i pertinenti requisiti generali di sicurezza e prestazione (GSPR).
- Una vista dell’ambiente operativo illustra le protezioni attese dall’organizzazione sanitaria, ad esempio limitando il segmento di rete che può raggiungere un servizio di manutenzione.
- Una vista del percorso di aggiornamento spiega come una patch collaudata raggiunge i dispositivi previsti e come ripristinare il sistema in caso di installazione non riuscita.
MDCG 2019-16 Rev.1 spiega come fabbricanti e organizzazioni sanitarie condividano la responsabilità di un funzionamento sicuro. La guida aiuta a collegare le ipotesi progettuali ai requisiti IT minimi e alle informazioni di sicurezza fornite con il dispositivo.
Dipendenze del sistema
Il livello di dettaglio architetturale dovrebbe riflettere il sistema effettivo del dispositivo. Un semplice dispositivo locale può richiedere meno viste di un sistema connesso al cloud, mobile, in rete o gestito come flotta. Le dipendenze che incidono sulla sicurezza del dispositivo dovrebbero essere incluse anche quando il sistema connesso è gestito dal cliente.
Servizi cloud e remoti
Includere un servizio remoto quando il dispositivo vi dipende per funzionare in sicurezza. Ad esempio, la perdita di un servizio di identità può incidere su chi può accedere al dispositivo e su come ripristinare l’accesso locale.
Percorsi di aggiornamento
L’architettura degli aggiornamenti dovrebbe illustrare l’intero percorso dall’approvazione del rilascio al dispositivo in uso sul campo, incluse autenticità, integrità, errori di distribuzione e ripristino.
Uso mobile e domestico
Il telefono del paziente e la rete domestica introducono controlli che il fabbricante potrebbe non gestire. Spiegare quali protezioni fornisce il dispositivo stesso e quali impostazioni deve mantenere l’utilizzatore.
Infrastruttura clinica condivisa
Un sistema centralizzato di monitoraggio o informativo ospedaliero può connettere molti dispositivi. Mostrare come l’accesso tramite tale sistema condiviso possa incidere su altri dispositivi o pazienti.
Collegare l’architettura ai controlli del rischio
Per ogni interfaccia importante, l’architettura dovrebbe aiutare il revisore a individuare la minaccia affrontata e la prova che verifica la protezione. Se il progetto dipende da una restrizione della rete ospedaliera, le informazioni per l’utilizzatore devono descrivere tale restrizione affinché possa essere mantenuta durante l’uso.