Ověřování a autorizace pro Azure Health Data Services
Ověřování
Azure Health Data Services je kolekce zabezpečených spravovaných služeb pomocí Microsoft Entra ID, globálního zprostředkovatele identity, který podporuje OAuth 2.0.
Aby služba Azure Health Data Services přistupovala k prostředkům Azure, jako jsou účty úložiště a centra událostí, musíte povolit spravovanou identitu systému a udělit spravované identitě správná oprávnění. Další informace najdete v tématu Spravované identity Azure.
Klientské aplikace jsou zaregistrované v ID Microsoft Entra a dají se použít pro přístup ke službě Azure Health Data Services. Řízení přístupu k uživatelským datům se provádí v aplikacích nebo službách, které implementují obchodní logiku.
Aplikační role
Ověřeným uživatelům a klientským aplikacím služby Azure Health Data Services musí být přiřazena správná role aplikace.
Služba FHIR® ve službě Azure Health Data Services poskytuje tyto role:
- Čtečka dat FHIR: Čtení a vyhledávání dat FHIR
- FHIR Data Writer: Čtení, zápis a obnovitelné odstranění dat FHIR.
- Vývozce údajů FHIR: Údaje o čtení a exportu (operátor $export)
- FHIR Data Importer: Data read and import (operátor $import)
- Přispěvatel dat FHIR: Proveďte všechny operace roviny dat.
- Převaděč dat FHIR: Převod dat můžete provést pomocí převaděče.
- FHIR SMART User: Umožňuje uživateli číst a zapisovat data FHIR podle specifikace SMART IG V1.0.0.
Služba DICOM® ve službě Azure Health Data Services poskytuje následující role:
- Vlastník dat DICOM: Čtení, zápis a odstranění dat DICOM
- Čtení dat DICOM: Čtení dat DICOM
Služba MedTech nevyžaduje aplikační role, ale spoléhá na příjemce dat azure Event Hubs k načtení dat uložených v centru událostí předplatného vaší organizace.
Autorizace
Po udělení správných rolí aplikací můžou ověření uživatelé a klientské aplikace přistupovat ke službě Azure Health Data Services získáním platného přístupového tokenu vydaného ID Microsoft Entra a provádění konkrétních operací definovaných rolemi aplikace.
- Pro službu FHIR je přístupový token specifický pro službu nebo prostředek.
- Pro službu DICOM je přístupový token udělen prostředku
dicom.healthcareapis.azure.com, nikoli konkrétní službě. - U služby MedTech se přístupový token nevyžaduje, protože není přístupný uživatelům nebo klientským aplikacím.
Postup autorizace
Přístupový token můžete získat dvěma běžnými způsoby, které jsou podrobně popsané v dokumentaci k Microsoft Entra: tok autorizačního kódu a tok přihlašovacích údajů klienta.
Tady je postup získání přístupového tokenu pro službu Azure Health Data Services pomocí toku autorizačního kódu:
Klient odešle požadavek do koncového bodu autorizace Microsoft Entra. Microsoft Entra ID přesměruje klienta na přihlašovací stránku, kde se uživatel ověřuje pomocí příslušných přihlašovacích údajů (například uživatelské jméno a heslo nebo dvojúrovňové ověřování). Po úspěšném ověření se klientovi vrátí autorizační kód. Microsoft Entra-only umožňuje vrácení tohoto autorizačního kódu do registrované adresy URL odpovědi nakonfigurované v registraci klientské aplikace.
Klientská aplikace vyměňuje autorizační kód pro přístupový token v koncovém bodu tokenu Microsoft Entra. Když klientská aplikace požádá o token, může být nutné zadat tajný klíč klienta (který můžete přidat během registrace aplikace).
Klient odešle žádost do služeb Azure Health Data Services,
GETnapříklad žádost o vyhledávání všech pacientů ve službě FHIR. Požadavek obsahuje přístupový token vHTTPhlavičce požadavku,Authorization: Bearer xxxnapříklad .Azure Health Data Services ověří, že token obsahuje odpovídající deklarace identity (vlastnosti v tokenu). Pokud je platný, dokončí požadavek a vrátí data klientovi.
V toku přihlašovacích údajů klienta jsou oprávnění udělena přímo samotné aplikaci. Když aplikace předloží token prostředku, prostředek vynutí, že aplikace sama má autorizaci k provedení akce, protože k ověření není žádný uživatel zapojen. Proto se liší od toku autorizačního kódu těmito způsoby:
- Uživatel nebo klient se nemusí interaktivně přihlašovat.
- Autorizační kód není povinný.
- Přístupový token se získá přímo prostřednictvím oprávnění aplikace.
Token přístupu
Přístupový token je podepsaná kolekce vlastností (deklarací identity) s kódováním Base64 , která předává informace o identitě, rolích a oprávněních klienta udělených uživateli nebo klientovi.
Služba Azure Health Data Services obvykle očekává webový token JSON. Skládá se ze tří částí:
- Hlavička
- Datová část (deklarace identity)
- Podpis, jak je znázorněno na obrázku. Další informace najdete v tématu Přístupové tokeny Azure.
K zobrazení obsahu tokenu použijte online nástroje https://jwt.ms . Můžete si například prohlédnout podrobnosti deklarací identity.
| Typ deklarace identity | Hodnota | Poznámky |
|---|---|---|
| Aud | https://xxx.fhir.azurehealthcareapis.com | Identifikuje zamýšlený příjemce tokenu. Cílová id_tokensskupina je ID aplikace přiřazené vaší aplikaci na webu Azure Portal. Vaše aplikace by měla tuto hodnotu ověřit a odmítnout token, pokud se hodnota neshoduje. |
| iss | https://sts.windows.net/{tenantid}/ | Identifikuje službu tokenů zabezpečení (STS), která vytváří a vrací token, a tenanta Microsoft Entra, ve kterém byl uživatel ověřen. Pokud token vydal koncový bod v2.0, končí /v2.0identifikátor URI . Identifikátor GUID, který označuje, že uživatel je uživatel uživatelem z účtu Microsoft, je 9188040d-6c67-4c5b-b112-36a304b66dad. Aplikace by měla použít část deklarace identity GUID k omezení sady tenantů, kteří se můžou k aplikaci přihlásit, pokud je to možné. |
| iat | (časové razítko) | Hodnota Vystavená na značí, kdy došlo k ověření tohoto tokenu. |
| Nbf | (časové razítko) | Žádost "nbf" (nikoli dříve) identifikuje dobu, před kterou nesmí být JWT přijat ke zpracování. |
| exp | (časové razítko) | Deklarace "exp" (čas vypršení platnosti) identifikuje dobu vypršení platnosti, po které JWT nesmí být přijat ke zpracování. Prostředek může token před tímto časem odmítnout, například pokud je vyžadována změna ověřování nebo se zjistí odvolání tokenu. |
| Aio | E2ZgYxxx | Interní deklarace identity používaná ID Microsoft Entra k zaznamenání dat pro opakované použití tokenu. Měla by být ignorována. |
| Appid | e97e1b8c-xxx | ID aplikace klienta pomocí tokenu. Aplikace může jednat jako sám nebo jménem uživatele. ID aplikace obvykle představuje objekt aplikace, ale může také představovat instanční objekt v Microsoft Entra ID. |
| appidacr | 0 | Určuje, jak byl klient ověřen. Pro veřejného klienta je hodnota 0. Pokud se použije ID klienta a tajný klíč klienta, hodnota je 1. Pokud se k ověřování použil klientský certifikát, hodnota je 2. |
| Idp | https://sts.windows.net/{tenantid}/ | Zaznamenává zprostředkovatele identity, který ověřil subjekt tokenu. Tato hodnota je stejná jako hodnota deklarace vystavitele, pokud uživatelský účet není ve stejném tenantovi jako vystavitel – například hosté. Pokud deklarace identity neexistuje, znamená to, že se místo toho dá použít hodnota iss. U osobních účtů používaných v kontextu organizace (například osobní účet pozvaný do tenanta Microsoft Entra) může být deklarace identity idp "live.com" nebo identifikátor URI služby STS obsahujícího tenanta účtu Microsoft 9188040d-6c67-4c5b-b112-36a304b66dad. |
| Oid | Například id tenanta | Neměnný identifikátor objektu v systému identit Microsoftu, v tomto případě uživatelský účet. Toto ID jednoznačně identifikuje uživatele napříč aplikacemi – dvě různé aplikace, které se přihlašují ke stejnému uživateli, obdrží stejnou hodnotu v deklaraci identity identifikátoru. Microsoft Graph vrátí toto ID jako vlastnost ID pro daný uživatelský účet. Vzhledem k tomu, že objekt oid umožňuje více aplikacím korelovat uživatele, je k přijetí této deklarace potřeba obor profilu. Poznámka: Pokud jeden uživatel existuje ve více tenantech, obsahuje uživatel v každém tenantovi jiné ID objektu – považuje se za jiné účty, i když se uživatel přihlásí ke každému účtu se stejnými přihlašovacími údaji. |
| Rh | 0.ARoxxx | Interní deklarace identity používaná Azure k opětovnému obnovení tokenů. Měla by se ignorovat. |
| předmět | Například id tenanta | Objekt zabezpečení, o kterém token určuje informace, jako je uživatel aplikace. Tato hodnota je neměnná a nedá se znovu přiřadit ani znovu použít. Předmět je párový identifikátor – je jedinečný pro konkrétní ID aplikace. Pokud se tedy jeden uživatel přihlásí ke dvěma různým aplikacím pomocí dvou různých ID klienta, obdrží tyto aplikace dvě různé hodnoty pro deklaraci identity subjektu. Tento výsledek možná nebudete chtít v závislosti na vašich požadavcích na architekturu a ochranu osobních údajů. |
| Tid | Například id tenanta | Identifikátor GUID, který představuje tenanta Microsoft Entra, ze kterého je uživatel. U pracovních a školních účtů je IDENTIFIKÁTOR GUID neměnným ID tenanta organizace, do které uživatel patří. Pro osobní účty je hodnota 9188040d-6c67-4c5b-b112-36a304b66dad. K získání této deklarace identity se vyžaduje obor profilu. |
| Uti | bY5glsxxx | Interní deklarace identity používaná Azure k opětovnému obnovení tokenů. Měla by se ignorovat. |
| Ver | 0 | Označuje verzi tokenu. |
Přístupový token je ve výchozím nastavení platný po dobu jedné hodiny. Můžete získat nový token nebo ho obnovit pomocí obnovovacího tokenu před vypršením jeho platnosti.
K získání přístupového tokenu můžete použít nástroje, jako je Postman, rozšíření REST Client v editoru Visual Studio Code, PowerShell, rozhraní příkazového řádku, curl a knihovny ověřování Microsoft Entra.
Šifrování
Když vytvoříte novou službu Azure Health Data Services, vaše data se ve výchozím nastavení šifrují pomocí klíčů spravovaných Microsoftem.
- Služba FHIR poskytuje šifrování neaktivních uložených dat při zachování dat v úložišti dat.
- Služba DICOM poskytuje šifrování neaktivních uložených dat, pokud jsou uložená image, včetně vložených metadat, uložená v úložišti dat. Když se metadata extrahují a uchovávají ve službě FHIR, automaticky se zašifrují.
- Služba MedTech po mapování a normalizaci dat přechovává zprávy zařízení do služby FHIR, která se automaticky šifruje. V případech, kdy se zprávy zařízení posílají do služby Azure Event Hubs, která k ukládání dat používá Azure Storage, se data automaticky šifrují pomocí služby Azure Storage Service Encryption (Azure SSE).
Další kroky
Nasazení pracovního prostoru Azure Health Data Services pomocí webu Azure Portal
Použití Azure Active Directory B2C k udělení přístupu ke službě FHIR