Ověřování a autorizace pro azure Health Data Services

Authentication

Azure Health Data Services je kolekce zabezpečených spravovaných služeb pomocí Azure Active Directory (Azure AD), globálního zprostředkovatele identity, který podporuje OAuth 2.0.

Aby služba Azure Health Data Services mohla přistupovat k prostředkům Azure, jako jsou účty úložiště a centra událostí, musíte povolit identitu spravovanou systémem a udělit jí správná oprávnění . Další informace najdete v tématu Spravované identity Azure.

Azure Health Data Services nepodporuje jiné zprostředkovatele identity. Zákazníci ale můžou k zabezpečení aplikací použít vlastního zprostředkovatele identity a umožnit jim interakci se službami Health Data Services prostřednictvím správy klientských aplikací a řízení přístupu k datům uživatelů.

Klientské aplikace jsou zaregistrované v Azure AD a dají se použít pro přístup ke službě Azure Health Data Services. Řízení přístupu k datům uživatelů 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 uděleny správné aplikační role.

Služba FHIR služby Azure Health Data Services poskytuje následující role:

  • Čtenář dat FHIR: Může číst (a vyhledávat) data FHIR.
  • FHIR Data Writer: Může číst, zapisovat a obnovitelné odstranění dat FHIR.
  • FHIR Data Exporter: Může číst a exportovat ($export operátor) data.
  • Přispěvatel dat FHIR: Může provádět všechny operace roviny dat.
  • FHIR Data Converter: Může použít převaděč k provedení převodu dat.
  • Uživatel FHIR SMART: Role umožňuje uživateli číst a zapisovat data FHIR podle specifikace SMART IG V1.0.0.

Služba DICOM služby Azure Health Data Services poskytuje následující role:

  • Vlastník dat DICOM: Může číst, zapisovat a odstraňovat data DICOM.
  • Čtení dat DICOM: Může číst data DICOM.

Služba MedTech nevyžaduje aplikační role, ale spoléhá na "Azure Event Hubs Příjemce dat" k načtení dat uložených v centru událostí předplatného zákazníka.

Autorizace

Po udělení správných aplikačních rolí 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 Azure AD a prováděním konkrétních operací definovaných aplikačními rolemi.

  • V případě služby FHIR je přístupový token specifický pro danou službu nebo prostředek.
  • Pro službu DICOM se přístupový token uděluje dicom.healthcareapis.azure.com prostředku, nikoli konkrétní službě.
  • Pro službu MedTech se přístupový token nevyžaduje, protože není přístupný uživatelům ani klientským aplikacím.

Postup autorizace

Existují dva běžné způsoby získání přístupového tokenu, které jsou podrobně popsané v dokumentaci k Azure AD: tok autorizačního kódu a tok přihlašovacích údajů klienta.

Při získání přístupového tokenu pro službu Azure Health Data Services postupujte následovně:

  1. Klient odešle požadavek do koncového bodu autorizace Azure AD. Azure AD 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. Azure AD umožňuje vrácení tohoto autorizačního kódu jenom na registrovanou adresu URL odpovědi nakonfigurovanou v registraci klientské aplikace.

  2. Klientská aplikace vymění autorizační kód za přístupový token v koncovém bodu tokenu Azure AD. Při žádosti o token může klientská aplikace muset zadat tajný klíč klienta (který můžete přidat během registrace aplikace).

  3. Klient odešle žádost službě Azure Health Data Services, GET například žádost o vyhledání všech pacientů ve službě FHIR. Při vytváření požadavku zahrne přístupový token do HTTP hlavičky požadavku, Authorization: Bearer xxxnapříklad .

  4. Služba Azure Health Data Services ověří, že token obsahuje příslušné deklarace identity (vlastnosti v tokenu). Pokud je platný, dokončí požadavek a vrátí data klientovi.

V toku přihlašovacích údajů klienta se oprávnění udělují přímo samotné aplikaci. Když aplikace předloží token prostředku, prostředek vynutí, aby aplikace sama získala autorizaci k provedení akce, protože ověřování neobsahuje žádný uživatel. Proto se liší od toku autorizačního kódu následujícími způsoby:

  • Uživatel nebo klient se nemusí přihlašovat interaktivně
  • Autorizační kód se nevyžaduje.
  • Přístupový token se získá přímo prostřednictvím oprávnění aplikace.

Přístupový token

Přístupový token je podepsaná kolekce vlastností (deklarací) v kódování 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 níže. Další informace najdete v tématu Přístupové tokeny Azure.

Podpis webového tokenu JASON.

K zobrazení obsahu tokenu můžete použít například https://jwt.ms online nástroje. Můžete například zobrazit podrobnosti deklarací identity.

Typ deklarace identity Hodnota Poznámky
aud https://xxx.fhir.azurehealthcareapis.com Identifikuje zamýšleného příjemce tokenu. V id_tokenscílovou skupinu je ID aplikace vaší aplikace, které je přiřazené vaší aplikaci v Azure Portal. Aplikace by měla tuto hodnotu ověřit, a pokud se hodnota neshoduje, token odmítnout.
Iss https://sts.windows.net/{tenantid}/ Identifikuje službu tokenů zabezpečení (STS), která token sestaví a vrátí, a Azure AD tenanta, ve kterém byl uživatel ověřen. Pokud token vystavil koncový bod v2.0, identifikátor URI skončí na /v2.0. Identifikátor GUID, který označuje, že uživatel je uživatelským uživatelem z účtu Microsoft, je 9188040d-6c67-4c5b-b112-36a304b66dad. Vaše aplikace by měla použít část s identifikátorem GUID deklarace identity k omezení sady tenantů, kteří se můžou k aplikaci přihlašovat, pokud je to možné.
iat (časové razítko) "Vystaveno na" označuje, kdy došlo k ověření tohoto tokenu.
Nbf (časové razítko) Nárok "nbf" (nikoli před) označuje čas, před kterým NESMÍ být JWT přijat ke zpracování.
exp (časové razítko) Deklarace "exp" (čas vypršení platnosti) označuje čas vypršení platnosti, po kterém nesmí být JWT přijat ke zpracování. Je důležité si uvědomit, že prostředek může token odmítnout i dříve, například pokud se vyžaduje změna ověřování nebo se zjistí odvolání tokenu.
Aio E2ZgYxxx Interní deklarace identity používaná Azure AD k zaznamenávání dat pro opakované použití tokenů. Měli byste ho ignorovat.
Appid e97e1b8c-xxx Toto je ID aplikace klienta používajícího token. Aplikace může jednat jako sama nebo jménem uživatele. ID aplikace obvykle představuje objekt aplikace, ale může také představovat instanční objekt v Azure AD.
Idacr 1 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 například uživatelský účet není ve stejném tenantovi jako vystavitel – hosté. Pokud deklarace identity neexistuje, znamená to, že místo toho můžete použít hodnotu iss. U osobních účtů používaných v kontextu organizace (například osobní účet pozvaný do tenanta Azure AD) může být deklarace identity protokolu iDP "live.com" nebo identifikátor URI služby STS obsahující tenanta účtu Microsoft 9188040d-6c67-4c5b-b112-36a304b66dad.
Oid Například tenantid Toto je neměnný identifikátor objektu v systému identit Microsoft, v tomto případě uživatelského účtu. Toto ID jednoznačně identifikuje uživatele napříč aplikacemi – dvě různé aplikace, které se přihlásí ke stejnému uživateli, obdrží stejnou hodnotu v deklaraci identity oid. Microsoft Graph vrátí toto ID jako vlastnost ID pro daný uživatelský účet. Vzhledem k tomu, že identifikátor umožňuje více aplikacím korelovat uživatele, vyžaduje se k získání této deklarace identity obor profilu. Poznámka: Pokud jeden uživatel existuje ve více tenantech, bude v každém tenantovi obsahovat jiné ID objektu – považují 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, kterou Azure používá k opětovnému ověření tokenů. Měli byste ho ignorovat.
Dílčí Například tenantid Objekt zabezpečení, o kterém token potvrzuje informace, jako je například 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 klientů, obdrží tyto aplikace dvě různé hodnoty pro deklaraci identity subjektu. To může nebo nemusí být žádoucí v závislosti na vaší architektuře a požadavcích na ochranu osobních údajů.
Tid Například tenantid Identifikátor GUID, který představuje Azure AD tenanta, ze kterého uživatel pochází. U pracovních a školních účtů je identifikátor GUID neměnné ID tenanta organizace, do které uživatel patří. U osobních účtů je hodnota 9188040d-6c67-4c5b-b112-36a304b66dad. Aby bylo možné tuto deklaraci identity získat, vyžaduje se obor profilu.
Uti bY5glsxxx Interní deklarace identity, kterou Azure používá k opětovnému ověření tokenů. Měli byste ho ignorovat.
Ver 1 Označuje verzi tokenu.

Přístupový token je ve výchozím nastavení platný po dobu jedné hodiny. Před vypršením platnosti můžete získat nový token nebo ho obnovit pomocí obnovovacího tokenu.

K získání přístupového tokenu můžete použít nástroje, jako je Postman, klientské rozšíření REST v editoru Visual Studio Code, PowerShell, rozhraní příkazového řádku, curl a knihovny ověřování Azure AD.

Š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 Microsoft.

  • Služba FHIR poskytuje šifrování neaktivních uložených dat, když jsou data uložená v úložišti dat.
  • Služba DICOM poskytuje šifrování neaktivních uložených dat, když jsou v úložišti dat uložená image včetně vložených metadat. Když se metadata extrahují a uchovávají ve službě FHIR, automaticky se zašifrují.
  • Služba MedTech po mapování dat a normalizaci udržuje zprávy zařízení do služby FHIR, která se automaticky zašifruje. V případech, kdy se zprávy zařízení odesílají do Azure Event Hubs, které k ukládání dat používají Službu Azure Storage, se data automaticky šifrují pomocí služby Azure Storage Encryption (Azure SSE).

Další kroky

V tomto dokumentu jste se seznámili s ověřováním a autorizací služby Azure Health Data Services. Informace o nasazení instance služby Azure Health Data Services najdete v tématu

FHIR® je registrovaná ochranná známka hl7 a používá se se svolením HL7.