DB2 ユニバーサル・データベース (OS/390 版) のアプリケーション・サーバー・サポートによって、 DB2 ユニバーサル・データベース (OS/390 版) は DRDA アプリケーション・リクエスターのサーバーとして機能することができます。 DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーに接続されたアプリケーション・リクエスターは、以下のものとして機能することができます。
DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーに接続されたアプリケーション・リクエスターの場合、 DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーは以下のようにデータベース・アクセスをサポートします。
DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーが適正に分散データベース要求を処理するためには、次のステップを踏む必要があります。
アプリケーション・サーバーが分散データベース要求を受信するためには、これをローカルなコミュニケーション・マネージャーに定義し、固有の RDB_NAME 名を割り当てる必要があります。以下の説明は SNA 接続と関連しています。アプリケーション・サーバーを正しく定義するには、次のステップを踏む必要があります。
VTAM ネットワークを調べる方法については、 RU サイズおよび歩調合わせの設定を参照してください。
たとえば、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', ' '); |
図 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 サブシステムに定義し、固有の RDB_NAME を割り当てる必要があります。さらに、DB2 ユニバーサル・データベース (OS/390 版) ブートストラップ・データ・セットは必要なパラメーターを含んでいなければなりません。そして、DB2 ユニバーサル・データベース (OS/390 版) 通信データベース (CDB) に更新が必要な場合もあります。
TCP/IP ノードへのインバウンド・データベース接続要求を許可したい場合、 SQL コマンドを使用して以下のようにこの表を更新することができます。
INSERT INTO SYSIBM.IPNAMES (LINKNAME) VALUES(' ')
アプリケーション・リクエスターが分散データベース要求を DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーに向けるときには、以下の機密保護上の考慮事項が関係します。
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 つのパターンと一致しなければなりません。
行が検出されない場合、リモート・アクセスは拒否されます。行が検出されると、リモート・アクセスが許可され、エンド・ユーザー名は NEWAUTHID 列で与えられた値に変換されます。 NEWAUTHID 値がブランクの場合は名前が変更されないことを示します。任意の DB2 ユニバーサル・データベース (OS/390 版) 資源に対する許可の検査 (たとえば、SQL 表特権) が、DB2 ユニバーサル・データベース (OS/390 版) により、元のユーザー名ではなく変換されたエンド・ユーザー名に対して実行されます。
DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーがアプリケーション・リクエスターからエンド・ユーザー名を受け取る場合、 DB2 ユニバーサル・データベース (OS/390 版) インバウンド名前変換機能を使用することによって以下のいくつかの目的が達成されます。
INSERT INTO SYSIBM.LUNAMES (LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS, MODESELECT, USERNAMES) VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I'); INSERT INTO SYSIBM.USERNAMES (TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD) VALUES ('I', 'JONES', 'LUNYC', 'NYJONES', ' ');
INSERT INTO SYSIBM.LUNAMES (LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS, MODESELECT, USERNAMES) VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I'); INSERT INTO SYSIBM.USERNAMES (TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD) VALUES ('I', ' ', 'LUNYC', 'NYUSER', ' ');
INSERT INTO SYSIBM.LUNAMES (LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS, MODESELECT, USERNAMES) VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I'); INSERT INTO SYSIBM.USERNAMES (TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD) VALUES ('I', 'SMITH', 'LUNYC', ' ', ' '); INSERT INTO SYSIBM.USERNAMES (TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD) VALUES ('I', 'JONES', 'LUNYC', ' ', ' ');
INSERT INTO SYSIBM.LUNAMES (LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS, MODESELECT, USERNAMES) VALUES (' ', ' ', 'A', 'N', 'N', 'I'); INSERT INTO SYSIBM.USERNAMES (TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD) VALUES ('I', ' ', 'LUNYC', ' ', ' '); INSERT INTO SYSIBM.USERNAMES (TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD) VALUES ('I', ' ', 'LUCHI', ' ', ' ');
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 つの基本的なオブジェクトのクラスは以下のとおりです。
アプリケーションが DB2 ユニバーサル・データベース (OS/390 版) にバインドされるとき、パッケージにはアプリケーション・プログラムに含まれる SQL ステートメントが含まれています。これらの SQL ステートメントは以下のように分けられます。
エンド・ユーザーがパッケージを実行する権限を与えられるとき、そのユーザーはパッケージに含まれる各静的 SQL ステートメントを実行する権限を自動的に与えられます。それで、実行されるパッケージに静的 SQL ステートメントしか含まれていない場合には、エンド・ユーザーは DB2 ユニバーサル・データベース (OS/390 版) 表特権を必要としません。
パッケージを作成するとき、 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 表でインバウンド名前変換機能をどのように定義したかに応じて異なります。
アプリケーション・リクエスターからの要求にユーザー ID (SECURITY=SAME) だけが含まれる場合、外部機密保護システムはまったく呼び出されません。インバウンド名前変換の規則によって、どのユーザーに DB2 ユニバーサル・データベース (OS/390 版) アプリケーション・サーバーへの接続が許可されているかが定義されているからです。
ご使用の DB2 ユニバーサル・データベース (OS/390 版) サブシステムが、各アプリケーション・リクエスターの CCSID を DB2 ユニバーサル・データベース (OS/390 版) サブシステムのインストール・システムの CCSID に変換できるかどうか確認する必要があります。詳細については、データの表示を参照してください。