Virtual DataPort におけるユーザーおよびアクセス権限¶

アクセス権限のタイプ
列権限
行制限
ロール

Denodo Virtual DataPort では、以下の 2 種類のユーザーが区別されています。

管理者: データベースを作成、変更、および削除することができ、制限は一切ありません。同様に、ユーザーを作成、変更、および削除することもできます。サーバーをインストールする際に、デフォルトの管理者ユーザーがユーザー名 admin 、パスワード admin で作成されます。常に少なくとも 1 人の管理者ユーザーが存在する必要があります。
一般ユーザー: ユーザーまたはデータベースを作成、変更、または削除することはできません。管理者ユーザーは、1 つまたは複数のデータベース、またはそれらのデータベースに含まれる特定のビューに対する Connect 権限、Execute 権限、Create 権限、または Write 権限を一般ユーザーに付与できます。

管理者は、一般ユーザーを 1 つまたは複数のデータベースの データベース管理者 に昇格させることができます。つまり、昇格させたユーザーは、それらのデータベースに対して管理タスクを実行できます。

serveradmin ロールを持つ一般ユーザーは、管理者と同じアクションを実行できます。

「一般ユーザー」に「ロール」を割り当てることができます。ロールとは、データベース、およびそのビューとストアドプロシージャに対する一連のアクセス権限です。ロールに割り当てられている権限を変更すると、そのロールに「属する」すべてのユーザーの権限が変更されます。そのため、ロールを使用すると、管理者はユーザーの権限を簡単に管理できます。

アクセス権限のタイプ¶

Virtual DataPort のアクセス権限を特定のユーザーまたはロールに適用することによって、そのユーザーやロールがデータベース、ビュー、およびストアドプロシージャに対して実行できるタスクの範囲を明確にします。

以下に示すアクセス権限は、「一般」ユーザーにのみ影響します。なぜなら、特定のデータベースのローカル管理者に昇格した一般ユーザーはそのデータベース内で任意のタスクを実行でき、管理者はサーバー全体で任意のタスクを実行できるからです。

「assignprivileges」ロールを持つ管理者は、特定のデータベース全体、または特定のデータベースの特定のビューまたはストアドプロシージャに対する権限をユーザーまたはロールに付与できます。

ユーザーまたはロールに付与できる、データベースに対する権限を以下に示します。

Connect
Create
Create Data Source
Create View
Create Data Service
Create Folder
Metadata
Execute
Write
File
Admin
Insert、Update、および Delete

Connect 権限¶

データベースに対する Connect 権限を持つユーザーは、そのデータベースに接続できます。

ユーザーのすべての権限を一時的に取り消すには、そのユーザーのロールと、すべてのデータベースに対する Connect 権限を取り消します。

Create 権限¶

Create 権限を持つユーザーは、次のタスクを実行できます。

データソース、ビュー、ストアドプロシージャ、Web サービスなどを作成または削除する (つまり、 CREATE ステートメントを実行する)。派生ビューを作成するには、データベース全体、または少なくとも作成するビューで使用するビューに対する Execute アクセス権限が必要です。

一時テーブルの作成をユーザーに許可し、他のタイプのエレメントの作成は許可しない場合は、そのユーザーに create_temporary_table ロールを付与します。

Create Data Source 権限¶

Create Data Source 権限を持つユーザーは、次のタスクを実行できます。

データソースを作成または削除する (つまり、 CREATE DATASOURCE ステートメントを実行する)。

Create View 権限¶

Create View 権限を持つユーザーは、ビュー、ストアドプロシージャ、および型を作成または削除することができます。つまり、 CREATE WRAPPER 、 CREATE TYPE 、 CREATE WRAPPER 、および CREATE PROCEDURE の各ステートメントを実行することができます。これには、マテリアライズドテーブルと一時テーブルが含まれます。

また、作成するビューで直接使用されるビュー、またはそのデータベースに対する「Execute」権限が必要です。

一時テーブルの作成をユーザーに許可し、他のタイプのエレメントの作成は許可しない場合は、そのユーザーに create_temporary_table ロールを付与します。

Create Data Service 権限¶

データベースに対する Create Data Service 権限を持つユーザーは、次のタスクを実行できます。

Web サービス (REST と SOAP)、ウィジェット、および JMS リスナーを作成または削除する (つまり、 CREATE REST/SOAP WEBSERVICE 、 CREATE WIDGET 、および CREATE LISTENER JMS の各ステートメントを実行する)。

Create Folder 権限¶

Create Folder 権限を持つユーザーは、次のタスクを実行できます。

フォルダを作成または削除する (つまり、 CREATE FOLDER ステートメントを実行する)。

Execute 権限¶

データベースに対する Execute 権限を持つユーザーは、次のタスクを実行できます。

データソースのイントロスペクションを実行する。
データベースの任意のビューまたはストアドプロシージャに対してクエリを実行する (つまり、 SELECT ステートメントまたは CALL ステートメントを実行する)。

データベースではなく、特定のビューまたはストアドプロシージャに対するこの権限をユーザーまたはロールに付与した場合、そのユーザーは、次のタスクを実行できます。

ビューまたはプロシージャに対してクエリを実行する (つまり、 SELECT ステートメントまたは CALL ステートメントを実行する)。

特定のビューに対して、より詳細な次の EXECUTE 権限を付与できます。

列権限 (「列権限」を参照)
行制限 (「行制限」を参照)

Metadata 権限¶

Metadata 権限を持つユーザーは、次のタスクを実行できます。

データベースのビューおよびストアドプロシージャのリストを表示する (つまり、 LIST ステートメントを実行する)。
ビューおよびストアドプロシージャのスキーマを表示する。
ビューの [Edit] ダイアログと [Options] ダイアログを開く。ただし、 Write 権限を持たないユーザーは、ビューを変更できません。
ビューの ツリービュー と データリネージ を開く。
実際にクエリを実行することなく、任意のクエリの実行プランを取得する。

クエリのクエリプランを確認するには、ビューの [Execute] ダイアログを開いて [Query plan] をクリックします。または、VQL シェルを開いて、クエリの先頭に DESC QUERYPLAN を付けます。次に例を示します。
```
DESC QUERYPLAN
  SELECT count(*), sum(total)
  FROM invoice
  GROUP BY billing_state
```

データベースではなく、一連のビューまたはプロシージャに対する Metadata 権限を付与した場合、次のような違いがあります。

ユーザーは、データベース全体ではなく、権限を持つビューまたはプロシージャにのみアクセスできます。
クエリプランには、ユーザーが Execute アクセス権限を持つビューの情報のみが表示されます。データソースに関する情報は一切表示されません。たとえば、データベースに委任された SQL クエリは表示されません。

この権限の主な目的は、以下のとおりです。

実際のライブデータを確認しなくても、開発者が本番サーバーに接続して問題をトラブルシューティングできるようにします。たとえば、クエリの実行プラン全体を確認できるようにします。
データソースとその基本ビューはすべて中央のデータベースに保存し、各プロジェクトは専用のデータベースに作成するとします。Metadata 権限を使用することにより、各プロジェクトの開発者はクエリプランの一部だけではなく全体を確認できます。

Write 権限¶

ユーザーまたはロールに Write 権限を付与すると、暗黙的に Execute 権限が付与されます。

データベースに対する Write 権限を持つユーザーは、次のタスクを実行できます。

データベースのデータソース、ビュー、Web サービス (REST と SOAP)、ストアドプロシージャ、ウィジェットを変更または削除する。
データベースの既存のフォルダ間でエレメントを移動する。ただし、移動するエレメントが別のフォルダである場合を除きます。
このデータベースのビューに対して INSERT 、 UPDATE 、および DELETE の各ステートメントを実行する。
Web サービスをデプロイ、再デプロイ、アンデプロイする。
ウィジェットの補助 Web サービスをデプロイ、再デプロイ、およびアンデプロイする。
データソース、ビュー、ストアドプロシージャ、JMS リスナー、Web サービス (REST と SOAP)、およびウィジェットの VQLを表示する。

データベースではなく、特定のエレメント (データソース、ビューなど) に対するこの権限をユーザーに付与した場合、そのユーザーは、次のタスクを実行できます。

エレメントを削除する。削除するエレメントに依存する他のエレメントがある場合、他のエレメントに対する Write アクセス権限も必要です。なぜなら、他のエレメントもカスケード方式で削除されるためです。
エレメントを変更する。ユーザーが派生ビューを変更できるのは、派生ビューのサブビューに対する「Execute」権限を持っている場合のみです。
データベースの既存のフォルダ間でエレメントを移動する。
ビューまたはストアドプロシージャの場合、このエレメントに対して INSERT 、 UPDATE 、および DELETE の各ステートメントを実行する。
エレメントの VQL を表示する。

File 権限¶

File 権限を持つユーザーは、[Server Configuration] ウィザードの [Privileges] ダイアログに一覧表示されたディレクトリを閲覧できます。

Admin 権限¶

この権限は、データベース全体に対してのみ割り当てることができます。この権限を持つユーザーは、そのデータベースのすべてのエレメントに対する Connect 権限、Create 権限、Metadata 権限、Execute 権限、および Write 権限を持ちます。さらに、以下のタスクを実行できます。

データベースのキャッシュ、スワップなどの構成パラメータを設定する。
データベースの説明を編集する。
データベースのエレメントに対する権限を一般ユーザーに付与するか、取り消す。Admin 権限を他のユーザーに付与することはできません。
データベースのエレメントに対する権限をロールに付与するか、取り消す。
フォルダを作成、名前変更、または削除する。
すべての Denodo Web サービスとウィジェットの補助 Web サービスを一覧表示、デプロイ、再デプロイ、およびアンデプロイする。

この権限を持つユーザーは、以下のタスクを実行することはできません。

ユーザーを作成または削除する。
ロールを作成または削除する。
ロールをユーザーまたは他のロールに付与するか、ユーザーまたは他のロールからロールを取り消す。
ユーザーのパスワードを変更する。
データベースを作成または削除する。
Admin 権限を他のユーザーに付与する。

Insert 権限、Update 権限、および Delete 権限¶

Insert 権限を持つユーザーは、ビューに対して INSERT ステートメントを実行できます。

Update 権限を持つユーザーは、ビューに対して UPDATE ステートメントを実行できます。

Delete 権限を持つユーザーは、ビューに対して DELETE ステートメントを実行できます。

これらの権限は、ストアドプロシージャには適用できません。

列権限¶

ビューに対する 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	保護列を参照しない	クエリは実行される
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	保護列を参照しない	ステートメントは実行される
UPDATE	保護列を参照する	ステートメントは失敗する
DELETE	保護列を参照しない	ステートメントは実行される
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 フィールドの値は NULL で置換します。

クエリの結果をフィルタするかどうかを決定するために必要な情報をすべて反映した カスタムポリシー を開発できます。カスタムポリシーの説明とその作成方法については、『開発者ガイド』の「カスタムポリシー」を参照してください。

行制限を割り当てる場合、以下の点を考慮してください。

行制限は、グローバル管理者、またはビューが属するデータベースの管理者には影響しません。つまり、行制限の有無にかかわらず、行が拒否またはマスクされることはありません。
[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] 制約の動作を示します。

各タイプのステートメントの [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] 制限の動作を示します。

各タイプのステートメントの [Reject Row if ANY/ALL sensitive fields are used] 制限の動作¶
ステートメント		動作
SELECT	機密フィールドを使用しない場合	制限なし
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	機密フィールドを使用しない場合	制限なし
UPDATE	機密フィールドを使用する場合	Virtual DataPort では、制限の条件を含む DML コマンドが実行される
DELETE	機密フィールドを使用しない場合	制限なし
DELETE	機密フィールドを使用する場合	Virtual DataPort では、制限の条件を含む DML コマンドが実行される

たとえば、「employee」ビューに対する行制限を「developer」ロールに割り当てているとします。この行制限は、ステートメントで機密列 salary が使用されている場合にのみ、条件 position <> 'manager' を満たしていない行を拒否します。

「developer」ロールを持つユーザーが次のクエリを実行したとします。

SELECT ename FROM employee

この場合、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] 制限の動作を示します。

ステートメントの各タイプの [Mask sensitive fields if ANY/ALL of them are used] 制限の動作¶
DML 操作		動作
SELECT	機密フィールドを使用しない場合	制限なし
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	機密フィールドを使用しない場合	制限なし
UPDATE	機密フィールドを使用する場合	Virtual DataPort では、制限の条件を含む DML コマンドが実行される
DELETE	機密フィールドを使用しない場合	制限なし
DELETE	機密フィールドを使用する場合	Virtual DataPort では、制限の条件を含む DML コマンドが実行される

前述の例を使って、「developer」ロールを持つユーザーが次のクエリを実行したとします。

SELECT ename, salary FROM employee

この場合、すべての行が返されますが、manager に対応する行の salary の値は null になります。

同様に、同じユーザーが次のクエリを実行したとします。

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」ではない行のみが削除されます。

ロール¶

ロールは、ユーザーに付与できる一連のアクセス権限です。ユーザーに権限を割り当てるのではなくロールを割り当てると、権限を管理しやすくなるという利点があります。ロールの権限を変更した場合、その変更は対象のロールに「属する」すべてのユーザーに適用されます。ロールを使用しない場合は、各ユーザーの権限を編集する必要があります。

1 人のユーザーに複数のロールを割り当てることができます。その場合、そのユーザーの「有効なアクセス許可」は、各ロールによって割り当てられるアクセス許可の和集合になります。たとえば、ロール A が「admin」データベースに対する Execute 権限を付与し、ロール B が「tests」データベースに対する Execute 権限を付与する場合、ロール A とロール B を持つユーザーは、「admin」と「tests」の両方のデータベースに対する Execute 権限を持ちます。

さらに、ロールを他のロールに割り当てることもできます。これを「ロールの継承」と呼びます。たとえば、以下のロールを持っているとします。

データベース admin に対する CONNECT 、 EXECUTE 、 CREATE 、 WRITE の権限を持つロール vdp_developer
データベース itpilot に対する CONNECT 、 EXECUTE 、 CREATE 、 WRITE の権限を持つロール itpilot_developer

ロール denodo_developer を作成し、このロールにロール vdp_developer とロール itpilot_developer を割り当てることができます。この新しいロールを持つユーザーは、 admin と itpilot の両方のデータベースに対する CONNECT 、 EXECUTE 、 CREATE 、および WRITE の各権限を持ちます。

ロールに割り当て可能なアクセス許可は、ユーザーに割り当て可能な権限と同じです。

デフォルトのロール¶

Virtual DataPort には、以下のデフォルトのロールが定義されています。これらは、変更も削除もできません。

allusers: 新しいローカルユーザーにデフォルトで付与されます。さらに、Kerberos 認証または SAML 2.0 を使用して Virtual DataPort に接続するすべてのユーザー、または LDAP 認証を使用するデータベースに接続するすべてのユーザーに自動的に付与することができます。
create_temporary_table: 一時テーブルを作成する権限を付与します。これは、ユーザーアカウントに一時テーブルの作成を許可しながら、他のタイプのエレメントの作成は許可しない (CREATE 権限または CREATE VIEW 権限を付与しない) 場合に便利です。
diagnostic_monitoring_tool_admin および diagnostic_monitoring_tool_create_diagnostic: これらのロールはそれぞれ、Diagnostic & Monitoring Tool に対する異なる権限を付与します。これらのロールが付与する権限については、『Diagnostic & Monitoring Tool ガイド』の「認可」を参照してください。
data_catalog_admin 、 data_catalog_classifier 、 data_catalog_content_admin 、 data_catalog_editor 、 data_catalog_exporter 、および data_catalog_manager: これらのロールはそれぞれ、Data Catalog に対する異なる権限を付与します。これらの各ロールが付与する権限については、『Data Catalog ガイド』の「認可」を参照してください。

selfserviceadmin ロールと selfserviceexporter ロールは非推奨になっているため、今後はユーザーに付与しないでください。これらのロールは Denodo 6.0 との下位互換性を維持するために存在しています。代わりに、 data_catalog_admin ロールおよび data_catalog_exporter ロールを付与してください。これらはそれぞれ、 selfserviceadmin ロールおよび selfserviceexporter ロールと同等です。

非推奨のすべての機能のリストについては、「 Denodo Platform 8.0 で非推奨となった機能」のセクションを参照してください。
disable_cache_query: ユーザーが　WRITE 権限を付与されていない場合、ビューのキャッシュを無効にするクエリを実行する権限を付与します。このキャッシュは、CONTEXT 句 'cache'='off’ を使用して無効にすることができます。
impersonator: このロールを持つユーザーが REST Web サービスを公開する場合、サービスで他のユーザーを偽装できます (「Web サービスの認証」の「ユーザーの偽装」を参照)。
monitor_admin: Virtual DataPort の監視インターフェイスに接続する権限を付与します。このインターフェイスは、JMX (Java Management Extensions) プロトコルを使用します。

この権限は、Diagnostic & Monitoring Tool、Denodo Monitor、Oracle VisualVM、Oracle Java Mission Control、Nagios などで Virtual DataPort を監視するために必要です。

旧バージョンの Denodo では、このロールの名前は jmxadmin です。この名前は下位互換性を確保するために維持されています。
scheduler_admin: Scheduler Administration Tool で使用されます。このロールを割り当てられているユーザーは、Scheduler Administration Tool で任意のタスクを実行できます。

詳細については、『Scheduler 管理ガイド』の「アクセス許可」を参照してください。
serveradmin: JMX 経由で Virtual DataPort に接続する権限が付与されない点を除いて、Virtual DataPort の管理者ユーザーであることと同等です。つまり、このロールを持つユーザーは、データベースの管理、サーバーの設定の変更などを行うことができます。このロールを持つユーザーがユーザーとロールの権限を管理するには、「assignprivileges」ロール (下記参照) も必要です。
assignprivileges: 他のユーザーへの権限の付与/取り消しを行う権限を付与します。

注釈

このロールを持たないユーザーは、管理者であっても、ユーザーやロールに権限を付与したり、その権限を取り消したりすることはできません。

以下の点を考慮してください。
- 新しい管理者ユーザーはデフォルトでこのロールを持っていますが、それを取り消すことはできます。
- このロールに権限やロールを付与することはできません。このロールが [Role Management] パネルに表示されず、[Assign roles] ダイアログに表示されるのは、そのためです。
- このロールは、管理者、または少なくとも 1 つのデータベースの管理者であるユーザーにのみ割り当てることができます。
- このロールを持つ管理者以外のユーザーは、自身が管理者であるデータベースの権限のみを変更できます。
- ロールをユーザーや他のロールに付与したり、そのロールを取り消したりすることができるのは、このロールを持つ管理者だけです。
- ロールの説明を変更できるのは、このロールを持つ管理者だけです。
create_user および create_role: ユーザーとロールを作成する権限を付与します。

どちらのロールでも、以下の点を考慮してください。
- これらのロールは、1 つまたは複数のデータベースに対する ADMIN 権限を持つユーザーまたはロールにのみ割り当てることができます。
- これらのロールは、 assignprivileges ロールを持つユーザーまたはロールにのみ割り当てることができます。
- assignprivileges ロールが取り消された場合、これらの 2 つのロールは自動的に取り消されます。
- すべての ADMIN 権限が取り消された場合、これらの 2 つのロールは自動的に取り消されます。

USER MANUALS