ビューレベルの詳細な権限¶
Denodo の詳細な制限は、他のコンシューマーに公開するデータを非常に柔軟かつ詳細に制御できる、強力なセキュリティメカニズムです。Denodo では、ビューに対するさまざまな種類の詳細なアクセス制御が可能です。
列権限: ユーザーやロールがクエリで使用できる列を制限します。
行権限: 行のサブセットに対して異なるアクションを許可します。
行を拒否します。
機密性の高いフィールドが使用される場合は、行を拒否します。
機密フィールドをマスクします。
非定型実装を必要とする特定の要件がある場合のために、Denodo には独自の カスタムポリシー を作成するための API もあります。
詳細な権限の使用について理解するには、 特定のビューに対するアクセス権をロールに付与するということは、単にそのビューを実行するためのアクセス権を与えることではない ということを念頭に置く必要があります。そのロールがビューを作成するための十分な権限を持っている場合、アクセス権のあるビューを基に新しいビューを作成して、それらの新しいビューにアクセスできる人を決定することもできるのです。つまり、ビューを実行するためのアクセス権をユーザーに与えるということは、ユーザーがそのビューのデータに対する権限を他のユーザーに付与できるようにすることでもあるのです。
たとえば、従業員に関するデータを含む標準ビュー EMPLOYEE に人事部の開発者がアクセスできるようにしたいとします。ただし、そのデータには従業員に関する個人情報が含まれているため、営業などの他部署からはアクセスしてほしくありません。人事部の開発者は EMPLOYEE にアクセスできるため、そのビューを使用してクエリを実行できるだけでなく、従業員情報を使用して新しいビューを作成することもできます。たとえば、EMPLOYEE を基に作成した新しいビューに対して営業部からのアクセスを許可して、EMPLOYEE ビューのデータに間接的にアクセスできるようにすることが可能です。
ここで役立つのが、中間レベルの詳細な制限です。
特定のロールについて、ビューに対する詳細な制限を指定した場合、そのロールを持つユーザーが (さらに多くの権限を持つ別のロールを持っていなければ) そのビューを基に構築されたビューを実行するときにも、常に制限が適用されます 。
そのため、この場合も、EMPLOYEE に制限を設けて、人事部の人だけがデータにアクセスできるようにすることが可能です。この方法では、人事部は営業部にビューを実行するためのアクセス権を与えることができますが、常に EMPLOYEE ビューに対する制限が適用されるため、営業部では従業員情報を一切見ることができません。
注釈
CREATE 権限を持つユーザーにビューに対する実行権限を与えるということは、間接的にそのビューのデータに対する権限を第三者に付与できるようにすることになります。詳細な制限により、この権限に対する制限を設けて、特定のセキュリティルールが常に適用されるようにすることができます。
そうした制限を適用すれば、汎用性が非常に高くなります。すべてのビューに対して同じ制限を複製しなくても、さまざまなユーザーが同じデータセットの異なるバージョンを参照できるようになるからです。その場合、中間ビューでこれらの制限を定義して、異なるビューに対して同じ制限を再利用できるようにするのがよいと考える人もいるかもしれません。ただし、それでは管理が難しくなる可能性があるため、一般的に適した方法ではありません。セキュリティの境界線上でファサードとして機能する、ビューに対する制限を常に定義する方法のほうが適しています。さらに、制限の定義の多くを再利用するには、 tag-based security policies を利用できます。
注釈
一般的なルールとして、データ所有者がビューを他のユーザーに公開したい場合、その下のビューではなく、それらのユーザーに見えるビューに対して詳細な制限を定義する必要があります。
あるいは、あるユーザーにビューの実行権限を付与した場合、該当のデータに対する権限が他のユーザーにも付与されてしまうことを避けるため、以下のオプションを使用できます。
タグベースのセキュリティポリシー を使用して、特定のロールのユーザーに対してビューのアクセスを制限します。
INDIRECT_ACCESS 権限を使用して、ビューのデータにアクセスできるロールを決定します。
列権限¶
ビューに対する EXECUTE 権限をユーザーまたはロールに付与した場合、このユーザー、またはこのロールを持つユーザーは、次のタスクを実行できます。
SELECT ステートメントを実行して、このビューに対してクエリを実行する。
ユーザーまたはロールがビューに対する INSERT 権限、UPDATE 権限、または DELETE 権限も持っている場合、このビューに対して INSERT、UPDATE、または DELETE の各ステートメントを実行できます。
場合によっては、ビューの特定の列へのアクセスを特定のユーザーに制限することができます。INSERT、UPDATE、または DELETE の各ステートメントを使用してクエリまたは変更を実行できないビューの列は、 保護列 と呼ばれます。
たとえば、「employee」というビューがあり、「developer」ロールを持つユーザーが「salary」列を参照するのを禁止するとします。つまり、「developer」ロールを持つユーザーに対して「salary」列を保護列にします。それには、以下の手順に従ってください。
[Administration] メニュー > [Role Management] をクリックします。ロールが表示されているテーブルで「developer」ロールを選択します。
[Assign privileges] をクリックして、「employee」ビューのデータベースの行で [edit] をクリックします。
少なくとも、このビューに対する「Execute」権限を選択します。
「employee」ビューの行を選択して、[Assign column privileges] をクリックします。
このダイアログで、「salary」フィールドの横にあるチェックボックスのチェックを外します。
この変更によって、ユーザーは次のクエリを実行できるようになります。
SELECT ename
FROM employee
ただし、次のクエリは失敗します。
SELECT ename, salary
FROM employee
クエリを失敗させずに、列の値をマスクしたい場合は、列マスキングを使用して行制限を指定できます (以下の「 行制限 」を参照)。
列権限を割り当てる場合は、以下の点に注意してください。
ビューに対する列権限をユーザーに割り当てた場合、クエリの句のいずれか (SELECT、WHERE、GROUP BY など) でこのビューの保護列を参照していると、このユーザーが実行するステートメントは失敗します。これは、たとえばユーザーが WHERE 句などで保護列を使用してその値を推測できないようにするためです。この例については、次のセクションを参照してください。
列権限は、グローバル管理者、またはビューが属するデータベースの管理者には影響しません。これらの管理者は、ステートメントで保護列を参照できます。
実行エンジンでは、列権限を指定されたビューがクエリで直接参照されているかどうかにかかわらず、ユーザー/ロールに付与された、ビューの列権限、行制限、カスタムポリシーが考慮されます。
次の表に、各 DML ステートメントについて、列権限の動作のリストを示します。
ステートメント |
動作 |
|
---|---|---|
SELECT |
保護列を参照しない |
クエリは実行される |
保護列を参照する |
クエリは失敗する |
|
CREATE MATERIALIZED TABLE <materialized table> AS SELECT ... FROM <view with restricted columns> |
保護列を参照しない |
クエリは実行される |
保護列を参照する |
クエリは失敗する |
|
INSERT |
ステートメントは常に実行される |
|
INSERT INTO <materialized view> SELECT ... FROM <view with restricted columns> |
保護列を参照しない |
ステートメントは実行される |
保護列を参照する |
ステートメントは失敗する |
|
UPDATE |
保護列を参照しない |
ステートメントは実行される |
保護列を参照する |
ステートメントは失敗する |
|
DELETE |
保護列を参照しない |
ステートメントは実行される |
保護列を参照する |
ステートメントは失敗する |
行制限¶
ユーザーまたはロールがビューに対する EXECUTE 権限、UPDATE 権限、または DELETE 権限を持っている場合は、そのビューに対して制限を定義して、そのユーザーまたはロールに返される行や、UPDATE ステートメントまたは DELETE ステートメントの影響を受ける行を制限できます。そうすることで、そのユーザーがビューに対して DML 操作を実行したときに、特定の条件に一致する行のみを取得、更新、または削除したり、一部の行の一部のフィールドをマスクしたりできます。
たとえば、「employee」ビューへのアクセスを、「developer」ロールを持つユーザーのみに制限するとします。ユーザーまたはロールに行制限を割り当てるには、そのユーザーまたはロールを編集して、制限するビュー (ここの例では「employee」) を選択し、[Assign restrictions]、[New restriction] の順にクリックします。
このダイアログでは、まず条件を指定する必要があります。ユーザーは、入力した条件 (position <> 'manager'
など) を満たす行を表示できます。条件を 満たさない 行に対するアクションとして、以下のいずれかを選択する必要があります。
Reject row: この例では、ユーザーは、マネージャーではない従業員のみを表示、更新、または削除できます。
Reject row if ANY/ALL sensitive fields are used ([ANY] または [ALL] を選択可能): たとえば、ステートメントが「salary」列を参照していない場合は、すべての従業員データの表示をユーザーに許可することができます。選択、更新、または削除の各操作が「salary」列を参照している場合、このステートメントはマネージャーではない従業員にのみ影響します。
Mask sensitive fields if ANY/ALL of them are used ([ANY] または [ALL] を選択可能): たとえば、すべての従業員データの表示をユーザーに許可することができますが、マネージャーである従業員の salary フィールドの値はマスキング式で置換します。
以下の表に、機密値を置き換えるための マスキング式 を示します。
式 |
説明 |
---|---|
Hide |
|
Show first 4 characters |
固定数のアスタリスクが付いた最初の 4 文字が返されます。 |
Show latest 4 characters |
固定数のアスタリスクが付いた最後の 4 文字が返されます。 |
Only year |
実際の年のみを返します。他の値はデフォルトにリセットされます。 |
Redact |
フィールドタイプに応じて、あらかじめ定義されたマスキング値を返します。 |
Redact with asterisk |
固定数のアスタリスクを返します。 |
Remove time |
時間の値をデフォルトにリセットします。 |
Round |
数値の値を丸めます。 |
Set to 0 |
値 |
Set to -1 |
値 |
Custom |
ユーザー定義の式。 この式はフィールドと同じタイプにする必要があります。それ以外の場合は |
以下の表に、型ごとの REDACT のデフォルト式を示します。
型 |
式 |
---|---|
数字 |
値 |
テキスト |
固定数のアスタリスクを返します。 |
日付時刻 |
正しい型 (localdate、timestamp...) の値をデフォルトにリセットして返します。 たとえば、「localdate」の値は 1970-01-01、「timestamp」の値は 1970-01-01 00:00:00 になります。 |
その他の型 |
|
クエリの結果をフィルタするかどうかを決定するために必要なあらゆる情報に基づいて、いわゆる カスタムポリシー を作成できます。カスタムポリシーの概要とその作成方法については、『開発者ガイド』の「 カスタムポリシー 」を参照してください。
行制限を割り当てる場合は、以下の点に注意してください。
行制限は、グローバル管理者、またはビューが属するデータベースの管理者には影響しません。つまり、行制限の有無にかかわらず、行が拒否またはマスクされることはありません。
実行エンジンでは、列権限を指定されたビューがクエリで直接参照されているかどうかにかかわらず、ユーザー/ロールに付与された、ビューの列権限、行制限、カスタムポリシーが考慮されます。
[Reject row if ANY/ALL sensitive fields are used] オプションとマスキングは、クエリのいずれかの句 (SELECT、WHERE、GROUP BY など) がこのビューの機密フィールドを参照している場合に適用されます。これは、ユーザーが WHERE 句で機密フィールドを使用してその値を推測するのを防ぐためです。たとえば、機密フィールド salary が SELECT 句でのみマスクされている場合、ユーザーは以下のようなクエリを使用して値の推測を試みることができます。
SELECT ename FROM employee WHERE salary > 50000 and salary < 100000;
または
UPDATE employee SET ename = ename || '_100000' WHERE salary > 100000
次の表に、DML ステートメントの各タイプについて、[Reject Row] 制約の動作を示します。
ステートメント |
動作 |
---|---|
SELECT |
Virtual DataPort では、制限の条件を含む DML コマンドが実行される |
CREATE MATERIALIZED TABLE <materialized table> AS SELECT ... FROM <view with restrictions> |
Virtual DataPort では、制限の条件を含む DML コマンドが実行される |
INSERT |
制限なし |
INSERT INTO <materialized table> SELECT ... FROM <view with restrictions> |
Virtual DataPort では、制限の条件を含む DML コマンドが実行される |
UPDATE |
Virtual DataPort では、制限の条件を含む DML コマンドが実行される |
DELETE |
Virtual DataPort では、制限の条件を含む DML コマンドが実行される |
たとえば、「employee」ビューに対する行制限を「sales_manager」ロールに割り当てているとします。この行制限は、条件 department = 'sales'
を満たしていない行を拒否します。
「sales_manager」ロールを持つユーザーが次のクエリを実行したとします。
SELECT * FROM employee
SELECT * FROM employee WHERE department = 'sales'
ユーザーが employee に対する UPDATE 権限を持っていて、次のクエリを実行したとします。
UPDATE employee SET manager_id = 1 WHERE manager_id = 2
UPDATE employee SET manager_id = 1 WHERE manager_id = 2 AND department = 'sales'
次の表に、DML ステートメントの各タイプについて、[Reject Row if ANY/ALL sensitive fields are used] 制限の動作を示します。
ステートメント |
動作 |
|
---|---|---|
SELECT |
機密フィールドを使用しない場合 |
制限なし |
機密フィールドを使用する場合 |
Virtual DataPort では、制限の条件を含む DML コマンドが実行される |
|
CREATE MATERIALIZED TABLE <materialized table> AS SELECT ... FROM <restricted view> |
機密フィールドを使用しない場合 |
制限なし |
SELECT クエリで機密フィールドを使用する場合 |
Virtual DataPort では、制限の条件を含む DML コマンドが実行される |
|
INSERT |
制限なし |
|
INSERT INTO <materialized table> SELECT ... FROM <view with restrictions> |
機密フィールドを使用しない場合 |
制限なし |
SELECT クエリで機密フィールドを使用する場合 |
Virtual DataPort では、制限の条件を含む DML コマンドが実行される |
|
UPDATE |
機密フィールドを使用しない場合 |
制限なし |
機密フィールドを使用する場合 |
Virtual DataPort では、制限の条件を含む DML コマンドが実行される |
|
DELETE |
機密フィールドを使用しない場合 |
制限なし |
機密フィールドを使用する場合 |
Virtual DataPort では、制限の条件を含む DML コマンドが実行される |
たとえば、「employee」ビューに対する行制限を「developer」ロールに割り当てているとします。この行制限は、ステートメントで機密列 salary が使用されている場合にのみ、条件 position <> 'manager'
を満たしていない行を拒否します。
「developer」ロールを持つユーザーが次のクエリを実行したとします。
SELECT ename FROM employee
SELECT ename FROM employee WHERE salary > 50000
SELECT ename FROM employee WHERE salary > 50000 and position <> 'manager'
同様に、同じユーザーが次のクエリを実行したとします。
CREATE MATERIALIZED TABLE employee_salary AS SELECT ename, salary FROM employee
SELECT ename, salary FROM employee WHERE position <> 'manager'
次の表に、ステートメントの各タイプについて、[Mask sensitive fields if ANY/ALL of them are used] 制限の動作を示します。
DML 操作 |
動作 |
|
---|---|---|
SELECT |
機密フィールドを使用しない場合 |
制限なし |
機密フィールドを使用する場合 |
機密列の値は Virtual DataPort によってマスクされる |
|
CREATE MATERIALIZED TABLE <materialized table> AS SELECT * FROM <view with restrictions> |
機密フィールドを使用しない場合 |
制限なし |
SELECT クエリで機密フィールドを使用する場合 |
機密列の値は Virtual DataPort によってマスクされる |
|
INSERT |
制限なし |
|
INSERT INTO <materialized table> SELECT * FROM <view with restrictions> |
機密フィールドを使用しない場合 |
制限なし |
SELECT クエリで機密フィールドを使用する場合 |
機密列の値は Virtual DataPort によってマスクされる |
|
UPDATE |
機密フィールドを使用しない場合 |
制限なし |
機密フィールドを使用する場合 |
Virtual DataPort では、制限の条件を含む DML コマンドが実行される |
|
DELETE |
機密フィールドを使用しない場合 |
制限なし |
機密フィールドを使用する場合 |
Virtual DataPort では、制限の条件を含む DML コマンドが実行される |
前述の例を用いて、「developer」ロールを持つユーザーが次のクエリを実行したとします。
SELECT ename, salary FROM employee
この場合、すべての行が返されますが、manager に対応する行の salary の値はマスクされます。
同様に、同じユーザーが次のクエリを実行したとします。
SELECT ename FROM employee WHERE salary > 50000
ユーザーには次のクエリの結果が表示されます。
SELECT ename FROM employee WHERE CASE WHEN (position <> 'manager') THEN salary ELSE null END > 50000
つまり、position がマネージャーではない従業員の名前が表示されます。
同じユーザーが employee に対する DELETE 権限を持っていて、次のクエリを実行したとします。
DELETE FROM employee
この場合、すべての従業員が削除されます。これに対して、今度は次のクエリを実行したとします。
DELETE FROM employee WHERE salary > 50000
「WHERE salary > 50000」を満たし、position が「manager」ではない行のみが削除されます。