表示されているのは Looker のドキュメントです。Looker Studio のドキュメントについては、https://support.google.com/looker-studio をご覧ください。

ベストプラクティス: フォルダを保護するコンテンツアクセスのガイド

これらのベストプラクティスには、経験豊富な Looker の機能横断的なチームによる推奨事項が反映されています。これらのインサイトは、実装から長期的な成功に至るまで、Looker のお客様との連携に携わった長年の経験に基づいています。ベストプラクティスはほとんどのユーザーと状況に合わせて作成されていますが、実装の際は慎重に判断してください。

このページでは、Looker インスタンスの管理者を対象に、コンテンツへのアクセス制御の設定例を紹介します。実装の手順を説明します。まず、新しいプロジェクトから、モデル、モデルセット、権限セット、グループ、ロール、ユーザー属性の順に説明します。

まず、このコンテキストで Looker の主な機能について理解します。

プロジェクトは、家のようなものです。

モデルは、家の中の特定のコンテンツが格納された部屋です。

モデルセットは、部屋のグループまたは 1 つの部屋（寝室、キッチン）です。

権限セットは、ユーザーが部屋でできること（食事、遊ぶ、眠る）を指定する、アクティビティのチェックリストです。

グループは、共有される特徴（大人、子ども、ゲスト）で人々を組み合わせる方法です。

ロールは、人々のグループに、異なる部屋のセットでのアクティビティチェックリストを提供する方法です。

ユーザー属性は、家の中で特別なアイテム（ティーポット、電動工具）を開くためのキーです。

シナリオ

以下は、財務チーム、セールスチーム、プロダクトチームで構成されるスタートアップの例です。CEO が唯一の管理者で、彼女は、各チームのバイスプレジデントがすべてのチームのコンテンツにアクセスできるという点を除き、各チームに関連するコンテンツのみを表示させたいと考えています。彼女は、標準の従業員、マネージャー、バイスプレジデントに、それぞれ異なる機能にアクセスさせたいと考えています。

標準の従業員は、自分のモデルでデータを表示、探索できる必要があります。
管理者には、標準のアクセス権があり、コンテンツのダウンロードやスケジュール設定を行えるようにする必要があります。
CEO 専用の一部の権限を除き、バイスプレジデントにはほぼすべての権限を持つ必要があります。

CEO は、セールス担当者が自分の活動のデータを表示できるものの、他のセールス担当者の個人の販売数の閲覧はできないようにしたいと考えています。ただし、セールスマネージャーはすべてのセールス担当者の数字を表示できる必要があります。最後に、そのモデルを使用する標準的な従業員用に対してマスクする、機密情報を含む財務フィールドがあります。

組織図を以下に示します。

この例のスタートアップの組織図。

上の図は、このスタートアップ例に関する次の組織構造を示しています。

財務担当バイスプレジデント

財務マネージャー

公認会計士

セールス担当バイスプレジデント

セールスマネージャー（西部）

セールス担当者（西部）

セールスマネージャー（東部）

セールス担当者（東部）

製品担当バイスプレジデント

プロダクトマネージャー

エンジニア

必要なアクセス制御を実装する手順は次のとおりです。

プロジェクトを作成: プロジェクトは、データベース接続とデータモデル間の構造リンクです。
モデルを追加: どのユーザーにどのデータを公開するかを決定します。
モデルセットを作成: 関連するモデルをグループ化します。
権限セットを作成:モデルセット内でユーザーが実行できる操作を明示的に定義します。
グループを作成: 類似するユーザーをグループ化します。
ロールを作成: モデルセット、権限セット、グループ間の接続を作成します。
コンテンツアクセスを編集: フォルダを使用して閲覧できるダッシュボードと Look を管理します。
データフィルタを追加: 特定のユーザーがモデル内でアクセスできるデータをさらにフィルタリングします。

1. プロジェクトを作成

最初に必要なのはプロジェクトです。プロジェクトは 1 つ以上のモデルのコンテナです。すでにプロジェクトを設定している場合は、この手順をスキップできます。それ以外の場合は、Looker の [開発] セクションで [プロジェクト] を選択して、[LookML プロジェクト] ページに移動し、[新しい LookML プロジェクト] を選択して新しいプロジェクトを作成します。新しいプロジェクトの作成方法について詳しくは、新しい LookML プロジェクトの作成に関するドキュメントページをご覧ください。

[新しいプロジェクト] ページで、次の設定でプロジェクトを作成します。

[名前] セクションで、プロジェクトに名前を付けます。
[開始ポイント] セクションで、[データベススキーマからモデルを生成] を選択します。
[接続] プルダウンメニューで、データベース接続の名前を選択します。
この例では、[ビューの作成元] セクションで [すべてのテーブル] オプションを選択して、LookML 生成ツールでデータベース内の各テーブルのビューファイルを作成します。

新しいプロジェクトに必要な構成が完了したら、[プロジェクトを作成] を選択します。

プロジェクトを作成すると、プロジェクトの自動生成された LookML モデルが表示されます。この時点で [Git を構成する] ボタンを使用して、プロジェクトのバージョン管理を設定する必要があります。バージョン管理の設定に関する詳細な手順については、Git 接続の設定とテストに関するドキュメントページをご覧ください。

2. モデルを追加

データモデルは、データベースに対するカスタマイズ可能なポータルのようなものです。モデルごとに異なるデータをユーザーに公開できます。この例で、セールス担当者が必要としているデータはエンジニアチームとは異なるため、データベースから適切な情報を公開するために別のモデルを追加します。

LookML プロジェクトで、目的のモデル（finance、sales、product）という名前の新しい LookML モデルファイルを追加します。各モデルファイルで少なくとも 1 つの Explore を定義するようにしてください。これにより、モデルセットの作成時にモデルを選択できるようになります（定義しないと、選択に表示されません）。モデルファイルで explore パラメータを使用する方法については、モデルの概要とファイルの表示のドキュメントページをご覧ください。

モデルを追加したら、引き続き構成を行う必要があります。モデルを構成するには、[開発] セクションの [プロジェクト] ページに戻ります。ここには、「使用するには構成が必要」という赤いテキストが、各モデル名とともにインラインに表示されます。

各モデルの横にある [構成] を選択します。プロジェクト名が正しいことと、このモデルで使用できる接続を確認してから、保存します。

[モデルの構成] ページでは、モデル名、プロジェクト、モデルに対して許可されている接続を確認できます。

すべてのモデルが正しく構成されると、以前の赤色の構成の問題に関するメッセージは表示されなくなります。

Looker では、1 つのモデルに対する see_lookml 権限または develop 権限をユーザーに付与すると、そのプロジェクトのすべてのモデルに対する権限がユーザーに付与されます。そのため、LookML を表示または開発する権限を分割する場合は、個別のプロジェクトを作成する必要があります。それ以外の場合は、新しいモデルを作成します。モデル権限で、特定のユーザーのみが特定のデータに対してクエリを実行できます。

権限の詳細については、ロールに関するドキュメントをご覧ください。

3. モデルセットを作成

各部門のデータモデルが構成されたので、各部門に対応するモデルを、構築するモデルセットに追加します。新しいモデルセットを作成するには、[管理者] パネルの [ロール] ページに移動し、[新しいモデルセット] を選択します。新しいモデルセットの作成方法については、ロールのドキュメントページをご覧ください。

新しいモデルセットが作成されると、次のサンプルスクリーンショットのように、[ロール] ページの [モデルセット] セクションに表示されます。

財務、プロダクト、セールスのモデルは、モデルセットページの財務、プロダクト、セールスのモデルセットに対応しています。

4. 権限セットを作成

次に、作成したモデルセットを使用して権限セットを作成します。シナリオを設定するときに述べたように、組織図の 4 つの階層レベルに対応する 4 つの権限階層が必要です。上位の階層には、以下の階層の権限が含まれている必要があります。このシナリオでは、次のような権限セットを特定します。

CEO は管理者の権限セットを持つ。
VP には 制限付き管理者の権限セットが設定されている。
マネージャーにはダウンロードと共有の権限セットが設定されている。
標準の従業員には、表示と探索の権限セットがある。

新しい権限セットを作成するには、[管理者] パネルの [ロール] ページに移動し、[新しい権限セット] を選択します。権限階層ごとに、適切な権限を選択します。一般的に、権限セットはできる限り少なくする必要があります。各セットでは、この権限セットを持つユーザーに必要な権限のみを追加します。これは、一部のユーザーに複数の権限セットを提供し、各権限セットで何が許可されているのかを正確に把握するためです。ただし、ツリー構造のため、多くの場合、ある程度の重複が必要になります。

この例では、表示と探索の権限セットで、ユーザーがコンテンツを表示したり、質問したり、便利なタイルを保存したりできるようにします。そのため、コンテンツの閲覧に関連する権限（see_looks、see_user_dashboards など）、explore 権限、save_content 権限を付与します。ここで注目すべき例外は、デベロッパーだけを対象とした see_lookml と、SQL を理解し、データベース構造の表示が信頼できるユーザー用に予約される see_sql です。これらの権限はすべて access_data ブランチの下に厳密に存在します。see 権限は管理者権限であるため、ツリーの下部には付与されません。

ダウンロードと共有の権限セットでは、一般公開 Look（非 Looker ユーザーとの Look の共有を可能にする）のダウンロード、スケジュール設定、共有、作成に関連する権限、および see_schedules を追加します（スケジュールを作成できるため、管理パネルで表示できるようにするのが論理的です）。

表示と探索およびダウンロードと共有の両方の権限セットを構成するときに選択した唯一のフィールドは、access_data ブランチの下に追加された子の権限を選択するのに必要な親の権限です。従って、ダウンロードと共有の権限セットを持つユーザーは、表示と探索の権限セットも持つため、ダウンロードと共有の権限セットに see_lookml_dashboards、see_user_dashboards、explore などの権限を含める必要はありません。これらの権限は、ダウンロードと共有の権限セットに必要な子の権限を含まないためです。

最後に、制限付き管理者の権限セットでは、CEO が必要とする manage_models と sudo の権限を除く、ほとんどの管理者権限をツリーの下部に追加します。たとえば、次のようになります。

すべての操作が完了すると、権限セットに次の権限が含まれます。

管理者: 管理者の権限セットは、この例の CEO 用に予約されたものです。すべての権限が含まれます。
制限付き管理者: 制限付き管理者の権限セットには、create_prefetches、login_special_email、manage_homepage、manage_spaces、see_alerts、see_datagroups、see_logs、see_pdts、see_queries、see_users、update_datagroups の権限が含まれます。
ダウンロードと共有: ダウンロードと共有の権限セットには、access_data、create_public_looks、download_with_limit、download_without_limit、save_content、schedule_external_look_emails、schedule_look_emails、see_looks、see_schedules、send_outgoing_webhook、send_to_s3、send_to_sftp の権限が含まれます。
表示と探索: 表示と探索の権限セットには access_data、create_table_calculations、explore、save_content、see_drill_overlay、see_lookml_dashboards、see_looks、see_user_dashboards の権限が含まれます。

既存の権限セットに属する権限を表示するには、[ロール] 管理ページの [権限セット] セクションに移動します。

5. グループの作成

次に、グループを作成してユーザーをグループ化します。ここでは、標準の従業員と各部門のマネージャーの両方のグループを作成します。最終的に、これらのグループは後で作成する別のロールと一致します。バイスプレジデントは各自のグループに属し、CEO にはグループは必要ありません。完了すると、[グループ] ページに、次のグループと、Looker によって自動的に生成される対応するグループ ID が一覧表示されます。例:

ID	名前
1	All Users
3	財務
4	セールス
5	プロダクト
7	セールスマネージャー
8	プロダクトマネージャー
9	財務マネージャー
10	バイスプレジデント

作成したグループには、ユーザーを追加する必要があります。グループにユーザーを追加する方法については、グループのドキュメントページをご覧ください。

作成したグループにユーザーを追加するときは、権限がどのように構造化されているかによって、上位階層のグループが下位階層のグループに含まれることがあります。たとえば、財務グループにバイスプレジデントは必要ですが、セールスマネージャはプロダクトグループに不要です。これを効率的に対処する方法は、まず上位階層のグループ（バイスプレジデントなど）にユーザーを追加して、下位階層にグループとして追加できるようにします。

6. ロールを作成

モデルセット、権限セット、グループができたので、ロールを使用してこれらをすべてまとめることができます。すべてのロールに 1 つの権限セットと 1 つのモデルセットがあり、これらは 1 つ以上のグループを含めることができます。ロールにはモデルセットを含める必要があるため、ここでも標準の従業員と各部門のマネージャの両方のロールを作成します。

標準ロール: 標準ロールには、表示と探索の権限セットと、それに対応するモデルセットが含まれます。その部門の標準グループとマネージャーグループ、およびバイスプレジデントに標準ロールを割り当てます。たとえば、標準財務のロールを財務グループと財務マネージャーグループ、および財務担当バイスプレジデントに割り当てます。
マネージャーロール: マネージャーロールには、ダウンロードと共有の権限セットと、それに対応するモデルセットがあります。これらのロールは、対応する部門のマネージャーグループと部門のバイスプレジデントに割り当てる必要があります。
マネージャーロール: マネージャーロールには、ダウンロードと共有の権限セットと、それに対応するモデルセットがあります。これらのロールは、対応する部門のマネージャーグループと部門のバイスプレジデントに割り当てる必要があります。
バイスプレジデントロール: バイスプレジデントロールには、制限付き管理者の権限セットとすべてのモデルセットがあります。このロールはバイスプレジデント グループに割り当てられます。

7. コンテンツアクセスを編集

次に、各グループが独自の（そして自分だけの）コンテンツにアクセスできるよう、フォルダのアクセス権を整理します。この例のインスタンス内のフォルダのレイアウトは次のとおりです。レイアウトは、管理パネルの [コンテンツアクセス] ページに移動すると表示されます。

共有フォルダには、財務、プロダクト、セールスの各フォルダがあり、各部門で使用するフォルダが含まれています。

フォルダへのアクセス権は、階層継承のルールに従います。この仕組みの詳細については、アクセスレベルとアクセス制御と権限の管理に関するドキュメントをご覧ください。

フォルダアクセスのルールに従って、[共有] フォルダ内のすべてのユーザーに [表示] アクセス権を付与します。各グループがアクセスできるフォルダの上にあるツリーの親フォルダに対する [表示] アクセス権を各グループに付与します。このように、ツリーを走査する際に、グループにフォルダを表示させたくない場合、アクセス権を付与するときにそのグループを入れないようにします。

フォルダの表示をコントロールしたいフォルダで、グループにアクセスの管理、編集のアクセスレベルを付与することができます。この例では、CEO と場合にのみこれらの権限を付与して、その他のユーザーには、必要なフォルダに対する表示アクセス権のみがあるようにします。

8. ユーザー属性によるデータアクセス制限を追加する

このセクションでは、特定のユーザーが、アクセスできるモデルから特定の行またはデータ列にアクセスするのを防ぐ方法について説明します。CEO は、セールス担当者が個人の活動のデータを表示できるものの、他のセールス担当者の活動を表示できないようにしたい考えています。ただし、セールスマネージャーはすべてのセールス担当者の数字を表示できる必要があります。これを行うには、ユーザー属性と sql_always_where パラメータを使用します。

ユーザー属性の作成

まず、ユーザーから隠される access_level という名前の新しいユーザー属性を作成します。これにより、グループごとにアクセス階層を定義できます。ユーザー属性を作成するときに、次の値を設定します。

名前: access_level
ラベル: アクセスレベル
データ型: 文字列
ユーザーアクセス: 編集
値を非表示: ×

この例では、[デフォルト値を設定] チェックボックスはオフのままにします。

フィールドの作成中に、基本、プレミアム、フルの 3 つのアクセスレベルを構成します。これらのレベルを、それぞれ標準、マネージャー、バイスプレジデントグループに割り当てます。これは、同じセクションの [グループ値] タブで行います。詳しくは、ユーザー属性ドキュメントのユーザーグループへの値の割り当てのセクションをご覧ください。

これらのルールの順序は重要です。そのため、最も高いアクセス値をリストの一番上に配置し、下位のアクセス値を一番下に配置します。この動作の詳細については、ユーザー属性のドキュメントページをご覧ください。

ユーザー属性による行データのフィルタリング

すべてのセールス情報を含む Explore がすでに作成されているとします。Explore をクエリするユーザーのアクセスレベルを確認します。アクセスレベルが基本（すべての標準セールス担当者に付与）となっている場合は、常にユーザー名で Explore がフィルタリングされるため、各セールス担当者自身の行のみがアクセス可能です。アクセスレベルがプレミアムまたはフルの場合、クエリはフィルタリングされません。デフォルトの設定では、名前というユーザー属性があります。これは Looker ユーザーの名前です。Explore の LookML は次のようになります。

explore: sales_info {
  sql_always_where: {% if {{_user_attributes['access_level']}} == "Basic" %}
    ${sales_info.name} = "{{_user_attributes['name']}}"
    % endif %
  ;;
}

ユーザー属性による列データのフィルタリング

最後に、財務モデルに個人情報（PII）列がありますが、これらの列を一部のユーザーから隠したいと思います。これを行うには、作成したユーザー属性とともに、ユーザー属性のドキュメントページにある、Looker でデータベースレベルの権限を適用する手順を使用して、フルアクセスレベルを持つユーザーのみに、PII フィールドを表示できる権限を付与します。

これでデモは終了です。コンテンツとデータのアクセス制御の設定を完了し、すべてのユーザーが Looker を自由に閲覧できるようになりました。これにより、許可したコンテンツだけがユーザーに表示されるようになります。

ベスト プラクティス: フォルダを保護する コンテンツ アクセスのガイド