Authentifizierung und Autorisierung für Azure Health Data Services

  • Artikel

Authentifizierung

Azure Health Data Services ist eine Sammlung geschützter verwalteter Dienste unter Verwendung von Microsoft Entra ID, einem globalen Identitätsanbieter, der OAuth 2.0 unterstützt.

Damit Azure Health Data Services auf Azure-Ressourcen wie Speicherkonten und Event Hubs zugreifen kann, müssen Sie die vom System verwaltete Identität aktivieren und der verwalteten Identität entsprechende Berechtigungen erteilen. Weitere Informationen finden Sie unter Von Azure verwaltete Identitäten.

Die Clientanwendungen sind in Microsoft Entra ID registriert und können für den Zugriff auf Azure Health Data Services verwendet werden. Benutzerdatenzugriffssteuerelemente werden in den Anwendungen oder Diensten durchgeführt, die Geschäftslogik implementieren.

Anwendungsrollen

Authentifizierte Benutzer und Client-Anwendungen der Azure Health Data Services müssen der richtigen Anwendungsrolle zugewiesen sein.

Der FHIR®-Dienst in Azure Health Data Services bietet folgende Rollen:

  • FHIR-Datenleser: Kann FHIR-Daten lesen und durchsuchen.
  • FHIR-Datenschreiber: Kann FHIR-Daten lesen, schreiben und vorläufig löschen.
  • FHIR-Datenexportierer: Kann Daten lesen und exportieren ($export-Operator).
  • FHIR -Datenimportierer: Kann Daten lesen und importieren ($import-Operator).
  • FHIR-Datenmitwirkender: Kann alle Vorgänge auf Datenebene durchführen.
  • FHIR-Datenkonvertierer: Kann den Konverter verwenden, um Datenkonvertierung durchzuführen.
  • FHIR SMART-Benutzer: Ermöglicht dem Benutzer das Lesen und Schreiben von FHIR-Daten gemäß SMART IG V1.0.0-Spezifikationen.

Der DICOM®-Dienst in Azure Health Data Services bietet folgende Rollen:

  • DICOM-Datenbesitzer: Kann DICOM-Daten lesen, schreiben und löschen.
  • DICOM-Datenleser: Kann DICOM-Daten lesen.

Der MedTech-Dienst erfordert keine Anwendungsrollen, basiert jedoch auf Azure Event Hubs Data Receiver zum Abrufen von Daten, die im Event Hub des Abonnements Ihrer Organisation gespeichert sind.

Autorisierung

Nachdem ihnen die richtigen Anwendungsrollen zugewiesen wurden, können die authentifizierten Benutzer und Client-Anwendungen auf Azure Health Data Services zugreifen, indem sie ein gültiges, von Microsoft Entra ID ausgestelltes Zugriffstoken erhalten und bestimmte, durch die Anwendungsrollen definierte Vorgänge durchführen.

  • Für den FHIR-Dienst ist das Zugriffstoken spezifisch für den Dienst oder die Ressource.
  • Für den DICOM-Dienst wird das Zugriffstoken der dicom.healthcareapis.azure.com-Ressource und nicht einem bestimmten Dienst gewährt.
  • Für den MedTech-Dienst ist das Zugriffstoken nicht erforderlich, da es nicht für die Benutzer oder Clientanwendungen verfügbar gemacht wird.

Schritte für die Autorisierung

Es gibt zwei gängige Methoden zum Abrufen eines Zugriffstokens, die in der Microsoft Entra-Dokumentation ausführlich beschrieben werden: Flow für Autorisierungscode und Flow für Clientanmeldeinformationen.

Hier erfahren Sie, wie ein Zugriffstoken für Azure Health Data Services mithilfe des Flow für Autorisierungscode abgerufen wird:

  1. Der Client sendet eine Anforderung an den Microsoft Entra-Autorisierungsendpunkt. Microsoft Entra ID leitet den Client zu einer Anmeldeseite um, auf der sich der Benutzer mit den entsprechenden Anmeldeinformationen (z. B. Benutzername und Kennwort oder Zwei-Faktor-Authentifizierung) authentifiziert. Nach erfolgreicher Authentifizierung wird ein Autorisierungscode an den Client zurückgegeben. Microsoft Entra erlaubt die Rückgabe dieses Autorisierungscodes nur an eine registrierte Antwort-URL, die bei der Registrierung der Clientanwendung konfiguriert wurde.

  2. Die Clientanwendung tauscht den Autorisierungscode gegen ein Zugriffstoken am Microsoft Entra-Tokenendpunkt aus. Wenn die Clientanwendung ein Token anfordert, muss die Anwendung möglicherweise einen geheimen Clientschlüssel angeben (den Sie während der Anwendungsregistrierung hinzufügen können).

  3. Der Client stellt eine Anforderung an Azure Health Data Services, z. B. eine GET-Anforderung, alle Patienten im FHIR-Dienst zu durchsuchen. Die Anforderung enthält das Zugriffstoken in einem HTTP-Anforderungsheader, z. B. Authorization: Bearer xxx.

  4. Azure Health Data Services prüft, ob das Token entsprechende Ansprüche (Eigenschaften im Token) enthält. Wenn es gültig ist, wird die Anforderung abgeschlossen und Daten werden an den Client zurückgegeben.

Im Clientanmeldeinformations-Flow werden Berechtigungen direkt an die Anwendung selbst erteilt. Wenn die Anwendung einer Ressource ein Token präsentiert, macht die Ressource geltend, dass die Anwendung selbst für die Durchführung einer Aktion autorisiert ist, da an der Authentifizierung kein Benutzer beteiligt ist. Daher unterscheidet er sich vom Autorisierungscodefluss auf folgende Weise:

  • Der Benutzer oder der Client muss sich nicht interaktiv anmelden.
  • Der Autorisierungscode ist nicht erforderlich.
  • Das Zugriffstoken wird direkt über Anwendungsberechtigungen abgerufen.

Zugriffstoken

Beim Zugriffstoken handelt es sich um eine signierte mit Base64 codierte Sammlung von Eigenschaften (Ansprüchen), die Informationen zur Identität des Clients und zu den Rollen und Berechtigungen enthalten, die dem Benutzer oder Client gewährt werden.

Azure Health Data Services erwartet in der Regel ein JSON-Webtoken. Es besteht aus drei Teilen:

  • Header
  • Nutzlast (die Ansprüche)
  • Signatur, wie in der Abbildung dargestellt. Weitere Informationen finden Sie unter Azure-Zugriffstoken.

Screenshot der Webtokensignatur

Verwenden Sie Onlinetools wie https://jwt.ms, um den Tokeninhalt anzuzeigen. Beispielsweise können Sie die Anspruchsdetails anzeigen.

Anspruchstyp Wert Hinweise
aud https://xxx.fhir.azurehealthcareapis.com Identifiziert den vorgesehenen Empfänger des Tokens. In id_tokens ist die Zielgruppe die Anwendungs-ID Ihrer App, die Ihrer App im Azure-Portal zugewiesen ist. Ihre App sollte diesen Wert überprüfen und das Token ablehnen, wenn der Wert nicht übereinstimmt.
Iss https://sts.windows.net/{tenantid}/ Identifiziert den Sicherheitstokendienst (STS), der das Token und den Microsoft Entra-Mandanten, in dem der Benutzer authentifiziert wurde, erstellt und zurückgibt. Wenn das Token vom v2.0-Endpunkt ausgegeben wurde, endet der URI mit /v2.0. Die GUID, die angibt, dass der Benutzer ein Consumer-Benutzer eines Microsoft-Kontos ist, lautet 9188040d-6c67-4c5b-b112-36a304b66dad. Ihre App sollte ggf. den GUID-Teil des Anspruchs verwenden, um die Mandanten einzuschränken, die sich bei der App anmelden können.
Iat (Zeitstempel) „Issued At“ gibt an, wann die Authentifizierung für dieses Token erfolgt ist.
nbf (Zeitstempel) Der Anspruch „nbf“ (nicht vor) gibt die Zeit an, vor der das JWT NICHT für die Bearbeitung akzeptiert werden darf.
exp (Zeitstempel) Der Anspruch „exp“ (Ablaufzeit) gibt die Ablaufzeit an, ab oder nach der das JWT NICHT für die Bearbeitung akzeptiert werden darf. Eine Ressource kann das Token vor diesem Zeitpunkt ablehnen, beispielsweise wenn eine Änderung der Authentifizierung erforderlich ist oder ein Tokenwiderruf erkannt wurde.
aio E2ZgYxxx Dabei handelt es sich um einen internen Anspruch, der von Microsoft Entra ID verwendet wird, um Daten für die Wiederverwendung von Token aufzuzeichnen. Sollte ignoriert werden.
appid e97e1b8c-xxx Die Anwendungs-ID des Clients, der das Token verwendet. Die Anwendung kann als sie selbst oder im Auftrag eines Benutzers agieren. Die Anwendungs-ID stellt in der Regel ein Anwendungsobjekt dar, kann jedoch auch ein Dienstprinzipalobjekt in Microsoft Entra ID darstellen.
appidacr 1 Gibt an, wie der Client authentifiziert wurde. Bei einem öffentlichen Client ist der Wert 0. Wenn die Client-ID und der geheime Clientschlüssel verwendet werden, ist der Wert 1. Wenn ein Clientzertifikat für die Authentifizierung verwendet wurde, lautet der Wert 2.
idp https://sts.windows.net/{tenantid}/ Der Identitätsanbieter, der den Antragsteller des Tokens authentifiziert hat. Dieser Wert ist identisch mit dem Wert des Ausstelleranspruchs, es sei denn, das Benutzerkonto ist nicht im gleichen Mandanten wie der Aussteller vorhanden (etwa Gäste). Wenn der Anspruch nicht vorhanden ist, bedeutet dies, dass stattdessen der Wert iss verwendet werden kann. Für persönliche Konten, die in einem Organisationskontext verwendet werden (etwa ein persönliches Konto, zu dem ein Microsoft Entra-Mandant eingeladen wurde), kann der idp-Anspruch „live.com“ oder ein STS-URI sein, der den Microsoft-Kontomandanten 9188040d-6c67-4c5b-b112-36a304b66dad enthält.
oid Beispiel: tenantid Der unveränderliche Bezeichner für ein Objekt im Microsoft-Identitätssystem, in diesem Fall ein Benutzerkonto. Diese ID identifiziert den Benutzer anwendungsübergreifend eindeutig: Zwei verschiedene Anwendungen, die den gleichen Benutzer anmelden, erhalten den gleichen Wert im oid-Anspruch. Microsoft Graph gibt diese ID als ID-Eigenschaft für ein bestimmtes Benutzerkonto zurück. Da mit oid mehrere Apps Benutzer korrelieren können, ist der Profil-Bereich erforderlich, um diesen Anspruch zu erhalten. Hinweis: Wenn ein einzelner Benutzer in mehreren Mandanten vorhanden ist, enthält der Benutzer in jedem Mandanten eine andere Objekt-ID. Sie werden als unterschiedliche Konten betrachtet, obwohl sich der Benutzer bei jedem Konto mit den gleichen Anmeldeinformationen anmeldet.
rh 0.ARoxxx Ein interner Anspruch, der von Azure zum erneuten Überprüfen von Token verwendet wird. Sollte ignoriert werden.
sub Beispiel: tenantid Der Prinzipal, für den das Token Informationen zusichert, z. B. der Benutzer einer App. Dieser Wert ist unveränderlich und kann nicht erneut zugewiesen oder wiederverwendet werden. Der Antragsteller ist ein paarweiser Bezeichner: Er gilt nur für eine bestimmte Anwendungs-ID. Wenn sich ein Benutzer bei zwei verschiedenen Apps mit zwei verschiedenen Client-IDs anmeldet, erhalten diese Apps zwei unterschiedliche Werte für den Antragstelleranspruch. Je nach Ihren Architektur- und Datenschutzanforderungen ist dieses Ergebnis möglicherweise unerwünscht.
tid Beispiel: tenantid Eine GUID, die den Microsoft Entra-Mandanten darstellt, von dem der Benutzer stammt. Bei Geschäfts- und Schulkonten ist die GUID die unveränderliche Mandanten-ID der Organisation, zu der der Benutzer gehört. Bei persönlichen Konten lautet der Wert 9188040d-6c67-4c5b-b112-36a304b66dad. Der Profil-Bereich ist erforderlich, um diesen Anspruch zu empfangen.
uti bY5glsxxx Ein interner Anspruch, der von Azure zum erneuten Überprüfen von Token verwendet wird. Sollte ignoriert werden.
ver 1 Gibt die Version des Tokens an.

Das Zugriffstoken ist standardmäßig für eine Stunde gültig. Sie können ein neues Token abrufen oder es mit dem Aktualisierungstoken verlängern, bevor es abläuft.

Zum Abrufen eines Zugriffstokens können Sie Tools wie Postman, die REST-Clienterweiterung in Visual Studio Code, PowerShell, CLI, curl und die Microsoft Entra-Authentifizierungsbibliotheken verwenden.

Verschlüsselung

Wenn Sie einen neuen Dienst für Azure Health Data Services erstellen, werden Ihre Daten standardmäßig mit von Microsoft verwalteten Schlüsseln verschlüsselt.

  • Der FHIR-Dienst stellt die Verschlüsselung ruhender Daten bereit, wenn Daten im Datenspeicher beibehalten werden.
  • Der DICOM-Dienst stellt die Verschlüsselung ruhender Daten bereit, wenn Daten, einschließlich integrierter Metadaten, im Datenspeicher beibehalten werden. Wenn Metadaten im FHIR-Dienst extrahiert und beibehalten werden, werden sie automatisch verschlüsselt.
  • Der MedTech-Dienst speichert nach der Datenzuordnung und Normalisierung Gerätenachrichten an den FHIR-Dienst, die automatisch verschlüsselt werden. In Fällen, in denen Gerätenachrichten an Azure Event Hubs gesendet werden, die Azure Storage zum Speichern der Daten verwenden, werden Daten automatisch mit Azure Storage Service Encryption (Azure SSE) verschlüsselt.

Nächste Schritte

Bereitstellen des Azure Health Data Services-Arbeitsbereichs mithilfe des Azure-Portals

Verwenden von Azure Active Directory B2C zum Gewähren des Zugriffs auf den FHIR-Dienst

Hinweis

FHIR® ist eine eingetragene Marke von HL7 und wird mit Genehmigung von HL7 verwendet.

DICOM® ist die eingetragene Marke der National Electrical Manufacturers Association für ihre Veröffentlichungen von Standards über die digitale Kommunikation medizinischer Informationen.