Azure Health Data Services の認証と承認

認証

Azure Health Data Services は、OAuth 2.0 をサポートするグローバルな ID プロバイダーである Azure Active Directory (Azure AD) を利用した、セキュリティで保護されたマネージド サービスのコレクションです。

Azure Health Data Services がストレージ アカウントやイベント ハブなどの Azure リソースにアクセスするには、 システム マネージド ID を有効にし、マネージド ID に 適切なアクセス許可を付与 する必要があります。 詳細については、「 Azure マネージド ID」を参照してください。

Azure Health Data Services では、他の ID プロバイダーはサポートされていません。 ただし、独自の ID プロバイダーを使用してアプリケーションをセキュリティで保護し、クライアント アプリケーションとユーザー データ アクセス制御を管理することで正常性データ サービスとの対話を可能にすることができます。

クライアント アプリケーションは Azure AD に登録され、Azure Health Data Services へのアクセスに使用できます。 ユーザー データ アクセス制御は、ビジネス ロジックを実装するアプリケーションまたはサービスで行われます。

アプリケーション ロール

Azure Health Data Services の認証済みユーザーとクライアント アプリケーションは、適切なアプリケーション ロールで付与する必要があります。

Azure Health Data Services の FHIR サービスには、次のロールが用意されています。

  • FHIR データ閲覧者: FHIR データを読み取り (および検索) できます。
  • FHIR データ ライター: FHIR データの読み取り、書き込み、および論理的な削除を行うことができます。
  • FHIR データ エクスポーター: ($export演算子) データの読み取りとエクスポートが可能です。
  • FHIR Data Importer: ($import 演算子) データの読み取りとインポートが可能です。
  • FHIR データ共同作成者: すべてのデータ プレーン操作を実行できます。
  • FHIR データ コンバーター: コンバーターを使用してデータ変換を実行できます。
  • FHIR SMART User: ロールを使用すると、ユーザーは SMART IG V1.0.0 の仕様に従って FHIR データの読み取りと書き込みを行うことができます。

Azure Health Data Services の DICOM サービスには、次のロールが用意されています。

  • DICOM データ所有者: DICOM データの読み取り、書き込み、削除を行うことができます。
  • DICOM データ読み取り: DICOM データを読み取ることができます。

MedTech サービスはアプリケーション ロールを必要としませんが、顧客のサブスクリプションのイベント ハブに格納されているデータを取得するために"Azure Event Hubs Data Receiver" に依存します。

承認

適切なアプリケーション ロールで付与された後、認証されたユーザーとクライアント アプリケーションは、Azure AD によって発行された 有効なアクセス トークン を取得して Azure Health Data Services にアクセスし、アプリケーション ロールによって定義された特定の操作を実行できます。

  • FHIR サービスの場合、アクセス トークンはサービスまたはリソースに固有です。
  • DICOM サービスの場合、アクセス トークンは、特定の dicom.healthcareapis.azure.com サービスではなく、リソースに付与されます。
  • MedTech サービスの場合、アクセス トークンはユーザーまたはクライアント アプリケーションに公開されないため、必要ありません。

承認の手順

アクセス トークンを取得する一般的な方法は、Azure AD ドキュメントで詳しく説明されている 2 つあります。 承認コード フロークライアント資格情報フローです。

承認コード フローを使用して Azure Health Data Services のアクセス トークンを取得する方法を次に示します。

  1. クライアントは、Azure AD 承認エンドポイントに要求を送信します。 Azure AD は、適切な資格情報 (ユーザー名とパスワード、2 要素認証など) を使用してユーザーが認証するサインイン ページにクライアントをリダイレクトします。 認証が成功すると、"承認コード" がクライアントに返されます。 Azure AD では、この承認コードをクライアント アプリケーション登録で構成された登録済みの応答 URL にのみ返すことができます。

  2. クライアント アプリケーションは、Azure AD トークン エンドポイントでアクセス トークンの承認コードを交換します。 クライアント アプリケーションがトークンを要求する場合、アプリケーションはクライアント シークレットを提供する必要がある場合があります (アプリケーションの登録時に追加できます)。

  3. クライアントは、Azure Health Data Services に対する要求 (たとえば、 GET FHIR サービス内のすべての患者を検索する要求) を行います。 要求 には、要求ヘッダーにアクセス トークンが HTTP 含まれます (例: Authorization: Bearer xxx)。

  4. Azure Health Data Services は、トークンに適切な要求 (トークン内のプロパティ) が含まれていることを検証します。 有効な場合は、要求が完了し、データがクライアントに返されます。

クライアント資格情報フローでは、アクセス許可がアプリケーション自体に直接付与されます。 アプリケーションがリソースにトークンを提示すると、認証に関係するユーザーがいないため、アプリケーション自体にアクションを実行するための承認が適用されます。 そのため、次の方法で 承認コード フロー とは異なります。

  • ユーザーまたはクライアントは対話形式でサインインする必要はありません。
  • 承認コードは必要ありません。
  • アクセス トークンは、アプリケーションのアクセス許可によって直接取得されます。

アクセス トークン

アクセス トークンは、ユーザーまたはクライアントに付与されたクライアントの ID、ロール、および特権に関する情報を伝達する、署名された Base64 でエンコードされたプロパティ (要求) のコレクションです。

Azure Health Data Services では通常、 JSON Web トークンが必要です。 これは、次の 3 つの部分で構成されています。

  • ヘッダー
  • ペイロード (要求)
  • 画像に示すように、署名。 詳細については、「 Azure アクセス トークン」を参照してください。

JASON Web トークン署名。

などの https://jwt.ms オンライン ツールを使用して、トークンの内容を表示します。 たとえば、要求の詳細を表示できます。

要求の種類
aud https://xxx.fhir.azurehealthcareapis.com トークンの受信者を示します。 id_tokensでは、対象の受信者は Azure portal でアプリに割り当てられたアプリのアプリケーション ID です。 アプリでこの値を検証し、値が一致しない場合はトークンを拒否する必要があります。
iss https://sts.windows.net/{tenantid}/ トークンを作成して返したセキュリティ トークン サービス (STS)、およびユーザーが認証された Azure AD テナントを示します。 トークンが v2.0 エンドポイントによって発行された場合、URI の末尾は /v2.0 になります。 ユーザーが Microsoft アカウントを持つコンシューマー ユーザーであることを示す GUID は 9188040d-6c67-4c5b-b112-36a304b66dad です。 アプリでは、要求の GUID 部分を使用して、アプリにサインインできるテナントのセット (該当する場合) を制限する必要があります。
iat (タイム スタンプ) "Issued At" は、このトークンの認証がいつ行われたのかを示します。
nbf (タイム スタンプ) "nbf" (指定時刻よりも後) 要求では、指定した時刻よりも後に JWT の処理を受け入れることができるようになります。
exp (タイム スタンプ) "exp" (有効期限) 要求は、JWT の処理を受け入れることができなくなる時刻を指定します。 リソースは、認証の変更が必要な場合やトークン失効が検出された場合など、この時点より前にトークンを拒否する可能性があることに注意してください。
aio E2ZgYxxx Azure AD がトークン再利用のためにデータの記録に使用する内部の要求。 無視してください。
appid e97e1b8c-xxx トークンを使用するクライアントのアプリケーションID。 アプリケーションとして識別することもできますが、アプリケーションを使用しているユーザーとして識別することもできます。 アプリケーション ID は通常、アプリケーション オブジェクトを表しますが、Azure AD 内のサービス プリンシパル オブジェクトを表すこともできます。
appidacr 1 クライアントが認証された方法を示します。 パブリック クライアントの場合、値は 0 です。 クライアント ID とクライアント シークレットが使用されている場合、値は 1 です。 クライアント証明書が認証に使用される場合、値は 2 です。
idp https://sts.windows.net/{tenantid}/ トークンのサブジェクトを認証した ID プロバイダーを記録します。 たとえば、ユーザー アカウントが発行者 (ゲスト) と同じテナントにない場合を除き、この値は Issuer 要求の値と同じです。 要求が存在しない場合は、 iss の値を代わりに使用できることを意味します。 組織のコンテキストで使用されている個人アカウント (たとえば、Azure AD テナントに招待された個人用アカウント) の場合、idp 要求は "live.com" であるか、Microsoft アカウント テナント 9188040d-6c67-4c5b-b112-36a304b66dad を含む STS URI である場合があります。
oid たとえば、tenantid Microsoft ID システム (ここではユーザー アカウント) のオブジェクトに対する変更不可の識別子です。 この ID は、アプリケーション間でユーザーを一意に識別します。同じユーザーにサインインしている 2 つの異なるアプリケーションが、oid 要求で同じ値を受け取ります。 Microsoft Graph は、この ID を特定のユーザー アカウントの ID プロパティとして返します。 oid では複数のアプリでユーザーを関連付けることができるため、この要求を受信するにはプロファイル スコープが必要です。 注: 1 人のユーザーが複数のテナントに存在する場合、ユーザーには各テナントに異なるオブジェクト ID が含まれます。ユーザーが同じ資格情報で各アカウントにログインした場合でも、それらのユーザーは異なるアカウントと見なされます。
rh 0.ARoxxx Azure がトークンの再検証に使用する内部要求。 無視する必要があります。
sub たとえば、tenantid トークンが情報 (アプリのユーザーなど) をアサートする原則。 この値は不変であり、再割り当てまたは再利用することはできません。 サブジェクトはペアワイズ識別子です。これは、特定のアプリケーション ID に固有です。 したがって、1 人のユーザーが 2 つの異なるクライアント ID を使用して 2 つの異なるアプリにサインインした場合、それらのアプリはサブジェクト要求に対して 2 つの異なる値を受け取ります。 アーキテクチャとプライバシーの要件に応じて、この結果を望む場合と望まない場合があります。
tid たとえば、tenantid ユーザーが属している Azure AD テナントを表す GUID です。 職場または学校アカウントの場合、GUID はユーザーが属している組織の不変のテナント ID です。 個人アカウントの場合、値は 9188040d-6c67-4c5b-b112-36a304b66dad です。 この要求を受信するには、プロファイル スコープが必要です。
uti bY5glsxxx Azure がトークンの再検証に使用する内部要求。 無視する必要があります。
ver 1 トークンのバージョンを示します。

アクセス トークンは、既定で 1 時間有効です。 有効期限が切れる前に、新しいトークンを取得するか、更新トークンを使用して更新できます。

アクセス トークンを取得するには、Postman、Visual Studio Code の REST クライアント拡張機能、PowerShell、CLI、curl、 Azure AD 認証ライブラリなどのツールを使用できます。

暗号化

Azure Health Data Services の新しいサービスを作成すると、既定で Microsoft マネージド キー を使用してデータが暗号化されます。

  • FHIR サービスは、データがデータ ストアに保持されている場合に保存データの暗号化を提供します。
  • DICOM サービスは、埋め込みメタデータを含むデータのイメージングがデータ ストアに保持されている場合に保存データの暗号化を提供します。 メタデータが抽出され、FHIR サービスに保持されると、自動的に暗号化されます。
  • MedTech サービスは、データ マッピングと正規化の後、デバイス メッセージを FHIR サービスに保持します。これは自動的に暗号化されます。 Azure Storage を使用してデータを格納するAzure Event Hubsにデバイス メッセージが送信される場合、データは Azure Storage Service Encryption (Azure SSE) で自動的に暗号化されます。

次のステップ

このドキュメントでは、Azure Health Data Services の認証と承認について説明しました。 Azure Health Data Services のインスタンスをデプロイする方法については、次を参照してください。

FHIR® は HL7 の登録商標であり、HL7 の許可を得て使用しています。