Section Access は、アプリケーションのセキュリティを制御するために使用されます。これは基本的にデータロード スクリプトの一部であり、セキュリティ テーブルを追加して、誰が何を表示するかを定義します。 Qlik Cloud はこの情報を使用して、ユーザーがアプリケーションを開いたときにデータを適切なスコープに縮小します。つまり、アプリ内のデータの一部は、ユーザーの ID に基づいてユーザーから非表示になります。セクション アクセスはアプリ内のデータと緊密に統合されており、アクセスを制御するためにデータに依存しています。この形式の動的データ削減は、テーブルの行、列、または両方の組み合わせを対象にすることができます。詳細については、「Qlik の信頼とセキュリティ」を参照してください。
ロード スクリプトのセクション
データのアクセス制御は、データが通常ロードされるのと同じ方法でロードされる 1 つまたは複数のセキュリティ テーブルを通じて管理されます。これにより、これらのテーブルを標準のデータベースまたはスプレッドシートに保存できます。セキュリティ テーブルを管理するスクリプト ステートメントは、スクリプトの中で Section Access ステートメントで開始される承認セクション内に指定します。
セクション アクセスに一覧表示されている項目名と項目値は、常にすべて大文字に変換されます。そのため、データ削減の一部となるすべての項目は、セクション アクセス ステートメントの外部にある場合でも、セクション アクセス ステートメントの記述内容と一致するように大文字に変換する必要があります。データベース内の小文字を含む項目名は、LOAD または SELECT ステートメントで読み取る前に、Upper 関数で大文字に変換できます。
詳細については、「Upper - スクリプトおよびチャート関数」を参照してください。
スクリプト内で承認セクションが定義されている場合、アプリのデータをロードする部分のスクリプトを Section Application で開始される別のセクション内に配置する必要があります。
ロード スクリプトに変更を加えた後、変更を有効にするためには、常にデータをリロードする必要があります。
セクション アクセスのシステム項目
アクセス レベルは、スクリプトの Section Access 部分内にロードされた 1 つ以上のセキュリティ テーブルのユーザーに割り当てられます。これらのテーブルには、少なくとも 2 つのシステム 項目が含まれている必要があります。アクセス レベルを定義する項目である ACCESS、および USERID または USER。EMAIL。使用例に応じて、オプションのシステム 項目を追加できます。Section Access のすべてのシステム項目は次のとおりです。
ACCESS
対応するユーザーに与えられるアクセス権を定義します。
指定したユーザーに対して、Qlik Sense アプリへのアクセスを承認できます。セキュリティ テーブルでは、アクセス レベルの ADMIN または USER をユーザーに割り当てることができます。管理者権限を持つユーザーは、セキュリティ テーブルによって制限されない限り、アプリ内の全データにアクセスできます。USER 権限を持つユーザーは、セキュリティ テーブルで指定されたデータにのみアクセスできます。有効なアクセス レベルが割り当てられていないユーザーは、アプリを開くことができません。
USERID
Qlik Cloud ユーザー名に対応する文字列を含みます。Qlik Cloud は IdP サブジェクトからログイン情報を取得し、その情報をこの項目の値と比較します。メール アドレスを使用してユーザー ID を確認する別の方法については、 USER.EMAIL を参照してください。マルチクラウド環境の場合、IdP サブジェクトを内部の Windows ID に対してマッピングできます。Qlik Account を使用する場合、サブジェクトを内部の Windows ID に対してマッピングできません。 ユーザー IdP のサブジェクトは、Administration アクティビティ センターの [ユーザー] セクションで表示できます。
ワイルドカード文字 (*) は、セキュリティ テーブルで指定された追加の条件に従って、すべてのユーザーとして解釈されます。例えば、次のセキュリティ テーブルでは、Qlik Sense Tenant Admins にいるユーザーは、リストされているすべての REDUCTION 値を確認できます。
NTNAME
WindowsNT ドメインのユーザー名またはグループ名の NetBIOS バージョンに対応する文字列を含む必要がある項目。別の認証システムを使用する場合は、認証されたユーザーの名前を含める必要があります。
Qlik Cloud は、ID プロバイダーの subject クレームからログオン情報を取得し、それをこの項目の値と比較します。
USER.EMAIL
ユーザーのメール アドレスに対応する文字列が含まれます。Qlik Cloud は ID プロバイダーからこの情報を取得し、その情報をこの項目の値と比較します。
GROUP
Qlik Cloud 内のグループに対応する文字列を含みます。Qlik Cloud は、ID プロバイダーの “groups” クレームから情報を取得し、その情報をこの項目の値と比較します。
OMIT
この特定のユーザーに対して省略する項目の名前を含みます。ワイルドカードを使用することができます。空にすることもできます。
アプリへのユーザー アクセスの管理
USERID AD_DOMAIN\C のユーザーは、そのユーザー ID がセキュリティ テーブルにリストされていないため、アプリをまったく開くことができません。
最も単純な形式のセクション アクセスを使用して、特定のユーザーによるアプリへのアクセスを制限できます。 ユーザーは、除外によってアプリへのアクセスを拒否されます。つまり、特定のユーザー メール アドレスがセキュリティ テーブルにリストされていない場合、そのユーザーはアプリにアクセスできません。このルールの唯一の例外は、セキュリティ テーブルの行の 1 つにある USER.EMAIL 項目にワイルドカード (*) が割り当てられている場合です。この場合、ワイルドカードは、認証されたすべてのユーザーがアプリにアクセスできることを意味します。 ユーザー ID のリストを含むセキュリティ テーブルの例を次に示します。
USER.EMAIL USER4@example.com という ID のユーザーは、そのユーザー メール アドレスがセキュリティ テーブルにリストされていないため、アプリをまったく開くことはできません。
アプリ内の特定のデータへのユーザー アクセスの管理
動的データ削減は、ユーザーがアプリ自体へのアクセスを許可された後、Qlik Sense アプリ内のデータ テーブルの行と列へのアクセスを制限します。
行レベルのデータへのアクセスの管理
ロード スクリプトのアクセス セクションのセキュリティ テーブルにデータ削減列を追加して、行レベルのデータへのアクセスを制限します。Section Access データを実際のデータにリンクすることにより、特定のレコード (行) をユーザーから隠すことができます。表示されるまたは除外されるデータの選択は、スクリプトの Section Access 部分と Section Application 部分に 1 つ以上の縮小項目に共通の名前を付けることで制御されます。ユーザー ログインの後、Qlik Sense はアクセス セクションの削減項目にある選択と、同じ項目名 (項目名は大文字で入力する必要があります) のアプリケーション セクションにある任意の項目を照合します。選択が行われると、Qlik Sense は選択によって除外されたすべてのデータをユーザーに表示しなくなります。データ削減列の項目値としてワイルドカード (*) が使用されている場合、ユーザーは、セキュリティ テーブル内で選択されているすべての削減項目に関連付けられたレコードにアクセスできると解釈されます。
Qlik Sense がセクション アクセスの削減項目をデータ モデルの項目と比較する際、次のような動作が予想されます:
データモデルの項目値とセクション アクセスの削減項目が一致した場合、アプリが開き、指定したユーザーの一致に関連付けられたデータが表示されます。その他のデータは非表示となります。
削減項目値がデータ モデルのどの値とも一致しない場合、アプリは通常の USER に対して開きます。ただし、ADMIN とマークされたユーザーに対しては削減されずに開きます。
アクセスの組み合わせが意図通りにならないため、セクション アクセスで複数の削減項目を使用することは推奨されません。
データ削減列のワイルドカード文字 * は、セキュリティ テーブルのすべての値のみを参照します。Section Application に、セキュリティテーブルの削減列には存在しない値がある場合、その値は削減されます。
ユーザー ID に基づく行レベルのデータ削減
この例では、現在、項目 REDUCTION (大文字) が Section Access と Section Application の両方にあります (項目値はすべて大文字)。2 つの項目は通常別のもので分かれていますが、Section Access を使用すると、この項目はリンクし、ユーザーに表示されるレコードの数が減ります。
結果は次のようになります。
- ユーザー USER1@EXAMPLE.COM は、REDUCTION = 1 または REDUCTION =2 のときにその他のユーザーに表示されるレコードとすべての項目を見ることができます。
- User USER2@EXAMPLE.COM は、すべての項目と、REDUCTION=1 に関連付けられたレコードを見ることができます。
- User USER3@EXAMPLE.COM は、すべての項目と、REDUCTION=2 に関連付けられたレコードを見ることができます。
- ユーザー USER4@EXAMPLE.COM は、REDUCTION = 1 または REDUCTION =2 のときにその他のユーザーに表示されるレコードとすべての項目を見ることができます。
列レベルのデータへのアクセスの管理
OMIT システム 項目を Section Access スクリプトのセキュリティ テーブルに追加して、行レベルのデータへのアクセスを制限します。次の例は、行のデータ削減が既に行われている前の例に基づいています。
ユーザー ID に基づく列のデータ削減
Section Access の項目 OMIT で、ユーザーに表示しない項目を定義します。
結果は次のようになります。
- ユーザー USER1@example.com は、REDUCTION が 1 または 2、3 の場合にその他のユーザーに表示されるレコードとすべての項目を見ることができます。
- User USER2@example.com は、すべての項目と、REDUCTION=1 に関連付けられたレコードを見ることができます。
- User USER3@example.com は、NUM 以外のすべての項目と、REDUCTION=2 に関連付けられたレコードを見ることができます。
- User USER4@example.com は、ALPHA 以外のすべての項目と、REDUCTION=3 に関連付けられたレコードを見ることができます。
ユーザー グループへのアクセスの管理
Section Access には、グループ メンバーシップを通じてユーザーに表示されるデータの範囲を制限するオプションがあります。ユーザー グループを使用してデータを制限するには、アクセス セクションのセキュリティ テーブルに GROUP 項目名を追加し、GROUP 項目の値を定義します。
ユーザー グループに基づくデータ削減
結果は次のようになります。
- ADMIN グループに属するユーザーはすべての項目を表示でき、この例では REDUCTION が 1、2、または 3 の場合に他のユーザーが表示できるレコードのみを表示できます。
- A グループに属するユーザーは、すべての項目において REDUCTION=1 に関連付けられたデータを見ることができます。
- B グループに属するユーザーは、REDUCTION=2 に関連付けられたデータを見ることができますが、NUM 項目のデータは見ることができません。
- C グループに属するユーザーは、REDUCTION=3 に関連付けられたデータを見ることができますが、ALPHA 項目のデータは見ることができません。
- GROUP1 グループに属するユーザーは、すべての項目において REDUCTION=3 に関連付けられたデータを見ることができます。
- ユーザー AD_DOMAIN\DEV はすべての項目のすべてのデータを見ることができます。
Qlik Cloud はユーザーを UserID と比較し、そのユーザーがテーブル内のグループに含まれているか確認します。ユーザーがアクセス権のあるグループに属する場合、あるいはユーザーが一致した場合、アプリにアクセスできます。
Qlik Cloud でのデータのリロード
Qlik Cloud でデータ削減をせずにアプリをリロードするには、セキュリティ テーブルの USER.EMAIL システム 項目を使用することをお勧めします。USER.EMAIL 項目の値は、アプリを編集およびロードできるユーザーのメール アドレスである必要があります。これは、共有スペースと管理スペースの両方のアプリに適用されます。例:
この例では、メール アドレス test@example.com のユーザーは ADMIN であり、アプリをリロードできます。
グループを使用している場合、次の例は Qlik Sense と Qlik Cloud の両方で同等に機能します。
以下の例で示すように、セキュリティ テーブルの [USERID] を ID プロバイダーの [subject claim] にマッピングすることもできます。この構成は、Qlik Sense から Qlik Cloud への移行、およびマルチクラウド環境に推奨されます。[USERID] を [subject claim] にマッピングする方法の詳細については、マルチクラウド環境におけるユーザー アクセスの管理 を参照してください
マルチクラウド環境におけるユーザー アクセスの管理
Qlik Sense マルチクラウド環境には、ユーザー認証メカニズムが混在しています。通常、Qlik Sense Enterprise on Windows を使用すると、セクション アクセス セキュリティ テーブルの USERID がプロキシ サービスによって検証されます。Qlik Cloud では、ID プロバイダーがその認証のロールを引き受けます。したがって、Qlik Sense Enterprise on Windows などのオンプレミス環境用に設定されたセクション アクセスは、クラウド環境では機能しません。
OIDC または SAML ID プロバイダー (Qlik IdP またはカスタム IdP) を Qlik Cloud で使用する場合、 [subject claim] はログイン時のユーザー識別に使用されます。Section Access では、セキュリティ テーブルの USERID 項目の値が、[subject claim] の値と比較されます。テナントを設定するとき、SAM アカウント名が ID プロバイダーの [subject claim] にマッピングされていることを確認してください。したがって、例えば、SAM アカウント名が AD_DOMAIN\Dev の場合、[subject claim] を AD_DOMAIN\Dev に設定します。IdP の [subject claim] の値を確認する場合、ブラウザーのテナント URL に「/api/v1/diagnose-claims」を追加します (例: your-tenant.us.qlikcloud.com/api/v1/diagnose-claims)。JSON 応答では、[subject claim] は [sub] と呼ばれます。
SAM アカウント名を使用できない場合は、別のユーザー認証方法があります。メール アドレスは異なる環境でも変更されない傾向があるため、セキュリティ テーブルでは、USERID の代わりに USER.EMAIL 項目を使用できます。セキュリティ テーブルがどのように見えるかの例を次に示します。
| ACCESS | UserId: | USER.EMAIL | コメント | COUNTRY |
|---|---|---|---|---|
| ユーザー | ABC\JOE | * | Access-on-prem | 米国 |
| ユーザー | * | JOE.SMITH@EXAMPLE.COM | Access-in-cloud | 米国 |
| ユーザー | ABC\URSULA | * | Access-on-prem | ドイツ |
| ユーザー | * | URSULA.SCHULTZ@EXAMPLE.COM | Access-in-cloud | ドイツ |
| ユーザー | ABC\STEFAN | * | Access-on-prem | スウェーデン |
| ユーザー | * | STEFAN.SVENSSON@EXAMPLE.COM | Access-in-cloud | スウェーデン |
承認スクリプト:
各ユーザーには 2 つのレコードがあることに注意してください。1 つはオンプレミス アクセス用で、もう 1 つはクラウド アクセス用です。ワイルドカードは、関連する認証項目のみが使用されることを保証します。この例では、COUNTRY がデータ削減項目として使用されています。
QlikView 承認項目
下位互換性のために、Qlik Cloud は QlikView からの承認項目を認識します。USERID は QlikView と Qlik Cloud で異なって解釈されますが、Qlik Cloud では Qlik Sense と同じように解釈されます。認証されたユーザーの名前と照合されます。
PASSWORD, NTSIDおよびNTDOMAINSID
項目 PASSWORD、NTSID、NTDOMAINSID のいずれかが使用され、関連する値が含まれている場合、ドキュメントへのアクセスは拒否されます。項目にワイルド カード (*) が含まれている場合、承認テーブルの他の項目によっては、アクセスが許可される場合があります。
SERIAL
項目 SERIAL が使用され、ライセンス番号が含まれている場合、セクション アクセス行はドキュメントへのアクセスを拒否します。項目にワイルド カード (*) が含まれている場合、承認テーブルの他の項目によっては、アクセスが許可される場合があります。
さらに、Qlik Cloud では、この項目を使用して環境を定義することもできます。これは、項目に文字列「QLIKCLOUD」が含まれている場合、承認テーブルの他の項目によっては、アクセスが許可される可能性があることを意味します。
混合環境
QlikView と Qlik Cloud の両方で同じセキュリティ テーブルを使用する場合は、次の点に注意してください。
• USERID は QlikView と Qlik Cloud で異なる意味を持ち、使用するとセキュリティ上の問題を引き起こす可能性があります。代わりに NTNAME を使用するか、以下で説明するように SERIAL と組み合わせてください。
•GROUP と、「USER.NAME」や「USER.EMAIL」などの「USER.」で始まる項目は、Qlik Cloud の項目を承認します (または承認する予定です)。セクション アクセスでこれらの項目を使用すると、Qlik Cloud でアクセスが拒否される場合があります。
•PASSWORD, NTSID と NTDOMAINSID は Qlik Cloud では使用できません。ワイルド カードを使用しない限り、アクセスは拒否されます。
•SERIAL を使用して Qlik Cloud のライセンス番号を確認することはできません。ただし、この項目に文字列「QLIKCLOUD」が含まれている場合は、アクセスが許可される可能性があります。これは、次のようなセキュリティ テーブルを持つことができることを意味します。ここで、行 1 は QlikView でアクセスを許可し (Qlik Cloud では許可しません)、行 2 は Qlik Cloud でアクセスを許可します (QlikView では許可しません)。
| 線 | SERIAL | UserId: | コメント |
|---|---|---|---|
| 1 | 4600 0123 4567 8901 | * | QlikView の正しいライセンス番号へのアクセスを許可します。 |
| 2 | QLIKCLOUD | JOHN DOE | Qlik Cloud の正しいユーザーにアクセスを許可します。 |
承認スクリプト:
セクションアクセスと Insight Advisor Chat の使用
Section Access を使用するアプリは、インデックス ユーザーを使用して、Insight Advisor Chat がアプリから取得する情報の量を決定します。 インデックス ユーザーは、Section Access スクリプトでアプリへの最高レベルのアクセス権を持つユーザーである必要があります。ただし、エンド ユーザーに提供されるデータは、セクション アクセス制限によって引き続き制御されます。
セクション アクセスと Insight Advisor Chat の使用方法に関するビジュアル デモについては、次を参照してください。
セクション アクセスと Insight Advisor Chat の使用
アプリ名、項目名、またはマスター アイテム名に機密情報がある場合、セクション アクセスを使用するアプリを Insight Advisor Chat で利用できるようにすることで、これらが公開される可能性があります。クエリに対するアプリの提案には、ユーザーがアクセスできるスペース内のアプリが含まれます。それらには、ユーザーがアプリのセクション アクセスでアクセス権を持たないアプリが含まれる場合があります。ただし、これらのアプリを選択しても何も起こりません。[軸] または [メジャー] をクリックして、セクション アクセスを使用してアプリから利用可能なアイテムを表示すると、ユーザーにはアクセスできないアイテムが表示される場合があります。ただし、これらのアイテムをクリックしても、ユーザーにデータは提供されません。
既定では、アプリの所有者はインデックス ユーザーです。[詳細] でインデックス ユーザーを変更できます。
次の手順を実行します。
Qlik Cloud で、アプリに移動します。
アプリで
をクリックし、[詳細] を選択します。[インデックス ユーザー] で、インデックス ユーザーを選択します。
[戻る] をクリックします。
アプリで
をクリックし、[リロード] を選択します。
セクション アクセスでの QVD の使用
QVD ファイルは、通常のロード、または最適化されたロードとして読み取ることができます。最適化されたロードとは、ロード中にデータ変換が行われず、WHERE 句にフィルターがない場合のことです。
セクション アクセスで QVD を使用する場合、最適化されたロードは機能しません。QVD ファイルを使用してセクション アクセスにデータをロードする場合は、QVD ファイルを展開する必要があります。QVD ファイルを展開する最も簡単な方法は、データをロードするときにフォーマットを変更することです。
次の例では、データのフォーマットが行われていないため、QVD ファイルは展開されません。
データ フォーマットなしの非稼働例 (最適化されたロード)
代わりに、たとえば upper() 関数を使用してデータをフォーマットし、QVD ファイルを展開できます。
データ フォーマットありの稼働例
Load ステートメントに Where 1=1 ステートメントを追加することもできます。
データ フォーマットありの別の稼働例
Section Access を使用するためのガイドラインとヒント
Section Access について知っておくべきいくつかの重要な事実と役立つヒントを次に示します。
- セクション アクセスに一覧表示されている項目名と項目値は、常にすべて大文字に変換されます。そのため、データ削減の一部となるすべての項目は、セクション アクセス ステートメントの外部にある場合でも、セクション アクセス ステートメントの記述内容と一致するように大文字に変換する必要があります。データベース内の小文字を含む項目名は、LOAD または SELECT ステートメントで読み取る前に、Upper 関数で大文字に変換できます。
詳細については、「Upper - スクリプトおよびチャート関数」を参照してください。
- 項目名として一覧に表示される Section Access システム 項目名をデータ モデルで使用できません。
- Section Access コントロールが適用される前に、アプリは公開されていなければなりません。アプリをリロードすると、新規または変更済み Section Access スクリプトは適用されません。
- スナップショットには、スナップショットを取得するユーザーのアクセス権限に従ってデータが表示され、そのスナップショットは 1 つのストーリーで共有することができます。ただし、ユーザーがアプリでライブ データを見るためにストーリーからビジュアライゼーションに戻ると、それらのスナップショットは、それ独自のアクセス権限によって制限されます。
- セクション アクセスを使用する場合、または極秘データを扱う場合は、値が色構成により公開される可能性があるため、マスター軸の値に色を割り当てないでください。
- 制限されているデータを公開しないようにするには、アプリを公開する前に、セクション アクセス設定が含まれるすべての添付ファイルを削除します。添付ファイルはアプリの公開時に含まれます。公開済みアプリがコピーされると、添付ファイルがそのコピーに含まれます。ただし、添付したデータ ファイルにセクション アクセス制限が適用されている場合、ファイルがコピーされるときにセクション アクセス設定が保持されません。そのため、コピーしたアプリのユーザーは、添付ファイルのすべてのデータを表示することができます。
- ワイルドカード (*) は、テーブル内の項目に含まれるすべての値として解釈されます。スクリプトのアクセス セクションでロードされたテーブル内のシステム項目 (USERID、GROUP) の 1 つで使用すると、この項目のすべての可能な値 (リストされていない値も含む) として解釈されます。
- セキュリティ項目は、さまざまなテーブルに配置できます。
- QVD ファイルからデータをロードする場合、Upper 関数はロード速度を遅くします。