Tableau の行レベルのセキュリティ オプションの概要

データのフィルターリングを、データを必要としているユーザーに基づいて行いたい場合があります。例えば、次のような場合です。

  • 地域の営業担当者に、自分の地域の売上高のみを表示させたい。
  • 営業マネージャーに、自分の部下の営業担当者の統計のみを表示させたい。
  • 生徒に、自分の成績に基づいたビジュアライゼーションのみを表示させたい。

データをこのようにフィルターリングするアプローチは、行レベルのセキュリティ (RLS) と呼ばれます。行レベルのセキュリティを実現する方法は Tableau の内部と外部で複数あり、それぞれに長所と短所があります。

手動でユーザー フィルターを作成し、ユーザーを値にマッピングする

Tableau で行レベルのセキュリティを実現する最も簡単な方法は、ユーザーを手動で値にマッピングするユーザー フィルターを使用することです。たとえば、「Alice」という名前のユーザーを値「東部」に手動でマッピングして、「地域」列が「東部」であるデータ ソースの行のみが表示されるようにすることができます。

この方法は便利ですが、メンテナンスに手がかかり、セキュリティに注意を払う必要があります。ワークブックごとに行う必要があり、ユーザー ベースが変更されるたびにフィルターを更新してデータ ソースをパブリッシュし直す必要があります。このタイプのユーザー フィルターを使用してアセットをパブリッシュする場合、ユーザーがアセットを保存またはダウンロードしてフィルターを削除し、その結果すべてのデータにアクセスできないようにパーミッションを設定する必要があります。

詳細については、Tableau Desktop および Web オーサリング ヘルプの「手動でユーザー フィルターを作成し、ユーザーを値にマッピングする」(新しいウィンドウでリンクが開く)を参照してください。

データのセキュリティ フィールドを使用して動的ユーザー フィルターを作成する

この方法を使用して、ユーザーをデータ値へマッピングするプロセスを自動化する計算フィールドを作成します。この方法では、フィルターに使用するセキュリティ情報が参照元データに含まれている必要があります。たとえば、データソースの計算フィールド、USERNAME() 関数、および「マネージャー」列を使用して、ビューを必要としているユーザーがマネージャーであるかどうかを判断し、それに応じてビューのデータを調整します。

フィルターリングはデータ レベルで定義され、計算フィールドで自動化されるため、この方法はユーザーを手動でデータ値にマッピングするよりも安全です。このタイプのユーザー フィルターを使用してアセットをパブリッシュする場合、ユーザーがアセットを保存またはダウンロードしてフィルターを削除し、その結果すべてのデータにアクセスできないようにパーミッションを設定する必要があります。

詳細については、Tableau Desktop および Web オーサリング ヘルプの「データのセキュリティ フィールドを使用して動的フィルターを作成する」(新しいウィンドウでリンクが開く)を参照してください。

データ ポリシーを使用する

Tableau 2021.4 以降、Tableau Server または Tableau Cloud で データ管理 が有効になっている場合、Creator ライセンスを持つユーザーは、仮想接続のデータ ポリシーを通じて行レベルのセキュリティを実装できるようになりました。仮想接続は一元化され再利用できるため、その接続を使用するすべてのコンテンツにわたって、各接続の行レベルのセキュリティを 1 か所で安全かつ確実に管理できます。

Tableau の行レベルのセキュリティに関する前述のソリューションとは異なり、この方法では、作成者がワークブックやデータ ソースのパーミッションを適切に設定しなかったために情報が漏えいするリスクはありません。すべてのクエリに対してサーバー上でポリシーが適用されるためです。

仮想接続のデータ ポリシーによる行レベルのセキュリティは、行レベルのセキュリティの他のソリューションの欠点に対処するために開発されました。このソリューションを選択できる場合は、ほとんどの状況でこのソリューションを使用することをお勧めします。

仮想接続でデータ ポリシーを使用する行レベルのセキュリティの詳細については、仮想接続とデータ ポリシーについてを参照してください。

データベース内の既存の RLS を使用する

多くのデータ ソースには、RLS のメカニズムが組み込まれています。組織がすでにデータ ソース内の行レベルのセキュリティの構築に力を入れている場合は、既存の RLS を利用できる場合があります。

組み込み RLS モデルの実装は、Tableau を念頭においた構築に比べて、必ずしも簡単であったり優れたりするとは限りません。これらの手法は、一般に、組織が既にこれらのテクノロジに投資しており、投資を活用する場合に利用されます。

組み込まれている RLS を使用する主な利点は、管理者がデータ セキュリティ ポリシーを 1 か所、つまりデータベースに実装して制御できることです。

ユーザー属性を渡す

JSON Web Token (JWT) に含まれるユーザー属性を渡すと、Tableau Cloud の埋め込みのワークフローでデータへのアクセスをカスタマイズおよび制御することができます。詳細については、埋め込み v3 API(新しいウィンドウでリンクが開く) ヘルプを参照してください。

行レベルのセキュリティ オプションの比較

RLS オプション役に立つ状況長所短所
手動ユーザー フィルター
  • 概念実証を行っている、または、ユーザー フィルターリング機能をテストしている
  • 変わることのないユーザー グループで使用する静的なワークブックを作成している
  • パーミッションが正しく設定されていないことによる情報セキュリティのリスクを理解している
  • 小規模でシンプル
  • わかりやすいマッピング
  • テストに適している
  • メンテナンスに手がかかる
  • ユーザーの所属が変わるとフィルターを更新し、パブリッシュし直す必要がある
  • ユーザーがフィルターリングされていないデータを見ることができないように、パーミッションを設定する必要がある
  • すべてのワークブックに複製する必要がある
動的ユーザー フィルター
  • データ管理 ライセンスがない
  • フィルターリングに使用できる情報がデータに含まれている
  • パーミッションが正しく設定されていないことによる情報セキュリティのリスクを理解している
  • セットアップが比較的簡単
  • ユーザーがフィルターリングされていないデータを見ることができないように、パーミッションを設定する必要がある
  • すべてのワークブックまたはデータ ソースに複製する必要がある
データ ポリシー
  • データ管理 ライセンスがある
  • フィルターリングに使用できる情報がデータに含まれている
  • データ セキュリティの容易さは重要な問題である
  • 一元化
  • 安全
  • メンテナンスが容易
  • セキュリティ責任と分析責任を分離できる
  • データ管理 ライセンスが必要
データベース内の RLS
  • データベース内に組み込まれた RLS がすでにある
  • 抽出を使用していない
  • 組織のデータベースにすでに組み込まれている可能性がある
  • Tableau 以外のデータベース クライアントにもポリシーを適用できる
  • ライブ クエリを使用する必要がある
  • 制限事項や必須要件がある場合があり、IT チームがそれらを識別できる
ユーザー属性
  • 他のポリシーやユーザーのパーソナライゼーションを管理する場所と同じところでデータ アクセス ポリシーを管理できる

 

フィードバックをお送りいただき、ありがとうございます。フィードバックは正常に送信されました。ありがとうございます!