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

背景情報

MaxComputeテーブルには大量のデータが含まれています。 データ共有シナリオでは、データ管理者は、特定のユーザーがアクセスする権限を持つ行のみにアクセスすることを求めます。 特定の行へのユーザーアクセスを制限するには、管理者はビューまたは抽出、変換、読み込み (ETL) タスクを作成して、ユーザーごとにデータをフィルター処理し、承認前にデータを別のテーブルに転送する必要があります。

行レベルのアクセス制御機能を使用すると、管理者は、データの移行とコピー、ビューの作成と保守を必要とせずに、特定のテーブルデータへのアクセスをユーザーに許可できます。

行レベルのアクセス制御機能は、次のシナリオに適しています。

• SQLクエリ

• Tunnelコマンドによるテーブルデータのダウンロード

• SparkやFlinkなどの外部エンジンを使用したテーブルデータの読み取り

行レベルのアクセス制御文を次の表に示します。

制限事項

• 行レベルのアクセス制御機能には、次の制限があります。

  • 行レベルのアクセスポリシーを設定できるのは、管理者 (管理者ロールおよびテーブル所有者) のみです。

  • トランザクションテーブル、ビュー、およびマテリアライズドビューに対して行レベルのアクセスポリシーを構成することはできません。 行レベルのアクセスポリシーが構成されているテーブルのマテリアライズドビューを作成したり、マテリアライズドビューのベーステーブルに行レベルのアクセスポリシーを追加したりすることはできません。 ただし、行レベルのアクセスポリシーが設定されているテーブルに基づいてビューを作成できます。 ビューのクエリ結果は、ベーステーブルに設定された行レベルのアクセスポリシーと、ビューの所有者によって定義されたビュールールによって決定されます。

  • 行レベルのアクセスポリシーが設定されているテーブルに対して、スキーマの進化操作を実行することはできません。

  • 行レベルのアクセスポリシーが設定されているテーブルを、ユーザー定義関数 (UDF) のリソースとして追加することはできません。 UDFのリソースとして追加されたテーブルに対して、行レベルのアクセスポリシーを構成することはできません。 これらの操作を実行すると、すぐにエラーは報告されません。 ただし、関連するUDFが実行されると、エラーが報告されます。

  • 行レベルのアクセスポリシーが設定されているテーブルのフィールドにマスキングルールを追加することはできません。

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

• 行レベルのアクセスポリシーが設定されているテーブルへのパッケージベースのクロスプロジェクトアクセスには、次の制限があります。

  • 現在のプロジェクトに追加されていないユーザーには、行レベルのアクセスポリシーをアタッチできます。 ユーザーは、Alibaba Cloudアカウントまたは現在のテナントのRAMユーザーです。

  • 行レベルのアクセスポリシーが別のプロジェクトで構成されているテーブルを使用すると、ユーザーポリシーまたは既定のポリシーのみが満たされ、ポリシーに基づいてデータがフィルタリングされます。

  • パッケージに行レベルのアクセスポリシーが含まれているテーブルに、行レベルのアクセスポリシーを追加することはできません。

注意事項

• filter_exprで使用される演算子または関数の実行は、フラグパラメータの影響を受ける場合があります。 システムは、クエリ中に使用されたパラメーター設定が、ポリシー作成中に構成されたパラメーター設定と一致しているかどうかを確認します。 矛盾している場合は、次のエラーメッセージが表示されます。

  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 (Grand Unified Configuration) パラメーターを設定して、行レベルのアクセス制御機能を有効にする必要があります。

  説明

  行レベルのアクセス制御機能は、将来、デフォルトでセッションレベルで有効になります。 ドキュメントの発表または指示に注意してください。

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

• SQL文を実行して、行レベルのアクセス制御が有効になっているテーブルのデータを照会する場合、行レベルのアクセス制御ではパーティションプルーニングがサポートされていないため、従量課金方式で課金される入力データの量は、データフィルタリングによって削減されません。 行レベルのアクセスポリシーがアタッチされているユーザーは、SQL式で完全なテーブルクエリを指定した場合でも、フィルタリングされた結果を取得できます。 ソーステーブル内のスキャンされたデータの量は、ユーザが結果に基づいて推定するデータの量よりも大きい可能性がある。 コストを抑えるためには、スキャンするデータ量を減らす必要があります。

• さまざまなユーザー固有のフィルタリングルールを使用して複数のビューまたはテーブルを作成し、それらを共有する方法は、行レベルのアクセス制御を実現し、フィルタリングされたデータに対して計算を実行できるようにし、操作をより便利で直感的にします。 詳細については、「行レベルのアクセス制御の実行」をご参照ください。 ユーザーごとに共有オブジェクトを作成する方法と比較して、行レベルのアクセス制御により、元のテーブルに基づくクエリ実行プランが複雑になります。 しかしながら、各ユーザに対して個別に共有オブジェクトを作成する必要性を排除し、共有オブジェクトの冗長記憶を回避する。 また、多数のユーザーのルールを定義するのにより適しており、ニーズに応じて柔軟に使用できます。

構文

CREATE/REPLACE、DROP、DESC、およびLISTステートメントを実行して、行レベルのアクセスポリシーを作成 (または変更) 、削除、または表示できます。

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

サンプルコード

policy_testという名前のテーブルを作成し、テーブルにデータを挿入します。 サンプル文:

-- Create a table.
CREATE TABLE policy_test(a bigint, b string);

-- Insert data into the table.
INSERT overwrite TABLE policy_test VALUES(1L, "1"), (2L, "2"), (3L, "3"), (4L, "4");

-- Check the inserted data.
SELECT * FROM policy_test;
-- Returned result:
+------------+---+
| a          | b |
+------------+---+
| 1          | 1 |
| 2          | 2 |
| 3          | 3 |
| 4          | 4 |
+------------+---+

例

次の例は、既定のユーザーに行レベルのアクセス許可を付与する方法を示しています。 承認の前に、サンプルデータを準備する必要があります。

• 例1: 行レベルのアクセスポリシーをpolicy_testテーブルに追加して、デフォルトユーザーがテーブルのa=2L行のデータにアクセスできるようにします。

  1. 行レベルのアクセスポリシーpolicy01を作成します。

     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;

     返される結果 :

     -- The following result is returned. The value of Restrictive is false, which is the default value.
     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;

     返される結果 :

     -- The following result is returned. The policy takes effect and only specific records are returned.
     +------------+---+
     | a          | b |
     +------------+---+
     | 2          | 2 |
     +------------+---+

• 例2: 属性がPERMISSIVEである2つの行レベルのアクセスポリシーをテーブルに追加して、デフォルトユーザーがpolicy_testテーブルのa=2Lおよびa=3L行のデータにアクセスできるようにします。

  1. 行レベルのアクセスポリシーpolicy02を作成します。

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

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

     LIST row access policy ON policy_test;

     返される結果 :

     -- The following result is returned:
     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;

     返される結果 :

     -- Two policies policy01 and policy02 take effect at the same time. The attributes of both policies are PERMISSIVE. Therefore, two records are returned.
     +------------+---+
     | a          | b |
     +------------+---+
     | 2          | 2 |
     | 3          | 3 |
     +------------+---+

• 例3: 属性がPERMISSIVEである2つの行レベルのアクセスポリシーと属性がRESTRICTIVEである1つの行レベルのアクセスポリシーをテーブルに追加して、デフォルトユーザーがpolicy_testテーブルの (a=2L | | a=3L )&& a<3L条件を満たすデータにアクセスできるようにします。

  1. 行レベルのアクセスポリシーpolicy03を作成し、ポリシーの属性を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;

     返される結果 :

     -- The following result is returned. The value of Restrictive is 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;

     返される結果 :

     -- The following result is returned. In this example, policy01, policy02, and policy03 take effect at the same time. 
     -- The attributes of policy01 and policy02 are PERMISSIVE. Therefore, the default user can access the table when one of the two policies is met. 
     -- The attribute of policy03 is RESTRICTIVE. Therefore, the default user can access the table only when this policy is met. 
     +------------+---+
     | a          | b |
     +------------+---+
     | 2          | 2 |
     +------------+---+

• 例4: 属性がPERMISSIVEである行レベルのアクセスポリシーと、属性がRESTRICTIVEである行レベルのアクセスポリシーをテーブルに追加します。 デフォルトのユーザーは、2つのポリシーが満たされている場合にのみ、テーブルのデータにアクセスできます。

  1. 行レベルのアクセスポリシーpolicy01を削除します。

     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テーブルのデータを照会して、承認結果を確認します。

     -- Check the inserted data.
     SELECT * FROM policy_test;

     返される結果 :

     -- The returned result is empty because policy02 and policy03 take effect at the same time. 
     +------------+------------+
     | a          | b          | 
     +------------+------------+
     +------------+------------+

付録

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