Autenticazione e autorizzazione per Servizi per i dati sanitari di Azure

  • Articolo

Authentication

Servizi dati di Integrità di Azure è una raccolta di servizi gestiti protetti tramite Azure Active Directory (Azure AD), 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 account di archiviazione e hub eventi, è necessario abilitare l'identità gestita del sistema e concedere le autorizzazioni appropriate all'identità gestita. Per altre informazioni, vedere Identità gestite di Azure.

Servizi dati di integrità di Azure non supporta altri provider di identità. Tuttavia, è possibile usare il proprio provider di identità per proteggere le applicazioni e consentire loro di interagire con Health Data Services gestendo le applicazioni client e i controlli di accesso ai dati utente.

Le applicazioni client vengono registrate in Azure AD 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 Servizi dati di integrità di Azure devono essere concessi con ruoli applicazione appropriati.

Il servizio FHIR di Servizi dati di integrità di Azure fornisce i ruoli seguenti:

  • Lettore dati FHIR: può leggere (e cercare) i dati FHIR.
  • Writer di dati FHIR: può leggere, scrivere ed eliminare soft i dati FHIR.
  • Esportazione dati FHIR: può leggere ed esportare i dati (operatore $export).
  • Importazione dati FHIR: può leggere e importare i dati (operatore $import).
  • Collaboratore dati FHIR: può eseguire tutte le operazioni del piano dati.
  • Convertitore di dati FHIR: può usare il convertitore per eseguire la conversione dei dati.
  • FHIR SMART User: il ruolo consente all'utente di leggere e scrivere dati FHIR in base alle specifiche SMART IG V1.0.0.

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

  • Proprietario dati DICOM: può leggere, scrivere ed eliminare dati DICOM.
  • Dati DICOM letti: può leggere i dati DICOM.

Il servizio MedTech non richiede ruoli applicazione, ma si basa sul "ricevitore di dati Hub eventi di Azure" per recuperare i dati archiviati nell'hub eventi della sottoscrizione del cliente.

Autorizzazione

Dopo aver ottenuto i 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 da Azure AD ed eseguire operazioni specifiche definite dai ruoli 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 Azure AD: 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 Azure AD. Azure AD 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, al client viene restituito un codice di autorizzazione. Azure AD consente di restituire questo codice di autorizzazione solo 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 di Azure AD. 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 effettua una richiesta ai servizi dati di integrità di Azure, ad esempio una GET richiesta di ricerca in 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 contenga 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 esiste alcun utente coinvolto nell'autenticazione. Di conseguenza, è diverso dal flusso del codice di autorizzazione nei modi seguenti:

  • 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 trasmettono 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.

Firma del token Web JASON.

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 Azure AD in cui l'utente è stato autenticato. Se il token è stato emesso dall'endpoint v2.0, l'URI termina con /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. Si noti che una risorsa può rifiutare il token prima di questa volta, ad esempio se è necessaria una modifica nell'autenticazione o se è stata rilevata una revoca del token.
aio E2ZgYxxx Attestazione interna usata da Azure AD per registrare i dati per il riutilizzo dei 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 dell'applicazione in genere rappresenta un oggetto applicazione, ma può anche rappresentare un oggetto di entità servizio in Azure AD.
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 Issuer, 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 Azure AD), l'attestazione idp può essere "live.com" o un URI del servizio token di sicurezza 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 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.
sub Ad esempio, tenantid Principio sul quale 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. È possibile che si desideri o meno questo risultato a seconda dell'architettura e dei requisiti di privacy.
tid Ad esempio, tenantid Valore GUID che rappresenta il tenant di Azure AD 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 è necessario 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, cli, curl e le librerie di autenticazione di Azure AD.

Crittografia

Quando si crea un nuovo servizio di Servizi dati di integrità di Azure, i dati vengono crittografati usando 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 salvati in modo permanente 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 SSE).

Passaggi successivi

In questo documento si è appresa l'autenticazione e l'autorizzazione di Servizi dati di integrità di Azure. Per informazioni su come distribuire un'istanza di Servizi dati di integrità di Azure, vedere

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

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