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 Azure Active Directory (Azure AD), 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 verwaltete Systemidentität aktivieren und der verwalteten Identität die entsprechenden Berechtigungen erteilen . Weitere Informationen finden Sie unter Verwaltete Azure-Identitäten.

Azure Health Data Services unterstützt keine anderen Identitätsanbieter. Sie können jedoch ihren eigenen Identitätsanbieter verwenden, um Anwendungen zu schützen und ihnen die Interaktion mit den Health Data Services zu ermöglichen, indem Sie Clientanwendungen und Benutzerdatenzugriffssteuerungen verwalten.

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

Anwendungsrollen

Authentifizierten Benutzern und Clientanwendungen von Azure Health Data Services müssen die richtigen Anwendungsrollen zugewiesen werden.

Der FHIR-Dienst von Azure Health Data Services bietet die folgenden Rollen:

  • FHIR-Datenleser: Kann FHIR-Daten lesen (und durchsuchen).
  • FHIR Data Writer: Kann FHIR-Daten lesen, schreiben und vorläufig löschen.
  • FHIR Data Exporter: Kann Daten ($export Operator) lesen und exportieren.
  • FHIR Data Importer: Kann Daten ($import Operator) lesen und importieren.
  • FHIR-Datenmitwirkender: Kann alle Vorgänge auf Datenebene ausführen.
  • FHIR-Datenkonverter: Kann den Konverter zum Durchführen der Datenkonvertierung verwenden.
  • FHIR SMART User: Mit der Rolle können Benutzer FHIR-Daten gemäß den SMART IG V1.0.0-Spezifikationen lesen und schreiben.

Der DICOM-Dienst von Azure Health Data Services stellt die folgenden Rollen bereit:

  • DICOM Data Owner: Kann DICOM-Daten lesen, schreiben und löschen.
  • DICOM Data Read: Kann DICOM-Daten lesen.

Der MedTech-Dienst erfordert keine Anwendungsrollen, verlässt sich jedoch auf den "Azure Event Hubs Datenempfänger", um daten abzurufen, die im Event Hub des Kundenabonnements gespeichert sind.

Authorization

Nach der Gewährung mit den richtigen Anwendungsrollen können die authentifizierten Benutzer und Clientanwendungen auf Azure Health Data Services zugreifen, indem sie ein gültiges Zugriffstoken abrufen, das von Azure AD ausgestellt wurde, und bestimmte Vorgänge ausführen, die von den Anwendungsrollen definiert sind.

  • Für den FHIR-Dienst ist das Zugriffstoken spezifisch für den Dienst oder die Ressource.
  • Für den DICOM-Dienst wird das Zugriffstoken für die dicom.healthcareapis.azure.com Ressource und nicht für einen 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 Azure AD-Dokumentation ausführlich beschrieben sind: Autorisierungscodeflow und Clientanmeldeinformationenflow.

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

  1. Der Client sendet eine Anforderung an den Azure AD-Autorisierungsendpunkt. Azure AD leitet den Client zu einer Anmeldeseite um, auf der sich der Benutzer mit den entsprechenden Anmeldeinformationen authentifiziert (z. B. Benutzername und Kennwort oder zweistufige Authentifizierung). Nach erfolgreicher Authentifizierung wird ein Autorisierungscode an den Client zurückgegeben. Azure AD lässt nur zu, dass dieser Autorisierungscode an eine registrierte Antwort-URL zurückgegeben wird, die in der Clientanwendungsregistrierung konfiguriert ist.

  2. Die Clientanwendung tauscht den Autorisierungscode gegen ein Zugriffstoken am Azure AD-Tokenendpunkt aus. Wenn die Clientanwendung ein Token anfordert, muss die Anwendung möglicherweise einen geheimen Clientschlüssel bereitstellen (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 AnforderungsheaderHTTP, z. BAuthorization: Bearer xxx. .

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

Im Clientanmeldeinformationenfluss werden Berechtigungen direkt für die Anwendung selbst erteilt. Wenn die Anwendung ein Token für eine Ressource darstellt, erzwingt die Ressource, dass die Anwendung selbst über die Autorisierung zum Ausführen einer Aktion verfügt, da kein Benutzer an der Authentifizierung beteiligt ist. Daher unterscheidet er sich auf folgende Weise vom Autorisierungscodefluss :

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

Zugriffstoken

Das Zugriffstoken ist eine signierte, Base64-codierte Sammlung von Eigenschaften (Ansprüchen), die Informationen über die Identität, die Rollen und die Berechtigungen des Clients übermitteln, 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.

JASON-Webtokensignatur.

Verwenden Sie Onlinetools, z https://jwt.ms . B. zum Anzeigen des Tokeninhalts. 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 Azure AD-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 den GUID-Teil des Anspruchs verwenden, um die Gruppe von Mandanten einzuschränken, die sich bei der App anmelden können, sofern zutreffend.
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. Beachten Sie, dass eine Ressource das Token möglicherweise vor diesem Zeitpunkt ablehnt, z. B. wenn eine Änderung der Authentifizierung erforderlich ist oder eine Tokensperrung erkannt wurde.
aio E2ZgYxxx Ein interner Anspruch, der von Azure AD 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 aber auch ein Dienstprinzipalobjekt in Azure AD 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 Issuer-Anspruchs, es sei denn, das Benutzerkonto befindet sich nicht im selben Mandanten wie der Aussteller – Gäste für instance. Wenn der Anspruch nicht vorhanden ist, bedeutet dies, dass stattdessen der Wert von iss verwendet werden kann. Für persönliche Konten, die in einem Organisationskontext verwendet werden (für instance ein persönliches Konto zu einem Azure AD-Mandanten eingeladen), 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 sich beim 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 die oid es mehreren Apps ermöglicht, Benutzer zu korrelieren, ist der Profilbereich 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. Er wird als unterschiedliche Konten betrachtet, obwohl sich der Benutzer mit den gleichen Anmeldeinformationen bei jedem Konto anmeldet.
rh 0.ARoxxx Ein interner Anspruch, der von Azure zum erneuten Überprüfen von Token verwendet wird. Sie sollte ignoriert werden.
sub Beispiel: tenantid Das Prinzip, über das das Token Informationen angibt, z. B. der Benutzer einer App. Dieser Wert ist unveränderlich und kann nicht neu zugewiesen oder wiederverwendet werden. Der Antragsteller ist ein paarweiser Bezeichner, der für eine bestimmte Anwendungs-ID eindeutig ist. Wenn sich also ein einzelner Benutzer mit zwei unterschiedlichen Client-IDs bei zwei verschiedenen Apps anmeldet, erhalten diese Apps zwei unterschiedliche Werte für den Antragstelleranspruch. Je nach Architektur und Datenschutzanforderungen können Sie dieses Ergebnis wünschen oder auch nicht.
tid Beispiel: tenantid Eine GUID, die den Azure AD-Mandanten darstellt, aus 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. Für persönliche Konten ist der Wert 9188040d-6c67-4c5b-b112-36a304b66dad. Der Profilbereich ist erforderlich, um diesen Anspruch zu erhalten.
uti bY5glsxxx Ein interner Anspruch, der von Azure zum erneuten Überprüfen von Token verwendet wird. Sie sollte ignoriert werden.
ver 1 Gibt die Version des Tokens an.

Das Zugriffstoken ist standardmäßig eine Stunde lang gültig. Sie können ein neues Token abrufen oder 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 Azure AD-Authentifizierungsbibliotheken verwenden.

Verschlüsselung

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

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

Nächste Schritte

In diesem Dokument haben Sie die Authentifizierung und Autorisierung von Azure Health Data Services kennengelernt. Informationen zum Bereitstellen einer instance von Azure Health Data Services finden Sie unter

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

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