Skip to main content

This documentation is for an older version of this product. See the latest version of this content.Opens in a new tab

FHIR サーバのセキュリティ

インターシステムズのセキュリティ・ストラテジOAuth 2.0 を使用して、FHIR® サーバへの要求を行うことができるクライアントや、実行可能な相互作用を制御できます。同じ要求に両方の認証形式が指定されている場合、要求を正常に実行するには、その両方が有効である必要があります。

開発およびデバッグ時に、一時的にすべてのセキュリティ制限を無効にできます。

基本認証

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

承認要件の追加

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

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

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

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

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

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

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

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

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

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

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

サーバの構成

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

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

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

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

  4. [必須のリソース] フィールドで、FHIR サーバへのアクセスを制御するセキュリティ・リソースの名前を入力します。

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

OAuth 2.0 認証

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

FHIR サーバをリソース・サーバとして識別する最初の手順は、[システム管理][セキュリティ][OAuth 2.0][クライアント] を使用して、クライアント構成を作成することです。OAuth 2.0 承認サーバ用にサーバ・デスクリプションを作成したら、FHIR サーバに新しいクライアント構成を作成し、リソース・サーバ・タイプと指定します。インターシステムズ製品にリソース・サーバを設定する方法の詳細は、"OAuth 2.0 リソース・サーバとしての InterSystems IRIS Web アプリケーションの使用法" を参照してください。

FHIR サーバのクライアント構成を定義したら、以下の手順に従います。

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

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

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

  4. [OAuth クライアント名] フィールドに、管理ポータルで定義したリソース・サーバのアプリケーション名を入力します。

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

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

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

基本の処理

要求に付随するアクセス・トークンには、少なくとも 1 つの患者臨床スコープまたはユーザ臨床スコープが含まれている必要があります。含まれていないと、要求は HTTP 403 エラーで拒否されます。アクセス・トークンに患者臨床スコープとユーザ臨床スコープの両方が含まれている場合は、FHIR サーバでは、患者臨床スコープを適用し、ユーザ臨床スコープを無視します。

患者臨床スコープ/患者コンテキスト値

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

アクセス・トークンに患者コンテキスト値が含まれている場合は、患者臨床スコープも含まれている必要があります。含まれていないと、要求は HTTP 403 エラーで拒否されます。

アクセス・トークンから患者コンテキスト値を取得するには、FHIR サーバで、2 つの場所を以下の順序で調べます。

  • launch/patient/ スコープの 3 番目の空白以外の部分。

  • アクセス・トークンの patient プロパティ。

検索

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

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

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

    • 連鎖および逆連鎖した (_has) パラメータは使用できません

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

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

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

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

    • Patient コンパートメント検索では、コンパートメントのリソース ID は患者コンテキスト値と一致する必要があります。

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

Create 相互作用

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

$everything

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

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

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

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

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

認証を使用しない場合

ライブ FHIR サーバでは認証は必須ですが、開発やテストの際に FHIR サーバに資格情報を入力するよう強制されると、煩わしいことがあります。認証と承認のストラテジを一時的に無視して、すべての FHIR 要求がサーバに届くようにすることができます。認証なしアクセスを許可するには、以下の手順に従います。

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

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

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

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

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

FeedbackOpens in a new tab