この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Lookerではトピック毎のベストプラクティスを個別にドキュメントやナレッジベースとしてまとめています。当エントリではその中から、『Lookerをセキュアに保つ方法』についてご紹介したいと思います。
目次
データベースに関するセキュリティ
- Lookerアプリケーションとデータベースの間に、安全なアクセスが構成されていることを確認します。
- Lookerの下記ドキュメントには、『LookerのIPホワイトリスト登録』『SSL送信の暗号化』『SSHトンネルを介したデータベースへの接続』など、幾つかの推奨事項が紹介されています。
- Lookerに対し、最もロックダウンされたデータベースアカウントのアクセス許可を設定します。これにより、アプリケーションが必要な機能を全て実行出来るようになります。
- データベースそれぞれの設定要件については、下記ページをご参照ください。
製品に関するセキュリティ
- Lookerではネイティブでユーザー名・パスワードオプションを使う形となっています。その他、下記のような様々な認証メカニズムを使用することも出来ます。以下の方法群は相互に排他的であり、セキュリティレベルは異なります。例えば、Google OAuthではメールドメイン内の誰でもLookerにログインすることが可能です。
- APIの認証情報は決して公開しないでください。メールやチャットサポート等であっても情報は共有しないでください。
-
ユーザーが作成するパブリックアクセスリンクを定期的に監査し、必要に応じて作成するアクセス許可を制限しましょう。
- Giving Public Access to Specific Looks
- Public Sharing, Importing, and Embedding
- 以下のi__lookerエクスプローラ(Explore)は、Lookerインスタンスの全てのパブリックなLookとその作成者をリストします。(※my.looker.comをLookerインスタンスのURLに置き換える事で動作します)
https://<my.looker.com>/explore/i__looker/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 -
インスタンスでSystem Activity Modelが有効になっているユーザー(Lookerバージョン6.2以降の"Labs"の機能として利用可能)は、以下のエクスプローラ(Explore) URLを介して公開Lookを追跡出来ます。
https://<my.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_grantをユーザー属性と組み合わせて使用し、ユーザーまたはグループ毎にエクスプローラ(Explore)、結合(Join)、ビュー(View)、フィールド等のLookMLの確証要素へのアクセスを制御します。
- モデルセット(Model Set)を使用して、Lookerモデル内でデータセットに対するセキュリティを適用します。ユーザーは、割り当てられたモデルセット以外のコンテンツを表示出来なくなります。
-
可能な限り、ユーザーに対して個別にロールを割り当てないようにしてください。"ユーザー個別に割り当てられたロール"と"グループメンバーシップに基づくロール"の両方があるとそれら両方の割当内容から全ての役割を継承する形となり、必要以上の権限を持ってしまう可能性があります。ベストプラクティスとしては、可能な限り"グループメンバーシップのみ"に基づいてロールを割り当てること、です。
-
殆どのユーザーは、共有フォルダの閲覧者(Viewer)である必要があります。(※閉じたシステム設定の場合を除く) これにより、ユーザーは共有フォルダ及びアクセス権のあるサブフォルダ内のコンテンツを表示出来るようになります。
- 共有フォルダに対するアクセスの管理と編集のアクセス許可をユーザーに提供することは、全てのサブフォルダ内でもこれらの権限を保持することを意味します。
- 最初にツリー内の下位要素に変更を加え、その後にアクセスをより高いレベルで取り消すようにすると良いでしょう。(詳細は次項にて解説)
コンテンツに関するセキュリティ
サポートする対象となる要件のアクセス制御に基づき、適切な構成のLookerシステムを実装しましょう。
完全にオープンにする：
- システム内における[要素を表示]及び[要素を編集]出来るユーザーに制限はありません。[全てのユーザー]グループは、ルートフォルダ内("Shared"と呼ばれている)の[アクセスの管理]、[編集]に割り当てる必要があります。
- 完全にオープンなアクセスシステムを有効にする方法の詳細については以下ドキュメントをご参照ください。
コンテンツ制限付きでオープンにする：
- 特定ユーザーのみが特定のコンテンツを編集出来るようにしたい、また特定のコンテンツが特定のユーザーには完全に見えないようにしたいという場合、何らかの方法でコンテンツを遮断・封鎖する必要があります。
- 可能な限り、よりフラットな階層構造を取るようにしてください。階層が深くネストされているフォルダよりも管理が行い易くなります。コンテンツ制限を踏まえたオープンなシステムセットアップの詳細については以下ドキュメントをご参照ください。
クローズドにする：
- このシステムでは、グループ間でコンテンツを"完全分離"するため、異なるグループのユーザーが他のグループの情報を知ることも出来ません。
- クローズドなシステムは『マルチテナントLookerの導入』を検討する場合に最適なケースとなるでしょう
- このオプションを実行する際は必ず以下ドキュメントをお読みください。
- 一旦この設定にしてしまうと、フォルダ管理アクセス周りの権限を変更することは困難となります。ご注意ください。
その他参考情報
その他参考になる情報としては以下があります。合わせて読み進め、対策を講じておきたいところです。
- アクセスコントロールと権限管理：
- アクセスレベルの設計と設定：
まとめ
というわけで、Lookerにおける『Lookerをセキュアに保つ方法』のご紹介でした。
Lookerでは当エントリで紹介したように、様々な切り口、局面での『情報をセキュアに保つ方法』が用意されています。逆に、様々な設定が用意されているので、適切なポリシーやルールが無いと設定がカオスになってしまう可能性もあります。予め、システムとしてどういう構成、設定でアクセスを行わせたいか、管理したいかを設計しておくことが重要となりますのでしっかり時間を確保し、設計を済ませておきましょう。
24
