Permissions

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

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

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

Permission Overlap

ユーザが重複するパーミッションを持つ複数のロールを持つ場合、正のパーミッションが優先されます。
例： ユーザが role_1 と role_2を持ち、 role_1 が view1 に対するR 権限を持ち、 role_2 が負の権限 ('') に対する view1を持つ場合、そのユーザは view1を見てアクセスすることができます。

Specificity of Permissions

権限は、対象となるリソースに応じて、より具体的にしたり緩めたりすることができます。考えられるケースは2つあります：

1. 特異性の衝突を持つ単一のロール
   ユーザが、一般的な権限と特定の権限の両方を含む単一のロールを持つ場合、より具体的な権限が適用されます。
   例：ユーザが role_1 を持ち、 role_1  がすべてのリソースに対する R  権限を持ち、データソース ds_1 に対するネガティブな権限 ('')  を持っている場合、そのユーザーは ds_1 を表示およびアクセスすることができません。

2. 特異性の衝突を持つ複数のロール
   ユーザが複数のロールを持ち、一方が一般的な権限、もう一方がより具体的な制限を持つ場合、ポジティブな権限が優先されます。
   例：ユーザが role_1  と role_2 を持ち、 role_1  がすべてのリソースに対する R  権限を持ち、 role_2  がデータソース ds_1 に対するネガティブな権限 ('')  を持っている場合、そのユーザーは ds_1 を表示およびアクセスすることができます。

Granting Permissions

権限を付与する際には、セキュリティが最も重要です。より限定的な権限と、そうでない権限が混在する場合には、より限定的な権限が優先されます。
これにより、機密性の高いリソースへのアクセスを明示的に許可する際に、よりきめ細かな制御が保証されます。

Permission Resource Type

権限リソースタイプは2つの方法で定義できます：

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

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

• table
• view
• procedure
• function
• job

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

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

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

Examples

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

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

3. schema_1 のすべてのプロシージャに対して権限を設定します：

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

Wildcards

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

Examples

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

2. すべての関数の権限を設定します：

Assigning and Removing Permissions

オブジェクトの権限は、以下のいずれかの方法で割り当てたり削除したりできます：

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

Access Rights

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

1. SELECT ステートメントの処理またはストアドプロシージャの実行：

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

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

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

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

6. 任意の関数の処理：

7. 任意のALTER またはCREATE TRIGGER ステートメントの処理：

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

8. 任意のOBJECTTABLE 関数の処理：

さらに、一時テーブルに対するステートメントの処理には、該当するロールに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 である場合、ジョブまたはプロシージャを呼び出すユーザーはpg.table_1 に対するREAD 権限を持っていなければなりません。

OWNER は、ジョブやプロシージャの所有者の権限がジョブやプロシージャに適用されることを意味します。例えば、ジョブやプロシージャに、名前がpg でテーブルtable_1 を持つPostgreSQL データソースからのSELECT が含まれていて、実行者がOWNER である場合、ジョブまたはプロシージャを呼び出すユーザー（より正確には、ジョブをトリガーするスケジュールの所有者）またはプロシジャにはpg.table_1 に対するREAD 権限がない可能性がありますが、ジョブやプロシージャの所有者にはこの権限が必要です。

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

See Also

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