この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Lookerでは局面や状況に応じて、様々な「アクセス制御」や「権限管理」の方法が提供されています。当エントリでは、そんなトピックについて、どういった形で制御や管理が可能なのかについて見ていきたいと思います。
目次
概要
Looker管理者は以下のポイントを検討し・設定を行う事でユーザーやユーザーの所属するグループがLooker内で表示及び実行出来ることを制御出来ます。
コンテンツアクセス
ユーザーまたはユーザーが所属するグループが「フォルダ」を表示出来るか、管理出来るかどうかを制御します。フォルダを表示出来るユーザーは、以下の操作が可能です。
- フォルダに移動
- フォルダ内のダッシュボード＆ルックの一覧を表示
フォルダを管理出来るユーザーは、以下の操作が可能です。
- フォルダ内コンテンツの操作(ダッシュボードとルックの複製、移動、削除、名前変更)
- フォルダ自体の管理(フォルダの名前変更、移動、削除)
- 他のユーザーとグループにフォルダへのアクセスを許可
コンテンツアクセスは、[Admin]タブ上でLooker管理者によって、また許可されている場合であれば[Browse]ページで個別ユーザーによって管理されます。
(参考)
- Controlling User Content Access - Access Control and Permission Management
- Organizing and Managing Access to Content
- Managing Access Levels for a Folder - Organizing and Managing Access to Content
データアクセス
ユーザーが表示出来るデータを制御します。データアクセスについては、主にLookerのロールを構成する要素の『モデルセット』を介して管理されます。
ロールは、グループとユーザーに適用されます。
クエリに自動フィルタがあるかのように、『アクセスフィルタ』の仕組みを使ってモデル内のデータアクセスを更に制限し、表示出来るデータの行を制限出来ます。
アクセス許可(access_grant)を使って、特定のエクスプローラ(Explore)、結合(Join)、ビュー(View)、またはフィールドへのアクセスを制限することも可能です。
機能アクセス
ユーザーがLookerで実行出来る「アクション」の種類を制御します。これには以下のものなども含まれます。
- データや保存されたコンテンツの表示
- LookMLモデルの変更
- Lookerの管理
機能アクセスは、Lookerのロールを構成する要素の権限セット(Permission Set)によって管理されます。これらアクセス許可の一部は、「データ送信における全てのスケジュールを表示出来る」などのようなLookerインスタンス全体に適用されているものもありますが、「このモデルに基づいたユーザー定義ダッシュボードを表示出来る」のように、ほとんどの権限は特定のモデルセットに適用されます。
ユーザー及びグループに対する「コンテンツアクセス」「データアクセス」「機能アクセス」を組み合わせて、何が出来て何が表示出来るかをLookerで指定します。
ユーザーとグループ
Lookerでは、ユーザーの考え方として「個々のユーザー」と「グループ所属のユーザー」の2つの概念があります。Lookerの管理パネル上では、ユーザーはの[Users]ページで、グループは[Groups]ページで管理されます。
ベストプラクティスとしては、ロールはグループに割り当てることです。これにより、多数のユーザーへのコントロールのロール割当という、面倒な作業を避けることが出来ます。
通常、ユーザーに許可するアクティビティの組み合わせについては、そのユーザーを1つ以上のグループに所属させることで調整可能ですが、その組み合わせでも十分でないという常用になった場合は「1人のユーザーのみのグループを作成する」ことを検討しましょう。こうしておくことで、今後そのグループを多くのユーザーに展開・拡張出来るようになります。
アクセスフィルタ(access filters)については、ユーザー属性をグループに割り当てる事が可能です。ユーザー属性の使用を検討してください。
ユーザーコンテンツアクセスの制御
Lookerの『フォルダ』機能を使うと、ダッシュボードやLook(ダッシュボードを構成する1つのビュー(View)のようなもの)のセットを整理出来ます。フォルダは他のフォルダを含めることも可能で、組織のネスト化された階層の実現を容易にします。この『フォルダ』を使って、アクセスレベルを設定し、どのユーザーがフォルダ配下のコンテンツを編集出来るか、フォルダ内のコンテンツを表示し、フォルダ設定を変更出来るかを決めることが出来ます。
- ユーザーがフォルダを表示し、フォルダ内に表示されているコンテンツのリストを表示するためには、少なくとも『フォルダへの表示』レベルのアクセス権限が必要です。
- ユーザーがコンテンツのコピーや移動、フォルダの名称変更や移動、及び同様のアクションを含むフォルダを整理出来るようになるためには、『フォルダのアクセス管理・編集』レベルのアクセス権限が必要です。
上記以外のケースでは、『フォルダ』は特にユーザーの操作を制御するものはありません。その他詳細については当エントリの機能アクセスとデータアクセスの制御の項をご参照ください。
Lookerの[Browse]セクションからフォルダのアクセスレベルを調整する手順については、下記ドキュメントをご参照ください。
Looker管理者であれば、Lookerの[Contents Access]ページから全てのグループとユーザーのフォルダアクセスレベルを確認・調整することも出来ます。インスタンス全体のアクセスレベル設計に関する詳細については、下記ドキュメントをご参照ください。
コンテンツアクセスは機能アクセスとは別に管理されますが、ユーザーに割り当てられたロールはフォルダにリストされたLookとダッシュボードを表示するか、Lookまたはダッシュボードを表示するか、フォルダを管理出来るかどうか、というところに影響します。『コンテンツアクセスと権限がどのように作用しているか』の項では、機能アクセスがコンテンツアクセスにどのように影響するかについて解説します。
機能アクセスとデータアクセスの制御
Lookerで機能アクセス及びデータアクセスを制御するには、通常であればユーザーの所属する「グループ」を作成し、そのグループにロールを割り当てます(※この手法がベストプラクティスです)。ロールは、一連の権限を対象となるLookMLモデルと結び付けます。モデル自体は、使用可能なフィールドとデータを定義します。
アクセスフィルタを使って、特定のユーザーに特定のデータ制限を適用する事が出来ます。
また、プロジェクトを使用することにより、特定のデータベースに基づいてモデルを操作するLooker開発者を制限することが出来ます。
アクセス許可(access grants)を作成することにより、特定のエクスプローラ(Explore)、結合(Join)、ビュー(View)またはフィールドへのアクセスを制御することが出来ます。また、アクセス許可(access grants)は特定のユーザー属性値が割り当てられているユーザーのみにアクセスを制 限することも可能です。
コンテンツアクセス制御について、「やりたいこと」と「基本的な手順」は以下のように分類・整理出来ます。
| やりたいこと | 基本的な手順 |
|---|---|
| ・ユーザーが実行出来るアクションを制御する | ・適切な権限を持つ許可セット(Permission Set)を作成し、その許可セットを持つロールにグループまたはユーザーを割り当てる |
| ・ユーザーがアクセス出来るフィールドを制御する | ・適切なフィールドを作成してモデルを作成、そのモデルを使用出来るロールにグループまたはユーザーを割り当てる |
| ・ユーザーがアクセス出来るデータを制御する | ・適切なデータ制限を使ってモデルを作成し、そのモデルを使ったロールにグループまたはユーザーを割り当てる ・アクセスフィルタ(access filters)を使って、ユーザーを適切なデータに制限する ・ユーザー属性(user attributes)を使って異なるデータベース資格情報をグループまたはユーザーに提供する ・ユーザー属性をアクセス許可(access grants)と共に使い、特定のエクスプローラ(Explore)、結合(Join)、ビュー(View)、またはフィールドへのアクセスを制限する |
| ・Looker開発者がアクセス出来るデータベース接続を制御する | ・適切な接続を使ってプロジェクトを作成し、プロジェクトを一連のモデルに関連付けてから、グループまたはユーザーをそれらのモデルのロールに割り当てる |
機能へのアクセス制限は、コンテンツへのアクセスにも影響します。データアクセス及び機能アクセスがコンテンツアクセスに与える影響の詳細については『コンテンツアクセスと権限がどのように作用しているか』の項をご参照ください。
覚えておいた方が良い「ビルディングブロック」の使い方
ロール(Roles)
権限(Permission)は、1つの権限セット(Permission Set)と1つのモデルセット(Model Set)の組み合わせで成り立っています。権限セットで『出来ること』を、モデルセットで『(出来ることの)適用するLookMLモデル』を定義します。
作成したロールはユーザーまたはグループに割り当てます。複数割り当てた場合は、それら全てがまとめて継承されます。権限についてはLookerインスタンス全体に及ぶものと、任意のモデルにのみ適用されるものが存在します。詳細については下記ドキュメントをご参照ください。
プロジェクト(Projects)
プロジェクトを使うことで、データベース接続をどのモデルで使うかを制御し、Looker開発者がモデル作成時に操作できるデータセットを制御出来るようになります。
プロジェクトを通じて定義された制限は、Looker SQL Runnerにも適用されます。(開発者がSQL Runnerを使用し、禁止されたデータベースにアクセスしようとしても出来ません)
ユーザー属性(User Attributes)
ユーザー属性を使うと、グループやユーザーに任意の値を設定する事が出来ます。Lookerの様々な局面で、各ユーザーのエクスペリエンス(体験)をカスタマイズするのに利用出来ます。
ユーザーのアクセス制御の1つの活用方法として、データベース資格情報をパラメータ化し、各ユーザー固有のものとするものがあります。データベースに対して様々なアクセスを行う、複数のユーザーがいる場合に有効です。詳細については以下ドキュメントをご参照ください。
Database Connections / Where Can User Attributes Be Used?- User Attributes
また、別の活用方法としては『アクセスフィルタ』があります。アクセスフィルタを使うと、1つ以上のユーザー属性をデータフィルタとして利用出来ます。各ユーザーに会社名を割り当て、表示されるコンテンツをその会社名でフィルタリングすることが出来ます。適用方法の詳細については、下記ドキュメントをご参照ください。
ユーザー属性で『アクセス許可』を制御することも可能です。
- アクセス許可でユーザー属性を指定し、そのユーザー属性に"許容値"を定義して、エクスプローラ(Explore)、結合(Join)、ビュー(View)、フィールドへのアクセスを制御する事が出来ます。
- 次に、エクスプローラ(Explore)、結合(Join)、ビュー(View)、フィールドレベルでrequired_access_grantsパラメータを使用し、LookML構造へのアクセスを許可されたユーザー属性値を持つユーザーのみに制限します。
- 「給与(salary)」のディメンションへのアクセスを、ユーザー属性の「部門」に"payroll"を持つユーザーのみに制限する、というような制御が可能になります。
- 詳細については下記ドキュメントをご参照ください。
ビルディングブロック 活用実践
Lookeｒのドキュメントでは、上記「ビルディングブロック」の実践例として以下のケースを紹介しています。これらについてはエントリを改めて、それぞれ実践してみた記録を紹介していきたいと思います。
- 機能アクセス制御
- Lookerフィールドに対するユーザーアクセス制御
- データに対するユーザーアクセス制御
- データベース接続に対する開発者アクセス制御
"コンテンツアクセス"と"権限"がどのように作用しているか
コンテンツアクセスについては、以下2つの方法で管理が行えます。
- [Browse]タブにてユーザーが管理
- [Admin]タブの[Contents Access]ページでLooker管理者が管理
ロールがユーザーに割り当てられると、アクセス出来る「機能」と「データアクセス」の範囲が決まります。これは、フォルダ内で出来ること、及びLookとダッシュボードを表示出来るかどうかというところにも影響します。
Look及びダッシュボードのデータを閲覧
Lookまたはダッシュボードのデータを表示するには、ユーザーの権限として少なくとも「コンテンツが保存されているフォルダへの表示アクセス権」を持っている必要があります。
また、ユーザーがLookを選択、データの内容を表示するには、access_data及びsee_looks権限が必要となります。同様に、ダッシュボードを選択、データの内容を表示するにはaccess_data及びsee_user_dashboards権限が必要です。
そして、Lookまたはダッシュボードタイルでデータを表示するには、ユーザーが対象となるデータにアクセス出来る必要があります。
以下操作についてはデータアクセスは発生しません。
- ユーザーがフォルダにリストされたLookを表示してLookにナビゲート出来る場合でも、Lookのクエリは実行されず、Lookのデータは表示されません。
- ユーザーがフォルダにリストされたダッシュボードを表示し、ダッシュボードに移動出来る場合であっても、ユーザーがアクセス出来ないタイルは「空白」で表示されます。また複数のモデルから作成されたタイルを持つもダッシュボードの場合、ユーザーはアクセス出来るモデルに関連漬けられたタイルのみを表示し、そうでないモデルのタイルは「空白」で表示されます。
フォルダとLookとダッシュボードの一覧を閲覧
ユーザーはそのフォルダを表示し、フォルダ内に保存されているコンテンツの一覧を表示出来るようにするために、少なくとも「フォルダへの表示アクセス」の権限が必要です。
また、少なくともsee_looks権限を持つユーザーには、フォルダ内のLookのタイトルは表示出来ます。同様に、少なくともsee_user_dashboards権限を持っているユーザーには、フォルダ内のダッシュボードのタイルが表示されます。ですがこれはLookまたはダッシュボードのデータを表示出来る、という事にはなりません。
access_data権限を持っているが、see_looksもsee_user_dashboardsも持っていない場合は、ユーザーはフォルダやコンテンツを見ることは出来ません。
フォルダを編集
ユーザーはフォルダを整理出来るように、そのフォルダに対するアクセスの管理、編集権限を持っている必要があります。
これには、以下のアクションも含まれます。
- コンテンツの複製と移動
- フォルダの名前変更と移動
- 同様のアクションを含む、フォルダの整理、アクセスの編集、フォルダのアクセス
また、ユーザーにはフォルダを作成、編集、移動、及び削除を行うためのmanage_spaces権限も必要です。
「ユーザー権限」に関するインフラを活用する
LDAPやSAML、またはOpenID Connectのインフラが既に設定されている場合は、そのシステムを使って、ユーザーログインに関する部分を管理出来ます。それぞれのセットアップ手順については以下のドキュメントをそれぞれご確認ください。
これらのサービスを活用してグループを構成した場合、Looker内でそれらのグループを使用することが出来ますが、幾つか留意すべき点があります。
- 作成したグループは全てLooker内に転送され、[Groups]ページに表示されます。LDAP、SAML、OpenID Connectグループ毎に1つのLookerグループが作成され、Lookerグループ名はLDAP、SAML、またはOpenID Connectのグループ名をミラーリングします。
- これらのLookerグループを使用して、フォルダのアクセス制御とユーザー属性をグループのメンバーに割り当てる事が出来ます。
- 手動で作成したグループのように、Lookerグループを使用してロールを構成することは出来ません。代わりに、セットアップのプロセス中にLDAP、SAML、またはOpenID ConnectグループをLookerロールにマップし、LDAP、SAML、またはOpenID Connectセットアップページから割り当てられたロールのみを変更できます。この制限が無いと、グループからロールへのマッピングは、LDAP、SAML、OpenID Connectスキームにでの目的の機能から逸脱してしまう可能性があります。
更に、LDAPを使用してユーザー固有のデータベース接続をLookerクエリに適用することも出来ます。
まとめ
という訳で、Lookerにおける「アクセス制御」と「権限管理」の内容のご紹介でした。Lookerでは色々な切り口での権限設定が行えるので、必要な設計を踏まえた上で活用していきたいところですね。
24
