管理の手引き


データベース・オブジェクトに対するアクセスの制御

データベース・アクセスを制御するには、 直接および間接の特権、管理権限、およびパッケージについての理解が必要です。 この部分ではそうした点について説明し、いくつかの例を挙げます。

直接付与される特権は、システム・カタログに格納されます。 データベース・アクセス制御計画の実施を監査する方法については、 システム・カタログの使用を参照してください。

権限許可を制御する方法には、次の 3 通りのものがあります。

この部分では、次の点について説明します。

特権の付与

GRANT ステートメントは、 許可されたユーザーが特権を付与することができるようにするものです。 特権は、1 つのステートメントで、1 つ以上の許可名に付与するか、あるいは、 特権をすべてのユーザーが使用可能なようにする PUBLIC に付与することができます。 許可名は、個別のユーザーかまたはグループのいずれかにすることができることに注意してください。

オペレーティング・システムに同じ名前のユーザーとグループがある場合、 ユーザーとグループのどちらに特権を付与するのかを指定する必要があります。 GRANT および REVOKE ステートメントのどちらにおいても、 USER および GROUP というキーワードがサポートされています。 これらの任意選択のキーワードが使用されないと、 データベース・マネージャーはオペレーティング・システムの機密保護機能をチェックして、 その許可名がユーザーであるかグループであるかを判別します。 許可名がユーザーとグループの両方である可能性がある場合、エラーが戻されます。

次の例は、HERON というユーザーに対して、 EMPLOYEE 表についての SELECT 特権を付与するものです。

   GRANT SELECT
      ON EMPLOYEE TO USER HERON

次の例は、HERON というグループに対して、 EMPLOYEE 表についての SELECT 特権を付与するものです。

   GRANT SELECT
      ON EMPLOYEE TO GROUP HERON

ほとんどのデータベース・オブジェクトに対する特権を付与するには、 ユーザーがそのオブジェクトに対する SYSADM 権限、DBADM 権限、または CONTROL 特権を持つか、 またはそのユーザーが WITH GRANT OPTION 特権を保持していなければなりません。 特権を付与できるのは既存のオブジェクトについてだけです。 だれかに CONTROL 特権を付与するためには、SYSADM または DBADM 権限が必要です。 DBADM 権限を付与するには、SYSADM 権限が必要です。

GRANT ステートメントの詳細については、SQL 解説書 を参照してください。

特権の取り消し

REVOKE ステートメントは、許可されたユーザーが、 他のユーザーに付与されている特権を取り消すことができるようにするためのものです。 データベース・オブジェクトについての特権を取り消すには、DBADM 権限、 SYSADM 権限、またはそのオブジェクトについての CONTROL 特権が必要です。 WITH GRANT OPTION 特権を保持しているだけでは、 その特権を取り消すには十分でないことに注意してください。 他のユーザーの CONTROL 特権を取り消すには、SYSADM または DBADM 権限が必要です。 DBADM 権限を取り消すには、SYSADM 権限が必要です。 特権を取り消すことができるのは、既存のオブジェクトについてだけです。
注:表または視点に対する DBADM 権限または CONTROL 特権を持っていないユーザーは、 WITH GRANT OPTION を使用して付与された特権を取り消すことはできません。 また、取り消された人から付与された特権を受け取っているユーザーに対する取り消しには、 連鎖はありません。 特権の取り消しに必要な権限の詳細については、 SQL 解説書 を参照してください。

同じ名前のユーザーとグループの両方に特権が付与されている場合、 特権を取り消す時に、GROUP と USER キーワードのどちらかを指定する必要があります。 次の例は、HERON というユーザーの EMPLOYEE 表についての SELECT 特権を取り消すものです。

   REVOKE SELECT
     ON EMPLOYEE FROM USER HERON

次の例は、HERON というグループの EMPLOYEE 表についての SELECT 特権を取り消すものです。

   REVOKE SELECT
      ON EMPLOYEE FROM GROUP HERON

1 つのグループから特権を取り消しても、 そのグループに属するすべてのメンバーからその特権が取り消されるとは限らないことに注意してください。 個別の名前が特権を直接付与されている場合は、その特権が直接取り消されるまで保持されます。

表特権がユーザーから取り消される場合、 取り消された表特権に依存するそのユーザーによって作成されたすべての視点に対する特権も取り消されます。 ただし、システムによって暗黙に付与された特権のみが取り消されます。 視点についての特権が別のユーザーによって直接付与された場合、 その特権は引き続き保持されます。

明示的に付与された表 (または視点) についての特権が DBADM 権限によってユーザーから取り消される場合、 その表に定義されている他の視点についての特権は取り消されることはありません。 視点についての特権は DBADM 権限によって使用可能になるものであり、 基礎表の明示特権とは関係ないからです。

1 つ以上の基礎となる表または視点に基づいて視点を定義しており、 それらの基礎となる表または視点の 1 つ以上に対する SELECT 特権を失った場合、 その視点は使用できません。
注:表または視点に対する CONTROL 特権がユーザーから取り消された場合でも、 そのユーザーは、その特権を他のユーザーに付与する能力は持ち続けます。 CONTROL 特権が与えられると、 そのユーザーは他の WITH GRANT OPTION 特権もすべて受け取ります。 CONTROL が取り消されても、他の特権のすべては、それらが明示して取り消されるまで、 WITH GRANT OPTION のまま残されます。

取り消された特権に依存しているすべてのパッケージは無効とみなされますが、 十分な権限を持つユーザーによって再バインドされるなら再び有効になります。 特権が後で再びアプリケーションをバインドしたユーザーに付与される場合、 パッケージも再作成することができます。そのアプリケーションを実行すると、 暗黙の再バインドが正常に実行されるトリガーとなります。 特権が PUBLIC から取り消された場合、 PUBLIC 特権に基づいたバインドしかできないユーザーによってバインドされていたすべてのパッケージが無効にされます。 ユーザーの持つ DBADM 権限が取り消されると、 そのユーザーによってバインドされたパッケージはすべて無効になります。 データベース・ユーティリティーに関連するパッケージも例外ではありません。 無効のマークが付けられているパッケージを使用しようとすると、システムは、 そのパッケージの再バインドを試みます。 この再バインドの試みが失敗すると、エラー (SQLCODE -727) が発生します。 この場合、それらのパッケージを明示的に再バインドするには、以下の権限が必要です。

そうしたパッケージの再バインドは、特権を取り消す時に行うべきです。 REVOKE および REBIND PACKAGE ステートメントの詳細については、 SQL 解説書 を参照してください。

1 つ以上の特権に基づいてトリガーを定義しており、 それらの特権のうちの 1 つ以上を失った場合、そのトリガーは使用できません。

オブジェクトの作成と除去による暗黙許可の管理

データベース・マネージャーは、CREATE SCHEMA、CREATE TABLESPACE、CREATE TABLE、CREATE VIEW、 または CREATE INDEX ステートメントを出すユーザー、 あるいは PREP または BIND コマンドを使用して新しいパッケージを作成するユーザーに対して、 暗黙に特定の特権を付与します。 特権は、SYSADM または DBADM 権限を持つユーザーによってオブジェクトが作成されるときにも付与されます。 同じように、オブジェクトを除去すると特権は除去されます。

作成されるオブジェクトが表スペース、表、索引、パッケージの場合、 ユーザーにはそのオブジェクトについての CONTROL 特権が与えられます。 オブジェクトが視点の場合、その視点についての CONTROL 特権が暗黙のうちに付与されるのは、 その視点定義の中で参照されるすべての表と視点についての CONTROL 特権を持っている場合に限られます。

明示して作成されたオブジェクトがスキーマである場合、そのスキーマの所有者には、 WITH GRANT OPTION によって ALTERIN、CREATEIN、および DROPIN 特権が与えられます。 暗黙に作成されたスキーマは、PUBLIC に付与された CREATEIN 特権を持ちます。

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

プランまたはパッケージの所有権の確立

BIND および PRECOMPILE コマンドは、アプリケーション・パッケージを作成または変更します。 どちらのコマンドでも、 OWNER オプションを使って結果パッケージの所有者の名前を付けてください。 パッケージの所有者の命名には、単純ルールがあります。

DB2 データベース製品を使用するパッケージをバインドできる、 すべてのオペレーティング・システムが OWNER オプションをサポートしているわけではありません。

BIND および PRECOMPILE コマンドの詳細については、コマンド解説書 を参照してください。

パッケージによる間接特権の許可

データベース内のデータに対するアクセス要求は、アプリケーション・プログラムによって、 また、対話式ワークステーション・セッションに関係しているユーザーによって行えます。 パッケージに含まれているステートメントによって、 ユーザーは多数のデータベース・オブジェクトに対して様々なアクションを実行できます。 そうしたアクションにはそれぞれ特権が必要です。

パッケージをバインドしている個別ユーザーに付与された特権、 および PUBLIC に付与された特権は、 静的 SQL がバインドされるときの許可検査のために使用されます。 グループを通して付与された特権は、 静的 SQL がバインドされるときの許可検査のためには使用されません。 有効な authID を持っており、 パッケージをバインドするユーザーは、 パッケージのバインド時に VALIDATE RUN が指定されている場合を除いて、 そのパッケージ内の静的 SQL ステートメントを実行するために必要なすべての特権を明示的に付与されているか、 あるいは PUBLIC を通して必要な特権が暗黙に付与されているかのいずれかでなければなりません。 BIND 時に VALIDATE RUN を指定すると、 そのパッケージ内のどの静的 SQL ステートメントに許可の障害が発生したとしても、 BIND は失敗せず、 その SQL ステートメントは実行時に再び有効になります。 ユーザーがパッケージをバインドするための、 適切な許可 (BIND または BINDADD 特権) を持っているようにするための検査を行う場合には、 PUBLIC、グループ、およびユーザーの特権がすべて使用されます。

パッケージには、静的 SQL および動的 SQL の両方を含めることができます。 静的 SQL を含むパッケージを処理する場合、 ユーザーに必要なのはパッケージについての EXECUTE 特権だけです。 したがってそのユーザーは、 パッケージ内の静的 SQL に対するパッケージ・バインダーの特権を間接的に取得することができます。 ただし、これはパッケージによって課される制限の範囲内に限られます。

動的 SQL を含むパッケージを処理する場合、 ユーザーは、そのパッケージに対する EXECUTE 特権を持っていなければなりません。 ユーザーは、そのパッケージの EXECUTE 特権に加えて、 そのパッケージ内の動的 SQL ステートメントを実行するためのすべての特権を必要とします。 パッケージ内のすべての静的 SQL に対しては、バインダーの権限と特権が使用されます。

ニックネームを含むパッケージによる間接特権の許可

パッケージにニックネームへの参照が含まれる場合、 パッケージ作成者およびパッケージ・ユーザーの許可処理はもう少し複雑です。 パッケージ作成者が、ニックネームを含むパッケージを正常にバインドする場合、 パッケージ作成者は、ニックネームがデータ・ソースで参照する表および視点に関して、 許可検査または特権検査をパスする必要はありません。 しかし、パッケージの実行者は、 データ・ソースで認証および許可検査をパスすることが必要です。

たとえば、パッケージ作成者の .SQC ファイルに、 複数の SQL ステートメントが入っているとします。 1 つの静的ステートメントはローカル表を参照します。 別の動的ステートメントはニックネームを参照します。 パッケージがバインドされると、 ローカル表の特権を検証するためにパッケージ作成者の許可 ID が使用されます。 しかし、ニックネームが識別するデータ・ソース・オブジェクトに関しては何も検査されません。 別のユーザーが、そのパッケージ用の EXECUTE 特権があることを前提としてパッケージを実行する場合、 そのユーザーは表を参照するステートメントへの付加的な特権検査をパスする必要はありません。 しかし、ニックネームを参照するステートメントの場合は、 パッケージを実行するユーザーはデータ・ソースで認証検査と特権検査をパスすることが必要です。

.SQC ファイルにすべての動的 SQL ステートメントと、 表とニックネームの参照が混ざったものが入っている場合、 ローカル・オブジェクトとニックネームへの DB2 許可検査は同じです。 パッケージ・ユーザーは、ステートメント内のすべてのローカル・オブジェクト (表、 視点) に関する特権検査をパスしなければならず、 さらにニックネーム・オブジェクトの特権検査もパスする必要があります (パッケージ・ユーザーは、 ニックネームが識別するオブジェクトを含むデータ・ソースで認証および特権検査をパスしなければなりません)。 どちらの場合も、パッケージのユーザーには EXECUTE 特権が必要です。

パッケージの ID およびパスワードは、すべてのデータ・ソース認証、 および特権処理に使用されます。 この情報は、ユーザー・マッピングの作成によって変更できます。
注:ニックネームは、静的 SQL では指定できません。 DYNAMICRULES オプション (BIND に設定) を、ニックネームを含むパッケージで使用しないでください。

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

視点によるデータへのアクセスの制御

視点を使うと、次のようにして、表に対するアクセス制御や特権付与が行えます。

視点を作成するには、SYSADM 権限、DBADM 権限、または、 その視点定義の中で参照する各表または各視点についての CONTROL 特権あるいは SELECT 特権が必要です。 ユーザーは、その視点用に指定されたスキーマ内に、 オブジェクトを作成することもできなければなりません。 つまり、スキーマがまだ存在していなければ、 既存のスキーマに対する CREATEIN 特権、または、 データベースに対する IMPLICIT_SCHEMA 権限が必要です。 詳細は、 視点の作成を参照してください。

ニックネームを参照する視点を作成している場合、 視点でニックネームが参照するデータ・ソース・オブジェクト (表と視点) で付加的な権限が必要になることはありません。 しかし、ユーザーには視点へのアクセス時に基礎となるデータ・ソース・オブジェクト用に、 SELECT 権限または同等の権限レベルが必要です。

ユーザーに、基礎となるオブジェクト (表および視点) に対してデータ・ソースでの適切な権限がない場合、次のことを実行できます。

その後、新しいニックネームを参照する SELECT ステートメントを発行することによって、 列にアクセスすることができます。

以下のシナリオは、情報へのアクセスを制限するために、 視点を使用する方法をより詳細に示した例です。

次のようなさまざまな理由から、STAFF 表の情報にアクセスする必要のある人が多いとします。 次に例を示します。

監査機能を使用したデータ・アクセスのモニター

DB2 監査機能は、一連の事前定義データベースのイベントに対して監査証跡を生成し、 かつその監査証跡を維持できるようにします。 データへのアクセスを妨げる機能ではありませんが、 監査機能はデータ・オブジェクトをアクセスまたは変更しようとした試みの記録をモニターかつ保持することができます。

SYSADM 権限は、監査機能の管理者ツール db2audit を使用するのに必須です。

DB2 監査機能の詳細記述については、第 17 章, DB2 アクティビティーの監査を参照してください。


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