タグベースのマスキングポリシー¶

権限¶

タグベースのマスキングポリシーをデータベース、スキーマ、またはテーブルのいずれに設定するかによって、必要な権限が異なります。

データベースまたはスキーマのタグベースのマスキングでは、現在のロールまたは現在のロール階層内のロールが、次の2つのオプション2つで示される権限のうちのいずれかを継承する必要があります。

オプション1:

このロールは、 APPLY MASKING POLICY グローバル権限と APPLY TAG グローバル権限の両方を持っている必要があります。たとえば、これらの権限を data_engineer カスタムロールに付与します。

USE ROLE ACCOUNTADMIN;

GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE data_engineer;

GRANT APPLY TAG ON ACCOUNT TO ROLE data_engineer;

Copy

これは、スキーマやデータベースのタグベースのマスキングポリシーで列を保護するための、最も 集中型のアプローチ です。

オプション2:

スキーマ所有者（つまり、スキーマの OWNERSHIP 権限を持つロール）は、 APPLY MASKING POLICY グローバル権限とタグの APPLY 権限を持つことができます。たとえば、タグの名前が governance.tags.schema_mask で、スキーマを所有するカスタムロールが schema_owner の場合は次のようにします。

USE ROLE ACCOUNTADMIN;

GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE schema_owner;

GRANT APPLY ON TAG governance.tags.schema_mask TO ROLE schema_owner;

Copy

このアプローチでは、列の保護をスキーマの所有者に委任することで、より柔軟な対応ができるようになります。

テーブルとビューへのタグベースのマスキングにより、 APPLY MASKING POLICY グローバル権限を持つロールは、タグのマスキングポリシーを割り当て、置き換えることができます。

たとえば、 APPLY MASKING POLICY グローバル権限を tag_admin カスタムロールに付与します。

USE ROLE SECURITYADMIN;

GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE tag_admin;

Copy

タグにマスキングポリシーを割り当てる¶

スキーマまたはデータベースへのタグベースマスキングポリシーの割り当ては、テーブルへのタグベースマスキングポリシーの設定と同じ手順に従います。

1. CREATE TAG コマンドを使用してタグを作成します。。

2. CREATE MASKING POLICY コマンドを使用してマスキングポリシーを作成します。

   オプションで、 SYSTEM$GET_TAG_ON_CURRENT_COLUMN および SYSTEM$GET_TAG_ON_CURRENT_TABLE システム関数をマスキングポリシー条件で使用できます。

3. ALTER TAG コマンドを使用して、タグにマスキングポリシーを設定します。

4. 以下のコマンドのいずれかを使用して、データを保護する方法に基づいてオブジェクトにタグを設定します。

   • ALTER DATABASE

   • ALTER SCHEMA

   • ALTER TABLE

ALTER TAG の使用上の注意に加えて、次の点に注意してください。

• タグは、データ型ごとに1つのマスキングポリシーのみを持つことができます。たとえば、 STRING データ型の1つのポリシー、 NUMBER データ型の1つのポリシーなどです。

• マスキングポリシーがすでに列を保護していて、マスキングポリシーのあるタグが同じ列に設定されている場合は、その列に 直接 割り当てられたマスキングポリシーが、タグに割り当てられたマスキングポリシーよりも優先されます。

• タグがマスキングポリシーに割り当てられている場合は、タグを ドロップ することはできません。

• マスキングポリシーがタグに割り当てられている場合は、マスキングポリシーを ドロップ することはできません。

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

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

• アクセス制御権限

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

タグにマスキングポリシーを設定した後、タグのマスキングポリシーを別のマスキングポリシーに置き換えるには、次の2つの方法があります。ALTER TAGステートメントでは、以下のオプションに示すようにマスキングポリシー名を指定する必要があります。

オプション1:

1つのステートメントでタグのポリシーを設定解除し、それから別のステートメントでタグの新しいポリシーを設定します。

ALTER TAG security UNSET MASKING POLICY ssn_mask;

ALTER TAG security SET MASKING POLICY ssn_mask_2;

Copy

オプション2:

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

タグに同じ データ型 のポリシーがすでに設定されている場合は、 FORCE キーワードを使用するとポリシーが置き換えられることに注意してください。

ALTER TAG security SET MASKING POLICY ssn_mask_2 FORCE;

Copy

権限 セクションで選択するオプションと、 タグにマスキングポリシーを割り当てる セクションで操作する順序は、データベースやスキーマのタグを置換または設定解除する必要がある場合に、タグ管理に影響を与えます。

スキーマ所有者がスキーマにタグを設定し、別のロールが同じタグにマスキングポリシーを設定した場合、スキーマ所有者に APPLY MASKING POLICY グローバル権限が付与されている場合を除き、スキーマ所有者はスキーマからタグの設定を解除することはできません。Snowflakeはスキーマ所有者の ALTER SCHEMA ... UNSET TAG 操作に失敗します。このシナリオでは、タグベースのマスキングポリシーで保護された列データが保護されたままであることを保証します。このシナリオを避けるには、 権限 セクションのオプション1を使用します。

重要

タグのマスキングポリシーを置き換えるときは注意してください。

列の置換とクエリのタイミングによっては、 UNSET 操作と SET 操作との時間間隔で列データが保護されない期間が発生するため、2つの別々のステートメントでポリシーを置き換えることを選択すると、データリークが発生する可能性があります。

ただし、置換ポリシーでポリシー条件が異なる場合に FORCE キーワードを指定すると、（以前は）ユーザーがデータにアクセスでき、置換ではアクセスが許可されなくなるため、アクセス権が失われる可能性があります。

ポリシーを置き換える前に、社内のデータ管理者に相談して、タグベースのマスキングポリシーでデータを保護し、必要に応じてマスキングポリシーを置き換えるための最善のアプローチを調整してください。

タグ値を更新する¶

スキーマ所有者（つまり、 sch_role）がスキーマにタグを設定し、その後別のロールが同じタグにマスキングポリシーを設定した場合（つまり、 masking_admin_role）、スキーマ所有者はタグの値を変更することはできません。Snowflakeはスキーマ所有者の ALTER SCHEMA ... SET TAG 操作に失敗します。

タグ値を変更するには、

1. masking_admin_role を使用して、タグのマスキングポリシーを解除します。

2. sch_role を使用して、タグ値を変更します。

3. masking_admin_role を使用して、マスキングポリシーをタグに再割り当てします。

親データベースおよびスキーマ¶

次の場合は、データベースとスキーマに対して DROP および REPLACE 操作を実行できません。

• タグとマスキングポリシーが同じスキーマにある。

• テーブルまたはビューが別のスキーマにある。

• テーブルまたはビューの保護された列が、マスキングポリシーとタグを含むスキーマとは異なるスキーマに存在する。

次の4つのコマンドは DROP を参照し、データベースとスキーマの操作を置き換えます。

• DROP DATABASE

• DROP SCHEMA

• CREATE OR REPLACE DATABASE

• CREATE OR REPLACE SCHEMA

条件付き引数¶

条件付きマスキングポリシー は、タグに割り当てることができます。タグを列に割り当てた後に、引数のデータ型が列のデータ型と一致する場合、条件付き引数は名前でテーブル内の列にマップされます。

次の場合に条件付きマスキングポリシーが列に割り当てられていると、クエリは失敗します。

• テーブルには、ポリシーの条件付き引数と同じ名前の列がない。

• テーブルには、ポリシーの条件付き引数の名前と一致する列があるが、データ型が一致しない。

これらのエラーの詳細については、 タグベースのマスキングポリシーをトラブルシューティングする （このトピック内）をご参照ください。

タグ継承¶

マスキングポリシーのタグは、すべての ベーステーブル オブジェクトに割り当てることができます。または、タグをベーステーブルの列に割り当てることができます。タグベースのマスキングポリシーがベーステーブルに割り当てられている場合、列のデータ型がマスキングポリシー署名のデータ型と一致する限り、列はポリシーによって保護されます。

マスキングポリシーはベーステーブルの列を保護するため、基になるベーステーブルの列から派生したビューの列も、現在の 制限、 考慮事項、およびテーブルとビューのマスキングポリシーに関する 動作 に基づいて保護されます。

データ共有¶

プロバイダーアカウントにある共有スキーマまたは共有データベースに設定されたタグベースのマスキングポリシーは、コンシューマーアカウントで適用されます。このシナリオでは、コンシューマー共有から新しいデータベースを作成しても、共有される保護されたデータが、保護されたままであることを保証します。

さらに、次に注意してください。

• タグの継承はコンシューマーアカウントに保持されます。

  プロバイダーがデータベースにタグベースのマスキングポリシーを設定し、そのデータベースを共有すると、Snowflakeはタグを含むデータベースという観点から、コンシューマーアカウント内の共有プロバイダーデータベースを参照します。

• タグおよびタグベースのマスキングポリシーがコンシューマーアカウントに由来する場合、Snowflakeは共有オブジェクトでのタグ継承を尊重しません。

  コンシューマーカウントからのタグとタグベースのマスキングポリシーは、共有オブジェクトには適用されません。

Snowsight¶

Snowsight でタグベースのマスキングポリシーを監視および割り当てることができます。詳細については、以下をご参照ください。

• Snowsight によるタグのモニター

• Snowsight を使用したマスキングポリシーのモニター

タグおよびポリシーの検出¶

Information Schemaテーブル関数 POLICY_REFERENCES とAccount Usage POLICY_REFERENCES ビューは、次の列を確認することで、マスキングポリシーとタグが相互に参照しているかどうかを判断するのに役立ちます。

• TAG_DATABASE

• TAG_SCHEMA

• TAG_NAME

• POLICY_STATUS

POLICY_STATUS 列には、次の4つの値を指定できます。

ACTIVE

列（つまり、REF_COLUMN_NAME）が、タグによって単一のポリシーにのみ関連付けられることを指定します。

MULTIPLE_MASKING_POLICY_ASSIGNED_TO_THE_COLUMN

複数のマスキングポリシーが同じ列に割り当てられることを指定します。

COLUMN_IS_MISSING_FOR_SECONDARY_ARG

ポリシー（つまり、POLICY_NAME）が条件付きマスキングポリシーであり、テーブル（つまり、REF_ENTITY_NAME）に同じ名前の列がないことを指定します。

COLUMN_DATATYPE_MISMATCH_FOR_SECONDARY_ARG

ポリシーが条件付きマスキングポリシーであり、テーブルに同じ名前の列がありますが、マスキングポリシー署名のデータ型とは異なるデータ型であることを指定します。

POLICY_STATUS 列に表示される可能性がある値の関連エラーメッセージの詳細については、 タグベースのマスキングポリシーをトラブルシューティングする （このトピック内）をご参照ください。

データ保護および検証のステップ¶

通常Snowflakeは、タグベースのマスキングポリシーを使用する場合、次のアプローチを推奨しています。

1. タグベースのマスキングポリシーに必要なタグを作成します。

2. タグベースのマスキングポリシーで保護する予定のテーブル列に基づいて、データ型ごとに1つのマスキングポリシーを作成します。

3. タグにマスキングポリシーを割り当てます。

4. マスキングポリシーを使用してタグをテーブル列に直接割り当てるか、テーブルに割り当てます。

5. Information Schemaをチェックして、タグベースのポリシーが列に割り当てられていることを確認します。

6. データをクエリして、タグベースのマスキングポリシーが意図したとおりにデータを保護していることを確認します。

前提条件のステップ¶

1. Snowflakeアカウントで既存のタグとその文字列値を特定します。

   • Account Usage TAG REFERENCES ビューをクエリして、すべてのタグとそれに割り当てられた文字列値を取得します。

   • オプション:

     • Account Usage TAGS ビュー（つまり、 タグカタログ）をクエリしてタグのリストを取得し、タグベースのマスキングポリシー使用時にタグの名前が重複しないようにします。

     • TAG_REFERENCES クエリの出力と TAGS クエリの出力を比較して、後で使用できる未割り当てのタグがあるかどうかを判断します。

     • CREATE TAG コマンドを使用して、後で必要になるタグを作成します。それ以外の場合は、必要に応じてタグを作成します。

2. Snowflakeアカウントで既存のポリシーとその定義を識別します。

   • SHOW MASKING POLICIES コマンドを実行して、既存のマスキングポリシーのリストを取得します。

   • これらのポリシーを現在の形式でタグに割り当てることができるかどうかを決定します。必要に応じて、 DESCRIBE MASKING POLICY コマンドを実行してポリシー定義を取得します。それ以外の場合は、タグに割り当てる新しいポリシーを作成することを計画してください。

3. ポリシー条件がテーブル列に設定されているタグ文字列値を評価する必要があるかどうかという観点から、マスキングポリシーを使用して列データを保護する方法を決定します。

一般的な仮定の例¶

例では、次を仮定しています。

• 前提条件のステップが完了している。

• tag_admin カスタムロールには次の権限がある。

  • スキーマレベルの CREATE TAG 権限。

  • APPLY TAG グローバル権限。

  詳細については、 タグの権限 をご参照ください。

• masking_admin カスタムロールには次の権限がある。

  • スキーマレベルの CREATE MASKING POLICY 権限。

  • governance データベースおよび governance.masking_policies スキーマに対する USAGE 権限。

  • タグにマスキングポリシーを割り当てるための APPLY MASKING POLICY グローバル権限（このトピック内の 権限 を参照）。

  • タグ（マスキングポリシーを含む）をオブジェクトに割り当てるための APPLY TAG グローバル権限。

  詳細については、 タグの権限 をご参照ください。

• row_access_admin カスタムロールには次の権限がある。

  • スキーマレベルの CREATE ROW ACCESS POLICY 権限。

  • governance データベースおよび governance.row_access_policies スキーマに対する USAGE 権限。

  • APPLY ROWACCESS POLICY グローバル権限。

  詳細については、 行アクセスポリシーの権限 をご参照ください。

• accounting_admin カスタムロールには次の権限がある。

  • finance データベースおよび finance.accounting スキーマに対する USAGE 権限。

  • finance.accounting スキーマのテーブルに対する SELECT 権限。

• analyst カスタムロールには次の権限がある。

  • finance データベースおよび finance.accounting スキーマに対する USAGE 権限。

  • finance.accounting.name_number テーブルに対する SELECT 権限。

• 上記のカスタムロールが、適切なユーザーに付与されている。

  詳細については、 アクセス制御の構成 をご参照ください。

例1: タグに直接割り当てられたマスキングポリシーに基づいて列データを保護する¶

この例では、2つのマスキングポリシーをタグに割り当ててから、同じタグをテーブルに割り当てます。その結果、マスキングポリシーは、データ型がポリシーのデータ型と一致するすべてのテーブル列を保護します。

次のステップでは、アカウントデータをマスクするためのタグベースのマスキングポリシーを作成します。たとえば、 ACCOUNT_NAME と ACCOUNT_NUMBER の2つの列がある finance.accounting.name_number という名前のテーブルについて考えてみます。これらの列のデータ型は、それぞれ STRING と NUMBER です。

---------------+----------------+
  ACCOUNT_NAME | ACCOUNT_NUMBER |
---------------+----------------+
  ACME         | 1000           |
---------------+----------------+

次のように、 ACCOUNT_NAME 列と ACCOUNT_NUMBER 列を保護するためのタグベースのマスキングポリシーを作成します。

1. governance.tags という名前のスキーマに accounting という名前のタグを作成します。

   USE ROLE tag_admin;
   USE SCHEMA governance.tags;
   CREATE OR REPLACE TAG accounting;
   

   Copy

2. ACCOUNT_NAME 列と ACCOUNT_NUMBER 列を保護するために、異なるマスキングポリシーを作成します。これらの各ポリシーでは、 ACCOUNTING_ADMIN カスタムロールのみが生データを表示できます。

   アカウント名ポリシー:

   USE ROLE masking_admin;
   USE SCHEMA governance.masking_policies;
   
   CREATE OR REPLACE MASKING POLICY account_name_mask
   AS (val string) RETURNS string ->
     CASE
       WHEN CURRENT_ROLE() IN ('ACCOUNTING_ADMIN') THEN val
       ELSE '***MASKED***'
     END;
   

   Copy

   アカウント番号ポリシー:

   CREATE OR REPLACE MASKING POLICY account_number_mask
   AS (val number) RETURNS number ->
     CASE
       WHEN CURRENT_ROLE() IN ('ACCOUNTING_ADMIN') THEN val
       ELSE -1
     END;
   

   Copy

3. 両方のマスキングポリシーを accounting タグに割り当てます。単一のステートメントで両方のポリシーをタグに割り当てることができることに注意してください。

   ALTER TAG governance.tags.accounting SET
     MASKING POLICY account_name_mask,
     MASKING POLICY account_number_mask;
   

   Copy

4. accounting タグを finance.accounting.name_number テーブルに割り当てます。

   ALTER TABLE finance.accounting.name_number
     SET TAG governance.tags.accounting = 'tag-based policies';
   

   Copy

5. Information Schema POLICY_REFERENCES テーブル関数を呼び出して、 ACCOUNT_NAME および ACCOUNT_NUMBER テーブルの列がタグベースのマスキングポリシーによって保護されていることを確認します。

   保護された列ごとに、クエリ結果の行で、列名、ポリシー名、およびタグ名に適切な値を指定する必要があります。

   USE ROLE masking_admin;
   SELECT *
   FROM TABLE (governance.INFORMATION_SCHEMA.POLICY_REFERENCES(
     REF_ENTITY_DOMAIN => 'TABLE',
     REF_ENTITY_NAME => 'governance.accounting.name_number' )
   );
   

   Copy

   戻り値（更新された列に注意）:

   -------------+------------------+---------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+------------+---------------+
     POLICY_DB  | POLICY_SCHEMA    | POLICY_NAME         | POLICY_KIND    | REF_DATABASE_NAME | REF_SCHEMA_NAME | REF_ENTITY_NAME | REF_ENTITY_DOMAIN | REF_COLUMN_NAME | REF_ARG_COLUMN_NAMES | TAG_DATABASE | TAG_SCHEMA | TAG_NAME   | POLICY_STATUS |
   -------------+------------------+---------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+------------+---------------+
     GOVERNANCE | MASKING_POLICIES | ACCOUNT_NAME_MASK   | MASKING_POLICY | FINANCE           | ACCOUNTING      | NAME_NUMBER     | TABLE             | ACCOUNT_NAME    | NULL                 | GOVERNANCE   | TAGS       | ACCOUNTING | ACTIVE        |
     GOVERNANCE | MASKING_POLICIES | ACCOUNT_NUMBER_MASK | MASKING_POLICY | FINANCE           | ACCOUNTING      | NAME_NUMBER     | TABLE             | ACCOUNT_NUMBER  | NULL                 | GOVERNANCE   | TAGS       | ACCOUNTING | ACTIVE        |
   -------------+------------------+---------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+------------+---------------+
   

6. Snowflakeが正しいクエリ結果を返すように、許可されたロールと許可されていないロールでテーブル列をクエリします。

   承認済み:

   USE ROLE accounting_admin;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   戻り値:

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
     ACME         | 1000           |
   ---------------+----------------+
   

   未承認:

   USE ROLE analyst;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   戻り値:

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
     ***MASKED*** | -1             |
   ---------------+----------------+
   

例2: 列タグの文字列値に基づいて列データを保護する¶

この例では、タグベースのマスキングポリシーを使用して、列に割り当てられたタグのタグ文字列値に基づいてデータをマスキングする必要があるかどうかを判断します。マスキングポリシーは、 SYSTEM$GET_TAG_ON_CURRENT_COLUMN 関数をマスキングポリシー条件に呼び出し、タグ文字列値と一致するようにマスキングポリシー条件を書き込むことにより、タグ文字列値を動的に評価します。

次のステップでは、アカウントデータをマスクするためのタグベースのマスキングポリシーを作成します。簡潔にするために、テーブルの列には、それぞれ STRING と NUMBER の2つのデータ型があります。たとえば、 finance.accounting.name_number という名前のテーブルの場合、

---------------+----------------+
  ACCOUNT_NAME | ACCOUNT_NUMBER |
---------------+----------------+
  ACME         | 1000           |
---------------+----------------+

次のように、 ACCOUNT_NAME 列と ACCOUNT_NUMBER 列を保護するためのタグベースのマスキングポリシーを作成します。

1. governance.tags という名前のスキーマに accounting_col_string という名前のタグを作成します。

   USE ROLE tag_admin;
   USE SCHEMA governance.tags;
   CREATE TAG accounting_col_string;
   

   Copy

2. ACCOUNT_NAME 列と ACCOUNT_NUMBER 列を保護するために、異なるマスキングポリシーを作成します。これらの各ポリシーでは、列の現在のタグ文字列値が 'visible' に設定されている場合にのみ、生データが表示されます。

   アカウント名ポリシー:

   USE ROLE masking_admin;
   USE SCHEMA governance.masking_policies;
   
   CREATE MASKING POLICY account_name_mask_tag_string
   AS (val string) RETURNS string ->
     CASE
       WHEN SYSTEM$GET_TAG_ON_CURRENT_COLUMN('tags.accounting_col_string') = 'visible' THEN val
       ELSE '***MASKED***'
     END;
   

   Copy

   アカウント番号ポリシー:

   CREATE MASKING POLICY account_number_mask_tag_string
   AS (val number) RETURNS number ->
     CASE
       WHEN SYSTEM$GET_TAG_ON_CURRENT_COLUMN('tags.accounting_col_string') = 'visible' THEN val
       ELSE -1
     END;
   

   Copy

   注釈

   tags スキーマと masking_policies スキーマの両方が governance データベースに存在するため、これらのポリシーは関数の引数で schema_name.tag_name オブジェクト名の形式を使用します。または、関数の引数でタグに完全修飾名を使用することもできます。

   十分に修飾されていないタグ名がポリシー条件のシステム関数の引数に含まれている場合、Snowflakeは、タグベースのマスキングポリシーによって保護されている列のクエリ実行時にエラーを返します。たとえば、引数は、スキーマ名またはデータベース名を指定せずに、タグ名を accounting_col_string としてのみ使用します。

   詳細については、 オブジェクト名の解決 をご参照ください。

3. 両方のマスキングポリシーを accounting_col_string タグに割り当てます。単一のステートメントで両方のポリシーをタグに割り当てることができることに注意してください。

   ALTER TAG accounting_col_string SET
     MASKING POLICY account_name_mask_tag_string,
     MASKING POLICY account_number_mask_tag_string;
   

   Copy

4. accounting_col_string タグを各テーブル列に割り当てます。この例では、 ACCOUNT_NAME 列のタグ文字列値は 'visible' ですが、 ACCOUNT_NUMBER 列のタグ文字列値は 'protect' に設定されています。

   ALTER TABLE finance.accounting.name_number MODIFY COLUMN
     account_name SET TAG governance.tags.accounting_col_string = 'visible',
     account_number SET TAG governance.tags.accounting_col_string = 'protect';
   

   Copy

5. Information Schema POLICY_REFERENCES テーブル関数を呼び出して、 ACCOUNT_NAME および ACCOUNT_NUMBER テーブルの列がタグベースのマスキングポリシーによって保護されていることを確認します。

   保護された列ごとに、クエリ結果の行で、列名、ポリシー名、およびタグ名に適切な値を指定する必要があります。

   SELECT *
   FROM TABLE(
    governance.INFORMATION_SCHEMA.POLICY_REFERENCES(
      REF_ENTITY_DOMAIN => 'TABLE',
      REF_ENTITY_NAME => 'finance.accounting.name_number'
      )
   );
   

   Copy

   戻り値（更新された列に注意）:

   ------------+----------------+--------------------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+-----------------------+---------------+
    POLICY_DB  | POLICY_SCHEMA  | POLICY_NAME                    |  POLICY_KIND   | REF_DATABASE_NAME | REF_SCHEMA_NAME | REF_ENTITY_NAME | REF_ENTITY_DOMAIN | REF_COLUMN_NAME | REF_ARG_COLUMN_NAMES | TAG_DATABASE | TAG_SCHEMA | TAG_NAME              | POLICY_STATUS |
   ------------+----------------+--------------------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+-----------------------+---------------+
    GOVERNANCE | MASKING_POLICY | ACCOUNT_NAME_MASK_TAG_STRING   | MASKING_POLICY | FINANCE           | ACCOUNTING      | NAME_NUMBER     | TABLE             | ACCOUNT_NAME    | NULL                 | GOVERNANCE   | TAGS       | ACCOUNTING_COL_STRING | ACTIVE        |
    GOVERNANCE | MASKING_POLICY | ACCOUNT_NUMBER_MASK_TAG_STRING | MASKING_POLICY | FINANCE           | ACCOUNTING      | NAME_NUMBER     | TABLE             | ACCOUNT_NUMBER  | NULL                 | GOVERNANCE   | TAGS       | ACCOUNTING_COL_STRING | ACTIVE        |
   ------------+----------------+--------------------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+-----------------------+---------------+
   

6. テーブルの列をクエリして、Snowflakeが正しいクエリ結果を返すことを確認します。これにより、 ACCOUNT_NUMBER 列の値のみがマスクされます。

   USE ROLE accounting_admin;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   戻り値:

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
     ACME         | -1             |
   ---------------+----------------+
   

例3: テーブルタグの文字列値に基づいてテーブルを保護する¶

この例では、行アクセスポリシーを使用して、テーブルに割り当てられたタグ文字列値に基づいてテーブルを保護し、タグベースのマスキングポリシーを使用して、テーブルの列を保護します。簡単にするために、この例では1つのタグを使用し、マスキングポリシーをタグに割り当て、タグをテーブルに割り当てます。タグ継承 のおかげで、テーブルの列は自動的に同じタグとその文字列値を持つことになります。

行アクセスポリシーは、行アクセスポリシー条件で SYSTEM$GET_TAG_ON_CURRENT_TABLE 関数を呼び出すことにより、テーブルに割り当てられたタグのタグ文字列値を動的に評価します。前の例と同様に、マスキングポリシー条件は、 SYSTEM$GET_TAG_ON_CURRENT_COLUMN 関数を呼び出して、テーブル列のタグ文字列値を評価します。

テーブル finance.accounting.name_number には2つの列があり、データ型は STRING と NUMBER です。

---------------+----------------+
  ACCOUNT_NAME | ACCOUNT_NUMBER |
---------------+----------------+
  ACME         | 1000           |
---------------+----------------+

次のように、行アクセスポリシーとタグベースのマスキングポリシーを使用して、テーブルとその列を保護します。

1. ポリシー条件で SYSTEM$GET_TAG_ON_CURRENT_TABLE 関数を呼び出す 行アクセスポリシーを作成 します。

   USE ROLE row_access_admin;
   USE SCHEMA governance.row_access_policies;
   
   CREATE ROW ACCESS POLICY rap_tag_value
   AS (account_number number)
   RETURNS BOOLEAN ->
   SYSTEM$GET_TAG_ON_CURRENT_TABLE('tags.accounting_row_string') = 'visible'
   AND
   'accounting_admin' = CURRENT_ROLE();
   

   Copy

   ポリシーでは、文字列値 'visible' を 使用した accounting_row_string タグがテーブルに割り当てられ、 さらに テーブルまたはその列に対するクエリを実行するロールが accounting_admin カスタムロールの場合に のみ、Snowflakeがクエリ結果の行を返すように指定します。

   次のいずれかに該当する場合、Snowflakeはクエリ結果に行を返しません。

   • accounting_row_string タグがテーブルに設定されていない。

   • accounting_row_string タグはテーブルに設定されているが、文字列値が異なる。

   • テーブルまたはその列に対してクエリを実行するロールが accounting_admin カスタムロールではない。

2. 行アクセスポリシーをテーブルに 割り当て ます。

   ALTER TABLE finance.accounting.name_number
     ADD ROW ACCESS POLICY rap_tag_value ON (account_number);
   

   Copy

   手順のこの時点では、 accounting_row_string タグがテーブルに割り当てられていないため、テーブルのクエリはSnowflakeのロールのクエリ結果の行を 返さない ようにする必要があることに注意してください。したがって、テーブルに対するクエリから期待される結果は次のようになります。

   USE ROLE accounting_admin;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   戻り値:

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
                  |                |
   ---------------+----------------+
   

   タグベースのマスキングポリシーをテーブルに割り当てる前に、行アクセスポリシーをテーブルに割り当てることを選択することにより、すべてのテーブルデータが可能な限り早期に保護されます。

3. governance.tags という名前のスキーマに accounting_row_string という名前のタグを作成します。

   USE ROLE tag_admin;
   USE SCHEMA governance.tags;
   CREATE TAG accounting_row_string;
   

   Copy

4. ACCOUNT_NAME 列と ACCOUNT_NUMBER 列を保護するために、異なるマスキングポリシーを作成します。これらの各ポリシーでは、列の現在のタグ文字列値が 'visible' に設定されている場合にのみ、生データが表示されます。

   アカウント名ポリシー:

   USE ROLE masking_admin;
   USE SCHEMA governance.masking_policies;
   
   CREATE MASKING POLICY account_name_mask AS (val string) RETURNS string ->
     CASE
       WHEN SYSTEM$GET_TAG_ON_CURRENT_COLUMN('tags.accounting_row_string') = 'visible' THEN val
       ELSE '***MASKED***'
     END;
   

   Copy

   アカウント番号ポリシー:

   CREATE MASKING POLICY account_number_mask AS (val number) RETURNS number ->
     CASE
       WHEN SYSTEM$GET_TAG_ON_CURRENT_COLUMN('tags.accounting_row_string') = 'visible' THEN val
       ELSE -1
     END;
   

   Copy

5. 両方のマスキングポリシーを accounting_row_string タグに割り当てます。単一のステートメントで両方のポリシーをタグに割り当てることができることに注意してください。

   ALTER TAG governance.tags.accounting_row_string SET
     MASKING POLICY account_name_mask,
     MASKING POLICY account_number_mask;
   

   Copy

6. accounting_row_string タグをタグ文字列値 'visible' でテーブルに割り当てます。

   ALTER TABLE finance.accounting.name_number
     SET TAG governance.tags.accounting_row_string = 'visible';
   

   Copy

   タグが文字列値 visible でテーブルに割り当てられたため、 accounting_admin カスタムロールのみがテーブルデータを表示できます。他のロールを持つユーザーがクエリを実行すると、この例で前述したように行が返されなくなります。つまり、行アクセスポリシーの条件に該当すると評価されるようになりました。

   同様に、テーブルの列もタグ継承によってタグとその文字列値を継承するため、 visible タグの文字列値を持ちます。その結果、 accounting_admin カスタムロールを持つユーザーがテーブルをクエリすると、Snowflakeはマスクされていないデータを返します。

   USE ROLE accounting_admin;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   戻り値:

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
     ACME         | 1000           |
   ---------------+----------------+
   

7. いずれかの列のデータをマスクするには、列のタグ文字列値を直接更新します。たとえば、 ACCOUNT_NUMBER 列のデータをマスクするには、次のようにします。

   ALTER TABLE finance.accounting.name_number MODIFY COLUMN
     account_number SET TAG governance.tags.accounting_row_string = 'protect';
   

   Copy

   これで、 accounting_admin カスタムロールを持つユーザーがテーブルまたは ACCOUNT_NUMBER 列をクエリすると、Snowflakeはマスクされたデータを返します。

   USE ROLE accounting_admin;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   戻り値:

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
     ACME         | -1             |
   ---------------+----------------+