仮想デー タベース内の任意のリソースパスについて、CREATE
, READ
, UPDATE
, DELETE
, EXECUTE
, ALTER
, LANGUAGE
( CRUDEAL
) 権限を設定できます。リソースパスは、カラムの完全修飾名のように具体的なものから、トップレベルのモデル(スキーマ)名のように一般的なものまであります。特定のパスに与えられたPermissionは、そのパスと同じ部分名を共有するリソースパスに適用されます。例えば、READ
の許可をmodel
に与えると、READ
もmodel.table
、model.table.column
などに与えられます。特定のアクションの許可または拒否は、最も具体的なリソースパスから最も具体的でないリソースパスまでのPermissionを検索することによって決定されます。最初に見つかったPermission が使用されます。したがって、高レベルのリソースパス名で非常に一般的なPermission を設定し、より具体的なリソースパスで必要に応じて上書きすることが可能です。
権限の付与は、ロールがアクセスを必要とするリソースに対してのみ必要です。Permission は、ユーザークエリののカラム、テーブル、プロシージャにのみ適用され、ビューやプロシージャの定義を通してトランジェスティブにアクセスされるすべてのリソースには適用されません。したがって、同じリソースにアクセスするモデル間で権限付与が一貫して適用されるようにすることが重要です。
ロールの権限が重複している場合、正の権限が選択されます。role_1
role_2
を持ち、role_1
R
view1
role_2
view1
の負のパーミッション( ''
)を持っている場合、ユーザはview1
を見てアクセスすることができます。
Permission Overlap
OLD_PERMISSIONS_BEHAVIOR
オプションを設定することで、現在と以前の動作を選択することができます。デフォルト値: TRUE
(古い動作)。
古い動作
ロールの権限が重複している場合、正の権限が選択されます。role_1
role_2
を持ち、role_1
R
view1
role_2
view1
の負のパーミッション( ''
)を持っている場合、ユーザはview1
を見てアクセスすることができます。
現在の動作
権限が重複している場合は、より具体的な権限が選択されます。ユーザーがrole_1
と role_2
を持ち、role_1
がすべてのリソースに対してR
の Permission を持ち、role_2
がデータソース ds_1
に対して負の Permission ( ''
) を持っている場合、ユーザーはds_1
を見ることもアクセスすることもできません。
ユーザのロールが同じリソースに対するPermissionを持っている場合、最初に作成されたロール(通常認証の場合)、またはアルファベット順の最初のロール(LDAP認証の場合)のPermissionが選択されます。ユーザーがrole_1
とrole_2
を持ち、role_1
がR
のパーミッションを持ち、view1
とrole_2
が先に作成され、view1 に対して負のパーミッション ( ''
) を持っている場合、これは以下のように動作します:
- 通常の認証:
role_2
が先に作成されているため、ユーザーはview1
,を見ることもアクセスすることもできません; - LDAP 認証:
role_1
がアルファベット順で最初に来るため、User はview1
を見てアクセスできます。
SYS
およびpg_catalog
スキーマには Permission は適用されません。これらのメタデータ報告スキーマは、ユーザーに関係なく常にアクセス可能です。ただし、SYSADMIN
スキーマは、必要に応じてPermission が必要な場合があります。
Permission Resource Type
Permission リソースタイプは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 |
---|---|
| Tables being accessed or the procedure being called |
| Every column referenced |
2. INSERT
ステートメントの処理:
Right | Object |
---|---|
| Table being inserted into |
| Every column being inserted in that table |
3. UPDATE
ステートメントの処理:
Right | Object |
---|---|
| Table being updated |
| Every column being updated in that table |
| Every column referenced in the criteria |
4. DELETE
ステートメントの処理:
Right | Object |
---|---|
| Table being deleted |
| Every column referenced in the criteria |
5. EXEC/CALL
ステートメントの処理:
Right | Object |
---|---|
| Procedure being executed |
6. 任意の関数を処理します:
Right | Object |
---|---|
| Function being called |
7. ALTER
またはCREATE TRIGGER
ステートメントを処理します:
Right | Object |
---|---|
| View or procedure that is affected |
INSTEAD OF
トリガー(更新プロシージャ)はまだ完全なスキーマオブジェクトとはみなされず、代わりにビュー属性として扱われることに注意してください。
8. OBJECTTABLE
関数を処理します:
Right | Object |
---|---|
| Allowed language name |
さらに、一時テーブルに対する文の処理には、該当するロールにallowCreateTempTables
属性が必要です。
Owner and Runner (Executor) of Jobs and Procedures
ジョブとプロシージャはowner
とrunner
属性を持ちます。スケジュールは owner
属性を持っています。これらの属性は、ジョブやプロシージャのアクセス権を定義します。
Owner
デフォルトでは、ジョブまたはプロシージャの作成者はその所有者です。所有者は、存在しないユーザー名であっても、別のユーザー名に設定することができます。プロシージャでは、プロシージャを作成または変更するときに設定できます。ジョブは所有者のデフォルト値で作成され、所有者はSYSADMIN.changeJobParameters プロシージャで変更できます。 の所有者を変更できるのは、admin-role
のメンバーのみです。
Runner
デフォルトでは、ランナーは CALLER
に設定されます。 プロシージャでは、プロシージャを作成するとき、またはEXECUTE AS
を使用してプロシージャを変更するときに設定できます。ジョブはrunAs
とrunAs
のデフォルト値で作成されますが、 SYSADMIN.changeJobParameters
のプロシージャで変更することができます。admin-role
の所有者とメンバーのみが runner
を変更できます。
許可された値は、CALLER
およびOWNER
です。
CALLER
は、ジョブを呼び出したユーザ(ジョブをトリガーしたスケジュールの所有者)またはプロシージャの権限が、ジョブまたはプロシージャに適用されることを意味します。例えば、ジョブやプロシージャがpg
とテーブルtable_1
を持つPostgreSQL データソースからのSELECT
を含み、ランナーがCALLER
の場合、ジョブやプロシージャを呼び出すユーザはREAD
のPermission を持っていなければなりません。pg.table_1
OWNER
は、ジョブやプロシジャの所有者のPermission が適用されることを意味します。例えば、ジョブやプロシジャが という名前のPostgreSQL データソースから を含み、テーブル とランナーが の場合、ジョブを呼び出すユーザ(より具体的には、ジョブをトリガーするスケジュールの所有者)やプロシジャは の権限を持っていないかもしれませんが、ジョブやプロシジャの所有者はこの権限を持っていなければなりません。 pg.table_1
pg
SELECT
table_1
OWNER
READ
ALTER
runner
= OWNER
のパーミッションを持つジョブやプロシージャを慎重に付与してください。そのようなジョブやプロシージャに対してALTER
EXECUTE
のパーミッションを持つユーザーは、所有者に代わって、所有者のアクセス権を使用して、それらを変更したり、何かを実行したりすることができます。
See Also
Permission Management Permissions を設定するための専用のシステムプロシージャについては、こちらをご覧ください。