Looker 22.16 のドキュメントを表示しています。最新のドキュメントはこちらをご覧ください。

アクセス制御と権限の管理

Looker 管理者は、次のアクセスを指定することで、ユーザーまたはユーザーグループが Looker で表示および実行できることを管理できます。

コンテンツアクセス: ユーザーまたはユーザーグループがフォルダを表示する、またはフォルダを管理できるかどうかを制御します。フォルダを表示できるユーザーは、そのフォルダに移動し、フォルダ内のダッシュボードと Look のリストを閲覧できます。フォルダの管理権限を持つユーザーは、フォルダのコンテンツの操作（ダッシュボードと Look のコピー、移動、削除、名前変更）、フォルダ自体の整理（フォルダの名前変更、移動、削除）を行ったり、他のユーザーやグループにフォルダへのアクセスを許可したりできます。コンテンツアクセスは、[管理] パネルで Looker 管理者が管理するか、フォルダ内の個々のユーザーが許可します。
データアクセス: ユーザーに表示を許可するデータを制御します。データアクセスは主に Looker のロールの半分を構成するモデルセットを介して管理されます。これらのロールは、ユーザーとグループに適用されます。アクセスフィルタを使用してモデル内でデータアクセスをさらに制限し、クエリに自動フィルタがかかっているかのうように、データの行を制限できます。アクセス許可を使用して、特定の Explore、結合、ビュー、フィールドへのアクセスを制限することもできます。
機能アクセス: Looker でユーザーが行える操作を制御します。これには、データや保存済みコンテンツの表示、LookML モデルの変更、Looker の管理などが含まれます。機能へのアクセスは、Looker のロールの残り半分を構成する権限セットによって管理されます。これらの権限の一部は、データ送信のすべてのスケジュールを表示できるなど、Looker インスタンス全体に適用されます。ほとんどの権限は、特定のモデルセットに適用されます。たとえば、それらのモデルに基づいてユーザー定義のダッシュボードを表示できます。

ユーザーとグループのデータアクセス、機能アクセス、コンテンツアクセスを組み合わせて、Looker でユーザーができることと表示する情報を指定します。

ユーザーとグループ

Looker には、個別ユーザーとユーザーグループの両方が存在します。ユーザーは Looker の [管理] パネルの [ユーザー] ページで管理されますが、グループは Looker の [管理] パネルの [グループ] ページで管理されます。

グループを使用すると、ユーザーごとに個別のコントロールの割り当て、調整、削除を行う手間を省くことができます。一般的に、ユーザーを 1 つ以上のグループに所属させることで、ユーザーに許可するアクティビティの組み合わせを調整できます。グループの組み合わせが不十分な場合は、ユーザーが 1 人だけのグループを作成することをおすすめします。そうすることで、今後そのグループをさらに多くのユーザーに拡大できます。アクセスフィルタの場合は、ユーザー属性の使用を検討してください。ユーザー属性はグループに割り当てることができます。

ユーザーコンテンツへのアクセスの制御

Looker フォルダを使用すると、ダッシュボードと Look のセットを整理できます。これらにはフォルダも含めることもできるため、組織のネストされた階層を管理できます。

フォルダにより、フォルダのコンテンツ（Look やダッシュボードなど）の編集、フォルダのコンテンツの表示、設定の変更を行えるユーザーを決定するアクセスレベルを設定できます。

フォルダを表示し、そのフォルダ内に保存されているコンテンツのリストを表示するには、少なくとも View アクセスレベルが必要です。
コンテンツのコピーと移動、フォルダの名前の変更と移動などの、フォルダの管理には、Manage Access, Edit アクセスレベルが必要です。

フォルダによって、Looker プラットフォームでユーザーが実行可能なことや、独自コンテンツの構築のために使用できるデータは制御されません。そのアクセスレベルを管理するには、このページの機能とデータアクセスの制御をご覧ください。

Looker でコンテンツをブラウジングしているユーザーのフォルダのアクセスレベルを調整する手順については、コンテンツへのアクセスの整理と管理に関するドキュメントをご覧ください。Looker 管理者は、Looker の [Content Access] ページで、すべてのグループとユーザーのフォルダのアクセスレベルを調整することもできます。インスタンス全体のアクセスレベル設計については、アクセスレベルのシステムの設計と構成に関するドキュメントをご覧ください。

コンテンツアクセスは機能アクセスとは別に管理されますが、ユーザーに割り当てられたロールは、ユーザーが Look とダッシュボードをフォルダに一覧表示したり、Look またはダッシュボードを表示したり、フォルダを管理したりできるかどうかに影響します。機能のアクセス権がコンテンツへのアクセスに及ぼす影響については、後述で詳しく説明します。

機能とデータアクセスの制御

Looker の機能とデータアクセスを制御するには、通常、ユーザーグループ（省略可能ですが、推奨）を作成し、そのグループをロールに割り当てます。ロールは、一連の権限を LookML モデルのセットに結び付けます。使用可能なフィールドやデータはモデル自体によって定義されます。

アクセスフィルタを使用すると、特定のユーザーにデータ制限を適用できます。Looker プロジェクトでは、プロジェクトを使用して特定のデータベースに基づくモデルのみを使用できます。

アクセス許可を作成することで、特定の Explore、結合、ビュー、フィールドへのアクセスを制御することもできます。アクセス許可は、特定のユーザー属性値が割り当てられたユーザーのみにアクセスを制限します。

目的	これらは、基本的な手順です。
ユーザーが実行できる操作を制御する	適切な権限を持つ権限セットを作成し、その権限セットを持つグループまたはユーザーをロールに割り当てる
ユーザーがアクセスできるフィールドを制御する	適切なフィールドを使用してモデルを作成し、そのモデルを使用してグループまたはユーザーをロールに割り当てる
ユーザーがアクセスできるデータを管理する	適切なデータ制限を使用してモデルを作成し、そのモデルを使用してグループまたはユーザーをロールに割り当てる - または - アクセスフィルタを使用してユーザーを適切なデータに制限します - または - ユーザー属性を使用して、グループやユーザーに異なるデータベース認証情報を提供します - または - アクセス権のあるユーザー属性を使用して、特定の Explore へのアクセス、結合を制限する。
Looker デベロッパーがアクセスできるデータベース接続を制御する	適切な接続を使用してプロジェクトを作成し、プロジェクトを一連のモデルに関連付けてから、それらのモデルを使用してグループまたはユーザーをロールに割り当てる

機能へのアクセスはコンテンツアクセスにも影響することがあります。データアクセスと機能アクセスがコンテンツアクセスに与える影響について詳しくは、以下のセクションをご覧ください。

お客様に理解していただく必要がある構成要素

ロール

ロールは、1 つの権限セットと 1 つのモデルセットを組み合わせたものです。権限セットはロールが実行できる操作を定義し、モデルセットはロールが表示できる LookML モデルを定義します。

ロールを作成すると、個々のユーザーまたはユーザーグループをそのロールに割り当てることができます。個別のロールをユーザーに割り当てたり、ユーザーが属するグループに他のロールを追加したりすると、そのロールに含まれるすべてのロールが継承されます。

権限の中には、Looker インスタンス全体に関連するものと、同じロール内のモデルだけに適用されるものがあります。詳細については、ロールに関するドキュメントページをご覧ください。

プロジェクト

プロジェクトを使用すると、どのデータベース接続をどのモデルで使用できるかを制限できます。これにより、Looker のデベロッパーがモデルの作成時に操作できるデータセットを制御できます。

プロジェクトによって定義されたこの制限は、Looker SQL Runner にも適用されるため、デベロッパーは SQL SQL Runner を使用して、禁止されているデータベース接続にアクセスできません。

ユーザー属性

ユーザー属性を使用すると、ユーザーのグループや個々のユーザーに任意の値を割り当てることができます。これらの値は、Looker のさまざまな部分への入力として使用され、各ユーザーのエクスペリエンスをカスタマイズします。

ユーザー属性によってアクセスを制御する方法の一つは、各ユーザーに固有なデータベース認証情報をパラメータ化することです。これは、データベースに異なるデータアクセスを持つユーザーが複数いる場合にのみ有効です。詳しくは、ユーザー属性に関するドキュメントページをご覧ください。

ユーザー属性がアクセスフィルタの一部として制御することもできます。アクセスフィルタを使用すると、1 つ以上のユーザー属性をデータフィルタとして使用できます。たとえば、各ユーザーに会社名を割り当て、そのユーザーに表示されるすべてのコンテンツがその名前でフィルタされるようにします。アクセスフィルタを適用する方法については、ユーザー属性に関するドキュメントページと access_filter パラメータに関するドキュメントページをご覧ください。

ユーザー属性はアクセス許可も制御します。アクセス許可は、ユーザー属性を指定し、そのユーザー属性に許容される値を定義して、Explore、結合、ビュー、フィールドへのアクセス権を付与します。その後、Explore、join、view、field レベルで required_access_grants パラメータを使用し、許可されたユーザー属性値を持つユーザーだけに LookML 構造へのアクセスを制限します。たとえば、アクセス許可を使用して、department のユーザー属性値 payroll を持つユーザーにのみ salary ディメンションへのアクセスを制限できます。アクセス許可を定義する方法については、access_grant パラメータのドキュメントページをご覧ください。

構成要素の使用

機能アクセスの制御

権限は、ユーザーやグループが実行できるアクティビティの種類を制御します。ユーザーが権限を取得する手順は次のとおりです。

おすすめの方法は、権限セットを持つユーザーの 1 つ以上のユーザーグループを特定して、必要に応じてグループを作成することです。必要に応じて、個々のユーザーに権限を付与することもできます。
適切な権限を含む権限セットを作成します。
割り当てる権限の一部がモデル固有の場合は、既存のモデルセットを作成するか、既存のモデルセットを特定します。
権限セットと、必要に応じてモデルセットを組み合わせたロールを作成します。
[ロール] ページからロールを割り当てます。ロールを作成した後、[ユーザー] ページでユーザーにロールを割り当てることもできます。

1 人のユーザーまたはグループに複数のロールを割り当てることができます。この場合、ユーザーは自身のロールに含まれているすべての権限を持ちます。例:

Role1 を使用すると、Model1 のダッシュボードを表示できます。
Role2 を使用すると、ダッシュボードを表示して Model2 を試すことができます。

両方のロールを同じユーザーグループに割り当てると、Model1 と Model2 の両方のダッシュボードを表示できますが、Model2 でのみ探索できます。

Looker フィールドへのユーザーアクセスの制御

ユーザーが使用できるフィールドは、ユーザーがアクセスできるモデルによって決まります。ユーザーは次の方法でフィールドにアクセスできます。

ユーザーがアクセスできる項目のみを含む LookML モデル（または LookML モデルの組み合わせ）を作成する。
これらのモデルを含むモデルセットを作成して、ロールに割り当てます。この操作は、Looker の [ロール] ページで行います。
ユーザーグループ（通常は Google が推奨）を操作するには、Looker の [グループ] ページでグループを作成します。次に、[ロール] ページでそのグループを適切なロールに割り当てます。
個々のユーザーを操作するには、[ユーザー] ページまたは [ロール] ページからそれらのユーザーにロールを割り当てます。

1 人のユーザーまたはグループに複数のロールを割り当てることができます。ユーザーは自分のロールのモデルをすべて操作できます。

フィールドの hidden パラメータは、フィールドアクセスを制御するためのものではなく、ユーザーのためによりクリーンなエクスペリエンスを提供するように設計されています。hidden パラメータは、フィールドピッカーからフィールドを非表示にしますが、ユーザーがそのフィールドを使用するのを防ぐことはできません。そのフィールドを使用するリンクが送信されると、Looker 内の他の場所にはフィールドが表示されます。

ユーザーによるデータへのアクセスの制御

ユーザーのデータへのアクセスを制御する方法は、ユースケースに応じていくつかあります。

ユーザーが特定の列のデータを表示できないようにするには、前述のように、アクセスできるフィールドを制御します。ユーザーが開発可能で、かつ SQL Runner を使用できない限り、ユーザーはアクセスできるフィールドによって制約を受けます。
特定の行のデータを表示できないようにするには、access_filter パラメータのドキュメントページで説明されているように、アクセスフィルタフィールドを適用します。
特定の Explore、結合、ビュー、フィールドへのアクセスを制限するには、許可されたユーザー属性値が割り当てられているユーザーにのみアクセスを許可するアクセス許可を作成します（access_grant パラメータのドキュメントページを参照）。
Looker ユーザーがクエリを実行する際に、データベースチームがデータアクセスを制限するように設定したデータベース ユーザーに対してクエリを実行するには、ユーザー属性を使用します。データベース接続をパラメータ化することで、特定のユーザーグループや個々のユーザーに特定のデータベース認証情報でクエリを実行させることができます。ユーザーを適切な Looker フィールドに限定することも検討してください。Looker ユーザーがデータベースユーザーがアクセスできないフィールドをクエリしようとすると、エラーが発生します。

hidden フィールドパラメータはフィールドアクセスの制御を目的としていないのと同様に、Explore 用の hidden パラメータによってすべてのユーザーが Explore を閲覧できなくなるわけではありません。hidden パラメータは Explore から Explore を削除しますが、非表示の Explore を参照するコンテンツを保存した場合、ユーザーは Explore のデータに引き続きアクセスできます。

シングルサインオン（SSO）埋め込みを使用する場合は、SSO 埋め込み URL を使用してデータアクセス制御を設定してください。

データベース接続へのデベロッパーアクセスを制御する

通常のユーザーとは異なり、Looker のデベロッパーは LookML モデルの追加や変更のみを行うため、モデルやアクセスフィルタによる完全な制約はありません。ただし、管理者はプロジェクトを使用することで、Looker 開発者が特定のデータベース接続に限定できます。手順は次のとおりです。

特定の数のモデルを特定の数のデータベース接続に制限するプロジェクトを作成する。これは、Looker の [プロジェクトの管理] ページで行います。
プロジェクト内のモデルのうち 1 つ以上を含むモデルセットを作成し、ロールに割り当てます。この操作は、Looker の [ロール] ページで行います。
ユーザーグループ（通常は Google が推奨）を操作するには、Looker の [グループ] ページでグループを作成します。次に、[ロール] ページでそのグループを適切なロールに割り当てます。
個々のユーザーを操作するには、[ユーザー] ページまたは [ロール] ページからそれらのユーザーにロールを割り当てます。

Looker デベロッパーは、プロジェクトに含まれる任意のモデルを表示できれば、そのプロジェクトの一部であるすべてのモデルを表示できます。たとえば、Looker デベロッパーに 1 つのモデルのみのロールを割り当てても、そのモデルが他のモデルを含むプロジェクトの一部であった場合などです。

コンテンツへのアクセスと権限の相互作用

コンテンツアクセスは、ユーザーがフォルダを表示したときにユーザーによって管理されます。あるいは、Looker 管理者によって管理パネルの コンテンツアクセス ページで管理されます。ユーザーに割り当てられるロールは、ユーザーの機能とデータアクセスによって決まります。これにより、ユーザーがフォルダ内で行える操作と、Look やダッシュボードを表示できるかどうかが決まります。

Look およびダッシュボードでのデータを表示する

Look やダッシュボードのデータを表示するには、コンテンツの保存先フォルダに対する閲覧以上の権限が必要です。

Look を選択してデータを表示するには、access_data 権限と see_looks 権限が必要です。ダッシュボードを選択してデータを表示するには、ユーザーに access_data 権限と see_user_dashboards 権限が必要です。

Look またはダッシュボードのタイルでデータを表示するには、ユーザーがそのデータにアクセスできる必要があります。必要なデータアクセスがない場合:

ユーザーがフォルダに Look を表示して、Look に移動できる場合でも、Look のクエリは実行されず、Look のデータは表示されません。
フォルダ内にダッシュボードが表示され、ダッシュボードに移動できる場合でも、ユーザーがアクセスできないタイルは空白で表示されます。ダッシュボードに複数のモデルから作成されたタイルがある場合、ユーザーはアクセス権を持つモデルに関連付けられているタイルを表示でき、他のモデルのタイルにはエラーが表示されます。

この例では、ユーザーは、フォルダに対する表示アクセス権、データに対するアクセス権、access_data 権限と see_looks 権限の両方を持っているため、Look のリストを表示してそれらの Look を表示できます。ユーザーには LookML またはユーザー定義のダッシュボードを表示する権限がないため、ダッシュボードがフォルダに表示されることはありません。

フォルダと Look およびダッシュボードのリストを表示する

フォルダを表示し、そのフォルダ内に保存されているコンテンツのリストを表示するには、少なくとも View アクセスレベルが必要です。

少なくとも see_looks 権限を持っているユーザーには、フォルダ内の Look のタイトルが表示されます。see_user_dashboards 以上の権限を持っているユーザーには、フォルダ内のダッシュボードのタイトルが表示されます。ただし、Look またはダッシュボードのデータを表示できるわけではありません。

この例では、ユーザーには see_looks 権限がありますが、access_data 権限はありません。したがって、ユーザーは Look のタイトルを表示できますが、Look のデータは表示されません。ユーザーは、Look に必要なデータアクセスを持っているとは限りません。

access_data 権限を与えられていても、see_looks または see_user_dashboards のいずれも持っていないユーザーは、どのフォルダやコンテンツも表示できません。

フォルダを変更する

コンテンツのコピーと移動、フォルダの名前の変更と移動などの、フォルダの管理を行うには、ユーザーにフォルダの管理権限と編集権限が必要です。フォルダの作成、編集、移動、削除を行うには、manage_spaces 権限も必要です。

ユーザー権限インフラストラクチャ（LDAP、SAML、OpenID Connect）を利用する

LDAP、SAML、OpenID のインフラストラクチャをすでに設定している場合は、そのシステムを使用してユーザーのログインを管理できます。LDAP の設定手順については、LDAP 認証のページをご覧ください。SAML の設定手順については、SAML 認証に関するドキュメントページをご覧ください。OpenID Connect の設定手順については、OpenID Connect 認証のドキュメントをご覧ください。

LDAP、SAML、OpenID Connect の実装でグループを構成している場合は、Looker 内でそれらのグループを使用することもできます。ただし、いくつか留意すべき点があります。

作成したすべてのグループは自動的に Looker に転送され、[グループ] ページに表示されます。LDAP グループ、SAML グループ、OpenID Connect グループごとに Looker グループが 1 つ作成され、Looker グループ名には LDAP、SAML、または OpenID Connect グループ名がミラーリングされます。
これらの Looker グループを使用して、フォルダのアクセスレベルとユーザー属性をグループのメンバーに割り当てることができます。
Looker グループを使用して、手動で作成したグループのようにロールを構成することはできません。代わりに、設定プロセス中に LDAP、SAML、または OpenID Connect のグループを Looker のロールにマッピングし、LDAP、SAML、または OpenID Connect の設定ページから割り当てられたロールのみを変更できます。LDAP、SAML、OpenID Connect の各グループが信頼できる唯一の情報源であり続けるために、このアプローチが必要でした。この制限がないと、グループからロールへのマッピングが、LDAP、SAML、OpenID Connect スキーム内の目的の機能と異なる場合があります。

LDAP 認証のドキュメントページで説明されているように、LDAP を使用してユーザー固有のデータベース接続を Looker クエリに適用することもできます。