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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 行アクセスポリシー DDL

• 行アクセスポリシーを使用する

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

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

代表的な例として、情報技術管理者（例: it_admin カスタムロール）は、内部システムを使用するための追加の権限を従業員に付与する前に、従業員ID番号（つまり、 empl_id）のクエリが必要になる場合があります。したがって、行アクセスポリシーは、 CURRENT_ROLE が it_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 式を使用するポリシーは、マッピング（つまり、ルックアップ）テーブルにアクセスするポリシーよりも通常パフォーマンスが向上します。テーブルルックアップの数を最小限に抑えると、パフォーマンスが向上します。

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

• メモ化可能な関数 （スカラー SQL UDF 概要内）。

• ポリシーでのメモ化可能な関数の使用 （行アクセスポリシーの使用トピック内）。

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

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

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

属性によるクラスター:

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

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

検索最適化サービス:

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

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

利点¶

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

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

使いやすさ:

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

変更管理:

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

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

データ管理と SoD:

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

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

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

制限事項¶

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

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

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

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

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

考慮事項¶

• 他の行アクセスポリシーまたはマスキングポリシーによって保護されているテーブルに行アクセスポリシーを添付すると、エラーの発生する可能性があります。詳細については、 ALTER TABLE、 ALTER 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 のセットアップスクリプトを作成するときは注意してください。詳細については、 バージョンスキーマの考慮事項 をご参照ください。

• マスキングまたは行アクセスポリシーの本文で CURRENT_DATABASE または CURRENT_SCHEMA 関数を指定した場合、この関数は、セッションで使用されているデータベースまたはスキーマではなく、保護されたテーブルを含むデータベースまたはスキーマを返します。

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

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 関数を呼び出すようにポリシー条件を記述することを推奨します。例については、次をご参照ください。

• 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は、ベーステーブルとビューでの行アクセスポリシーの設定をサポートしています。ベーステーブルまたはビューポリシーは、ビューの所有者（つまり、 INVOKER_ROLE）またはクエリ演算子のロール（つまり、 CURRENT_ROLE）に適用できます。

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

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

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

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

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

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

動的テーブル¶

行アクセスポリシー、マスキングポリシー、タグを持つ動的テーブルを作成できます。詳細については、次をご参照ください。

• CREATE DYNAMIC TABLE

• 増分リフレッシュの追加制限

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 という名前のテーブルを保護する行アクセスポリシーです。ここで、 t1 は share1 という名前のプロバイダーからの共有にあります。

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

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

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

• 外部関数。

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

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

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

Snowflake Native App Framework¶

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

• ポリシーを含むデータコンテンツの共有制限.

• プロキシビューのポリシーを定義する.

• ブロックされたコンテキスト関数.

Streamlit in Snowflake¶

Streamlit in Snowflake アプリで使用される行アクセスポリシーには、行アクセスポリシーの本文にコンテキスト関数を使用する制限事項があります。詳細については、次をご参照ください。

• Streamlit in Snowflake のコンテキスト関数と行アクセス・ポリシー

• 例: CURRENT_USER を使用して行アクセスポリシーのテーブルのデータにアクセスします。

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

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

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

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

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

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

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

行アクセスポリシー DDL¶

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

• CREATE ROW ACCESS POLICY

• ALTER ROW ACCESS POLICY

• DROP ROW ACCESS POLICY

• SHOW ROW ACCESS POLICIES

• DESCRIBE ROW ACCESS POLICY

• ALTER TABLE、 ALTER EXTERNAL TABLE、および ALTER VIEW （テーブルまたはビューにポリシーを追加/ドロップするため）

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

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

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

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

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

共有 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のガバナンスエリアへのアクセス¶

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

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

タグ付きオブジェクト¶

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

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

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

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

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