MaxCompute:行レベルのアクセス制御

背景情報

MaxCompute テーブルには大量のデータが含まれる場合があります。データ共有のシナリオにおいて、データ管理者は特定のユーザーがアクセスを許可されたデータ行のみを参照できるようにする必要があります。従来、行レベルのアクセス制御を行うには、各ユーザー向けに個別のビューを作成するか、ETL タスクを使用してフィルター処理を行い、別のテーブルにデータをコピーする必要がありました。

行レベルのアクセス制御により、このワークフローが簡素化されます。データの移動やコピー、ビューの作成および保守は不要になります。

行レベルのアクセス制御は、以下のシナリオに適用されます。

• SQL クエリ。

• MaxCompute Tunnel を使用したテーブルデータのダウンロード。

• Spark や Flink などの外部エンジンによるテーブルデータの読み取り。

以下の表は、行レベルのアクセス制御に関するコマンドを示しています。

制限事項

• 行レベルのアクセス制御には、以下の制限事項が適用されます。

  • 管理者（Admin ロールを持つユーザーまたはテーブル所有者）のみが Row Access Policy を構成できます。

  • トランザクションテーブル、ビュー、マテリアライズドビューには Row Access Policy を構成できません。Row Access Policy が設定されたテーブルに対してマテリアライズドビューを作成することも、マテリアライズドビューのベーステーブルに対して Row Access Policy を追加することもできません。ただし、Row Access Policy が設定されたテーブルに基づいてビューを作成することは可能です。この場合、ビューからのクエリ結果は、ベーステーブルの Row Access Policy とビュー所有者が定義したルールの両方によって決定されます。

  • Row Access Policy が設定されたテーブルに対してスキーマ進化操作を実行することはできません。

  • Row Access Policy が設定されたテーブルを UDF テーブルリソースとして追加することはできません。また、UDF テーブルリソースであるテーブルに対して Row Access Policy を構成することもできません。構成時にはエラーは報告されませんが、ランタイムでエラーが発生します。

  • Row Access Policy が設定されたテーブルに対してマスキングルールを追加することはできません。

  • 行レベルのアクセス制御は現在、パーティションプルーニングをサポートしていません。ds がパーティションフィールドの場合、filter_expr 内で ds='20220101' のようなフィルター条件を指定しても、データをフィルターするために全表スキャンが必要になる可能性があります。filter_expr の詳細については、「filter_expr の説明」をご参照ください。

• パッケージを使用して Row Access Policy が設定されたテーブルをプロジェクト間で共有する場合、以下の制限事項が適用されます。

  • 現在のテナントの Alibaba Cloud アカウントまたは RAM ユーザーなど、プロジェクト外のユーザーに対して行レベルの権限を構成できます。

  • Row Access Policy が設定されたテーブルをプロジェクト間で使用する場合、ユーザー向けポリシーまたは DEFAULT ポリシーのみが適用されます。

  • Row Access Policy が設定されたパッケージ内のテーブルに対して、別の Row Access Policy を追加することはできません。

注意事項

• filter_expr 内で使用される演算子または関数の動作は、さまざまなフラグパラメーターの影響を受ける場合があります。MaxCompute は、クエリ実行時のパラメーター設定がポリシー作成時と一致しているかどうかをチェックします。一致しない場合は、以下のエラーが発生します。

  FAILED: ODPS-0130071:[0,0] Semantic analysis exception - physical plan generation failed: java.lang.IllegalArgumentException: Row access policy flag mismatch for: xxx

• CREATE、DROP、DESC、LIST などの行レベルのアクセス制御コマンドを実行する前に、セッションレベルで以下の GUC パラメーターを設定して、行レベルのアクセス制御を有効にする必要があります。

  説明

  この機能は今後のリリースでセッションレベルでデフォルトで有効になる予定です。詳細については、リリースアナウンスをご参照ください。

  SET odps.sql.row.policy.enabled=true;

• 行レベルのアクセス制御が有効なテーブルをクエリする場合、行レベルのアクセス制御がパーティションプルーニングをサポートしていないため、フィルター処理によって従量課金の入力データ量は削減されません。Row Access Policy を持つユーザーは、全表をクエリしてもフィルター済みの結果セットを受け取る可能性があります。ソーステーブルからスキャンされるデータ量は、結果サイズに基づく想定よりも大きくなる場合があります。コストに十分ご注意ください。

• 異なるユーザー向けにフィルタールールを含む複数のビューまたはテーブルを作成・共有することで、行レベルのアクセス制御を実装することも可能です。この方法では、すでにフィルター済みのデータに対して計算を実行でき、よりシンプルで直感的です。詳細については、「行レベルのアクセス制御」をご参照ください。ユーザー向けの共有オブジェクトを作成する方法と比較して、行レベルのアクセス制御は元のテーブルのクエリ実行計画をより複雑にします。一方で、個別の共有オブジェクトを作成する必要がなく、冗長なストレージを回避でき、多数のユーザー向けにルールを定義するのに適しています。ニーズに最も合う方法を選択してください。

構文

CREATE/REPLACE、DROP、DESC、LIST コマンドを使用して、Row Access Policy の作成（または変更）、削除、または表示を行います。

DESC ROW ACCESS POLICY <policy_name> ON <table_name>;

サンプルデータ

policy_test という名前のテーブルを作成し、データを挿入します。SQL コマンドは以下のとおりです。

-- テーブルを作成します。
CREATE TABLE policy_test(a bigint, b string);

-- テーブルにデータを挿入します。
INSERT overwrite TABLE policy_test VALUES(1L, "1"), (2L, "2"), (3L, "3"), (4L, "4");

-- 挿入されたデータを確認します。
SELECT * FROM policy_test;
-- 以下の結果が返されます：
+------------+---+
| a          | b |
+------------+---+
| 1          | 1 |
| 2          | 2 |
| 3          | 3 |
| 4          | 4 |
+------------+---+

例

このセクションでは、デフォルトユーザー向けに行レベルの権限を使用する方法の例を示します。開始する前に、サンプルデータ を準備する必要があります。

• 例 1：policy_test テーブルに対して行レベルの権限を付与し、デフォルトユーザーが a=2L のデータにアクセスできるようにします。

  1. policy01 という名前の Row Access Policy を作成します。

     CREATE row access policy policy01 ON policy_test TO default filter using (a = 2L);

  2. policy_test テーブル上の policy01 の詳細を表示します。

     DESC row access policy policy01 on policy_test;

     以下の結果が返されます。

     -- Restrictive プロパティはデフォルト値 false に設定されています。
     Authorization Type: Row Access Policy
     Name: policy01
     Objects: acs:odps:*:projects/clone_table_2/tables/policy_test
     FilterExpr: (a = 2L)
     NormalizedFilterExpr: (policy_test.a = 2L)
     Restrictive: false
     Settings: 
     
     
     OK

  3. policy_test テーブルをクエリして、権限付与が有効であることを確認します。

     SELECT * FROM policy_test;

     以下の結果が返されます。

     -- ポリシーが有効であり、レコードのサブセットのみが返されます。
     +------------+---+
     | a          | b |
     +------------+---+
     | 2          | 2 |
     +------------+---+

  4. Logview のサマリーに以下の情報が含まれている場合、行レベルのフィルターがトリガーされています。

     WARNING:[1,15]  row access policy is enabled on table xxx.xxx_xxx.policy_test
     resource cost: cpu 0.00 Core * Min, memory 0.00 GB * Min
     inputs:
         xxx.xxx_xxx.policy_test: 4 (510 bytes)
     outputs:
     ----------------------------------------JOB:SQL_0_0_0_job_0----------------------------------------
     Job run time: 1.453
     Job run mode: service job 2.0
     Job run engine: execution engine
     M1:
         bubble: 0
         instance count: 1
         run time: 1.450
         instance time:

• 例 2：テーブルに 2 つの許容的（permissive）な行レベルの権限を追加し、デフォルトユーザーが policy_test テーブルの a=2L または a=3L のデータにアクセスできるようにします。

  1. policy02 という名前の Row Access Policy を作成します。

     CREATE row access policy policy02 ON policy_test TO default filter using (a = 3L);

  2. policy_test テーブル上のすべてのポリシーを一覧表示します。

     LIST row access policy ON policy_test;

     以下の結果が返されます。

     Authorization Type: Row Access Policy
     Name: policy01
     Objects: acs:odps:*:projects/clone_table_2/tables/policy_test
     FilterExpr: (a = 2L)
     NormalizedFilterExpr: (policy_test.a = 2L)
     Restrictive: false
     Settings: 
     Name: policy02
     Objects: acs:odps:*:projects/clone_table_2/tables/policy_test
     FilterExpr: (a = 3L)
     NormalizedFilterExpr: (policy_test.a = 3L)
     Restrictive: false
     Settings: 
     
     
     OK

  3. policy_test テーブルをクエリして、権限付与が有効であることを確認します。

     SELECT * FROM policy_test;

     以下の結果が返されます。

     -- 2 つの PERMISSIVE ポリシー policy01 および policy02 が両方とも有効です。2 件のレコードが返されます。
     +------------+---+
     | a          | b |
     +------------+---+
     | 2          | 2 |
     | 3          | 3 |
     +------------+---+

• 例 3: テーブルに行レベルの権限を許可用 2 つと制限用 1 つ追加すると、デフォルトユーザーは、policy_test テーブル内で (a=2L || a=3L) && a<3L を満たすデータにアクセスできます。

  1. policy03 という名前の Row Access Policy を作成し、その属性を RESTRICTIVE に設定します。

     CREATE row access policy policy03 ON policy_test TO default filter using (a < 3L) as restrictive;

  2. policy_test テーブル上の policy03 の詳細を表示します。

     DESC row access policy policy03 ON policy_test;

     以下の結果が返されます。

     -- Restrictive プロパティは true に設定されています。
     Authorization Type: Row Access Policy
     Name: policy03
     Objects: acs:odps:*:projects/clone_table_2/tables/policy_test
     FilterExpr: (a < 3L)
     NormalizedFilterExpr: (policy_test.a < 3L)
     Restrictive: true
     Settings: 
     
     
     OK

  3. policy_test テーブルをクエリして、権限付与が有効であることを確認します。

     select * from policy_test;

     以下の結果が返されます。

     -- ポリシー policy01、policy02、および policy03 がすべて有効です。
     -- policy01 および policy02 は PERMISSIVE であるため、いずれか 1 つを満たせば十分です。
     -- policy03 は RESTRICTIVE であるため、必ず満たす必要があります。
     +------------+---+
     | a          | b |
     +------------+---+
     | 2          | 2 |
     +------------+---+

• 例 4：テーブルに 1 つの PERMISSIVE ポリシーと 1 つの RESTRICTIVE ポリシーを追加します。デフォルトユーザーは両方の条件を満たす必要があり、テーブルデータにアクセスできます。

  1. policy01 という名前の Row Access Policy を削除します。

     SET odps.sql.row.policy.enabled=true;
     DROP ROW ACCESS POLICY policy01 ON policy_test;

  2. policy_test テーブル上の行レベルの権限を表示します。

     SET odps.sql.row.policy.enabled=true;
     LIST ROW ACCESS POLICY ON policy_test;

     以下の結果が返されます。

     Authorization Type: Row Access Policy
     Name: policy02
     Objects: acs:odps:*:projects/clone_table_2/tables/policy_test
     FilterExpr: (a = 3L)
     NormalizedFilterExpr: (policy_test.a = 3L)
     Restrictive: false
     Settings: 
     Name: policy03
     Objects: acs:odps:*:projects/clone_table_2/tables/policy_test
     FilterExpr: (a < 3L)
     NormalizedFilterExpr: (policy_test.a < 3L)
     Restrictive: true
     Settings: 
     
     
     OK

  3. policy_test テーブルをクエリして、権限付与の結果を確認します。

     -- テーブル内のデータを確認します。
     SELECT * FROM policy_test;

     以下の結果が返されます。

     -- 結果は空です。a=3 および a<3 の条件を同時に満たすことはできないためです。
     +------------+------------+
     | a          | b          | 
     +------------+------------+
     +------------+------------+

付録

setproject odps.sql.create.row.policy.disable=true;