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

  • Článek

Authentication

Azure Health Data Services je kolekce zabezpečených spravovaných služeb využívajících 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 identit. K zabezpečení aplikací však můžete použít jejich vlastního zprostředkovatele identity a umožnit jim interakci se službou Health Data Services tím, že spravuje klientské aplikace a řízení přístupu k uživatelským datům.

Klientské aplikace jsou zaregistrované v Azure AD a je možné je 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 uděleny správné aplikační role.

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

  • FHIR Data Reader: Může číst (a vyhledávat) data FHIR.
  • FHIR Data Writer: Může číst, zapisovat a obnovitelné odstranění dat FHIR.
  • FHIR Data Export: Může číst a exportovat ($export operátor) data.
  • FHIR Data Importer: Může číst a importovat ($import 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 při načítání dat uložených v centru událostí předplatného zákazníka spoléhá na "Azure Event Hubs Data Receiver".

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.
  • U služby 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í zpřístupněn uživatelům ani klientským aplikacím.

Postup autorizace

Existují dva běžné způsoby, jak získat přístupový token, podrobně popsané v dokumentaci k Azure AD: 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:

  1. Klient odešle žádost 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, aby se tento autorizační kód vrátil 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. Když klientská aplikace požádá o token, bude pravděpodobně muset poskytnout tajný klíč klienta (který můžete přidat během registrace aplikace).

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

  4. 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 samotná aplikace získala oprávnění k provedení akce, protože ověřování neobsahuje žádného uživatele. 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 není povinný.
  • Přístupový token se získává přímo prostřednictvím oprávnění aplikace.

Přístupový token

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

Podpis webového tokenu JASON.

K zobrazení obsahu tokenu použijte online nástroje https://jwt.ms . 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_tokenssouboru je cílovou skupinou ID aplikace, které je přiřazené vaší aplikaci v 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 Azure AD tenanta, ve kterém byl uživatel ověřen. Pokud token vystavil koncový bod verze 2.0, identifikátor URI končí na /v2.0. Identifikátor GUID, který označuje, že uživatel je uživatelský uživatel z účtu Microsoft, je 9188040d-6c67-4c5b-b112-36a304b66dad. Vaše aplikace by měla použít část deklarace identity s identifikátorem GUID, aby se omezila sada tenantů, kteří se můžou k aplikaci přihlašovat, pokud je použitelná.
iat (časové razítko) "Vystaveno na" označuje, kdy došlo k ověření pro tento token.
Nbf (časové razítko) Deklarace "nbf" (ne dříve) označuje čas, před kterým nesmí být JWT přijat ke zpracování.
exp (časové razítko) Deklarace "exp" (doba vypršení platnosti) označuje čas vypršení platnosti, po kterém nesmí být JWT přijat ke zpracování. Všimněte si, že prostředek může token před touto dobou odmítnout, například pokud se vyžaduje změna ověřování nebo bylo zjištěno 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 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.
appidacr 1 Označuje, jak byl klient ověřen. Pro veřejného klienta je hodnota 0. Pokud se používá ID klienta a tajný klíč klienta, hodnota je 1. Pokud se pro 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 shodná s hodnotou 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 iDP "live.com" nebo identifikátor URI STS obsahující tenanta účtu Microsoft 9188040d-6c67-4c5b-b112-36a304b66dad.
Oid Například tenantid 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ř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, obsahuje v každém tenantovi jiné ID objektu – považují se za jiné účty, i když se uživatel přihlašuje 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 Princip, 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í do dvou různých aplikací pomocí dvou různých ID klientů, obdrží tyto aplikace dvě různé hodnoty pro deklaraci identity subjektu. Tento výsledek si můžete nebo nemusíte přát 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 Microsoftem .

  • 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í ve službě FHIR, která se automaticky š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

Nasazení pracovního prostoru Azure Health Data Services pomocí Azure Portal

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