🔎

【Looker】個人情報フィールドのマスキング方法(パート①)

7 min read

はじめに

Lookerを使い始めて、すでに1年が経ちました。
ようやく色々とナレッジが溜まってきたので、備忘録的に記事をアップしていこうと思ってます!!

記念すべき第1回は、特定フィールドのマスキングについて、トライしたことをまとめてみました!
他にも良いやり方があれば、コメント頂けると幸いです^^

やりたきこと

今回実現したかったことは、
開発者にLooker開発環境を利用してもらいたい、本番データを使いたいけど
個人情報などの機微な情報だけはマスキングしておきたい。
というところでした。

ということで、実現したい機能要件は下記の通りです。

  • LookerのDashboardやExploreで機微なフィールドがマスキングされていること
  • LookerのSQL Runner[1]でSQLを実行しても機微なフィールドがマスキングされていること
  • BigQueryのクエリエディタでSQLを実行しても機微なフィールドがマスキングされていること

【全体概要図】

ここで、少し補足になります!
上記の要件において、LookerのSQL Runnerをユーザに使えないようにすれば良いのでは?
BigQueryのクエリエディタを叩けないようにGCPコンソール触らせなければ良いのでは?
という話があると思います。

まずSQL Runnerの利用について、LookerのUserに割り当てるRole[2]で制御することができます。
具体的には、Roleに割り当てるPermission Setsにおいて、see_sqluse_sql_runner
Permissionを外すことでUserにLookerからSQLを実行できないようにすることができます。

【該当するPermission】

【see_sqlの制御結果】

上記のPermissionを外したPermission SetsをRoleに割り当てて
そのRoleをGroupまたはUserに割り当てることで制御することが可能になります。

【Role周辺の関連性】

今回、開発者がBigQueryの物理テーブル相当のデータもクエリ出来るよう
SQL Runnerは利用したいという要件があったため、上記の制御はできませんでした。

BigQueryのクエリエディタは、GCPコンソールを触らせないことで制御することとしました^^

今回実施したこと

BigQueryの列レベルセキュリティ[3]で出来る事もありますが
まずはLookerの機能で出来ることをやってみることにしました!

下記のサイトには、2つのやり方が提示されています。
いずれの方法においても、ユーザ属性(以降、UserAttributes[4])を利用します。

  1. Liquid式を使った方法
  2. Access Grantsを使った方法

https://help.looker.com/hc/en-us/articles/360001236867-Masking-Sensitive-Fields-for-Certain-Users

それぞれ特徴がありますので、以降の内容で
設定方法、動作結果、注意ポイントについてまとめていました。

実行環境

Product version
Looker 21.0.19
BigQuery 2021年2月5日時点

【LookMLの構成】

【補足】
個人情報を持っているマスターテーブルを参照しているviewファイルはemp_masterです。
そのテーブルの中のColums2フィールドに格納されています。
logging_view_lake.viewと結合後、NDT[5]を使い、さらにviewを作成しています。

実施手順

  1. UserAttributesの設定
  2. Liquid式での設定
  3. Access Grantsでの設定

1. UserAttributesの設定

まず、UserAttributesの設定について、どんな動きをするのか説明します。
[Admin] > [Users] でUserの設定を見てみましょう!

下部にUserAttributesとして、パラメータ設定が存在します。
パラメータを新たに追加し、ユーザによって異なる挙動にしたい場合に利用することができます。

【Userの設定画面】

下記がUserAttributesの設定画面になります。

【UserAttributesの設定画面】

【今回の設定内容】

項目名 設定値 説明
Name test ユーザ属性名
Label Test ユーザ属性の表示名
Data Type String ユーザ属性で定義する値のデータ型
User Access View ユーザ属性の値に対するユーザのアクセス権限
Hide Values No ユーザ属性の値をマスキングするか否か
Default Value no ユーザ属性の値のデフォルト値

このUserAttribute(今回はtestという名前にしていますが)を利用して
開発者(Dev)にはno(デフォルト値)、管理者(admin)にはyesという値を付与します。

Default Valueはnoにしていますが、特定のGroupだけはyesにしますよ!
という感じで、以下のようにGroup ValuesタグでAdminの設定を変更します。

【Admin Groupへの適用】

noになっているユーザにはマスキングして見せない、yesのユーザには見せる
という制御をすることで特定フィールドのマスキングを実現しています。

User Accessの設定は、必ずViewまたはNoneに設定してください!
セキュリティに関するUserAttributesのため、ユーザが値を変更できてしまうとまずいです。
Access Grantsでの設定は、ここがEditになっているとエラーでLookMLを適用できません。

2. Liquid式での設定

まずは、1つ目の方法になります。
マスキングしたいフィールドを定義しているviewファイルで設定します。
NDTを利用している今回の構成においては、物理テーブルに近いviewファイルで行います。

emp_master.view
  dimension: Colums2 {
    label: "Colums2"
    type: string
    sql:
+      CASE
+        WHEN '{{ _user_attributes['test'] }}' = 'yes'
+        THEN ${TABLE}.COLUMS2
+        ELSE ‘******’
+      END ;;
  }

この方法は、testの値がnoのユーザがダッシュボードでSQLを実行した際に
DBの物理テーブルからデータを取得後、ELSEで定義した値に書き換えます。

今回の例で言いますと「******」になります。以下のような表グラフになります。

Colums1 Colums2 Colums3
ABC ****** aaaa
DCB ****** bbbb
AAA ****** aaaa
DDD ****** cccc
ZXX ****** cccc
RGG ****** aaaa

UserAttributesのHide ValuesをYesにするとLiquid式で値を読み取れずエラーになります。

値を書き換えていますので、文字通りマスキングですね。かなり力技のような印象を持ちました。

Lookerサイトの設定例は、ELSEに「0」という数値を指定していました。
これはdimensionで定義しているフィールドが社会保険番号で、typeが数値だからです。

3. Access Grantsでの設定

次は、2つ目の方法になります。

https://docs.looker.com/ja/reference/model-params/access_grant?version=7.21

設定する箇所は2箇所になります。
1つ目はaccess_grantをmodelファイルで設定を追加します。
2つ目はマスキングしたいフィールドを定義しているviewファイルになりますが
NDTを利用している今回の構成においては、ダッシュボードに近いviewファイルで行います。

Liquid式の方法のように物理テーブルに近いviewファイルにrequired_access_grantsを記述しても効きません。

logging_model.model
+  access_grant: can_see_emp {
+    user_attribute: test
+    allowed_values: ["yes"]
+  }
logging_view_dwh.view
  dimension: Colums2 {
    label: "Colums2"
+   required_access_grants: [can_see_emp]
  }

こちらの方法は、testの値がnoのユーザがダッシュボードでSQLを実行した際に
DBの物理テーブルからデータは取得しますが、Explore以降で見せないという動きになります。

今回の例で言いますとColums2フィールドが非表示になります。
以下のようなダッシュボードの表グラフになります。

Colums1 Colums3
ABC aaaa
DCB bbbb
AAA aaaa
DDD cccc
ZXX cccc
RGG aaaa

まとめ

さて、いかがでしたでしょうか?

いずれの方法も個人情報フィールドを開発者には見せず
管理者のみ閲覧することができました。

ですが、SQL Runnerの利用権限をPermission Setsで与えてしまうと
開発者は好きにSQLを実行出来るようになります。

今回紹介した方法はダッシュボードを生成するためにLookMLがSQLを
自動生成する際、マスキングするためのSQL文を埋め込んでいるに過ぎません。

なので、このままでは要件を満たせないことが分かりましたので
次回は、BigQueryの列レベルセキュリティを使い
SQL Runnerでもマスキング出来るようチャレンジしたいと思います!

脚注
  1. SQL Runnerとは ↩︎

  2. Roleとは ↩︎

  3. BigQueryの列レベルのセキュリティの概要 ↩︎

  4. User Attirbutesとは ↩︎

  5. 派生テーブルの使用 ↩︎

Discussion

ログインするとコメントできます