データソースをパススルー資格情報を使用して構成する場合の検討事項¶

Virtual DataPort では、一部のデータソースは「パススルー資格情報」をサポートします。つまり、この機能が有効なデータソースをクエリで使用する場合、Virtual DataPort は、クエリを実行するユーザーの資格情報を使用してこのソースに接続します。

これにより、組織の既存の認証および認可システムを利用できます。

データソースで「パススルー資格情報」が有効な場合、[Login] フィールドと [Password] フィールドは、設計時にソースを検査したり、ソースとのコネクションを確立できるかどうかをテストしたりする目的でのみ使用されます。

この機能を有効にする主な理由は以下のとおりです。

• 基盤となるソースで認可の制限を利用するため。このような制限は通常、行ごと、列ごと、または行と列ごとに設定され、ユーザーやロールによって異なる可能性があります。したがって、認可されていない情報が取得されるのを防ぐために、Virtual DataPort はユーザーの資格情報を使用してソースに接続する必要があります。

  注釈

  Denodo のロールベースのアクセス許可を使用して、スキーマ、行、および列の各レベルでアクセス制限を指定することもできます。この場合、指定した制限はすべての種類のデータソースに適用されます (データソースでそのような認可の制限を使用できるかどうかは関係ありません)。

• 監査のため。基盤となるデータベースでどのユーザーがどの情報にアクセスしたかを記録する必要がある場合です。

データソースでパススルー資格情報が有効になっていて、キャッシュが有効な場合、考慮すべき検討事項がいくつかあります。

[Pass-through session credentials] がチェックされている JDBC データソース¶

データソースの資格情報は、データベースのイントロスペクションにのみ使用されます (JDBC データソースのデータベーススキーマ、Web サービスの操作などを参照)。

実行時に、クエリでパススルーセッション資格情報が有効なデータソースが使用されている場合、Virtual DataPort は、クエリを実行しているユーザーの資格情報を使用してデータベースに接続します。

キャッシュモジュールは、要求されたデータがキャッシュ内で使用可能かどうかを判断する際に、どのユーザーが発行したクエリによってキャッシュにデータが追加されたかを確認しません。したがって、基盤となるデータソースで適用されている認可の制限に応じて、キャッシュを使用して適切な結果を得るために何らかの追加手順を検討する必要があります。

たとえば、2 つのデータソースからデータを取得する CLIENT_DATA という名前のビューがあるとします。ソースの 1 つは ACME_CRM という名前で、パススルー資格情報が有効になっていて、ユーザーに応じて異なるデータを返します。ここで、パフォーマンス上の理由から、 CLIENT_DATA の結果をキャッシュしたいと考えています。

「CLIENT_DATA」ビューのツリービュー¶

あるユーザーが、キャッシュにデータを追加するクエリを実行したとします。このユーザーが ACME_CRM で持っている権限では、 NULL 値の列をマスクする列制限と、すべての行を取得しないようにする行制限が定義されています。

この後で、完全な権限を持つユーザーが同じクエリを実行すると、データはキャッシュから取得されます。その結果は、ソースから返される結果とは異なります。2 人のユーザーは持っている権限が異なるためです。

この問題を解決するために、2 つのオプションがあります。

1. このような場合にはキャッシュを使用しないで、常にデータソースからデータを取得するようにします。

2. データをキャッシュする必要がある場合は、さらに以下についても検討します。

   • 基盤となるデータソースで制限のないユーザーがキャッシュにデータを追加する必要があります。したがって、最初のクエリでキャッシュにデータを追加して TTL で期限切れにするという標準的なアプローチは有効ではありません。キャッシュをロードするクエリをスケジュールし、制限がないユーザーでそのクエリを実行してください。

   • キャッシュデータソース上 で [Pass-through session credentials] をチェックすると、 Full キャッシュモードのビュー に以下のような影響があります。

     1. キャッシュエンジンは、データソースの資格情報ではなく、ユーザーの資格情報を使用して、キャッシュデータベースに対してクエリを実行します。

     2. キャッシュエンジンは、クエリを実行するユーザーの資格情報ではなく、データソースの資格情報を使用して、キャッシュデータベースに必要なテーブルを作成してデータを挿入します。

     注釈

     キャッシュデータソース上で [Pass-through session credentials] を有効にすることのセキュリティ上の影響について検討してください。このオプションを有効にする場合、クエリを実行するユーザーに、キャッシュデータベースに対する読み取りアクセスを付与する必要があります。アクセスを付与されたユーザーは、このデータベースに Denodo からだけでなく直接接続できるようになり、Denodo で設定されている行制限、列制限、および他の権限を迂回できます。

   • Partial キャッシュモードのビューの場合、キャッシュエンジンは、クエリを実行するユーザーの資格情報ではなく、常にデータソースの資格情報を使用して、キャッシュデータベースに必要なテーブルを作成してデータを挿入し、これらのテーブルに対してクエリを実行します。この動作は、[Pass-through session credentials] の有効/無効には関係ありません。

   • データベースで定義されている認可ルールを、Virtual DataPort の行制限と列制限、およびマスクのサポートを使用して、対象となる派生ビューに複製する必要があります (詳細については、「 アクセス権限のタイプ 」を参照)。

   • クエリで集計操作 (GROUP BY 、 HAVING ...) を行う場合、キャッシュされたビューに対して集計を実行する必要があります。そうしないと、 COUNT(*) などの集計フィールドに間違った結果が含まれる可能性があります。次の図では、データがキャッシュされる「前」に集計 () が実行されているので、間違った結果が生じる可能性があります。

間違った結果が生じる可能性があるパススルー資格情報の例¶

次の図では、キャッシュが有効なビューに対して集計が実行されます。この場合、 CLIENT_DATA ビューで適切な行制限が設定されていれば、正しい結果に対して集計を実行できます。

正しく使用されているパススルー資格情報の例¶

以下シナリオでは、ビューのキャッシュを有効に しないでください 。

• データソースでパススルー資格情報が有効になっている

• データベースに委任されたクエリで集計操作が実行される

• さらに、集計の際に投影フィールドで取得する値が、(前述の COUNT(*) の例のように) クエリを実行するユーザーに依存する

次の図に、パススルー資格情報を有効にすべきではないシナリオを示します。

パススルー資格情報を有効にすべきではないシナリオ¶