ユーザーに返されるデータを制御するために、SYSADMIN.setPermissions システムプロシージャを使用して、行ベースの Permission と列マスキングを一緒に、または個別に設定できます。

Row-based Permissions

完全修飾されたテーブル、ビュー、またはプロシージャに対するPermissionsは、条件を指定することができます。以下に留意点を挙げます:

  • 条件はUser Queryレベルだけでなく、常に適用されます;
  • サブクエリを介して参照されるテーブルとビューには、行ベースのフィルタと列のマスキングが適用されます;
  • 条件は、テーブルまたはビューのカラムを参照する有効な SQL 文であれば何でもかまいません;
  • この条件は、行ベースのフィルタとして、またINSERT / UPDATE操作のチェック付き制約として機能します;
  • この条件は、TableやViewがどのように問い合わせで使用されるかに関係なく存在します(UNION、JOINなど)。

指定されたリソースに対するUPDATE / DELETE / SELECT / WHERE句に対して条件が連結的に適用されるため、これらのクエリは条件を通過した行のサブセットにのみ影響します。INSERT / CHANGEの値が、INSERT / UPDATEが成功するための条件(TRUEへの評価)に適合するように、影響を受ける物理テーブルに対する挿入と更新がさらに検証されます。INSERT / UPDATE制約チェックを無効にするには、条件制約フラグをFALSEに設定します。

Currently, conditions on source tables acting as check constraints must not contain correlated subqueries.

複数の適用可能なRolesにまたがって、複数の条件が同じリソースに適用される場合、条件は OR を介して分離的に累積されます。これは、TRUE 条件でPermissionを付与すると、このロールを持つユーザは指定されたリソースのすべての行を見ることができることを意味します。

NULL値の取り扱いは特定のデータロールの実装者次第であり、列がNULL可能である時にNULL値が許可されることを保証するためにISNULL検査を必要とするかもしれません。

以下に、行ベースの Permission 設定の例を示します:

1. この例では、col1 > 10の場合、test_schema.test_view1 の行を表示します:

CALL "SYSADMIN.setPermissions"(
"role_name" => 'user-role-1',
"resourceName" => 'test_schema.test_view1',
"permissions" => 'CRUDEAL',
"condition" => 'col1 > 10'
);;

2. この例では、MOD(d, 100) IN (SELECT a FROM test_tables_pg.test_a)の場合、test_tables_pg.test_d の行を表示します:

CALL "SYSADMIN.setPermissions"(
"role_name" => 'user-role-1',
"resourceName" => 'test_tables_pg.test_d',
"permissions" => 'CRUDEAL',
"condition" => 'MOD(d, 100) IN (SELECT a FROM test_tables_pg.test_a)'
);;

Column Masking

完全修飾されたテーブル、ビュー、またはプロシージャ列に対するPermissionは、マスクと、オプションで条件を指定することもできます。クエリが送信されると、Roleがチェックされ、関連するマスクまたは条件情報が組み合わされて、アクセスに従って返されたであろう値をマスクする検索されたケース式が形成されます。結果としてのマスクは、User Queriesレベルだけでなく、常に適用されます。条件と式は、テーブルの列、ビュー、またはプロシージャを参照する有効な SQL 文であれば何でもかまいません。

列マスキングは、 SELECT ステートメントに対してのみ適用され、2ターン目では、行ベースのセキュリティの後に適用されます。しかし、ViewとソースTableの両方が行と列ベースのセキュリティを持つ可能性があるため、実際のViewレベルのマスキングはソースレベルのマスキングの上で行われる可能性があります。マスクとともに条件が指定された場合、有効なマスク式は行のサブセットのみに影響します: CASE WHEN condition THEN mask ELSE column .そうでない場合、条件はTRUEであると仮定され、マスクがすべての行に適用されることを意味します。

複数のロールが1つの列に対してマスクを指定する場合、マスクの順序引数は、より大きな検索された大文字小文字式の一部として、最も高いものから最も低いものへの優先順位を決定します。例えば、デフォルトの次数が0のマスクと次数が1のマスクは、CASE WHEN condition1 THEN mask1 ELSE CASE WHEN condition0 THEN mask0 ELSE column END ENDのように結合されます。

以下はその例です:

1. この例では、col2 col2 > 3の代わりに ' 1111 ' を表示するよう求めています:

CALL "SYSADMIN.setPermissions"(
"role_name" => 'user-role-1',
"resourceName" => 'test_schema.colMask_view1',
"permissions" => 'CRUDEAL'
);;
 
CALL "SYSADMIN.setPermissions"(
"role_name" => 'user-role-1',
"resourceName" => 'test_schema.colMask_view1.col2',
"permissions" => 'CRUDEAL',
"condition" => 'col2 > 3',
"mask" => 1111,
"maskOrder" => 1
);;

2. col2 を CASE WHEN col2 <= 2 THEN 2222 ELSE CASE WHEN col2 >= 2 THEN 1111 ELSE col2 END ENDのように表示したい場合です:

CALL "SYSADMIN.setPermissions"(
"role_name" => 'user-role-1',
"resourceName" => 'test_schema.colMask_view1',
"permissions" => 'CRUDEAL'
);;
 
CALL "SYSADMIN.setPermissions"(
"role_name" => 'user-role-1',
"resourceName" => 'test_schema.colMask_view1.col2',
"permissions" => 'CRUDEAL',
"condition" => 'col2 >= 2',
"mask" => 1111,
"maskOrder" => 1
);;
 
CALL "SYSADMIN.setPermissions"(
"role_name" => 'user-role-2',
"resourceName" => 'test_schema.colMask_view1.col2',
"permissions" => 'CRUDEAL',
"condition" => 'col2 <= 2',
"mask" => 2222,
"maskOrder" => 2
);;