仮想デー タベース内の任意のリソースパスについて、CREATE , READ , UPDATE , DELETE , EXECUTE , ALTER , LANGUAGE  ( CRUDEAL ) 権限を設定できます。リソースパスは、カラムの完全修飾名のように具体的なものから、トップレベルのモデル(スキーマ)名のように一般的なものまであります。特定のパスに与えられたPermissionは、そのパスと同じ部分名を共有するリソースパスに適用されます。例えば、READの許可をmodelに与えると、READmodel.tablemodel.table.columnなどに与えられます。特定のアクションの許可または拒否は、最も具体的なリソースパスから最も具体的でないリソースパスまでのPermissionを検索することによって決定されます。最初に見つかったPermission が使用されます。したがって、高レベルのリソースパス名で非常に一般的なPermission を設定し、より具体的なリソースパスで必要に応じて上書きすることが可能です。

権限の付与は、ロールがアクセスを必要とするリソースに対してのみ必要です。Permission は、ユーザークエリののカラム、テーブル、プロシージャにのみ適用され、ビューやプロシージャの定義を通してトランジェスティブにアクセスされるすべてのリソースには適用されません。したがって、同じリソースにアクセスするモデル間で権限付与が一貫して適用されるようにすることが重要です。

ロールの権限が重複している場合、正の権限が選択されます。role_1  role_2を持ち、role_1R view1  role_2view1の負のパーミッション( '' )を持っている場合、ユーザはview1を見てアクセスすることができます。

Permission Overlap

OLD_PERMISSIONS_BEHAVIORオプションを設定することで、現在と以前の動作を選択することができます。デフォルト値: TRUE(古い動作)。

古い動作

ロールの権限が重複している場合、正の権限が選択されます。role_1  role_2を持ち、role_1R view1  role_2view1の負のパーミッション( '' )を持っている場合、ユーザはview1を見てアクセスすることができます。

現在の動作

権限が重複している場合は、より具体的な権限が選択されます。ユーザーがrole_1 と role_2を持ち、role_1がすべてのリソースに対してRの Permission を持ち、role_2がデータソース ds_1に対して負の Permission ( '' ) を持っている場合、ユーザーはds_1を見ることもアクセスすることもできません。

ユーザのロールが同じリソースに対するPermissionを持っている場合、最初に作成されたロール(通常認証の場合)、またはアルファベット順の最初のロール(LDAP認証の場合)のPermissionが選択されます。ユーザーがrole_1role_2を持ち、role_1Rのパーミッションを持ち、view1role_2が先に作成され、view1 に対して負のパーミッション ( '' ) を持っている場合、これは以下のように動作します:

  • 通常の認証: role_2が先に作成されているため、ユーザーはview1 ,を見ることもアクセスすることもできません;
  • LDAP 認証: role_1がアルファベット順で最初に来るため、User はview1を見てアクセスできます。

SYSおよびpg_catalogスキーマには Permission は適用されません。これらのメタデータ報告スキーマは、ユーザーに関係なく常にアクセス可能です。ただし、SYSADMINスキーマは、必要に応じてPermission が必要な場合があります。

Permission Resource Type

Permission リソースタイプは2つの方法で定義できます:

  1. リソース名に リソースタイプの接頭辞を追加する、または
  2. resourceTypeパラメータを設定する。この場合、リソースタイプの接頭辞がPermission リ ソ ース名に付加され、この接頭辞を付けてSYSADMIN.PermissionsにPermission が保存されます。

サポートされるリソースタイプは以下のとおりです:

  • table
  • view
  • procedure
  • function
  • job

リソースタイプを使用して、仮想スキーマまたはデータソース内のすべてのプロシージャ、関数、ビュー、またはテーブルにパーミッションを設定することができます。

指定のリソースタイプを持つ Permission と持たない Permission は、SYSADMIN.Permissionsに別々に保存されます。これは、1つのオブジェクトが2つのPermission を持つことができることを意味します:1つは指定されたリソースタイプを持つもの、もう1つは持たないものです。この場合は:

  • リソースタイプを指定したPermission が優先され、適用されます;
  • リソースタイプを指定しないPermission は、特定のリソースタイプのPermission が削除された場合にのみ適用されます。

Examples

1. リソース型接頭辞を使用してビューschema.view_1 の権限を設定します:

CALL "SYSADMIN.setPermissions"("role_name" => 'role_1', "resourceName" => 'view:schema.view_1', "permissions" => 'R');;

2. resourceTypeパラメータを使用してschema.proc_1プロシージャのパーミッションを設定します。パーミッションはSYSADMIN.Permissionsにリソース名'procedure:schema.proc_1' で保存されます:

CALL "SYSADMIN.setPermissions"("role_name" => 'role_1', "resourceName" => 'schema.proc_1', "permissions" => 'RE', "resourceType" => 'procedure');;

3. schema_1のすべてのプロシージャに対してパーミッションを設定します :

CALL "SYSADMIN.setPermissions"("role_name" => 'role_1', "resourceName" => 'procedure:schema_1', "permissions" => 'RE');;

4. role_1には、proc_1に対する、リソースタイプの接頭辞がある場合とない場合の2つのパーミッションがあります。この場合、接頭辞付きのREパーミッションが適用されます:

CALL "SYSADMIN.setPermissions"("role_name" => 'role_1', "resourceName" => 'procedure:schema_1.proc_1', "permissions" => 'RE');;
CALL "SYSADMIN.setPermissions"("role_name" => 'role_1', "resourceName" => 'schema_1.proc_1', "permissions" => 'RDEA');;

Wildcards

パーミッションは*ワイルドカードを使って設定できます。リソースタイプと一緒に使用すると、すべてのプロシージャ、ファンクション、ビュー、またはテーブルに対してパーミッションを設定することができます。

Examples

1. すべてのオブジェクトの権限を設定します:

CALL "SYSADMIN.setPermissions"("role_name" => 'role_1', "resourceName" => '*', "permissions" => 'R');;

2. すべてのファンクションの権限を設定します:

CALL "SYSADMIN.setPermissions"("role_name" => 'role_1', "resourceName" => 'function:*', "permissions" => 'RE');;

Assigning and Removing Permissions

オブジェクトのパーミッションは、以下のいずれかの方法で割り当てたり削除したりできます:

  • 管理者ユーザー;
  • オブジェクト(プロシージャまたはジョブ)の所有者;
  • オブジェクトに対して"A"(Alter)権限を持つユーザー。このユーザは、このオブジェクトに対して自分が保持しているパーミッションのみを割り当てたり削除したりできます。

Permissions resource type, wildcards and rules of assigning and removing permissions available since v4.9

Access Rights

異なるアクションに対して、ユーザーアカウントは異なるアクセス権を必要とします。以下に、これらの行為に必要な権限と、その権限が適用されるべきものを列挙します。

1. SELECTステートメントを処理するか、ストアドプロシージャを実行します:

Right

Object

READ

Tables being accessed or the procedure being called

READ

Every column referenced

2. INSERTステートメントの処理:

Right

Object

CREATE

Table being inserted into

CREATE

Every column being inserted in that table

3. UPDATEステートメントの処理:

Right

Object

UPDATE

Table being updated

UPDATE

Every column being updated in that table

READ

Every column referenced in the criteria

4. DELETEステートメントの処理:

Right

Object

DELETE

Table being deleted

READ

Every column referenced in the criteria

5. EXEC/CALLステートメントの処理:

Right

Object

EXECUTE or READ

Procedure being executed

6. 任意の関数を処理します:

Right

Object

EXECUTE or READ

Function being called

7. ALTERまたはCREATE TRIGGERステートメントを処理します:

Right

Object

ALTER

View or procedure that is affected

INSTEAD OFトリガー(更新プロシージャ)はまだ完全なスキーマオブジェクトとはみなされず、代わりにビュー属性として扱われることに注意してください。

8. OBJECTTABLE関数を処理します:

Right

Object

LANGUAGE

Allowed language name

さらに、一時テーブルに対する文の処理には、該当するロールにallowCreateTempTables属性が必要です。

Owner and Runner (Executor) of Jobs and Procedures

ジョブとプロシージャはownerrunner属性を持ちます。スケジュールは owner属性を持っています。これらの属性は、ジョブやプロシージャのアクセス権を定義します。

Owner

デフォルトでは、ジョブまたはプロシージャの作成者はその所有者です。所有者は、存在しないユーザー名であっても、別のユーザー名に設定することができます。プロシージャでは、プロシージャを作成または変更するときに設定できます。ジョブは所有者のデフォルト値で作成され、所有者はSYSADMIN.changeJobParameters プロシージャで変更できます。 の所有者を変更できるのは、admin-roleのメンバーのみです。 

Runner

デフォルトでは、ランナーは CALLERに設定されます。  プロシージャでは、プロシージャを作成するとき、またはEXECUTE ASを使用してプロシージャを変更するときに設定できます。ジョブはrunAsrunAsのデフォルト値で作成されますが、 SYSADMIN.changeJobParametersのプロシージャで変更することができます。admin-roleの所有者とメンバーのみが runnerを変更できます。

許可された値は、CALLERおよびOWNERです。

CALLERは、ジョブを呼び出したユーザ(ジョブをトリガーしたスケジュールの所有者)またはプロシージャの権限が、ジョブまたはプロシージャに適用されることを意味します。例えば、ジョブやプロシージャがpgとテーブルtable_1 を持つPostgreSQL データソースからのSELECTを含み、ランナーがCALLERの場合、ジョブやプロシージャを呼び出すユーザはREADのPermission を持っていなければなりません。pg.table_1

OWNERは、ジョブやプロシジャの所有者のPermission が適用されることを意味します。例えば、ジョブやプロシジャが という名前のPostgreSQL データソースから を含み、テーブル とランナーが の場合、ジョブを呼び出すユーザ(より具体的には、ジョブをトリガーするスケジュールの所有者)やプロシジャは の権限を持っていないかもしれませんが、ジョブやプロシジャの所有者はこの権限を持っていなければなりません。 pg.table_1pgSELECTtable_1  OWNER READ

 ALTER runner = OWNERのパーミッションを持つジョブやプロシージャを慎重に付与してください。そのようなジョブやプロシージャに対してALTEREXECUTEのパーミッションを持つユーザーは、所有者に代わって、所有者のアクセス権を使用して、それらを変更したり、何かを実行したりすることができます。

Owner and Runner (Executor) of jobs and procedures are available since v4.1

See Also

Permission Management Permissions を設定するための専用のシステムプロシージャについては、こちらをご覧ください。