Snowflakeには、アカウント間で安全かつ効率的にデータを共有できるデータシェアリング機能があります。データをコピーすることなくリアルタイムに共有できる点が大きな特長です。
一方で、外部アカウントへデータを共有する際には、閲覧者ごとに表示内容を制御する仕組みが重要になります。その代表的な機能がマスキングポリシーです。
本記事では、Snowflakeのデータシェアリング機能に焦点を当て、マスキングポリシーの制御方法の一つであるアカウントレベル制御を用いた実装方法をご紹介します。
なお、本記事ではマスキングポリシー自体の概要説明には触れず、データシェアリングと組み合わせた具体的な実装手順にフォーカスします。
データシェアリングの概要
Snowflakeのデータシェアリングは、異なるSnowflakeアカウント間でデータを効率的かつ安全に共有するための機能です。データのコピーや物理的な転送を行うことなく、サービスレイヤーおよびメタデータストアを活用して共有を実現します。
そのため、プロバイダー（提供側）とコンシューマー（利用側）間でリアルタイムかつ安全にデータを共有することが可能です。
マスキングポリシー実装の考え方
データシェアリングを利用する際には、共有先に対してどのようにデータを見せるかを制御する設計が重要になります。そのための仕組みがマスキングポリシーです。
マスキングポリシーの制御方法には複数の考え方があり、ロール単位で制御する方法や、アカウント単位で制御する方法などがあります。本記事では、データシェアリングとの組み合わせに適したアカウントレベル制御に焦点を当て、その実装方法を解説します。
データシェアリングとマスキングポリシーの実装
ここからは、データシェアリング環境において、アカウントレベル制御を用いたマスキングポリシーをどのように実装するのか、具体的な手順を説明します。
事前準備
本記事では、Snowflakeアカウントの作成方法や、データベースおよびテーブルの準備手順については割愛します。 あらかじめ以下の構成を用意している前提で説明を進めます。
- UserA
- プロバイダー側アカウント（データを共有するアカウント）
- マスキングポリシーの制御を行う
- UserB
- コンシューマー側アカウント
- データの内容をすべて閲覧可能
- UserC
- コンシューマー側アカウント
- 指定した列がマスキングされる
本手順では テーブル を対象にマスキングポリシーおよびデータシェアリングの設定を行います。 なお、同様の構成は セキュアビュー（SECURE VIEW） を対象として実装することも可能です。
今回使用するオブジェクト情報は以下のとおりです。
- データベース名：PROVIDER_DB
- スキーマ名：PUBLIC
- テーブル名：CUSTOMER
対象テーブル（PROVIDER_DB.PUBLIC.CUSTOMER）のデータ内容は以下のとおりです。
| CUSTOMER_ID | NAME | PHONE | PREFECTURE | |
|---|---|---|---|---|
| 1 | Yamada Taro | user1@example.com | 01-xxxx-xxxx | Tokyo |
| 2 | Suzuki Hanako | user2@example.com | 02-xxxx-xxxx | Kanagawa |
| 3 | Tanaka Ichiro | user3@example.com | 03-xxxx-xxxx | Osaka |
| 4 | Sato Yuki | user4@example.com | 04-xxxx-xxxx | Aichi |
| 5 | Kato Ken | user5@example.com | 05-xxxx-xxxx | Fukuoka |
手順1 マスキングポリシーの作成および適用
本手順は UserA（プロバイダー側アカウント） にて実施します。 まずは作業コンテキストを設定します。
作業コンテキスト設定
作業を実施するため、使用するロールおよびデータベース、スキーマの作業コンテキストを設定します。
USE ROLE ACCOUNTADMIN;
USE DATABASE PROVIDER_DB;
USE SCHEMA PUBLIC;
マスキングポリシー作成
コンシューマー側アカウントを識別するため、CURRENT_ACCOUNT() を利用したマスキングポリシーを作成します。 指定したアカウントからアクセスした場合のみ実データを表示し、それ以外のアカウントからのアクセス時にはマスキングされた値を返します。
※ 実際のアカウント識別子は公開できないため、本記事では <USERB_ACCOUNT_IDENTIFIER> というプレースホルダーを使用しています。
CREATE OR REPLACE MASKING POLICY MP_PII_STRING
AS (val STRING)
RETURNS STRING ->
CASE
WHEN CURRENT_ACCOUNT() IN ('<USERB_ACCOUNT_IDENTIFIER>')
THEN val
ELSE '*****'
END;
マスキングポリシー適用
作成したマスキングポリシーを、対象テーブルの EMAIL 列および PHONE 列に適用します。
ALTER TABLE PROVIDER_DB.PUBLIC.CUSTOMER
MODIFY COLUMN EMAIL SET MASKING POLICY MP_PII_STRING;
ALTER TABLE PROVIDER_DB.PUBLIC.CUSTOMER
MODIFY COLUMN PHONE SET MASKING POLICY MP_PII_STRING;
UserA：マスキングポリシーが適応されていることを確認
本マスキングポリシーでは、指定したコンシューマーアカウント（UserB）からのアクセス時のみ 実データを表示し、それ以外のアカウントからはマスキングされた値を返します。
そのため、プロバイダー側アカウント（UserA）で参照すると、 EMAILおよびPHONE列がマスキングされていることを確認できます。
手順2 データシェアリングの作成
次に、プロバイダー側で共有（SHARE）を作成し、 対象のテーブルを追加します。 その後、コンシューマー側アカウントを指定して共有設定を行います。
共有用SHAREの作成
コンシューマー側アカウントへデータを共有するための SHARE を作成します。
CREATE OR REPLACE SHARE PROVIDER_CUSTOMER_SHARE;
SHARE に DatabaseとSchema の使用権限を付与
SHARE から対象データを参照できるようにするため、データベースおよびスキーマに対して USAGE 権限を付与します。
GRANT USAGE ON DATABASE PROVIDER_DB TO SHARE PROVIDER_CUSTOMER_SHARE;
GRANT USAGE ON SCHEMA PROVIDER_DB.PUBLIC TO SHARE PROVIDER_CUSTOMER_SHARE;
共有対象テーブルへのアクセス権限を付与
共有対象とするテーブルを SHARE に追加するため、対象テーブルに対して SELECT 権限を付与します。
GRANT SELECT ON TABLE PROVIDER_DB.PUBLIC.CUSTOMER TO SHARE PROVIDER_CUSTOMER_SHARE;
コンシューマーアカウントを SHARE に追加
共有先となるコンシューマー側アカウントを SHARE に追加します。
※ 本記事ではプロバイダー側のアカウント識別子を公開できないため、
ALTER SHARE PROVIDER_CUSTOMER_SHARE ADD ACCOUNTS = '<USERB_ACCOUNT_IDENTIFIER>';
ALTER SHARE PROVIDER_CUSTOMER_SHARE ADD ACCOUNTS = '<USERC_ACCOUNT_IDENTIFIER>';ここまででプロバイダー側の SHARE 設定は完了です。 次の手順でコンシューマー側アカウントでの作業に進みます。
手順3 コンシューマー側アカウントでの作業
本手順は 各コンシューマー側アカウント（UserBおよびUserC） にて実施します。 プロバイダー側で作成した SHARE を利用し、共有データベースを作成します。
※ 本記事ではプロバイダー側のアカウント識別子を公開できないため、 <USERA_ACCOUNT_IDENTIFIER> をプレースホルダーとして記載しています。 実際の環境では、ご自身のプロバイダーアカウント識別子を指定してください。
共有データベースの作成
プロバイダー側で作成された SHARE を利用し、コンシューマー側アカウントに共有データベースを作成します。
下記のコマンドを実行することで、プロバイダー側が共有した PROVIDER_CUSTOMER_SHARE からデータベースが作成されます。
CREATE DATABASE CONSUMER_DB
FROM SHARE <USERA_ACCOUNT_IDENTIFIER>.PROVIDER_CUSTOMER_SHARE;手順4 動作確認
最後に、各コンシューマー側アカウントで共有データを参照し、 表示内容を確認します。
UserB：すべてのデータが表示されることを確認
UserBが共有データをSELECTして内容を確認します。
UserC：指定した列がマスキングされていることを確認
UserCが共有データをSELECTして内容を確認します。
利用シーンとメリット、注意点
利用シーン
本構成は、以下のようなケースで有効です。
- 複数の取引先企業へ同一データを提供するが、開示範囲をアカウント単位で制御したい場合
- グループ会社間でデータを共有する際に、会社ごとに閲覧可能な情報を制御したい場合
- 個人情報や機密情報を含むデータを、安全に外部共有したい場合
メリット
アカウントレベルでのマスキング制御を行うことで、 プロバイダー側がデータ公開範囲を完全にコントロールできる点が大きなメリットです。 コンシューマー側でのロール設定に依存せず、共有元で一元管理が可能となります。
注意点
本記事では、Snowflakeのデータシェアリング機能とアカウントレベルのマスキングポリシーを組み合わせた実装方法をご紹介しました。
データのコピーを伴わない安全な共有と、プロバイダー側での一元的なマスキング制御を組み合わせることで、よりセキュアかつ柔軟なデータ提供が可能になります。
本記事が、Snowflakeをご利用の方々にとって、データシェアリングやマスキング設計を考える際のヒントになれば幸いです。
