この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Lookerではトピック毎のベストプラクティスを個別にドキュメントやナレッジベースとしてまとめています。当エントリではその中から、実際のユースケースに即した形での『コンテンツアクセス制御』をLookerで実現するための手順を、順を追って説明した内容をご紹介したいと思います。
目次
はじめに
このエントリでは、Lookerインスタンスの管理者が、コンテンツへのアクセス制御を設定する手順について説明します。新しいプロジェクトの作成から始めて、モデル、モデルセット、権限セット、グループ、ロール、ユーザー属性といった要素について継続して実装していくプロセスを追って行きます。
主要なLookerの機能を理解するために、Lookerの諸機能を『家』及び『家の中の要素』の中の何に相当するかを当てはめてみると以下の様な形となります。
- プロジェクト(project)は『家』の様なものです。
- モデル(model)は、『特定のコンテンツで満たされた、家の部屋』です。
- モデルセット(model set)は、『部屋のグループ、または(ベッドルームやキッチンのような)単一の部屋』です。
- 許可セット(permission set)は、『アクティビティセット』であり『人々が部屋で出来ること(食事、遊び、睡眠)』を指定します。
- グループ(group)は、『共通の特性(大人、子供、ゲスト)を持つ人々を組み合わせる方法』です。
- 役割(role)は、『人々のグループに異なる部屋のセットで活動チェックリストを提供する方法』です。
- ユーザー属性(user attribute)は、『家の特別なアイテム(ティーポット、電動家具)を開くキー』です。
想定シナリオ
ここでは、『財務、販売、製品のチームを持つスタートアップ』を例に挙げて解説を進めていきます。
CEOは我々の唯一の管理者であり、各チームのVPが全てのチームのコンテンツにアクセス出来ることを除き、各チームが自分に関するコンテンツのみを表示出来ることを望んでおり、彼女は標準の従業員、マネージャー、及びVPに異なる機能アクセスを望んでいます。
- 標準的な従業員：自らのモデルでデータを表示・調査出来る必要がある
- マネージャー：標準的なアクセス権を持ち、コンテンツのダウンロード、及びスケジューリングが出来る必要がある
- VP：CEO専用で定められているの幾つかのものを除き、ほぼ全ての特権が利用出来る必要がある
彼女は、営業担当者が自分の活動のデータを表示出来るようにしたい一方で、別の営業担当者の個々の販売番号を表示出来ないようにしたいと考えています。但し、営業マネージャーは全ての営業担当者の番号を表示できる必要があります。そして、使用するモデルの中には、標準的な従業員に対して見せたくない(隠しておきたい)幾つかの金融に関する項目があります。
シナリオにおける組織図は以下の通りです：
このシナリオにおけるアクセス制御を実現するには、以下の手順に従ってLooker実装・設定作業を進めていきます。
- 1.プロジェクト(project)を作成
- プロジェクトは、データベース接続とデータモデル間の構造的なリンクとなります。
- 2.モデル(model)の追加
- どのデータをどのユーザーに公開するかを決定します。
- 3.モデルセット(model set)の作成
- 関連するモデルをグループ化します。
- 4.権限セット(permission set)の作成
- モデルセット内でユーザーが実行出来るアクションを明示的に定義します。
- 5.グループ(group)の作成
- 同様のユーザーをまとめます。
- 6.ロール(role)の作成
- モデルセット、権限セット、及びグループ間の接続を作成します。
- 7.コンテンツアクセス(Content Access)の編集
- ユーザーがフォルダを介して表示出来るダッシュボードとLookerを管理します。
- 8.データフィルター(Data Filters)の追加
- 特定のユーザーがモデル内でアクセス出来るデータを更にフィルタリングします。
ステップ別解説
1.プロジェクトの作成
Lookerではまずはじめに「プロジェクト(project)」が必要となります。プロジェクトは、1つ以上のモデルを格納するコンテナです。
Lookerインスタンスの試用または実装中に、プロジェクトが既に環境にセットアップされている事がありますが、その場合はこの手順をスキップする事が出来ます。それ以外の場合、このステップを実施する必要があります。
新しいプロジェクトを作成するには、[Develop]→[Manage LookML Projects]→[New LookML Project]と選択。プロジェクトに名前を付け、接続を指定して[Create Project]を選択します。
プロジェクトを作成すると、プロジェクトの自動生成LookMLモデルが表示されます。この時点で、プロジェクトのバージョン管理を設定するには画面左上の[Configure Git]を使って進めます。バージョン管理のセットアップの詳細な手順については以下をご参照ください。
2.モデルの追加
データモデルは、データベースへのカスタマイズ可能なポータルのようなものです。
各々のモデルは、異なるデータをユーザーに公開する場合があります。今回の例では、営業担当者がエンジニアとは異なるデータを必要とするため、データベースから適切な情報を各種ユーザーに公開するための個々のモデルを追加します。
プロジェクトのLookMLページにて、[Add Files](ファイルの追加)ボタンを押下し、目的となる各モデル(財務、販売、製品など)の名前を持つ、新しいLookMLモデルファイルを追加します。この際、各モデルファイルで少なくとも1つのエクスプローラを定義してください。この設定により、モデルセットを作成する際にモデルを選択出来るようになります。
ひとまずExploreの定義内容はこのままで問題ありません。下記のページでは、モデルファイルのexploreパラメーターの使用方法を確認できます。
モデルは正常に追加されましたが、まだ構成の設定を行う必要があります。モデルを構成するには、[Develop]→[Manage LookML Projects]を選択します。これにより、各モデル名と共に"Configuration Required for Use"(使用に必要な構成)という赤字テキストが表示されます。
次に、モデルの横にある[Configure]をクリックします。プロジェクト名と接続が正しいことを確認し、このモデル使用を許可＆保存します。すべてのモデルが正しく構成されると、赤字テキスト(エラーメッセージ)は表示されなくなります。
Lookerでは、ユーザーに1つのモデルのsee_lookmlまたはdevelopパーミッションを付与すると、そのプロジェクトの全てのモデルにそのパーミッションが付与される事に注意してください。従って、LookMLを表示または開発する権限を分割する場合は、個別のプロジェクトを作成する必要があります。それ以外の場合は新しいモデルを作成するだけでOKです。
特定のユーザーのみが特定のデータを照会出来るようにするには、モデルのアクセス許可で対応出来ます。
権限の詳細については、下記の「役割」に関するドキュメントをご参照ください。
3.モデルセットの作成
各部門のデータモデルが構成されました。次はこの各部門に対応するモデルを、構築するモデルセットに追加します。
新しいモデルセットを作成するには、[Admin] → [Roles]に移動し、[New Model Set]を選択します。最終的な以下の様な形となります。
4.権限セットの作成
次に、作成したモデルセットを使用して権限セット(permission sets)を作成します。
シナリオ作成時に言及したように、組織図の4つの階層レベルに対応する、「4層のアクセス許可」が必要です。上位層には以下の層のアクセス許可を含める必要があります。当シナリオでは、アクセス許可セットを以下のように構成します。
- 1.CEO = Admin
- 2.VP = Limited Admin
- 3.Manager = Download & Share
- 4.Standard = View & Explore
新しい権限セット(permission)を作成するには、[Admin] → [Roles]に移動し、[New Permission Set]を選択します。
それぞれのアクセス許可層に対して、適切な権限を設定します。
一般的に、権限セットは出来るだけ重複しないようにして、各セットにはこの権限セットを持つユーザーに対して与えたい特定の許可のみを追加します。これは、一部のユーザーに複数の権限セットを付与し、それぞれの権限セットが機能するのを正確に把握したいためです。ただし、ツリー構造を取るため、得てして幾つかの重複が発生してしまうことが良くあります。
この例では、ユーザーがコンテンツを表示・質問し、有用なタイルを保存出来るように、表示と探索を行う権限セットが必要となります。そのため、see_[content]、explore、及びsave_contentに関連付けられた権限セットを付与します。ここで注目すべき例外は、開発者のみに必要な(※場合による)see_lookmlと、SQLを理解し、DB構造を理解出来る人用に設けられているsee_sqlです。これらの権限は全て、厳密にaccess_dataブランチの下に存在します。ツリーの下部にある権限は管理権限であるため付与していません。
ダウンロードと共有の権限セットには、以下の権限を追加します。
- ダウンロード(downloading)
- スケジュール設定(scheduling)
- 共有(sharing)
- 公開Lookの作成(creating public looks) ※非LookerユーザーへのLook共有を許可
- see_schedules(スケジュールを作成できるため、管理パネルでスケジュールを表示することも可能)
以下スクリーンショットでは、両方のセットで選択されているフィールドはaccess_dataブランチの下に追加された、子のアクセス許可を選択するために必要な親のアクセス許可のみであることに注意。
最後に、制限付き管理権限セットでは、CEOが自分だけのために必要とするmanage_modelsとsudo特権を除き、殆どの管理権限をツリーの下部に追加します。内容的には以下の様になる感じです。
全ての設定が完了すると、権限セットはは以下の様な状態になります。
5.グループの作成
次のステップは、グループを作成し、ユーザーをバケット化することです。
各部門の"標準的な従業員"と"マネージャー"の両方のグループを作成します。これらは、後に作成する様々な役割(Role)に最終的に一致させるためです。VPはそれぞれのグループに所属し、またCEOはグループを必要としません。完了するとグループのページは以下のようになります。
ユーザーをグループに追加
グループを作成したら、そのグループにユーザーを追加します。各グループの横にある[Edit]ボタンをクリックして、各グループに適切なユーザーを追加します。
権限を構造化するために、上位グループが下位グループに含まれる事があります。例えば、FinanceグループのVPは必要ですが、ProductグループのSales Managerは必要ありません。これにアプローチするための効率的な方法は、ユーザーを上位層グループ(VPなど)に追加することから始めることです。これにより、ユーザーをグループとして下位層に追加出来ます。
6.ロールの作成
モデルセット、権限セット、及びグループが用意出来ました。これらを「ロール」(role)を使用して全てまとめることが出来ます。
全てのロールには、単一の権限セットと単一のモデルセットがあり、1つ以上のグループを含める事が出来ます。ロールにはモデルセットが含まれている必要があるため、各部門の標準従業員とマネージャーの両方のロールを再度作成します。
- 標準(Standard)のロールには、表示(View)と探索(Explore)の権限セット、及び対応するモデルセットを含み、その部門とVPのStandardグループ、Managerグループを選択します。
- マネージャー(Manager)のロールには、ダウンロード(Download)と共有(Share)の権限セットに加えて、対応するモデルセットがあります。その部門とVPのManagerグループが必要です。
- VPには、制限された管理者権限セットに加え、全てのモデルセット、VPグループが含まれます。
設定後の状態は以下の通り。
そしてグループは以下の通り。
7.コンテンツアクセスの編集
次のステップは、フォルダ単位のアクセス許可を整理することです。各グループは、独自の(そして自身の)コンテンツにのみアクセス出来ます。各フォルダにアクセスするために必要なフォルダのレイアウトとアクセス許可レベルは以下の通りです。
フォルダへのアクセスは"階層継承"のルールに従います。どの様に機能するか、という部分の詳細については、下記ドキュメントをご参照ください。
フォルダアクセスのルールに従い、共有フォルダの全てのユーザーに「表示アクセス」を許可します。
各グループに、グループがアクセス出来るフォルダの上にあるツリー内の、親フォルダへの表示アクセス権を与えます。 この方法では、ツリーを下に辿り、グループにフォルダを表示させたくない場合、アクセスを許可する際にそのグループを含めません。
そのフォルダを表示するユーザーを制御するフォルダ内のグループに、アクセスの管理、編集のアクセスレベルを与えることが出来ます。この例では、CEOとVPにのみ、これらの権限を付与しています。他の全てのユーザーは、必要なフォルダへの表示アクセスのみを持ちます。
8.ユーザー属性を使用してデータアクセス制限を追加
最終セクションとなるこの部分では、特定のユーザーがアクセス出来るモデルの、特定の行または列のデータにアクセス出来ないようにする方法を示します。
我々のCEOは「営業担当者が自分の個人的な活動データを閲覧出来るようにしたい」が「他の人は閲覧できないようにしたい」と言っていました。また「営業マネージャーは全ての営業担当者の番号を表示できる必要がある」とも言っていました。これらを実現するには、「ユーザー属性」とsql_always_whereパラメータを活用します。
ユーザー属性(User Attributes)の作成
まずはじめに、ユーザーからは見えないaccess_levelという新しいユーザー属性を作成します。
これにより、様々なグループのアクセス層を定義出来ます(ユーザー属性の作成の詳細については下記ドキュメントをご参照ください)。
フィールドの作成は以下の様な感じです。
フィールドの作成で「Basic」「Premium」「Full」の3つのアクセスレベルを構成します。これらのレベルをそれぞれ「標準」「マネージャー」「VPグループ」に割り当てます。これは、同じセクションの[Group Values]タブで行われ、以下の様な内容となります。
これらのルールの順序は重要です。リストの一番上に最高のアクセス値を配置し、下方に低いアクセス値を上書きするということに注意してください。この部分の動作については下記ドキュメントにて詳しく言及しています。
ユーザー属性を使用した行データのフィルタリング
全ての販売情報が組み込まれたExploreが、既に構築されていることを想像します。
Exploreを照会するユーザーのアクセスレベルを確認し、内容に応じて以下のように挙動を制御可能です。
- アクセスレベルが「Basic」(全ての標準営業担当者に与えられている)の場合、ユーザー名で常にExploreをフィルタリングするため、各営業担当者の行のみがアクセス出来ます。
- アクセスレベルが「Basic」以外(「Premium」または「Full」)の場合、クエリはフィルタリングされません。デフォルトでは、Nameというユーザー属性があります。これは(当然のことですが)Lookerユーザーの名前です。ExploreのLookMLは以下のようになります。
ユーザー属性を使用した列データのフィルタリング
最後に、「財務」モデルには一部のユーザーからも隠したいPII(personally identifiable information:個人を特定できる情報)の列があります。これを実現するには、特定ユーザーの機密フィールドのマスキングに関する下記ドキュメントを参考に、作成したユーザー属性を使用して、フルアクセスレベルのユーザーのみがPIIフィールドを表示出来るようにします。
以上で当エントリの手順は完了となります。
これらの設定手順を実施することにより、コンテンツとデータアクセスコントロールの設定が完了し、全てのユーザーがLookerを自由に探索出来、アクセスを許可したコンテンツのみを見ることが出来るようになります。
まとめ
というわけで「コンテンツアクセス」に関するユースケース実践手順のご紹介でした。
若干の駆け足感はありましたが、Lookerではきめ細やかなアクセス制御の手段がそれぞれ用意されているので、実際のユースケースに応じた制御も柔軟に対応が可能です。逆に細かいところも色々出来てしまうので、Lookerで実装する前に予め設計段階で詳細を確認・検討しておくとよりスムーズ且つ的確に目的を達成出来ると思います。
当ブログでは、Lookerの様々なベスト・プラクティスを下記シリーズにてまとめています。この他にもまだまだ有用なコンテンツがありますので、引き続きご紹介して行きたいと思います！