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

このトピックでは、タグベースのマスキングポリシーに関する概念と、列データを保護するためのタグベースのマスキングポリシー例について説明します。

このトピックの内容:

概要

タグベースのマスキングポリシーは、オブジェクトのタグ付けとマスキングポリシーの機能を組み合わせ、 ALTER TAG コマンドを使用してタグにマスキングポリシーを設定できるようにします。マスキングポリシー署名のデータ型と列のデータ型が一致すると、タグ付けされた列はマスキングポリシーの条件によって自動的に保護されます。これにより、保護する必要のある列データには、データを保護するために手動で列に適用するマスキングポリシーが不要になるため、データ保護の取り組みが簡素化されます。列は、列に直接割り当てられたマスキングポリシーと、タグベースのマスキングポリシーによって保護できます。列がこれらのマスキングポリシーの両方を参照している場合、列に直接割り当てられているマスキングポリシーは、タグベースのマスキングポリシーよりも優先されます。

タグは、Snowflakeがサポートする データ型 ごとに1つのマスキングポリシーをサポートできます。最初の列データ保護の取り組みを簡素化するには、データ型ごとに汎用マスキングポリシーを作成します(例: STRING、 NUMBER、 TIMESTAMP_LTZ)。これにより、許可されたロールは生データを表示し、許可されていないロールは固定のマスク値を表示できるようになります。

マスキングポリシー条件は、ポリシー管理者、タグ管理者、およびデータスチュワードの決定に応じて、タグに割り当てられたポリシーに基づいて列データを保護するか、列に割り当てられたタグのタグ文字列値に基づいて列データを保護するように記述できます。

タグベースのマスキングポリシーの例については、 タグベースのマスキングポリシーの使用 セクション(このトピック内)をご参照ください。

利点

使いやすさ

1つ以上のマスキングポリシーをタグに割り当てるのは簡単です。ポリシー管理者は、既存のワークフローを壊すことなく、ポリシーを追加または置換できます。

スケーラブル

タグベースのポリシーを使用すると、ポリシー管理者はポリシーを1回記述し、ポリシーをタグに1回割り当て、タグが設定されている レベル に応じて、ポリシーを多くのオブジェクトに適用できます。これにより、新しい列が作成または置換されるたびに、単一のポリシーを単一の列に手動で割り当てる必要が大幅に削減されます。

包括的

ポリシー管理者は、データ型ごとにポリシーを作成し、それらすべてのポリシーを単一のタグに割り当てることができます。タグがテーブルレベルで適用されると、列のデータ型がポリシーで指定されたデータ型と一致する場合に、テーブル内のすべての列が保護されます。

将来のオブジェクトの保護

タグベースのマスキングポリシーをテーブルに割り当てると、マスキングポリシーが新しいテーブル列に自動で適用されます。この動作は、 将来の付与 に類似しています。

柔軟性

タグベースのマスキングポリシーは、 CREATE TABLE ステートメントでマスキングポリシーを指定する代わりの方法を提供します。これは、テーブル DDL の管理を簡素化するのに役立ちます。管理者は、マスキングポリシーをテーブルの作成時に割り当てるか、 タグ系統 を使用するタグにポリシーを割り当てるかを選択できます。

考慮事項

制限事項

既存の マスキングポリシーの制限 はすべて、タグベースのマスキングポリシーに適用されます。

タグベースのマスキングポリシーを使用する場合は、次の追加の制限に注意してください。

データ型

タグは、データ型ごとに1つのマスキングポリシーをサポートできます。たとえば、タグにすでに NUMBER データ型のマスキングポリシーがある場合、同じタグに NUMBER データ型の別のマスキングポリシーを割り当てることはできません。

オブジェクトのドロップ

マスキングポリシーがタグに割り当てられている場合は、マスキングポリシーもタグも削除できません。同様に、ポリシーがタグに割り当てられている場合は、タグとマスキングポリシーを含む親スキーマとデータベースを削除することはできません。詳細については、 割り当て (このトピック内)をご参照ください。

マテリアライズドビュー

基になるテーブルまたはビューが、タグベースのマスキングポリシーによって保護されている場合は、マテリアライズドビューを作成することはできません。詳細については、 マスキングポリシーとマテリアライズドビュー をご参照ください。

マテリアライズドビューが存在し、タグベースのマスキングポリシーが基になるテーブルまたはビューに後で追加された場合は、マテリアライズドビューをクエリできません。マテリアライズドビューはこれで無効になります。マテリアライズドビューを引き続き使用するには、タグベースのマスキングポリシーを設定解除、再作成、または 再開 してから、マテリアライズドビューをクエリします。

行アクセスポリシー

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

条件付き列

マスクされた列は、マスキングポリシーの条件付き列としては使用できません。

マッピングテーブル

タグベースのマスキングポリシーで保護されている列を含むテーブルは、マッピングテーブルとしては使用できません。

仮想列

仮想列にタグを割り当てることはできますが、仮想列にタグベースのマスキングポリシーを割り当てることはできません。タグベースのポリシーが仮想列に割り当てられている場合、列のクエリは実行時に失敗します。

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

マスキングポリシーとタグの既存の権限は、マスキングポリシーとタグを管理するための DDL とともに、タグベースのマスキングポリシーに適用されます。

ただし、 APPLY MASKING POLICY 権限と ALTER TAG コマンドには追加の更新があります。

権限

APPLY MASKING POLICY グローバル権限を持つロールは、タグにマスキングポリシーを設定し、タグからマスキングポリシーの設定を解除できます。

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

use role securityadmin;

grant apply masking policy on account to role tag_admin;

割り当て

ALTER TAG コマンドを使用して、タグにマスキングポリシーを設定するか、タグからマスキングポリシーの設定を解除します。ALTER TAG コマンドの構文では、1つのステートメントで複数のマスキングポリシーをタグに割り当てることができることに注意してください。

ALTER TAG <tag_name> SET MASKING POLICY <masking_policy_name> [ , MASKING POLICY <masking_policy_2_name> , ... ]

ALTER TAG <tag_name> UNSET MASKING POLICY <masking_policy_name> [ , MASKING POLICY <masking_policy_2_name> , ... ]

たとえば、 ssn_mask という名前のマスキングポリシーを security という名前のタグに割り当てます。

-- set
alter tag security set masking policy ssn_mask;

-- unset

alter tag security unset masking policy ssn_mask;

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

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

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

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

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

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

条件付き引数

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

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

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

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

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

タグ系統

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

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

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

以下のサブセクションでは、次の情報を提供します。

  • データの保護と検証のためにタグベースのマスキングポリシーで使用する一般的な手順。

  • タグベースのマスキングポリシーを実装する前に完了する必要のある手順。

  • 例の一般的な仮定リスト。

  • 次のシステム機能の使用法を含む、タグベースのマスキングポリシー使用法の代表的な例。

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

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

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

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

    alter tag governance.tags.accounting set
      masking policy account_name_mask,
      masking policy account_number_mask;
    
  4. accounting タグを finance.accounting.name_number テーブルに割り当てます。

    alter table finance.accounting.name_number set tag governance.tags.accounting = 'tag-based policies';
    
  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' )
    );
    

    戻り値(更新された列に注意):

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

    戻り値:

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

    未承認:

    use role analyst;
    select* from finance.accounting.name_number;
    

    戻り値:

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

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

    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;
    

    注釈

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

    戻り値(更新された列に注意):

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

    戻り値:

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

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

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

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

重要

タグには行アクセスポリシーを割り当て られない ことに注意してください。

代わりに、 ALTER TABLE コマンドを使用して、行アクセスポリシーをテーブルに直接割り当てます。

テーブル 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();
    

    ポリシーでは、文字列値 '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);
    

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

    use role accounting_admin;
    select * from finance.accounting.name_number;
    

    戻り値:

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

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

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

    use role tag_admin;
    use schema governance.tags;
    create tag accounting_row_string;
    
  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;
    

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

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

    alter tag governance.tags.accounting_row_string set
      masking policy account_name_mask,
      masking policy account_number_mask;
    
  6. accounting_row_string タグをタグ文字列値 'visible' でテーブルに割り当てます。

    alter table finance.accounting.name_number set tag governance.tags.accounting_row_string = 'visible';
    

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

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

    use role accounting_admin;
    select * from finance.accounting.name_number;
    

    戻り値:

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

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

    use role accounting_admin;
    select * from finance.accounting.name_number;
    

    戻り値:

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

タグベースのマスキングポリシーのトラブルシューティング

次のテーブルに、タグベースのマスキングポリシーを使用したときにSnowflakeが返す可能性のあるいくつかのエラーメッセージを示します。

動作

エラーメッセージ

トラブルシューティングアクション

列をクエリできません。ポリシーが多すぎます。

SQL execution error: Column <col_name> is mapped to multiple masking policies by tags.Please contact your local administrator to fix the issue.

特定の列は、1つのマスキングポリシーによってのみ保護できます。

POLICY_REFERENCES 関数を呼び出して、列に設定されているマスキングポリシーを識別します。タグからマスキングポリシーの設定を解除してタグを変更し、列が1つのポリシーのみで保護されるようにします。

列をクエリできません。条件付き列がありません。

SQL execution error: Column <col_name> is mapped to a masking policy where the table doesnt have acolumn for a secondary argument name of the policy.Please contact your local administrator to fix the issue.

条件付き引数 を使用するマスキングポリシーでは、指定されたすべての列が同じテーブルまたはビューに含まれている必要があります。次のいずれかを実行して、列データを保護します。

  • 列に 直接 別のポリシーを割り当てる。

  • タグに別のマスキングポリシーを 割り当て て、タグを変更する。

列とポリシーのデータ型が一致しないため、列データはマスクされません。

SQL execution error: Column <col_name> is mapped to a masking policy where the table has a column with different data-type for a secondary argument name.Please contact your local administrator to fix the issue.

列データをマスクするには、列のデータ型とマスキングポリシー署名のデータ型が一致している必要があります。次のいずれかを実行して、列データを保護します。

  • 列に 直接 別のポリシーを割り当てる。

  • タグにマスキングポリシーを 割り当て、ポリシーのデータ型と列のデータ型が一致していることを確認する。

最上部に戻る