目次 前 次 PDF


セキュリティの提供

セキュリティの提供
セキュリティとは、コンピュータに格納されているデータやコンピュータ間で渡されるデータが危険にさらされないよう保証する技術のことです。ほとんどのセキュリティ対策には、パスワードおよびデータの暗号化が含まれます。パスワードとは、ユーザーが特定のプログラムやシステムにアクセスするための秘密の文字列であり、データの暗号化とは、解読メカニズムがないと理解できない形式にデータを変換することです。
この項の内容は次のとおりです。
注意:
Oracle Tuxedo Mainframe Adapter for SNAのセキュリティの理解
電子商取引(E-Commerce)などで使用される分散アプリケーションには、悪質なユーザーがデータを傍受したり、操作を中断したり、不正な入力を生成できるアクセス・ポイントが多数あります。ビジネスがより広い範囲に分散されるほど、攻撃に対して脆弱になります。そのため、このようなアプリケーションの基盤となる分散型コンピューティング・ソフトウェアまたはミドルウェアはセキュリティ機能を備えている必要があります。
Oracle Tuxedo Mainframe Adapter for SNAは、ATMIプラットフォームで動作して、次のセキュリティ機能を実現します。
ユーザーIDのマッピング
ユーザーIDは、ATMIおよびメインフレーム環境のシステム・リソースへのアクセスを制御するために使用されます。ATMIおよびメインフレーム環境でユーザーIDを使用するには、いずれの側にもセキュリティ・メカニズムを配備しておく必要があります。ATMIドメインの場合、セキュリティ・メカニズムは認証サーバーです。ホスト・システムの場合、セキュリティ・メカニズムは外部セキュリティ・マネージャです。図4‑1に、Oracle Tuxedo Mainframe Adapter for SNAのセキュリティ要素を示します。
Oracle Tuxedo Mainframe Adapter for SNAソフトウェアでは、ドメイン間でユーザーIDを2つの方法で共有できます。
図4-1 Oracle Tuxedo Mainframe Adapter for SNAのセキュリティ要素
注意:
混合環境のセキュリティは、図4-1に示されているよりも複雑です。稼働するセキュリティ・メカニズムが配備されていないドメインは、ユーザーIDを「信頼できるユーザー」とみなしてすべてのトランザクション・リクエストを受け入れます。ドメイン・セキュリティの詳細は、該当するATMI製品ドキュメントを参照してください。
ATMI/ホスト間ユーザーIDマッピング
ATMI/ホスト間ユーザーIDマッピングは、ローカル・ドメインのユーザーIDをホスト・システムの対応するユーザーIDと関連付けます。ATMI/ホスト間ユーザーIDマッピングでは、ATMIのユーザーIDがホストの対応するものと異なっていてもかまいません。図4‑2を参照してください。
この種類のマッピングを作成するには、dmadminコマンドを使用します。「dmadminコマンドを使用したユーザーIDマッピングの管理」を参照してください。このコマンドはDMCONFIGファイルのバイナリ形式版(BDMCONFIGファイル)を変更します。
図4-2 一般的なATMI/ホスト間ユーザーIDマッピングの例
直接ユーザーIDマッピング
直接ユーザーIDマッピングを使用すると、ATMIユーザーIDを同一のホスト・ユーザーIDに直接マッピングできます。これにより、ATMI/ホスト間ユーザーIDマッピングの場合のようにdmadminコマンドを使用する必要がなくなります。この機能を使用する場合は、BDMCONFIGファイル内のすべてのユーザーIDマッピングはバイパスされます。この機能を有効にするには、Oracle Tuxedo Mainframe Adapter for SNA Gatewayを起動する際、GWSNAXコマンドとともにコマンド行パラメータを指定します。「ユーザーIDマッピングのバイパス」を参照してください。
注意:
直接ユーザーIDマッピングを使用する場合は、BDMCONFIGファイルのどのマッピング・エントリも変更および削除する必要はありません。
直接ユーザーIDマッピングでは、図4-3に示すように、ATMI環境とホスト環境のユーザーIDが同じである必要があります。ATMIのローカル・ドメインがリクエストを開始する場合は、リクエストされたホスト・サービスにはATMIのユーザーIDが適用されます。ホストがリクエストを開始する場合は、リクエストされたATMIサービスにはホストのユーザーIDが適用されます。
注意:
直接マッピングでは、セキュリティ・レベルIDENTIFYのみをサポートできます。
図4-3 直接ユーザーIDマッピング
ユーザーIDマッピングの構成
DMCONFIGおよびUBBCONFIGファイルの次の4つのセクションで、ローカル・ドメインおよびOracle Tuxedo Mainframe Adapter for SNAのセキュリティに関係するパラメータを指定します。
DMCONFIGファイルのDM_LOCAL_DOMAINSセクション
DMCONFIGファイルのDM_SNALINKSセクション
DMCONFIGファイルのDM_ACCESS_CONTROLセクション
UBBCONFIGファイルのRESOURCESセクション
セキュリティ・パラメータの決定
UBBCONFIGおよびDMCONFIGファイルの両方でSECURITYパラメータを設定すると、次の効果があります。
DM_LOCAL_DOMAINSのセキュリティ・パラメータをNONEまたはAPP_PWに設定した場合、ゲートウェイではセキュリティに関するアクションが実行されません。
ただし、UBBCONFIGファイルのセキュリティ・パラメータをAPP_PWに設定した場合は、クライアントがアプリケーションに参加するときに、アプリケーションのパスワードがAUTHSVCによって検証されます。AUTHSVCはユーザー・アプリケーションによって提供されます。
ホスト・システムからローカル・ドメインへのインバウンド・リクエストごとにローカル・ドメインとホスト・システムの両方によってセキュリティを実行する場合は、次の設定を行う必要があります。
UBBCONFIGファイルのSECURITYパラメータをUSER_AUTHACLまたはMANDATORY_ACLのいずれかに設定する必要があります。
DMCONFIGファイルのDM_LOCAL_DOMAINSセクションのSECURITYパラメータをDM_USER_PWに設定する必要があります。
DMCONFIGファイルのDM_SNALINKSSECURITYパラメータをIDENTIFYに設定する必要があります。
SNAスタックを、IDENTIFYの適切なパラメータを使用して構成する必要があります。
インバウンド・リクエストのセキュリティ・パラメータの決定
Oracle Tuxedo側の構成
表4-1に、ホスト・システムからのインバウンド・リクエストに対するローカル・ドメインとホスト・システムのセキュリティの組合せを実現するために必要な、UBBCONFIGおよびDMCONFIGファイルのSECURITYパラメータの設定を示します。
注意:
 

UBBCONFIG SECURITY

DM_LOCAL_DOMAINS SECURITY

DM_SNALINKS SECURITY
USER_AUTH、ACLまたは
MANDATORY_ACL
ホスト・システムから送信されるリクエストの場合、ローカル・ドメインが会話型通信起動リクエストからリモートのユーザーIDまたはユーザーIDおよびパスワードを抽出し、ドメイン・セキュリティ表をチェックします。この表には、ローカル・プリンシパル・ユーザーIDとリモート・ユーザーIDのペアが格納され、サービスごとに管理されています。リモート・ユーザーIDはローカル・プリンシパル・ユーザーIDにマップされています。ローカル・プリンシパル・ユーザーIDとパスワードは、UBBCONFIGファイルで指定されている詳細なACLチェックに使用されます。直接ユーザーIDマッピング・オプションが指定されている場合、リモート・ユーザーIDはローカル・プリンシパル・ユーザーIDとして使用されます。
ローカル・ドメインは、ホスト・システムからリクエストを受信すると、ローカル・サービスのDMCONFIGファイルのACLをチェックして、リモート・ドメインからのリクエストが許可されているかどうかを確認します。DMCONFIGファイルにACLが含まれない場合、サービスはすべてのリクエストからアクセス可能です。
メインフレーム側の構成
開始する前に、各VTAM LU 6.2ペアに関する次の情報をVTAMシステム管理者から入手してください。
次のいずれかの方法を選択して、z/OSでCRM LUを構成できます。
RDEFINE APPCLU local-netid.luid1.remote-netid.luid2 UACC(NONE) SESSION(SESSKEY(APPCPWD) CONVSEC(ALREADYV)
別の側面:
RDEFINE APPCLU local-netid.luid2.remote-netid.luid1 UACC(NONE) + SESSION(SESSKEY(APPCPWD) CONVSEC(ALREADYV))
RDEFINE APPCLU local-netid.luid1.luid2 UACC(NONE) SESSION(SESSKEY(APPCPWD) CONVSEC(ALREADYV))
別の側面:
RDEFINE APPCLU local-netid.luid2.luid1 UACC(NONE) + SESSION(SESSKEY(APPCPWD) CONVSEC(ALREADYV))
local-netid/remote-netid: パートナのネットワークID (NETID)。これらのIDは、SYS1.VTAMLSTATCSTRxxメンバー内にあるVTAM開始オプションNETIDで指定されます。
luid1/luid2: パートナのLU名。それぞれのケースで、最初に指定されるLU名はローカルLU名で、2番目のLU名はパートナLU名です。
注意:
最初の2つの修飾子(netidluid)にアスタリスク(*)や他の汎用文字を指定しないでください。
CRM LUのVTAM APPL定義を変更します。SECACPTパラメータは必須で、その値はALREADYVである必要があります。
アウトバウンド・リクエストのセキュリティ・パラメータの決定
ローカル・ドメインからのアウトバウンド・リクエストごとにローカル・ドメインとホスト・システムの両方によってセキュリティを実行する場合は、次の設定を行う必要があります。
UBBCONFIGファイルのSECURITYパラメータをUSER_AUTHACLまたはMANDATORY_ACLのいずれかに設定する必要があります。
DMCONFIGファイルのDM_LOCAL_DOMAINSセクションのSECURITYパラメータをDM_USER_PWに設定する必要があります。
DMCONFIGファイルのDM_SNALINKSSECURITYパラメータをIDENTIFYまたはVERIFYに設定する必要があります。
SNAスタックを、IDENTIFYまたはVERIFYの適切なパラメータを使用して構成する必要があります。
ホスト・システムの接続定義のATTACHSECレベルを、DMCONFIGファイルのDM_SNALINKSSECURITYパラメータと一致するよう、IDENTIFYまたはVERIFYに設定する必要があります。
Oracle Tuxedo側の構成
表4-2に、アウトバウンド・リクエストに対するローカル・ドメインとホスト・システムのセキュリティの組合せを実現するために必要な、UBBCONFIGおよびDMCONFIGファイルのSECURITYパラメータの設定を示します。
注意:
 

UBBCONFIG SECURITY

DM_LOCAL_DOMAINS SECURITY

DM_SNALINKS SECURITY
ホスト・システムに送信されるリクエストの場合、ローカル・プリンシパル・ユーザーIDがドメイン・セキュリティ表で特定され、関連するリモートのユーザーIDまたはユーザーIDおよびパスワードが会話型通信起動リクエストに配置された後で、LU6.2会話型通信で送信されます。このような状況が発生するのは、DMCONFIGファイルのDM_SNALINKSセクションでSECURITYIDENTIFYまたはVERIFYに設定されている場合です。直接ユーザーIDマッピング・オプションが指定されている場合、ローカル・プリンシパル・ユーザーIDは会話型通信起動リクエストに配置されます。
メインフレーム側の構成
メインフレーム側では、次のように設定します。
1.
SEC=YES
XTRAN=YES
これらを指定した場合、定義されたユーザーのみが対応するトランザクションにアクセスできます。
次のように、RACFを使用してプロファイルで有効なユーザーを定義できます。
PERMIT * CLASS(TCICSTRN) ID(GUMENG) ACCESS(READ)
個々のトランザクションを制御する場合は、*をトランザクション名に置き換えることができます。
2.
IDENTIFYまたはVERIFYの適切なパラメータを使用して、SNAスタックを構成します。
3.
ホスト・システムの接続定義のATTACHSECレベルを、DMCONFIGファイルのDM_SNALINKSのSECURITYパラメータと一致するよう、IDENTIFYまたはVERIFYに設定します。
DMCONFIGファイルのセキュリティ・パラメータの設定
DMCONFIGファイルの3つのセクションには、ATMIローカル・ドメインへのアクセスに対するOracle Tuxedo Mainframe Adapter for SNAによる制御に影響するパラメータが含まれています。
DM_LOCAL_DOMAINSセクションのSECURITYパラメータは、ATMIローカル・ドメインで実行するセキュリティのタイプを指定します。
DM_SNALINKSセクションのSECURITYパラメータは、ホスト・システムで実行されているセキュリティを記録します。
DM_ACCESS_CONTROLセクションのローカル・アクセス制御リストは、ATMIローカル・ドメインがローカル・リソースをそれらへのアクセス権限のあるホスト・システムと関連付けるために使用します。
注意:
dmloadcfコマンドを実行する前にDMCONFIGバイナリ・ファイルを削除しないでください。このファイルにはリモート・ユーザー、リモート・パスワードおよびリモート・マッピングの表が保管されています。削除すると、すべてのセキュリティ情報を再入力する必要が生じます。
DM_LOCAL_DOMAINSセクション
このセクションのSECURITYパラメータ設定は、ATMIローカル・ドメインのUBBCONFIGファイルのRESOURCESセクション内のSECURITYパラメータと連動して、Oracle Tuxedo Mainframe Adapter for SNAがATMIローカル・ドメインへのアクセスを制御する方法を設定します。このパラメータは次の形式を取ります。
SECURITY = {value}
このパラメータでは、valueを次のように設定できます。
NONE
セキュリティは実行されません。
APP_PW
セキュリティは実行されません。
DM_USER_PW
ユーザーおよびパスワードのセキュリティは実行されません。
このパラメータをNONEまたはAPP_PWに設定した場合、ローカル・ドメインはセキュリティに関するアクションを実行しません。このパラメータをDM_USR_PWに設定した場合は、ローカル・ドメインはUBBCONFIGファイルの設定に従ってセキュリティを実行します(「DMCONFIGファイルのセキュリティ・パラメータの設定」を参照)。
DM_SNALINKSセクション
DMCONFIGファイルのこのセクションは、Oracle Tuxedo Mainframe Adapter for SNAのパラメータ専用です。これはホスト・システムで実行されているセキュリティを記録します。これは接続リソース定義のATTACHSECパラメータに設定された値に関連付けられます。次のパラメータ定義において、リモートはATMIドメインを指し、ローカルはホスト・システムを指します。このパラメータは次の形式を取ります。
SECURITY_TYPE = {value}
このパラメータでは、valueを次のように設定できます。
LOCAL
ユーザー識別子がリモート・システムによって提供されないよう指定します。LOCALがデフォルト値です。
IDENTIFY
すべてのアタッチ・リクエスト時にユーザー識別子を要求するよう指定します。システムのすべてのリモート・ユーザーがリモートの外部セキュリティ・マネージャに対して識別される必要があります。
VERIFY
ユーザーIDおよび有効なパスワードをリモート・リージョンにアタッチします。ユーザーIDおよびパスワードはリージョンの外部セキュリティ・マネージャによって制御されます。
PERSISTENT
完全にはサポートされていません。VERIFYと同様に機能します。
MIXIDPE
完全にはサポートされていません。VERIFYと同様に機能します。
LOCALIDENTIFYは、DMCONFIGファイルのSECURITYパラメータのNONEおよびAPP_PWとほぼ等価です。
DM_ACCESS_CONTROLセクション
このセクションには、ATMIローカル・ドメインがリモート・リージョンによるローカル・リソースへのアクセスを制限するために使用するローカルACLが格納されます。Oracle Tuxedo 10.0または10gR3のドキュメントのATMIセキュリティ管理に関する項を参照してください。各エントリは、ACL_NAMEリソース識別子および、そのリソースにアクセスできるリモート・ドメインを指定する必須パラメータのリストから構成されます。ローカル・サービスに対するエントリがない場合、サービスはすべてのリモート・ドメインからアクセス可能になります。
UBBCONFIGファイルのセキュリティ・パラメータの設定
このファイルのRESOURCESセクションのSECURITYパラメータは、DMCONFIGファイルのSECURITYパラメータと連動して、Oracle Tuxedo Mainframe Adapter for SNAがATMIローカル・ドメインへのアクセスを制御する方法を設定します。このパラメータは次の形式を取ります。
SECURITY = {value}
このパラメータでは、valueを次のように設定できます。
NONE
セキュリティは実行されません(デフォルト)。
APP_PW
ローカル・アプリケーションに接続する際、ゲートウェイおよび管理ツールでのパスワード認証を要求します。
USER_AUTH
APP_PWと同じですが、ユーザーごとに追加の認証が必要です。
ACL
USER_AUTHと同じですが、サービス名、キュー名およびイベント名について追加のアクセス制御チェックが行われます。指定した名前に対するアクセス制御リスト(ACL)が存在しない場合は、アクセスが付与されます。
MANDATORY_ACL
ACLと同じですが、指定した名前に対するACLが存在しない場合は、アクセスが拒否されます。
ほとんどの場合、UBBCONFIGファイルはすでに構成されており、SECURITYパラメータを設定する必要はありませんが、このファイルを調べることで、Oracle Tuxedo Mainframe Adapter for SNAでセキュリティがどのように実行されるかを確認できます。
このパラメータをNONEに設定した場合、セキュリティは実行されません。APP_PWに設定した場合は、ローカルATMIドメインの認証サーバーはアプリケーションのパスワードの入力を求めます。USER_AUTHACLまたはMANDATORY_ACLに設定した場合は、指定したとおりの限定付きセキュリティが実行されます。
ユーザーIDマッピングのバイパス
直接ユーザーIDマッピングを使用するには、GWSNAXプロセス起動コマンド行エントリで-mパラメータを使用します。このパラメータにより、ATMI/ホスト間ユーザーIDマッピングでなく直接ユーザーIDマッピングを設定できます。
注意:
たとえば、ゲートウェイ・サーバー・プロセスを設定することでユーザーIDマッピングをバイパスする場合は、次の形式でコマンドを入力します。
GWSNAX SRVGRP = <groupname> SRVID = <number> CLOPT = "-A -- -m"
詳細は、付録A「管理コマンド・リファレンス・ページ」「GWSNAX」を参照してください。
dmadminコマンドを使用したユーザーIDマッピングの管理
ATMI/ホスト間ユーザーIDマッピングを使用する場合は、BDMCONFIGファイル内にマッピングを作成する必要があります。
注意:
直接ユーザーIDマッピング・オプションを指定した場合、BDMCONFIGファイル内にマッピングを作成する必要はありません。BDMCONFIGファイルのマッピングはすべて無視されます。
ローカル・ドメインとホスト・システムの間のユーザーIDマッピングを構成するには、dmadminユーティリティのaddumapaddusrdelumapmodusrおよびdelusrコマンドを使用して次のタスクを完了します。
各ATMIコマンドの詳細は、付録A「管理コマンド・リファレンス・ページ」を参照してください。
これらのコマンドを使用するには、システム・プロンプトでdmadminを入力します。dmadminの">"プロンプトで、説明されているとおりにコマンドを入力します。
ユーザーおよびパスワードの追加
ATMIローカル・ドメインのユーザーIDおよびパスワードをリモート・ドメインのユーザー/パスワード・ファイルに追加するには、addusr ATMIコマンドを使用します。次のコマンドを入力します。
addusr {-d} local_domain_id {-R} remote_domain_id {-u} remote_userid [{-w}]
このコマンドの引数およびオプションは次のように定義されています。
-d
ユーザーIDおよびパスワードを関連付けるローカル・ドメインの名前を指定します。
-R
ユーザーIDおよびパスワードを追加するリモート・ドメインの名前を指定します。
-u
追加するユーザー名を指定します。要求されたら、ユーザーのパスワードを入力します。
-w
パスワードを要求しないよう指定します。IDENTIFYを使用して実行する場合に使用します。
ユーザーIDのマッピング
ローカル・ドメインのプリンシパル・ユーザーID番号をリモート・ドメインのユーザー名にマップするには、addumap ATMIコマンドを使用します。ユーザーIDはマップする前に追加しておく必要があります。「ユーザーおよびパスワードの追加」を参照してください。次のコマンドを入力します。
addumap {-d} local_domain_id {-R} remote_domain_id
{-p} local_principal_userid {-u} remote_userid
このコマンドの引数およびオプションは次のように定義されています。
-d
ユーザーIDを関連付けるローカル・ドメインの名前を指定します。
-R
ユーザーIDをマップするリモート・ドメインの名前を指定します。
-p
tpusrに定義されているローカル・プリンシパル・ユーザーID番号を指定します。
-u
リモート・ドメインのセキュリティ・アプリケーションに定義されているリモート・ユーザー名を指定します。
ユーザーIDマッピングの削除
リモート・ドメインのユーザー名に対するローカル・ドメインのプリンシパル・ユーザーIDのマッピングを削除するには、delumap ATMIコマンドを使用します。次のコマンドを入力します。
delumap {-d} local_domain_id {-R} remote_domain_id
{-p} local_principal_userid {-u} remote_userid
このコマンドの引数およびオプションは次のように定義されています。
-d
ユーザーIDを関連付けるローカル・ドメインの名前を指定します。
-R
ユーザーIDをマップするリモート・ドメインの名前を指定します。
-p
tpusrに定義されているローカル・プリンシパル・ユーザーID番号を指定します。
-u
リモート・ドメインのセキュリティ・アプリケーションに定義されているリモート・ユーザー名を指定します。
ユーザーIDおよびパスワードの削除
リモート・ドメインのユーザー/パスワード・ファイルからローカルATMIドメインのユーザーIDおよびパスワードを削除するには、delusr ATMIコマンドを使用します。ユーザーIDを削除する前に、ユーザーIDのマッピングを削除しておく必要があります。次のコマンドを入力します。
delusr {-d} local_domain_id {-R} remote_domain_id {-u} remote_userid
このコマンドの引数およびオプションは次のように定義されています。
-d
ユーザーIDおよびパスワードを関連付けるローカル・ドメインの名前を指定します。
-R
ユーザーIDおよびパスワードを削除するリモート・ドメインの名前を指定します。
-u
削除するユーザー名を指定します。
パスワードの変更
リモート・ドメインのユーザー/パスワード・ファイルに記録されたローカル・ドメイン・ユーザーのパスワードを変更するには、modusr ATMIコマンドを使用します。次のコマンドを入力します。
modusr {-d} local_domain_id {-R} remote_domain_id {-u} remote_userid [{-w}]
このコマンドの引数およびオプションは次のように定義されています。
-d
ユーザーIDおよびパスワードを関連付けるローカル・ドメインの名前を指定します。
-R
ユーザーIDおよびパスワードを変更するリモート・ドメインの名前を指定します。
-u
変更するユーザー名を指定します。要求されたら、ユーザーのパスワードを入力します。
-w
パスワードを要求しないよう指定します。IDENTIFYを使用して実行する場合に使用します。
セキュリティの設定例
この項では、すでに構成されているアプリケーションでセキュリティを設定する場合の段階的手順を例で示します。
ATMIドメインのセキュリティの構成
1.
UBBCONFIGファイルを編集します。
a.
RESOURCESセクションにSECURITY USER_AUTHを追加します。
b.
SERVERSセクションにAUTHSVRサーバーを追加します。
注意:
SECURITY USER_AUTHレベルは、アプリケーションに参加するにはアプリケーション・パスワード、ユーザーIDおよびユーザー・パスワードが必要であることを意味します。AUTHSVRはATMIが提供する認証サーバーです。これはAUTHSVCサービスを公開します。
2.
tmloadcfコマンドを入力してATMI構成をロードします(次はその例です)。
tmloadcf -y ubbconfig.sna
3.
アプリケーション・パスワードを設定します。(tmloadcfコマンドにより、アプリケーション・パスワードを入力するよう要求されます。)
4.
tpusraddコマンドを使用してATMIドメインにユーザーを追加します。このコマンドにより、各ユーザーのパスワードを入力するよう要求されます(次はその例です)。
tpusradd me
(meのパスワードを入力します。)
注意:
tpaddusrコマンドを使用しないでください。
5.
tpinitの呼出しでセキュリティ・パラメータを指定するようATMIクライアントを変更します。リスト4-1は、これを行うためのコードの例です。
リスト4-1 tpinitの呼出しへのセキュリティ・パラメータの追加
TPINIT *tpinitbuf;
char passwd[30];
int security_level;
/* Initialize security parameters */
if ((tpinitbuf = (TPINIT *) tpalloc("TPINIT", NULL,
TPINITNEED(sizeof(passwd)))) == NULL)
{
userlog("tpalloc tpinit failed %s \n", tpstrerror(tperrno));
exit(1);
}
strcpy(tpinitbuf->usrname,"");
strcpy(tpinitbuf->cltname,"");
strcpy(tpinitbuf->passwd,"");
strcpy(tpinitbuf->grpname,"");
/* Determine level of enforced security */
security_level = tpchkauth();

if ((security_level == TPSYSAUTH) || (security_level ==
TPAPPAUTH))
{
fprintf(stdout,"\nApplication passwd required.");
fprintf(stdout,"\nApplication passwd:");
gets(tpinitbuf->passwd);
}
if (security_level == TPAPPAUTH)
{
fprintf(stdout,"\nUser Name required.");
fprintf(stdout,"\nUser Name:");
gets(tpinitbuf->usrname);

fprintf(stdout,"\nUser Password required.");
fprintf(stdout,"\nUser Password:");
gets(passwd);
strcpy(&tpinitbuf->data,passwd);
tpinitbuf->datalen=strlen(passwd);
}
if (tpinit(tpinitbuf) == -1)
{
userlog("TPINIT %s \n", tpstrerror(tperrno));
exit(1);
}
 
6.
7.
dmloadcfコマンドを入力してドメイン構成をロードします。次に例を示します。
dmloadcf -y dmconfig.sna
8.
tmbootコマンドを入力してATMIドメインを起動します(次はその例です)。
tmboot -y
9.
DMCONFIGファイルを編集してSNAドメインのセキュリティを構成します。
a.
DM_LOCAL_DOMAINSセクションに次のパラメータを追加します。
SECURITY=DM_USER_PW
b.
DM_SNALINKSセクションにリモート・リンクのパラメータを追加します。
SECURITY=VERIFY
10.
dmadminを起動し、addumapコマンドを使用してローカル・ユーザーIDをリモート・ユーザーIDにマップし、リモート・ドメインのユーザー名マッピングを追加します。次に例を示します。
dmadmin
>addumap -d myldom -R myrdom -p localme -u REMOTEME
11.
dmadminを起動し、addusrコマンドを使用してリモート・パスワードを入力し、リモート・ドメインのリモート・ユーザーIDのパスワードを追加します。次に例を示します。
dmadmin
>addusr -d myldom -R myrdom -u REMOTEME
(次のプロンプトが表示されます。
エラー: リモート・ユーザーのパスワードを入力してください:
エラー: リモート・ユーザーのパスワードを再入力してください:
)
ローカル・ドメインのセキュリティの構成
ローカル・ドメインのセキュリティを構成するには、次のようにします。
該当するスタック・ドキュメントを参照してください。
リモート・ドメインのセキュリティの構成
メインフレームの接続定義のセキュリティを変更するには、次のようにします。
1.
CEDA EX GR(MYCONNGRP)
MYCONNGRPを、接続定義を含むグループの名前に置き換えます。
2.
各接続定義のATTACHSECの値をVERIFYに変更して、各接続定義のセキュリティを変更します。
3.
接続のCEMT I CONN(MYCN)に対する照会を行って接続に移動し、INSエントリをOUTに変更して、各接続のサービスを停止します。
4.
CEDA I GR(MYCONNGRP)
MYCONNGRPを、接続定義を含むグループの名前に置き換えます。
5.
セキュリティ・レベルのIDENTIFYへの設定
セキュリティ・レベルIDENTIFYを使用して前述の例を構成するには、次の手順を実行します。
1.
DMCONFIGファイルのSECURITYパラメータをIDENTIFYに変更します。
2.
接続のATTACHSECパラメータをIDENTIFYに変更します。
リンクレベルの暗号化の使用
分散ネットワークでのCommunication Resource Manager (CRM)とゲートウェイ(GWSNAX)間のセキュアな通信を確立するため、Oracle Tuxedo Mainframe Adapter for SNAではリンクレベルの暗号化プロセスを使用しています。
暗号化プロセスの図
次の図に示すように、この暗号化機能はOracle Tuxedo Mainframe Adapter for SNA GatewayとCRM間のリンクにのみ適用されます。
注意:
図4-4 リンクの暗号化
暗号化プロセスは次のように行われます。
1.
2.
各プロセスには、プロセス起動コマンド行で指定された、許容可能な暗号化レベルの範囲があります。共通する最も低い暗号化レベルが使用されます。
注意:
Oracle Tuxedo Mainframe Adapter for SNA GatewayとCRMの構成
Oracle Tuxedo Mainframe Adapter for SNA Gatewayを構成するには、次のようにします。
1.
暗号化レベルの許容範囲(minmax)を決定します。
2.
UBBCONFIGファイルのGWSNAXエントリを編集し、目的のminmaxを指定して-nオプションを追加します。
付録A「管理コマンド・リファレンス・ページ」「GWSNAX」を参照してください。
CRMを構成するには、次のようにします。
1.
暗号化レベルの許容範囲(minmax)を決定します。
2.
CRMをコマンド行から起動する場合は、付録A「管理コマンド・リファレンス・ページ」「SNACRM」の説明に従って、目的のminmaxを指定して-nオプションを追加します。
CRMをATMIサーバーとして起動する場合は、付録A「管理コマンド・リファレンス・ページ」「SNACRM」の説明に従って、SNACRMサーバー・エントリを変更し、目的のminmaxを指定して-nオプションを追加します。
暗号化したCRMでcrmlkoffcrmlkonまたはcrmdownを使用する場合、追加のコマンド行引数は必要ありません。
SSL暗号化の使用
分散ネットワーク上でCommunication Resource Manager (CRM)とゲートウェイ(GWSNAX)の間にSSLを確立する場合、Oracle Tuxedo Mainframe Adapter for SNAではGWSNAXとCRMの両側でSSLを有効にする必要があります。
暗号化プロセスは次のように行われます。
1.
2.
各プロセスには、プロセス起動コマンド行で指定された、許容可能な暗号スイートの範囲があります。サポートされている最も強力な暗号スイートが使用されます。
Oracle Tuxedo Mainframe Adapter for SNA GatewayとCRMの構成
Oracle Tuxedo Mainframe Adapter for SNA Gatewayを構成するには、次のようにします。
1.
UBBCONFIGファイルのGWSNAXエントリを編集し、目的のminmaxを指定してCPLOTに-nオプションを追加し、暗号スイートの許容範囲を決定します。
2.
UBBCONFIGファイルの*MACHINESセクションでGWSNAXプロセスのSEC_PRINCIPAL_NAMESEC_PRINCIPAL_LOCATIONおよびSEC_PRINCIPAL_PASSVARパラメータを定義します。
HP-UXにデプロイされたCRMを構成するには、次のようにします。
1.
CRMコマンド行で目的のminmaxを指定してCRM -nオプションを定義し、暗号スイートの許容範囲を決定します(-n SSL:min:max)。
2.
-Sを定義してSSL構成ファイルを指定します。
3.
-Sオプションで指定されたSSL構成ファイルでCRMプロセスのSEC_PRINCIPAL_NAMESEC_PRINCIPAL_LOCATIONおよびSEC_PRINCIPAL_PASSVARパラメータを編集します。
z/OSにデプロイされたCRMを構成するには、次のようにします。
1.
CRMコマンド行で-Sを定義してSSL構成ファイルを指定します。
2.
-Sオプションで指定されたSSL構成ファイルでGSK_KEYRING_FILEGSK_KEYRING_PWおよびGSK_KEYRING_LABELを編集します。
GSK_KEYRING_FILEは、セキュア・セッションまたはSSL環境の証明書ファイルの絶対パスを示します。
GSK_KEYRING_PWは、セキュア・セッションまたはSSL環境で使用される証明書ストア・ファイルのパスワードを指します。
GSK_KEYRING_LABELは、セキュア・セッションまたはSSL環境で使用される証明書ストア内の証明書に関連付けられた証明書ラベルを示します。
CRMのSSL暗号化構成ファイルのサンプル
HP-UXにデプロイされたCRMの構成ファイル:
SEC_PRINCIPAL_NAME=slc05are
SEC_PRINCIPAL_LOCATION=/storage/cert
SEC_PRINCIPAL_PASSVAR=password
SEC_TRACE_LEVEL=3
z/OSにデプロイされたCRMの構成ファイル:
GSK_KEYRING_LABEL=slc05are
GSK_KEYRING_FILE=/storage/CERTDB
GSK_KEYRING_PW=password
GSK_TRACE_LEV=3
TCP/IPリンク認証の使用
暗号化に加えて、Oracle Tuxedo Mainframe Adapter for SNAでは認証プロセスを使用して、分散ネットワークでのCRMとGateway間のセキュアな通信を確立します。
表4-3は、認証をサポートするプロセスのリストです。
 
一方向の認証をサポートします。CRMはcrmlkonプログラムを認証しますが、その逆は行われません
一方向の認証をサポートします。CRMはcrmlkoffプログラムを認証しますが、その逆は行われません
一方向の認証をサポートします。CRMはcrmdownプログラムを認証しますが、その逆は行われません
認証プロセスの図
次の図に示すように、この認証機能はゲートウェイとCRM間のリンクにのみ適用されます。
図4-5 リンクの認証
ゲートウェイがCRMへの接続を確立する際、次のイベントが行われます。
1.
2.
3.
Oracle Tuxedo Mainframe Adapter for SNA GatewayとCRMの認証用の構成
ゲートウェイを認証用に構成するには、次の手順に従います。
1.
保護された場所にkeyfileを格納します。
2.
付録A「管理コマンド・リファレンス・ページ」「GWSNAX」の説明に従って、次の形式の一般的なコマンド行エントリを使用して認証を設定します。
[-u <keyfile>]
CRMを構成するには、次のようにします。
1.
保護された場所にkeyfileを格納します。
2.
CRMをコマンド行から起動する場合は、付録A「管理コマンド・リファレンス・ページ」「SNACRM」の説明に従って、-u<keyfile>オプションを追加します。
CRMをATMIサーバーとして起動する場合は、付録A「管理コマンド・リファレンス・ページ」「SNACRM」の説明に従って、SNACRMサーバー・エントリを変更して-u<keyfile>オプションを追加します。
3.
認証が有効なCRMでcrmlkoffcrmlkonまたはcrmdownを使用する場合は、付録A「管理コマンド・リファレンス・ページ」「SNACRM」の説明に従って、-u<keyfile>コマンド行オプションを使用します。
 

Copyright ©1994, 2017,Oracle and/or its affiliates. All rights reserved