行アクセスポリシーについて

このトピックでは、行アクセスポリシーと行レベルのセキュリティの概要を説明します。

このトピックの内容:

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

Snowflakeは、行アクセスポリシーを使用してクエリ結果で返す行を決定することにより、行レベルのセキュリティをサポートします。行アクセスポリシーは、1つの特定のロールが行を表示できるようにするために比較的単純な場合もあれば、クエリ結果の行へのアクセスを決定するためにポリシー定義に マッピングテーブル を含めるときのように、より複雑な場合もあります。ポリシーにマッピングテーブルルックアップが含まれている場合は、一元化されたマッピングテーブルを作成し、保護されたテーブルと同じデータベースにマッピングテーブルを格納します。これは、ポリシーが IS_DATABASE_ROLE_IN_SESSION 関数を呼び出す場合に特に重要です。詳細については、関数の使用上の注意をご参照ください。

行アクセスポリシーは、次の型のステートメントから、テーブルまたはビューの特定の行を表示できるかどうかを決定する、スキーマレベルのオブジェクトです。

  • SELECT ステートメント

  • UPDATEDELETE、および MERGE ステートメントによって選択された行。

行アクセスポリシーには、ポリシー式に条件と関数を含めることができ、それらの条件が満たされた場合は、クエリの実行時にデータが変換されます。ポリシー主導のアプローチは、職務の分離をサポートし、ガバナンスチームが機密データの公開を制限するポリシーを定義できるようにします。このアプローチには、通常は基になるデータへのフルアクセス権を持つオブジェクト所有者(つまり、テーブルやビューなど、オブジェクトに対する OWNERSHIP 権限を持つロール)も含まれます。単一のポリシーを異なるテーブルとビューに同時に設定できます。

行アクセスポリシー管理者は、テーブルとビューに行アクセスポリシーを適用できます。

現在、行アクセスポリシーは、行の挿入を防止したり、表示されている行の更新や削除の防止したりすることはできません。

行アクセスポリシーは、オブジェクトの作成時またはオブジェクトの作成後にテーブルまたはビューに追加できます。詳細については、 テーブルまたはビューに行アクセスポリシーを適用する (このトピック内)をご参照ください。

行アクセスポリシーのしくみ

行アクセスポリシーには、Snowflakeデータベースオブジェクト(テーブルやビューなど)を指定し、 条件式関数コンテキスト関数 を使用して、特定のコンテキストで表示する行を決定できる式が含まれています。

Snowflakeは、クエリを実行した演算子のロールではなく、 ポリシー所有者 のロールを使用してポリシー式を評価します。このアプローチでは、クエリ演算子は行アクセスポリシーのマッピングテーブルへのアクセスを必要としないため、Snowflakeはクエリ結果に行を返さないようにします。

Tip

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

その後、行アクセスポリシー式を ALTER ROW ACCESS POLICY コマンドで更新できます。このコマンドでは、テーブルまたはビューから行アクセスポリシーをドロップする必要はありません。したがって、行アクセスポリシーによって保護されているテーブルまたはビューは、ポリシー式が更新されている間も保護されたままになります。

クエリ実行時の行アクセスポリシー

クエリ実行時に、Snowflakeは次のプロセスを実行します。

  1. Snowflakeは、行アクセスポリシーがデータベースオブジェクトに設定されているかどうかを判別します。ポリシーがデータベースオブジェクトに追加されると、すべての行がポリシーによって保護されます。

  2. Snowflakeは、データベースオブジェクトの動的なセキュアビュー(つまり、セキュアインラインビュー)を作成します。

  3. ALTER TABLE または ALTER VIEW コマンドで指定された列の値(つまり、行アクセスポリシーをテーブルまたはビューに追加する場合)は、ポリシー内の対応するパラメーターにバインドされ、ポリシー式が評価されます。

  4. Snowflakeはユーザーのクエリ出力を生成し、クエリ出力には TRUE と評価されるポリシー定義に基づく行のみが含まれます。

特定の実行プランの詳細については、 クエリプロファイル (このトピック内)をご参照ください。

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

  • テーブルに適用可能な行アクセスポリシーは、必ず最初に実行されます。

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

  • ネストされたビューが存在する場合(例: テーブル1 -> ビュー1 -> ビュー2 -> ...ビューn)、ポリシーは左から右へと順番に適用されます。

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

テーブルとビューの行アクセスポリシー。

行アクセスポリシーの権限、コマンド、および段階的な実装の詳細については、以下をご参照ください。

代表的なユースケース: 単純な行フィルタリング

行アクセスポリシーの簡単なアプリケーションは、ポリシーで属性を指定し、クエリ結果でその属性を表示できるようにするロールを指定することです。このような単純なポリシーの利点は、マッピングテーブルで行アクセスポリシーを使用する場合と比較して、Snowflakeがこれらのポリシーを評価してクエリ結果を返すためのパフォーマンスコストがごくわずかであることです。

代表的な例として、情報技術管理者(例: it_admin カスタムロール)は、内部システムを使用するための追加の権限を従業員に付与する前に、従業員ID番号(つまり、 empl_id)のクエリが必要になる場合があります。したがって、行アクセスポリシーは、 CURRENT_ROLEit_admin カスタムロールと一致する場合にクエリ結果で行を返し、他のすべてのロールには行を返さないようにします。例:

CREATE OR REPLACE ROW ACCESS POLICY rap_it
AS (empl_id varchar) RETURNS BOOLEAN ->
  'it_admin' = current_role()
;
Copy

このポリシーは、評価する他の条件がなく、 CURRENT_ROLE の値のみであるため、行アクセスポリシーの最も簡潔なバージョンです。

ロール階層を考慮する必要がある場合、このポリシーは同様に IS_ROLE_IN_SESSION を使用して、クエリ結果に従業員 ID 番号を表示するために他のロールを含めることができます。

または、追加の条件を検討するために、 CASE 関数を使用すると、 WHEN/THEN/ELSE 句を含めて、より詳細な条件付きロジックをサポートできます。

代表的な使用例: マッピングテーブルを使用してクエリ結果をフィルターする

行アクセスポリシー条件は、マッピングテーブルを参照してクエリ結果セットをフィルターできますが、マッピングテーブルを使用すると、より 単純な の例と比較して、パフォーマンスが低下する可能性があります。

たとえば、マッピングテーブルを使用して、営業部長が指定された販売地域で表示できる売上高の値を決定します。マッピングテーブルでは、営業部長と販売地域を指定する必要があります(例: WW: 全世界、 NA: 北米、 EU: 欧州連合)。

営業部長

地域

アリス

WW

ボブ

NA

サイモン

EU

次に、1つ以上の条件を使用してポリシーを定義し、サブクエリを使用してマッピングテーブルをクエリします。クエリの実行時に、Snowflakeは、クエリを実行するユーザーがマッピングテーブルで指定された販売地域と一致するかどうかを判断します。

一致が発生した場合、ユーザーはクエリ結果にそれらの行を表示できます。マッピングテーブルによると、予想されるクエリ結果は次のとおりです。

会社

地域

売上高

表示できる人

Acme

EU

25億

アリス、サイモン

Acme

NA

15億

アリス、ボブ

マッピングテーブルを使用した行アクセスポリシーの実装の詳細については、次をご参照ください。

ポリシーパフォーマンスガイドライン

行アクセスポリシーは、さまざまな実際のシナリオで適切に機能するように設計されています。次のヒントを使用して、データを保護し、パフォーマンスを向上させます。

ポリシー引数を制限する:

Snowflakeは、クエリで参照されていない場合でも、ポリシーがバインドされている列をスキャンする必要があります。したがって、引数が少ないポリシーは、引数が多いポリシーよりも通常パフォーマンスが向上します。

SQL 式を単純化する:

CASE ステートメントなどの単純な SQL 式を使用するポリシーは、マッピング(つまり、ルックアップ)テーブルにアクセスするポリシーよりも通常パフォーマンスが向上します。テーブルルックアップの数を最小限に抑えると、パフォーマンスが向上します。

マッピングテーブルを指定するときは、マッピングテーブル参照をメモ可化能な関数に置き換えます。詳細については、次をご参照ください。

現実的なワークロードでテストする:

行アクセスポリシーがない場合、Snowflakeはテーブル内の行数をすでに認識しているため、クエリ SELECT COUNT(*) FROM t1 はミリ秒単位で実行されます。ただし、行アクセスポリシーを追加すると、Snowflakeはテーブルをスキャンして、現在のコンテキストでアクセス可能な行の数をカウントする必要があります。パフォーマンスの違いは大きくなりますが、このクエリは実際のワークロードの大部分を代表するものではありません。

この例の詳細については、 考慮事項 セクション(このトピック内)をご参照ください。

属性によるクラスター:

非常に大きなテーブルの場合は、ポリシーフィルタリングに使用される属性でのクラスタリングにより、パフォーマンスを向上させることができます。

詳細については、 クラスタリングキーとクラスタ化されたテーブル をご参照ください。

検索最適化サービス:

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

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

利点

行アクセスポリシーの主な利点は、このポリシーにより、組織が拡張可能なポリシーを通じてデータセキュリティ、ガバナンス、および分析のバランスを適切にとることができることです。行アクセスポリシーの拡張可能な性質により、いつでも1つ以上の条件を追加または削除して、ポリシーがデータ、マッピングテーブル、および RBAC 階層の更新と整合していることを確認できます。

その他の利点は次のとおりです。

使いやすさ:

1度ポリシーを作成すると、データベースとスキーマ全体のテーブルに適用できます。

変更管理:

ポリシーをテーブルに再適用しなくても、行アクセスポリシー定義を簡単に変更できます。

マッピングテーブルを使用している場合は、ポリシーを変更せずに、ポリシーによって参照されるマッピングテーブルの資格情報を更新します。

データ管理と SoD:

中央のデータ管理者は、オブジェクトの所有者ではなく、保護するオブジェクトを決定します。行アクセスポリシーは、職務の分離(つまり、 SoD)をサポートするための集中型、分散型、およびハイブリッド型の管理モデルを通じて、簡単に管理とサポートができます。

データの認証とガバナンス:

行アクセスポリシーは、ロールまたはカスタム資格によるコンテキストデータアクセスをサポートしています。

制限事項

  • 行アクセスポリシーで保護されたビューでの CHANGES 句の使用はサポートされていません。

  • Snowflakeは、行アクセスポリシーのマッピングテーブルとして外部テーブルを使用することをサポートしていません。詳細については、 外部テーブル (このトピック内)をご参照ください。

  • Snowflakeは、ストリームオブジェクト自体への行アクセスポリシーの添付をサポートしていませんが、ストリームが行アクセスポリシーで保護されているテーブルにアクセスするときに、行アクセスポリシーをテーブルに適用します。詳細については、 ストリーム (このトピック内)をご参照ください。

  • 行アクセスポリシーに対する権限の 将来の付与 はサポートされていません。

    回避策として、カスタムロールに APPLYROW ACCESS POLICY 権限を付与して、そのロールがテーブルまたはビューに行アクセスポリシーを適用できるようにします。

考慮事項

  • 他の行アクセスポリシーまたはマスキングポリシーによって保護されているテーブルに行アクセスポリシーを添付すると、エラーの発生する可能性があります。詳細については、 ALTER TABLEALTER EXTERNAL TABLE および ALTER VIEW をご参照ください。

  • ポリシー本体に1つ以上の サブクエリ を含めると、エラーが発生する可能性があります。可能であれば、サブクエリの数を制限し、 JOIN 操作の数を制限し、 WHERE 句の条件を単純化します。

  • Snowflakeは、テーブルとビューの列に関する統計を維持し、ミリ秒単位で多くの単純なクエリに回答できるようにします。このようなクエリの例には、 COUNT 関数、 select count(*) from my_table の使用や、 MAX 関数、 select max(c) from my_table の使用が含まれます。

    Snowflakeは、クエリによるアクセスが許可されている行のサブセットを識別する必要があるため、通常、これらの統計と最適化は行アクセスポリシーには適用できません。行アクセスポリシーを使用してテーブルとビューでこの型のクエリを実行すると、これらの統計と最適化が使用されないため、クエリ結果を取得するのに予想よりも時間がかかる場合があります。そして、返される統計は、アクセスが許可されているもののみに基づいており、「真の」統計値(つまり、行アクセスポリシーのないテーブルまたはビューの統計)ではありません。

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

Snowflakeオブジェクトおよび機能で行アクセスポリシーを使用する

次のセクションでは、行アクセスポリシーが他のSnowflake機能とともにテーブルとビューにどのような影響を与えるかについて説明します。

行アクセスポリシーを使用してデータベースオブジェクトを取得する

Information Schema POLICY_REFERENCES テーブル関数は、特定のオブジェクトに割り当てられた行アクセスポリシーに関する情報を返すことができます。

  • 特定のポリシーに対してすべてのオブジェクトは、

    行アクセスポリシーの名前を指定します(例: mydb.policies.rap1)。

    SELECT *
    FROM TABLE(
      mydb.INFORMATION_SCHEMA.POLICY_REFERENCES(
        POLICY_NAME=>'mydb.policies.rap1'
      )
    );
    
    Copy
  • 特定のオブジェクトに割り当てられたポリシーは、

    オブジェクトの名前(例: mydb.tables.t1)とオブジェクトドメイン(例: table)を指定します。

    SELECT *
    FROM TABLE(
      mydb.INFORMATION_SCHEMA.POLICY_REFERENCES(
        REF_ENTITY_NAME => 'mydb.tables.t1',
        REF_ENTITY_DOMAIN => 'table'
      )
    );
    
    Copy

このテーブル関数は、Account Usage POLICY_REFERENCES ビューを補完するものであることに注意してください。

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

ポリシー条件は、ポリシー管理者がポリシーを記述する方法次第で、セッションで直接ユーザーのアクティブなプライマリロールとセカンダリロールを評価したり、マッピングテーブルでアクティブなロールを検索したり、その両方を実行したりできます。ポリシーにマッピングテーブルルックアップが含まれている場合は、一元化されたマッピングテーブルを作成し、保護されたテーブルと同じデータベースにマッピングテーブルを格納します。これは、ポリシーが 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 VIEW ステートメントを含むビューにポリシーを適用する。

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

-- table
CREATE TABLE sales (
  customer   varchar,
  product    varchar,
  spend      decimal(20, 2),
  sale_date  date,
  region     varchar
)
WITH ROW ACCESS POLICY sales_policy ON (region);

-- view
CREATE VIEW sales_v WITH ROW ACCESS POLICY sales_policy ON (region)
AS SELECT * FROM sales;
Copy

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

-- table

ALTER TABLE t1 ADD ROW ACCESS POLICY rap_t1 ON (empl_id);

-- view

ALTER VIEW v1 ADD ROW ACCESS POLICY rap_v1 ON (empl_id);
Copy

マスキングポリシー

データベースオブジェクトに行アクセスポリシーと1つ以上の マスキングポリシー の両方がある場合、Snowflakeは最初に行アクセスポリシーを評価します。

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

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

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

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

外部テーブル

CREATE EXTERNAL TABLE ステートメントを実行することにより、行アクセスポリシーを使用して外部テーブルを作成し、VALUE にポリシーを適用することができます。

外部テーブルで ALTER TABLE ステートメントを実行することにより、行アクセスポリシーを外部テーブルの VALUE 列に適用できます。

行アクセスポリシーを仮想列に直接追加することはできません。代わりに、外部テーブルでビューを作成し、ビューの列に行アクセスポリシーを適用します。

重要

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

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

ストリーム

行アクセスポリシーがテーブルに追加された場合、Snowflakeは、ストリームがテーブルデータにアクセスするときに、行アクセスポリシーをテーブルデータに適用します。

詳細については、 制限事項 をご参照ください。

ビュー

Snowflakeは、ベーステーブルとビューでの行アクセスポリシーの設定をサポートしています。ベーステーブルまたはビューポリシーは、ビューの所有者(つまり、 INVOKER_ROLE)またはクエリ演算子のロール(つまり、 CURRENT_ROLE)に適用できます。

詳細については、 制限事項 をご参照ください。

マテリアライズドビュー

行アクセスポリシーが基になるテーブルまたはビューに設定されて いない 場合、Snowflakeは、マテリアライズドビューへの行アクセスポリシーの追加をサポートします。

行アクセスポリシーとマテリアライズドビューには、次の制限があります。

  • 行アクセスポリシーが基になるテーブルに追加されている場合は、そのテーブルからマテリアライズドビューを作成することはできません。

  • マテリアライズドビューが基になるテーブルから作成されている場合は、そのテーブルに行アクセスポリシーを追加することはできません。

CREATE TABLE ステートメント

以下は、行アクセスポリシーが CREATE TABLE ステートメントにどのように影響するかをまとめたものです。

CREATE TABLE ... CLONE:

次のアプローチは、クローンされたオブジェクトにアクセスする際に、テーブルまたはビューに対する SELECT 権限を持つユーザーからデータを保護するのに役立ちます。

  • 個別のポリシーオブジェクトのクローニングはサポートされていません。

  • スキーマのクローニングにより、スキーマ内のすべてのポリシーがクローニングされます。

  • クローンされたテーブルは、ソーステーブルと同じポリシーにマップされます。つまり、ベーステーブルまたはその列にポリシーが設定されている場合、そのポリシーはクローンテーブルまたはその列にアタッチされます。

    • テーブルがその親スキーマクローニングのコンテキストでクローンされるときに、同じ親スキーマのポリシーへの参照(つまり、ローカル参照)がソーステーブルにあると、クローンされたテーブルはクローンされたポリシーへの参照を持つようになります。

    • ソーステーブルが別のスキーマのポリシー(つまり、外部参照)を参照している場合、クローンされたテーブルは外部参照を保持します。

詳細については、 CREATE <オブジェクト> ... CLONE をご参照ください。

CREATE TABLE ... LIKE:

行アクセスポリシーがベーステーブルに設定されている場合、行アクセスポリシーは新しいテーブルの列に設定 されません。新しいテーブルは空です。

CREATE TABLE ... AS SELECT:

行アクセスポリシーがベーステーブルに設定されている場合、新しいテーブルには、行アクセスポリシー定義に基づいてフィルターされた行が含まれます。新しいテーブルでは、列に行アクセスポリシーが設定されていません。

クエリプロファイル

クエリの実行時に、Snowflakeは 動的なセキュアビュー を作成します。

行アクセスポリシーが設定されているデータベースオブジェクトで EXPLAIN コマンドを使用すると、クエリ結果は行アクセスポリシーが存在することを示します。データベースオブジェクトに行アクセスポリシーが設定されている場合、 EXPLAIN クエリ結果は次の列値を指定します。

  • operation 列には値 DynamicSecureView が含まれます。

  • object 列には、値 "<オブジェクト名> (+ RowAccessPolicy)" が含まれます。

行アクセスポリシーの呼び出しを必要とするクエリプランの各ステップの結果は、クエリプランのそのステップに対応する値を指定する operation 列と object 列になります。行アクセスポリシーがクエリで1回だけ呼び出された場合は、 EXPLAIN クエリ結果の1つの行にのみ DynamicSecureView"<オブジェクト名> (+ RowAccessPolicy)" の値が含まれます。

EXPLAIN コマンドの結果と クエリプロファイル ウェブインターフェイスで、Snowflakeは、ユーザーに行アクセスポリシー 情報 (つまり、ポリシー名、ポリシー署名、ポリシー式)またはポリシーによってアクセスされたオブジェクトを表示しません。

次の例は、行アクセスポリシーが1回だけ呼び出されることを示しています。

EXPLAIN SELECT * FROM my_table;
Copy
+-------+--------+--------+-------------------+--------------------------------+--------+-------------+-----------------+--------------------+---------------+
|  step |   id   | parent |     operation     |           objects              | alias  | expressions | partitionsTotal | partitionsAssigned | bytesAssigned |
+-------+--------+--------+-------------------+--------------------------------+--------+-------------+-----------------+--------------------+---------------+
...

| 1     | 2      | 1      | DynamicSecureView | "MY_TABLE (+ RowAccessPolicy)" | [NULL] | [NULL]      | [NULL]          | [NULL]             | [NULL]        |
+-------+--------+--------+-------------------+--------------------------------+--------+-------------+-----------------+--------------------+---------------+

次の例は、同じテーブルで2回呼び出されている行アクセスポリシーを示しています。

EXPLAIN SELECT product FROM sales
  WHERE revenue > (SELECT AVG(revenue) FROM sales)
  ORDER BY product;
Copy
+--------+--------+--------+-------------------+-----------------------------+--------+-------------+-----------------+--------------------+---------------+
|  step  |   id   | parent |     operation     |           objects           | alias  | expressions | partitionsTotal | partitionsAssigned | bytesAssigned |
+--------+--------+--------+-------------------+-----------------------------+--------+-------------+-----------------+--------------------+---------------+
...
| 1      | 0      | [NULL] | DynamicSecureView | "SALES (+ RowAccessPolicy)" | [NULL] | [NULL]      | [NULL]          | [NULL]             | [NULL]        |
...
| 2      | 2      | 1      | DynamicSecureView | "SALES (+ RowAccessPolicy)" | [NULL] | [NULL]      | [NULL]          | [NULL]             | [NULL]        |
+--------+--------+--------+-------------------+-----------------------------+--------+-------------+-----------------+--------------------+---------------+

Time Travel

Snowflakeは、行アクセスポリシーを使用して、テーブルとビューでのTime Travelをサポートします。

クエリの実行時に、Snowflakeは行アクセスポリシーのマッピングテーブルをクエリ時に評価します。言い換えれば、Time Travelはマッピングテーブルに影響を与えません。

詳細については、 Time Travelの理解と使用 をご参照ください。

複製

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

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

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

  • プライマリデータベースに含まれるテーブルまたはビューには、別のデータベースにある行アクセスポリシーへの ダングリング参照 があります。

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

注釈

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

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

データ共有

使用状況:
  • プロバイダーが共有テーブルまたはビューにポリシーを割り当て、ポリシー条件が 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は次の場合にエラーを返します。

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

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

Snowflake Native App Framework

Snowflake Native App を使用した行アクセスポリシーの詳細については、次をご参照ください。

行アクセスポリシーを管理する

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

行アクセスポリシーを効果的に管理するには、行をフィルタリングするアプローチが、集中型、分散型、またはハイブリッド型のガバナンスアプローチに従う必要があるかどうかを検討すると役立ちます。

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

ポリシーアクション

集中型

ハイブリッド型

分散型

ポリシー作成

ガバナンス責任者

ガバナンス責任者

個別チーム

列にポリシーを適用する

ガバナンス責任者

個別チーム

個別チーム

構文例については、 DDL コマンド、操作、および権限の概要 をご参照ください。

Tip

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

行アクセスポリシーの権限

Snowflakeは、ユーザーが行アクセスポリシーを作成、設定、および所有できるかどうかを決定するために、次の行アクセスポリシー権限をサポートしています。

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

権限

使用状況

CREATE

スキーマで、新しい行アクセスポリシーを作成できるようにします。

APPLY

テーブルまたはビューの 行アクセスポリシー の追加およびドロップ操作を実行できるようにします。

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

構文例については、 DDL コマンド、操作、および権限の概要 をご参照ください。

OWNERSHIP

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

行アクセスポリシー DDL

Snowflakeは、行アクセスポリシーを管理するために、次の DDL コマンドと操作をサポートしています。

DDL コマンド、操作、および権限の概要

次のテーブルは、行アクセスポリシー DDL 操作と必要な権限の関係をまとめたものです。

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

操作

必要な権限

行アクセスポリシーを作成する

同じスキーマ内の CREATE ROW ACCESS POLICY 権限を持つロール。

行アクセスポリシーを変更する

行アクセスポリシーに対する OWNERSHIP 権限を持つロール。

Add/Drop 行アクセスポリシー

アカウントに対する APPLY ROW ACCESS POLICY 権限を持つロール、 または データベースオブジェクトに対する OWNERSHIP 権限と行アクセスポリシーオブジェクトに対する APPLY 権限を持つロール。

行アクセスポリシーをドロップする

次のいずれか: 行アクセスポリシーに対する OWNERSHIP 権限を持つロール または . 行アクセスポリシーが存在するスキーマに対する OWNERSHIP 権限を持つロール。

行アクセスポリシーを表示する

次のいずれか: . APPLY ROW ACCESS POLICY 権限、 または . 行アクセスポリシーの OWNERSHIP 権限、 または . 行の APPLY 権限を持つロールアクセスポリシー。

行アクセスポリシーを説明する

次のいずれか: APPLY ROW ACCESS POLICY 権限、 または . 行アクセスポリシーの OWNERSHIP 権限、 または . 行の APPLY 権限を持つロールアクセスポリシー。

Snowflakeは、オブジェクトに行アクセスポリシーを作成および設定するためのさまざまなアクセス権限をサポートしています。

  1. rap_admin カスタムロールが すべての オブジェクトに行アクセスポリシーを作成および設定する、集中型行アクセスポリシー管理アプローチの場合、次の権限が必要です。

    use role securityadmin;
    grant create row access policy on schema <db_name.schema_name> to role rap_admin;
    grant apply row access policy on account to role rap_admin;
    
    Copy
  2. ハイブリッド型管理アプローチでは、単一のロールに CREATE ROW ACCESS POLICY 権限があり、クエリのパフォーマンスを最適化するための一貫したポリシー作成が保証され、個々のチームまたはロールには、テーブルとビューを保護するための特定の行アクセスポリシーに対する APPLY 権限があります。

    たとえば、カスタムロール finance_role ロールには、テーブルに行アクセスポリシー rap_finance を追加する権限を付与し、ロールが所有するビューを表示できます。

    use role securityadmin;
    grant create row access policy on schema <db_name.schema_name> to role rap_admin;
    grant apply on row access policy rap_finance to role finance_role;
    
    Copy

SQL を使用した行アクセスポリシーをモニターする

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

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

行アクセスポリシーを見つける

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

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.ROW_ACCESS_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(
        POLICY_NAME => 'rap_t1'
      )
    );
    
    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 タブが開きます。必要に応じて、タグとポリシーの割り当てを編集できます。

行アクセスポリシーを監査する

Snowflakeは、行アクセスポリシーの監査とガバナンス操作を容易にするために、次のアプローチをサポートしています。

  • SHOW ROW ACCESS POLICIES を使用して、アカウントからドロップされていない行アクセスポリシーのリストを作成します。

  • 行アクセスポリシー管理者(つまり、行アクセスポリシー OWNERSHIP 権限 を持つユーザー)は、 Time Travel または ストリーム を使用して、行アクセスポリシーで参照されているマッピングテーブルに関する履歴データをキャプチャできます。

  • 特定のユーザーがアクセスできるデータを判別するために、行アクセスポリシー管理者はユーザーのロールを引き受けてクエリを実行できます。

    • Snowflakeは、 CREATE ROW ACCESS POLICY コマンドでこの動作をサポートするカスタムロジックを使用した、行アクセスポリシー expression の定義をサポートしています。

    • Snowflakeには現在、この操作をサポートするためのデフォルトのメカニズム(例: 専用システムまたはコンテキスト関数)がありません。

  • 特定の行アクセスポリシーがマッピングテーブルを使用して、行データにアクセスできるロールとユーザー集団を決定する場合、行アクセスポリシーの所有者は、マッピングテーブルにクエリを実行して、許可されたユーザーアクセスをオンデマンドで決定できます。

  • Snowflakeは、Account Usage QUERY_HISTORY ビュー ビューの行アクセスポリシーに関連するエラーメッセージ情報をキャプチャしてログに記録します。クエリでエラーが発生した場合、Snowflakeはクエリの評価中に発生した最初のエラーメッセージを記録します。行アクセスポリシーのエラーメッセージの詳細については、 行アクセスポリシーをトラブルシューティングする をご参照ください。

  • 特定のユーザーが過去にアクセスしたデータを識別するには、データベースオブジェクトの行アクセスポリシーと関連があるため、Time Travelを ROW_ACCESS_POLICIES Account Usageビューおよび POLICY_REFERENCES Information Schemaテーブル関数と組み合わせて使用します。

    • ポリシーテーブルとマッピングテーブル(存在する場合)が変更されていない場合、行アクセスポリシー管理者はユーザーのロールを引き受け、Time Travelクエリを実行できます。 CURRENT_ROLE などの関連するセッションパラメーターの値は、クエリ結果で利用できます。

    • ポリシーまたはマッピングテーブルが変更された場合、行アクセスポリシー管理者は、マッピングテーブルに対してTime Travelクエリを実行し、指定されたインシデント時に存在した行アクセスポリシーを再構築する必要があります。これらのステップの後、行アクセスポリシー管理者はデータのクエリを開始し、分析を続行できます。

行アクセスポリシーをトラブルシューティングする

次の動作とエラーメッセージは、行アクセスポリシーに適用されます。

動作

エラーメッセージ

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

行アクセスポリシーを設定できません(マテリアライズドビュー)。

行アクセスポリシーをマテリアライズドビューに添付できません。

マテリアライズドビューで行アクセスポリシーを設定できることを確認します。 マテリアライズドビュー (このトピック内)をご参照ください。

行アクセスポリシーを作成できません(ブール値)。

003551=SQL compilation error: 行アクセスポリシーの戻り値の型「{0}」が BOOLEAN ではありません。

行アクセスポリシー定義には RETURNS BOOLEAN が必要です。 CREATE ROW ACCESS POLICY に示すように、行アクセスポリシーを書き直します。

行アクセスポリシーを作成できません(データベース)。

このセッションには現在のデータベースがありません。「USE DATABASE」を呼び出すか、修飾名を使用します。

行アクセスポリシーはスキーマレベルのオブジェクトであるため、現在のセッションのデータベースとスキーマを定義するか、 CREATE ROW ACCESS POLICY コマンドで完全修飾名を使用します。詳細については、 オブジェクト名の解決 をご参照ください。

行アクセスポリシーを作成できません(オブジェクトが存在します)

SQL コンパイルエラー: オブジェクト「<名前>」は既に存在します。

スキーマ内の行アクセスポリシーは指定された名前ですでに存在するため、別の name 値で行アクセスポリシーを再作成します。

行アクセスポリシーを作成できません(スキーマ所有権)。

SQL アクセス制御エラー: スキーマ「S1」を操作するには権限が不十分です

DDL コマンド、操作、および権限の概要 (このトピック内)で、行アクセスポリシーを作成するための権限を確認します。

行アクセスポリシーを作成できません(スキーマの使用法)。

SQL コンパイルエラー: スキーマ「<スキーマ名>」が存在しないか、許可されていません。

DDL コマンド、操作、および権限の概要 (このトピック内)で、指定されたスキーマが存在し、行アクセスポリシーを作成するための権限があることを確認します。

行アクセスポリシーを記述できません(使用法のみ)。

SQL コンパイルエラー: 行アクセスポリシー「RLS_AUTHZ_DB.S_B.P1」が存在しないか、許可されていません。

行アクセスポリシーが存在する親データベースとスキーマに対して USAGE 権限を持っているだけでは、行アクセスポリシーに対する DESCRIBE 操作を実行するには不十分です。行アクセスポリシーが存在し、 DDL コマンド、操作、および権限の概要 (このトピック内)で行アクセスポリシーを説明するための権限があることを確認します。

行アクセスポリシーをドロップできません。(メンテナンス)。

SQL コンパイルエラー: 行アクセスポリシー「RLS_AUTHZ_DB.S_B.P1」が存在しないか、許可されていません。

指定された行アクセスポリシーが存在し、 DDL コマンド、操作、および権限の概要 (このトピック内)で行アクセスポリシーをドロップするための権限があることを確認します。

行アクセスポリシーで UNDROP を実行できません。(メンテナンス)

サポート対象外機能「UNDROP は、タイプ ROW_ACCESS_POLICY のオブジェクトでサポートされていません」。

行アクセスポリシーを元に戻すには、 CREATE ROW ACCESS POLICY コマンドを実行してから、 ALTER TABLE または ALTER VIEW に示すように、 ALTER TABLE または ALTER VIEW コマンドを使用して行アクセスポリシーをデータベースオブジェクトに追加します。

行アクセスポリシーを更新できません(名前/操作)。

SQL コンパイルエラー: 見つかったオブジェクトはタイプ「ROW_ACCESS_POLICY」であり、指定されたタイプ「MASKING_POLICY」ではありません

クエリを再確認して、オブジェクトの名前とオブジェクトに対する目的の操作を確認します。 . . たとえば、Snowflakeは ALTER ROW ACCESS POLICY <名前>; をサポートしていません。 . . 代わりに、 CREATE OR REPLACE ROW ACCESS POLICY コマンドを使用して行アクセスポリシーを更新します。行アクセスポリシー操作の詳細については、 DDLコマンド、操作、および権限の概要 (このトピック内)をご参照ください。

Snowflakeの機能またはサービス(サポートされていない機能)で行アクセスポリシーを使用することはできません。

サポート対象外機能「CREATE ON OBJECTS ENFORCED BY ROW ACCESS POLICY」。

一部のSnowflakeの機能とサービスでは、行アクセスポリシーをサポートしていません。詳細については、このトピック内の 制限事項 および Snowflakeオブジェクトおよび機能で行アクセスポリシーを使用する のセクションをご参照ください。

行アクセスポリシーを更新できません(サポートされていないトークン)。

サポート対象外機能「TOK_ROW_ACCESS_POLICY」。

TOK はトークンを参照します。これは、クエリがサポートされていないか、不正確な場合に返される可能性があります。 Snowflakeの SQL コンパイラは、指定されたクエリの処理方法を理解していません。 . 例: alter row access policy p1_test set comment = 'test policy 1';。この例では、 ALTER コマンドをポリシーオブジェクトで直接使用することはできません。 DDL コマンド、操作、および権限の概要 (このトピック内)に示すように、代わりに ALTER TABLE または ALTER VIEW コマンドを使用します。

次のトピック: