🔎

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

2021/02/18に公開

Google Cloud

はじめに

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_sqlとuse_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])を利用します。

Liquid式を使った方法
Access Grantsを使った方法

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

実行環境

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

【LookMLの構成】

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

実施手順

UserAttributesの設定
Liquid式での設定
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のユーザには見せる
という制御をすることで特定フィールドのマスキングを実現しています。

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

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

3. Access Grantsでの設定

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

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

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でもマスキング出来るようチャレンジしたいと思います！

脚注