Verificatie en autorisatie voor Azure Health Data Services

Verificatie

Azure Health Data Services is een verzameling beveiligde beheerde services met behulp van Microsoft Entra ID, een globale id-provider die ondersteuning biedt voor OAuth 2.0.

Voor Toegang tot Azure Health Data Services tot Azure-resources, zoals opslagaccounts en Event Hubs, moet u de door het systeem beheerde identiteit inschakelen en de juiste machtigingen verlenen aan de beheerde identiteit. Zie Beheerde Identiteiten van Azure voor meer informatie.

De clienttoepassingen worden geregistreerd in de Microsoft Entra-id en kunnen worden gebruikt voor toegang tot De Azure Health Data Services. Besturingselementen voor toegang tot gebruikersgegevens worden uitgevoerd in de toepassingen of services die bedrijfslogica implementeren.

Toepassingsrollen

Geverifieerde gebruikers en clienttoepassingen van De Azure Health Data Services moeten worden toegewezen aan de juiste toepassingsrol.

De FHIR-service® in Azure Health Data Services biedt deze rollen:

• FHIR-gegevenslezer: FHIR-gegevens lezen en doorzoeken.
• FHIR Data Writer: FHIR-gegevens lezen, schrijven en voorlopig verwijderen.
• FHIR-gegevensexporteur: gegevens lezen en exporteren ($export operator).
• FHIR-gegevensimporteur: gegevens lezen en importeren ($import operator).
• FHIR-gegevensbijdrager: voer alle bewerkingen in het gegevensvlak uit.
• FHIR Data Converter: Gebruik het conversieprogramma om gegevensconversie uit te voeren.
• FHIR SMART User: hiermee kan de gebruiker FHIR-gegevens lezen en schrijven volgens de specificaties van SMART IG V1.0.0.

De DICOM-service® in Azure Health Data Services biedt de volgende rollen:

• DICOM-gegevenseigenaar: DICOM-gegevens lezen, schrijven en verwijderen.
• DICOM-gegevens lezen: DICOM-gegevens lezen.

De MedTech-service vereist geen toepassingsrollen, maar is wel afhankelijk van Azure Event Hubs-gegevensontvanger om gegevens op te halen die zijn opgeslagen in de Event Hub van het abonnement van uw organisatie.

Autorisatie

Nadat deze zijn verleend met de juiste toepassingsrollen, hebben de geverifieerde gebruikers en clienttoepassingen toegang tot Azure Health Data Services door een geldig toegangstoken te verkrijgen dat is uitgegeven door Microsoft Entra ID en specifieke bewerkingen uit te voeren die zijn gedefinieerd door de toepassingsrollen.

• Voor de FHIR-service is het toegangstoken specifiek voor de service of resource.
• Voor de DICOM-service wordt het toegangstoken verleend aan de dicom.healthcareapis.azure.com resource, niet aan een specifieke service.
• Voor de MedTech-service is het toegangstoken niet vereist omdat het niet beschikbaar is voor de gebruikers of clienttoepassingen.

Stappen voor autorisatie

Er zijn twee veelvoorkomende manieren om een toegangstoken te verkrijgen, dat in detail wordt beschreven in de Microsoft Entra-documentatie: autorisatiecodestroom en clientreferentiestroom.

U kunt als volgt een toegangstoken voor Azure Health Data Services verkrijgen met behulp van de autorisatiecodestroom:

1. De client verzendt een aanvraag naar het Microsoft Entra-autorisatie-eindpunt. Microsoft Entra ID leidt de client om naar een aanmeldingspagina waar de gebruiker zich verifieert met de juiste referenties (bijvoorbeeld gebruikersnaam en wachtwoord of tweeledige verificatie). Na een geslaagde verificatie wordt een autorisatiecode geretourneerd naar de client. Met Microsoft Entra kan deze autorisatiecode alleen worden geretourneerd naar een geregistreerde antwoord-URL die is geconfigureerd in de registratie van de clienttoepassing.

2. De clienttoepassing wisselt de autorisatiecode uit voor een toegangstoken op het Microsoft Entra-tokeneindpunt. Wanneer de clienttoepassing een token aanvraagt, moet de toepassing mogelijk een clientgeheim opgeven (dat u kunt toevoegen tijdens de registratie van de toepassing).

3. De client doet een aanvraag bij de Azure Health Data Services, bijvoorbeeld een GET aanvraag om alle patiënten in de FHIR-service te doorzoeken. De aanvraag bevat bijvoorbeeld het toegangstoken in een HTTP aanvraagheader Authorization: Bearer xxx.

4. Azure Health Data Services valideert dat het token de juiste claims bevat (eigenschappen in het token). Als deze geldig is, wordt de aanvraag voltooid en worden gegevens naar de client geretourneerd.

In de stroom met clientreferenties worden machtigingen rechtstreeks aan de toepassing zelf verleend. Wanneer de toepassing een token aan een resource presenteert, dwingt de resource af dat de toepassing zelf autorisatie heeft om een actie uit te voeren, omdat er geen gebruiker betrokken is bij de verificatie. Daarom verschilt het van de autorisatiecodestroom op deze manieren:

• De gebruiker of de client hoeft zich niet interactief aan te melden.
• De autorisatiecode is niet vereist.
• Het toegangstoken wordt rechtstreeks verkregen via toepassingsmachtigingen.

Toegangstoken

Het toegangstoken is een ondertekende, base64 gecodeerde verzameling eigenschappen (claims) die informatie overbrengen over de identiteit, rollen en bevoegdheden van de client die zijn verleend aan de gebruiker of client.

Azure Health Data Services verwacht doorgaans een JSON-webtoken. Het bestaat uit drie delen:

• Koptekst
• Nettolading (de claims)
• Handtekening, zoals wordt weergegeven in de afbeelding. Zie Azure-toegangstokens voor meer informatie.

Gebruik onlinehulpprogramma's zoals https://jwt.ms het weergeven van de tokeninhoud. U kunt bijvoorbeeld de details van de claims bekijken.

Claimtype	Value	Notes
aud	https://xxx.fhir.azurehealthcareapis.com	Identificeert de beoogde ontvanger van het token. In id_tokens, de doelgroep is de toepassings-id van uw app, toegewezen aan uw app in Azure Portal. Uw app moet deze waarde valideren en het token afwijzen als de waarde niet overeenkomt.
iss	https://sts.windows.net/{tenantid}/	Identificeert de beveiligingstokenservice (STS) die het token bouwt en retourneert, en de Microsoft Entra-tenant waarin de gebruiker is geverifieerd. Als het token is uitgegeven door het v2.0-eindpunt, eindigt de URI in /v2.0. De GUID die aangeeft dat de gebruiker een consumentgebruiker is van een Microsoft-account is 9188040d-6c67-4c5b-b112-36a304b66dad. Uw app moet het GUID-gedeelte van de claim gebruiken om de set tenants te beperken die zich kunnen aanmelden bij de app, indien van toepassing.
iat	(tijdstempel)	'Uitgegeven op' geeft aan wanneer de verificatie voor dit token heeft plaatsgevonden.
nbf	(tijdstempel)	De claim 'nbf' (not before) geeft de tijd aan waarvoor de JWT NIET mag worden geaccepteerd voor verwerking.
exp	(tijdstempel)	De "exp" (vervaltijd)-claim identificeert de vervaltijd op of waarna de JWT niet moet worden geaccepteerd voor verwerking. Een resource kan het token vóór deze tijd weigeren, bijvoorbeeld als een wijziging in de verificatie is vereist of als er een tokenintrekking wordt gedetecteerd.
aio	E2ZgYxxx	Een interne claim die door Microsoft Entra-id wordt gebruikt om gegevens vast te leggen voor hergebruik van tokens. Moet worden genegeerd.
appid	e97e1b8c-xxx	De toepassings-id van de client met behulp van het token. De toepassing kan fungeren als zichzelf of namens een gebruiker. De toepassings-id vertegenwoordigt doorgaans een toepassingsobject, maar kan ook een service-principalobject in Microsoft Entra-id vertegenwoordigen.
appidacr	1	Geeft aan hoe de client is geverifieerd. Voor een openbare client is de waarde 0. Als client-id en clientgeheim worden gebruikt, is de waarde 1. Als er een clientcertificaat is gebruikt voor verificatie, is de waarde 2.
idp	https://sts.windows.net/{tenantid}/	Registreert de identiteitsprovider waarmee het onderwerp van het token is geverifieerd. Deze waarde is identiek aan de waarde van de verlenerclaim, tenzij het gebruikersaccount zich niet in dezelfde tenant bevindt als de verlener - gasten, bijvoorbeeld. Als de claim niet aanwezig is, betekent dit dat in plaats daarvan de waarde van iss kan worden gebruikt. Voor persoonlijke accounts die worden gebruikt in een organisatiecontext (bijvoorbeeld een persoonlijk account dat is uitgenodigd voor een Microsoft Entra-tenant), kan de idp-claim 'live.com' zijn of een STS-URI met de Microsoft-accounttenant 9188040d-6c67-4c5b-b112-36a304b66dad.
oid	Bijvoorbeeld tenantid	De onveranderbare id voor een object in het Microsoft-identiteitssysteem, in dit geval een gebruikersaccount. Deze id identificeert de gebruiker in verschillende toepassingen: twee verschillende toepassingen die zich aanmelden bij dezelfde gebruiker, ontvangen dezelfde waarde in de oid-claim. Microsoft Graph retourneert deze id als de id-eigenschap voor een bepaald gebruikersaccount. Omdat de oid meerdere apps toestaat om gebruikers te correleren, is het profielbereik vereist om deze claim te ontvangen. Opmerking: Als één gebruiker in meerdere tenants bestaat, bevat de gebruiker een andere object-id in elke tenant. Ze worden beschouwd als verschillende accounts, ook al meldt de gebruiker zich aan bij elk account met dezelfde referenties.
rh	0.ARoxxx	Een interne claim die wordt gebruikt door Azure om tokens opnieuw te valideren. Het moet worden genegeerd.
sub	Bijvoorbeeld tenantid	De principal waarover het token informatie bevestigt, zoals de gebruiker van een app. Deze waarde is onveranderbaar en kan niet opnieuw worden toegewezen of opnieuw worden gebruikt. Het onderwerp is een paargewijze id. Het is uniek voor een bepaalde toepassings-id. Dus als één gebruiker zich aanmeldt bij twee verschillende apps met twee verschillende client-id's, ontvangen deze apps twee verschillende waarden voor de onderwerpclaim. Mogelijk wilt u dit resultaat niet afhankelijk van uw architectuur en privacyvereisten.
tid	Bijvoorbeeld tenantid	Een GUID die de Microsoft Entra-tenant vertegenwoordigt waaruit de gebruiker afkomstig is. Voor werk- en schoolaccounts is de GUID de onveranderbare tenant-id van de organisatie waartoe de gebruiker behoort. Voor persoonlijke accounts is de waarde 9188040d-6c67-4c5b-b112-36a304b66dad. Het profielbereik is vereist om deze claim te ontvangen.
uti	bY5glsxxx	Een interne claim die wordt gebruikt door Azure om tokens opnieuw te valideren. Het moet worden genegeerd.
ver	1	Geeft de versie van het token aan.

Het toegangstoken is standaard één uur geldig. U kunt een nieuw token verkrijgen of vernieuwen met behulp van het vernieuwingstoken voordat het verloopt.

Als u een toegangstoken wilt verkrijgen, kunt u hulpprogramma's zoals Postman, de REST Client-extensie in Visual Studio Code, PowerShell, CLI, curl en de Microsoft Entra-verificatiebibliotheken gebruiken.

Versleuteling

Wanneer u een nieuwe service van Azure Health Data Services maakt, worden uw gegevens standaard versleuteld met door Microsoft beheerde sleutels .

• De FHIR-service biedt versleuteling van data-at-rest wanneer gegevens worden bewaard in het gegevensarchief.
• DE DICOM-service biedt versleuteling van data-at-rest wanneer imaginggegevens, inclusief ingesloten metagegevens, worden bewaard in het gegevensarchief. Wanneer metagegevens worden geëxtraheerd en bewaard in de FHIR-service, wordt deze automatisch versleuteld.
• De MedTech-service, na gegevenstoewijzing en normalisatie, bewaart apparaatberichten naar de FHIR-service, die automatisch wordt versleuteld. In gevallen waarin apparaatberichten worden verzonden naar Azure Event Hubs, die Gebruikmaken van Azure Storage om de gegevens op te slaan, worden gegevens automatisch versleuteld met Azure Storage Service Encryption (Azure SSE).

Volgende stappen

Azure Health Data Services-werkruimte implementeren met behulp van Azure Portal

Azure Active Directory B2C gebruiken om toegang te verlenen tot de FHIR-service

Notitie

FHIR® is een geregistreerd handelsmerk van HL7 en wordt gebruikt met de machtiging HL7.

DICOM® is het gedeponeerde handelsmerk van de National Electrical Manufacturers Association voor haar standaardenpublicaties met betrekking tot digitale communicatie van medische informatie.