第7章 データロール
エンタイトルメントとも呼ばれるデータロールは、データアクセスパーミッションを指定する仮想データベースごとに定義されるパーミッションのセットです(作成、読み取り、更新、削除)。データロールは、Data Virtualization がランタイム時に実施し、アクセス違反の監査ログエントリーを提供する粒度の細かいパーミッションシステムを使用します。
データロールを適用する前に、仮想データベースの基本的な設計でソースシステムアクセスを制限したい場合があります。ほとんどの場合、Data Virtualization はインポートされたメタデータで表されるソースエントリーのみにアクセスできます。インポートされたメタデータは、仮想データベースで使用するために必要なものだけに絞り込む必要があります。
データロール検証が有効になり、データロールが仮想データベースに定義されている場合、アクセスパーミッションは Data Virtualization サーバーによって適用されます。データロールの使用は、teiid
サブシステム policy-decider-module の設定を削除することで、システム全体で無効にできます。データロールには、行ベースおよびその他の承認チェックに使用できる組み込み セキュリティー機能 もあります。
データロールなしでデプロイされた仮想データベースには、任意の認証ユーザーがアクセスできます。
デフォルトでは、非表示でないスキーマメタデータは、ユーザーが指定されたオブジェクトに対して何らかのパーミッションがある場合にのみ、JDBC/pg に表示されます。OData アクセスは、デフォルトで非表示ではないメタデータをすべて提供します。JDBC/pg を設定して、全認証ユーザーに非表示でないスキーマメタデータも表示されるようにするには、environment/system プロパティー org.teiid.metadataRequiresPermission
を false に設定します。
7.1. パーミッション リンクのコピーリンクがクリップボードにコピーされました!
複数の方法でデータへのアクセスを制御するか、または付与します。SELECT、UPDATE などの単純なアクセス制限が列レベルまでありました。
少なくとも 1 列を読み取る権限がない限り、列またはテーブルメタデータが JDBC/ODBC ユーザーに表示されません。
パーミッションを使用して結果をフィルターおよびマスクし、更新値を制限/チェックすることもできます。
ユーザークエリーのパーミッション
CREATE、READ、UPDATE、DELETE(CRUD)パーミッションは、VDB 内のリソースパスに設定できます。リソースパスは、列の完全修飾名または一般レベルのモデル(スキーマ)名として固有にできます。特定のパスに付与されたパーミッションは、そのパスと、同じ部分的な名前を共有するリソースパスに適用されます。たとえば、選択を「model」に付与すると、その選択も「model.table」、「model.table.column」などに付与されます。特定のアクションを許可または拒否するには、最も具体的なリソースパスからパーミッションを検索することで決定されます。特定の allow または deny で見つかった最初のパーミッションが使用されます。そのため、高レベルのリソースパス名で非常に一般的なパーミッションを設定し、より具体的なリソースパスに必要な場合にのみ上書きできます。
パーミッション付与は、ロールがアクセスする必要のあるリソースにのみ必要です。パーミッションは、表示および手順の定義で推移的にアクセスされるすべてのリソースではなく、ユーザークエリーの列/テーブル/プロセスのみにも適用されます。そのため、パーミッション付与が同じリソースにアクセスするモデル間で一貫して適用されるようにすることが重要です。
非表示ではないモデルは、ユーザークエリーでアクセスできます。ユーザーアクセスをモデルレベルで制限するには、データロールの確認を有効にするために少なくとも 1 つのデータロールを作成する必要があります。その後、このロールは任意の認証ユーザーにマッピングでき、アクセスできないモデルにパーミッションを付与することはできません。
パーミッションは、SYS および pg_catalog スキーマには適用されません。これらのメタデータレポートスキーマは、ユーザーに関係なく常にアクセスできます。ただし、SYSADMIN スキーマでは、必要に応じてパーミッションが必要になる場合があります。
パーミッションの割り当て
SELECT ステートメントまたはストアドプロシージャーの実行を処理するには、ユーザーアカウントに以下のアクセス権限が必要です。
- SELECT- アクセスされるテーブル、または呼び出される手順。
- SELECT- 参照されたすべての列で。
INSERT ステートメントを処理するには、ユーザーアカウントに以下のアクセス権限が必要です。
- INSERT: 挿入されるテーブル。
- INSERT: テーブルに挿入されるすべての列。
UPDATE ステートメントを処理するには、ユーザーアカウントに以下のアクセス権限が必要です。
- UPDATE- 更新されるテーブルで。
- UPDATE- そのテーブルで更新されるすべての列で。
- SELECT- 条件で参照されるすべての列で。
DELETE ステートメントを処理するには、ユーザーアカウントに以下のアクセス権限が必要です。
- DELETE- 削除中のテーブルで
- SELECT- 条件で参照されるすべての列で。
EXEC/CALL ステートメントを処理するには、ユーザーアカウントに以下のアクセス権限が必要です。
- EXECUTE(または SELECT)- 実行される手順。
任意の機能を処理するには、ユーザーアカウントに以下のアクセス権限が必要です。
- EXECUTE(または SELECT)- 呼び出される機能。
ALTER または CREATE TRIGGER ステートメントを処理するには、ユーザーアカウントに以下のアクセス権限が必要です。
- 代替方法として、有効なビューまたは手順。INSTEAD OF Trigger(更新手順)はまだ完全なスキーマオブジェクトとして処理されず、代わりにビューの属性として処理されます。
OBJECTTABLE 機能を処理するには、ユーザーアカウントに以下のアクセス権限が必要です。
- gitopsUAGE - 許可される言語名を指定します。
Data Virtualization 一時テーブルに対してステートメントを処理するには、以下のアクセス権限が必要です。
- 任意のロールで allow-create-temporary-tables 属性
- 必要に応じて、FOREIGN 一時テーブルに対する操作に必要なターゲットモデル/スキーマに対して SELECT、INSERT、UPDATE、DELETE。
行ベースのセキュリティー
ユーザークエリーの CRUD パーミッションと同様の方法で指定されますが、行ベースおよび列ベースのパーミッションは、より粒度の細かい一貫性のあるレベルでユーザーへ返されるデータを制御するために一緒にまたは別々に使用できます。
行ベースのセキュリティーに対する GRANT での条件の指定は非推奨になりました。GRANT での条件の指定は、「CREATE POLICY policyName ON schemaName.tblName TO role USING(condition);)」を指定することと同じで、条件がすべての操作に適用されます。
完全修飾テーブル/ビュー/手順に対する POLICY は、指定のロールにより満たされる条件を指定できます。条件は、テーブル/ビュー/手順の列を参照する有効なブール式であればどれでも構いません。手順の結果セット列は proc.col
として参照できます。条件は行ベースのフィルターとして機能し、挿入/更新操作のチェックされた制約として機能します。
行ベースの条件の適用
条件は、影響を受けるリソースに対して WHERE 句を更新/削除/選択するために制約が適用されます。そのため、これらのクエリーは、条件を渡す行のサブセット("SELECT * FROM TBL WHERE something AND 条件 )に対してのみ有効です。条件は、統合、結合、またはその他の操作のいずれかによって、クエリーでテーブル/ビューがどのように使用されるかに関係なく表示されます。
条件例
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 が適用される操作を制限することで、挿入/更新の制約チェックを無効にできます。
DDL 以外の制約条件の例
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 を作成すると、そのロールのユーザーは指定の操作に対する指定のリソースの行をすべて表示できます。
条件使用時の考慮事項
プッシュされない状況は、パフォーマンスに悪影響を及ぼす可能性があることに注意してください。プッシュされていない条件と同じリソースに対して複数の条件を使用しないと、OR ステートメント全体がプッシュされません。パーミッション条件の挿入が必要な場合は、インラインビューを追加する際には注意してください。これは、ソースと互換性のない場合にパフォーマンスの問題が発生する可能性があるためです。
各行の条件をチェックする必要があるため、複数行を挿入/更新操作をプッシュすると抑制されます。
パーミッション条件はロールごとに管理できますが、別の方法として、認証されたロールに条件パーミッションを追加します。この方法でパーミッションを追加すると、この条件は hasRole
、user、およびその他のセキュリティー機能を使用するすべてのユーザー
が一般的に使用されます。後者アプローチの利点は、静的な行ベースのポリシーを提供することです。その結果、クエリー計画の範囲全体がユーザー間で共有されます。
null 値の処理方法は以下のとおりです。ISNULL チェックを実装し、列が null 可能である場合に null 値が許可されるようにすることが でき ます。
条件を使用する際の制限
- チェック制約として機能するソーステーブルの条件には、現在相関サブクィジーを含めることはできません。
- 条件には集約関数やウィンドウ機能が含まれない場合があります。
- subqueries で参照されるテーブルと手順には、行ベースのフィルターと列マスクが適用されます。
行ベースのフィルター条件は、マテリアル化されたビューの負荷に対しても適用されます。
マテリアル化されたビューの生成に使用されるテーブルに、マテリアル化されたビューの結果に影響を与える可能性のある行ベースのフィルター条件がないことを確認する必要があります。
列マスク
完全修飾テーブル/ビュー/手順列に対するパーミッションでも、マスクを指定でき、任意で条件を指定できます。クエリーが送信されると、ロールが参照され、関連するマスク/条件情報が組み合わされ、アクセスによって返された値をマスクするために検索されたケース式を形成します。CRUD が上記で定義されたアクションを許可するのとは異なり、生成されるマスク効果は、ユーザーのクエリーレベルだけでなく、常にユーザークエリーレベルに適用されます。条件と式には、テーブル/ビュー/手順の列を参照する有効な SQL を使用できます。手順の結果セット列は proc.col
として参照できます。
列マスクの適用
列のマスクは SELECT にのみ適用されます。列のマスクは、行ベースのセキュリティーに影響を与えた後に論理的に適用されます。ただし、ビューとソーステーブルの両方が行ベースと列ベースのセキュリティーを持つ可能性があるため、実際のビューレベルのマスクはソースレベルのマスクの上に実行できます。条件をマスクと共に指定した場合、有効なマスク式は行のサブセット(CASE WHEN 条件 THEN mask ELSE 列)にのみ影響します。そうでない場合は、条件が TRUE であると想定されます。つまり、マスクがすべての行に適用されます。
複数のロールが列に対してマスクを指定する場合、マスク順序の引数は、検索されたケース式の中で、上から順に優先順位を決定します。たとえば、デフォルトの順序が 0 で、順序が 1 のマスクは「CASE WHEN condition1 THEN mask1 WHEN condition0 THEN mask0 ELSE column」と組み合わされます。
列マスクに関する考慮事項
非プッシュマスクの条件/式は、影響を受けるリソースの上にクエリー構成が無害になる可能性があるため、パフォーマンスに悪影響を及ぼす可能性があります。場合によっては、マスクの挿入で、インラインビューの追加でプランを変更する必要がある場合があります。これにより、ソースがインラインビューの使用と互換性がない場合にはパフォーマンスが低下する可能性があります。
order の値を使用してロールごとにマスクを管理する方法に加え、条件/式が hasRole
、ユーザー、およびその他のセキュリティー機能を使用して、認証されたユーザー
/ロールごとにマスクを指定する方法です。後者のアプローチの利点は、すべてのクエリー計画をユーザー間で共有できるように、実質的に静的なマスクポリシーがあることです。
列マスクの制限
- 2 つのマスクの order 値が同じ場合、適用される順序は明確に定義されません。
- マスクまたはその条件に集約またはウインドウ関数を含めることはできません。
- subqueries で参照されるテーブルと手順には、行ベースのフィルターと列マスクが適用されます。
マスクは、マテリアル化されたビューの負荷に対しても適用されます。
マテリアル化されたビューの生成に使用されるテーブルにマスクがなくなり、マテリアル化されたビューの結果に影響を与える可能性があることを確認する必要があります。