Login sicuri per il settore sanitario

Queste organizzazioni diventano parte della HIN Community nel momento in cui scelgono un prodotto per il collegamento. Insieme a esso ricevono una o più identità HIN. Il collegamento consente loro di utilizzare i servizi HIN per comunicare e collaborare in sicurezza all’interno della Community e di accedere in modo sicuro alle applicazioni web. Per il collegamento sono disponibili diverse opzioni, come abbonamenti basati su client – collegamento abituale per i medici operanti in studi privati – oppure, per i clienti istituzionali, una soluzione gateway per la quale non è necessario installare alcun software su singole postazioni di lavoro.

Accesso sicuro alle applicazioni web

L’ampia diffusione dell’identità HIN nel settore sanitario svizzero rende interessante per i fornitori di applicazioni web la possibilità di collegarla alla piattaforma tramite Access Control Service (ACS) o Federation Service (FS). Ciò consente ai partecipanti di accedere in modo sicuro alla piattaforma con la loro identità tramite Single Sign-On. Ad esempio, un ospedale può chiedere di utilizzare l’identità HIN come strumento di autentificazione per la sua piattaforma di riferimento. Oltre a molteplici applicazioni esterne, l’azienda offre anche una serie di propri servizi appositamente sviluppati. Tra essi rientrano applicazioni che consentono una comunicazione sicura. L’esempio più noto è HIN Mail, un servizio di codifica automatica delle e-mail. Questo assicura che gli ospedali e i medici operanti in studi privati possano comunicare tra loro senza alcuna complessa integrazione nel programma di posta elettronica. Altri componenti del portfolio sono un servizio di messaggistica, uno strumento di collaborazione, una soluzione per la sicurezza degli endpoint rivolta alle esigenze dei medici, iniziative di formazione IT-Security Awareness e un portale Awareness.

Ecco come funziona l’autenticazione 

Utilizzando l’esempio di una collaboratrice fittizia nel settore sanitario – un medico – è possibile seguire il percorso che va dall’identificazione della persona, alla sua registrazione, fino al login nell’applicazione. Il medico si rivolge a HIN per registrarsi come tale e ottenere l’accesso ad applicazioni protette HIN. Il fornitore di identità deve ora accertarsi che le informazioni fornite dalla richiedente siano conformi ai fatti. HIN lo fa seguendo due procedure:

• Controllo dei documenti d’identità: al momento della registrazione, il medico deve fornire i suoi documenti di identità scansionati, che vengono in seguito esaminati da HIN.
• Identificazione video: il medico si collega in videochat con un collaboratore HIN, il quale pone domande per verificare la sua identità e nel contempo effettua un’identificazione sulla base di un documento d’identità.

Al termine di entrambe le procedure è garantito che tutti i dati relativi alla persona siano corretti. Di conseguenza, HIN può emettere un’identità. L’identità è dotata degli attributi sanitari rilevanti per il medico nell’esercizio della sua professione. Se la persona afferma di essere un medico, prima di rilasciare l’identità HIN lo verifica sulla base di registri medici e altre fonti. Una volta superato il controllo, il fornitore assegna uno strumento di autenticazione, con il quale in futuro il medico potrà autenticarsi nelle applicazioni collegate. Si tratta di uno strumento di autenticazione «classico» e noto ad altri fornitori di servizi di eID. Tuttavia, nome utente e password sono integrati da un secondo fattore. Come secondo fattore si utilizzano da un lato un SMS e dall’altro un’app Authenticator, che supporta un meccanismo di autorizzazione e la generazione di password monouso, o un token hardware. La procedura che prevede nome utente/password è supportata da HIN, ma è solo una forma alternativa di autenticazione accanto alle due procedure principali. Si tratta da un lato di un software client che deve essere installato sulla rispettiva postazione di lavoro e che di solito è utilizzato dai medici operanti in studi privati. L’autenticazione avviene tramite un certificato client oppure – la variante più recente e che acquisirà importanza in futuro – tramite procedura challenge -response: in questo caso, il server HIN invia una sfida (challenge) al client, il quale restituisce una risposta (response) firmata. Tuttavia, per le grandi organizzazioni non sarebbe pratico installare il client su migliaia di postazioni di lavoro. Pertanto, in questo caso si utilizza l’Access Gateway HIN, il quale viene installato una volta sulla rete dell’organizzazione e, analogamente al client, consente l’autenticazione tramite procedura challenge-response.

Proteggere in modo sicuro i dati del paziente 

Le procedure di autenticazione descritte sono utilizzate, tra l’altro, per la cartella informatizzata del paziente, introdotta in Svizzera alla fine del 2020. Al suo interno, i medici e altri professionisti della salute possono archiviare documenti relativi al paziente in questione. Ciò dovrebbe facilitare l’accesso ai dati sanitari per entrambe le parti; per i pazienti, in particolare, si rende così più trasparente ciò che il medico sa di loro. I pazienti possono stabilire chi può avere accesso ai dati, ad esempio concedendo autorizzazioni per l’accesso al medico di famiglia o anche revocando l’autorizzazione a quest’ultimo. La base giuridica per la procedura è disciplinata dalla Legge federale svizzera sulla cartella informatizzata del paziente. Per HIN sono particolarmente rilevanti due articoli:

• Art. 7: ogni persona che desidera accedere alla cartella deve disporre di un’identità elettronica.
• Art. 11: l’emittente di strumenti d’identificazione deve essere certificato.

Identity and Access Management con Nevis 

Per l’Identity and Access Management (IAM), ovvero la verifica delle autorizzazioni di un utente, HIN si affida alle soluzioni di Nevis. La collaborazione tra le due aziende è iniziata alla fine del 2013, quando HIN era alla ricerca di una nuova base software per l’IAM. L’appalto è stato vinto da Nevis, allora ancora sotto l’egida della società madre AdNovum Informatik. Determinante è stato il fatto che Nevis sia riuscita a dimostrare che i problemi con la soluzione precedente non si sarebbero più verificati in caso di cambiamento. Ciò ha riguardato in particolare la flessibilità nell’ambito dell’introduzione delle nuove procedure di autenticazione. Oggi, tutte le applicazioni offerte da HIN sono protette dall’IAM di Nevis. In questo contesto viene eseguito un confronto automatico dei dati del sistema ERP con l’Identity Management, con la creazione di utenti e l’attribuzione di ruoli. A seconda delle applicazioni che il singolo utente ha ottenuto tramite HIN, nell’Identity Management vengono a lui assegnate diverse autorizzazioni. Questo confronto tra ERP (Enterprise Resource Planning) e IAM avviene in tempo reale. 

La sicurezza delle applicazioni è garantita da vari meccanismi, tra cui un Web Application Firewall. In questo modo si esclude l’estrazione dei dati tramite SQL Injection o Cross-Site Request Forgery (attacchi tramite il canale web). Le password sono memorizzate solo come hash e i criteri di password definiscono sia la lunghezza necessaria delle password sia il loro intervallo di sostituzione. Le soluzioni sono state verificate e certificate da KPMG secondo lo standard svizzero di eHealth, incluso il centro di calcolo in Svizzera, che garantisce che i dati sensibili non escano dai confini nazionali.

Processo di autenticazione dell’app SwissCovid 

Un altro esempio attuale di protezione dei dati sanitari sensibili è l’app SwissCovid. Analogamente alla Corona-Warn-App utilizzata in Germania, l’app mira a favorire il tracciamento dei contatti con persone che hanno contratto il Covid-19, facilitando così l’interruzione della catena infettiva. Il sistema di tracciamento è costituito da due componenti: l’app per smartphone e l’applicazione web Covidcode. HIN è tuttavia coinvolta direttamente solo nell’applicazione web. Se a un paziente viene diagnosticata la malattia, il medico può registrarsi nell’applicazione web Covidcode, per la quale si autenticherà con la sua identità HIN. Al suo interno il medico genera un codice che trasmette al paziente. Il paziente inserisce il codice nella propria app e in questo modo tutte le persone che hanno avuto contatti con una persona infetta vengono informate automaticamente. Il meccanismo impedisce l’invio di notifiche errate. Il processo di autenticazione ha inizio nel browser, ad esempio quando un medico accede a Covidcode come descritto sopra. L’accesso viene registrato sul proxy Nevis, che avvia l’autenticazione con «Nevis Auth». Qui, con un connettore http, si passa a una terza applicazione sviluppata da HIN, dove viene elaborata la sfida (challenge). Il terzo componente genera questa sfida e la invia al browser dell’utente tramite Nevis Auth e il proxy collegato. La pagina della sfida avvia due processi in parallelo nel browser. Da un lato, la pagina della sfida contatta il client HIN tramite un gestore di protocollo. Il client mostra una finestra di dialogo per il login. Per sbloccare il materiale chiave, l’utente deve immettere la propria passphrase. Una volta eseguita questa operazione, il client genera una risposta (response) firmata con il materiale chiave sbloccato. La risposta viene inviata al proxy Nevis, da dove viene trasmessa al terzo componente. Dall’altro lato viene inviata una richiesta con ID di sessione al proxy Nevis. Il proxy trasmette l’ID di sessione a Nevis Auth e da lì alla terza applicazione. Non appena da un lato la risposta firmata e dall’altro l’ID di sessione corretto arrivano alla terza applicazione, le due informazioni vengono abbinate. Utilizzando la firma, la terza applicazione è in grado di riconoscere l’utente che ha appena effettuato il login. Questa informazione ritorna a Nevis Auth, dopodiché il proxy trasmette un cookie di sessione al browser per il rispettivo utente. A partire da questo momento, nel browser viene stabilita una sessione autenticata e l’utente può accedere a tutte le applicazioni protette HIN senza dover immettere nuovamente nome utente/password o altre credenziali di autenticazione. Questa forma di autenticazione è utilizzata soprattutto con Access Gateway per grandi organizzazioni.