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

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

このトピックの内容:

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

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

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

  • SELECT ステートメント

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

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

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

現在、行アクセスポリシーは、行の挿入を防止したり、表示されている行の更新や削除の防止したりすることはできません。行アクセスポリシーは、 ALTER TABLE ステートメントを使用してテーブルに追加され、 ALTER VIEW ステートメントを使用してビューに追加されます。

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

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

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

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

クエリの実行時に、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億

アリス、ボブ

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

利点

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

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

使いやすさ

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

変更管理

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

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

データ管理と SoD

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

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

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

制限事項

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

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

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

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

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

  • ストリーム:

    • Snowflakeは、ストリームオブジェクト自体への行アクセスポリシーの添付をサポートしていませんが、ストリームが行アクセスポリシーで保護されているテーブルにアクセスするときに、行アクセスポリシーをテーブルに適用します。

考慮事項

  • 他の行アクセスポリシーまたはマスキングポリシーによって保護されているテーブルに行アクセスポリシーを添付すると、エラーの発生する可能性があります。詳細については、 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機能とともにテーブルとビューにどのような影響を与えるかについて説明します。

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

行アクセスポリシーを持つデータベースオブジェクトのリストを取得するには、次のステートメントを実行します。

select *
from table(
  information_schema.policy_references(
    policy_name=>'<policy_name>'
  )
);

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

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

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

外部テーブル

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

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

ストリーム

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

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

ビュー

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

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

CREATE TABLE ステートメント

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

CREATE TABLE ... 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かそれ以上である必要があります。

    詳細については、 データベース複製とフェールオーバー/フェールバック をご参照ください。

データ共有

Snowflakeを使用すると、データ共有プロバイダーとコンシューマーは、データベースオブジェクトに行アクセスポリシーを追加できます。

データ共有プロバイダーは、行アクセスポリシーでコンテキスト関数(例: INVOKER_SHARE)を使用して、許可されたユーザーの母集団を決定する必要があります。行アクセスポリシーが外部関数を参照している場合は、テーブルまたはビューを共有することはできません。

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

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

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

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

  • ビュー:

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

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

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

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

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

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

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

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

  • データベースオブジェクトの行アクセスポリシーに関連する特定のユーザーが過去にアクセスしたデータを特定するには、Time Travelを行アクセスポリシーAccount Usageおよび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 コンパイルエラー: オブジェクト「<名前>」は既に存在します。

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

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

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 コマンドを使用します。

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

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

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

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

ポリシーアクション

集中型

ハイブリッド型

分散型

ポリシー作成

ガバナンス責任者

ガバナンス責任者

個別チーム

列へのポリシー適用

ガバナンス責任者

個別チーム

個別チーム

ちなみに

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

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

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

注釈

行アクセスポリシーはスキーマレベルのオブジェクトです。

行アクセスポリシー上で動作するには、親データベースとスキーマでの USAGE 権限も必要です。

権限

使用法

CREATE

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

APPLY

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

OWNERSHIP

行アクセスポリシーの所有権を譲渡します。これにより、行アクセスポリシーを包括的に制御できます。行アクセスポリシーのほとんどのプロパティを変更するために必要です。

行アクセスポリシー DDL

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

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

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

操作

必要な権限

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

親データベースに対する USAGE 権限を持つロールと、同じスキーマ内の CREATE ROW ACCESS POLICY 権限を持つスキーマ。

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

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

追加/ドロップ 行アクセスポリシー

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

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

行アクセスポリシーに対する OWNERSHIP 権限を持つロール、または行アクセスポリシーが存在するスキーマに対する OWNERSHIP 権限を持つロール。

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

行アクセスポリシーで OWNERSHIP 権限を持つロール、または行アクセスポリシーで APPLY 権限を持つロール、 または グローバル APPLY ROW ACCESS POLICY 権限を持つロール。

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

スキーマに対する OWNERSHIP 権限を持つロール。

次のトピック: