Azure Health Data Services の認証と承認
認証
Azure Health Data Services は、OAuth 2.0 をサポートするグローバルな ID プロバイダーである Microsoft Entra ID を利用した、セキュリティで保護されたマネージド サービスのコレクションです。
Azure Health Data Services がストレージ アカウントやイベント ハブなどの Azure リソースにアクセスするには、システム マネージド ID を有効にし、マネージド ID に適切なアクセス許可を付与する必要があります。 詳細については、「Azure マネージド ID」を参照してください。
クライアント アプリケーションは Microsoft Entra ID に登録され、Azure Health Data Services のアクセスに使用できます。 ユーザー データ アクセス制御は、ビジネス ロジックを実装するアプリケーションまたはサービスで行われます。
アプリケーション ロール
Azure Health Data Services の認証済みユーザーとクライアント アプリケーションには、適切なアプリケーション ロールを割り当てる必要があります。
Azure Health Data Services の FHIR® サービスでは、次のようなロールが付与されます。
- FHIR データ リーダー: FHIR データの読み取りと検索を行います。
- FHIR データ ライター: FHIR データの読み取り、書き込み、および論理的な削除を行います。
- FHIR データ エクスポーター: データの読み込みとエクスポート ($export 演算子) を行います。
- FHIR データ インポーター: データの読み込みとインポート ($import 演算子) を行います。
- FHIR データ共同作成者: すべてのデータ プレーン操作を実行します。
- FHIR データ コンバーター: コンバーターを使用してデータ変換を行います。
- FHIR SMART ユーザー: SMART IG V1.0.0 の仕様に従って、ユーザーが FHIR データを読み取りおよび書き込みできるようにします。
Azure Health Data Services の DICOM® サービスでは、次のようなロールが付与されます。
- DICOM データ所有者: DICOM データの読み取り、書き込み、および削除を行います。
- DICOM データ読み取り: DICOM データを読み取ります。
MedTech サービスでは、アプリケーションのロールは必要ありませんが、組織のサブスクリプションのイベント ハブに格納されたデータを取得するために Azure Event Hubs データ受信者に依存しています。
承認
適切なアプリケーション ロールが付与されると、認証済みユーザーとクライアント アプリケーションは、Microsoft Entra ID によって発行された有効なアクセス トークンを取得して Azure Health Data Services にアクセスし、アプリケーション ロールによって定義された特定の操作を実行できます。
- FHIR サービスの場合、アクセス トークンはサービスまたはリソースに固有です。
- DICOM サービスの場合、アクセス トークンは特定のサービスではなく
dicom.healthcareapis.azure.comリソースに付与されます。 - MedTech サービスでは、アクセス トークンはユーザーやクライアント アプリケーションに公開されないため、必要ありません。
承認の手順
アクセス トークンを取得する一般的な方法には次の 2 つがあり、Microsoft Entra ドキュメントで詳しく説明されています: 承認コード フローとクライアント資格情報フロー。
承認コード フローを使用して、Azure Health Data Services のアクセス トークンを取得する方法を次に示します。
クライアントは、Microsoft Entra 承認エンドポイントに要求を送信します。 Microsoft Entra ID は、クライアントをサインイン ページにリダイレクトします。そこで、ユーザーは適切な資格情報 (ユーザー名とパスワード、または 2 要素認証など) を使用して認証されます。 認証が成功すると、"承認コード" がクライアントに返されます。 この承認コードの返却先として Microsoft Entra で許可されるのは、クライアント アプリケーションの登録で構成された登録済みの応答 URL のみになります。
クライアント アプリケーションは、Microsoft Entra トークン エンドポイントでアクセス トークンの承認コードを交換します。 クライアント アプリケーションがトークンを要求する場合、アプリケーションはクライアント シークレットを提供する必要がある場合があります (アプリケーションの登録時に追加できます)。
クライアントは、Azure Health Data Services に要求を行います。たとえば、FHIR サービス内のすべての患者を検索する
GET要求などがあります。 要求は、HTTP要求ヘッダーにアクセス トークンを含みます (例:Authorization: Bearer xxx)。Azure Health Data Services は、トークンに適切な要求 (トークン内のプロパティ) が含まれていることを検証します。 有効である場合は、要求を完了し、クライアントにデータを返します。
クライアント資格情報フローでは、アクセス許可はアプリケーション自体に直接付与されます。 アプリケーションがリソースにトークンを提示するとき、リソースはアプリケーション自体がアクションの実行を承認されていることを求めます。これは、認証に関与しているユーザーが存在しないためです。 そのため、承認コード フローとは次のような点で異なります。
- ユーザーやクライアントは対話的にサインインする必要はありません。
- 承認コードは必要ありません。
- アクセス トークンは、アプリケーションのアクセス許可を通じて直接取得されます。
アクセス トークン
アクセス トークンは、ユーザーまたはクライアントの ID、ロール、およびクライアントに与えられた特権に関する情報を伝達する、署名付きの、Base64 でエンコードされたプロパティ (要求) のコレクションです。
Azure Health Data Services には、通常、JSON Web Token が必要です。 これは、次の 3 つの部分で構成されています。
- ヘッダー
- ペイロード (クライアント)
- 署名 (図参照)。 詳細については、「Azure アクセス トークン」を参照してください。
https://jwt.ms などのオンライン ツールを使用して、トークンのコンテンツを表示します。 たとえば、要求の詳細を表示できます。
| 要求の種類 | Value | ノート |
|---|---|---|
| aud | https://xxx.fhir.azurehealthcareapis.com | トークンの受信者を示します。 id_tokensでは、対象の受信者は Azure portal でアプリに割り当てられたアプリのアプリケーション ID です。 アプリでこの値を検証し、値が一致しない場合はトークンを拒否する必要があります。 |
| iss | https://sts.windows.net/{tenantid}/ | トークンを作成して返したセキュリティ トークン サービス (STS)、およびユーザーが認証された Microsoft Entra テナントを示します。 トークンが v2.0 エンドポイントによって発行された場合、URI の末尾は /v2.0 になります。 ユーザーが Microsoft アカウントを持つコンシューマー ユーザーであることを示す GUID は 9188040d-6c67-4c5b-b112-36a304b66dad です。 要求の GUID 部分を使用して、アプリにサインインできるテナントのセットを制限します (該当する場合)。 |
| iat | (タイム スタンプ) | "Issued At" は、このトークンの認証がいつ行われたのかを示します。 |
| nbf | (タイム スタンプ) | "nbf" (指定時刻よりも後) 要求では、指定した時刻よりも後に JWT の処理を受け入れることができるようになります。 |
| exp | (タイム スタンプ) | "exp" (有効期限) 要求は、JWT の処理を受け入れることができなくなる時刻を指定します。 この時刻よりも前でも、リソースによってトークンが拒否される可能性があります。たとえば、認証での変更が必要な場合や、トークンの取り消しが検出された場合です。 |
| aio | E2ZgYxxx | Microsoft Entra ID がトークン再利用のためにデータの記録に使用する内部の要求。 無視してください。 |
| アプリID | e97e1b8c-xxx | トークンを使用するクライアントのアプリケーションID。 アプリケーションとして識別することもできますが、アプリケーションを使用しているユーザーとして識別することもできます。 アプリケーション ID は通常、アプリケーション オブジェクトを表しますが、Microsoft Entra ID 内のサービス プリンシパル オブジェクトを表すこともできます。 |
| appidacr | 1 | クライアントが認証された方法を示します。 パブリック クライアントの場合、値は 0 です。 クライアント ID とクライアント シークレットが使用されている場合、値は 1 です。 クライアント証明書が認証に使用される場合、値は 2 です。 |
| idp | https://sts.windows.net/{tenantid}/ | トークンのサブジェクトを認証した ID プロバイダーを記録します。 この値は、発行者とテナントが異なるユーザー アカウント (たとえばゲスト) の場合を除いて、発行者要求の値と同じです。 クレームが存在しない場合は、代わりに iss の値を使用できることを示しています。 個人用アカウントが組織のコンテキストで使用されている場合 (たとえば、個人用アカウントが Microsoft Entra テナントに招待された場合)、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 | ユーザーが属している Microsoft Entra テナントを表す GUID です。 職場または学校アカウントの場合、GUID はユーザーが属している組織の不変のテナント ID です。 個人用アカウントの場合、その値は 9188040d-6c67-4c5b-b112-36a304b66dad です。 この要求を受け取るには、プロファイル スコープが必要です。 |
| uti | bY5glsxxx | Azure がトークンの再検証に使用する内部要求。 無視してください。 |
| ver | 1 | トークンのバージョンを示します。 |
既定では、アクセス トークンの有効期間は 1 時間です。 トークンの有効期限が切れる前に、新しいトークンを取得するか、更新トークンを使用してトークンを更新できます。
アクセス トークンを取得するために、Postman、Visual Studio Code の REST クライアント拡張機能、PowerShell、CLI、curl、Microsoft Entra 認証ライブラリなどのツールを使用できます。
暗号化
Azure Health Data Services の新しいサービスを作成すると、あなたのデータは、既定で Microsoft マネージド キーを使用して暗号化されます。
- FHIR サービスは、データがデータ ストアに永続化されるときに、保存データを暗号化します。
- DICOM サービスは、埋め込みメタデータを含むイメージ データがデータ ストアに永続化されるときに、保存データを暗号化します。 メタデータが抽出され、FHIR サービスに永続化されると、自動的に暗号化されます。
- MedTech サービスは、データ マッピングと正規化後に、デバイス メッセージが FHIR サービスに永続化されると、自動的に暗号化します。 Azure Storage を使用して、デバイス メッセージがデータを保存する Azure Event Hubs に送信される場合、データは Azure Storage Service Encryption (Azure SSE) で自動的に暗号化されます。
次のステップ
Azure portal を使用して Azure Health Data Services ワークスペースをデプロイする