分散データベース環境の機密保護を考慮する場合、 分散コンピューティング環境 (DCE) 機密保護サービスを使用するのが優れた選択です。 これは、DCE が以下のものを提供するためです。
DB2 は、DCE の省略時ログイン・コンテキスト、接続ログイン・コンテキスト、 および代行ログイン・コンテキストをサポートします。 省略時ログイン・コンテキスト は、 ユーザーがクライアントで dce_login を行ったときに確立されます。 後続の DB2 コマンドはこのコンテキストにアクセスし、 ユーザーによるそれ以上の介入なしで (つまり、ユーザー ID またはパスワードを必要とせずに)、 ユーザー認証を行うことができます。 接続ログイン・コンテキスト は、 USER/USING 文節を使用した CONNECT または ATTACH で提供されるユーザー ID およびパスワードを使用して、 DB2 セッションに対して確立されます。 また、代行ログイン・コンテキスト は、 DB2 クライアントが DCE サーバー・アプリケーションの一部として使用された場合に行われます。 DCE サーバー・アプリケーション (これも 1 つの DB2 クライアントです) は、 DCE クライアント・アプリケーション (そのポイントから、 ユーザーのオリジナルのアイデンティティーが出されます) から要求を受け取ります。 DCE サーバーが DCE クライアントを代行できるよう、 DCE クライアントと DCE サーバーが正しく構成されている場合、DB2 は、 代行トークンを取得して、それを DB2 サーバーに転送します。 これによって、DB2 サーバーは、DCE サーバーのアイデンティティーを使用するのではなく、 DCE クライアントのオリジナルのアイデンティティーを使用して、 要求を処理することができます。 代行ログイン・コンテキストを確立する方法については、 使用しているプラットフォームの DCE の資料に説明があります。
注: | DCE をサポートしているベンダー製品がいくつかあります。 機密保護サービス域で IBM の DCE 製品を使用して作業できることを保証するために、 2 つの新しい DLL が提供されています。 それは、db2dces.ibm と db2dcec.ibm です。 (これらの DLL ファイルは、Windows NT でのみ使用できます。) 機密保護サービスのために IBM の DCE 製品を購入して使用する場合には、 これら 2 つのファイルを db2dces.dll および db2dcec.dll にそれぞれコピーしてください。 別のベンダーの DCE 製品を使用することを考慮している場合は、 そのベンダーのサービス部門と DB2 UDB のサービス部門と連絡を取って、 機密保護サービスのためにそのベンダーの DCE を実装することが、 DB2 UDB で効果があるかどうかを話し合う必要があります。 |
ユーザーは、DB2 で使用される前に、分散コンピューティング環境 (DCE) レジストリーに登録され、 正しい属性を持っていなければなりません。 DCE プリンシパルを作成する方法については、 該当のプラットフォーム固有の DCE の資料を参照してください。
DCE 認証サーバーを希望する各 DB2 ユーザーは、DCE プリンシパルとアカウントが、 クライアント・フラグを使用可能にして DCE レジストリーの中に定義されていなければなりません。 このプリンシパルはまた、拡張レジストリー属性 (ERA) セクションに、 特定の DCE 認証サーバーに接続した場合に このプリンシパルに対してどの許可名が使用されるかを示す項目を持っていなければなりません。
また、データベース内でグループ特権を使用するために、 ユーザー・プリンシパルをグループのメンバーにしたい場合もあります。 グループ ERA 内の類似の情報が、グループ名を DB2 許可名にマップします。 許可名は 2 次許可名ですが、同じ制約事項が適用されます。 グループの作成およびメンバーの追加の方法についての詳細は、DCE の資料を参照してください。
ERA の中の情報は、特定のサーバー DCE プリンシパル名について、 ユーザーの DCE プリンシパルまたはグループ名を DB2 許可名にマップします。 ERA を使用するためには、この属性の形式を示す ERA スキーマを定義しなければなりません。 これは、DCE セルごとに 1 回行う必要があり、以下のステップを行うことによって達成されます。
> xattrschema create /.:/sec/xattrschema/db2map \ > -aclmgr {{principal r m r m } {group r m r m }} \ > -annotation {Schema entry for DB2 database access} \ > -encoding stringarray \ > -multivalued no \ > -uuid 1cbe84ca-9df3-11cf-84cd-02608c2cd17b
これは、拡張レジストリー属性 db2map を作成します。
このマッピングを表示するには、dcecp プロンプトで以下のコマンドを出します。
> xattrschema show /.:/sec/xattrschema/db2map
以下のように表示されます。
{axlmgr {{principal {{query r} {update m} {test r} {delete m}}} {group {{query r} {update m} {test r} {delete m}}}}} {annotation {Schema entry for DB2 database access}} {applydefs no} {intercell rejects} {multivalued no} {reserved no} {scope {}} {trigbind {}} {trigtype none} {unique no} {uuid 1cbe84ca-9df3-11cf-84cd-02608c2cd17b}
注: | ERA に記録された許可名の内容についての制約事項は、 DCE によって施行されません。 DCE プリンシパルまたはグループに無効な許可名が与えられた場合、 ユーザーを認証する試みが DB2 によって行われたときにエラーになります。 (認証は、CONNECT、ATTACH、DB2START、 または認証が必要な他のいずれかの操作で行われることに注意してください。) また、DCE プリンシパルに対する許可名の割り当ては、1 対 1 の対応を持ち、 固有なものになるようにすることを強くお勧めします。 DCE は、これらの条件を検査しません。 |
DB2 クライアントが DB2 UDB サーバーにアクセスする場合、 DB2 クライアントが DCE プリンシパルとして登録されると、 プリンシパル名から許可名へのマッピングを提供するために、 ERA 情報を追加しなければなりません。 これは、各ユーザーまたはグループに対して 1 回行われますが、 以下のステップを行うことによって達成されます。
> principal modify principal_name \ > -add {db2map map_1 map_2...map_n}
ここで、map_n は、以下の形式を使用します。
DCE_server_principal,DB2_authid
ただし、DCE_server_principal は DB2 UDB サーバーに対する有効な DCE プリンシパル名 (または、 このマッピングが、別の map_n 項目にすでに指定されたものでない任意の DB2 サーバーに対して有効であることを示すワイルドカード *) であり、 DB2_authid は有効な DB2 許可名です。
DCE グループを DCE プリンシパルに使用するつもりである場合、DCE グループには、 SYSADM または SYSCTRL 権限などの適切な権限を持つ DB2 authid へのマッピングもなければなりません。
DCE プリンシパル名を DB2 authid にマップするのに使用される DCE スキーマで指定される許可識別子 (authid) は、 英大文字で記入する必要がある ことにぜひ注意してください。 小文字の使用または大文字小文字の混合は、エラーとなります。
サーバーは、DB2 で使用される前に、 分散コンピューティング環境 (DCE) レジストリーの登録済みプリンシパルでなければならず、 正しい属性を持っていなければなりません。 DCE サーバー・プリンシパルを作成する方法については、 該当のプラットフォーム固有の DCE の資料を参照してください。
DCE 機密保護クライアントの実行時コードはインストールされていて、 サーバー・インスタンスによってアクセス可能でなければなりません。
認証メカニズムとして DCE を使用したい各 DB2 サーバーは、 DB2START を出したときに DCE に登録しなければなりません。 これを手操作で行うのを避けるために、DCE は、 サーバーが keytab ファイルと呼ばれる特殊なファイルの中に自身のユーザー ID およびパスワード (キー) を維持する方式を提供します。 DB2START 時に、DB2 は、データベース・マネージャー構成ファイルを読み取り、 インスタンスの認証タイプを獲得します。 認証タイプが DCE であることがわかると、keytab ファイルから情報を獲得するために、 DCE 呼び出しが DB2 サーバーによって行われます。 サーバーを DCE に登録するために使用されるのは、この情報です。 この登録によって、サーバーは、DCE クライアントから DCE トークンを受け入れ、 そのトークンをこれらのユーザーの認証に使用することができます。
インスタンス管理者は、DCE コマンドを使用して、 インスタンスに対する keytab ファイルを作成しなければなりません。 keytab ファイルの作成方法についての詳細は、 使用しているプラットフォーム用の DCE の資料に説明があります。 その資料の中で、keytab ファイルと、 dcecp keytab コマンドまたは rgy_edit コマンドに関連する詳細説明を参照してください。 DB2 keytab ファイルは、keytab.db2 という名前でなければならず、 インスタンスの sqllib ディレクトリーの security サブディレクトリーに常駐していなければなりません。 (Intel ベースのオペレーティング・システムの場合、このファイルは、 sqllib ディレクトリーの INSTANCENAME サブディレクトリーの security サブディレクトリーの中に常駐していなければなりません。 INSTANCENAME は、作業しているデータベースのインスタンス名です。) 指定されたインスタンスについて、 サーバー・プリンシパルに対して 1 つだけの項目が含まれている必要があり、 そうでないと、DB2START 時にエラーになります。 UNIX オペレーティング・システムのプラットフォームでは、このファイルは、 インスタンス所有者の読み取り / 書き込みだけが許されるファイル許可によって保護されていなければなりません。
以下は、keytab ファイルを作成する例です。
> ktadd -p principal_name -pw principal_password \ > -f keytab.db2
DCE 構成が完了してから DCE 認証を使用して DB2 を開始するためには、 データベース・マネージャー構成ファイルを更新して認証タイプを "DCE" にすることによって、 DB2 に DCE 認証を使用することを通知しなければなりません。 これは、以下の CLP コマンドを出すことによって行われます。
db2 update database manager configuration using authentication DCE sysadm_group DCE_group_name
次に、SYSADM 権限を持つ有効な DB2 DCE ユーザーに対して dce_login を実行し、 DB2START を出します。
注: | DCE 認証を使用して DB2 を開始する前に、
そのインスタンスに対する SYSADM として使用される DCE ユーザー・プリンシパルを定義して、
インスタンスの開始、停止、
および管理を行える有効な DCE ユーザー ID を持てるようにしてください。
これを行う方法についての指示は、DCE に対する DB2 ユーザーのセットアップの方法を参照してください。
これらの指示に加えて、作成されたプリンシパルが、 そのインスタンスに対する SYSADM_GROUP のメンバーになるようにしてください。 省略時解釈では、このグループ名は、グループが明示して指定されていない場合 (つまり、 SYSADM_GROUP がヌル値である場合)、DCE 認証に対して DB2ADMIN になります。 ただし、インスタンスの認証タイプを変更する前に、 好みのグループ名 (許可名) に更新することができます。 選択した DCE グループには、その DCE グループを、 指定された SYSADM_GROUP 許可名にマップする ERA が定義されていなければなりません。
DB2 管理サーバーの関数の 1 つは、DB2 インスタンスを開始することです。 AUTHENTICATION = DCE であるとき、 このインスタンス用 DB2 keytab ファイルで使用される DCE プリンシパルは、 有効な DCE プリンシパルを DB2 authid にマッピングさせる必要があります。 このマッピングは、DB2 インスタンスを開始するため DB2 管理サーバーで必須となります。 有効なマッピングによって、この ID はクライアントとしてもサーバーとしても機能できます。 |
データベース・マネージャー構成ファイルを更新し、 認証タイプを DCE に設定することによって、クライアントのみのインスタンスを、 ローカル操作に対して DCE 認証を使用するように設定することができます。 DCE に登録する必要があるサーバーがないため、 クライアントのみのインスタンスについては、keytab ファイルは必要ありません。 一般に、クライアントのみの DB2 インスタンスが DCE 認証を使用することは推奨されません (または必須ではありません) が、サポートはされています。
DCE 機密保護を使用してリモート・データベースへのアクセスを希望するクライアントは、 適切な DCE 機密保護製品にアクセスする必要があります。 クライアントは、ターゲット・データベースの認証タイプをデータベース・ディレクトリーにカタログすることを選択することができます (この選択は任意です)。 クライアントが DCE 認証を指定することを選択した場合、 DCE サーバー・プリンシパルの完全修飾名も指定しなければなりません。 DCE 認証がディレクトリーに指定されていない場合、認証およびプリンシパルの情報は、 CONNECT 時にサーバーから取得されます。
DCE 認証を使用する場合、DB2 によって提供され、 グループ・サポートに関連する特定の SQL 機能について、いくつかの制約事項があります。 以下の制約事項は、DCE 認証を使用している場合に存在します。
DB2 で実行されるような DCE 認証は、OSF DCE 汎用機密保護サービスのアプリケーション・プログラミング・インターフェース (GSSAPI) を使用して獲得された DCE チケットを発行します。 したがって、DCE 機密保護のすべての認証はそのデータベースのプロトコル層で行われます。 ある通信メカニズムでは、 付加的な通信層の機密保護 (DCE に必ずしも内蔵されるとは限らない) を提供する場合があります。 通信層の認証がデータベース・プロトコル層の認証から完全に独立した状態を維持できる場合には、 どんな制約事項も実施されません。 ただし、接続が正常に確立される前に、 認証しているデータベース・プロトコル層および通信層の両方の基準が満たされなければなりません。 データベース・プロトコル層および通信層の認証メカニズムが相互作用する場合で、 ある組み合わせが機密漏れをもたらすならば、それらの使用は制限されることがあります。
DCE 認証は TCPIP SOCKS サポートと共同して使用する場合がありますが、 その 2 つの機密保護メカニズムは互いに独立して働きます。 これは、ユーザーが有効な DCE ログイン・コンテキストを備えるだけではなく、 さらに SOCKS サーバーの基準に一致するローカルのオペレーティング・システムのユーザー ID にログオンする必要があることを示しています。
DCE 認証は NT 名前付きパイプと共同して使用する場合がありますが、 その 2 つの機密保護メカニズムは互いに独立して働きます。 ユーザーは有効な DCE ログイン・コンテキストを備えるだけではなく、 さらに NT 名前付きパイプ・サポートの基準に一致するユーザー ID に NT ドメインをログオンする必要があります。
上記 2 つの例に示されているように、 DCE プリンシパルおよびローカル・オペレーティング・システムのユーザー ID の両方を認証のために使用する際に考えられる混乱に取り組むため、 統合された DCE を用いることができます。 この場合さらに、システムにログオンする際、 ユーザーは適切な DCE プリンシパルに自動的に記録されます。 この機能の使用方法に関する詳細については、それがサポートされている場合、 ご使用のプラットフォームの DCE 資料をご覧ください。 このアプローチを使う際、 同一の名前が DCE プリンシパルおよびローカルのオペレーティング・システム ID に使用されることに注意してください。 このことは、DCE の暗号化されたチケットに含まれる同一の値が、 通信層の暗号化されていないワイヤーに発行されることもあることを示しています。
SECURITY パラメーターが NONE に設定されるとき、 DCE 認証は APPC 通信によってのみ使用することができます。 これは、通信層における暗号化されないプリンシパルまたはパスワード、 あるいはその両方の送信の可能性を避けるためです。 一方、データベース・プロトコル層には同一プリンシパルの暗号化された DCE トークンを使用しています。 APPC 層の DCE 機密保護は、この時点では DB2 によりサポートされていません。