列レベルのセキュリティについて

Enterprise Editionの機能

この機能には、Enterprise Edition（またはそれ以上）が必要です。アップグレードについては、 Snowflakeサポート にお問い合わせください。

.

関連トピック

• ダイナミックデータマスキング

• 外部トークン化

このトピックでは、列レベルのセキュリティの概要と、ダイナミックデータマスキングと外部トークン化の両方に共通する機能とサポートについて説明します。

列レベルのセキュリティとは

Snowflakeの列レベルのセキュリティでは、テーブルまたはビュー内の列にマスキングポリシーを適用できます。現在、列レベルのセキュリティには2つの機能があります。

1. ダイナミックデータマスキング

2. 外部トークン化

ダイナミックデータマスキングは、マスキングポリシーを使用してクエリ時にテーブルとビューの列のプレーンテキストデータを選択的にマスクする、列レベルのセキュリティ機能です。

外部トークン化により、アカウントはデータをSnowflakeにロードする前にトークン化し、クエリ実行時にデータをトークン解除できます。トークン化とは、機密データを解読不能なトークンに置き換えて機密データを削除するプロセスです。外部トークン化は、 外部関数 でマスキングポリシーを利用します。

マスキングポリシーとは

Snowflakeは、スキーマレベルのオブジェクトとしてマスキングポリシーをサポートし、クエリ実行時に権限を持つユーザーが機密データにアクセスすることを許可しながら、機密データを不正アクセスから保護します。つまり、Snowflakeの機密データは既存のテーブルでは変更されません（つまり、静的マスキングは行われません）。むしろ、マスキングポリシーが適用されるクエリをユーザーが実行する場合は、マスキングポリシーの条件により権限のないユーザーに、マスキング済み、部分的にマスキング済み、難読化済み、トークン化済みのデータのいずれが表示されるかが決定されます。ポリシーをスキーマレベルのオブジェクトとしてマスキングすると、集中管理、分散管理、またはハイブリッド管理のアプローチを柔軟に選択できます。詳細については、 列レベルのセキュリティの管理 （このトピック内）をご参照ください。

マスキングポリシーには、条件と関数が含まれ、それらの条件が満たされた場合は、クエリの実行時にデータが変換されます。ポリシー主導型アプローチは、役割分担をサポートし、セキュリティチームが、基礎となるデータへの完全なアクセス権を通常持っているオブジェクト所有者（テーブルやビューなどのオブジェクトに対するOWNERSHIP権限を持つロール）にも、機密データの漏洩を制限できるポリシーを定義できるようになります。

たとえば、マスキングポリシーの管理者は、アナリスト（つまり、カスタムANALYSTロールを持つユーザー）には電話番号の最後の4桁のみを表示し、社会保障番号は表示せず、カスタマーサポートの担当者（つまり、カスタムSUPPORTロールを持つユーザー）には、顧客確認ユースケースのために電話番号全体と社会保障番号を表示できるようにするマスキングポリシーを実装できます。

マスキングポリシーは、単一のデータ型、1つ以上の条件、および1つ以上のマスキング関数で構成されます。

• データ型が一致する1つ以上のテーブル/ビュー列にマスキングポリシーを適用できます。たとえば、メールアドレスのポリシーを1回定義して、データベースとスキーマ全体の1000のメール列に適用できます。

• マスキングポリシー条件は、 条件式関数 と コンテキスト関数 を使用するか、カスタム資格テーブルをクエリすることで表現できます。コンテキスト関数 INVOKER_ROLE と INVOKER_SHARE は、それぞれビューと共有で使用できます。

• マスキング関数は、組み込み関数（例: REGEXP_REPLACE、 SHA2 , SHA2_HEX）、 UDFs （ユーザー定義関数）、または 外部関数 （外部トークン化プロバイダーを使用したトークン解除用）のいずれかです。

Snowflakeは、機密データへのアクセスを制限するために セキュアなビュー を提供しますが、セキュアなビューは、ビューと各ビューから派生するビジネスインテリジェンス（BI）ダッシュボードが多数になるため、管理が困難となります。マスキングポリシーは、管理するビューとダッシュボードの急増を回避することにより、この管理上の課題を解決します。

マスキングポリシーは、ポリシー管理者とオブジェクト所有者の役割を分担することで、ロール分離（SoD）をサポートします。セキュアなビューにはSoDがありません。これは、ユーティリティの重大な制限です。このロール分離により、デフォルトは次のようになります。

• オブジェクト所有者（オブジェクトに対してOWNERSHIP権限を持つロール）には、マスキングポリシーを設定解除する特権がありません。

• オブジェクト所有者には、マスキングポリシーが適用されている列データを表示できません。

ロールと権限の管理の詳細については、 列レベルのセキュリティの管理 （このトピック内）および アクセス制御権限 をご参照ください。

マスキングポリシーはどのように機能しますか？

ダイナミックデータマスキングと外部トークン化のマスキングポリシーは同じ構造と形式を採用していますが、1つの重要な例外があります。それは、外部トークン化のマスキングポリシーでは、マスキングポリシー本文で 外部関数 を使用する必要があるという点です。

この例外の理由は、外部トークン化では、データをSnowflakeにロードする前に、サードパーティのトークン化プロバイダーがデータをトークン化する必要があるためです。クエリの実行時に、Snowflakeは外部関数を使用してトークン化プロバイダーにREST API呼び出しを行ってから、トークン化ポリシー（Snowflakeの外部で作成された）を評価し、マスキングポリシー条件に基づいてトークン化または非トークン化データを返します。指定されたクエリから確実に正しいデータを返すことができるように、ロールマッピングがSnowflakeとトークン化プロバイダーに存在する必要があることに注意してください。

Snowflakeは、 CREATE MASKING POLICY を使用したマスキングポリシーの作成をサポートしています。例：

-- Dynamic Data Masking

create masking policy employee_ssn_mask as (val string) returns string ->
  case
    when current_role() in ('PAYROLL') then val
    else '******'
  end;

-- External Tokenization

  create masking policy employee_ssn_detokenize as (val string) returns string ->
  case
    when current_role() in ('PAYROLL') then ssn_unprotect(val)
    else val -- sees tokenized data
  end;

条件:

• employee_ssn_mask

  ダイナミックデータマスキングポリシーの名前。

• employee_ssn_detokenize

  外部トークン化ポリシーの名前。

• as (val string) returns string

  入力と出力のデータ型を指定します。データ型は一致する必要があります。

• ->

  マスキングポリシーステートメントの矢印を他の文字と置き換えないでください。

• case ... end;

  マスキングポリシーの本文（つまり、SQL式）の条件を指定します。

  これら2つの例では、クエリ演算子が現在のセッションでPAYROLLカスタムロールを使用している場合、演算子はマスクされていない/トークン化されていない値を確認します。それ以外の場合は、固定されたマスク/トークン化された値が表示されます。

• ssn_unprotect

  トークン化されたデータを処理する外部関数。

ちなみに

既存のマスキングポリシーを更新するために、ポリシーの現在の定義を確認する必要がある場合は、 GET_DDL 関数を呼び出すか、 DESCRIBE MASKING POLICY コマンドを実行します。

マスキングポリシー使用の詳細については、以下をご参照ください。

• テーブルとビューでの列レベルのセキュリティの使用 （このトピック）

• ダイナミックデータマスキング

• 外部トークン化

• 高度な列レベルのセキュリティトピック

クエリ実行時のマスキングポリシー

Snowflakeは、テーブルのマスキングポリシーや同テーブルのビューのマスキングポリシーなど、ネストされたマスキングポリシーをサポートしています。クエリの実行時、Snowflakeは特定のクエリに関連するすべてのマスキングポリシーを次の順序で評価します。

• テーブルに適用可能なマスキングポリシーは、必ず最初に実行されます。

• ビューのポリシーは、テーブルのポリシーを評価した後に実行されます。

• ネストされたビューが存在する場合（例：テーブル1->ビュー1->ビュー2-> ...ビューn）、ポリシーは左から右に順番に適用されます。

このパターンは、クエリ内のデータに関して存在するマスキングポリシーの数だけ続行します。次の図は、クエリ実行者、テーブル、ビュー、およびポリシー間の関係を示しています。

実行時に、Snowflakeはクエリを書き換えて、マスキングポリシー式をマスキングポリシーで指定した列に適用します。マスキングポリシーは、次のように、SQL式のどこで列が参照されるかに関係なく適用されます。

• 投影。

• JOIN述語。

• WHERE句の述語。

• ORDER BY およびGROUP BY句。

重要

マスキングポリシーは、関連する列がSQL構造体によって参照される場所に意図的に適用され、マスクされた列データを含めるためのクリエイティブクエリによるデータの匿名化を防止します。

したがって、クエリを実行して1つ以上の列でマスクされたデータが出力された場合、マスクされたデータにより目的のコンテキストですべてのクエリ出力データを評価できないため、クエリ出力が予想される値を提供しない場合があります。

次の例では、ユーザーが送信したクエリの後に、Snowflakeランタイムクエリの書き換えが続き、マスキングポリシー（<SQL_expression>）が email 列にのみ適用されることを示しています。

単純クエリ:

SELECT email, city from customers where city = 'San Mateo';

SELECT <SQL_expression>(email), city from customers where city = 'San Mateo';

次の例では、ユーザーが送信したクエリの後に、Snowflakeランタイムクエリの書き換えが続き、ここでマスキングポリシー（<SQL式>）が比較の片方のみに適用されることを示しています（メール列の比較対象である文字列でなく、メール列のみなど）。クエリの結果は、ユーザーが意図したものには なりません。比較の片側のみをマスクすることは、一般的なアンチパターンです。

WHERE句の述語で保護された列を使用したクエリ（アンチパターン）：

SELECT email from customers where email = 'user@example.com';

SELECT <SQL_expression>(email) from customers where <SQL expression>(email) = 'user@example.com';

JOIN述語で保護された列を使用したクエリ（アンチパターン）：

select b.email, d.city from sf_tuts.public.emp_basic as b join sf_tuts.public.emp_details as d on b.email = d.email;

select <SQL_expression>(b.email), d.city from sf_tuts.public.emp_basic as b join sf_tuts.public.emp_details as d on <SQL expression>(b.email) = <SQL expression>(d.email);

クエリ実行時の考慮事項

Snowflakeでは、列にマスキングポリシーを適用した場合の影響を予測する際、およびクエリオペレーターがマスキングされたデータを表示するかどうかを検討する際に、以下の要素を検討することをお勧めします。

現在のセッション

CURRENT_ROLE を使用したポリシー条件のマスキング。

実行中のロール

INVOKER_ROLE を使用したポリシー条件のマスキング。

ロール階層

IS_ROLE_IN_SESSION または IS_GRANTED_TO_INVOKER_ROLE を使用したポリシー条件のマスキング。

データ共有

Snowflake Secure Data Sharing を使用してデータを共有するかどうか。 制限事項 を参照してください（このトピック）。

複製

複製されたデータベースオブジェクト をご参照ください。

サブクエリ

マスキングポリシーは、ポリシー定義でサブクエリを参照できますが、Snowflakeでのサブクエリのサポートには制限があります。詳細については、 サブクエリの操作 をご参照ください。

最初の3つの項目については、 高度な列レベルのセキュリティトピック で詳しく説明しています。共有のコンテキストでは外部関数を呼び出すことができないため、データ共有はダイナミックデータマスキングにのみ適用されます。

最終的に、特定のユースケースによって、ダイナミックデータマスキングと外部トークン化のどちらが適しているかが決定されます。

ダイナミックデータマスキングまたは外部トークン化の選択

組織のニーズに最も合致する正しい機能を選択するには、関連する考慮事項と制限とともに、データの主な使用例を評価してください。次の2つのセクションでは、2つの機能の利点と制限をまとめています。

利点

次のテーブルは、ダイナミックデータマスキングと外部トークン化の利点を比較しています。

要素	ダイナミックデータマスキング	外部トークン化	メモ
匿名化後の分析値を保持します。		✔	トークン化は特定の文字セットに一意の値を提供するため、機密情報を公開せず、トークン化された値でレコードをグループ化することができます。たとえば、患者の診断コードをトークン化して、診断コードごとに医療記録をグループ化します。次に、データアナリストは、診断コードのビューをクエリして、一意の診断コードを持つ患者の数を取得できます。
トークン化されたデータをプリロードします。		✔	権限のないユーザーには、実際のデータ値は表示されません。サードパーティのトークン化プロバイダーが必要です。
マスクされていないデータをプリロードします。	✔		必要なのは内蔵のSnowflake機能のみで、サードパーティは必要ありません。
データ共有。	✔		外部関数はデータ共有では使用できないため、外部トークン化はできません。
使いやすさと変更管理。	✔	✔	ポリシーを1回記述して、データベースとスキーマ全体の数千の列に適用します。
データ管理とSoD。	✔	✔	オブジェクト所有者ではなく、セキュリティまたはプライバシー担当者が保護する列を決定します。 . マスキングポリシーは管理が容易であり、集中管理および分散管理モデルをサポートします。
データの承認とガバナンス。	✔	✔
ロールまたはカスタム資格によるコンテキストデータアクセス。	✔	✔	セキュリティまたはプライバシー担当者が実装するデータガバナンスをサポートし、 ACCOUNTADMIN または SECURITYADMIN のロールを持つ権限ユーザーがデータを不必要に表示することを禁止できます。
データベースの複製	✔	✔	複製されたデータベースオブジェクト をご参照ください。

制限事項

次のテーブルでは、列レベルのセキュリティに対する現在の制限について説明します。チェックマーク（つまり、 ✔）は、機能が制限されているか、現在サポートされていないことを示します。

制限事項	ダイナミックデータマスキング	外部トークン化	メモ
GEOGRAPHY データ型	✔	✔	このデータ型ではマスキングポリシーを使用できません。
共有オブジェクト。	✔	✔	動的データマスキングの場合、テーブルまたはビュー列のマスキングポリシーが外部関数を参照していると、テーブルまたはビューを共有できません。 . データ共有コンシューマーとして、共有データベースまたはテーブルにマスキングポリシーを適用することはできません。回避策として、共有データベースまたはテーブルをインポートし、マスキングポリシーを共有するデータベースまたはテーブルのローカルビューに適用します。 . 外部トークン化の場合、共有のコンテキストで外部関数を呼び出すことができないため、 Secure Data Sharing は適用されません。
マテリアライズドビュー（MV）。	✔	✔	包括的な要約については、 マテリアライズドビュー列にマスキングポリシーを適用する （このトピック内）をご参照ください。
DROP MASKING POLICY	✔	✔	ポリシーを削除する前に、 ALTER TABLE ... ALTER COLUMN または ALTER VIEW を使用して、テーブルまたはビューの列からポリシーを設定解除してください。
DROP DATABASE および DROP SCHEMA	✔	✔	データベースまたはスキーマをドロップするには、マスキングポリシーとそのマッピングがデータベースまたはスキーマ内で自己完結している必要があります。 . たとえば、 database_1 には policy_1 が含まれ、 policy_1 は database_1 でのみ使用されます。
仮想列。	✔	✔	マスキングポリシーは仮想列に適用できません。ポリシーはソーステーブル列またはビュー列に適用してください。
ポリシー定義の入力および出力のさまざまなデータ型。	✔	✔	マスキングポリシー定義は、入力と出力で同じデータ型である必要があります。つまり、代表的な例として、入力データ型をタイムスタンプとして定義して文字列を返すことはできません。
ポリシー変更管理のマスキング。	✔	✔	オプションで、選択したバージョン管理システムにマスキングポリシーの変更を保存して追跡できます。

考慮事項

• ソース列にマスキングポリシーがあるソース列から、ターゲット列にマスキングポリシーがないターゲット列に値を挿入する場合は、注意が必要です。ソース列にマスキングポリシーが設定されているため、マスクされていない列データを表示するロールは、マスクされていないデータを別の列に挿入できます。テーブルまたはビューに対して十分な権限を持つロールは、値を表示できます。

• ソース列でマスクされたデータを参照するロールがそれらの値をターゲット列に挿入する場合、挿入された値はマスクされたままになります。ターゲット列にマスキングポリシーが設定されていない場合、テーブルまたはビューに対して十分な権限を持つユーザーには、ターゲット列にマスクされた値とマスクされていない値の組み合わせが表示される場合があります。したがって、ベストプラクティスとして:

  • 列にマスキングポリシーを適用する場合は注意が必要です。

  • テーブルとビューをユーザーが利用できるようにする前に、マスキングポリシーのある列を使用してクエリを確認します。

  • ソース列のデータが表示される可能性のある追加のテーブルとビュー（つまり、ターゲット列）を決定します。

  • 詳細については、（このトピックの） マスキングポリシーを使用して列を取得する をご参照ください。

テーブルとビューでの列レベルのセキュリティの使用

Snowflakeは、テーブルとビューによるマスキングポリシーをサポートしています。以下に、マスキングポリシーがSnowflakeのテーブルとビューにどのように影響するかを説明します。

列にマスキングポリシーを適用する

マスキングポリシーポリシーをテーブルまたはビューの列に適用するには、次のステートメントを実行します。

-- table
ALTER TABLE IF EXISTS user_info MODIFY COLUMN ssn_number SET MASKING POLICY ssn_mask;

-- view
ALTER VIEW user_info_v MODIFY COLUMN ssn_number SET MASKING POLICY ssn_mask_v;

構文と使用の詳細については、 ALTER TABLE ... ALTER COLUMN および ALTER VIEW をご参照ください。

マテリアライズドビュー列にマスキングポリシーを適用する

Snowflakeでは、マテリアライズドビュー列にマスキングポリシーを設定できます。クエリの実行時にクエリプランは、マテリアライズドビューの書き換えを作成する前に、存在するマスキングポリシーを実行します。マテリアライズドビューの書き換えが発生すると、マテリアライズドビューの列にマスキングポリシーを設定することはできません。

マテリアライズドビューにマスキングポリシーを設定するには、マテリアライズドビューで ALTER VIEW ... MODIFY COLUMN ステートメントを実行します。

さらに、マスキングポリシーとマテリアライズドビューに関して、次の2つの制限があります。

1. 基になるテーブルまたはビューからマテリアライズドビューがすでに作成されている場合は、テーブルまたはビューにマスキングポリシーを設定することはできません。これを試行すると、Snowflakeは次のエラーメッセージを返します。

   SQL execution error: One or more materialized views exist on the table. number of mvs=<number>, table name=<table_name>.
   

2. 基になるテーブルまたはビューの列にマスキングポリシーが設定されていて、そのテーブルまたはビューからマテリアライズドビューが作成されている場合、マテリアライズドビューには、マスキングポリシーで保護されていない列のみが含まれます。マスキングポリシーで保護された1つ以上の列を含めようとすると、Snowflakeは次のエラーメッセージも返します。

   Unsupported feature 'CREATE ON MASKING POLICY COLUMN'.
   

マスキングポリシーを使用して列を取得する

マスキングポリシーを含む列のリストを取得するには、次のステートメントを実行します。詳細については、 POLICY_REFERENCES をご参照ください。

SELECT * from table(information_schema.policy_references(policy_name=>'<policy_name>'));

DESCRIBE TABLE または DESCRIBE VIEW ステートメントを実行して、テーブルまたはビューの列のマスキングポリシーを表示します。

マスキングポリシーのハッシュ、暗号化、および暗号化関数

ハッシュ および 暗号化/チェックサム は、機密データをマスクするためのマスキングポリシーで使用できます。

詳細については、 高度な列レベルのセキュリティトピック を参照してください。

外部テーブル

外部テーブルで ALTER EXTERNAL TABLE ステートメントを実行することにより、マスキングポリシーを外部テーブルの VALUE 列に適用できます。

ALTER EXTERNAL TABLE <name> MODIFY COLUMN VALUE SET MASKING POLICY <policy_name>;

マスキングポリシーを仮想列に直接適用することはできません。代わりに、外部テーブルでビューを作成し、ビューの列にマスキングポリシーを適用します。

ストリーム

テーブルの列のマスキングポリシーは、同じテーブルのストリームに引き継がれます。

その結果、権限のないユーザーにはマスクされたデータが表示されます。権限のあるユーザーが作成したストリームには、マスキングポリシーで定義されたデータが表示されます。

CLONEDオブジェクト

次のアプローチは、クローンされたオブジェクトにアクセスする際にSELECT権限を持つユーザーからデータを保護するのに役立ちます。

• 個別のマスキングポリシーオブジェクトの複製はサポートされていません。

• スキーマを複製すると、スキーマ内のすべてのマスキングポリシーが複製されます。

• 複製されたテーブルは、ソーステーブルと同じマスキングポリシーにマップされます。

  • テーブルがその親スキーマの複製コンテキストで複製されると、ソーステーブルに同じ親スキーマのマスキングポリシーへの参照（ローカル参照）がある場合、複製されたテーブルは複製されたマスキングポリシーへの参照を持つことになります。

  • ソーステーブルが別のスキーマのマスキングポリシー（外部参照など）を参照している場合、複製されたテーブルは外部参照を保持します。

詳細については、 CREATE <オブジェクト> ... CLONE をご参照ください。

CREATE TABLE ... AS SELECT（CTAS）ステートメント

CREATE TABLE…AS SELECT（CTAS）ステートメントを実行すると、新しいテーブルにデータが入力される 前 にステートメントに含まれる列にマスキングポリシーが適用されます（該当する列データは新しいテーブルでマスクされる）。CTAS ステートメントを使って作成されたテーブルには、ソースオブジェクトとは異なる列のセットがあり、Snowflakeはマスキングポリシーを新しいテーブルの列に暗黙的に適用できないため、このフローは順守されます。

マスクされていないデータをコピーする必要がある場合は、保護されたデータに対する許可があるロールを使用して、 CTAS ステートメントを実行します。新しいテーブルを作成したら、新しいテーブルの所有権を別のロールに転送し、マスキングポリシー管理者にマスキングポリシーを新しいテーブルの列に適用するよう依頼します。

詳細については、 CREATE TABLE をご参照ください。

集計関数とマスクされた列を使用したクエリ

マスクされたデータを含む列で 集計関数 を使用することが可能です。

代表的な使用例としては、データアナリストが実際のデータを確認しなくても、社会保障番号の列の COUNT を取得する場合が挙げられます。ただし、データアナリストがマスクされたテーブル列で SELECT を使用してクエリを実行すると、クエリは固定マスク値を返します。現在のセッションのPAYROLLカスタムロールを持つユーザーにはマスクされていないデータが表示され、他のすべてのユーザーにはマスクされたデータが表示されます。

この結果を達成するには：

1. テーブル所有者が、集計関数を含む列にビューを作成します。

   CREATE VIEW ssn_count AS SELECT DISTINCT(ssn) FROM table1;
   

2. ビューに対する完全な権限をANALYSTロールに付与します。アナリストにはテーブルに関する権限を付与しないでください。

3. マスキングポリシーをテーブル列に適用します。ビュー列にポリシーがある場合、テーブルポリシーは常にビューポリシーの前に適用されることに注意してください。

   case
     when current_role() in ('PAYROLL') then val
     else '***MASKED***'
   end;
   

4. ビュー列でクエリを実行します。

   use role ANALYST;
   select count(DISTINCT SSN) from <view>;
   

クエリプロファイル

マスキングポリシーを含む列で使用すると、 EXPLAIN コマンドの出力には、マスキングポリシーの本体ではなく、マスキングされたデータが含まれます。

次の例では、従業員識別番号と社会保障番号のテーブルに対するクエリの EXPLAIN プランを生成します。この例のコマンドは、 JSON 形式で例を生成します。

社会保障番号を含む列にはマスキングポリシーがあります。

explain using json select * from mydb.public.ssn_record;

{
  "GlobalStats": {
    "partitionsTotal": 0,
    "partitionsAssigned": 0,
    "bytesAssigned": 0
  },
  "Operations": [
    [
      {
        "id": 0,
        "operation": "Result",
        "expressions": [
          "1",
          "'**MASKED**'"
        ]
      },
      {
        "id": 1,
        "parent": 0,
        "operation": "Generator",
        "expressions": [
          "1"
        ]
      }
    ]
  ]
}

データのアンロード

マスキングポリシーを持つ列で COPY INTO <場所> コマンドを使用すると、マスキングポリシーがデータに適用されます。したがって、許可のないユーザーには、コマンドの実行後にマスクされたデータを表示します。

列レベルのセキュリティの管理

このセクションでは、マスキングポリシーに対する全体的な管理アプローチを決定するのに役立つ情報を提供し、列レベルのセキュリティを管理するために必要な権限について説明し、サポートされている DDL コマンドをリストします。

集中、ハイブリッド、または分散のアプローチの選択

ダイナミックデータマスキングと外部トークン化ポリシーを効果的に管理するには、列内のマスキングデータへのアプローチが、集中型セキュリティアプローチ、分散型アプローチ、またはこれら2つのアプローチのハイブリッドのうちどれに従うべきかを検討することが役立ちます。

次のテーブルは、これら2つのアプローチのそれぞれに関する考慮事項の一部をまとめたものです。

ポリシーアクション	集中管理	ハイブリッド管理	分散管理
ポリシーを作成する	セキュリティ責任者	セキュリティ責任者	個別チーム
列にポリシーを適用する	セキュリティ責任者	個別チーム	個別チーム

Snowflakeでは、ベストプラクティスとして、組織内で関連するすべての関係者を集め、環境に列レベルのセキュリティを実装するための最適な管理アプローチを決定することをお勧めします。

マスキングポリシー権限

このセクションでは、列レベルのセキュリティマスキングポリシー権限と、それらが集中、分散、またはハイブリッド管理アプローチにどのように適用されるかについて説明します。

Snowflakeは、列レベルのセキュリティのマスキングポリシーに対して次の権限を提供します。

権限	使用法
APPLY	マスキングポリシーのポリシー設定/設定解除操作の適用を有効にします。
OWNERSHIP	マスキングポリシーの完全な制御を許可するマスキングポリシーの所有権を譲渡します。マスキングポリシーのほとんどのプロパティを変更するために必要です。

注釈

マスキングポリシー上で動作するには、親データベースとスキーマでの USAGE 権限も必要です。

次の例は、権限の付与がさまざまな管理アプローチにどのように適用されるかを示しています。APPLY 権限をロールに付与した後、マスキングポリシーは、 ALTER TABLE ... ALTER COLUMN ステートメントを使用してテーブル列に設定するか、 ALTER VIEW ステートメントを使用してビュー列に設定できます（マスキングポリシーの APPLY 権限を持つロールのメンバーにより）。

集中管理

集中管理アプローチでは、セキュリティ担当者のカスタムロール（例： SECURITY_OFFICER）のみがマスキングポリシーを作成し、テーブルまたはビューの列に適用します。このアプローチにより、最も一貫したマスキングポリシー管理と機密データのマスキングを提供できます。

-- create a SECURITY_OFFICER custom role

use role accountadmin;
create role security_officer;

-- grant CREATE AND APPLY masking policy privileges to the SECURITY_OFFICER custom role.

grant create masking policy on schema <schema_name> to role security_officer;

grant apply masking policy on account to role security_officer;

条件:

• スキーマ名

  スキーマの識別子を指定します。スキーマが作成されるデータベースに対して一意である必要があります。

  また、識別子はアルファベット文字で始まる必要があり、識別子文字列全体が二重引用符で囲まれていない限り、スペースや特殊文字を含めることはできません（例："私のオブジェクト"）。二重引用符で囲まれた識別子も大文字と小文字が区別されます。

  詳細については、 識別子の要件 をご参照ください。

ハイブリッド管理

ハイブリッド管理アプローチでは、セキュリティ担当者のカスタムロール（例： SECURITY_OFFICER）がマスキングポリシーを作成し、個々のチーム（例：財務、給与、人事）が、チームの所有するテーブルまたはビューの列にマスキングポリシーを適用します。このアプローチにより、一貫したポリシーの作成と保守を実現できますが、機密データをマスクする責任を個々のチームに持たせる必要があります。

-- create a SECURITY_OFFICER custom role

use role accountadmin;
create role security_officer;

-- grant the CREATE masking policy privilege to the SECURITY_OFFICER role.

grant create masking policy on schema <schema_name> to role security_officer;

SECURITY_OFFICER カスタムロールは、 APPLY 権限を人事チーム（つまり、 HUMAN_RESOURCES カスタムロールを持つユーザー）に付与し、 HUMAN_RESOURCES カスタムロールが所有するオブジェクトの列の社会保障番号（例：マスキングポリシー： ssn_mask）をマスクします。

grant apply on masking policy ssn_mask to role human_resources;

条件:

• grant apply on masking policy ポリシー名 to role ロール名;

  ポリシー所有者が、列における特定のマスキングポリシーの設定解除、および設定操作をオブジェクト所有者に分散するために使用します。

  この権限は、オブジェクトの所有者もデータスチュワードと見なされる 任意のアクセス制御 をサポートします。

分散型アプローチ

分散管理アプローチでは、個々のチームがマスキングポリシーを作成して、テーブルまたはビューの列に適用します。個々のチームがマスキングポリシーの管理と機密データのマスキングに関するすべての責任を負うため、このアプローチは一貫性のないポリシー管理につながり、機密データが適切にマスクされない可能性があります。

この代表的な例では、サポートチーム（つまり、カスタムロール SUPPORT のユーザー）と財務チーム（つまり、カスタムロール FINANCE のユーザー）がマスキングポリシーを作成できます。これらのカスタムロールには、SECURITY_OFFICERカスタムロールが含まれない場合があることに注意してください。

use role accountadmin;

-- grant masking policy privileges to the SUPPORT custom role.

grant create masking policy on schema <schema_name> to role support;

-- grant masking policy privileges to the FINANCE custom role.

grant create masking policy on schema <schema_name> to role finance;

サポートチームは、 APPLY 権限を人事チーム（つまり、カスタムロール HUMAN_RESOURCES を持つユーザー）に付与し、 HUMAN_RESOURCES カスタムロールが所有するオブジェクトの列の社会保障番号（例：マスキングポリシー： ssn_mask）をマスクします。

use role support;
grant apply on masking policy ssn_mask to role human_resources;

財務チームは、内部監査チーム（つまり、カスタムロール AUDIT_INTERNAL のユーザー）に APPLY 権限を付与し、 AUDIT_INTERNAL カスタムロールが所有するオブジェクトの列のキャッシュフローデータ（例：マスキングポリシー： cash_flow_mask）をマスクします。

use role finance;
grant apply on masking policy cash_flow_mask to role audit_internal;

ポリシー権限のマスキングの詳細については、以下をご参照ください。

• ダイナミックデータマスキングの使用

• 外部トークン化の使用

マスキングポリシー DDL

Snowflakeは、列レベルのセキュリティマスキングポリシーを管理するための以下のコマンドセットを提供します。

• CREATE MASKING POLICY

• ALTER MASKING POLICY （ ALTER TABLE、 ALTER TABLE ... ALTER COLUMN、 ALTER VIEW も参照）

• DROP MASKING POLICY

• SHOW MASKING POLICIES

• DESCRIBE MASKING POLICY

次のテーブルは、列レベルのセキュリティマスキングポリシー DDL 操作と必要な権限の関係をまとめたものです。

操作	必要な権限
マスキングポリシーを作成する	CREATE MASKING POLICY SCHEMA権限を持つロール。
マスキングポリシーを変更する	マスキングポリシーの所有者（つまり、マスキングポリシーに対するOWNERSHIP権限を持つロール）。
マスキングポリシーを削除する	マスキングポリシーの所有者（つまり、マスキングポリシーに対するOWNERSHIP権限を持つロール）。
マスキングポリシーを表示する	次のいずれか： . グローバルAPPLY MASKING POLICY権限を持つロール、 または . マスキングポリシーの所有者（マスキングポリシーに対するOWNERSHIP権限を持つロール）。
マスキングポリシーを説明する	次のいずれか： . グローバルAPPLY MASKING POLICY権限を持つロール、 または . マスキングポリシーの所有者（マスキングポリシーに対するOWNERSHIP権限を持つロール）。
列のマスキングポリシーをSET/UNSETする	次のいずれかです： . グローバルAPPLY MASKING POLICY権限を持つロール、 または . 特定のマスキングポリシーに対するMASKING POLICY権限でAPPLYを持つロール および にOWNERSHIPがあるターゲットテーブル/ビュー。
マスキングポリシーを持つ列のリスト	次のいずれか： . APPLY MASKING POLICY権限を持つロール、 または . 特定のマスキングポリシーに対するMASKING POLICY権限でAPPLYを持つロール および ターゲットオブジェクトにOWNERSHIPがあるロール。
マスキングポリシーでのUDFsの使用	新しいマスキングポリシーを作成するか、既存のマスキングポリシーを変更する場合、ポリシー管理者ロールはUDFで使用し、ポリシー式のすべてのスカラーUDFsは同じデータ型であり、UDFが存在する必要があります。 . クエリの実行時に、SnowflakeはUDFが存在するかどうかを確認します。存在しない場合、SQL式は解決されず、クエリは失敗します。

次のトピック：

• ダイナミックデータマスキング
• 外部トークン化