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

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

このトピックの内容:

概要

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

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

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

ポリシーを割り当てるデータベース、スキーマ、またはテーブルを選択する

データエンジニアとデータスチュワードは、タグベースのマスキングポリシーをデータベース、スキーマ、テーブル、または列に割り当てることができます。

データベースおよびスキーマ:

データベースまたはスキーマにタグベースのマスキングポリシーを設定すると、 タグの系統 を活用して、スキーマまたはデータベースのテーブル列とビュー列を保護できます。データベースまたはスキーマにタグベースのマスキングポリシーを設定すると、列のデータ型がタグに設定されたマスキングポリシーのデータ型と一致する場合に、そのデータベースまたはスキーマ内の列が保護されます。

データベースやスキーマにタグベースのマスキングポリシーを設定する主な利点は、列のデータ型がマスキングポリシーのデータ型と一致する場合に、新しく追加されたすべてのテーブルや表示の列が自動的に保護されることです。このアプローチでは、すべてのテーブルにタグを設定する必要がなくなるため、データ保護管理が簡素化されます。その結果、データ保護担当者が列に直接マスキングポリシーを割り当てるか、テーブルまたはビューに行アクセスポリシーを割り当てるかを決定するまで、このポリシーがSnowflakeの新しいデータを保護します。

テーブル:

テーブルにタグベースのマスキングポリシーを設定すると、テーブル内のすべての列にタグが設定されます。列のデータ型がマスキングポリシーのデータ型と一致する場合に、マスキングポリシーは列データを保護します。

列は、列に直接割り当てられたマスキングポリシーと、タグベースのマスキングポリシーによって保護できます。列がこれらのマスキングポリシーの両方を参照している場合、列に直接割り当てられているマスキングポリシーは、タグベースのマスキングポリシーよりも優先されます。

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

利点

使いやすさ:

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

スケーラブル:

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

包括的:

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

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

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

柔軟性:

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

考慮事項

  • タグがマスキングポリシーおよびテーブルとは異なるスキーマに格納されているタグベースのマスキングポリシーの場合は、マスキングポリシーおよびテーブルを含むスキーマをクローンすると、クローンされたスキーマ内ではなく、ソーススキーマ内のマスキングポリシーによって保護されるクローンされたテーブルが生成されます。

    ただし、タグ、マスキングポリシー、およびテーブルがすべてスキーマに存在するタグベースのマスキングポリシーの場合は、スキーマをクローンすると、ソーススキーマ内ではなく、クローンされたスキーマ内のマスキングポリシーによってテーブルが保護されます。

    テーブルが別のスキーマまたはデータベースにクローンまたは移動され、そのスキーマまたはデータベースで設定されたタグベースのマスキングポリシーによって元々保護されていた場合、そのテーブルはソーススキーマまたはデータベースで設定されたタグベースのマスキングポリシーによっては保護されません。ターゲットスキーマまたはデータベースにタグベースのマスキングポリシーが設定されている場合、テーブルはターゲットスキーマまたはデータベースに設定されたタグベースのマスキングポリシーによって保護されます。

  • 複製とタグベースのマスキングポリシーについては、 ポリシー複製の考慮事項 をご参照ください。

  • Secure Data Sharing とこの機能の詳細については、以下をご参照ください。

制限事項

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

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

データ型:

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

システムタグ:

マスキングポリシーを システムタグ に割り当てることはできません。

オブジェクトのドロップ:

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

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

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

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

行アクセスポリシー:

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

条件付き列:

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

マッピングテーブル:

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

Snowflake Native App Framework:

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

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

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

権限

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

データベースまたはスキーマのタグベースのマスキングでは、現在のロールまたは現在のロール階層内のロールが、次の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. 以下のコマンドのいずれかを使用して、データを保護する方法に基づいてオブジェクトにタグを設定します。

Tip

タグベースのマスキングポリシーを割り当てる前に、スキーマまたはデータベースにタグベースのマスキングポリシーを設定する際、タグとマスキングポリシーの競合を回避するために、

  • Account Usage TAG_REFERENCES ビューをクエリして、テーブルまたはテーブル内の列に設定されている既存のタグを確認します。

  • タグベースのマスキングポリシーがテーブルまたは列に設定されているかどうかを調べるには、Account Usage POLICY_REFERENCES ビューをクエリします。詳細については、 タグおよびポリシーの検出 をご参照ください。

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

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

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

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

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

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

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

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

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;
    
    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 関数を呼び出して、テーブル列のタグ文字列値を評価します。

重要

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

代わりに、 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();
    
    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             |
    ---------------+----------------+
    

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

次のテーブルに、タグベースのマスキングポリシーを使用したときに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.

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

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

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