第7章 データロール

複数の方法でデータへのアクセスを制御するか、または付与します。SELECT、UPDATE などの単純なアクセス制限が列レベルまでありました。

パーミッションを使用して結果をフィルターおよびマスクし、更新値を制限/チェックすることもできます。

パーミッション付与は、ロールがアクセスする必要のあるリソースにのみ必要です。パーミッションは、表示および手順の定義で推移的にアクセスされるすべてのリソースではなく、ユーザークエリーの列/テーブル/プロセスのみにも適用されます。そのため、パーミッション付与が同じリソースにアクセスするモデル間で一貫して適用されるようにすることが重要です。

パーミッションは、SYS および pg_catalog スキーマには適用されません。これらのメタデータレポートスキーマは、ユーザーに関係なく常にアクセスできます。ただし、SYSADMIN スキーマでは、必要に応じてパーミッションが必要になる場合があります。

INSERT ステートメントを処理するには、ユーザーアカウントに以下のアクセス権限が必要です。

UPDATE ステートメントを処理するには、ユーザーアカウントに以下のアクセス権限が必要です。

DELETE ステートメントを処理するには、ユーザーアカウントに以下のアクセス権限が必要です。

EXEC/CALL ステートメントを処理するには、ユーザーアカウントに以下のアクセス権限が必要です。

任意の機能を処理するには、ユーザーアカウントに以下のアクセス権限が必要です。

ALTER または CREATE TRIGGER ステートメントを処理するには、ユーザーアカウントに以下のアクセス権限が必要です。

OBJECTTABLE 機能を処理するには、ユーザーアカウントに以下のアクセス権限が必要です。

Data Virtualization 一時テーブルに対してステートメントを処理するには、以下のアクセス権限が必要です。

完全修飾テーブル/ビュー/手順に対する POLICY は、指定のロールにより満たされる条件を指定できます。条件は、テーブル/ビュー/手順の列を参照する有効なブール式であればどれでも構いません。手順の結果セット列は proc.col として参照できます。条件は行ベースのフィルターとして機能し、挿入/更新操作のチェックされた制約として機能します。

CREATE POLICY policyName ON schemaName.tblName TO superUser USING ('foo=bar');

CREATE POLICY policyName ON schemaName.tblName TO superUser USING ('foo=bar');

条件が影響を受ける物理テーブルに対して挿入と更新がさらに検証されるため、挿入/更新の値は、正常な SQL 制約と同じ挿入/更新に条件（evaluate から true）を渡す必要があります。これは、クエリー式、一括挿入/更新などを含むすべてのスタイルで行われます。ビューに対する挿入/更新は、制約に関してチェックされません。

POLICY が適用される操作を制限することで、挿入/更新の制約チェックを無効にできます。

CREATE POLICY readPolicyName ON schemaName.tblName FOR SELECT,DELETE TO superUser USING ('col>10');

CREATE POLICY readPolicyName ON schemaName.tblName FOR SELECT,DELETE TO superUser USING ('col>10');

当然ながら別の POLICY を追加して、INSERT および UPDATE 操作に対応するには、異なる条件が必要です。

複数の POLICY が同じリソースに適用されると、その条件は OR 経由で誤って累積されます（"(condition1) OR (condition2)…）。そのため、条件「true」で POLICY を作成すると、そのロールのユーザーは指定の操作に対する指定のリソースの行をすべて表示できます。

各行の条件をチェックする必要があるため、複数行を挿入/更新操作をプッシュすると抑制されます。

パーミッション条件はロールごとに管理できますが、別の方法として、認証されたロールに条件パーミッションを追加します。この方法でパーミッションを追加すると、この条件は hasRole、user、およびその他のセキュリティー機能を使用するすべてのユーザー が一般的に使用されます。後者アプローチの利点は、静的な行ベースのポリシーを提供することです。その結果、クエリー計画の範囲全体がユーザー間で共有されます。

null 値の処理方法は以下のとおりです。ISNULL チェックを実装し、列が null 可能である場合に null 値が許可されるようにすることが でき ます。

マテリアル化されたビューの生成に使用されるテーブルに、マテリアル化されたビューの結果に影響を与える可能性のある行ベースのフィルター条件がないことを確認する必要があります。

複数のロールが列に対してマスクを指定する場合、マスク順序の引数は、検索されたケース式の中で、上から順に優先順位を決定します。たとえば、デフォルトの順序が 0 で、順序が 1 のマスクは「CASE WHEN condition1 THEN mask1 WHEN condition0 THEN mask0 ELSE column」と組み合わされます。

order の値を使用してロールごとにマスクを管理する方法に加え、条件/式が hasRole、ユーザー、およびその他のセキュリティー機能を使用して、認証されたユーザー /ロールごとにマスクを指定する方法です。後者のアプローチの利点は、すべてのクエリー計画をユーザー間で共有できるように、実質的に静的なマスクポリシーがあることです。

マテリアル化されたビューの生成に使用されるテーブルにマスクがなくなり、マテリアル化されたビューの結果に影響を与える可能性があることを確認する必要があります。