abstract

Lookerのグループを組閣単位で自動生成/自動更新することで、組閣が常にLooker上で表現されるようにしました。
user_attributeとaccess_grantを利用することで組閣単位でカラムレベルの権限管理を可能としました。

背景・前提

セキュリティ観点から最小権限の法則に従い、特定のデータをアクセスが必要な人にだけ見せたいと考えました。
- 特定の情報へのアクセス権限は、個人ではなく組閣や役職に紐づくと考えています。
Looker上で探索環境やカラムやDimensionグループが大量に表示されると情報取得までのリードタイムが長くなり、探索体験が悪化します。
- ユーザーの所属するドメイン以外を見せなくすることによって、Looker利用時の迷いが無くなりUXが向上すると考えました。

実装方法

Looker上のグループを組閣と一致させる実装

めちゃくちゃざっくりと実装概要を示すと以下のような形です

smartHRから組閣情報を抜き出してBigQueryにロード
BigQuery上で組織図を扱いやすい形にデータモデリング（この組閣のモデリングが実はものすごく大変なので、これは別の機会にどこかで書きます）
github actionsからLookerAPIをキックしてグループの反映とユーザーのグループ追加を実施

って流れです。
人事メンバーがsmartHRに情報を反映したら、Looker上の組閣情報も自動で更新されるような状態を構築しました。

考慮したポイント

考慮したポイントとしては、組織グループを全階層分作成したことです。
全ての階層の組織をグループで作成して、所属している階層全てをユーザーに紐づけました。

この図でいうところの組織aに所属している人はLooker上で組織a, 組織1, 組織A全てに所属している状態としました。
これによって、より現場に近いレイヤーだけがアクセスできる状態を構築できたり、本部や支社単位で一括で権限付与ができたりします。

UserAttributeを作成してグループに反映する実装

UserAttributeの紹介記事など少ないと感じたので簡単に説明します。
UserAttributeはWebUI上からだとこのような画面で設定可能な項目になっています。

UserAttributeはvalueとしてNumber,String,DateTimeなどを持つことができます。（Pythonの型注釈で表現するならDict[str, Any]みたいなイメージ）
UserAttributeのvalueに持たせた値をliquid変数で参照したり、後述するaccess_grantで参照できたりします。

UserAttributeはUser単位、Group単位で付与することができます。
たとえばこれはUserAttributeをtest部署というグループにおいて、SFUseDepartmentというSalesforceを利用している部署かどうかを示すUserAttributeにTrueの値をセットしているものになります。

今回わかりやすいようにWebUI上の操作をしていますが、APIからUserAttributeの作成、値の設定、グループやUserへの割り当てなど行うことができます。

カラムレベル閲覧制御を行う実装

先ほど作成したSFUseDepartmentというuser_attributeの値がTrueのグループの人だけ見られるカラムを作成します。

xxx.model.lkmlに以下のようなaccess_grant_filterを作成します。

access_grant: sf_use_department_filter {
  user_attribute: sf_use_department
  allowed_values: ["True"]
}

この場合sf_use_department_filterは、sf_use_departmentというkeyのuser_attributeがTrueという値の場合にTrueを返すようなフィルターとなります。

このフィルターをview.lkmlに定義してあるdimensionに以下のように適用します

  dimension: torihikisaki_sekininsya_information {
    label: "取引先責任者の何かしらの情報です"
    type: string
    sql: ${TABLE}.dimension_name ;;
    required_access_grants: [sf_use_department_filter]
  }

このようにすることで、torihikisaki_sekininsya_informationというdimensionはsf_use_department=Trueを割り当てられているメンバーにしか表示されなくなります。取引先責任者の情報をSalesforceを普段利用している営業部署以外の人たちには表示されないようにできました！

このrequired_access_grantsは複数のフィルター条件をOR条件で持たせられるので

required_access_grants: [sf_use_department_filter, yakushoku_filter]

こんな風にSalesforceを普段から利用する部署、または役職者の人だけ見られる
みたいな制限も簡単に作ることができます！

まとめ

Lookerグループの組閣単位の自動生成/自動更新とuser_attributeとaccess_grantを利用した組閣単位のカラムレベルの権限管理を紹介しました！
今回は組閣×カラムレベルの制御でしたが、もちろんUser単位でUserAttributeを設定できますし、カラムではなくDimension単位で閲覧制限をかけたりすることができます。
このような出し分けがLookerの機能として可能となることで、この記事でデモしたセキュリティ的な用途だけでなく、雑多な情報を見せないデザインにも応用できたりして奥が深いです

今回紹介した利用方法以外にも、Lookerグループを組閣ベースで作成することで副次的な効果として「どの部署がどのくらいLookerを使ったのか」「どの部署のLooker利用が推進できていないか」などの情報もモニタリングできるようになったことは大きいなと思っています。

またLookerの便利な使い方を見つけたら紹介できたらと思います！それでは！

okodooooooon

Looker上で組閣✖️カラムレベルで権限制御を行える状態を構築した話