列レベルのセキュリティについて¶
この機能には、Enterprise Edition（またはそれ以上）が必要です。アップグレードについては、 Snowflakeサポート にお問い合わせください。
このトピックでは、列レベルのセキュリティの概要と、ダイナミックデータマスキングと外部トークン化の両方に共通する機能とサポートについて説明します。
タグでマスキングポリシーを使用する方法の詳細については、 タグベースのマスキングポリシー をご参照ください。
列レベルのセキュリティとは¶
Snowflakeの列レベルのセキュリティでは、テーブルまたはビュー内の列にマスキングポリシーを適用できます。現在、列レベルのセキュリティには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 コマンドを実行します。
マスキングポリシーの定義は、 ALTER MASKING POLICY コマンドで更新できます。マスキングポリシーが列に設定されている場合、このコマンドでは列からマスキングポリシーを設定解除する必要はありません。したがって、ポリシーによって保護されている列は、ポリシー定義が更新されている間も保護されたままになります。
マスキングポリシー使用の詳細については、以下をご参照ください。
テーブルとビューでの列レベルのセキュリティの使用 （このトピック）
IS_ROLE_IN_SESSION （ロール階層とロールのアクティブ化が重要な場合のポリシーの例）
条件付き列の使用¶
条件付きマスキングでは、マスキングポリシーを使用して、1つ以上の異なる列の値に基づいてテーブルまたはビューの列データを選択的に保護します。
別の列を使用して特定の列のデータを保護する必要があるかどうかを判断すると、ポリシー管理者（つまり、 POLICY_ADMIN カスタムロールを持つユーザー）がポリシー条件をより自由に作成できるようになります。
2つの代表的なポリシーの例の違いに注意してください。
- マスキングポリシー
このポリシーは、動的データマスキングに使用できます。
create masking policy email_mask as (val string) returns string -> case when current_role() in ('PAYROLL') then val else '******' end;
このポリシーは、文字列データを含む列を表す1つの引数
valのみを指定します。このポリシーは一度作成すると、文字列データを含む任意の列に適用できます。 CURRENT_ROLE がPAYROLLカスタムロールであるユーザーのみが、列データを表示できます。それ以外の場合、Snowflakeは固定のマスクされた値をクエリ結果に返します。詳細については、 CREATE MASKING POLICY をご参照ください。
- 条件付きマスキングポリシー
この例にある引数
(email varchar, visibility string)に注意してください。create masking policy email_visibility as (email varchar, visibility string) returns varchar -> case when current_role() = 'ADMIN' then email when visibility = 'Public' then email else '***MASKED***' end;
このポリシーは、
emailとvisibilityの2つの引数を指定しており、これらの引数は列名です。最初の列は 常に、マスクする列を指定します。2番目の列は、最初の列をマスクする必要があるかどうかを評価するための条件付き列です。複数の条件列を指定できます。このポリシーでは、 CURRENT_ROLE がADMINカスタムロールであるユーザーがメールアドレスを表示できます。電子メールアドレスの可視性列の値もPublicの場合、そのメールアドレスはクエリ結果に表示されます。それ以外の場合、Snowflakeは、メール列のマスクされた値が固定されたクエリ結果を返します。このポリシーは、テーブルまたはビューの列構造がポリシーで指定された列と一致する場合に、複数のテーブルおよびビューで使用できます。詳細については、 CREATE MASKING POLICY をご参照ください。
代表的な例ごとに同じオブジェクトタイプが使用されているため、ポリシーの全体的な動作は類似しています。これには、以下が含まれますが、これらに限定されません。
実行時評価をクエリします。
ユーティリティ（例: コンテキスト関数 の使用による、機密データの保護）。
権限構造。
職務の分離をサポートするためのさまざまな管理アプローチでの使用（SoD）。
- 制限事項
既存の マスキングポリシーの制限 に加えて、条件付きマスキングポリシーには次の制限があります。
- 考慮事項
条件付きマスキングポリシーを使用する前に、既存で通常の マスキングポリシーの考慮事項 に加えて、次の点を評価してください。
CREATE MASKING POLICY ステートメントで指定されたすべての列が、同じテーブルまたはビューにあることを確認します。
ポリシー定義の列引数の数を最小限に抑えます。Snowflakeは、クエリの実行時に各列を評価する必要があります。指定する列の数を減らすと、全体的なパフォーマンスが向上します。
Information Schemaテーブル関数 POLICY_REFERENCES を呼び出して、マスキングポリシーの条件付き列の使用状況を追跡します。
条件付き列を使用したマスキングポリシーの設定の詳細については、 列に条件付きマスキングポリシーを適用する （このトピック内）をご参照ください。
クエリ実行時のマスキングポリシー¶
実行時に、Snowflakeはクエリを書き換えて、マスキングポリシー式をマスキングポリシーで指定した列に適用します。マスキングポリシーは、次のように、SQL式のどこで列が参照されるかに関係なく適用されます。
投影。
JOIN述語。
WHERE句の述語。
ORDER BY およびGROUP BY句。
重要
マスキングポリシーは、関連する列がSQL構造体によって参照される場所に意図的に適用され、マスクされた列データを含めるためのクリエイティブクエリによるデータの匿名化を防止します。
したがって、クエリを実行して1つ以上の列でマスクされたデータが出力された場合は、マスクされたデータにより目的のコンテキストですべてのクエリ出力データを評価できないため、クエリ出力が望ましい値を提供しない可能性があります。
ネストされたオブジェクトを使用したポリシーのマスキング:
Snowflakeは、テーブルのマスキングポリシーや同じテーブルのビューのマスキングポリシーなど、ネストされたマスキングポリシーをサポートしています。クエリの実行時、Snowflakeは特定のクエリに関連するすべてのマスキングポリシーを次の順序で評価します。
テーブルに適用可能なマスキングポリシーは、必ず最初に実行されます。
ビューのポリシーは、テーブルのポリシーを評価した後に実行されます。
ネストされたビューが存在する場合（例:
table_1»view_1»view_2» ...view_n）、ポリシーは左から右へ順番に適用されます。このパターンは、クエリ内のデータに関して存在するマスキングポリシーの数だけ続行します。次の図は、クエリ実行者、テーブル、ビュー、およびポリシー間の関係を示しています。
ユーザークエリ:
次の例では、ユーザーが送信したクエリの後に、Snowflakeランタイムクエリの書き換えが続き、マスキングポリシー（つまり、
sql_expression）が email 列にのみ適用されることを示しています。SELECT email, city from customers where city = 'San Mateo'; SELECT <SQL_expression>(email), city from customers where city = 'San Mateo';
WHERE句の述語で保護された列を使用したクエリ（アンチパターン）：
次の例では、ユーザーが送信したクエリの後に、Snowflakeランタイムクエリの書き換えが続き、ここでマスキングポリシー（つまり、
sql_expression）が比較の片方のみに適用されることを示しています（例: メール列の比較対象である文字列でなく、メール列）。クエリの結果は、ユーザーが意図したものには なりません。比較の片側のみをマスクすることは、一般的なアンチパターンです。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でのサブクエリのサポートには制限があります。詳細については、 サブクエリの操作 をご参照ください。
- マスキングポリシーでの UDFs の使用
列、 UDF、およびマスキングポリシーのデータ型が一致していることを確認します。詳細については、 マスキングポリシー内のユーザー定義関数 （このトピック内）をご参照ください。
- 検索最適化サービス
検索最適化サービスは、マスキングまたは行アクセスポリシーを使用するテーブルでのクエリパフォーマンスを向上させることができます。
詳細については、 検索最適化サービスにおける、マスキングポリシーと行アクセスポリシーを使用したテーブルのサポート をご参照ください。
最初の3つの項目については、 高度な列レベルのセキュリティトピック で詳しく説明しています。共有のコンテキストでは外部関数を呼び出すことができないため、データ共有はダイナミックデータマスキングにのみ適用されます。
最終的に、特定のユースケースによって、ダイナミックデータマスキングと外部トークン化のどちらが適しているかが決定されます。
ダイナミックデータマスキングまたは外部トークン化の選択¶
組織のニーズに最も合致する正しい機能を選択するには、関連する考慮事項と制限とともに、データの主な使用例を評価してください。次の2つのセクションでは、2つの機能の利点と制限をまとめています。
利点¶
次のテーブルは、ダイナミックデータマスキングと外部トークン化の利点を比較しています。
要素 |
ダイナミックデータマスキング |
外部トークン化 |
メモ |
|---|---|---|---|
匿名化後の分析値を保持します。 |
✔ |
トークン化は特定の文字セットに一意の値を提供するため、機密情報を公開せず、トークン化された値でレコードをグループ化することができます。 たとえば、患者の診断コードをトークン化して、診断コードごとに医療記録をグループ化します。次に、データアナリストは、診断コードのビューをクエリして、一意の診断コードを持つ患者の数を取得できます。 |
|
トークン化されたデータをプリロードします。 |
✔ |
権限のないユーザーには、実際のデータ値は表示されません。サードパーティのトークン化プロバイダーが必要です。 |
|
マスクされていないデータをプリロードします。 |
✔ |
必要なのは内蔵のSnowflake機能のみで、サードパーティは必要ありません。 |
|
データ共有。 |
✔ |
詳細については、 データ共有 （このトピック内）をご参照ください。 |
|
使いやすさと変更管理。 |
✔ |
✔ |
ポリシーを1回記述して、データベースとスキーマ全体の数千の列に適用します。 |
データ管理と SoD。 |
✔ |
✔ |
セキュリティまたはプライバシー担当者は、オブジェクト所有者ではなく、保護する列を決定します。 マスキングポリシーは管理が容易であり、集中型管理モデルと分散型管理モデルをサポートします。 |
データの認証とガバナンス。 |
✔ |
✔ |
|
ロールまたはカスタム資格によるコンテキストデータアクセス。 |
✔ |
✔ |
セキュリティまたはプライバシー担当者が実装するデータガバナンスをサポートし、 ACCOUNTADMIN または SECURITYADMIN のシステムロールを持つ権限ユーザーがデータを不必要に表示することを禁止できます。 |
データベース複製およびアカウントオブジェクト複製。 |
✔ |
✔ |
複製 （このトピック内）をご参照ください。 |
制限事項¶
次のテーブルでは、列レベルのセキュリティに対する現在の制限について説明します。チェックマーク（つまり、 ✔）は、機能が制限されているか、現在サポートされていないことを示します。
制限事項 |
ダイナミックデータマスキング |
外部トークン化 |
メモ |
|---|---|---|---|
共有オブジェクト。 |
✔ |
✔ |
詳細については、 データ共有 （このトピック内）をご参照ください。 |
マテリアライズドビュー（MV）。 |
✔ |
✔ |
包括的な要約については、 マテリアライズドビュー （このトピック内）をご参照ください。 |
✔ |
✔ |
ポリシーをドロップする前に、 ALTER TABLE ... ALTER COLUMN または ALTER VIEW を使用して、テーブルまたはビューの列からポリシーの設定を解除します。 |
|
✔ |
✔ |
データベースまたはスキーマをドロップするには、マスキングポリシーとそのマッピングがデータベースまたはスキーマ内で自己完結している必要があります。 たとえば、 |
|
仮想列。 |
✔ |
✔ |
マスキングポリシーは仮想列に適用できません。ポリシーをソーステーブル列またはビュー列に適用します。 |
外部テーブル。 |
✔ |
✔ |
外部テーブルをルックアップテーブルとして（つまり、サブクエリで）参照して、列の値をマスクする必要があるかどうかを判断することはできません。詳細については、 外部テーブル （このトピック内）をご参照ください |
ポリシー定義の入力および出力のさまざまなデータ型。 |
✔ |
✔ |
マスキングポリシー定義は、入力と出力で同じデータ型である必要があります。つまり、代表的な例として、入力データ型をタイムスタンプとして定義して文字列を返すことはできません。 |
ポリシー変更管理のマスキング。 |
✔ |
✔ |
オプションで、選択したバージョン管理システムにマスキングポリシーの変更を保存して追跡できます。 |
✔ |
✔ |
マスキングポリシーに対する権限の 将来の付与 はサポートされていません。 回避策として、カスタムロールに APPLY MASKING POLICY 権限を付与して、そのロールがテーブルまたはビューの列にマスキングポリシーを適用できるようにします。 |
考慮事項¶
ソース列にマスキングポリシーがあるソース列から、ターゲット列にマスキングポリシーがないターゲット列に値を挿入する場合は、注意が必要です。ソース列にマスキングポリシーが設定されているため、マスクされていない列データを表示するロールは、マスクされていないデータを別の列に挿入できます。テーブルまたはビューに対して十分な権限を持つロールは、値を表示できます。
ソース列でマスクされたデータを参照するロールがそれらの値をターゲット列に挿入する場合、挿入された値はマスクされたままになります。ターゲット列にマスキングポリシーが設定されていない場合、テーブルまたはビューに対して十分な権限を持つユーザーには、ターゲット列にマスクされた値とマスクされていない値の組み合わせが表示される場合があります。したがって、ベストプラクティスとして:
列にマスキングポリシーを適用する場合は注意が必要です。
テーブルとビューをユーザーが利用できるようにする前に、マスキングポリシーのある列を使用してクエリを確認します。
ソース列のデータが表示される可能性のある追加のテーブルとビュー（つまり、ターゲット列）を決定します。
詳細については、（このトピックの） マスキングポリシーを使用して列を取得する をご参照ください。
テーブルとビューでの列レベルのセキュリティの使用¶
Snowflakeは、テーブルとビューによるマスキングポリシーをサポートしています。以下に、マスキングポリシーがSnowflakeのテーブルとビューにどのように影響するかを説明します。
ちなみに
POLICY_CONTEXT 関数を呼び出して、マスキングポリシーで保護されている列、行アクセスポリシーで保護されているテーブルまたはビュー、または両方のタイプのポリシーでクエリをシミュレートします。
アクティブロール階層およびマッピングテーブル¶
ポリシー条件は、ポリシー管理者がポリシーを記述する方法次第で、セッションで直接ユーザーのアクティブなプライマリロールとセカンダリロールを評価したり、マッピングテーブルでアクティブなロールを検索したり、その両方を実行したりできます。
これらのユースケースでは、ポリシー条件を記述して IS_ROLE_IN_SESSION コンテキスト関数を呼び出すことをお勧めします。ポリシーの例については、IS_ROLE_IN_SESSION 関数の 例 セクションを参照してください。
コンテキスト関数およびマスキングポリシーに関するその他の例は 高度な列レベルのセキュリティトピック をご参照ください。
列へのマスキングポリシーの適用¶
列がマスキングポリシーで保護されていない場合、テーブルまたはビューの列にマスキングポリシーを適用するには、次の2つのオプションがあります。
新しい テーブルまたはビューを使用して、 CREATE TABLE ステートメントを含むテーブル列または CREATE VIEW ステートメントを含むビュー列にポリシーを適用します。
既存の テーブルまたはビューを使用して、 ALTER TABLE ... ALTER COLUMN ステートメントを含むテーブル列または ALTER VIEW ステートメントを含むビュー列にポリシーを適用します。
新しい テーブルまたはビューの場合は、次のステートメントを実行します。
-- table create or replace table user_info (ssn string masking policy ssn_mask); --view create or replace view user_info_v (ssn masking policy ssn_mask_v) as select * from user_info;
既存の テーブルまたはビューの場合は、次のステートメントを実行します。
-- 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 をご参照ください。
マスキングポリシーで UDF を使用する場合は、 マスキングポリシー内のユーザー定義関数 （このトピック内）をご参照ください。
列に条件付きマスキングポリシーを適用する¶
条件付き列 を使用してマスキングポリシーを 作成 した後、マスキングポリシーですでに保護されていない列に条件付きマスキングポリシーを設定するための2つのオプションがあります。
新しい テーブルまたはビューの場合は、対応する CREATE ステートメントを使用してテーブルまたはビュー列にポリシーを適用します。
構文および使用方法の詳細については、次をご参照ください。
新しい テーブルまたはビューの場合は、次のステートメントを実行します。
-- table create or replace table user_info (email string masking policy email_visibility) using (email, visibility); --view create or replace view user_info_v (email masking policy email_visibility) using (email, visibility) as select * from user_info;
既存の テーブルまたはビューの場合は、対応する ALTER ステートメントを使用してテーブルまたはビュー列にポリシーを設定します。
構文および使用方法の詳細については、次をご参照ください。
既存の テーブルまたはビューの場合は、次のステートメントを実行します。
-- table alter table if exists user_info modify column email set masking policy email_visibility using (email, visibility); -- view alter view user_info_v modify column email set masking policy email_visibility using (email, visibility);
列のマスキングポリシーを置き換える¶
列のマスキングポリシー設定後には、テーブルまたはビュー全体を置き換えることなく、列のマスキングポリシーを別のマスキングポリシーに置き換えるための2つの異なる経路があります。
これらの例では、 ALTER TABLE コマンドを使用しています。 ALTER VIEW コマンドを使用したビューにも同じアプローチが適用されます。
1つのステートメントでテーブル列からポリシーを設定解除し、別のステートメントでその列に新しいポリシーを設定します。
alter table t1 modify column c1 unset masking policy; alter table t1 modify column c1 set masking policy p2;
FORCEキーワードを使用して、単一のステートメントでポリシーを置き換えます。alter table t1 modify column c1 set masking policy p2 force;
注意:
FORCEキーワードでは、 ALTER TABLE ステートメント内のポリシーの データ型 （つまり、 STRING）が、列に現在設定されているマスキングポリシーのデータ型（つまり、 STRING）と一致する必要があります。FORCEキーワードは、USING句と組み合わせて、列に条件付きマスキングポリシーを設定できます。alter table t1 modify column c1 set masking policy policy1 using (c1, c3, c4) force;
重要
列のマスキングポリシーを置き換えるときは注意してください。
列の置換とクエリのタイミングによっては、 UNSET 操作と SET 操作との時間間隔で列データが保護されない期間が発生するため、2つの別々のステートメントでポリシーを置き換えることを選択すると、データリークが発生する可能性があります。
ただし、置換ポリシーでポリシー条件が異なる場合に FORCE キーワードを指定すると、（以前は）ユーザーがデータにアクセスでき、置換ではアクセスが許可されなくなるため、アクセス権が失われる可能性があります。
ポリシーを置き換える前に、社内のデータ管理者に相談して、マスキングポリシーでデータを保護し、必要に応じてマスキングポリシーを置き換えるための最善のアプローチを調整してください。
行アクセスポリシー¶
特定のテーブルまたはビュー列は、マスキングポリシー署名または行アクセスポリシー署名のいずれかで指定できます。つまり、マスキングポリシー署名と行アクセスポリシー署名の両方で同時に同じ列を指定することはできません。
この動作は、マスキングポリシーで条件付き列として使用される列にも適用されます。
詳細については、 CREATE MASKING POLICY および CREATE ROW ACCESS POLICY をご参照ください。
ポリシーがどのように機能するかをシミュレートする¶
POLICY_CONTEXT 関数を呼び出して、マスキングポリシーで保護されている列、行アクセスポリシーで保護されているテーブルまたはビュー、または両方のタイプのポリシーでクエリをシミュレートします。
マテリアライズドビュー¶
Snowflakeでは、マテリアライズドビュー列にマスキングポリシーを設定できます。クエリの実行時にクエリプランは、マテリアライズドビューの書き換えを作成する前に、存在するマスキングポリシーを実行します。マテリアライズドビューの書き換えが発生した場合は、マテリアライズドビューの列にマスキングポリシーを設定することはできません。
マテリアライズドビュー列にマスキングポリシーを設定するには、次の2つのオプションがあります。
新しい マテリアライズドビューの場合は、 CREATE MATERIALIZED VIEW ステートメントを実行します。
既存の マテリアライズドビューの場合は、マテリアライズドビューで ALTER VIEW ... MODIFY COLUMN ステートメントを実行します。
新しい マテリアライズドビューの場合は、次のステートメントを実行します。
create or replace materialized view user_info_mv (ssn_number masking policy ssn_mask) as select ssn_number from user_info;
既存の マテリアライズドビューについては、 列にマスキングポリシーを適用する セクション（このトピック内）にあるビューの例をご参照ください。
さらに、マスキングポリシーとマテリアライズドビューに関して、次の2つの制限があります。
基になるテーブルからマテリアライズドビューがすでに作成されている場合は、テーブル列にマスキングポリシーを設定することはできません。これを試行すると、Snowflakeは次のエラーメッセージを返します。
SQL execution error: One or more materialized views exist on the table. number of mvs=<number>, table name=<table_name>.
基になるテーブル列にマスキングポリシーが設定されていて、そのテーブルからマテリアライズドビューが作成されている場合、マテリアライズドビューには、マスキングポリシーで保護されていない列のみが含まれます。マスキングポリシーで保護された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 ステートメントを実行して、テーブルまたはビューの列のマスキングポリシーを表示します。
オブジェクトのタグ付けとマスキングポリシー¶
詳細については、 タグベースのマスキングポリシー をご参照ください。
列に直接割り当てられるマスキングポリシーは、タグベースのマスキングポリシーよりも優先されることに注意してください。
マスキングポリシーのハッシュ、暗号化、および暗号化関数¶
ハッシュ および 暗号化/チェックサム は、機密データをマスクするためのマスキングポリシーで使用できます。
詳細については、 高度な列レベルのセキュリティトピック を参照してください。
外部テーブル¶
CREATE EXTERNAL TABLE ステートメントを使用して外部テーブルを 作成 する場合、この列はデフォルトで自動的に作成されるため、外部テーブル VALUE 列にマスキングポリシーを適用することはできません。
外部テーブルで ALTER TABLE ... ALTER COLUMN ステートメントを実行することにより、マスキングポリシーを外部テーブルの VALUE 列に適用できます。
ALTER TABLE <name> MODIFY COLUMN VALUE SET MASKING POLICY <policy_name> ;
ユーザーが追加した仮想列を含む、他の外部テーブル列には、ポリシーを設定することはできません。これらの列を保護する必要がある場合は、外部テーブルにビューを作成し、ビュー列にポリシーを適用します。
マスキングポリシーの条件付き列では、仮想列を追加の列引数としてリストして、最初の列の引数をマスクするかトークン化するかを決定できます。ただし、仮想列をマスクまたはトークン化する最初の列として指定することはできません。
詳細については、 CREATE MASKING POLICY をご参照ください。
重要
Snowflakeは、マスキングポリシーで外部テーブルをルックアップテーブルとして（つまり、サブクエリで）使用することをサポートしていません。データベースをクローンする際、Snowflakeはマスキングポリシーのクローンを作成しますが、外部テーブルのクローンは作成しません。したがって、クローンされたデータベースのポリシーは、クローンされたデータベースに存在しないテーブルを参照します。
ポリシーに外部テーブルのデータが必要な場合は、クローン操作を完了する前に、マスキングポリシーが存在するデータベース内の専用スキーマに、外部テーブルのデータを移動することを検討してください。完全修飾テーブル名を参照するようにマスキングポリシーを更新して、ポリシーが、クローンされたデータベース内のテーブルを参照するようにします。
ストリーム¶
テーブルの列のマスキングポリシーは、同じテーブルのストリームに引き継がれます。
その結果、権限のないユーザーにはマスクされたデータが表示されます。許可されたユーザーが作成したストリームには、マスキングポリシーで定義されたデータが表示されます。
クローンされたオブジェクト¶
次のアプローチは、クローンされたオブジェクトにアクセスする際に、テーブルまたはビューに対する SELECT 権限を持つユーザーからデータを保護するのに役立ちます。
個別のポリシーオブジェクトのクローニングはサポートされていません。
スキーマのクローニングにより、スキーマ内のすべてのポリシーがクローニングされます。
クローンされたテーブルは、ソーステーブルと同じポリシーにマップされます。つまり、ベーステーブルまたはその列にポリシーが設定されている場合、そのポリシーはクローンテーブルまたはその列にアタッチされます。
テーブルがその親スキーマクローニングのコンテキストでクローンされるときに、同じ親スキーマのポリシーへの参照（つまり、ローカル参照）がソーステーブルにあると、クローンされたテーブルはクローンされたポリシーへの参照を持つようになります。
ソーステーブルが別のスキーマのポリシー（つまり、外部参照）を参照している場合、クローンされたテーブルは外部参照を保持します。
詳細については、 CREATE <オブジェクト> ... CLONE をご参照ください。
CREATE TABLE ... AS SELECT （CTAS）ステートメント¶
CREATE TABLE … AS SELECT （CTAS）ステートメントを実行すると、新しいテーブルにデータが入力される 前 にステートメントに含まれる列にマスキングポリシーが適用されます（該当する列データは新しいテーブルでマスクされる）。CTAS ステートメントを使って作成されたテーブルには、ソースオブジェクトとは異なる列のセットがあり、Snowflakeはマスキングポリシーを新しいテーブルの列に暗黙的に適用できないため、このフローは順守されます。
マスクされていないデータをコピーする必要がある場合は、保護されたデータに対する許可があるロールを使用して、 CTAS ステートメントを実行します。新しいテーブルを作成したら、新しいテーブルの所有権を別のロールに転送し、マスキングポリシー管理者にマスキングポリシーを新しいテーブルの列に適用するよう依頼します。
詳細については、 CREATE TABLE をご参照ください。
集計関数とマスクされた列を使用したクエリ¶
マスクされたデータを含む列で 集計関数 を使用することが可能です。
代表的な使用例としては、データアナリストが実際のデータを確認しなくても、社会保障番号の列の COUNT を取得する場合が挙げられます。ただし、データアナリストがマスクされたテーブル列で SELECT を使用してクエリを実行すると、クエリは固定マスク値を返します。現在のセッションのPAYROLLカスタムロールを持つユーザーにはマスクされていないデータが表示され、他のすべてのユーザーにはマスクされたデータが表示されます。
この結果を達成するには：
テーブル所有者が、集計関数を含む列にビューを作成します。
CREATE VIEW ssn_count AS SELECT DISTINCT(ssn) FROM table1;
ビューに対する完全な権限を ANALYST ロールに付与します。アナリストにはテーブルに関する権限を付与しないでください。
マスキングポリシーをテーブル列に適用します。ビュー列にポリシーがある場合、テーブルポリシーは常にビューポリシーの前に適用されることに注意してください。
case when current_role() in ('PAYROLL') then val else '***MASKED***' end;
ビュー列でクエリを実行します。
use role ANALYST; select count(DISTINCT SSN) from <view>;
マスキングポリシー内のユーザー定義関数¶
UDF をマスキングポリシー条件に渡すことができます。
テーブルまたはビューの列、 UDF、およびマスキングポリシーのデータ型が一致していることを確認することが重要です。テーブル列と UDF にデータ型 VARIANT があり、マスキングポリシー（ポリシー条件にこの UDF がある）が VARCHAR データ型を返すなど、データ型が異なる場合は、このマスキングポリシーがテーブル列に設定されていると、テーブル列に対してクエリを実行したときにSnowflakeはエラーを返します。
テーブル列、 UDF、およびマスキングポリシーのデータ型を一致させる代表的な例については、 CREATE MASKING POLICY の JSON （バリアント）における JavaScript UDFs の使用 の例をご参照ください。
データ共有¶
- 使用法
プロバイダーが共有テーブルまたはビューにポリシーを割り当て、ポリシー条件が CURRENT_ROLE または CURRENT_USER 関数を呼び出すか、ポリシー条件が セキュア UDF を呼び出す場合、Snowflakeはコンシューマーアカウントの関数または UDF に NULL 値を返します。
なぜなら、共有されるデータの所有者は通常、テーブルまたはビューが共有されるアカウントのユーザーまたはロールを制御しないためです。回避策として、ポリシー条件で CURRENT_ACCOUNT 関数を使用します。
共有ビューとポリシーが異なるデータベースに存在する場合は、ポリシーを含むデータベースに対する REFERENCE_USAGE 権限を共有に付与します。詳細については、 複数のデータベースのデータの共有 をご参照ください。
- 制限事項
データ共有プロバイダーは、 リーダーアカウント にポリシーを作成できません。
データ共有コンシューマーは、共有テーブルまたはビューにポリシーを適用できません。回避策として、共有データベースをインポートし、共有テーブルまたはビューからローカルビューを作成します。
データ共有コンシューマーは、2つの異なるプロバイダーを参照する共有テーブルまたはビューをクエリできません。例:
rap1は、t1という名前のテーブルを保護する行アクセスポリシーです。ここで、t1はshare1という名前のプロバイダーからの共有にあります。rap1ポリシー条件は、t2という名前のマッピングテーブルを参照します。ここで、t2はshare2と別のプロバイダーから取得されます。t1に対するコンシューマークエリは失敗します。t1のプロバイダーはt1をクエリできます。
外部関数。
Snowflakeは次の場合にエラーを返します。
共有テーブルまたはビューに割り当てられたポリシーが、外部関数を呼び出すように更新される。
ポリシーが外部関数を呼び出し、そのポリシーを共有テーブルまたはビューに割り当てようとする。
注釈
外部トークン化の場合、 Secure Data Sharing は適用されません。共有のコンテキストでは外部関数を呼び出すことができないためです。
複製¶
マスキングポリシーとその割り当ては、データベース複製と複製グループを使用して複製することができます。
データベース複製 の場合は、次のいずれかの条件に該当すると、複製操作に失敗します。
プライマリデータベースはEnterprise（またはそれ以上）のアカウントにあり、ポリシーを含んでいますが、下位エディションには、複製が承認された1つ以上のアカウントがある。
プライマリデータベースに含まれるテーブルまたはビューには、別のデータベースにあるマスキングポリシーへの ダングリングリファレンス がある。
複製グループ で複数のデータベースを複製すると、データベース複製のダングリングリファレンス動作を回避できます。
注釈
フェールオーバーまたはフェールバックのアクションを使用している場合、SnowflakeアカウントはBusiness Critical Editionかそれ以上である必要があります。
詳細については、 データベース複製とフェールオーバー/フェールバック をご参照ください。
クエリプロファイル¶
マスキングポリシーを含む列で使用すると、 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は、列レベルのセキュリティのマスキングポリシーに対して次の権限を提供します。
スキーマ内の任意のオブジェクトを操作するには、親データベースとスキーマに対する USAGE 権限も必要であることに注意してください。
権限 |
使用法 |
|---|---|
CREATE |
スキーマで、新しいマスキングポリシーを作成できるようにします。 |
APPLY |
列の マスキングポリシー に対する設定解除および設定の操作を実行できるようにします。 APPLY MASKING POLICY グローバル権限（つまり、 ACCOUNT の APPLY MASKING POLICY）を付与すると、テーブルとビューで DESCRIBE 操作を実行できることに注意してください。 構文例については、 マスキングポリシー権限 をご参照ください。 |
OWNERSHIP |
マスキングポリシーに対する包括的な制御を付与します。マスキングポリシーのほとんどのプロパティを変更するために必要です。特定のオブジェクトに対して一度にこの権限を保持できるのは、1つのロールのみです。 |
注釈
マスキングポリシー上で動作するには、親データベースおよび親スキーマでの 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 <db_name.schema_name> to role security_officer; grant apply masking policy on account to role security_officer;条件:
schema_nameスキーマの識別子を指定します。スキーマが作成されるデータベースに対して一意である必要があります。
また、識別子はアルファベット文字で始まる必要があり、識別子文字列全体が二重引用符で囲まれていない限り、スペースや特殊文字を含めることはできません（例："私のオブジェクト"）。二重引用符で囲まれた識別子も大文字と小文字が区別されます。
詳細については、 識別子の要件 をご参照ください。
ハイブリッド管理
ハイブリッド管理アプローチでは、セキュリティ担当者のカスタムロール（例： SECURITY_OFFICER）がマスキングポリシーを作成し、個々のチーム（例：財務、給与、人事）が、チームの所有するテーブルまたはビューの列にマスキングポリシーを適用します。このアプローチにより、一貫したポリシーの作成と保守を実現できますが、機密データをマスクする責任を個々のチームに持たせる必要があります。
use role accountadmin; create role security_officer; grant create masking policy on schema <db_name.schema_name> to role security_officer;SECURITY_OFFICER カスタムロールは、 APPLY 権限を人事チーム（つまり、 HUMAN_RESOURCES カスタムロールを持つユーザー）に付与し、 HUMAN_RESOURCES カスタムロールが所有するオブジェクトの列の社会保障番号（例：マスキングポリシー：
ssn_mask）をマスクします。use role security_officer; grant apply on masking policy ssn_mask to role human_resources;条件:
grant apply on masking policy policy_name to role role_name;ポリシー所有者が、列における特定のマスキングポリシーの設定解除、および設定操作をオブジェクト所有者に分散するために使用します。
この権限は、オブジェクトの所有者もデータスチュワードと見なされる 任意のアクセス制御 をサポートします。
分散型アプローチ
分散管理アプローチでは、個々のチームがマスキングポリシーを作成して、テーブルまたはビューの列に適用します。個々のチームがマスキングポリシーの管理と機密データのマスキングに関するすべての責任を負うため、このアプローチは一貫性のないポリシー管理につながり、機密データが適切にマスクされない可能性があります。
この代表的な例では、サポートチーム（つまり、カスタムロール SUPPORT のユーザー）と財務チーム（つまり、カスタムロール FINANCE のユーザー）がマスキングポリシーを作成できます。これらのカスタムロールには、 SECURITY_OFFICER カスタムロールが含まれない場合があることに注意してください。
use role accountadmin; grant create masking policy on schema <db_name.schema_name> to role support; grant create masking policy on schema <db_name.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は、列レベルのセキュリティマスキングポリシーを管理するための以下のコマンドセットを提供します。
次のテーブルは、列レベルのセキュリティマスキングポリシー DDL 操作と必要な権限の関係をまとめたものです。
スキーマ内の任意のオブジェクトを操作するには、親データベースとスキーマに対する USAGE 権限も必要であることに注意してください。
操作 |
権限 |
|---|---|
マスキングポリシーを作成する |
CREATE MASKING POLICY SCHEMA権限を持つロール。 |
マスキングポリシーを変更する |
マスキングポリシーの所有者（つまり、マスキングポリシーに対するOWNERSHIP権限を持つロール）。 |
マスキングポリシーを削除する |
マスキングポリシーの所有者（つまり、マスキングポリシーに対するOWNERSHIP権限を持つロール）。 |
マスキングポリシーを表示する |
次のいずれか: . グローバル APPLY MASKING POLICY 権限を持つロール、 または . マスキングポリシーの所有者（つまり、マスキングポリシーに対する OWNERSHIP 権限を持つロール） または . マスキングポリシーに対する APPLY 権限を持つロール。 |
マスキングポリシーを説明する |
次のいずれか: . グローバル APPLY MASKING POLICY 権限を持つロール または . マスキングポリシーの所有者（つまり、マスキングポリシーに対する OWNERSHIP 権限を持つロール） または . マスキングポリシーに対する APPLY 権限を持つロール。 |
マスキングポリシーを持つ列のリスト |
次のいずれか: . APPLY MASKING POLICY 権限を持つロール、 または . 特定のマスキングポリシーに対する MASKING POLICY 権限で APPLY を持つロール および ターゲットオブジェクトに OWNERSHIP があるロール。 |
マスキングポリシーでの UDFs の使用 |
新しいマスキングポリシーを作成するか、既存のマスキングポリシーを変更する場合、ポリシー管理者ロールは UDF で使用し、ポリシー式のすべてのスカラー UDFs は同じデータ型であり、 UDF が存在する必要があります。 クエリの実行時に、Snowflakeは UDF が存在するかどうかを確認します。存在しない場合、 SQL 式は解決されず、クエリは失敗します。 |
次のトピック: