メイン コンテンツをスキップする
お知らせ

Section Access によるデータ セキュリティの管理

このページ上

Section Access によるデータ セキュリティの管理

Section Access は、アプリケーションのセキュリティを制御するために使用されます。これは基本的にデータロード スクリプトの一部であり、セキュリティ テーブルを追加して、誰が何を表示するかを定義します。 Qlik Sense はこの情報を使用して、ユーザーがアプリケーションを開いたときにデータを適切なスコープに縮小します。つまり、アプリ内のデータの一部は、ユーザー ID に基づいてユーザーから非表示になります。 Section Access はアプリ内のデータと緊密に統合されており、アクセスを制御するためにデータに依存しています。この形式の動的データ削減は、テーブルの行、列、または両方の組み合わせを対象にすることができます。

注: Insight Advisor Chat は、セクション アクセスを使用するアプリをサポートしていません。

ロード スクリプトのセクション

データ アクセス制御は、データが通常ロードされるのと同じ方法でロードされる 1 つ以上の セキュリティ テーブルを介して管理されます。 これにより、これらのテーブルを標準のデータベースまたはスプレッドシートに保存できます。セキュリティ テーブルを管理するスクリプト ステートメントは、承認セクション内に指定されます。 承認セクションは、スクリプト内で Section Access ステートメントによって開始されます。

スクリプトで承認セクションが定義されている場合、 アプリ データをロードするスクリプトの一部は、 Section Application ステートメントによって開始される別のセクションに配置する必要があります。

Example:  

Section Access; Load * INLINE [ ACCESS, USERID, REDUCTION USER, AD_DOMAIN\ADMIN, * USER, AD_DOMAIN\A, 1 USER, AD_DOMAIN\B, 2 USER, AD_DOMAIN\C, 3 ADMIN, INTERNAL\SA_SCHEDULER, ]; Section Application; T1: Load *, NUM AS REDUCTION; LOAD Chr(RecNo()+ord('A')-1 AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

ロード スクリプトに変更を加えた後、 変更を有効にするには、常にデータをリロードする必要があることに注意してください。

セクション アクセスのシステム項目

アクセス レベルは、スクリプトの Section Access 部分内にロードされた 1 つ以上のセキュリティ テーブルのユーザーに割り当てられます。これらのテーブルには、少なくとも 2 つの システム項目が含まれている必要があります。アクセス レベルを定義する項目である ACCESS、および USERID または USER。EMAIL . ユース ケースに応じて、他の オプションのシステム項目を追加できます。Section Access のすべてのシステム項目は次のとおりです。

ACCESS

対応するユーザーに与えられるアクセス権を定義します。

指定したユーザーに対して、Qlik Sense アプリへのアクセスを承認できます。セキュリティ テーブルでは、アクセス レベルの ADMIN または USER をユーザーに割り当てることができます。管理者権限を持つユーザーは、 セキュリティ テーブルによって制限されていない限り、アプリ内のすべてのデータにアクセスできます。USER 権限を持つユーザーは、セキュリティ テーブルで指定されたデータにのみアクセスできます。有効なアクセス レベルが割り当てられていないユーザーは、 アプリを開くことができません。

が Section Access はリロード シナリオで使用されます。スケジューラ サービス ユーザーである INTERNAL\SA_SCHEDULER は、リロードを実行するために ADMIN アクセスを必要とします。例:

Section Access; LOAD * inline [ ACCESS, USERID ADMIN, INTERNAL\SA_SCHEDULER ];

INTERNAL\SA_SCHEDULER アカウントを使用したくない場合は、別の方法について なりすましを使用したデータのリロード を参照してください。

テンプレート アプリの On-demand アプリ生成 (ODAG) シナリオで Section Access が使用されている場合、INTERNAL\SA_API ユーザーは、Section Access テーブルに ADMIN として含まれる必要があります。例:

Section Access; LOAD * inline [ ACCESS, USERID ADMIN, INTERNAL\SA_API ];

USERID

Qlik Sense ドメイン名とユーザー名に対応する文字列が含まれます。 Qlik Sense はプロキシ サービスからログイン情報を取得し、その情報をこの項目の値と比較します。

ワイルドカード文字 (*) は、セキュリティ テーブルで指定された追加の条件に従って、すべてのユーザーとして解釈されます。例えば、次のセキュリティ テーブルでは、Qlik Sense Tenant Admins にいるユーザーは、リストされているすべての REDUCTION 値を確認できます。

Section Access; LOAD * INLINE [ ACCESS, USERID, GROUP, REDUCTION ADMIN, *, Qlik Sense Tenant Admins, * USER, QLIK-POC\SOMEOTHERUSER1, *, 1 USER, QLIK-POC\SOMEOTHERUSER2, *, 2 ... ];
注: USERID と NTNAME はどちらも同じ認証情報を使用するため、セキュリティ テーブルの同じ行で両方をチェックする必要はありません。2 つの項目の違いは、NTNAME がグループもチェックすることです。

NTNAME

注: NTNAME はレガシー QlikView 項目であり、 同じセキュリティテーブルを QlikView が使用していない場合は、USERID を使用することをお勧めします。

WindowsNT ドメインのユーザー名またはグループ名に対応する文字列を含む必要がある項目。別の認証システムを使用する場合は、認証されたユーザーの名前を含める必要があります。Qlik Sense は OS からログイン情報を取得し、その情報をこの項目の値と比較します。

GROUP

Qlik Sense 内のグループに対応する文字列を含みます。Qlik Sense は、プロキシ サービスから提供されるユーザーを、このグループに基づいて解決します。

SERIAL

注: SERIAL はレガシー QlikView 項目であり、Qlik Sense のみを使用している場合は使用されません。

プラットフォームに対応する文字列が含まれます。項目に文字列「QLIKSENSE」またはワイルドカード「*」が含まれている場合、セキュリティ テーブルの他の項目に応じて、アクセスが許可される場合があります。

注: 項目 SERIAL にライセンス番号が含まれている場合、 セクション アクセス行はドキュメントへのアクセスを拒否します。この設定は QlikView でのみ有効です

OMIT

この特定のユーザーに対して省略する項目の名前を含みます。ワイルドカードを使用することができます。空にすることもできます。

注: OMIT をキー項目に適用しないことをお勧めします。省略されたキー項目はデータ モデル ビューアーに表示されますが、コンテンツは使用できないので、ユーザーを混乱させる可能性があります。さらに、ビジュアライゼーションで使用されるキー項目に OMIT を適用すると、省略された項目へのアクセス権を持っていないユーザーにはビジュアライゼーションが不完全なものになります。

アプリへのユーザー アクセスの管理

最も単純な形式のセクション アクセスを使用して、特定のユーザーによるアプリへのアクセスを制限できます。 ユーザーは、除外によってアプリへのアクセスを拒否されます。つまり、特定のユーザー ID がセキュリティ テーブルにリストされていない場合、そのユーザーはアプリにアクセスできません。 このルールの唯一の例外は、セキュリティ テーブルの行の 1 つにある USERID 項目にワイルドカード (*) が割り当てられている場合です。この場合、ワイルドカードは、認証されたすべてのユーザーがアプリにアクセスできることを意味します。 ユーザー ID のリストを含むセキュリティ テーブルの例を次に示します。

Section Access; LOAD * inline [ ACCESS, USERID ADMIN, AD_DOMAIN\ADMIN USER, AD_DOMAIN\A USER, AD_DOMAIN\B ]; Section Application;

USERID AD_DOMAIN\C のユーザーは、そのユーザー ID がセキュリティ テーブルにリストされていないため、アプリをまったく開くことができません。

アプリ内の特定のデータへのユーザー アクセスの管理

動的データ削減は、ユーザーがアプリ自体へのアクセスを許可された後、Qlik Sense アプリ内のデータ テーブルの行と列へのアクセスを制限します。

行レベルのデータへのアクセスの管理

ロード スクリプトのアクセス セクションのセキュリティ テーブルにデータ削減列を追加して、行レベルのデータへのアクセスを制限します。Section Access データを実際のデータにリンクすることにより、特定のレコード (行) をユーザーから隠すことができます。表示されるまたは除外されるデータの選択は、スクリプトの Section Access 部分と Section Application 部分に 1 つ以上の縮小項目に共通の名前を付けることで制御されます。ユーザーログイン後、Qlik Sense はアクセス セクションのリダクション項目の選択を、まったく同じ項目名を持つアプリケーション セクション の任意の項目と照合します (項目名は大文字で記述する必要があります)。選択が行われると、Qlik Sense は選択によって除外されたすべてのデータをユーザーに表示しなくなります。データ削減列の項目値としてワイルドカード (*) が使用されている場合、ユーザーは セキュリティ テーブルで選択されたすべての削減項目に関連付けられたレコードにアクセスできると解釈されます。

注:

データ削減列のワイルドカード文字 * は、セキュリティ テーブルのすべての値のみを参照します。Section Application に、セキュリティテーブルの削減列には存在しない値がある場合、その値は削減されます。

注: アクセス セクションでは、すべての項目名と項目値がデフォルトで大文字に変換されるので、上で説明した転送で使用するすべての項目名とそれらの項目のすべての項目値を大文字にする必要があります。
注: 既定では、Qlik Management Console タスクでスクリプトのリロードを有効にする場合は、ADMIN アクセス権を付与されている INTERNAL\SA_SCHEDULER アカウント ユーザーが必要とされます。INTERNAL\SA_SCHEDULER アカウントを使用したくない場合は、別の方法について なりすましを使用したデータのリロード を参照してください。

Example: ユーザー ID に基づく行レベルのデータ削減

Section Access; Authorization: LOAD * inline [ ACCESS, USERID, REDUCTION ADMIN, AD_DOMAIN\ADMIN, * USER, AD_DOMAIN\A, 1 USER, AD_DOMAIN\B, 2 USER, AD_DOMAIN\C, * ADMIN, INTERNAL\SA_SCHEDULER, * ]; Section Application; T1: LOAD *, NUM AS REDUCTION; LOAD RecNo() AS NUM AUTOGENERATE 3;

この例では、現在、項目 REDUCTION (大文字) が Section Access と Section Application の両方にあります (項目値はすべて大文字)。2 つの項目は通常別のもので分かれていますが、Section Access を使用すると、この項目は リンクし、ユーザーに表示されるレコードの数が減ります。

結果は次のようになります。

  • ユーザー ADMIN は、 REDUCTION = 1 または REDUCTION =2 のときにその他のユーザーに表示されるレコードとすべての項目を見ることができます。
  • User A は、すべての項目と、REDUCTION=1 に関連付けられたレコードを見ることができます。
  • User B は、すべての項目と、REDUCTION=2 に関連付けられたレコードを見ることができます。
  • ユーザー C は、REDUCTION = 1 または REDUCTION =2 のときにその他のユーザーに表示されるレコードとすべての項目を見ることができます。

列レベルのデータへのアクセスの管理

Section Access スクリプトのセキュリティ テーブルに OMIT システム フィールドを 追加して、列レベルのデータへのアクセスを制限します。次の例は、行のデータ削減が既に行われている前の例に基づいています。

Example: ユーザー ID に基づく列のデータ削減

Section Access; LOAD * inline [ ACCESS, USERID, REDUCTION, OMIT ADMIN, AD_DOMAIN\ADMIN, *, USER, AD_DOMAIN\A, 1, USER, AD_DOMAIN\B, 2, NUM USER, AD_DOMAIN\C, 3, ALPHA ADMIN, INTERNAL\SA_SCHEDULER, *, ]; Section Application; T1: LOAD *, NUM AS REDUCTION; LOAD Chr( RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

Section Access の項目 OMIT で、ユーザーに表示しない項目を定義します。

結果は次のようになります。

  • ユーザー ADMIN は、REDUCTION が 1 または 2、3 の場合にその他のユーザーに表示されるレコードとすべての項目を見ることができます。
  • User A は、すべての項目と、REDUCTION=1 に関連付けられたレコードを見ることができます。
  • User B は、NUM 以外のすべての項目と、REDUCTION=2 に関連付けられたレコードを見ることができます。
  • User C は、ALPHA 以外のすべての項目と、REDUCTION=3 に関連付けられたレコードを見ることができます。

ユーザー グループへのアクセスの管理

Section Access には、グループ メンバーシップを通じてユーザーに表示されるデータの範囲を制限するオプションがあります。ユーザー グループを使用してデータを制限するには、アクセス セクションのセキュリティ テーブルに GROUP 項目名を追加し、GROUP 項目の値を定義します。

Example: ユーザー　グループに基づくデータ削減

Section Access; LOAD * inline [ ACCESS, USERID, GROUP, REDUCTION, OMIT USER, *, ADMIN, *, USER, *, A, 1, USER, *, B, 2, NUM USER, *, C, 3, ALPHA USER, *, GROUP1, 3, ADMIN, INTERNAL\SA_SCHEDULER, *, *, ]; section application; T1: LOAD *, NUM AS REDUCTION; LOAD Chr( RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

結果は次のようになります。

  • ADMIN グループに属するユーザーは、すべてのデータとすべての項目を見ることができます。
  • A グループに属するユーザーは、 すべての項目で REDUCTION=1 に関連付けられたデータを表示できます。
  • B グループに属するユーザーは、REDUCTION=2 に関連付けられたデータを見ることができますが、NUM 項目のデータは見ることができません。
  • C グループに属するユーザーは、REDUCTION=3 に関連付けられたデータを見ることができますが、ALPHA 項目のデータは見ることができません。
  • GROUP1 グループに属するユーザーは、すべての項目において REDUCTION=3 に関連付けられたデータを見ることができます。

Qlik Sense は、ユーザーを UserID と比較し、テーブル内のグループに対してユーザーを解決します。 ユーザーがアクセス権のあるグループに属する場合、あるいはユーザーが一致した場合、アプリにアクセスできます。

なりすましを使用したデータのリロード

既定では、内部システム アカウント SA_SCHEDULER がリロード タスクの実行に使用されます。このアカウントには 昇格された権限があり、技術的には、任意のデータ ソースを使用できます。ただし、QMC には内部システム アカウントではなく、アプリ所有者のアクセス許可を使用してなりすましで リロード タスクを実行する設定があります。この設定を構成すると、SA_SCHEDULER ではなくアプリの所有者がリロードに使用されます。つまり、Section Access テーブルに SA_SCHEDULER を追加せず、代わりにアプリの所有者を追加します。タスク チェーン内において、アプリは異なる所有者およびソースに対する権限を有することができますが、これは各所有者のアクセス権に依存します。詳細については、[サービス クラスター] を参照してください。

マルチクラウド環境での ユーザー アクセスの管理

Qlik Sense マルチクラウド環境には、ユーザー認証メカニズムが混在しています。通常、Qlik Sense Enterprise on Windows を使用すると、Section Access セキュリティ テーブルの USERID がプロキシ サービスによって検証されます。SaaS editions of Qlik Sense では、ID プロバイダーがその認証のロールを引き受けます。したがって、Qlik Sense Enterprise on Windows などのオンプレミス環境用に設定された Section Access は、クラウド環境では機能しません。

OIDC ID プロバイダー (Qlik IdP またはカスタム IdP) を SaaS editions of Qlik Sense で使用する場合、[件名のクレーム] は、 ログイン時にユーザーを識別するために使用されます。Section Access では、セキュリティ テーブルの USERID 項目の値が、[件名のクレーム] の値と比較されます。テナントを設定するときは、 SAM アカウント名が ID プロバイダーの [件名のクレーム] にマップされていることを確認してください。したがって、例えば、SAM アカウント名が AD_DOMAIN\Dev の場合、[件名のクレーム] を AD_DOMAIN\Dev に設定します。IdP の [件名のクレーム] の値を確認する場合は、 ブラウザーのテナント URL に「/api/v1/diagnose-claims」を追加します (例: your-tenant.us.qlikcloud.com/api/v1/diagnose-claims)。JSON 応答では、[件名のクレーム] は [sub] と呼ばれます。

SAM アカウント名を使用できない場合は、 ユーザーを認証する別の方法があります。ユーザーのメール アドレスは、さまざまな環境で同じままになる傾向があります。その場合は、セキュリティ テーブルの USERID の代わりに USER.EMAIL 項目を使用できます。セキュリティ テーブルがどのように見えるかの例を次に示します。

ACCESS USERID USER.EMAIL Comment COUNTRY
USER ABC\Joe * Access-on-prem 米国
ユーザー * joe.smith@example.com Access-in-cloud United States
USER ABC\Ursula * Access-on-prem Germany
USER * ursula.schultz@example.com Access-in-cloud Germany
USER ABC\Stefan * Access-on-prem Sweden
USER * stefan.svensson@example.com Access-in-cloud Sweden

承認スクリプト:

Section Access; LOAD * INLINE [ ACCESS, USERID, USER.EMAIL, COUNTRY USER, ABC\Joe, *, United States USER, *, joe.smith@example.com, United States USER, ABC\Ursula, *, Germany USER, *, ursula.schultz@example.com, Germany USER, ABC\Stefan, *, Sweden USER, *, stefan.svensson@example.com, Sweden ];

各ユーザーには 2 つのレコードがあることに注意してください。1 つはオンプレミス アクセス用で、もう 1 つはクラウド アクセス用です。ワイルドカードは、関連する認証項目のみが使用されることを保証します。この例では、COUNTRY がデータ削減項目として使用されています。

Section Access を使用するためのガイドラインとヒント

Section Access について知っておくべきいくつかの重要な事実と役立つヒントを次に示します。

  • アクセス セクション内の LOAD または SELECT ステートメントにリストする項目は、すべて大文字で記述する必要があります。データベース内の小文字を含む項目名は、Upper 関数で LOAD または SELECT ステートメントで読み取る前に、大文字に変換されます。

    詳細については、「Upper - スクリプトおよびチャート関数」を参照してください。

  • データ モデルの項目名としてリストされている Section Access システムの項目名を 使用することはできません。
  • Section Access コントロールが適用される前に、アプリは公開されていなければなりません。アプリをリロードすると、新規または変更済み Section Access スクリプトは適用されません。
  • スナップショットには、スナップショットを取得するユーザーのアクセス権限に従ってデータが表示され、そのスナップショットは 1 つのストーリーで共有することができます。ただし、ユーザーがアプリでライブ データを見るためにストーリーからビジュアライゼーションに戻ると、それらのスナップショットは、それ独自のアクセス権限によって制限されます。
  • セクション アクセスを使用する場合、または極秘データを扱う場合は、値が色構成により公開される可能性があるため、マスター軸の値に色を割り当てないでください。
  • 制限されているデータを公開しないようにするには、アプリを公開する前に、セクション アクセス設定が含まれるすべての添付ファイルを削除します。添付ファイルはアプリの公開時に含まれます。公開済みアプリがコピーされると、添付ファイルがそのコピーに含まれます。ただし、添付したデータ ファイルにセクション アクセス制限が適用されている場合、ファイルがコピーされるときにセクション アクセス設定が保持されません。そのため、コピーしたアプリのユーザーは、添付ファイルのすべてのデータを表示することができます。
  • ワイルドカード (*) は、この項目に含まれるすべての値 (リストされている値)、つまりこのテーブル内のその他の場所にリストされている値として解釈されます。スクリプトのアクセス セクションでロードされたテーブル内のシステム項目 (USERID、GROUP) の 1 つで使用すると、この項目のすべての可能な値 (リストされていない値も含む) として解釈されます。
  • セキュリティ項目は、さまざまなテーブルに配置できます。
  • QVD ファイルからデータをロードする場合、Upper 関数はロード速度を遅くします。
  • セクション アクセスを設定することで、アプリから自分自身をロックしている場合、データなしでアプリを開き、データ ロード スクリプトでアクセス セクションを編集することができます。そのためには、データ ロード スクリプトの編集およびリロードにアクセスできる必要があります。

    詳細については、「データなしでアプリを開く」を参照してください。

  • バイナリ ロードを使用すると、新しい Qlik Sense アプリにアクセス制限が継承されます。