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

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

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

列レベルのセキュリティとは

Snowflakeの列レベルのセキュリティでは、テーブルまたはビュー内の列にマスキングポリシーを適用できます。現在、列レベルのセキュリティには2つの機能があります。

  1. ダイナミックデータマスキング

  2. 外部トークン化

ダイナミックデータマスキングは、マスキングポリシーを使用してクエリ時にテーブルとビューの列のプレーンテキストデータを選択的にマスクする、列レベルのセキュリティ機能です。

外部トークン化により、アカウントはデータをSnowflakeにロードする前にトークン化し、クエリ実行時にデータをトークン解除できます。トークン化とは、機密データを解読不能なトークンに置き換えて機密データを削除するプロセスです。外部トークン化は、 外部関数 でマスキングポリシーを利用します。

マスキングポリシーとは

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

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

マスキングポリシーの管理者は、マスキングポリシーをテーブルとビューに適用できます。

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

許可されたロールと許可されていないロールのマスキングポリシーの結果。

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

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

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

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

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

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

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

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

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

マスキングポリシーが機能するしくみ

ダイナミックデータマスキングと外部トークン化のマスキングポリシーは同じ構造と形式を採用していますが、1つの重要な例外があります。それは、外部トークン化のマスキングポリシーでは、マスキングポリシー本文で 外部関数の記述 を使用する必要があるという点です。

この例外の理由は、外部トークン化では、データをSnowflakeにロードする前に、サードパーティのトークン化プロバイダーがデータをトークン化する必要があるためです。クエリの実行時に、Snowflakeは外部関数を使用してトークン化プロバイダーにREST API呼び出しを行ってから、トークン化ポリシー(Snowflakeの外部で作成された)を評価し、マスキングポリシー条件に基づいてトークン化または非トークン化データを返します。指定されたクエリから確実に正しいデータを返すことができるように、ロールマッピングがSnowflakeとトークン化プロバイダーに存在する必要があることに注意してください。

Snowflakeは、 CREATE MASKING POLICY を使用したマスキングポリシーの作成をサポートしています。例:

-- Dynamic Data Masking

CREATE MASKING POLICY employee_ssn_mask AS (val string) RETURNS string ->
  CASE
    WHEN CURRENT_ROLE() IN ('PAYROLL') THEN val
    ELSE '******'
  END;

-- External Tokenization

  CREATE MASKING POLICY employee_ssn_detokenize AS (val string) RETURNS string ->
  CASE
    WHEN CURRENT_ROLE() IN ('PAYROLL') THEN ssn_unprotect(VAL)
    ELSE val -- sees tokenized data
  END;
Copy

条件:

employee_ssn_mask

ダイナミックデータマスキングポリシーの名前。

employee_ssn_detokenize

外部トークン化ポリシーの名前。

AS (val string) RETURNS string

入力と出力のデータ型を指定します。データ型は一致する必要があります。

->

ポリシー署名を本文から分離します。

case ... end;

マスキングポリシー本文(つまり、 SQL 式)の条件を指定します。

これら2つの例では、クエリ演算子が現在のセッションでPAYROLLカスタムロールを使用している場合、演算子はマスクされていない/トークン化されていない値を確認します。それ以外の場合は、固定されたマスク/トークン化された値が表示されます。

ssn_unprotect

トークン化されたデータを処理する外部関数。

Tip

既存のマスキングポリシーを更新するためにポリシーの現在の定義を確認する必要がある場合は、 GET_DDL 関数を呼び出すか、 DESCRIBE MASKING POLICY コマンドを実行します。

マスキングポリシーの定義は、 ALTER MASKING POLICY コマンドで更新できます。マスキングポリシーが列に設定されている場合、このコマンドでは列からマスキングポリシーを設定解除する必要はありません。したがって、ポリシーによって保護されている列は、ポリシー定義が更新されている間も保護されたままになります。

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

条件付き列を使用する

条件付きマスキングでは、マスキングポリシーを使用して、1つ以上の異なる列の値に基づいてテーブルまたはビューの列データを選択的に保護します。

別の列を使用して特定の列のデータを保護する必要があるかどうかを判断すると、ポリシー管理者(つまり、 POLICY_ADMIN カスタムロールを持つユーザー)がポリシー条件をより自由に作成できるようになります。

2つの代表的なポリシーの例の違いに注意してください。

マスキングポリシー:

このポリシーは、動的データマスキングに使用できます。

CREATE MASKING POLICY email_mask AS
(val string) RETURNS string ->
  CASE
    WHEN CURRENT_ROLE() IN ('PAYROLL') THEN val
    ELSE '******'
  END;
Copy

このポリシーは、文字列データを含む列を表す1つの引数 val のみを指定します。このポリシーは一度作成すると、文字列データを含む任意の列に適用できます。 CURRENT_ROLEPAYROLL カスタムロールであるユーザーのみが、列データを表示できます。それ以外の場合、Snowflakeは固定のマスクされた値をクエリ結果に返します。

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

条件付きマスキングポリシー:

この例にある引数 (email varchar, visibility string) に注意してください。

CREATE MASKING POLICY email_visibility AS
(email varchar, visibility string) RETURNS varchar ->
  CASE
    WHEN CURRENT_ROLE() = 'ADMIN' THEN email
    WHEN VISIBILITY = 'PUBLIC' THEN email
    ELSE '***MASKED***'
  END;
Copy

このポリシーは、 emailvisibility の2つの引数を指定しており、これらの引数は列名です。最初の列は 常に、マスクする列を指定します。2番目の列は、最初の列をマスクする必要があるかどうかを評価するための条件付き列です。複数の条件列を指定できます。このポリシーでは、 CURRENT_ROLE が ADMIN カスタムロールであるユーザーがメールアドレスを表示できます。電子メールアドレスの可視性列の値も Public の場合、そのメールアドレスはクエリ結果に表示されます。それ以外の場合、Snowflakeは、メール列のマスクされた値が固定されたクエリ結果を返します。

このポリシーは、テーブルまたはビューの列構造がポリシーで指定された列と一致する場合に、複数のテーブルおよびビューで使用できます。詳細については、 CREATE MASKING POLICY をご参照ください。

代表的な例ごとに同じオブジェクトタイプが使用されているため、ポリシーの全体的な動作は類似しています。これには、以下が含まれますが、これらに限定されません。

  • 実行時評価をクエリします。

  • ユーティリティ(例: コンテキスト関数 の使用による、機密データの保護)。

  • 権限構造。

  • 職務の分離をサポートするためのさまざまな管理アプローチでの使用(SoD)。

制限事項:

既存の マスキングポリシーの制限 に加えて、条件付きマスキングポリシーには次の制限があります。

  • 行アクセスポリシー。詳細については、 行アクセスポリシー (このトピック内)をご参照ください。

  • 外部テーブル。詳細については、 外部テーブル (このトピック内)をご参照ください。

考慮事項:

条件付きマスキングポリシーを使用する前に、既存で通常の マスキングポリシーの考慮事項 に加えて、次の点を評価してください。

  • CREATE MASKING POLICY ステートメントで指定されたすべての列が、同じテーブルまたはビューにあることを確認します。

  • ポリシー定義の列引数の数を最小限に抑えます。Snowflakeは、クエリの実行時に各列を評価する必要があります。指定する列の数を減らすと、全体的なパフォーマンスが向上します。

  • Information Schemaテーブル関数 POLICY_REFERENCES を呼び出して、マスキングポリシーの条件付き列の使用状況を追跡します。

条件付き列を使用したマスキングポリシーの設定の詳細については、 列に条件付きマスキングポリシーを適用する (このトピック内)をご参照ください。

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

実行時に、Snowflakeはクエリを書き換えて、マスキングポリシー式をマスキングポリシーで指定した列に適用します。マスキングポリシーは、次のように、SQL式のどこで列が参照されるかに関係なく適用されます。

  • 投影。

  • JOIN述語。

  • WHERE句の述語。

  • ORDER BY およびGROUP BY句。

重要

マスキングポリシーは、関連する列がSQL構造体によって参照される場所に意図的に適用され、マスクされた列データを含めるためのクリエイティブクエリによるデータの匿名化を防止します。

したがって、クエリを実行して1つ以上の列でマスクされたデータが出力された場合、マスクされたデータにより目的のコンテキストですべてのクエリ出力データを評価できないため、クエリ出力が予想される値を提供しない場合があります。

ネストされたオブジェクトを使用したポリシーのマスキング:

Snowflakeは、テーブルのマスキングポリシーや同じテーブルのビューのマスキングポリシーなど、ネストされたマスキングポリシーをサポートしています。クエリの実行時、Snowflakeは特定のクエリに関連するすべてのマスキングポリシーを次の順序で評価します。

  1. テーブルに適用可能なマスキングポリシーは、必ず最初に実行されます。

  2. ビューのポリシーは、テーブルのポリシーを評価した後に実行されます。

  3. ネストされたビューが存在する場合(例: table_1 » view_1 » view_2 » ... view_n)、ポリシーは左から右へ順番に適用されます。

このパターンは、クエリ内のデータに関して存在するマスキングポリシーの数だけ続行します。次の図は、クエリ実行者、テーブル、ビュー、およびポリシー間の関係を示しています。

テーブルとビューを使用したマスキングポリシー。

ユーザークエリ:

次の例では、ユーザーが送信したクエリの後に、Snowflakeランタイムクエリの書き換えが続き、マスキングポリシー(つまり、 sql_expression)が email 列にのみ適用されることを示しています。

SELECT email, city
FROM customers
WHERE city = 'San Mateo';

SELECT <SQL_expression>(email), city
FROM customers
WHERE city = 'San Mateo';
Copy

WHERE句の述語で保護された列を使用したクエリ(アンチパターン):

次の例では、ユーザーが送信したクエリの後に、Snowflakeランタイムクエリの書き換えが続き、ここでマスキングポリシー(つまり、 sql_expression)が比較の片方のみに適用されることを示しています(例: メール列の比較対象である文字列でなく、メール列)。クエリの結果は、ユーザーが意図したものには なりません。比較の片側のみをマスクすることは、一般的なアンチパターンです。

SELECT email
FROM customers
WHERE email = 'user@example.com';

SELECT <SQL_expression>(email)
FROM customers
WHERE <SQL_expression>(email) = 'user@example.com';
Copy

JOIN述語で保護された列を使用したクエリ(アンチパターン):

SELECT b.email, d.city
FROM
  sf_tuts.public.emp_basic AS b
  JOIN sf_tuts.public.emp_details AS d ON b.email = d.email;

SELECT
  <SQL_expression>(b.email),
  d.city
FROM
  sf_tuts.public.emp_basic AS b
  JOIN sf_tuts.public.emp_details AS d ON <SQL_expression>(b.email) = <SQL_expression>(d.email);
Copy

クエリ実行時の考慮事項

Snowflakeでは、列にマスキングポリシーを適用した場合の影響を予測する際、およびクエリオペレーターがマスキングされたデータを表示するかどうかを検討する際に、以下の要素を検討することをお勧めします。

現在のセッション:

CURRENT_ROLE を使用したポリシー条件のマスキング。

実行中のロール:

INVOKER_ROLE を使用したポリシー条件のマスキング。

ロール階層:

IS_ROLE_IN_SESSION または IS_GRANTED_TO_INVOKER_ROLE を使用したポリシー条件のマスキング。

データ共有:

Secure Data Sharing を使用してデータを共有するかどうか。詳細については、このトピックの データ共有 をご参照ください。

複製:

複製 (このトピック内)をご参照ください。

サブクエリ:

マスキングポリシーは、ポリシー定義でサブクエリを参照できますが、Snowflakeでのサブクエリのサポートには制限があります。詳細については、 サブクエリの操作 をご参照ください。

マスキングポリシーでの UDFs の使用:

列、 UDF、およびマスキングポリシーのデータ型が一致していることを確認します。詳細については、 マスキングポリシー内のユーザー定義関数 (このトピック内)をご参照ください。

検索最適化サービス:

検索最適化サービスは、マスキングまたは行アクセスポリシーを使用するテーブルでのクエリパフォーマンスを向上させることができます。

詳細については、 検索最適化サービスにおける、マスキングポリシーと行アクセスポリシーを使用したテーブルのサポート をご参照ください。

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

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

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

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

利点

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

要素

ダイナミックデータマスキング

外部トークン化

メモ

匿名化後の分析値を保持します。

トークン化は特定の文字セットに一意の値を提供するため、機密情報を公開せず、トークン化された値で記録をグループ化することができます。

たとえば、患者の診断コードをトークン化して、診断コードごとに医療記録をグループ化します。次に、データアナリストは、診断コードのビューをクエリして、一意の診断コードを持つ患者の数を取得できます。

トークン化されたデータをプリロードします。

権限のないユーザーには、実際のデータ値は表示されません。サードパーティのトークン化プロバイダーが必要です。

マスクされていないデータをプリロードします。

必要なのは内蔵のSnowflake機能のみで、サードパーティは必要ありません。

データ共有。

詳細については、 データ共有 (このトピック内)をご参照ください。

使いやすさと変更管理。

ポリシーを1回記述して、データベースとスキーマ全体の数千の列に適用します。

データ管理と SoD。

セキュリティまたはプライバシー担当者は、オブジェクト所有者ではなく、保護する列を決定します。

マスキングポリシーは管理が容易であり、集中管理モデルと分散管理モデルをサポートします。

データの承認とガバナンス。

ロールまたはカスタム資格によるコンテキストデータアクセス。

セキュリティまたはプライバシー担当者が実装するデータガバナンスをサポートし、 ACCOUNTADMIN または SECURITYADMIN のシステムロールを持つ権限ユーザーがデータを不必要に表示することを禁止できます。

データベース複製およびアカウントオブジェクト複製。

複製 (このトピック内)をご参照ください。

制限事項

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

制限事項

ダイナミックデータマスキング

外部トークン化

メモ

マテリアライズドビュー(MV)。

包括的な要約については、 マテリアライズドビュー (このトピック内)をご参照ください。

DROP MASKING POLICY

ポリシーをドロップする前に、 ALTER TABLE ... ALTER COLUMN または ALTER VIEW を使用して、テーブルまたはビューの列からポリシーの設定を解除します。

DROP DATABASE および DROP SCHEMA

データベースまたはスキーマをドロップするには、マスキングポリシーとそのマッピングがデータベースまたはスキーマ内で自己完結している必要があります。

たとえば、 database_1 には policy_1 が含まれ、 policy_1database_1 でのみ使用されます。

外部テーブル。

外部テーブルをルックアップテーブルとして(つまり、サブクエリで)参照して、列の値をマスクする必要があるかどうかを判断することはできません。詳細については、 外部テーブル (このトピック内)をご参照ください

ポリシー定義の入力および出力のさまざまなデータ型。

マスキングポリシー定義は、入力と出力で同じデータ型である必要があります。つまり、代表的な例として、入力データ型をタイムスタンプとして定義して文字列を返すことはできません。

ポリシー変更管理のマスキング。

オプションで、選択したバージョン管理システムにマスキングポリシーの変更を保存して追跡できます。

将来の付与

マスキングポリシーに対する権限の 将来の付与 はサポートされていません。

回避策として、カスタムロールに APPLY MASKING POLICY 権限を付与して、そのロールがテーブルまたはビューの列にマスキングポリシーを適用できるようにします。

考慮事項

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

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

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

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

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

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

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

テーブルおよびビューでのレベルのセキュリティ使用

Snowflakeは、テーブルとビューによるマスキングポリシーをサポートしています。以下に、マスキングポリシーがSnowflakeのテーブルとビューにどのように影響するかを説明します。

Tip

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

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

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

このようなユースケースの場合、Snowflakeでは、アカウントロールまたはデータベースロールのどちらを指定するかに応じて、 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 ステートメントを使用してテーブルまたはビュー列にポリシーを適用します。

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

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

    -- 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 ステートメントを使用してテーブルまたはビュー列にポリシーを設定します。

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

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

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

重要

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

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

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

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

行アクセスポリシー

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

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

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

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

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

マテリアライズドビュー

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

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

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

  2. 既存の マテリアライズドビューの場合は、マテリアライズドビューで ALTER VIEW ... MODIFY COLUMN ステートメントを実行します。

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

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

既存の マテリアライズドビューについては、 列にマスキングポリシーを適用する セクション(このトピック内)にあるビューの例をご参照ください。

さらに、マスキングポリシーとマテリアライズドビューに関して、次の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

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

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

重要

Snowflakeは、マスキングポリシーで外部テーブルをルックアップテーブルとして(つまり、サブクエリで)使用することをサポートしていません。データベースをクローンする際、Snowflakeはマスキングポリシーのクローンを作成しますが、外部テーブルのクローンは作成しません。したがって、クローンされたデータベースのポリシーは、クローンされたデータベースに存在しないテーブルを参照します。

ポリシーに外部テーブルのデータが必要な場合は、クローン操作を完了する前に、マスキングポリシーが存在するデータベース内の専用スキーマに、外部テーブルのデータを移動することを検討してください。完全修飾テーブル名を参照するようにマスキングポリシーを更新して、ポリシーが、クローンされたデータベース内のテーブルを参照するようにします。

ストリーム

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

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

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

次のアプローチは、クローンされたオブジェクトにアクセスする際に、テーブルまたはビューに対する 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 POLICYJSON (バリアント)における JavaScript UDFs の使用 の例をご参照ください。

データ共有

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

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

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

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

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

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

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

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

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

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

  • 外部関数。

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

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

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

注釈

外部トークン化の場合、 Secure Data Sharing は適用されません。共有のコンテキストでは外部関数を呼び出すことができないためです。

複製

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

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

  • プライマリデータベースはEnterprise(またはそれ以上)のアカウントにあり、ポリシーを含んでいますが、下位エディションには、複製が承認された1つ以上のアカウントがある。

  • プライマリデータベースに含まれるテーブルまたはビューには、別のデータベースにあるマスキングポリシーへの ダングリングリファレンス がある。

複製グループ で複数のデータベースを複製すると、データベース複製のダングリングリファレンス動作を回避できます。

注釈

フェールオーバーまたはフェールバックのアクションを使用している場合、SnowflakeアカウントはBusiness Critical Editionかそれ以上である必要があります。

詳細については、 複数のアカウント間にわたる複製とフェールオーバーの概要 をご参照ください。

クエリプロファイル

マスキングポリシーを含む列で使用すると、 EXPLAIN コマンドの出力には、マスキングポリシーの本体ではなく、マスキングされたデータが含まれます。

次の例では、従業員識別番号と社会保障番号のテーブルに対するクエリの EXPLAIN プランを生成します。この例のコマンドは、 JSON 形式で例を生成します。

社会保障番号を含む列にはマスキングポリシーがあります。

EXPLAIN USING JSON SELECT * FROM mydb.public.ssn_record;
Copy
{
  "GlobalStats": {
    "partitionsTotal": 0,
    "partitionsAssigned": 0,
    "bytesAssigned": 0
  },
  "Operations": [
    [
      {
        "id": 0,
        "operation": "Result",
        "expressions": [
          "1",
          "'**MASKED**'"
        ]
      },
      {
        "id": 1,
        "parent": 0,
        "operation": "Generator",
        "expressions": [
          "1"
        ]
      }
    ]
  ]
}
Copy

データをアンロードする

マスキングポリシーを持つ列で COPY INTO <場所> コマンドを使用すると、マスキングポリシーがデータに適用されます。したがって、許可のないユーザーには、コマンドの実行後にマスクされたデータを表示します。

Snowflake Native App Framework

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

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

このセクションでは、マスキングポリシーに対する全体的な管理アプローチを決定するのに役立つ情報を提供し、列レベルのセキュリティを管理するために必要な権限について説明し、サポートされている DDL コマンドをリストします。

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

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

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

ポリシーアクション

集中管理

ハイブリッド管理

分散管理

ポリシー作成

セキュリティ責任者

セキュリティ責任者

個別チーム

列にポリシーを適用する

セキュリティ責任者

個別チーム

個別チーム

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

マスキングポリシー権限

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

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

スキーマ内の任意のオブジェクトを操作するには、親データベースとスキーマに対する USAGE 権限も必要であることに注意してください。

権限

使用状況

CREATE

スキーマで、新しいマスキングポリシーを作成できるようにします。

APPLY

列の マスキングポリシー に対する設定解除および設定の操作を実行できるようにします。

APPLY MASKING POLICY グローバル権限(つまり、ACCOUNT の APPLY MASKING POLICY)を付与すると、テーブルとビューで DESCRIBE 操作を実行できることに注意してください。

構文例については、 マスキングポリシー権限 をご参照ください。

OWNERSHIP

マスキングポリシーに対する包括的な制御を付与します。マスキングポリシーのほとんどのプロパティを変更するために必要です。特定のオブジェクトに対して一度にこの権限を保持できるのは、1つのロールのみです。

注釈

マスキングポリシー上で動作するには、親データベースおよび親スキーマでの 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は、列レベルのセキュリティマスキングポリシーを管理するための以下のコマンドセットを提供します。

次のテーブルは、列レベルのセキュリティマスキングポリシー DDL 操作と必要な権限の関係をまとめたものです。

スキーマ内の任意のオブジェクトを操作するには、親データベースとスキーマに対する USAGE 権限も必要であることに注意してください。

操作

権限

マスキングポリシーを作成する

CREATE MASKING POLICY SCHEMA権限を持つロール。

マスキングポリシーを変更する

マスキングポリシーの所有者(つまり、マスキングポリシーに対する OWNERSHIP 権限を持つロール)。

マスキングポリシーを削除する

マスキングポリシーの所有者(つまり、マスキングポリシーに対する OWNERSHIP 権限を持つロール)。

マスキングポリシーを表示する

次のいずれか: . グローバル APPLY MASKING POLICY 権限を持つロール、 または . マスキングポリシーの所有者(つまり、マスキングポリシーに対する OWNERSHIP 権限を持つロール) または . マスキングポリシーに対する APPLY 権限を持つロール。

マスキングポリシーを説明する

次のいずれか: . グローバル APPLY MASKING POLICY 権限を持つロール または . マスキングポリシーの所有者(つまり、マスキングポリシーに対する OWNERSHIP 権限を持つロール) または . マスキングポリシーに対する APPLY 権限を持つロール。

マスキングポリシーを持つ列のリスト

次のいずれか: . APPLY MASKING POLICY 権限を持つロール、 または . 特定のマスキングポリシーに対する MASKING POLICY 権限で APPLY を持つロール および ターゲットオブジェクトに OWNERSHIP があるロール。

マスキングポリシーでの UDFs の使用

新しいマスキングポリシーを作成するか、既存のマスキングポリシーを変更する場合、ポリシー管理者ロールは UDF で使用し、ポリシー式のすべてのスカラー UDFs は同じデータ型であり、 UDF が存在する必要があります。

クエリの実行時に、Snowflakeは UDF が存在するかどうかを確認します。存在しない場合、 SQL 式は解決されず、クエリは失敗します。

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

マスキングポリシーの使用状況は、2つの異なるAccount UsageビューとInformation Schemaテーブルを通じてモニターできます。

マスキングポリシーの使用状況をモニターする方法を決定するために、2つの一般的なアプローチを考えると役に立つ場合があります。

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

共有 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 を使用したマスキングポリシーのモニター

Snowsight Monitoring » Governance 領域を使用すると、テーブル、ビュー、列でのポリシーとタグの使用状況をモニターし、レポートできます。 DashboardTagged Objects という2つの異なるインターフェイスがあります。

Dashboard および Tagged Objects インターフェイスを使用する場合は、次の詳細に注意してください。

  • Dashboard および Tagged Objects インターフェイスには稼働中のウェアハウスが必要です。

  • Snowsight は、 Dashboard を12時間ごとに更新します。

  • Tagged Objects 情報の遅延は最大2時間になる可能性があり、最大1000個のオブジェクトが返されます。

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ビューで複雑なクエリ集中型の操作を実行するための代替または補完です。

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

タグ付きオブジェクト

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

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

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

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

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

Tip

Snowsight を使用して、マスキングポリシーの割り当てのトラブルシューティングを行うことができます。 Columns タブでは、列のマスキングポリシーの割り当てと競合がある場合、 MASKING POLICY 列に Policy Error が表示されます。詳細については、 Policy Error を選択します。

さらに、列のマスキングポリシーの割り当てにエラーがある場合、 Data Preview タブにはデータプレビューが表示されません。代わりに、 Data Preview タブは SQL エラー メッセージを返します。このメッセージは、Account Usage POLICY_REFERENCES ビューおよびInformation Schema POLICY_REFERENCES テーブル関数の POLICY_STATUS 列にあるエラー値の1つに対応します。

エラーを修正するには、 SQL エラーメッセージと Policy Error メッセージを使用してタグまたはポリシーの割り当てを変更します。

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