Hologres:スキーマレベルの簡易権限モデルの使用

前提条件

開始する前に、以下を確認してください。

• Hologres インスタンスのスーパーユーザー権限

• インスタンスに接続済みの開発ツール (例: HoloWeb または psql)

データベースでのSLPMの有効化

1. SLPM 拡張機能をインストールします。これはデータベースごとに 1 回実行します。

   create extension slpm;

2. SLPM を有効化します。このコマンドを実行する際は、データベース上で SQL ステートメントが実行されていないことを確認してください。

   call slpm_enable ();

3. (任意) 標準 PostgreSQL 権限モデルからの移行。データベースに既に標準 PostgreSQL モデルで管理されているテーブル、ビュー、または外部テーブルが存在する場合は、次のコマンドを使用して既存のオブジェクトの所有権を SLPM に移行します。

   移行前に、どの権限モデルがアクティブかを確認するには：

   1. Hologres コンソールにログインします。左側のナビゲーションペインで、[HoloWeb へ移動]をクリックします。

   2. [セキュリティセンター] をクリックします。[DB 承認] ページで、現在の権限モデルを確認します。

   slpm_migrate は、1 回の実行につき最大 64 ユーザーを処理します (調整可能)。データベースのユーザー数がこれを超える場合は、すべての権限が移行されるまで関数を複数回実行してください。パラメーターの詳細については、「slpm_migrate」をご参照ください。

   -- 既存のオブジェクトの所有権を、SLPMで管理するためにdeveloperグループに移管します。
   call slpm_migrate ();

ステップ1：ユーザーの作成

ユーザーがインスタンスに既に存在する場合は、このステップをスキップしてください。

-- ユーザーを作成します。
call slpm_create_user('<ACCOUNT>');

-- ユーザーを作成し、一度にグループに追加します。
call slpm_create_user('<ACCOUNT>', '{dbname}.[admin|{schemaname}.developer|{schemaname}.writer|{schemaname}.viewer]');

<ACCOUNT> を次のいずれかの形式に置き換えます。

RAM ユーザー UID を使用するには、p4_ プレフィックスを追加します。UID は、RAM コンソールの Users ページから取得します。アカウント形式の詳細については、「アカウントシステム」をご参照ください。

ステップ2：ユーザーをグループに追加

call slpm_grant('{dbname}.[admin|{schemaname}.developer|{schemaname}.writer|{schemaname}.viewer]', '<ACCOUNT>');

作成時に既にユーザーをグループに追加している場合は、このステップをスキップしてください。

例：

次の例では、Alibaba Cloud アカウントを mydb の admin グループに追加します。

call slpm_grant('mydb.admin', '197006222995xxx');
call slpm_grant('mydb.admin', 'ALIYUN$xxx');

次の例では、mydb の public スキーマの developer グループにユーザーを追加します。

call slpm_grant('mydb.public.developer', '197006222995xxx');
call slpm_grant('mydb.public.developer', 'RAM$mainaccount:subuser');

次の例では、MYDB (大文字と小文字を区別するデータベース名) の lisa スキーマの viewer グループにユーザーを追加します。

call slpm_grant('"MYDB.lisa.viewer"', '197006222995xxx');
call slpm_grant('mydb.lisa.viewer', '"xxx@aliyun.com"');

ステップ1：モデルの無効化

SLPM を無効化できるのはスーパーユーザーのみです。

call slpm_disable ();

無効化後：

• 4 つのユーザーグループ ({db}.admin、{db}.{schemaname}.developer、{db}.{schemaname}.writer、{db}.{schemaname}.viewer) は、既存のオブジェクトに対する権限を保持します。この権限は新しいオブジェクトには適用されません。

• PUBLIC には、public スキーマに対する USAGE と CREATE、データベースに対する CONNECT と TEMPORARY、関数とプロシージャに対する EXECUTE、言語とデータ型 (ドメインを含む) に対する USAGE が付与されます。

• PUBLIC には、テーブル、ビュー、マテリアライズドビュー、テーブル列、シーケンス、外部データラッパー、外部サーバー、または非 public スキーマに対する権限は付与されません。これらの権限を個別に付与するには、スーパーユーザーに依頼してください。

ステップ2：ユーザーグループのクリーンアップ (任意)

SLPM が無効化されても、ユーザーグループは自動的には削除されません。削除するには、slpm_cleanup を呼び出します。

slpm_cleanup を呼び出す前に、データベース上で SQL ステートメントが実行されていないことを確認してください。slpm_cleanup は、オブジェクトの所有権を 64 個単位のバッチで移管します (調整可能)。必要に応じて複数回実行してください。ただし、5 回以上の実行は避けてください。詳細については、「slpm_cleanup」をご参照ください。

シナリオ1：ユーザーグループを削除するが、データベースは保持する。

スーパーユーザーとして、対象データベースで次のコマンドを実行します。

call slpm_cleanup('<DBNAME>');

シナリオ2：データベースが削除された後にユーザーグループを削除する。

スーパーユーザーとして、別のデータベース (postgres など) で次のコマンドを実行します。

call slpm_cleanup('mydb');

この機能を使用する場合

一般的なデータウェアハウスのパターンは、データを階層化されたスキーマ (例：オペレーショナルデータストア (ODS)、DWD、データウェアハウスサービス (DWS)、ADS) に編成し、複数の内部レイヤーのテーブルを結合する外部レイヤーにサマリービューを作成することです。

ads スキーマのビューが ods と dwd のテーブルを結合する次の例を考えてみます。

ビューの DDL：

CREATE VIEW ads.customer_total_order_price_view AS
SELECT
    c_name,
    sum(o_totalprice)
FROM
    ods.orders AS o
INNER JOIN dwd.customer AS c
ON o.o_custkey = c.c_custkey
GROUP BY
    1;

権限要件

上記の例で、ads.customer_total_order_price_view を ads_dev_user として作成するには：

• ads_dev_user に ads に対する developer 権限を付与します。

• ads_dev_user に ods と dwd に対する viewer 権限を付与します。

ads_view_user がビューをクエリできるようにするには、ads_view_user に ads に対する viewer 権限を付与します。

簡易権限モデル (SPM) から SLPM に切り替えた後、既存のクロススキーマビューはアクセス不可となり、これらのビューへのクエリは permission denied for table エラーで失敗します。スーパーユーザーとして次のコマンドを実行してクロススキーマビュー機能を有効化し、既存のクロススキーマビューを再作成します。

call slpm_enable_multi_schema_view();

-- クロススキーマビューを再作成します
CREATE OR REPLACE VIEW schema_b.cross_schema_view AS
SELECT a.id, a.name, b.value
FROM schema_a.table_a a
JOIN schema_b.table_b b ON a.id = b.id;

ビューを再作成せずに機能を有効化しただけでは、権限エラーは解決されません。

クロススキーマビュー機能の有効化

スーパーユーザーとして次のコマンドを実行します。

call slpm_enable_multi_schema_view();

ビューの所有権の移管

機能が有効化された後、ビューを作成したユーザーがその所有者になります。所有者のみが変更または削除できます。所有権を移管するには (例えば、データベースからユーザーを削除する前に)、次のコマンドを実行します。新しい所有者は、ビューのスキーマに対する developer 権限と、すべてのソーススキーマに対する viewer 以上の権限が必要です。

-- 構文
call slpm_alter_view_owner('<VIEW_NAME>', '<ACCOUNT>');

-- 例：ads.customer_total_order_price_viewの所有権をp4_xxxxxに移管します。
call slpm_alter_view_owner('ads.customer_total_order_price_view', 'p4_xxxxx');

クロススキーマビュー機能の無効化

-- クロススキーマビューのサポートを無効化します。
call slpm_disable_multi_schema_view();
-- すべてのビューの所有権を各ビューのスキーマのdeveloperグループに戻します。
call slpm_migrate();

これらのコマンドを実行した後、既存の非クロススキーマビューは引き続きクエリでき、SLPM は通常通り動作します。クロススキーマビューはクエリできなくなります。