Condividi tramite

Autenticazione e autorizzazione per Servizi per i dati sanitari di Azure

  • Articolo

Autenticazione

Servizi dati di integrità di Azure è una raccolta di servizi gestiti protetti tramite Microsoft Entra ID, un provider di identità globale che supporta OAuth 2.0.

Per consentire a Servizi dati di integrità di Azure di accedere alle risorse di Azure, ad esempio gli account di archiviazione e gli hub eventi, è necessario abilitare l'identità gestita del sistema e concedere autorizzazioni appropriate all'identità gestita. Per altre informazioni, vedere Identità gestite di Azure.

Le applicazioni client vengono registrate nell'ID Microsoft Entra e possono essere usate per accedere a Servizi dati di integrità di Azure. I controlli di accesso ai dati utente vengono eseguiti nelle applicazioni o nei servizi che implementano la logica di business.

Ruoli applicazione

Gli utenti autenticati e le applicazioni client di Azure Health Data Services devono essere assegnati al ruolo applicazione appropriato.

Il servizio FHIR® in Servizi dati di integrità di Azure fornisce questi ruoli:

  • Lettore dati FHIR: leggere e cercare i dati FHIR.
  • FHIR Data Writer: lettura, scrittura e eliminazione temporanea dei dati FHIR.
  • FHIR Data Exporter: dati di lettura ed esportazione (operatore $export).
  • Utilità di importazione dati FHIR: dati di lettura e importazione (operatore $import).
  • Collaboratore dati FHIR: eseguire tutte le operazioni del piano dati.
  • Convertitore di dati FHIR: usare il convertitore per eseguire la conversione dei dati.
  • FHIR SMART User: consente all'utente di leggere e scrivere dati FHIR in base alle specifiche SMART IG V1.0.0.

Il servizio DICOM® in Servizi dati di integrità di Azure fornisce i ruoli seguenti:

  • Proprietario dati DICOM: lettura, scrittura ed eliminazione dei dati DICOM.
  • Dati DICOM letti: leggere i dati DICOM.

Il servizio MedTech non richiede ruoli dell'applicazione, ma si basa su Hub eventi di Azure Ricevitore dati per recuperare i dati archiviati nell'hub eventi della sottoscrizione dell'organizzazione.

Autorizzazione

Dopo essere stati concessi con ruoli applicazione appropriati, gli utenti autenticati e le applicazioni client possono accedere a Servizi dati di integrità di Azure ottenendo un token di accesso valido rilasciato dall'ID Entra Di Microsoft ed eseguire operazioni specifiche definite dai ruoli dell'applicazione.

  • Per il servizio FHIR, il token di accesso è specifico del servizio o della risorsa.
  • Per il servizio DICOM, il token di accesso viene concesso alla dicom.healthcareapis.azure.com risorsa, non a un servizio specifico.
  • Per il servizio MedTech, il token di accesso non è necessario perché non è esposto agli utenti o alle applicazioni client.

Passaggi per l'autorizzazione

Esistono due modi comuni per ottenere un token di accesso, descritti in dettaglio nella documentazione di Microsoft Entra: flusso del codice di autorizzazione e flusso delle credenziali client.

Ecco come viene ottenuto un token di accesso per Servizi dati di integrità di Azure usando il flusso del codice di autorizzazione:

  1. Il client invia una richiesta all'endpoint di autorizzazione di Microsoft Entra. Microsoft Entra ID reindirizza il client a una pagina di accesso in cui l'utente esegue l'autenticazione usando le credenziali appropriate, ad esempio nome utente e password o autenticazione a due fattori. Al termine dell'autenticazione, viene restituito un codice di autorizzazione al client. Microsoft Entra-only consente di restituire questo codice di autorizzazione a un URL di risposta registrato configurato nella registrazione dell'applicazione client.

  2. L'applicazione client scambia il codice di autorizzazione per un token di accesso nell'endpoint del token Microsoft Entra. Quando l'applicazione client richiede un token, l'applicazione potrebbe dover fornire un segreto client (che è possibile aggiungere durante la registrazione dell'applicazione).

  3. Il client invia una richiesta ai servizi dati di Integrità di Azure, ad esempio una GET richiesta di ricerca di tutti i pazienti nel servizio FHIR. La richiesta include il token di accesso in un'intestazione HTTP di richiesta, Authorization: Bearer xxxad esempio .

  4. Servizi dati di integrità di Azure convalida che il token contiene attestazioni appropriate (proprietà nel token). Se è valido, completa la richiesta e restituisce i dati al client.

Nel flusso delle credenziali client, le autorizzazioni vengono concesse direttamente all'applicazione stessa. Quando l'applicazione presenta un token a una risorsa, la risorsa impone che l'applicazione stessa abbia l'autorizzazione per eseguire un'azione perché non è presente alcun utente coinvolto nell'autenticazione. Di conseguenza, è diverso dal flusso del codice di autorizzazione in questi modi:

  • L'utente o il client non deve accedere in modo interattivo.
  • Il codice di autorizzazione non è obbligatorio.
  • Il token di accesso viene ottenuto direttamente tramite le autorizzazioni dell'applicazione.

Token di accesso

Il token di accesso è una raccolta con codifica Base64 firmata di proprietà (attestazioni) che forniscono informazioni sull'identità, i ruoli e i privilegi del client concessi all'utente o al client.

Servizi dati di integrità di Azure prevede in genere un token Web JSON. È costituito da tre parti:

  • Intestazione
  • Payload (attestazioni)
  • Firma, come illustrato nell'immagine. Per altre informazioni, vedere Token di accesso di Azure.

Screenshot che mostra la firma del token Web

Usare strumenti online, https://jwt.ms ad esempio per visualizzare il contenuto del token. Ad esempio, è possibile visualizzare i dettagli delle attestazioni.

Tipo di attestazione valore Note
aud https://xxx.fhir.azurehealthcareapis.com Identifica il destinatario del token. Negli id_tokens il destinatario è l'ID applicazione assegnato all'app nel portale di Azure. L'app deve convalidare questo valore e rifiutare il token se il valore non corrisponde.
iss https://sts.windows.net/{tenantid}/ Identifica il servizio token di sicurezza (STS) che costruisce e restituisce il token e il tenant di Microsoft Entra in cui l'utente è stato autenticato. Se il token è stato rilasciato dall'endpoint 2.0, l'URI termina in /v2.0. Il GUID che indica che l'utente è un utente consumer di un account Microsoft è 9188040d-6c67-4c5b-b112-36a304b66dad. L'app deve usare la parte GUID dell'attestazione per limitare il set di tenant che possono accedere all'app, se applicabile.
iat (timestamp) "Issued At" indica quando è avvenuta l'autenticazione per il token.
nbf (timestamp) L'attestazione "nbf" (not before) identifica l'ora prima della quale il token JWT non deve essere accettato per l'elaborazione.
exp (timestamp) L'attestazione "exp" (expiration time) identifica l'ora di scadenza a partire dalla quale o successivamente alla quale il token JWT non deve essere accettato per l'elaborazione. Una risorsa potrebbe rifiutare il token prima di questa volta, ad esempio se è necessaria una modifica nell'autenticazione o viene rilevata una revoca del token.
aio E2ZgYxxx Attestazione interna usata da Microsoft Entra ID per registrare i dati per il riutilizzo del token. Deve essere ignorata.
appid e97e1b8c-xxx ID applicazione del client che usa il token. L'applicazione può fungere per conto proprio o per conto dell'utente. L'ID applicazione rappresenta in genere un oggetto applicazione, ma può anche rappresentare un oggetto entità servizio in Microsoft Entra ID.
appidacr 1 Indica la modalità di autenticazione del client. Per un client pubblico, il valore è 0. Se vengono usati l'ID client e il segreto client, il valore è 1. Se venisse usato un certificato client per l'autenticazione, il valore sarebbe pari a 2.
idp https://sts.windows.net/{tenantid}/ Registra il provider di identità che ha autenticato l'oggetto del token. Questo valore è identico al valore dell'attestazione Autorità di certificazione, a meno che l'account utente non si trova nello stesso tenant dell'emittente, ad esempio guest. Se l'attestazione non è presente, significa che è possibile usare il valore di iss. Per gli account personali usati in un contesto aziendale (ad esempio, un account personale invitato a un tenant di Microsoft Entra), l'attestazione idp potrebbe essere "live.com" o un URI stS contenente il tenant dell'account Microsoft 9188040d-6c67-4c5b-b112-36a304b66dad.
oid Ad esempio, tenantid Identificatore non modificabile per un oggetto nel sistema di identità Microsoft, in questo caso, un account utente. Questo ID identifica in modo univoco l'utente tra le applicazioni: due applicazioni diverse che accedono allo stesso utente ricevono lo stesso valore nell'attestazione oid. Microsoft Graph restituisce questo ID come proprietà ID per un determinato account utente. Poiché l'oid consente a più app di correlare gli utenti, l'ambito del profilo è necessario per ricevere questa attestazione. Nota: se un singolo utente esiste in più tenant, l'utente contiene un ID oggetto diverso in ogni tenant, considerato account diversi, anche se l'utente accede a ogni account con le stesse credenziali.
Rh 0.ARoxxx Attestazione interna usata da Azure per riconvalidare i token. Deve essere ignorato.
secondario Ad esempio, tenantid Entità su cui il token asserisce informazioni, ad esempio l'utente di un'app. Questo valore non è modificabile e non può essere riassegnato o riutilizzato. L'oggetto è un identificatore pairwise, che è univoco per un ID applicazione specifico. Pertanto, se un singolo utente accede a due app diverse usando due ID client diversi, tali app ricevono due valori diversi per l'attestazione dell'oggetto. Questo risultato potrebbe non essere utile a seconda dell'architettura e dei requisiti di privacy.
tid Ad esempio, tenantid GUID che rappresenta il tenant di Microsoft Entra da cui proviene l'utente. Per gli account aziendali e dell'istituto di istruzione, il GUID è l'ID tenant non modificabile dell'organizzazione a cui appartiene l'utente. Per gli account personali, il valore è 9188040d-6c67-4c5b-b112-36a304b66dad. L'ambito del profilo è obbligatorio per ricevere questa attestazione.
uti bY5glsxxx Attestazione interna usata da Azure per riconvalidare i token. Deve essere ignorato.
ver 1 Indica la versione del token.

Il token di accesso è valido per un'ora per impostazione predefinita. È possibile ottenere un nuovo token o rinnovarlo usando il token di aggiornamento prima della scadenza.

Per ottenere un token di accesso, è possibile usare strumenti come Postman, l'estensione client REST in Visual Studio Code, PowerShell, interfaccia della riga di comando, curl e le librerie di autenticazione di Microsoft Entra.

Crittografia

Quando si crea un nuovo servizio di Servizi dati di integrità di Azure, i dati vengono crittografati usando le chiavi gestite da Microsoft per impostazione predefinita.

  • Il servizio FHIR fornisce la crittografia dei dati inattivi quando i dati vengono salvati in modo permanente nell'archivio dati.
  • Il servizio DICOM fornisce la crittografia dei dati inattivi quando i dati di creazione dell'immagine, inclusi i metadati incorporati, vengono resi persistenti nell'archivio dati. Quando i metadati vengono estratti e salvati in modo permanente nel servizio FHIR, vengono crittografati automaticamente.
  • Il servizio MedTech, dopo il mapping dei dati e la normalizzazione, rende persistenti i messaggi del dispositivo nel servizio FHIR, che viene crittografato automaticamente. Nei casi in cui i messaggi del dispositivo vengono inviati a Hub eventi di Azure, che usano Archiviazione di Azure per archiviare i dati, i dati vengono crittografati automaticamente con crittografia del servizio di Archiviazione di Azure (Azure S edizione Standard).

Passaggi successivi

Distribuire l'area di lavoro di Servizi dati di Integrità di Azure usando il portale di Azure

Usare Azure Active Directory B2C per concedere l'accesso al servizio FHIR

Nota

FHIR® è un marchio registrato di HL7 e viene usato con l'autorizzazione di HL7.

DICOM® è il marchio registrato della National Electrical Manufacturers Association per le sue pubblicazioni Standard relative alle comunicazioni digitali delle informazioni mediche.