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

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

列レベルのセキュリティとは何ですか？
- マスキングポリシーとは
ダイナミックデータマスキングまたは外部トークン化の選択
- 利点
- 制限事項
テーブルとビューでの列レベルのセキュリティの使用
列レベルのセキュリティの管理

列レベルのセキュリティとは何ですか？¶

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
トークン化されたデータを処理する外部関数。

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

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

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 を使用してデータを共有するかどうか。制限事項を参照してください（このトピック）。
複製: 複製されたデータベースオブジェクトをご参照ください。

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

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

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

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

利点¶

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

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

制限事項¶

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

制限事項	ダイナミックデータマスキング	外部トークン化	メモ
共有オブジェクト。	✔	✔	ダイナミックデータマスキングの場合、データ共有コンシューマーであるあなたはマスキングポリシーを共有データベースまたはテーブルに適用できません。 . 回避策として、共有データベースまたはテーブルをインポートし、マスキングポリシーをその共有データベースまたはテーブルのローカルビューに適用します。 . 外部トークン化の場合、共有のコンテキストで外部関数を呼び出すことができないため、Secure Data Sharingは適用されません。
マテリアライズドビュー（MV）。	✔	✔	次のアクションはサポートされていません：MV列でのマスキングポリシーの関連付け、1つ以上の列にマスキングポリシーを持つテーブルからのMVの作成、およびマスキングポリシーのテーブル列への関連付け（そのテーブルにMVがある場合）。
DROP MASKING POLICY	✔	✔	ポリシーを削除する前に、 ALTER TABLE ... ALTER COLUMN または ALTER VIEW を使用して、テーブルまたはビューの列からポリシーを設定解除してください。
DROP DATABASE および DROP SCHEMA	✔	✔	マスキングポリシーとそのマッピングがデータベースとスキーマ内で自己完結している必要があります。 . たとえば、 `database_1` には `policy_1` が含まれ、 `policy_1` は `database_1` でのみ使用されます。
仮想列	✔	✔	マスキングポリシーは仮想列に適用できません。ポリシーはソーステーブル列またはビュー列に適用してください。
1つのステートメント内の複数列。	✔	✔	ALTER TABLE または ALTER VIEW ステートメントごとに1列のみ。列に対して単一の ALTER ステートメントを実行して、列レベルのセキュリティマスキングポリシーを設定または設定解除します。
ポリシー変更管理のマスキング。	✔	✔	オプションで、選択したバージョン管理システムにマスキングポリシーの変更を保存して追跡できます。
Microsoft Azureクラウドプラットフォーム		✔	Microsoft Azureクラウドプラットフォームでの外部トークン化のサポートが予定されています。
Google Cloud Platform		✔	Google Cloud Platformのアカウントのサポートが予定されています。

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

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 を参照してください。

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

マスキングポリシーを含む列のリストを取得するには、次のステートメントを実行します。詳細については、 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カスタムロールを持つユーザーにはマスクされていないデータが表示され、他のすべてのユーザーにはマスクされたデータが表示されます。

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

テーブル所有者が、集計関数を含む列にビューを作成します。
```
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>;

クエリプロファイル¶

マスキングポリシーを含む列で使用すると、 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式は解決されず、クエリは失敗します。

次のトピック：