管理の手引き


特権、権限、および許可

特権 は、 ユーザーがデータベース・リソースを作成したりデータベース・リソースにアクセスしたりすることを許可するためのものです。 権限レベル によって、特権のグループ分けの方法、 およびより高いレベルのデータベース・マネージャーの保守とユーティリティー操作が得られます。 それらが一緒になって、 データベース・マネージャーとそのデータベース・オブジェクトへのアクセスを制御する働きをします。 ユーザーがアクセスできるのは、該当する許可、 つまり、必須の特権や権限を持っているオブジェクトに限られます。

権限には、次の種類があります。

特権には次の種類があります。

図 49 は、権限とその制御の範囲 (データベース、 データベース・マネージャー) の間の関係を示します。

図 49. 権限の階層


SQLD0AUT

ユーザーまたはグループは、次のレベルの権限許可を 1 つまたは複数持つことができます。

管理権限 (SYSADM または DBADM) または所有権特権 (CONTROL) を持ったユーザーは、 GRANT および REVOKE ステートメントを使用して、 他のユーザーとの間で特権の付与および取り消しを行うことができます。 (データベース・オブジェクトに対するアクセスの制御を参照。) 特権が WITH GRANT OPTION を使用して保持されているものである場合、 別のユーザーに、表、視点、またはスキーマの特権を付与することもできます。 ただし、WITH GRANT OPTION では、特権を付与する人が、 いったん付与した特権を取り消すことは許されません。 特権を取り消すためには、SYSADM 権限、DBADM 権限、 または CONTROL 特権を持っていなければなりません。

1 つのユーザーまたはグループに対して、 個々の特権または権限をいくつか組み合わせて許可することもできます。 特権をリソースに関連付ける場合、そのリソースは存在していなければなりません。 たとえば、表がそれ以前に作成されているのでなければ、 その表についての SELECT 特権をユーザーに与えることはできません。
注:ある許可名が権限と特権を与えられ、 しかもその許可名で作成されたユーザーがいない場合には、注意が必要です。 後で、その許可名を使用してユーザーが作成され、 その許可名に関連するすべての権限と特権を自動的に受け取る可能性があります。

特定のコマンド、API、または SQL コマンドについて、 どんな許可が必要かについては、コマンド解説書管理 API 解説書、 または SQL 解説書 を参照してください。

システム管理権限 (SYSADM)

SYSADM 権限は、最高レベルの管理権限です。 SYSADM 権限を与えられたユーザーは、ユーティリティーを実行したり、 データベースおよびデータベース・マネージャーのコマンドを発行したり、 データベース・マネージャー・インスタンス内のデータベースの表データにアクセスしたりできます。 この権限は、インスタンス内のすべてのデータベース・オブジェクトを制御します。 制御されるデータベース・オブジェクトには、データベース、表、視点、索引、 パッケージ、スキーマ、サーバー、別名、データ・タイプ、関数、プロシージャー、トリガー、 表スペース、ノードグループ、バッファー・プール、およびイベント・モニターがあります。

SYSADM 権限は、 sysadm_group 構成パラメーター (第 32 章, DB2 の構成を参照) によって指定されたグループに割り当てられます。 このグループのメンバーシップは、データベース・マネージャーの外で、 プラットフォームで使われている機密保護機能によって制御されます。 SYSADM 権限の作成、変更、または削除のためにシステム機密保護機能を 使用する方法については、概説およびインストール を参照してください。

SYSADM 権限を持つユーザーだけが実行できる機能は、次のとおりです。

さらに、SYSADM 権限を持つユーザーは、次の権限を持つユーザーの機能も実行できます。

注:SYSADM 権限を持つユーザーがデータベースを作成すると、そのユーザーには、 そのデータベースに対する明示的な DBADM 権限が自動的に付与されます。 データベースの作成者が SYSADM グループから除去され、 そのデータベースに DBADM としてアクセスすることも防止したい場合は、 この DBADM 権限を明示的に取り消さなければなりません。

システム制御権限 (SYSCTRL)

SYSCTRL 権限 は、最高レベルのシステム制御権限です。 この権限があると、データベース・マネージャーのインスタンスとそのデータベースに対して、 保守およびユーティリティー操作を実行することができます。 これらの操作はシステム・リソースに影響を及ぼす場合がありますが、 データベース内のデータに対するアクセスは認められていません。 システム制御権限は、 重要データの入ったデータベース・マネージャーのインスタンスを管理するユーザーを対象としたものです。

SYSCTRL 権限は、 sysctrl_group 構成パラメーター (第 32 章, DB2 の構成を参照) によって指定されたグループに割り当てられます。 グループを指定すると、そのグループに属するものは、 プラットフォーム上で使用される機密保護機能によって、 データベース・マネージャーの外で制御されます。

SYSCTRL 以上の権限を持つユーザーだけが実行できることは、次のとおりです。

さらに、SYSCTRL 権限を持つユーザーは、 システム保守権限 (SYSMAINT) 権限を持つユーザーの機能を実行できます。

SYSCTRL 権限を持つユーザーは、データベースへの接続に関する暗黙の特権も持っています。
注:SYSCTRL 権限を持つユーザーがデータベースを作成すると、そのユーザーには、 そのデータベースに対する明示的な DBADM 権限が自動的に付与されます。

データベースの作成者が SYSCTRL グループから除去され、 そのデータベースに DBADM としてアクセスすることも防止したい場合は、 この DBADM 権限を明示的に取り消さなければなりません。

システム保守権限 (SYSMAINT)

SYSMAINT 権限は、2 番目のレベルのシステム制御権限です。 この権限があると、データベース・マネージャーのインスタンスとそのデータベースに対して、 保守およびユーティリティー操作を実行することができます。 これらの操作はシステム・リソースに影響を及ぼす場合がありますが、 データベース内のデータに対するアクセスは認められていません。 システム保守権限は、重要データの入ったデータベース・マネージャーのインスタンス内のデータベースを保守するユーザーを対象としています。

SYSMAINT 権限は、 sysmaint_group 構成パラメーター (第 32 章, DB2 の構成を参照) によって指定されたグループに割り当てられます。 グループを指定すると、そのグループに属するものは、 プラットフォーム上で使用される機密保護機能によって、 データベース・マネージャーの外で制御されます。

SYSMAINT 以上の権限を持つユーザーだけが実行できることは、次のとおりです。

SYSMAINT、DBADM、またはそれ以上の権限を持つユーザーは、次のことを実行できます。

SYSMAINT 権限を持つユーザーは、データベースへの接続に関する暗黙の特権も持っています。

データベース管理権限 (DBADM)

DBADM 権限は、2 番目にレベルの高い管理権限です。 この権限は特定のデータベースにのみ適用され、ユーザーは、 特定のユーティリティーを実行し、データベース・コマンドを出し、 そしてデータベース内のどの表のデータにもアクセスすることができます。 DBADM 権限が付与されると、BINDADD、 CONNECT、CREATETAB、CREATE_NOT_FENCED、および IMPLICIT_SCHEMA 特権も付与されます。 SYSADM 権限を持つユーザーだけが DBADM 権限の付与または取り消しを行えます。 DBADM 権限を持つユーザーは、データベースについての特権を他のユーザーに付与できます。 また、だれが特権を付与したかにかかわりなく、ユーザーの特権を取り消すこともできます。

DBADM 以上の権限を持つユーザーだけが実行できることは、次のとおりです。

DBADM、SYSMAINT、またはそれ以上の権限を持つユーザーは、次のことを実行できます。

注:DBADM によって上記の機能を実行できるのは、 DBADM 権限が与えられているデータベースに対してだけです。

LOAD 権限

表に対する INSERT 特権の他に、 データベース・レベルでの LOAD 権限も持っているユーザーは、 LOAD コマンドまたは AutoLoader ユーティリティーを使用して、 データを表にロードすることができます。

表に対する INSERT 特権の他に、 データベース・レベルでの LOAD 権限も持っているユーザーは、 直前のロード操作でデータを挿入するロードを行った場合に、 LOAD RESTART または LOAD TERMINATE を行うことができます。

直前のロード操作でロード置換を行った場合、 ユーザーは、DELETE 特権が許可されていないと、 LOAD RESTART または LOAD TERMINATE を行うことができません。

LOAD の一部として例外表が使用される場合、 ユーザーには、その例外表に対する INSERT 特権が必要です。

この権限を持っているユーザーは、 QUIESCE TABLESPACES FOR TABLE、RUNSTATS、 および LIST TABLESPACES コマンドを実行することができます。

データベースの特権

図 50 は、データベースの特権を示します。

図 50. データベースの特権


SQLD0DBP

データベースの特権には、データベース全体に対するアクションが関係しています。

他のユーザーに特権を付与したり他のユーザーから特権を取り消したりすることができるのは、 SYSADM または DBADM 権限を持つユーザーだけです。
注:データベース作成時に、以下の特権が自動的に PUBLIC に付与されます。
  • CREATETAB
  • BINDADD
  • CONNECT
  • IMPLICIT_SCHEMA
  • USERSPACE1 表スペースに対する USE 特権
  • システム・カタログ視点上での SELECT 特権

特権を除去するためには、 DBADM または SYSADM が明示的に PUBLIC から特権を取り消さなければなりません。

暗黙スキーマ権限 (IMPLICIT_SCHEMA) の考慮事項

新しいデータベースが作成されるとき、 またはデータベースが以前のリリースから移行されるときに、 PUBLIC に IMPLICIT_SCHEMA データベース権限が与えられます。 この権限を使用して、どのユーザーも、オブジェクトを作成し、 すでに存在していないスキーマ名を指定することによって、 スキーマを作成することができます。 SYSIBM が暗黙に作成されたスキーマの所有者になり、 PUBLIC にこのスキーマ内にオブジェクトを作成するための特権が与えられます。

だれが暗黙にスキーマ・オブジェクトを作成できるかを制御することがデータベースで必要な場合は、 IMPLICIT_SCHEMA データベース権限を PUBLIC から取り消す必要があります。 いったんこれを行うと、スキーマ・オブジェクトが作成される方法は、以下の 3 つしかありません。

ユーザーは、自分自身の許可名を使用して、 自分自身のスキーマを明示的に作成する能力を常に持っています。

スキーマの特権

スキーマ特権は、オブジェクト特権区分に入ります。 オブジェクト特権は、図 51 に示されています。

図 51. オブジェクト特権


SQLD0OBJ

スキーマの特権には、データベース内のスキーマ上でのアクションが含まれます。 ユーザーには、以下の特権のどれでも付与することができます。

スキーマの所有者は、これらの特権をすべて持ち、 その特権を他のユーザーに付与する能力を持ちます。 スキーマ・オブジェクト内で操作されるオブジェクトには、表、視点、索引、 パッケージ、データ・タイプ、関数、トリガー、プロシージャー、および別名があります。

表スペース特権

表スペース特権は、 データベースの表スペースに対してアクションを実行することを可能にします。 表スペースの USE 特権を付与されたユーザーは、 その表スペース内で表を作成できます。

表スペースの所有者 (多くの場合、 SYSADM または SYSCTRL 権限を持っている作成者) は USE 特権を持っており、 他のユーザーにこの特権を付与することができます。 デフォルトでは、 データベースの作成時に、 表スペース USERSPACE1 に関する USE 特権が PUBLIC に付与されますが、 この特権は取り消すこともできます。

USE 特権は、 SYSCATSPACE またはシステム一時表スペースでは使用できません。

表および視点の特権

表および視点の特権には、 データベース内の表や視点に対するアクションが関係しています。 次に挙げる特権のいずれかを使用するユーザーには、 データベースについての CONNECT 特権が必要です。

GRANT ステートメントの WITH GRANT OPTION を使用して、 これらの特権を他のユーザーに付与する特権を付与することもできます。
注:ユーザーまたはグループが、ある表の CONTROL 特権を付与された場合、 その表に対する他のすべての特権は、自動的に WITH GRANT OPTION によって付与されます。 その後、表に対する CONTROL 特権をユーザーから取り消しても、 そのユーザーは自動的に付与された他の特権を依然として持っています。 CONTROL 特権と一緒に付与された特権をすべて取り消す場合は、 特権を個別に明示的に取り消すか、 または REVOKE ステートメントに ALL キーワードを指定しなければなりません。 以下にその例を示します。

   REVOKE ALL
     ON EMPLOYEE FROM USER HERON

タイプ付き表を処理しているときには、表および視点の特権に関連した含意があります。
注:特権は、表階層の各レベルで別々に授与されます。 その結果、タイプ付き表の階層内のスーパー表で特権を授与されたユーザーは、 副表にも間接的に影響を与えることがあります。 しかし、その副表で必要な特権が保持されている場合は、 ユーザーは副表に対する操作を直接的にしか行えません。

表階層の表の間のスーパー表 / 副表関係は、SELECT、UPDATE、および DELETE などの操作が、 操作のターゲット表とそのすべての副表 (もしあれば) の行に影響を与えることを意味します。 この性質を"代替性"と呼ぶことができます。 たとえば、タイプ Manager_t の副表マネージャーを使用して、 タイプ Employee_t の Employee 表を作成したとします。 構造型 Employee_t と Manager_t 間のタイプ / サブタイプ関係、 また表 Employee と Manager 間の対応する表 / 副表関係によって示されているとおり、 マネージャーはある種の (特殊な) 従業員です。 この関係の結果、次の SQL 照会は、

   SELECT * FROM Employee

従業員とマネージャー両方のオブジェクト識別子と Employee_t 属性を戻します。 同様に、次の更新操作は、

   UPDATE Employee SET Salary = Salary + 1000

マネージャーと従業員の給与を 1000 ドル引き上げます。

Employee で SELECT 特権を持つユーザーは、 Manager で明示的な SELECT 特権を持っていなくても、この SELECT 操作を実行できます。 しかし、そのようなユーザーは、 Manager 副表に対して SELECT 操作を直接実行することは許可されませんので、 Manager 表の継承されたのではない列にアクセスすることはできません。

同様に、Employee で UPDATE 特権を持つユーザーは、 Manager 表で明示的な UPDATE 特権がなくても、 Employee に対して UPDATE 操作を実行できるので、 正規の従業員とマネージャー両方に影響を与えます。 しかし、そのようなユーザーは、 Manager 副表に対して UPDATE 操作を直接実行することは許可されませんので、 Manager 表の継承されたのではない列を更新することはできません。

特定のコマンド、API、または SQL ステートメントの実行に必要な権限許可については、 次のマニュアルを参照してください。

カタログ統計の更新に必要な許可については、第 24 章, システム・カタログ統計を参照してください。

視点の特権が決定される方法については、 SQL 解説書 の CREATE VIEW ステートメントの説明を参照してください。

ニックネームの特権

ニックネームの特権には、データベース内のニックネーム上でのアクションが含まれます。 これらの特権は、ニックネームが参照するデータ・ソース・オブジェクト上の特権には影響しません。 次に挙げる特権のいずれかを使用するユーザーには、 データベースについての CONNECT 特権が必要です。

GRANT ステートメントの WITH GRANT OPTION を使用して、 これらの特権を他のユーザーに付与する特権を付与することもできます。
注:ユーザーまたはグループが、あるニックネームの CONTROL 特権を付与された場合、 そのニックネームに対する他のすべての特権は、自動的に WITH GRANT OPTION によって付与されます。 その後、ニックネームに対する CONTROL 特権をユーザーから取り消しても、 そのユーザーは自動的に付与された他の特権を依然として持っています。

データ・ソースのデータにアクセスするには、 ニックネームが参照するデータ・ソースにあるオブジェクトについての適切な許可もなければなりません。

ユーザーが 1 つ以上のニックネームを参照する視点にアクセスする場合、 ユーザーにはデータ・ソースでニックネームが参照する視点とオブジェクトにアクセスする権限がなければなりません。

サーバー特権

PASSTHRU というサーバー特権があります。 この特権は、 DDL および DML ステートメントを直接 (パススルー操作) データ・ソースに発行する、 許可 ID を制御します。

DB2 は 2 つの SQL ステートメントを提供してパススルー操作を制御します。

パススルー権限をサーバー ORACLE1 のユーザー SHAWN に付与するサンプル・ステートメントを次に示します。

   GRANT PASSTHRU ON SERVER ORACLE1 TO USER SHAWN

PASSTHRU ステートメントの構文に関する詳細は、SQL 解説書 を参照してください。

パッケージの特権

パッケージとは、データベース・オブジェクトの 1 つで、データベース・マネージャーが、 特定のアプリケーション・プログラムにとって最も効率的な方法でデータにアクセスするのに必要な情報が入れられたものです。 パッケージの特権を与えられたユーザーは、パッケージの作成と操作を行えます。 次に挙げる特権のいずれかを使用するユーザーには、 データベースについての CONNECT 特権が必要です。

これらのパッケージ特権に加えて、BINDADD データベース特権によって、 ユーザーは、データベース内に新しいパッケージを作成するか、 または既存のパッケージを再バインドすることができます。

ニックネームを含むパッケージを実行する権限のあるユーザーには、 パッケージ内で付加的な特権またはニックネームの権限レベルは必要ありません。 ただし、ニックネームが参照するオブジェクトを含むデータ・ソースで、 認証検査をパスする必要があります。 さらに、パッケージ・ユーザーには、 データ・ソースにあるデータ・ソース・オブジェクトについての適切な特権、 または権限レベルが必要です。

DB2 ファミリーのデータ・ソースを使って通信するときに DB2 が動的 SQL を使用するため、 ニックネームを含むパッケージが付加的な許可ステップを必要とする可能性があります。 データ・ソースでパッケージを実行する許可 ID には、 そのデータ・ソースでパッケージを動的に実行するための適切な権限が必要です。 DB2 が静的および動的 SQL を処理する方法についての詳細は、 SQL 解説書 を参照してください。

索引の特権

索引または索引の指定の作成者には、索引についての CONTROL 特権が自動的に与えられます。 索引の CONTROL 特権は、実際には、索引を除去するための能力です。 ある索引の CONTROL 特権を付与するためには、 そのユーザーには SYSADM または DBADM 権限が必要です。

表レベルの INDEX 特権を使うと、表に関する索引を作成できます (表および視点の特権を参照)。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]