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

マスキングポリシーとは¶

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

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

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

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

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

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

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

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

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

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

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

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

-- 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;

利点¶

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

制限事項¶

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

考慮事項¶

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

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

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

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

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

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

• バージョン管理されたスキーマにマスキングポリシーが存在する場合、 Snowflake Native App のセットアップスクリプトを作成するときは注意してください。詳細については、 バージョンスキーマの考慮事項 をご参照ください。

アクティブロール階層およびマッピングテーブル¶

ポリシー条件は、ポリシー管理者がポリシーを記述する方法次第で、セッションで直接ユーザーのアクティブなプライマリロールとセカンダリロールを評価したり、マッピングテーブルでアクティブなロールを検索したり、その両方を実行したりできます。ポリシーにマッピングテーブルルックアップが含まれている場合は、一元化されたマッピングテーブルを作成し、保護されたテーブルと同じデータベースにマッピングテーブルを格納します。これは、ポリシーが IS_DATABASE_ROLE_IN_SESSION 関数を呼び出す場合に特に重要です。詳細については、関数の 使用上の注意 をご参照ください。

このようなユースケースの場合、Snowflakeでは、アカウントロールまたはデータベースロールのどちらを指定するかに応じて、 IS_ROLE_IN_SESSION または IS_DATABASE_ROLE_IN_SESSION 関数を呼び出すようにポリシー条件を記述することを推奨します。例については、次をご参照ください。

• IS_ROLE_IN_SESSION 関数の 例 セクション。

• IS_DATABASE_ROLE_IN_SESSION

• ポリシーで保護されたデータを共有する

コンテキスト関数およびマスキングポリシーに関するその他の例は 高度な列レベルセキュリティのトピック をご参照ください。

列へのマスキングポリシーの適用¶

列がマスキングポリシーで保護されていない場合、テーブルまたはビューの列にマスキングポリシーを適用するには、次の2つのオプションがあります。

1. 新しい テーブルまたはビューを使用して、 CREATE TABLE ステートメントを含むテーブル列または CREATE VIEW ステートメントを含むビュー列にポリシーを適用します。

2. 既存の テーブルまたはビューを使用して、 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;

Copy

既存の テーブルまたはビューの場合は、次のステートメントを実行します。

-- 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;

Copy

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

マスキングポリシーで UDF を使用する場合は、 マスキングポリシー内のユーザー定義関数 （このトピック内）をご参照ください。

列に条件付きマスキングポリシーを適用する¶

条件付き列 を使用してマスキングポリシーを 作成 した後、マスキングポリシーですでに保護されていない列に条件付きマスキングポリシーを設定するための2つのオプションがあります。

1. 新しい テーブルまたはビューの場合は、対応する CREATE ステートメントを使用してテーブルまたはビュー列にポリシーを適用します。

   構文および使用方法の詳細については、次をご参照ください。

   • CREATE TABLE

   • CREATE VIEW

   • CREATE MATERIALIZED VIEW

   新しい テーブルまたはビューの場合は、次のステートメントを実行します。

   -- 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;
   

   Copy

2. 既存の テーブルまたはビューの場合は、対応する ALTER ステートメントを使用してテーブルまたはビュー列にポリシーを設定します。

   構文および使用方法の詳細については、次をご参照ください。

   • ALTER TABLE

   • ALTER TABLE ... ALTER COLUMN

   • ALTER VIEW

   • ALTER MATERIALIZED VIEW

   既存の テーブルまたはビューの場合は、次のステートメントを実行します。

   -- 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);
   

   Copy

列のマスキングポリシーを置き換える¶

列のマスキングポリシー設定後には、テーブルまたはビュー全体を置き換えることなく、列のマスキングポリシーを別のマスキングポリシーに置き換えるための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;
  

  Copy

• FORCE キーワードを使用して、単一のステートメントでポリシーを置き換えます。

  ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY p2 FORCE;
  

  Copy

  注意:

  • FORCE キーワードでは、 ALTER TABLE ステートメント内のポリシーの データ型 （つまり、 STRING）が、列に現在設定されているマスキングポリシーのデータ型（つまり、 STRING）と一致する必要があります。

  • FORCE キーワードは、 USING 句と組み合わせて、列に条件付きマスキングポリシーを設定できます。

    ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY policy1 USING (c1, c3, c4) FORCE;
    

    Copy

行アクセスポリシー¶

特定のテーブルまたはビュー列は、マスキングポリシー署名または行アクセスポリシー署名のいずれかで指定できます。つまり、マスキングポリシー署名と行アクセスポリシー署名の両方で同時に同じ列を指定することはできません。

この動作は、マスキングポリシーで条件付き列として使用される列にも適用されます。

詳細については、 CREATE MASKING POLICY および CREATE ROW ACCESS POLICY をご参照ください。

ポリシーがどのように機能するかをシミュレートする¶

POLICY_CONTEXT 関数を呼び出して、マスキングポリシーで保護されている列、行アクセスポリシーで保護されているテーブルまたはビュー、または両方のタイプのポリシーでクエリをシミュレートします。

マテリアライズドビュー¶

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

マテリアライズドビュー列にマスキングポリシーを設定するには、次の2つのオプションがあります。

1. 新しい マテリアライズドビューの場合は、 CREATE MATERIALIZED VIEW ステートメントを実行します。

   CREATE OR REPLACE MATERIALIZED VIEW user_info_mv
     (ssn_number masking policy ssn_mask)
   AS SELECT ssn_number FROM user_info;
   

   Copy

2. 既存 のマテリアライズドビューの場合は、 列へのマスキングポリシーの適用 セクション（このトピック内）で表示されているように、マテリアライズドビューで 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>.
   

   Copy

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

   Unsupported feature 'CREATE ON MASKING POLICY COLUMN'.
   

   Copy

動的テーブル¶

行アクセスポリシー、マスキングポリシー、タグを持つ動的テーブルを作成できます。詳細については、次をご参照ください。

• CREATE DYNAMIC TABLE

• 増分リフレッシュの追加制限

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

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

SELECT * from table(
  INFORMATION_SCHEMA.POLICY_REFERENCES(
    policy_name=>'<policy_name>'
  )
);

Copy

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

オブジェクトのタグ付けおよびマスキングポリシー¶

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

列に直接割り当てられるマスキングポリシーは、タグベースのマスキングポリシーよりも優先されることに注意してください。

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

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

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

外部テーブル¶

CREATE EXTERNAL TABLE ステートメントを使用して外部テーブルを 作成 する場合、この列はデフォルトで自動的に作成されるため、外部テーブル VALUE 列にマスキングポリシーを割り当てることはできません。

外部テーブルで ALTER TABLE ... ALTER COLUMN ステートメントを実行することにより、マスキングポリシーを外部テーブルの VALUE 列に割り当てることができます。VALUE 列を保護するマスキングポリシーのデータ型は、 VARIANT である必要があります。

ALTER TABLE t1 MODIFY COLUMN VALUE SET MASKING POLICY p1;

Copy

外部テーブルの仮想列にマスキングポリシーを割り当てるには、次の手順に従います。

• 外部テーブルの VALUE 列を保護するマスキングポリシーの EXEMPT_OTHER_POLICIES マスキングポリシープロパティを TRUE に設定します。

  このプロパティがまだ設定されていない場合は、 CREATE OR REPLACE ステートメントを VALUE 列を保護するマスキングポリシー上で実行し、 EXEMPT_OTHER_POLICIES プロパティを指定します。仮想列は VALUE 列を保護するポリシーを継承し、このプロパティにより、仮想列のポリシーが継承されたポリシーを上書きできるようになります。詳細については、 CREATE MASKING POLICY をご参照ください。

• ALTER TABLE コマンドを使用して、仮想列に別のマスキングポリシーを割り当てます。仮想列は機密性が低いため、このポリシーは VALUE 列のポリシーよりも厳密ではなくすることができます。仮想列は VALUE 列より少ない量のデータを含み、 VALUE 列は外部テーブルの各行の全データを含みます。

  仮想列を保護するポリシーのデータ型は、仮想列のデータ型に依存します。

マスキングポリシーの条件付き列では、仮想列を追加の列引数としてリストして、最初の列の引数をマスクするかトークン化するかを決定できます。ただし、仮想列をマスクまたはトークン化する最初の列として指定することはできません。

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

ストリーム¶

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

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

クローンされたオブジェクト¶

次のアプローチは、クローンされたオブジェクトにアクセスする際に、テーブルまたはビューに対する 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;
   

   Copy

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

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

   CASE
     WHEN CURRENT_ROLE() IN ('PAYROLL') THEN val
     ELSE '***MASKED***'
   END;
   

   Copy

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

   USE ROLE analyst;
   SELECT COUNT(DISTINCT ssn) FROM v1;
   

   Copy

マスキングポリシー内のユーザー定義関数¶

UDF をマスキングポリシー条件に渡すことができます。

テーブルまたはビューの列、 UDF、およびマスキングポリシーのデータ型が一致していることを確認することが重要です。テーブル列と UDF にデータ型 VARIANT があり、マスキングポリシー（ポリシー条件にこの UDF がある）が VARCHAR データ型を返すなど、データ型が異なる場合は、このマスキングポリシーがテーブル列に設定されていると、テーブル列に対してクエリを実行したときにSnowflakeはエラーを返します。

テーブル列、 UDF、およびマスキングポリシーのデータ型を一致させる代表的な例については、 CREATE MASKING POLICY の JSON （バリアント）における JavaScript UDFs の使用 の例をご参照ください。

データ共有¶

使用状況:

• プロバイダーが共有テーブルまたはビューにポリシーを割り当て、ポリシー条件が CURRENT_ROLE または CURRENT_USER 関数を呼び出すか、ポリシー条件が セキュア UDF を呼び出す場合、Snowflakeはコンシューマーアカウントの関数または UDF に NULL 値を返します。

  なぜなら、共有されるデータの所有者は通常、テーブルまたはビューが共有されるアカウントのユーザーまたはロールを制御しないためです。回避策として、ポリシー条件で CURRENT_ACCOUNT 関数を使用します。

  あるいは、プロバイダーとして、 IS_DATABASE_ROLE_IN_SESSION 関数を呼び出すポリシー条件を記述し、データベースロールを共有します。コンシューマーとして、共有データベースロールをアカウントロールに付与します。詳細については、 ポリシーで保護されたデータを共有する をご参照ください。

制限事項:

• データ共有プロバイダーは、 リーダーアカウント にポリシーを作成できません。

• データ共有コンシューマーは、共有テーブルまたはビューにポリシーを適用できません。回避策として、共有データベースをインポートし、共有テーブルまたはビューからローカルビューを作成します。

• データ共有コンシューマーは、2つの異なるプロバイダーを参照する共有テーブルまたはビューをクエリできません。例:

  • rap1 は、 t1 という名前のテーブルを保護する行アクセスポリシーです。ここで、 t1 は share1 という名前のプロバイダーからの共有にあります。

  • rap1 ポリシー条件は、 t2 という名前のマッピングテーブルを参照します。ここで、 t2 は share2 と別のプロバイダーから取得されます。

  • t1 に対するコンシューマークエリは失敗します。

  • t1 のプロバイダーは t1 をクエリできます。

• 外部関数。

  Snowflakeは次の場合にエラーを返します。

  • 共有テーブルまたはビューに割り当てられたポリシーが、外部関数を呼び出すように更新される。

  • ポリシーが外部関数を呼び出し、そのポリシーを共有テーブルまたはビューに割り当てようとする。

複製¶

マスキングポリシーとその割り当ては、データベース複製と複製グループを使用して複製することができます。

データベース複製 の場合は、次のいずれかの条件に該当すると、複製操作に失敗します。

• プライマリデータベースは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 <場所> コマンドを使用すると、マスキングポリシーがデータに適用されます。したがって、許可のないユーザーには、コマンドの実行後にマスクされたデータを表示します。

Snowflake Native App Framework¶

マスキングポリシーを Snowflake Native App で使用する場合の詳細については、次をご参照ください。

• ポリシーを含むデータコンテンツの共有制限.

• プロキシビューのポリシーを定義する.

• ブロックされたコンテキスト関数.

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

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

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

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

マスキングポリシー権限¶

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

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

スキーマ内のオブジェクトに対して操作を実行するには、親データベースとスキーマに対する 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 mydb.mysch TO ROLE security_officer;

GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE security_officer;

Copy

条件:

• schema_name

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

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

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

ハイブリッド管理

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

USE ROLE ACCOUNTADMIN;
CREATE ROLE security_officer;
GRANT CREATE MASKING POLICY ON SCHEMA mydb.mysch TO ROLE security_officer;

Copy

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

USE ROLE security_officer;
GRANT APPLY ON MASKING POLICY ssn_mask TO ROLE human_resources;

Copy

条件:

• grant apply on masking policy policy_name to role role_name;

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

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

分散型アプローチ

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

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

USE ROLE ACCOUNTADMIN;
GRANT CREATE MASKING POLICY ON SCHEMA mydb.mysch TO ROLE support;
GRANT CREATE MASKING POLICY ON SCHEMA <DB_NAME.SCHEMA_NAME> TO ROLE FINANCE;

Copy

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

USE ROLE support;
GRANT APPLY ON MASKING POLICY ssn_mask TO ROLE human_resources;

Copy

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

USE ROLE finance;
GRANT APPLY ON MASKING POLICY cash_flow_mask TO ROLE audit_internal;

Copy

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

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

• 外部トークン化の使用

マスキングポリシー 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 操作と必要な権限の関係をまとめたものです。

スキーマ内のオブジェクトに対して操作を実行するには、親データベースとスキーマに対する USAGE 権限が必要です。

マスキングポリシーを見つける¶

共有 SNOWFLAKE データベースのAccount Usageスキーマで MASKING_POLICIES ビューを使用できます。このビューは、Snowflakeアカウント内にあるすべてのマスキングポリシーの カタログ です。例:

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.MASKING_POLICIES
ORDER BY POLICY_NAME;

Copy

割り当てを識別する¶

Snowflakeは、クエリがアカウントまたは特定のデータベースをターゲットにする必要があるかどうかに応じて、マスキングポリシーの割り当てを識別するためのさまざまなオプションをサポートしています。

• アカウントレベルのクエリ:

  Account Usage POLICY_REFERENCES ビューを使用して、マスキングポリシーを持つすべての列を確認します。例:

  SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.POLICY_REFERENCES
  ORDER BY POLICY_NAME, REF_COLUMN_NAME;
  

  Copy

• データベースレベルのクエリ:

  すべてのSnowflakeデータベースには Snowflake Information Schema が含まれています。Information Schema テーブル関数 POLICY_REFERENCES を使用して、特定のテーブルの列上にあるすべてのマスキングポリシーを決定します。

  SELECT *
  FROM TABLE(
    my_db.INFORMATION_SCHEMA.POLICY_REFERENCES(
      'my_table',
      'table'
    )
  );
  

  Copy

  この関数を使用してマスキングポリシーの名前でクエリを実行し、特定のマスキングポリシーに関連付けられているオブジェクトを検索することもできます。

Snowsightのガバナンスエリアへのアクセス¶

Governance エリアにアクセスするには、Snowflakeアカウントが Enterprise Edition 以上 である必要があります。さらに、次のいずれかを実行する必要があります。

• ACCOUNTADMIN ロールを使用します。

• GOVERNANCE_VIEWER および OBJECT_VIEWER データベースロールが 直接 付与されているアカウントロールを使用します。

  これらのデータベースロール付与では、アカウントロールを 使用する必要があります。現在のところ、 Snowsight はテーブル、ビュー、データアクセスポリシー、タグにアクセスできるロール階層およびユーザー定義のデータベースロールを評価しません。

  アカウントロールにこれらの2つのデータベースロールが付与されているかどうかを確認するには、 SHOW GRANTS コマンドを使用します。

  SHOW GRANTS LIKE '%VIEWER%' TO ROLE data_engineer;
  

  Copy

  |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
  | created_on                    | privilege | granted_on    | name                        | granted_to | grantee_name    | grant_option | granted_by |
  |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
  | 2024-01-24 17:12:26.984 +0000 | USAGE     | DATABASE_ROLE | SNOWFLAKE.GOVERNANCE_VIEWER | ROLE       | DATA_ENGINEER   | false        |            |
  | 2024-01-24 17:12:47.967 +0000 | USAGE     | DATABASE_ROLE | SNOWFLAKE.OBJECT_VIEWER     | ROLE       | DATA_ENGINEER   | false        |            |
  |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
  

  
  

  アカウントロールにこれらのデータベースロールのいずれかまたは両方が付与されていない場合は、 GRANT DATABASE ROLE コマンドを使用し、 SHOW GRANTS コマンドを再度実行して付与を確認してください。

  USE ROLE ACCOUNTADMIN;
  GRANT DATABASE ROLE SNOWFLAKE.GOVERNANCE_VIEWER TO ROLE data_engineer;
  GRANT DATABASE ROLE SNOWFLAKE.OBJECT_VIEWER TO ROLE data_engineer;
  SHOW GRANTS LIKE '%VIEWER%' TO ROLE data_engineer;
  

  Copy

  これらのデータベースロールの詳細については、 SNOWFLAKE データベースロール をご参照ください。

ダッシュボード¶

データ管理者は、 Dashboard インターフェイスを使用して、次の方法でタグとポリシーの使用状況をモニターできます。

• カバレッジ: テーブル、ビュー、または列にポリシーまたはタグがあるかどうかに基づいて、カウントとパーセンテージを指定します。

• 普及率: 最も頻繁に使用されるポリシーとタグをリストし、カウントします。

カバレッジと普及率は、データがどの程度適切に保護され、タグ付けされているかに関するスナップショットを提供します。

カウント数、パーセンテージ、ポリシー名、またはタグ名を選択すると、 Tagged Objects インターフェイスが開きます。 Tagged Objects インターフェイスは、 Dashboard での選択に基づいてフィルターを自動的に更新します。

モニター情報は、複数のAccount Usageビューで複雑なクエリ集中型の操作を実行するための代替または補完です。

これらのビューには、 COLUMNS、 POLICY_REFERENCES、 TABLES、 TAG_REFERENCES、および VIEWS ビューが含まれますが、これらに限定されません。

タグ付きオブジェクト¶

データ管理者は、このテーブルを使用して、 Dashboard のカバレッジと普及率を特定のテーブル、ビュー、または列のリストにすばやく関連付けることができます。次のようにテーブルの結果を手動でフィルターすることもできます。

• Tables または Columns を選択します。

• タグの場合は、タグあり、タグなし、または特定のタグでフィルターできます。

• ポリシーの場合は、ポリシーあり、ポリシーなし、または特定のポリシーでフィルターできます。

テーブル内の行を選択すると、 Data » Databases の Table Details または Columns タブが開きます。必要に応じて、タグとポリシーの割り当てを編集できます。

追加の詳細については、 タグおよびポリシーの検出 をご参照ください。