Best Practice: Keeping Looker Secure

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

データベース セキュリティ

Looker を必要最小限のアクセス権に制限してデータベースを保護します。

  • Looker アプリケーションとデータベース間で安全なアクセスを構成するLooker ドキュメントでは、許可リストへの Looker IP の追加、SSL 伝送の暗号化、SSH トンネルを通じたデータベースへの接続など、いくつかの推奨事項が記載されています。
  • Loker に対して、アプリケーションにすべての必要な機能の実行を許可しつつ、最も制限されたデータベース アカウント権限を設定します。データベース固有の設定要件については、データベース構成手順のドキュメント ページをご覧ください。

プロダクトのセキュリティ

Looker へのユーザー アクセスを、各ユーザーが必要とする最小限の機能とデータアクセスに制限します。

  • Looker のネイティブのユーザー名 / パスワードのオプション、または、可能であれば 2FALDAPGoogle OAuthSAML などのより強固な認証メカニズムを使用してユーザー認証を設定します。(これらのメソッドは相互排他的でセキュリティ レベルも異なり、たとえば Google Oauth では、メール ドメイン内の誰もが Looker にログインすることが可能です。
  • API 認証情報を決して一般公開で投稿せず、API 認証情報は、可能であれば環境変数として保存し、メールやチャット サポートで共有しないでください。
  • ユーザーが作成するあらゆる公開アクセスリンクを定期的に監査し、必要に応じて作成の権限を制限します。次の システム アクティビティ Explore は公開 Look を追跡できます。
    https://<instance_name.looker.com>/explore/system__activity/look?fields=look.id,look.title,look.public,user.name&f[look.public]=Yes&limit=500&query_timezone=America%2FLos_Angeles&vis=%7B%22type%22%3A%22table%22%7D&filter_config=%7B%22look.public%22%3A%5B%7B%22type%22%3A%22is%22%2C%22values%22%3A%5B%7B%22constant%22%3A%22Yes%22%7D%2C%7B%7D%5D%2C%22id%22%3A0%2C%22error%22%3Afalse%7D%5D%7D&dynamic_fields=%5B%5D&origin=share-expanded
  • 管理者権限の所有者に特別な注意を払いながら、ユーザーによる作業を可能にしつつ、最も制限されたユーザー権限とコンテンツ アクセスを設定します。各機能の詳細については、フォルダを保護しましょう。コンテンツ アクセスのチュートリアルのベスト プラクティスをご覧ください。
  • access_filter パラメータをユーザー属性と組み合わせて使用し、ユーザーまたはユーザー グループによる行レベルのデータ セキュリティを適用します。
  • access_grants をユーザー属性と組み合わせて使用し、Explore、結合、ビュー、フィールドなどの LookML 構造へのアクセスをユーザーまたはグループ単位で制御します。
  • モデルセットを使用して、Looker モデル内でデータセット セキュリティを適用します。ユーザーが各自に割り当てられたモデルセットに含まれてないコンテンツを閲覧することはできません。
  • できる限り、ユーザーを個別にロールへ割り当てるのは避けること。個人のロールとグループ メンバーに基づくロールの両方を付与されたユーザーは、個人とグループの割り当ての両方からロールをすべて継承します。これにより、割り当てられるべきではない権限がユーザーに付与されてしまう可能性あり。ベスト プラクティスは、可能な限りグループ メンバーに基づいてロールを割り当てることです。
  • ほとんどのユーザーを共有フォルダの閲覧者に設定します(クローズド システム設定の場合を除く)。これにより、共有フォルダとアクセス権が付与されたあらゆるサブフォルダのコンテンツをユーザーが閲覧可能にります。共有フォルダに対するアクセスの管理、編集の権限をユーザーに付与すると、あらゆるサブフォルダに対する権限が保持されます。まず階層の下のレベルで変更を加えてから、上位のアクセス権を取り消すことが有効。詳細については、後で説明します。

コンテンツのセキュリティ

サポートする必要があるアクセス制御に基づき、適切なタイプの Looker システムを実装します。

  • 完全オープン: 誰でもシステム内の項目を閲覧および編集することが可能です。すべてのユーザー グループに、ルートフォルダ(共有と呼ばれる)内で、アクセスの管理、編集の権限を割り当てる必要があります。完全オープンのアクセス システムの有効化の詳細については、完全オープン システムの構成のドキュメント ページをご覧ください。
  • コンテンツの制限付きオープン: コンテンツへのアクセスをなんらかの方法(特定のユーザーのみが特定のコンテンツを編集できるようにするか、特定のコンテンツを特定のユーザーにまったく表示されないようにする)で制限します。可能であれば、よりフラットな構造にすることで、深くネストされたフォルダより管理しやすくなります。コンテンツの制限付きオープンのシステムの設定について詳しくは、制限付きのオープン システムの構成のドキュメント ページをご覧ください。
  • クローズド システム: このシステムでは、グループ間でコンテンツを完全に分離するため、異なるグループのユーザー間で情報を共有することができません。クローズド システムはマルチテナントでの Looker のインストールに最適。 このオプションを進める前に、アクセスレベルのシステムの設計と構成のドキュメント ページでクローズド システムの構成に関する説明を必ずお読みください。 クローズド システムを有効にすると、フォルダ管理へのアクセス権の変更が難しくなります。このドキュメント ページでは、Looker インスタンスのセットアップを有効にする方法について説明しています。

詳細については、Looker のアクセス制御と権限管理またはアクセスレベルのシステムの設計と構成をご覧ください。