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

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

このトピックの内容:

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

Snowflakeは、行アクセスポリシーを使用してクエリ結果で返す行を決定することにより、行レベルのセキュリティをサポートします。行アクセスポリシーは、1つの特定のロールが行を表示できるようにするために比較的単純な場合もあれば、クエリ結果の行へのアクセスを決定するためにポリシー定義に マッピングテーブル を含めるときのように、より複雑な場合もあります。

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

  • SELECT ステートメント

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

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

The row access policy admin can apply row access policies to tables and views.

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

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

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

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

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

ちなみに

既存の行アクセスポリシーを更新するためにポリシーの現在の定義を確認する必要がある場合は、 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)、ポリシーは左から右へと順番に適用されます。

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

Row access policies with tables and views.

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

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

行アクセスポリシーの簡単なアプリケーションは、ポリシーで属性を指定し、クエリ結果でその属性を表示できるようにするロールを指定することです。このような単純なポリシーの利点は、マッピングテーブルで行アクセスポリシーを使用する場合と比較して、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()
;

このポリシーは、評価する他の条件がなく、 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 句の使用はサポートされていません。

  • 将来の付与 は、行アクセスポリシーでは使用できません。回避策として、行アクセスポリシーを設定するロールに APPLY ROW ACCESS POLICY 権限を付与します。

  • 検索最適化サービス。行アクセスポリシーで保護されているデータベースオブジェクトは、検索最適化サービスでは使用できません。詳細については、 行アクセスポリシーのトラブルシューティング (このトピック内)をご参照ください。

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

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

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

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

考慮事項

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

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

  • IS_ROLE_IN_SESSION は、マッピングテーブルを含む行アクセスポリシーでは使用できません。この関数は、マッピングテーブルを含まない行アクセスポリシーで使用できます。

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

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

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

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

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

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

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

    <ポリシー名 > を行アクセスポリシーの名前(例 mydb.policies.rap1)に置き換えます。

    select *
    from table(
      mydb.information_schema.policy_references(
        policy_name=>'<policy_name>'
      )
    );
    
  • 特定のオブジェクトに割り当てられたポリシーは、

    <名前> をオブジェクトの名前(例: mydb.tables.t1)に、 <ドメイン> をオブジェクトドメイン(例: table)にそれぞれ置き換えます。

    select *
    from table(
      mydb.information_schema.policy_references(
        ref_entity_name => '<name>',
        ref_entity_domain => '<domain>'
      )
    );
    

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

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

ポリシー条件は、ポリシー管理者がポリシーを記述する方法次第で、セッションで直接ユーザーのアクティブなプライマリロールとセカンダリロールを評価したり、マッピングテーブルでアクティブなロールを検索したり、その両方を実行したりできます。

これらのユースケースでは、ポリシー条件を記述して IS_ROLE_IN_SESSION コンテキスト関数を呼び出すことをお勧めします。ポリシーの例については、IS_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;

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

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

列レベルのセキュリティマスキングポリシー

データベースオブジェクトに行アクセスポリシーと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;

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

+--------+--------+--------+-------------------+-----------------------------+--------+-------------+-----------------+--------------------+---------------+
|  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 関数を使用します。

  • 共有ビューと行アクセスポリシーが異なるデータベースに存在する場合は、行アクセスポリシーを含むデータベースに対する REFERENCE_USAGE 権限を共有に付与します。詳細については、 複数のデータベースのデータの共有 をご参照ください。

制限事項
  • 外部関数。

    次のいずれかに該当する場合、Snowflakeはエラーを返します。

    • 共有テーブルまたはビューに割り当てられたポリシーは、外部関数を呼び出すための ALTER ROW ACCESS POLICY ステートメントで更新されます。

    • ポリシーが外部関数を呼び出し、 ALTER TABLE ステートメントを使用してポリシーを共有テーブルに割り当てようとするか、 ALTER VIEW ステートメントを使用してポリシーをビューに割り当てようとします。

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

  • データ共有プロバイダーは、 リーダーアカウント には行アクセスポリシーを作成できません。

行アクセスポリシーの管理

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

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

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

ポリシーアクション

集中型

ハイブリッド型

分散型

ポリシー作成

ガバナンス責任者

ガバナンス責任者

個別チーム

列にポリシーを適用する

ガバナンス責任者

個別チーム

個別チーム

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

ちなみに

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

行アクセスポリシーの監査

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

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

  • ビュー:

    • ポリシーの関連付けについては、 POLICY_REFERENCES ビュー (Account Usage内)をクエリします。このビューは、アカウントに対して行アクセスポリシーが有効化され、使用されている場合にのみ、行アクセスポリシー情報を返すことに注意してください。

    • ROW_ACCESS_POLICIES ビュー (Account Usage内)をクエリして、アカウントで作成されたすべての行アクセスポリシーのリストを取得します。

  • Information Schemaテーブル関数 POLICY_REFERENCES は、次のいずれかに使用できます。

    • オブジェクトで行アクセスポリシーが設定されているすべてのオブジェクト(つまり、テーブル、ビュー)のリストを返します。

    • 指定されたオブジェクト名とオブジェクト型を持つポリシー関連付けのリストを返します。

  • 行アクセスポリシー管理者(つまり、行アクセスポリシー 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 コマンドを使用します。

次のトピック:

最上部に戻る