Sicurezza dei portali per pazienti: testare gli accessi oltre il login

La decisione che questa guida vi aiuta a prendere

L’accesso conferma un’identità, ma non dimostra l’autorizzazione a consultare uno specifico record o a esportarlo. Confronta i ruoli di pazienti, delegati e personale clinico nelle relazioni di cura attive e revocate. Osserva l’operazione specifica e l’accesso che ne deriva, anziché basarti sull’esito dell’accesso.

Definire chiaramente il modello delle autorizzazioni

Gli accessi dei pazienti, i delegati familiari, i medici curanti, il personale di supporto e gli amministratori seguono spesso regole diverse. Descriva queste relazioni come attore, oggetto e azione prima di esaminare i payload. Includa gli accessi dei delegati scaduti e il personale trasferito tra organizzazioni di erogatori; questi stati del ciclo di vita spesso rivelano lacune che i test dei soli percorsi previsti non evidenziano.

Confrontare le decisioni sullo stesso oggetto

Mantenere costante l’oggetto mentre si cambia il principal, quindi mantenere costante il principal mentre si cambia il proprietario dell’oggetto. Verificare la risposta del server e il successivo evento di audit. Un pulsante nascosto non è un controllo di accesso e un identificativo di record imprevedibile non sostituisce una decisione di autorizzazione.

Esaminare le interfacce secondarie

Il download di un documento, un processo di esportazione o un’API mobile di un portale possono applicare controlli diversi da quelli della pagina principale del record. Verifichi ogni percorso consentito con la stessa matrice sintetica dei ruoli. La creazione, la verifica dello stato e il recupero di un’esportazione sono operazioni separate e potrebbero richiedere controlli di autorizzazione distinti.

Rendere verificabile la correzione

Si raccomanda una policy lato server al confine tra oggetto e operazione, quindi si riprovano sia gli accessi consentiti sia quelli vietati. Registrare il soggetto, il record di test, l’ID della richiesta e il risultato. L’obiettivo è ottenere una decisione di accesso chiara senza compromettere l’accesso legittimo alle cure, anziché limitarsi a sopprimere un messaggio di errore.

Utilizzare coppie di account e record

Preparate due pazienti con appuntamenti, messaggi e documenti sintetici separati. Stabilite la baseline legittima per ciascun account, quindi ripetete una singola operazione concordata sull’oggetto canary dell’altro account. Mantenete comparabili il tipo di richiesta e lo stato dell’oggetto. In questo modo la decisione sulla titolarità è isolata da errori di convalida non correlati. Includete un account delegato solo se il portale lo supporta, documentando chiaramente la relazione e la scadenza. Non presumete che l’accesso familiare a un tipo di documentazione consenta l’accesso a tutta la documentazione.

Lo stesso confronto è utile per i professionisti clinici che operano in più strutture: un account può legittimamente accedere alle cartelle in due contesti, mentre un altro può avere accesso a uno solo. Il risultato atteso deve essere definito dal titolare del servizio, non dedotto dal tester sulla base di una supposizione relativa al rapporto assistenziale previsto.

Testare il ciclo di vita di un’autorizzazione esistente

L’accesso può essere corretto al momento della creazione e non esserlo più dopo una modifica del rapporto. Concordate verifiche per la revoca, il trasferimento tra organizzazioni e la scadenza di un ruolo delegato. Verificate se un link a un documento già emesso, un’esportazione in coda o una sessione attiva continuano a esporre il materiale sintetico. Utilizzate pochi oggetti predisposti e registrate il momento in cui la modifica dei criteri dovrebbe entrare in vigore. Non concludete che un controllo abbia fallito solo perché la documentazione del prodotto descrive un ritardo intenzionale e approvato; confrontate quanto osservato con il requisito effettivo.

La nostra guida sull’isolamento dei tenant spiega perché è necessario esaminare insieme il rifiuto della richiesta e lo stato successivo. Questo metodo si applica bene anche ai portali con generazione asincrona di documenti.

Descrivere un rilievo che il team di prodotto possa correggere

Le evidenze dovrebbero identificare il ruolo che effettua la richiesta, il responsabile previsto, l’operazione e l’autorizzazione specifica che avrebbe dovuto impedirla. Acquisire una richiesta e una risposta con i dati oscurati, insieme all’identificativo sintetico dell’oggetto e, se disponibile, a un riferimento di audit lato server. Indicare se l’osservazione dimostra accesso in lettura, modifica o soltanto individuazione dell’oggetto. Si tratta di impatti diversi. Uno screenshot di una pagina paziente senza contesto sull’identità costituisce una prova debole e può esporre inutilmente materiale sensibile.

I test di ripetizione dovrebbero ripetere il confronto non superato, confermare che l’accesso legittimo continui a funzionare e verificare l’endpoint equivalente più vicino. Se il problema riguarda un’integrazione utilizzata da un ospedale, la nostra guida ai test delle integrazioni EHR e di diagnostica per immagini aiuta a individuare le ulteriori identità di servizio da esaminare.

Applicate le indicazioni

Utilizzate la lista di preparazione per documentare le ipotesi oppure consultate il rapporto fittizio di Healthcare AG per esempi di evidenze e piani di trattamento. Contattate Atlant Security con una descrizione non sensibile dell’ambito.