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

このページは Cloud Translation API によって翻訳されました。

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

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

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

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

ユーザーとグループ

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

ベストプラクティスは、グループを使用して、ユーザーが個別に制御の割り当て、調整、削除を行う手間を省くことです。通常、ユーザーに許可するアクティビティの組み合わせは、そのユーザーを 1 つ以上のグループに所属させることで調整できます。グループの組み合わせが不十分な場合は、ユーザーが 1 人だけのグループを作成することを検討してください。これにより、今後そのグループをより多くのユーザーに公開できるようになります。アクセスフィルタでは、ユーザー属性をグループに割り当てることができるため、ユーザー属性の使用を検討してください。

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

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

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

フォルダが存在することの確認、そのフォルダ内の Look とダッシュボードの表示、フォルダ内の Look とダッシュボードのコピーをするためには、少なくともフォルダに対する View アクセスレベルが必要です。
フォルダへのアクセス権の管理、フォルダとそのコンテンツの編集（フォルダの名前の変更、コンテンツの移動、Look とダッシュボードの削除など）を行うには、フォルダに対するManage Access, Edit アクセスレベルが必要です。

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

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

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

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

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

アクセスフィルタを使用して、特定のユーザーに特定のデータの上限を適用できます。また、プロジェクトを使用することで、Looker 開発者が特定のデータベースに基づくモデルで作業するように制限できます。

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

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

機能アクセスは、コンテンツアクセスにも影響する可能性があります。データアクセスと機能アクセスがコンテンツアクセスに与える影響の詳細については、このページのコンテンツアクセスと権限の関係をご覧ください。

理解する必要がある構成要素

ロール

ロールは、1 つの権限セットと 1 つのモデルセットを組み合わせたものです。権限セットは 1 つ以上の権限で構成され、ロールで可能な操作を定義します。モデルセットは 1 つ以上のモデルで構成され、ロールが適用される LookML モデルを定義します。

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

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

プロジェクト

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

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

ユーザー属性

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

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

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

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

構成要素の使用

機能アクセスを制御する

権限によって、ユーザーまたはグループが実行できるアクティビティの種類を制御します。ユーザーは次の方法で権限を取得できます。

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

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

Role1 は Model1 のダッシュボードを表示できます。
Role2 は Model2 のダッシュボードを表示して探索できます。

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

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

ユーザーが作業できるフィールドは、ユーザーがアクセスできるモデルによって制御されます。ユーザーは次の方法でフィールドにアクセスできます。

ユーザーがアクセスできるフィールドのみを含む LookML モデル（または LookML モデルの組み合わせ）を作成します。
[管理者] > [ユーザー] > [ロール] の順に選択します。
[ロール] ページで、それらのモデルを含むモデルセットを作成し、ロールに割り当てます。
ユーザーのグループ（通常はベストプラクティス）を操作するには、Looker の [グループ] ページでグループを作成します。次に、[ロール] ページで、そのグループを適切なロールに割り当てます。
個々のユーザーを操作するには、[ユーザー] ページまたは [ロール] ページから、それらのユーザーにロールを割り当てます。

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

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

データへのユーザーアクセスを制御する

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

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

hidden フィールドパラメータが、フィールドアクセスの制御を目的としていないように、Explore の hidden パラメータを使用しても、ユーザーによる Explore の閲覧が防止されない場合があります。hidden パラメータは、Explore メニューから Explore を削除しますが、非表示の Explore を参照するコンテンツを保存したユーザーは、引き続き Explore のデータにアクセスできます。

署名付き埋め込みを使用している場合は、署名付き埋め込み URL でデータアクセス制御を構成してください。

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

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

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

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

コンテンツアクセスと権限の関係

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

Look とダッシュボードのデータの表示

Look またはダッシュボードのデータを表示するには、コンテンツが保存されているフォルダに対する少なくとも [表示] アクセス権がユーザーに必要です。

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

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

ユーザーがフォルダに 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 のデータは表示できません。

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

フォルダの変更

コンテンツのコピーと移動、フォルダの名前の変更と移動などの同じようなアクションを含む、フォルダの管理には、フォルダに対する Manage Access、Edit アクセスレベルが必要です。フォルダを作成、編集、移動、削除するには、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 のグループごとに 1 つの Looker グループが作成され、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 クエリに適用することもできます。