データベース・サーバーに関連するデータおよびリソースを保護するために、 DB2 は、外部機密保護サービスと内部アクセス制御情報の組み合わせを使用します。 データベース・サーバーにアクセスするには、データベースのデータまたは リソースに対するアクセス権が与えられるまでに、いくつかの機密保護検査 にパスしなければなりません。 データベース機密保護の最初のステップは認証 と呼ばれ、 ユーザーは、自分が言っているとおりの人物であることを証明しなければなりません。 2 番目のステップは許可 と呼ばれ、そこでは、 検査されているユーザーについて、要求したアクションの実行または要求 したデータのアクセスが許されるかどうかを、データベース・マネージャー が判断します。
ユーザーの認証は、DB2 の外部の機密保護機能を使用して完了します。 機密保護機能は、オペレーティング・システムの一部であるか、別個の製品 であるか、または、場合によってはまったく存在しない場合があります。 UNIX ベースのシステムでは、機密保護機能は、 オペレーティング・システムそのものの中にあります。 DCE 機密保護サービスは、分散環境に対して機密保護機能を提供する別個の製品です。 Windows 95 または Windows 3.1 オペレーティング・システムには、機密保護機能はありません。
機密保護は、ユーザーを認証するのに 2 つの項目を必要とします。 それは、ユーザー ID とパスワードです。 ユーザー ID は、機密保護機能にユーザーを知らせます。 正しいパスワード (ユーザーおよび機密保護機能にのみ認識されている情報) を提供すれば、 ユーザーの身元 (ユーザー ID に対応) が検証されます。
認証された後、
DB2 は、最大 64 グループまでのグループのリストを取得します。 1 ユーザーが 64 グループを超えるグループのメンバーである場合、有効な DB2 許可名にマップされる最初の 64 グループだけが、DB2 グループ・リストに追加されます。 エラーは戻されず、最初の 64 グループより後のグループは、 すべて DB2 によって無視されます。
DB2 は、機密保護機能を使用して、以下の 2 つの方法のうちの 1 つでユーザーを認証します。
DB2 管理者は、プロファイル・レジストリー変数 DB2CHGPWD_EEE を使用して、 AIX および Windows NT EEE システム上で、 パスワードを変更する許可を他のユーザーに与えることができます。 この変数の省略時値は NOT SET (使用不可) です。 DB2CHGPWD_EEEは、他の DB2 プロファイル変数が使用する標準ブール値を受け入れます。
DB2 管理者は、すべてのノードのパスワードを、 Windows NT ドメイン・コントローラ (Windows NT の場合) または NIS (AIX の場合) を使って集中保守する責任があります。
注: | パスワードが集中保守されない場合、 DB2CHGPWD_EEE 変数を使用可能にすることによって、 パスワードがすべてのノードで一貫しなくなる可能性が生じます。 つまり、ユーザーが「パスワード変更」機能を使用すると、 ユーザーのパスワードが、接続しているノードでのみ変更されます。 |
DB2 UDB (AIX 版) では、オペレーティング・システムで失敗したパスワード入力をロギングし、 LOGINRETRIES パラメーターで指定されたログイン試行の許可回数をクライアントが超過したときを検出します。
データベースにアクセスしているリモート・クライアントがある場合に特に関係する、 システム項目の妥当性検査についての追加情報に関しては、 サーバーに対する認証方式の選択 を参照してください。
許可とは、それによって DB2 が、 認証された DB2 ユーザーに関する情報 (ユーザーが実行できるデータベース操作、 およびアクセスできるオブジェクトを示します) を取得するプロセスのことです。 それぞれのユーザー要求について、オブジェクトおよび関係する操作によっては、 複数の許可検査が行われる場合があります。
許可は、DB2 の機能を使用して実行されます。 それぞれの許可名に関連する許可事項を記録するために、 DB2 表と構成ファイルが使用されます。 認証ユーザーの許可名、およびそのユーザーが属しているグループの許可名が、 記録されている許可事項と比較されます。 この比較に基づいて、DB2 は、要求されたアクセスを許すかどうかを判断します。
DB2 によって記録された許可事項のタイプには、 「特権」と「権限レベル」の 2 つのタイプがあります。 特権 は、 1 ユーザーがデータベース・リソースを作成またはアクセスできるようにするために、 1 つの許可名に対して単一の許可事項を定義します。 特権は、データベース・カタログに保管されます。 権限レベル は、特権をグループ化する方法を 提供し、より高いレベルで、データベース・マネージャーの保守とユーティ リティー操作を制御します。 データベース固有の権限は、データベース・カタログに保管されます。 また、システム権限は、グループ・メンバーシップと関連付けられ、 特定のインスタンスについて、データベース・マネージャー構成ファイルの中に保管されます。
グループは、それぞれのユーザーに個別に特権の付与または取り消しを行うことを必要とせずに、 ユーザーの集合に対して許可を実行するための便利な手段を提供します。 特に異なる指定がなければ、グループ許可名は、許可名が許可の目的で使用 されるところであれば、どこでも使用することができます。 一般に、グループ・メンバーシップは、 動的 SQL およびデータベース以外のオブジェクト (インスタンス・レベルのコマンドおよびユーティリティーなど) の許可のためのものと考えられ、 静的 SQL のためのものとは考えられません。 この一般的なケースの例外は、 特権が PUBLIC に与えられるときに生じ、 この場合は 静的 SQL が処理されるときに考慮されます。 グループ・メンバーシップが適用されない特定のケースについては、DB2 の 資料全体を通して、該当する場合にその旨の注が付いています。
詳細については、 特権、権限、および許可 を参照してください。
DB2 連合データベース・システム (federated database system: 複数のデータベースから構成されるが、 単一のデータベース・イメージを提供するデータベース・システムを意味します) は複数のデータベース管理システムの情報にアクセスできるので、 データを保護するために付加的なステップが必要になる場合があります。
認証アプローチの計画時には、ユーザーが DB2 だけではなくデータ・ソースでも、 認証検査をパスする必要があるかもしれないということを考慮してください。 連合システムでは、DB2 クライアント・ワークステーション、DB2 サーバー、 データ・ソース (DB2、DB2 (OS/390 版)、他の DRDA サーバー、Oracle)、 または DB2 (クライアントまたは DB2 サーバー) とデータ・ソースの組み合わせにおいて、 認証が行われる可能性があります。 DCE 環境でも、データ・ソースにユーザー ID とパスワードが必要な場合、 特定のステップが必要になります。 詳細については、 統合データベースの認証処理 を参照してください。
同様に、ユーザーは、データ・ソースおよび DB2 で許可検査をパスする必要 があります。 各データ・ソース (DB2、Oracle、DB2 (OS/390 版) など) は、 その制御下でオブジェクトの機密保護を保守します。 ユーザーがニックネームに対して操作を実行する場合、 そのユーザーはニックネームが参照する表または視点に関する許可検査をパスする必要があります。