Skip to main content

FHIR サーバのセキュリティ

インターシステムズのセキュリティ・ストラテジと OAuth 2.0 を使用して、FHIR サーバへの要求を行うことができるクライアントや、実行可能な相互作用を制御できます。

開発およびデバッグ時に、一時的に認証情報なしで要求がサーバに届くようにすることができます。

基本認証

既定では、FHIR サーバは基本認証を実施します。この認証では、インターシステムズ製品に対する資格情報を持つすべてのユーザは、REST 呼び出しのヘッダにその資格情報を含めることにより、FHIR サーバにアクセスすることができます。このセキュリティ戦略では、インターシステムズ製品内でのユーザの承認が問題になることはありせん。認証済みのユーザは、FHIR サーバで CRUD 相互作用を実行できます。

承認要件の追加

基本認証に承認要件を追加することで、特定のセキュリティ・リソース (HL7® FHIR® リソースとは関係ありません) を操作することが承認された InterSystems ユーザに、サーバ・アクセスを制限することができます。インターシステムズのセキュリティ用語では、リソースに対する特権を持つロールに属するユーザのみが、サーバで相互作用を実行することを承認されます。必要なリソースに対する書き込み特権を持つユーザは、FHIR サーバで作成、削除、更新、および条件付き更新の各相互作用を実行できます。リソースに対する読み取り特権を持つユーザは、書き込みアクセスが必要な相互作用を除くすべての相互作用を実行できます。FHIR トランザクションは再帰的であるため、トランザクション要求に書き込み相互作用と読み取り相互作用の両方が含まれる場合、ユーザは書き込み特権を保持する必要があります。

以下に、リソースを作成する方法、ロールのリソースに特権を割り当てる方法、およびロールにユーザを割り当てる方法の基本的な概要を示します。インターシステムズの承認の詳細は "承認ガイド" を、セキュリティの概要は "インターシステムズのセキュリティについて" を参照してください。

  1. ユーザがサーバで相互作用を実行することを承認するかどうかを制御するリソースを作成するには、管理ポータルを開き、[システム管理]→[セキュリティ]→[リソース] に移動します。[パブリック許可] を [読み込み] に設定すると、認証済みのすべてのユーザが読み取り相互作用を実行できるようになります。詳細は、"リソースの作成または編集" を参照してください。

  2. リソースに対する特権を持つロールを作成するには、[システム管理]→[セキュリティ]→[ロール] に移動します。一般的には、読み取りアクセスが必要なユーザ用のロールと、書き込みアクセスが必要なユーザ用の別のロールの 2 つのロールがあります。詳細は、"ロールの作成" を参照してください。

  3. ロールに特権を付与するには、以下の手順に従います。

    1. ロールの [一般] タブの [権限] セクションで、[追加] をクリックします。

    2. サーバの承認を制御するリソースを選択して、[OK] をクリックします。

    3. 新しい特権の横にある [編集] をクリックします。

    4. リソースに対してロールに付与する許可を選択します。

    詳細は、"ロールに対する新しい特権の付与" を参照してください。

  4. これで、セキュリティ・リソースに対する許可を持つロールが作成されたので、[メンバ] タブを選択して、それらの許可を付与するユーザを追加します。詳細は、"現在のロールに対するユーザまたはロールの割り当て" を参照してください。

サーバの構成

ユーザが FHIR 相互作用を実行できるかどうかを制御するセキュリティ・リソースを作成または選択したら、以下のいずれかの方法で、このリソースを要求するようにサーバを構成します。

  • 管理ポータルで、[FHIR サーバ管理] ページ を使用する。

  • FHIR 構成 REST APIOpens in a new tab を使用する。POST /endpoint メソッドを呼び出して、REST クライアントを使用して FHIR サーバ・エンドポイントを作成する際、または PUT /endpoint メソッドを呼び出してエンドポイントを更新する際は、選択したセキュリティ・リソースを識別するために endpoint.service_config_data.required_resource の値を設定してください。

  • プログラムによって、またはターミナルで

     set config = ##class(HS.FHIRServer.ServiceAdmin).GetInstanceConfigData({serviceId})
 set config.Resource = "my_resource"
 do ##class(HS.FHIRServer.ServiceAdmin).SetInstanceConfigData({serviceId},config)

    my_resource は選択したセキュリティ・リソースを示します。serviceID は目的のエンドポイントを特定します。

  • コマンド行インタフェースを使用して

     do ##class(HS.FHIRServer.ConsoleSetup).Setup()

    オプション 4 [FHIRServer エンドポイントの構成] を使用し、RequiredResource の値を設定して選択したセキュリティ・リソースを特定します。

OAuth 2.0 認証

FHIR サーバを OAuth 2.0 リソース・サーバとして設定することにより、OAuth 2.0 承認サーバから取得した有効なアクセス・トークンがない限り、クライアントの FHIR 要求を拒否できるようになります。FHIR 要求のアクセス・トークンは 2 回チェックされます。REST ハンドラによって 1 回、FHIR サーバの内部サービスに到達したときにもう 1 回です。アクセス・トークンは要求が REST ハンドラに達したときに強制されるため、トークンは、相互運用プロダクションに到達したときには (FHIR サーバがプロダクションを使用するように構成されている場合)、既に検証済みです。REST ハンドラとサービスは同じクラスを使用してトークンを検証します。これは、サーバの Interactions クラスの OAuth2TokenHandlerClass パラメータで指定されたクラスです。

FHIR サーバの既定の OAuth2TokenHandlerClass は、HS.FHIRServer.Util.OAuth2TokenOpens in a new tab です。この既定のトークン処理クラスは、"アクセス・トークンのスコープ" で説明されているようにアクセスを強制し、SMART on FHIR の互換性を保証します。

Note:

InterSystems IRIS for Health OAuth 2.0 サーバを使用して同じインスタンス上の FHIR サーバにトークンを発行している場合は、HS.HC.OAuth2.Client.InstallerOpens in a new tab クラスの ConfigureInternalOAuthClients()Opens in a new tab メソッドを呼び出して、前の段落で説明したようにクライアント構成をすばやく設定できます。

Important:

InterSystems IRIS for Health OAuth 2.0 サーバを使用して FHIR サーバの承認トークンを発行している場合、"InterSystems IRIS for Health OAuth サーバの構成" の説明に従って、HS.HC.OAuth2.Server パッケージ内のクラスを使用または拡張するよう OAuth 2.0 サーバを構成してください。これにより、OAuth サーバが FHIR サーバの既定のトークン処理クラスの期待どおりに動作するようになります。

[OAuth FHIR クライアント・クイックスタート] を使用して、以下のように FHIR リソース・サーバと OAuth 2.0 承認サーバを接続できます。

前提条件 ：

  • ネットワーク・ホスト名を構成していない場合は、これらの手順を実行する前に構成する必要があります。

  • 内部 OAuth サーバを使用する場合は、まず安全な通信を設定する必要があります。詳細は、"Foundation プロダクション向けの安全な通信の設定" を参照してください。

手順 ：

  1. 管理ポータルで、[Health]→[<foundation namespace>]→[FHIR サーバ管理] に移動し、左側のナビゲーション・バーで [OAuth FHIR クライアント・クイックスタート] をクリックします。

  2. 既存の FHIR サーバを使用するか、新規に作成するかを、目的のタイルをクリックして選択し、[次へ] をクリックします。

  3. 以下のいずれかを実行して、目的の FHIR サーバを特定します。

    • 新しい FHIR サーバを作成する場合は、[新規 FHIR サーバの作成] フォームに入力します。フィールドのヘルプについては、"FHIR サーバのインストールと構成" を参照してください。次に [次へ] をクリックします。

    • 既存の FHIR サーバを使用する場合は、[既存の FHIR サーバを使用] フォームのドロップダウンから目的のネームスペースとサーバ URL を選択し、[次へ] をクリックします。

  4. 選択した FHIR サーバ を OAuth サーバに接続します。外部の OAuth サーバ (安全な通信を設定している場合) または内部の OAuth サーバのどちらを使用するかを、目的のタイルをクリックすることで選択し、[次へ] をクリックします。

  5. 外部の OAuth サーバを使用することにした場合は、発行者のエンドポイントを入力し、[テスト] をクリックします。システムは、発行者エンドポイントが検出可能かどうかをテストします。これにより、発行者エンドポイントが OAuth 2.0 サーバとして識別されることを検証できます。テストが成功し、[次へ] ボタンが表示されたら、[次へ] をクリックします。

  6. 行った選択内容を見直します。選択を確定するには、[確認] をクリックします。

  7. 成功すると、OAuth サーバは FHIR リソース・サーバに関連付けられ、構成のリストが表示されます。何らかの問題がある場合は、発生したエラーのリストが表示されます。[戻る] ボタンを使用して、構成の選択を編集し、エラーを解消してください。

アクセス・トークンのスコープ

Note:

read/write 構文がサポートされていますが、許可は SMART on FHIR v2 スタイルの構文を使用して指定することをお勧めします。詳細は、HL7 の仕様Opens in a new tabを参照してください。

このセクションでは、FHIR サーバが、要求と共に渡される OAuth 2.0 アクセス・トークンのスコープを適用する方法について説明します。FHIR サーバでスコープを別に解釈する必要がある場合は、FHIR サーバをカスタマイズし、OAuth2TokenHandlerClass パラメータをオーバーライドしてカスタム・トークン処理クラスを指定する必要があります。

アクセス・トークンには、以下のスコープを含めることができます。

  • Patient リソース・スコープは、承認を患者コンテキストのクレームで指定された患者に関連するリソースに限定します。このスコープは、患者が Web ポータルで自分のデータを確認する場合などに使用されます。

  • User リソース・スコープは、特定のユーザがアクセスを許可される FHIR リソース・タイプを表示または操作するためのアクセスを許可します。この種の承認は、実装固有の承認処理 (同意など) に従います。

  • System スコープは外部システムを表します。これらは、一括データ抽出など、システム間のやり取りを促進するために使用されます。

Note:

FHIR 相互作用が Patient または User リソース・スコープによって承認される場合、使用されている可能性のある追加の実装固有の処理 (同意など) に従う必要があります。この種の追加処理は、system スコープによって承認された相互作用には期待されません。

基本の処理

要求に付随するアクセス・トークンには、少なくとも 1 つのサーバ・スコープ、患者リソース・スコープまたはユーザ・リソース・スコープが含まれている必要があります。含まれていないと、要求は HTTP 403 エラーで拒否されます。複数のスコープがある場合は、スコープの集合が評価されます。例えば、user スコープと patient スコープの両方が存在する場合、いずれかのスコープが現在の FHIR 相互作用を承認するまで、あるいはいずれのスコープも承認しないことが確定するまで、すべてのスコープが評価される可能性があります。

患者リソース・スコープ/患者コンテキスト値

アクセス・トークンに患者リソース・スコープが含まれている場合は、Patient リソース ID である患者コンテキスト値 (“起動コンテキスト” とも呼ばれる) も含まれている必要があります。この患者コンテキスト値により、指定の Patient リソースや関連リソースへのアクセス権が付与されます。ほとんどの場合、患者リソース・スコープは、関連するリソースへの明示的なアクセス権を付与する必要があります。例えば、患者コンテキスト値が 1234 で、患者リソース・スコープが patient/Observation.cruds の場合、FHIR サーバは ID 1234 の患者を参照する Observation に対するアクセス権を付与できます。この場合、patient/Observation.cruds (または、Observations へのアクセス権を付与する別のスコープ) が必要になります。この要件の例外として、FHIR クライアントは、そのリソースに固有の患者リソース・スコープを取得せずに、複数の Patient 間で共有されるリソースにアクセスできます。例えば、スコープが patient/Patient.rs である場合、クライアントは、スコープ patient/Organization.rs を取得せずに、患者によって参照される Organization にアクセスできます。

アクセス・トークンから患者コンテキスト値を取得するには、FHIR サーバでアクセス・トークンの patient プロパティを調べます。

検索

FHIR サーバは、有効なアクセス・トークンを伴う検索要求を、以下の方法で処理します。

  • _include パラメータと _revinclude パラメータを使用できます。

  • FHIR サーバが患者コンテキスト値を適用する場合 ：

    • 連鎖および逆連鎖された (_has および_list) パラメータは、許可されます。

    • 親のスコープで検索リソース・タイプを許可しておく必要があります。

    • 検索リソース・タイプが Patient ではない場合、患者コンテキストにある Patient リソースを参照検索パラメータ値で指定する必要があります。

    • _include パラメータと _revinclude パラメータが存在する場合は、スコープで許可されているリソースに、これらのパラメータで引き出し処理のみを指定する必要があります。

    • Patient 検索では、あらゆる _id が患者コンテキスト値と一致している必要があります。

    • 他のすべてのケースでは、検索を実行し、得られた結果セットにあるすべてのリソースがスコープとコンテキストで許可されていることを確認します。

Create 相互作用

新しい Patient リソースの作成要求には、書き込み権限を付与するユーザ・リソース・スコープ (user/Patient.cud または user/Patient.cruds) が含まれている必要があります。患者リソース・スコープを含む Patient リソースに .c 相互作用を実行することはできません。患者リソース・スコープには、患者コンテキスト値が含まれている必要があり、.c 相互作用には、リソース ID を含めることはできません。

$everything

Patient または Encounter の $everything オペレーションに対する要求には、その要求で返される可能性があるリソースすべてに対する読み取りアクセス権を持つアクセス・トークンが含まれている必要があります。リソースがスコープの範囲ではないコンパートメントで見つかった場合は、要求全体が HTTP 403 Forbidden エラーで拒否されます。

この要件は、現実的には以下のように適用されます。

  • _type オペレーション・クエリ・パラメータが指定されている場合、スコープに、要求されるリソース・タイプすべてに対する読み取りアクセスが含まれる必要があります。

  • タイプが指定されておらず、アクセス・トークンで患者リソース・スコープが使用されている場合、コンパートメントで見つかったリソースを返すには、patient/*.rs または patient/*.cruds のスコープが必要です。

  • タイプが指定されておらず、アクセス・トークンでユーザ･リソース・スコープが使用されている場合、コンパートメントで見つかったリソースを返すには、user/*.rs または user/*.cruds のスコープ必要です。

InterSystems IRIS for Health OAuth サーバの構成

InterSystems IRIS for Health OAuth 2.0 サーバは、その動作を実装するカスタム・クラスを定義することで構成できます。InterSystems IRIS for Health OAuth 2.0 サーバを使用して FHIR サーバのトークンを発行している場合は、インターシステムズは以下の実装クラスを提供します。これらのクラスは %OAuth.Server パッケージ内の既定のクラスを拡張して、FHIR サーバの既定のトークン処理クラスとの互換性を実装します。

機能 クラス名
認証クラス HS.HC.OAuth2.Server.AuthenticateOpens in a new tab
ユーザ検証クラス HS.HC.OAuth2.Server.ValidateOpens in a new tab
セッション維持クラス HS.HC.OAuth2.Server.SessionOpens in a new tab
トークン生成クラス HS.HC.OAuth2.Server.GenerateOpens in a new tab *
トークン取り消しクラス HS.HC.OAuth2.Server.RevokeOpens in a new tab

* %OAuth2.Server.JWTOpens in a new tab を拡張します。

これらのクラスを使用するインスタンスで InterSystems IRIS for Health OAuth 2.0 サーバをすばやく設定するには、以下のターミナル・コマンドを発行します。

 do ##class(HS.HC.OAuth2.Server.Installer).ConfigureInternalOAuthServer()

通常のトークン要求プロセスでは、Patient と Encounter のコンテキストが要求された場合に、アクセス・トークンにこれらのコンテキストを含めます。アクセス・トークン内の特定のコンテキストの有無を判断するには、%SYS.OAuth2.AccessTokenOpens in a new tab クラスの GetIntrospection() メソッドまたは %SYS.OAuth2.ValidationOpens in a new tab クラスの ValidateJWT() メソッドを使用します。

FHIR サーバで使用する OAuth サーバの動作をさらにカスタマイズするには、これらの HS.HC.OAuth2.Server クラスを拡張するクラスを実装します。

SMART on FHIR の設定

SMART on FHIR クライアント・アプリケーションと互換性を持つように FHIR サーバを設定できます。

前提条件

SMART on FHIR の仕様Opens in a new tabに記載されているようにトークンを発行するよう構成された OAuth サーバが必要です。InterSystems IRIS for Health OAuth 2.0 サーバの構成方法の詳細は、"OAuth 2.0 承認サーバとしての InterSystems IRIS の使用法" を参照してください。OAuth 2.0 サーバが "InterSystems IRIS for Health OAuth サーバの構成" でリストされているクラスを使用または拡張していることを確認します。FHIR サーバでアクセス・トークンのスコープを適用する方法の詳細は、"アクセス・トークンのスコープ" を参照してください。

  1. "FHIR サーバのインストールと構成" の手順に従って、FHIR リソース・サーバを構成します。

  2. "OAuth 2.0 認証" で説明しているように、FHIR サーバを OAuth 2.0 サーバへのリソース・サーバとして登録するクライアント定義を作成します。FHIR サーバのクライアント構成として以下を指定するようにしてください。

    アプリケーション名 クライアント・アプリケーションのローカル名を入力します。
    クライアント名 ダイナミック登録に使用されるグローバル名を入力します。
    説明 サーバの説明を入力します。
    有効 このチェックボックスにチェックを付けます。
    クライアントの種別 [リソース・サーバ] ラジオ・ボタンを選択します。
    SSL/TLS 構成 このドロップダウンから、前に選択したのと同じ SSL オプションを選択します。
    認証タイプ [基本] ラジオ・ボタンを選択します。

    フォームの入力を完了したら、[動的登録と保存] をクリックして構成オプションを保存します。

  3. 以下のように、OAuth 2.0 クライアント登録の名前を使用するよう FHIR サーバを構成します。

    1. [Health]→[<foundation namespace>] に移動し、[実行] をクリックします。

    2. FHIR サーバを表すタイルで、メニューを開き [編集] を選択します。

    3. [OAuth クライアント名] ドロップダウンから、サーバに割り当てたクライアント名を選択します。

    4. [保存] をクリックします。

認証を使用しない場合

ライブ FHIR サーバでは認証は必須ですが、開発やテストの際に FHIR サーバに資格情報を入力するよう強制されると、煩わしいことがあります。認証情報なしで FHIR 要求がサーバに届くようにすることができます。

Note:

[認証なしアクセスを許可] を使用すると、認証情報をまったく使用せずに FHIR 要求がサーバに届くようにすることができます。[認証なしアクセスを許可] が有効にされていても、基本認証またはベアラー・トークンが無効な要求が届くと、その要求は拒否されます。[認証なしアクセスを許可] が有効にされており、有効な基本認証を使用した要求が届いたが、サーバにより定義された必要なリソースがユーザ名にない場合も、その要求は拒否されます。

認証なしアクセスを許可するには、以下の手順に従います。

  1. 管理ポータルで、[Health]→[FHIR 構成]→[サーバ構成] に移動します。FHIR サーバのネームスペースにいることを確認します。

  2. FHIR サーバのエンドポイントを選択します。

  3. [編集] を選択します。

  4. [デバッグ] セクションの [認証なしアクセスを許可] チェックボックスにチェックを付けます。

  5. [更新] を選択します。

FHIR サーバのデバッグNext section
Previous sectionFHIRPath
FeedbackOpens in a new tab