アプリケーション開発の手引き

許可についての考慮事項

許可 を与えられたユーザーまたはグループは、データベースへの接続、表の作成、システムの管理などの一般的なタスクを実行できます。 特権 を付与されたユーザーやグループは、特定の方法で特定のデータベースにアクセスできます。 DB2 は、保管された情報を保護するために特権のセットを使用します。さまざまな特権の詳細については、 管理の手引き: 計画 を参照してください。

大部分の SQL ステートメントは、ステートメントが使用するデータベース・オブジェクトに対する何らかのタイプの特権を必要とします。ほとんどの API 呼び出しは、通常データベース・オブジェクトに対するいかなる特権も必要としませんが、権限を持っていないと呼び出すことができないものが多くあります。 DB2 API を使用すると、アプリケーション・プログラムから DB2 の管理機能を実行できます。たとえば、データベース内にバインド・ファイルの必要ないパッケージを作成するには、 sqlarbnd (または REBIND) API を使用できます。各 DB2 API の詳細については、管理 API 解説書 を参照してください。

各 SQL ステートメントを発行するために必要な特権については、 SQL 解説書 を参照してください。各 API 呼び出しを発行するために必要な特権および権限については、 管理 API 解説書 を参照してください。

アプリケーションを設計する際に、ユーザーがアプリケーションを実行するために必要な特権を考慮する必要があります。ユーザーが必要とする特権は、以下によって決まります。

動的 SQL

DYNAMICRULES RUN (省略時値) でバインドされたパッケージで動的 SQL を使用するには、動的 SQL アプリケーションを実行するユーザーが、パッケージに対する EXECUTE 特権だけでなく、実行する各 SQL 要求の発行に必要な特権も持っていなければなりません。ユーザーの許可 ID、ユーザーがメンバーとなっているグループ、または PUBLIC に対して特権を付与することができます。

DYNAMICRULES BIND オプションを指定してアプリケーションをバインドする場合は、許可 ID とアプリケーション・パッケージが関連付けられます。これにより、アプリケーションを実行するどのユーザーでも、その許可 ID に関連付けられた特権を継承することができます。

アプリケーション (組み込み動的 SQL アプリケーションの場合) をバインドする場合は、プログラムに静的 SQL が含まれていなければ、必要になるのはデータベースに対する BINDADD 権限だけです。この特権も、ユーザーの許可 ID、ユーザーがメンバーとなっているグループ、または PUBLIC に対して付与することができます。

DYNAMICRULES BIND オプションを指定して動的 SQL パッケージをバインドする場合、アプリケーションを実行するユーザーにはパッケージに対する EXECUTE 特権だけが必要です。 DYNAMICRULES BIND オプションを指定して動的 SQL アプリケーションをバインドするには、そのアプリケーションですべての動的および静的 SQL ステートメントを実行するのに必要な特権を持っている必要があります。 SYSADM または DBADM 権限を持っており、 DYNAMICRULES BIND オプションを指定してパッケージをバインドする場合は、 OWNER BIND オプションを使って異なる許可 ID を指定することを考慮してください。 OWNER BIND オプションを使用すると、動的 SQL ステートメントに対する SYSADM または DBADM 特権を、パッケージが自動的に継承しないようにすることができます。 DYNAMICRULES BIND および OWNER BIND オプションの詳細については、 コマンド解説書 の BIND コマンドの節を参照してください。

静的 SQL

静的 SQL は、アプリケーションを実行しているユーザーがパッケージに対する EXECUTE 特権を持っていれば使用できます。パッケージを構成するそれぞれのステートメントに対する特権は必要ありません。 EXECUTE 特権は、ユーザーの許可 ID、ユーザーがメンバーとなっているグループ、または PUBLIC に対して付与することができます。

アプリケーションをバインドするときに VALIDATE RUN オプションを指定しない場合は、アプリケーションのバインドに使用する許可 ID に、アプリケーション内にあるすべてのステートメントを実行できるだけの権限が必要です。 BIND 時に VALIDATE RUN を指定した場合は、このパッケージ内にある静的 SQL に関連してどのような許可障害が発生しても BIND は成功し、その中にあるステートメントの妥当性は実行時に再び検査されます。アプリケーションをバインドするためには、BINDADD 権限が必要です。ステートメントを実行するのに必要な特権は、ユーザーの許可 ID または PUBLIC に付与するようにしてください。静的 SQL ステートメントをバインドする際には、グループ特権は使用しません。動的 SQL の場合と同様に、BINDADD はユーザーの許可 ID、ユーザーがメンバーとなっているグループ、または PUBLIC に対して付与することができます。

上述の静的 SQL の特性により、DB2 にある情報のアクセスを正確に制御できます。このことを実行できるアプリケーションについては、この節の最後の例を参照してください。

API の使用

DB2 が提供する API の大部分は特権を使用する必要がありませんが、呼び出しに何らかの権限を必要とするものが多くあります。特権が必要ない API の場合は、アプリケーションを実行しているユーザーに特権を付与しなければなりません。特権は、ユーザーの許可 ID、ユーザーがメンバーとなっているグループ、または PUBLIC に対して付与することもできます。各 API 呼び出しを発行するために必要な特権および権限については、 管理 API 解説書 を参照してください。

STAFF 表に対する照会を行う必要のある 2 名のユーザー、PAYROLL と BUDGET があるとします。 PAYROLL は会社の従業員の給与支払いを管理しており、給与支払い小切手を出す際に、さまざまな SELECT ステートメントを発行する必要があります。 PAYROLL は各従業員の給与にアクセスできなければなりません。 BUDGET は、給与の支払いにいくら必要であるかの決定を管理しています。しかし、BUDGET が個々の従業員の給与を見ることはできないようにしておかなければなりません。

PAYROLL がさまざまな SELECT ステートメントを発行しているため、 PAYROLL 用に設計されたアプリケーションは、動的 SQL を使用することになるでしょう。そのため、PAYROLL には STAFF 表に対する SELECT 特権が必要になります。 PAYROLL はどうしてもこの表すべてをアクセスする必要があるので、 SELECT 特権を付与することに問題はありません。

一方 BUDGET は、個々の従業員の給与にアクセスさせてはなりません。つまり、STAFF 表に対する SELECT 特権を BUDGET に付与してはならないということです。 BUDGET は STAFF 表全体の給与の合計にアクセスする必要があるので、 SELECT SUM (SALARY) FROM STAFF を実行するための静的 SQL アプリケーションを作成してバインドし、このアプリケーションのパッケージに対する EXECUTE 特権を BUDGET に付与することができます。これにより BUDGET は、アクセスしてはならない情報を使用せずに必要な情報を取得できます。


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