コネクティビティー 補足

アプリケーション・サーバーのセットアップ

DB2 ユニバーサル・データベース (OS/390 版) のアプリケーション・サーバー・サポートによって、 DB2 ユニバーサル・データベース (OS/390 版) は DRDA アプリケーション・リクエスターのサーバーとして機能することができます。 DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーに接続されたアプリケーション・リクエスターは、以下のものとして機能することができます。

DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーに接続されたアプリケーション・リクエスターの場合、 DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーは以下のようにデータベース・アクセスをサポートします。

ネットワーク情報の提供

DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーが適正に分散データベース要求を処理するためには、次のステップを踏む必要があります。

  1. アプリケーション・サーバーをローカルのコミュニケーション・マネージャーに定義する。
  2. 使用される可能性のある各 2 次サーバーの宛先を定義し、 DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーが SQL 要求を最終的な宛先に再経路指定できるようにする。
  3. 必要な機密保護を提供する。
  4. データ表示を提供する。

アプリケーション・サーバー (SNA) を定義する

アプリケーション・サーバーが分散データベース要求を受信するためには、これをローカルなコミュニケーション・マネージャーに定義し、固有の RDB_NAME 名を割り当てる必要があります。以下の説明は SNA 接続と関連しています。アプリケーション・サーバーを正しく定義するには、次のステップを踏む必要があります。

  1. DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーが使用する LU 名と RDB_NAME を選択する。これらの名前を DB2 ユニバーサル・データベース (OS/390 版) と VTAM に記録するプロセスは、 ローカル・システム (SNA) の定義に説明されているプロセスと同じです。 DB2 ユニバーサル・データベース (OS/390 版) のために選択する RDB_NAME を、アプリケーション・サーバーへのコネクティビティーが必要なすべてのエンド・ユーザーおよびアプリケーション・リクエスターに供給しなければなりません。
  2. アクセスの必要なアプリケーション・リクエスターごとに NETID.LUNAME 値を DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーに登録して、アプリケーション・リクエスターが SNA 要求を DB2 ユニバーサル・データベース (OS/390 版) サーバーに経路指定できるようにします。アプリケーション・リクエスターがダイナミック・ネットワーク・ルーティングを実行できる場合でも、そのようにしてください。アプリケーション・リクエスターは NETID.LUNAME を知らないとダイナミック・ネットワーク・ルーティングを使用できないからです。
  3. DRDA 省略時 TPN (X'07F6C4C2') を各アプリケーション・リクエスターに指定します。 DB2 ユニバーサル・データベース (OS/390 版) が自動的にこの値を使用するためです。
  4. アプリケーション・リクエスターで要求された各モード名ごとに、VTAM モード表に項目を作成します。これらの項目は、各モード名の RU サイズ、歩調合わせウィンドウ・サイズ、およびサービス・クラスを記述します。
  5. DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーに接続するアプリケーション・リクエスターに、セッション限度を定義します。 VTAM APPL ステートメントは、すべてのパートナー・システムにあてはまる省略時のセッション限度を定義します。特定のパートナーに対して固有の省略時値を設定したい場合は、通信データベース (CDB) の SYSIBM.LUMODES 表を使用できます。

    VTAM ネットワークを調べる方法については、 RU サイズおよび歩調合わせの設定を参照してください。

  6. DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーへの接続が許可されたアプリケーション・リクエスターを識別するための項目を DB2 ユニバーサル・データベース (OS/390 版) CDB に作成します。ネットワーク内のアプリケーション・リクエスター用に CDB 項目を定義する 2 つの基本的な方法は、以下のとおりです。
    1. CDB で特に記述されていない、任意の LU に使用する省略時値を指定する行を SYSIBM.LUNAMES に挿入できます (省略時の行は LUNAME 列がブランクです)。この方法では、ネットワーク内のいくつかの LU に対しては特定の属性を与え、一方、他のすべての LU については省略時値を設定できます。

      たとえば、DALLAS システム (別の DB2 ユニバーサル・データベース (OS/390 版) システム) には検査済み分散データベース要求 (LU 6.2 SECURITY=SAME) を送信することを許可する一方で、データベース・マネージャー・システムにはパスワードを送信させるということができます。さらに、特にデータベース・マネージャー・システムが多数ある場合などは、システムごとに CDB に項目を作成したくない場合もあります。 図 25 では、DALLAS システムに対して SECURITY=SAME を指定する一方、他のすべてのリクエスターに対しては SECURITY=PGM にさせるために CDB を使用する方法を示します。

      図 25. アプリケーション・リクエスター接続の省略時値の確立 (SNA)

      INSERT INTO SYSIBM.LUNAMES
           (LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS, MODESELECT, USERNAMES)
        VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', ' ');
      INSERT INTO SYSIBM.LUNAMES
           (LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS, MODESELECT, USERNAMES)
        VALUES (' ', ' ', 'C', 'N', 'N', ' ');
      

    2. CDB を次のいずれかに設定することにより、 CDB を使用してネットワーク内の各アプリケーション・リクエスターに個別に許可を与えることができます。
      • SYSIBM.LUNAMES 中に省略時の行を記録しないようにする。省略時の行 (LU 名がブランクの行) が存在しない場合、DB2 ユニバーサル・データベース (OS/390 版) は、接続しようとする各アプリケーション・リクエスターの LU 名を含んだ SYSIBM.LUNAMES 中の行を必要とします。対応する行が CDB に見つからない場合、アプリケーション・リクエスターはアクセスを拒否されます。
      • SYSIBM.LUNAMES に、 come-from 検査が必要であることを指定した省略時の行を記録する (USERNAMES 列を 'I' または 'B' に設定)。これにより、Come-From 検査で説明されているように、 DB2 ユニバーサル・データベース (OS/390 版) はアクセスをアプリケーション・リクエスターおよび SYSIBM.USERNAMES 表で定義されたエンド・ユーザーに限定します。名前変換規則が SYSIBM.LUNAMES 中にブランク LU 名の行を必要とするものの、この行の使用によって DB2 ユニバーサル・データベース (OS/390 版) が DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーへの無制限なアクセスを許可するようにはしたくない場合、この方法を使用できます。

      図 26 では、LUNAME 列にブランクの行はないため、 DB2 ユニバーサル・データベース (OS/390 版) は LUDALLAS または LUNYC 以外の LU へのアクセスをすべて拒否します。

      図 26. 個々のアプリケーション・リクエスター接続の識別 (SNA)

      INSERT INTO SYSIBM.LUNAMES
           (LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS, MODESELECT, USERNAMES)
        VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', ' ');
      INSERT INTO SYSIBM.LUNAMES
           (LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS, MODESELECT, USERNAMES)
        VALUES ('LUNYC', ' ', 'A', 'N', 'N', ' ');
      

アプリケーション・サーバー (TCP/IP) を定義する

アプリケーション・サーバーが TCP/IP 接続上で分散データベース要求を受信するためには、アプリケーション・サーバーをローカル TCP/IP サブシステムに定義し、固有の RDB_NAME を割り当てる必要があります。さらに、DB2 ユニバーサル・データベース (OS/390 版) ブートストラップ・データ・セットは必要なパラメーターを含んでいなければなりません。そして、DB2 ユニバーサル・データベース (OS/390 版) 通信データベース (CDB) に更新が必要な場合もあります。

  1. AS での TCP/IP のセットアップについては、 DB2 ユニバーサル・データベース (OS/390 版) インストレーションの手引き を参照してください。 AR のセットアップ方法については、 DB2 コネクト エンタープライズ・エディション (OS/2 および Windows NT 版) 概説およびインストール、および DB2 コネクト パーソナル・エディション 概説およびインストール に説明されています。
  2. ブートストラップ・データ・セット定義の例を図 18 に示します。
  3. インバウンド・データベース接続のみを使用する場合は、CDB の更新は必要ありません。それで、DB2 ユニバーサル・データベース (OS/390 版) をサーバーとしてのみ使用する計画であるなら、 CDB にデータを読み込む必要はなく、省略時値を使用できます。以下に SYSIBM.IPNAMES を更新する簡単な方法を示します。

    TCP/IP ノードへのインバウンド・データベース接続要求を許可したい場合、 SQL コマンドを使用して以下のようにこの表を更新することができます。

       INSERT INTO SYSIBM.IPNAMES (LINKNAME) VALUES('        ')                                   
    

機密保護の提供

アプリケーション・リクエスターが分散データベース要求を DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーに向けるときには、以下の機密保護上の考慮事項が関係します。

Come-From 検査

DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーがエンド・ユーザー名をアプリケーション・リクエスターから受け取る場合、アプリケーション・サーバーは指定されたアプリケーション・リクエスターから受け取るエンド・ユーザー名を制限できます。これは come-from 検査を使用することで行えます。 come-from 検査を使用すると、アプリケーション・サーバーは、所定のユーザー ID が特定のパートナーだけに使用されるよう指定できます。たとえば、アプリケーション・サーバーは JONES を DALLAS だけ「から来る (come-from)」よう制限できます。 (DALLAS 以外の) 別のアプリケーション・リクエスターが名前 JONES をアプリケーション・サーバーに送ろうとする場合、アプリケーション・サーバーはその名前が適正なネットワーク・ロケーションから来なかったために要求を拒否できます。

DB2 ユニバーサル・データベース (OS/390 版) は come-from 検査をインバウンド・エンド・ユーザー名前変換の一部として実装しています。これについては次の節で説明します。
注:インバウンドおよび come-from 検査は TCP/IP インバウンド要求に対してなされます。

エンド・ユーザー名の選択

アプリケーション・リクエスターによって渡されるユーザー ID は、 SNA ネットワーク全体で一意ではないことがあります。 DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーはインバウンド名前変換を実行して、 SNA ネットワーク全体を通じて固有なエンド・ユーザー名を作成する必要があるかもしれません。同様に、DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーはアウトバウンド名前変換を実行して、アプリケーションに関係する 2 次サーバーに対して固有なエンド・ユーザー名を与える必要があるかもしれません。 (アウトバウンド・エンド・ユーザー名前変換については、機密保護の提供を参照してください。)

インバウンド名前変換は、 SYSIBM.LUNAMES または SYSIBM.IPNAMES 表の USERNAMES 列を 'I' (インバウンド変換) または 'B' (インバウンドおよびアウトバウンド両方の変換) に設定することにより、使用可能にできます。インバウンド名前変換が有効であるとき、 DB2 ユニバーサル・データベース (OS/390 版) はアプリケーション・リクエスターによって送られたユーザー ID を変換して、 DB2 ユニバーサル・データベース (OS/390 版) は所有者の名前を立案します (アプリケーション・リクエスターが別の DB2 ユニバーサル・データベース (OS/390 版) システムである場合)。

アプリケーション・リクエスターがユーザー ID およびパスワードの両方を APPC ALLOCATE verb に関して送る場合、ユーザー ID およびパスワードはユーザー ID が変換される前に妥当性検査されます。 SYSIBM.USERNAMES の PASSWORD 列は、パスワード妥当性検査には使用されません。代わりに、ユーザー ID とパスワードが妥当性検査のため、外部機密保護システム (RACF または RACF と同等の製品) に送られます。

ALLOCATE verb の着信ユーザー ID が検査されるとき、 DB2 ユニバーサル・データベース (OS/390 版) は許可出口ルーチンを持ちます。これは、2 次 AUTHID のリストを提供し、追加の機密保護検査を実行するために使用できます。詳細については、 DB2 ユニバーサル・データベース (OS/390 版) 管理の手引き を参照してください。

インバウンド名前変換処理は SYSIBM.USERNAMES 表の中の行を検索しますが、これは以下の優先順位リスト (TYPE.AUTHID.LINKNAME) のうちの 1 つのパターンと一致しなければなりません。

  1. I.AUTHID.LINKNAME − 特定のアプリケーション・リクエスターからの特定のエンド・ユーザー
  2. I.AUTHID.blank − 任意のアプリケーション・リクエスターからの特定のエンド・ユーザー
  3. I.blank.LINKNAME − 特定のアプリケーション・リクエスターからの任意のエンド・ユーザー

行が検出されない場合、リモート・アクセスは拒否されます。行が検出されると、リモート・アクセスが許可され、エンド・ユーザー名は NEWAUTHID 列で与えられた値に変換されます。 NEWAUTHID 値がブランクの場合は名前が変更されないことを示します。任意の DB2 ユニバーサル・データベース (OS/390 版) 資源に対する許可の検査 (たとえば、SQL 表特権) が、DB2 ユニバーサル・データベース (OS/390 版) により、元のユーザー名ではなく変換されたエンド・ユーザー名に対して実行されます。

DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーがアプリケーション・リクエスターからエンド・ユーザー名を受け取る場合、 DB2 ユニバーサル・データベース (OS/390 版) インバウンド名前変換機能を使用することによって以下のいくつかの目的が達成されます。

ネットワーク機密保護の提供

SNA 接続では、LU 6.2 は主に 3 つのネットワーク機密保護機能を提供します。

ネットワーク機密保護では、 DB2 ユニバーサル・データベース (OS/390 版) でのセッション・レベル機密保護および暗号化について説明しています。 DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーは、DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・リクエスターとまったく同様に、セッション・レベルの機密保護および暗号化を使用します。

残りのネットワーク機密保護の考慮事項は、SNA 会話レベル機密保護だけです。会話レベル機密保護のいくつかの面は DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバー独自のものです。 DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーはネットワーク機密保護において 2 つの異なった役割を果たします。

機密保護違反が検出された場合、 LU 6.2 は DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバー が SNA 機密保護違反センス・コード ('080F6051'X) をアプリケーション・リクエスターに送るようにします。このセンス・コードは障害の原因を示すものではないので、 DB2 ユニバーサル・データベース (OS/390 版) は 2 つの方式で分散機密保護違反の原因を記録します。

データベース・マネージャー機密保護

データベース資源の所有者として、DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーは、そこにある SQL オブジェクトに対してデータベース機密保護機能を制御します。 DB2 ユニバーサル・データベース (OS/390 版) が管理するオブジェクトへのアクセスは、特権によって制御されます。これは、DB2 ユニバーサル・データベース (OS/390 版) 管理者または個々のオブジェクトの所有者によって、ユーザーに与えられます。 DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーが制御する 2 つの基本的なオブジェクトのクラスは以下のとおりです。

パッケージを作成するとき、 DISABLE/ENABLE オプションによって、どの DB2 ユニバーサル・データベース (OS/390 版) 接続タイプがパッケージを実行できるか制御することができます。 RACF および DB2 ユニバーサル・データベース (OS/390 版) 機密保護出口ルーチンを使用して、エンド・ユーザーに選択的に DDF の使用を許可できます。 RLF を使用して、リモート・バインドおよび動的 SQL 実行のプロセッサー時間を制限できます。

MYPKG という名前の DB2 ユニバーサル・データベース (OS/390 版) パッケージについて考慮します。これは JOE が所有しているものとします。 JOE は SAL に対して、 DB2 ユニバーサル・データベース (OS/390 版) GRANT USE ステートメントを発行することにより、このパッケージの実行を許可できます。 SAL がこのパッケージを実行すると、以下の事柄が発生します。

機密保護サブシステム

DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーの機密保護サブシステム (RACF または RACF と同等の製品) の使用法は、 SYSIBM.LUNAMES 表でインバウンド名前変換機能をどのように定義したかに応じて異なります。

データの表示

ご使用の DB2 ユニバーサル・データベース (OS/390 版) サブシステムが、各アプリケーション・リクエスターの CCSID を DB2 ユニバーサル・データベース (OS/390 版) サブシステムのインストール・システムの CCSID に変換できるかどうか確認する必要があります。詳細については、データの表示を参照してください。


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