Databricks におけるカラムマスキング機能の使い方

GLB事業部Lakehouse部の林（リン）です。今回はデータブリックスのデータマスキング機能を紹介したいと思います。

はじめに
Part 1: 前提条件と制限
Part 2: マスキング関数の適用方法
- Step 1 関数実行者権限の設定
- Step 2 関数の作成
Part 3: 注意点
- 1. タイムトラベル機能が使えなくなります。
- 2．下流テーブルはマスク関数を継承しません。
Part 4: シナリオに応じた機密資料の処理方法
- マスキングしない場合
- マスキングする場合
まとめ

はじめに

機密性やPII（Personally Identifiable Information, 個人識別情報）を含む資料をより安全に使えるには、データのセキュリティ面の管理が不可欠です。Databricksでは、UDF（User-Defined Function）を活用することでデータマスキングを適用できます。データ管理者は、元のデータに対して何らかの操作を行う必要がある場合があります。一方で、データアナリストは機密性の低いデータのみを閲覧することが求められるため、マスキングは通常アクセス制御と併用されます。

文章の構成は4つのパートに分かれています。

Part 1：マスキング関数を使用する際の前提条件と制限
Part 2：マスキング関数の適用方法の紹介
Part 3：注意点の説明
Part 4：シナリオに応じたマスキング方法の紹介

早速説明したいと思います。

Part 1: 前提条件と制限

関数を有効にするためには、以下の前提条件と制限があります。

Workspace Prerequisite

Unity Catalogが有効になっていること。

User Prerequisite

関数のEXECUTE権限
スキーマのUSE SCHEMA権限
カタログのUSE CATALOG権限

＊関数を適用できるユーザーは、本文では「関数実行者」と呼びます

Compute Requirement

以下のいずれかが必要です：

SQLウェアハウス
標準アクセスモード(旧：共有アクセスモード) Databricks Runtime 12.2 LTS 以降
専用アクセスモード(旧：シングルユーザーアクセスモード) Databricks Runtime 15.4 LTS 以降

Part 2: マスキング関数の適用方法

peepsというデータセットを整理し、スキーマblog内にテーブルpeepsを作成しました。以下に、一部のデータを示します。

select name_given
     , name_family
     , email_addr
     , phone_number 
from blog.peeps

例として、peepsの電話番号（phone_number）を PIIとしてマスキングします。

Step 1 関数実行者権限の設定

Account consoleにてグループを作成し、ワークスペースにてグループに必要な権限 (Part 1のUser Prerequisite) をGrantします。

＊Account adminの権限が必要です。

Step 2 関数の作成

基本的にはSQLで構成されますが、pythonとScalaもサポートされています。以下のデモはSQLで書きます。

構文は以下のとおりです：

CREATE [OR REPLACE] FUNCTION schema.mask_function(col_name STRING)
RETURN 
CASE WHEN is_account_group_member('group_name') 
-- or use: current_user() IN ('User_account; group_name') 
THEN col_name 
ELSE [masking_rule]
END;

スキーマblog内にUDF phone_mask (blog.phone_mask) を作成し、電話番号(phone_number)を3桁まで表示します。

CREATE OR REPLACE FUNCTION blog.phone_mask(phone_number STRING)
RETURN 
CASE WHEN is_account_group_member('Admin_group') 
THEN phone_number 
ELSE substring(phone_number, 1, 3) || regexp_replace(substring(phone_number, 3, length(phone_number)), '\\d', '*')END; 
--only show first 3 digits

作成した関数phone_maskはスキーマblogの配下に登録され、関数の再利用は可能です。 blog.peeps(table)にblog.phone_mask(UDF)を適用します。

ALTER TABLE blog.peeps ALTER COLUMN phone_number SET MASK blog.phone_mask;

関数実行者は元のデータを閲覧できますが、他のユーザーにはマスクされたデータが表示されます。

select name_given
     , name_family
     , email_addr
     , phone_number 
from blog.peeps

Catalogで関数が適用されているかを確認でき、Column masking ruleで表示されます。(下の赤枠の右側) これでマスキング機能の適用が完了しました！

アンマスキングする場合は、以下のコマンドを実行してください。

ALTER TABLE blog.peeps ALTER COLUMN phone_number DROP MASK;

Part 3: 注意点

注意点を2つ説明したいと思います。

1. タイムトラベル機能が使えなくなります。

select * from blog.peeps version as of 0

コマンドを実行したら、「COLUMN_MASKS_FEATURE_NOT_SUPPORTED.TIME_TRAVEL」というエラーが表示されます。過去のバージョンに戻る必要があればご注意ください。ドキュメントの制限事項にも記載されています。

2．下流テーブルはマスク関数を継承しません。

関数実行者がテーブルを作成した場合

関数実行者としてpeeps_downstreamという下流テーブルを作成しました。

CREATE OR REPLACE TABLE blog.peeps_downstream
AS
select name_given
     , name_family
     , phone_number 
from blog.peeps

権限に関係なく、関数の実行者でなくても、 peeps_downstreamをプレビューしたら、元のデータが表示されます！

select * from blog.peeps_downstream

関数実行者以外の権限で下流テーブルを作成した場合

関数実行者以外の権限でテーブルを作成し、テーブルをプレビューしたら、phone_numberはマスクされた状態ですが、catalogでColumn masking ruleの表示はありません。これは、下流テーブルはマスキング処理後の値で上書きされるためです。そのため、アンマスキングすることはできません！

select * from blog.peeps_downstream

サマリー

下流テーブルでは、マスキングされたカラムの値は継承できますが、マスク関数そのものは継承できません。権限によって作成された下流テーブルは異なりますので、ご注意ください。

Part 4: シナリオに応じた機密資料の処理方法

誰でもマスキング関数を使えるわけではなく、誰でもデータを閲覧できるわけでもないため、アクセス制御が重要になります。

マスキング関数を使用するには、関数実行者はEXECUTE・MANAGE権限が必要です。ある程度の自動化を行う場合は、パイプラインを実行する権限が必要です；ユーザーはロールに応じてテーブルの権限を付与されます。

機密資料を処理する際、メダリオンアーキテクチャとアクセス制御に基づいて、いくつかのシナリオが考えられます。

マスキングしない場合

ソースデータの機密カラムの読み込みが不要な場合は、メタデータとパイプラインを調整し、機密カラムを除外します。

マスキングする場合

ソースデータの機密カラムが読み込み必要な場合は、以下の3つのシナリオを参考にしてください。

1．Bronze / Silver / Goldごとに関数を適用

マスキング関数は継承されないため、Bronze / Silver / Goldの各テーブルに対して、関数実行者が関数を適用します。

メリット：各スキーマのテーブルのアンマスキングが可能

デメリット：すべてのテーブルに適用するのが手間

2．関数実行者がBronze のみに関数を適用し、Silver / Goldは関数権限のないユーザーが作成

関数実行者がBronzeテーブルだけ関数を適用し、機密カラムがマスクされます。下流テーブルは関数権限のないユーザーが作成すると、機密カラムがマスキング処理後の値で上書きされます。

例えば、Azureでデータを読み込む際、関数実行者が Bronze テーブルに関数を適用し、MI (Managed Identity) や SP (Service Principal) は関数権限のないユーザーとして Silver / Gold テーブルを作成します。

メリット：マスキングされたカラムの値を継承可能

デメリット：Silver / Goldではアンマスキング不可。

3．Dynamic view

ロールに応じてDynamic viewを使用します。役割が明確に分けている場合のベストプラクティスだと考えられます。

Viewをを作成し、グループauditorsに所属していないユーザーはphone_numberを閲覧できません。

CREATE VIEW blog.peeps_view AS
select name_given
     , name_family
     , CASE WHEN is_account_group_member('Admin_group') THEN phone_number
       ELSE 'REDACTED'
       END AS phone_number
from blog.peeps

関数実行者以外のユーザーが見るphone_numberはREDACTEDとなります。

select * from blog.peeps_view

メリット：使用する場面に応じて、フレキシブルにビューの作成が可能

デメリット：厳密なアクセス管理が必要

まとめ

Databricks のカラムマスキング機能について、関数の適用方法、注意点、およびシナリオを紹介しました。機密資料を処理する際の参考になれば幸いです。

最後までご覧いただきありがとうございます！

私たちはDatabricksを用いたデータ分析基盤の導入から内製化支援まで幅広く支援をしております。
もしご興味がある方は、お問い合わせ頂ければ幸いです。

www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です！
APCにご興味がある方の連絡をお待ちしております。

APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。