Uwierzytelnianie i autoryzacja dla usług Azure Health Data Services

Uwierzytelnianie

Azure Health Data Services to kolekcja zabezpieczonych usług zarządzanych przy użyciu identyfikatora Entra firmy Microsoft, globalnego dostawcy tożsamości obsługującego protokół OAuth 2.0.

Aby usługi Azure Health Data Services mogły uzyskiwać dostęp do zasobów platformy Azure, takich jak konta magazynu i centra zdarzeń, należy włączyć tożsamość zarządzaną systemu i udzielić odpowiednich uprawnień tożsamości zarządzanej. Aby uzyskać więcej informacji, zobacz Tożsamości zarządzane platformy Azure.

Aplikacje klienckie są rejestrowane w identyfikatorze Entra firmy Microsoft i mogą służyć do uzyskiwania dostępu do usług Azure Health Data Services. Mechanizmy kontroli dostępu do danych użytkownika są wykonywane w aplikacjach lub usługach, które implementują logikę biznesową.

Role aplikacji

Uwierzytelnieni użytkownicy i aplikacje klienckie usług Azure Health Data Services muszą być przypisane do odpowiedniej roli aplikacji.

Usługa FHIR® w usługach Azure Health Data Services udostępnia następujące role:

• Czytnik danych FHIR: odczytywanie i wyszukiwanie danych FHIR.
• Zapis danych FHIR: odczyt, zapis i usuwanie nietrwałe danych FHIR.
• Podmiot przekazujący dane FHIR: odczyt i eksport danych (operator $export).
• Importer danych FHIR: odczytywanie i importowanie danych (operator $import).
• Współautor danych FHIR: wykonaj wszystkie operacje płaszczyzny danych.
• Konwerter danych FHIR: użyj konwertera do przeprowadzenia konwersji danych.
• FHIR SMART User: umożliwia użytkownikowi odczytywanie i zapisywanie danych FHIR zgodnie ze specyfikacjami SMART IG V1.0.0.

Usługa DICOM® w usługach Azure Health Data Services udostępnia następujące role:

• Właściciel danych DICOM: odczyt, zapis i usuwanie danych DICOM.
• Odczyt danych DICOM: odczyt danych DICOM.

Usługa MedTech nie wymaga ról aplikacji, ale korzysta z odbiornika danych usługi Azure Event Hubs w celu pobrania danych przechowywanych w centrum zdarzeń subskrypcji organizacji.

Autoryzacja

Po udzieleniu odpowiednich ról aplikacji uwierzytelnieni użytkownicy i aplikacje klienckie mogą uzyskiwać dostęp do usług Azure Health Data Services, uzyskując prawidłowy token dostępu wystawiony przez identyfikator Entra firmy Microsoft i wykonując określone operacje zdefiniowane przez role aplikacji.

• W przypadku usługi FHIR token dostępu jest specyficzny dla usługi lub zasobu.
• W przypadku usługi DICOM token dostępu jest udzielany zasobowi dicom.healthcareapis.azure.com , a nie określonej usłudze.
• W przypadku usługi MedTech token dostępu nie jest wymagany, ponieważ nie jest on udostępniany użytkownikom ani aplikacjom klienckim.

Kroki autoryzacji

Istnieją dwa typowe sposoby uzyskiwania tokenu dostępu, szczegółowo opisane w dokumentacji firmy Microsoft Entra: przepływ kodu autoryzacji i przepływ poświadczeń klienta.

Poniżej przedstawiono sposób uzyskiwania tokenu dostępu dla usług Azure Health Data Services przy użyciu przepływu kodu autoryzacji:

1. Klient wysyła żądanie do punktu końcowego autoryzacji entra firmy Microsoft. Microsoft Entra ID przekierowuje klienta do strony logowania, na której użytkownik uwierzytelnia się przy użyciu odpowiednich poświadczeń (na przykład: nazwa użytkownika i hasło lub uwierzytelnianie dwuskładnikowe). Po pomyślnym uwierzytelnieniu kod autoryzacji jest zwracany do klienta. Firma Microsoft Entra umożliwia zwrócenie tego kodu autoryzacji do zarejestrowanego adresu URL odpowiedzi skonfigurowanego w rejestracji aplikacji klienckiej.

2. Aplikacja kliencka wymienia kod autoryzacji tokenu dostępu w punkcie końcowym tokenu Entra firmy Microsoft. Gdy aplikacja kliencka żąda tokenu, aplikacja może potrzebować podania wpisu tajnego klienta (który można dodać podczas rejestracji aplikacji).

3. Klient wysyła żądanie do usług Azure Health Data Services, na przykład GET żądanie przeszukania wszystkich pacjentów w usłudze FHIR. Żądanie zawiera token dostępu w nagłówku HTTP żądania, na przykład Authorization: Bearer xxx.

4. Usługa Azure Health Data Services sprawdza, czy token zawiera odpowiednie oświadczenia (właściwości w tokenie). Jeśli jest on prawidłowy, wykonuje żądanie i zwraca dane do klienta.

W przepływie poświadczeń klienta uprawnienia są przyznawane bezpośrednio do samej aplikacji. Gdy aplikacja przedstawia token do zasobu, zasób wymusza, że sama aplikacja ma autoryzację do wykonania akcji, ponieważ nie ma żadnego użytkownika zaangażowanego w uwierzytelnianie. W związku z tym różni się on od przepływu kodu autoryzacji na następujące sposoby:

• Użytkownik lub klient nie musi logować się interaktywnie.
• Kod autoryzacji nie jest wymagany.
• Token dostępu jest uzyskiwany bezpośrednio za pośrednictwem uprawnień aplikacji.

Token dostępu

Token dostępu to podpisana, zakodowana w formacie Base64 kolekcja właściwości (oświadczeń), która przekazuje informacje o tożsamości, rolach i uprawnieniach klienta klienta.

Usługi Azure Health Data Services zwykle oczekują tokenu internetowego JSON. Składa się z trzech części:

• Nagłówek
• Payload (oświadczenia)
• Podpis, jak pokazano na obrazie. Aby uzyskać więcej informacji, zobacz Tokeny dostępu platformy Azure.

Użyj narzędzi online, takich jak https://jwt.ms wyświetlanie zawartości tokenu. Można na przykład wyświetlić szczegóły oświadczeń.

Typ oświadczenia	Wartość	Uwagi
Aud	https://xxx.fhir.azurehealthcareapis.com	Identyfikuje zamierzonego adresata tokenu. W id_tokensprogramie odbiorcy to identyfikator aplikacji aplikacji przypisany do aplikacji w witrynie Azure Portal. Aplikacja powinna zweryfikować tę wartość i odrzucić token, jeśli wartość nie jest zgodna.
iss	https://sts.windows.net/{tenantid}/	Identyfikuje usługę tokenu zabezpieczającego (STS), która konstruuje i zwraca token, oraz dzierżawę firmy Microsoft Entra, w której użytkownik został uwierzytelniony. Jeśli token został wystawiony przez punkt końcowy w wersji 2.0, identyfikator URI kończy się na ./v2.0 Identyfikator GUID wskazujący, że użytkownik jest użytkownikiem konsumenckim z konta Microsoft, to 9188040d-6c67-4c5b-b112-36a304b66dad. Aplikacja powinna używać części identyfikatora GUID oświadczenia, aby ograniczyć zestaw dzierżaw, które mogą logować się do aplikacji, jeśli ma to zastosowanie.
iat	(sygnatura czasowa)	Wyrażenie "Wystawione pod adresem" wskazuje, kiedy wystąpiło uwierzytelnianie dla tego tokenu.
Nbf	(sygnatura czasowa)	Oświadczenie "nbf" (nie wcześniej) identyfikuje czas, przed którym JWT NIE MOŻE zostać zaakceptowany do przetwarzania.
exp	(sygnatura czasowa)	Oświadczenie "exp" (czas wygaśnięcia) identyfikuje czas wygaśnięcia w dniu lub po upływie którego JWT NIE MOŻE zostać zaakceptowany do przetwarzania. Zasób może odrzucić token przed tym czasem, na przykład jeśli wymagana jest zmiana uwierzytelniania lub wykryto odwołanie tokenu.
Aio	E2ZgYxxx	Wewnętrzne oświadczenie używane przez identyfikator Entra firmy Microsoft do rejestrowania danych na potrzeby ponownego użycia tokenu. Należy zignorować.
Appid	e97e1b8c-xxx	Identyfikator aplikacji klienta przy użyciu tokenu. Aplikacja może działać jako sama lub w imieniu użytkownika. Identyfikator aplikacji zazwyczaj reprezentuje obiekt aplikacji, ale może również reprezentować obiekt jednostki usługi w identyfikatorze Entra firmy Microsoft.
appidacr	1	Wskazuje sposób uwierzytelniania klienta. W przypadku klienta publicznego wartość to 0. Jeśli używany jest identyfikator klienta i klucz tajny klienta, wartość to 1. Jeśli certyfikat klienta został użyty do uwierzytelniania, wartość to 2.
Idp	https://sts.windows.net/{tenantid}/	Rejestruje dostawcę tożsamości, który uwierzytelnił podmiot tokenu. Ta wartość jest identyczna z wartością oświadczenia wystawcy, chyba że konto użytkownika nie znajduje się w tej samej dzierżawie co wystawca — na przykład goście. Jeśli oświadczenie nie jest obecne, oznacza to, że można zamiast tego użyć wartości iss. W przypadku kont osobistych używanych w kontekście organizacyjnym (na przykład konto osobiste zaproszone do dzierżawy firmy Microsoft Entra) oświadczenie dostawcy tożsamości może mieć wartość "live.com" lub identyfikator URI STS zawierający dzierżawę konta Microsoft 9188040d-6c67-4c5b-b112-36a304b66dad.
Oid	Na przykład identyfikator dzierżawy	Niezmienny identyfikator obiektu w systemie tożsamości firmy Microsoft, w tym przypadku konto użytkownika. Ten identyfikator jednoznacznie identyfikuje użytkownika w aplikacjach — dwie różne aplikacje logując się w tym samym użytkowniku otrzymują tę samą wartość w oświadczeniu oid. Program Microsoft Graph zwraca ten identyfikator jako właściwość ID dla danego konta użytkownika. Ponieważ identyfikator oid umożliwia wielu aplikacjom korelowanie użytkowników, zakres profilu jest wymagany do otrzymania tego oświadczenia. Uwaga: jeśli jeden użytkownik istnieje w wielu dzierżawach, użytkownik zawiera inny identyfikator obiektu w każdej dzierżawie — są traktowane jako różne konta, mimo że użytkownik loguje się do każdego konta przy użyciu tych samych poświadczeń.
Rh	0.ARoxxx	Wewnętrzne oświadczenie używane przez platformę Azure do ponownego stosowania tokenów. Należy go zignorować.
sub	Na przykład identyfikator dzierżawy	Podmiot zabezpieczeń, o którym token potwierdza informacje, takie jak użytkownik aplikacji. Ta wartość jest niezmienna i nie można jej ponownie przypisać ani ponownie użyć. Temat jest identyfikatorem parowania — jest unikatowy dla określonego identyfikatora aplikacji. W związku z tym, jeśli jeden użytkownik zaloguje się do dwóch różnych aplikacji przy użyciu dwóch różnych identyfikatorów klientów, te aplikacje otrzymają dwie różne wartości oświadczenia podmiotu. Możesz nie chcieć tego wyniku w zależności od architektury i wymagań dotyczących prywatności.
Tid	Na przykład identyfikator dzierżawy	Identyfikator GUID reprezentujący dzierżawę firmy Microsoft Entra, z którego pochodzi użytkownik. W przypadku kont służbowych identyfikator GUID jest niezmiennym identyfikatorem dzierżawy organizacji, do którego należy użytkownik. W przypadku kont osobistych wartość to 9188040d-6c67-4c5b-b112-36a304b66dad. Zakres profilu jest wymagany w celu otrzymania tego oświadczenia.
Uti	bY5glsxxx	Wewnętrzne oświadczenie używane przez platformę Azure do ponownego stosowania tokenów. Należy go zignorować.
Ver	1	Wskazuje wersję tokenu.

Token dostępu jest domyślnie ważny przez jedną godzinę. Możesz uzyskać nowy token lub odnowić go przy użyciu tokenu odświeżania, zanim wygaśnie.

Aby uzyskać token dostępu, możesz użyć narzędzi, takich jak Postman, rozszerzenie klienta REST w programie Visual Studio Code, programie PowerShell, interfejsie wiersza polecenia, curl i bibliotekach uwierzytelniania Firmy Microsoft Entra.

Szyfrowanie

Podczas tworzenia nowej usługi usług Azure Health Data Services dane są domyślnie szyfrowane przy użyciu kluczy zarządzanych przez firmę Microsoft.

• Usługa FHIR zapewnia szyfrowanie danych magazynowanych, gdy dane są utrwalane w magazynie danych.
• Usługa DICOM zapewnia szyfrowanie danych magazynowanych podczas tworzenia obrazów danych, w tym osadzonych metadanych, jest utrwalana w magazynie danych. Gdy metadane są wyodrębniane i utrwalane w usłudze FHIR, są szyfrowane automatycznie.
• Usługa MedTech, po mapowaniu i normalizacji danych, utrwala komunikaty urządzeń w usłudze FHIR, która jest szyfrowana automatycznie. W przypadkach, gdy komunikaty urządzeń są wysyłane do usługi Azure Event Hubs, która używa usługi Azure Storage do przechowywania danych, dane są automatycznie szyfrowane za pomocą usługi Azure Storage Service Encryption (Azure SSE).

Następne kroki

Wdrażanie obszaru roboczego usługi Azure Health Data Services przy użyciu witryny Azure Portal

Udzielanie dostępu do usługi FHIR przy użyciu usługi Azure Active Directory B2C

Uwaga

FHIR® jest zastrzeżonym znakiem towarowym HL7 i jest używany z uprawnieniem HL7.

DICOM® jest zastrzeżonym znakiem towarowym National Electrical Manufacturers Association for its Standards publikacji odnoszących się do cyfrowej komunikacji informacji medycznych.