管理の手引き


サーバーに対する認証方式の選択

インスタンスまたはデータベースにアクセスするためには、まず、 そのユーザーが認証 されていることが必要です。 各インスタンスの認証タイプ によって、 ユーザーを検査する方法と場所が決まります。 認証タイプは、サーバーのデータベース・マネージャー構成ファイルに保管されます。 認証タイプは、インスタンスの作成時に初期設定されます。 このデータベース・マネージャー構成パラメーターについての詳細は、 第 32 章, DB2 の構成を参照してください。 インスタンスごとに 1 つの認証タイプがあり、それが、 そのデータベース・サーバーおよびその制御下のすべてのデータベースのアクセスをカバーしています。

統合データベースからデータ・ソースにアクセスしたい場合、 データ・ソース認証処理および統合認証タイプの定義を考慮する必要があります。 詳細については、統合データベースの認証処理を参照してください。

以下の認証タイプがあります。

SERVER

ローカルのオペレーティング・システムの機密保護を使用して、 サーバー上で認証が行われることを指定します。 接続が試みられているときにユーザー ID およびパスワードが指定されると、 それらがサーバーにある有効なユーザー ID とパスワードの組み合わせと比較され、 そのユーザーがそのインスタンスへのアクセスを許されているかどうかが判別されます。 これが省略時の機密保護メカニズムです。
注:サーバー・コードは、接続がローカルなのかリモートなのかを検出します。 ローカル接続の場合、認証が SERVER であると、ユーザー ID とパスワードは、 認証の成功のためには必要とされません。

リモート・インスタンスが SERVER 認証である場合は、 ユーザーがローカル・マシンまたはドメインにすでにログオンされている場合であっても、 ユーザー ID とパスワードを、ユーザーが提供するかまたは DB2 が検索して、 妥当性検査のためにサーバーに提供しなければなりません。

SERVER_ENCRYPT

サーバーが、暗号化された SERVER 認証スキーマを受け入れるように指定します。 クライアント認証が指定されない場合、 クライアントはサーバーで選択された方式を使用して認証されます。

クライアント認証が DCS または SERVER である場合、 クライアントはユーザー ID およびパスワードをサーバーに渡すことによって認証されます。 クライアント認証が DCS_ENCRYPT または SERVER_ENCRYPT である場合、 クライアントはユーザー ID および暗号化されたパスワードを渡すことによって認証されます。

SERVER_ENCRYPT がクライアントで指定され、SERVER がサーバーで指定されると、 認証レベルの不一致のためにエラーが戻されます。

CLIENT

オペレーティング・システムの機密保護を使用して、 アプリケーションが呼び出されたデータベース区画上で認証が行われることを指定します。 接続が試みられているときにユーザー ID およびパスワードが指定されると、 それらがサーバーにある有効なユーザー ID とパスワードの組み合わせと比較され、 そのユーザー ID がそのインスタンスへのアクセスを許されているかどうかが判別されます。 データベース・サーバーでは、それ以上の認証は行われません。

ユーザーがローカルまたはクライアントのログインを行った場合、そのユーザーは、 そのローカルのクライアント・ワークステーションでのみ認識されます。

リモート・インスタンスが CLIENT 認証である場合、 trust_allclntstrust_clntauth という他の 2 つのパラメーターが最終的な認証タイプを決定します。

TRUSTED クライアントのみに対する CLIENT レベル機密保護:

トラステッド・クライアントとは、 信頼できるローカル機密保護システムをもつクライアントのことです。 具体的には、Windows 95 および Windows 98 の各オペレーティング・システムを除く、 すべてのクライアントがトラステッド・クライアントです。

CLIENT の認証タイプが選択されている場合、 固有の機密保護を操作環境が持っていないクライアントに対する保護のために、 追加のオプションを選択することができます。

機密保護のないクライアントに対する保護のために、 管理者は、trust_allclnts パラメーターを NO に設定することによって、 「トラステッド・クライアント認証」を選択することができます。 これは、すべてのトラステッド・プラットフォームが、 サーバーに代わってユーザーの認証ができることを意味します。 非トラステッド・クライアントは、サーバー上で認証され、 ユーザー ID とパスワードを提供しなければなりません。 ユーザーは、クライアントを信頼するかどうかを示すために、 trust_allclnts 構成パラメーターを使用します。 このパラメーターの省略時値は YES です。

注:一部のクライアントが認証のためのネイティブの安全な機密保護システムを持っていない場合であっても、 すべてのクライアントをトラステッド・クライアント (trust_allclnts が YES) とすることは可能です。

トラステッド・クライアントの場合であっても、 サーバー側で認証を完了させたい場合があります。 トラステッド・クライアントをどこで妥当性検査するかを指示するために、 trust_clntauth 構成パラメーターを使用します。 このパラメーターの省略時値は CLIENT です。 このパラメーターの詳細は、第 32 章, DB2 の構成を参照してください。
注:トラステッド・クライアントの場合のみ、 CONNECT または ATTACH を試みているときにユーザー ID またはパスワードが明示して提供されないと、 ユーザーの妥当性検査は、そのクライアントで行われます。 trust_clntauth パラメーターは、 USER/USING 文節で提供された情報をどこで妥当性検査するかを判別するためだけに使用されます。

DRDA クライアントを除くすべてのクライアントに対して、DB2 (MVS 版)、 DB2 (OS/390 版)、DB2 (VM および VSE 版)、および DB2 (OS/400 版) から保護するには、 trust_allclnts パラメーターを DRDAONLY に設定します。 上記のクライアントだけを、クライアント側の確認を行うよう承認することができます。 他のすべてのクライアントには、 サーバーによって認証されているユーザー ID とパスワードが必要です。

trust_clntauth パラメーターは、 上記のクライアントが認証される位置を判別するのに使用されます。 trust_clntauth が "client" である場合、認証はクライアントで行われます。 trust_clntauth を "server" に設定すると、 認証は、クライアント (パスワードが指定されなかった場合) およびサーバー (パスワードが指定された場合) で行われます。


表 25. TRUST_ALLCLNTS および TRUST_CLNTAUTH パラメーターの組み合わせを使用した認証モード
TRUST_ ALLCLNTS TRUST_ CLNTAUTH 非トラステッドである DRDA 認証、パスワードなし 非トラステッドである DRDA 認証、パスワードあり トラステッドである DRDA 認証、パスワードなし トラステッドである DRDA 認証、パスワードあり DRDA クライアント認証、パスワードなし DRDA クライアント認証、パスワードあり
YES CLIENT CLIENT CLIENT CLIENT CLIENT CLIENT CLIENT
YES SERVER CLIENT SERVER CLIENT SERVER CLIENT SERVER
NO CLIENT SERVER SERVER CLIENT CLIENT CLIENT CLIENT
NO SERVER SERVER SERVER CLIENT SERVER CLIENT SERVER
DRDAONLY CLIENT SERVER SERVER SERVER SERVER CLIENT CLIENT
DRDAONLY SERVER SERVER SERVER SERVER SERVER CLIENT SERVER

DCS

主として、DB2 コネクトを使用してアクセスされるデータベースをカタログ化するために使用されます。 (このトピックについてさらに詳しくは、 DB2 コネクト 使用者の手引き の機密保護に関する節を参照してください。) これがデータベース・マネージャー構成ファイルの中の 1 つのインスタンスに対する認証タイプを指定するために使用された場合、 このタイプは SERVER 認証の場合と同じ意味になります。 ただし、拡張プログラム間通信 (APPC) プロトコルを使用して分散リレーショナル・データベース体系 (DRDA) アプリケーション・サーバー (AS) を介して、 サーバーがアクセスされている場合を除きます。 この場合、DCS を使用すると、認証はサーバーで行われるが、 APPC 層内のみであることを示します。 それ以上の認証は、DB2 コード内では行われません。 この値は、接続に対する APPC SECURITY パラメーターが、 SAME または PROGRAM として指定されている場合にのみサポートされます。

DCS_ENCRYPT

DB2 コネクトが、暗号化された SERVER 認証スキーマを受け入れるように指定します。 クライアント認証が指定されない場合、 クライアントはサーバーで選択された方式を使用して認証されます。

クライアント認証が DCS または SERVER である場合、 クライアントはユーザー ID およびパスワードを DB2 コネクトに渡すことによって認証されます。 クライアント認証が DCS_ENCRYPT または SERVER_ENCRYPT である場合、 クライアントはユーザー ID および暗号化されたパスワードを渡すことによって認証されます。

DCS_ENCRYPT がクライアントで指定され、DCS がサーバーで指定されると、 認証レベルの不一致のためにエラーが戻されます。

DCE

DCE 機密保護サービスを使用してユーザーが認証されることを指定します。 DCE 機密保護について詳しくは、ユーザーの認証のための DCE 機密保護サービスの使用を参照してください。

DCE_SERVER_ENCRYPT

サーバーが、DCE 認証または暗号化された SERVER 認証スキーマを受け入れるように指定します。 クライアント認証が DCE であるか、または指定されない場合、 クライアントは DCE 機密保護サービスを使用して認証されます。 DCE 機密保護について詳しくは、ユーザーの認証のための DCE 機密保護サービスの使用を参照してください。

クライアント認証が SERVER または DCS である場合、 クライアントはユーザー ID およびパスワードをサーバーに渡すことによって認証されます。 クライアント認証が SERVER_ENCRYPT または DCS_ENCRYPT である場合、 クライアントはユーザー ID および暗号化されたパスワードを渡すことによって認証されます。 クライアントの認証タイプを DCE_SERVER_ENCRYPT として指定することはできません。 インスタンスの認証タイプが DCE_SERVER_ENCRYPT として指定されると、 すべてのローカル・アプリケーションは DCE を認証スキーマとして使用します。 これは、データベース接続またはインスタンス接続を必要としないユーティリティー・コマンドにも当てはまります。

DCE と SERVER_ENCRYPT 認証タイプの混合を許可することに加えて、 DCE_SERVER_ENCRYPT 認証タイプも、DCE 内のグループを使用するときに、 制限のうち 1 つを緩和します。 認証タイプが DCE_SERVER_ENCRYPT に設定される場合、 前提事項は認証時以外で要求されているグループ・リストであり、 DCE からではなく基本オペレーティング・システムからとられます。 その後、管理者として、 認証時にサポートされるグループ・リスト・サポートを外部で提供するために、 サーバー上でユーザーがショート DCE 名と一致するように設定することができます。

KERBEROS

DB2 クライアントとサーバーが両方とも、 ケルベロス機密保護プロトコルをサポートしているオペレーティング・システム上で実行されている場合に使用します。 ケルベロス機密保護プロトコルは、 従来の暗号を使用して共有秘密キーを作成することにより、 サード・パーティーの認証サービスとして認証を実行します。 このキーがユーザーの証明書になり、 ローカルまたはネットワーク・サービスが要求されるたびに、 ユーザーのアイデンティティーの確認に使用されます。 このキーを使用することにより、 ネットワークを介して生のテキストでユーザー名およびパスワードを渡す必要がなくなります。 ケルベロス機密保護プロトコルにより、 リモート DB2 サーバーへの単一のサインオンを行えるようになります。

KRB_SERVER_ENCRYPT
サーバーが、KERBEROS 認証または暗号化された SERVER 認証スキーマを受け入れるように指定します。 クライアント認証が KERBEROS である場合、 クライアントはケルベロス機密保護システムを使用して認証されます。 クライアント認証が KERBEROS でない場合、 システム認証タイプは SERVER_ENCRYPT と同じになります。
注:ケルベロス認証タイプがサポートされているのは、 Windows 2000 を実行しているクライアントおよびサーバーだけです。

注:

  1. 認証のタイプの選択が重要になるのは、 データベースにアクセスするリモート・データベース・クライアントがある場合、 または統合データベース機能の使用時だけです。 ローカル・クライアントを通してデータベースにアクセスしているほとんどのユーザーは、 データベースと同じマシン上で常に認証されます。 DCE 機密保護サービスが使用される場合、この例外がある場合があります。 リモート・クライアントのサポートと使用については、 使用しているプラットフォーム用の概説およびインストール を参照してください。

  2. 構成ファイル自体へのアクセスは構成ファイル内の情報によって保護されているため、 認証情報を変更しているときに、 誤って自分自身を自分のインスタンスからロックアウトしてしまわないようにしてください。 以下のデータベース・マネージャー構成ファイル・パラメーターは、 インスタンスへのアクセスを制御します。

    * は、2 つの最も重要なパラメーターを示し、これらが最も問題を引き起こす可能性があります。

    このようなことが起こらないようにするために、行えることがいくつかあります。 誤って自分自身を DB2 システムからロックアウトしてしまった場合、 すべてのプラットフォームで使用可能なフェールセーフのオプションがあります。 これは、高い特権をもったローカルのオペレーティング・システムの機密保護ユーザーを使用して、 通常の DB2 機密保護検査をオーバーライドしてデータベース・マネージャー構成ファイルを更新することです。 このユーザーは、 常にデータベース・マネージャー構成ファイルを更新するための特権を持っており、 それによって問題を訂正します。 ただし、この機密保護上のう回は、 データベース・マネージャー構成ファイルのローカルでの更新にのみ制限されています。 フェールセーフのためのユーザーは、リモートで、 または他の DB2 コマンドに対して使用することはできません。 この特別のユーザーは、以下のように識別されます。

  3. Windows NT の機密保護の詳細については、付録 L, DB2 (Windows NT 版) が Windows NT 機密保護を処理する方法を参照してください。


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