|
|
セキュリティとは、コンピュータ内のデータまたはコンピュータ間で送受信されるデータが損なわれないことを保証する技術のことです。ほとんどのセキュリティ機能では、パスワードおよびデータの暗号化を使用してセキュリティを実現します。パスワードとは、秘密の文字列であり、ユーザーは、これを入力することにより特定のプログラムやシステムにアクセスできます。データの暗号化とは、データを理解できない形式に変換することであり、変換されたデータは復号化のメカニズムがないと解読できません。
| 注意: | ATMIファイル、機能およびドキュメントに関する記述はすべて、Tuxedoファイル、機能およびドキュメントに適用されます。 |
電子商取引などで使用される分散アプリケーションには、悪質なユーザーがデータを傍受したり、操作を中断したり、不正な情報を入力できるアクセス・ポイントが多数あります。ビジネスがより広い範囲に分散されるほど、こうした悪質なユーザーによる攻撃を受けやすくなります。したがって、このようなアプリケーションの基盤となる分散型のコンピューティング・ソフトウェア、つまりミドルウェアは、セキュリティ機能を備えている必要があります。
Oracle Tuxedo Mainframe Adapter for SNAは、ATMIプラットフォームで動作して、次のセキュリティ機能を実現します。
ユーザーIDはATMIおよびメインフレーム環境のシステム・リソースへのアクセスを制御するために使用されます。ATMIおよびメインフレーム環境がユーザーIDを使用するにはいずれの側もセキュリティ・メカニズムを配備しておく必要があります。ATMIドメインでは、セキュリティ・メカニズムは認証サーバーです。ホスト・システムでは、セキュリティ・メカニズムは外部セキュリティ・マネージャです。図4-1は、Oracle Tuxedo Mainframe Adapter for SNAのセキュリティ要素を示します。
Oracle Tuxedo Mainframe Adapter for SNAソフトウェアでは、ドメイン間でユーザーIDを2つの方法で共有できます。
| 警告: | 混合環境でのセキュリティは図4-1に示されているより複雑です。稼働するセキュリティ・メカニズムが配備されていないドメインは、ユーザーIDを「信頼できるユーザー」とみなしてすべてのトランザクション・リクエストを受け入れます。ドメイン・セキュリティの詳細は、該当するATMI製品ドキュメントを参照してください。 |
ATMI/ホスト間ユーザーIDマッピングは、ローカル・ドメインのユーザーIDをホスト・システムの対応するユーザーIDと関連付けます。ATMI/ホスト間ユーザーIDマッピングにより、ATMIのユーザーIDがホストのユーザーIDと一致しなくてもよくなります。図4-2を参照してください。
この種類のマッピングを作成するには、dmadminコマンドを使用します。「dmadminコマンドを使用したユーザーIDマッピングの管理」を参照してください。このコマンドはDMCONFIGファイルのバイナリ形式版(BDMCONFIGファイル)を変更します。
直接ユーザー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が適用されます。
| 注意: | 直接ユーザーIDマッピングを使用するには、ローカル・ドメインとホスト・ドメインとで一致するユーザーIDが存在している必要があります。 |
| 注意: | 直接マッピングでは、セキュリティ・レベルIDENTIFYのみサポートされます。 |
DMCONFIGおよびUBBCONFIGファイルの次の4つのセクションに、ローカル・ドメインおよびOracle Tuxedo Mainframe Adapter for SNAのセキュリティに関係するパラメータを指定します。
UBBCONFIGおよびDMCONFIGファイルの両方でSECURITYパラメータを設定すると、次の効果があります。
ホスト・システムからローカル・ドメインへのインバウンド・リクエストごとにローカル・ドメインとホスト・システムの両方によってセキュリティを実行する場合は、次の設定を行う必要があります。
UBBCONFIGファイルのSECURITYパラメータをUSER_AUTH、ACLまたはMANDATORY_ACLのいずれかに設定する必要があります。DMCONFIGファイルの DM_LOCAL_DOMAINSセクションのSECURITYパラメータをDM_USER_PWに設定する必要があります。DMCONFIGファイルのDM_SNALINKSのSECURITYパラメータをIDENTIFYに設定する必要があります。IDENTIFYの適切なパラメータを使用して構成する必要があります。ATTACHSECレベルを、DMCONFIGファイルのDM_SNALINKSのSECURITYパラメータと一致するよう、IDENTIFYまたはVERIFYに設定する必要があります。 表4-1は、ホスト・システムからのインバウンド・リクエストに対するローカル・ドメインとホスト・システムのセキュリティの組合せを実現するために必要な、UBBCONFIGおよびDMCONFIGファイルのSECURITYパラメータの設定を示します。
| 注意: | 表に示されていないセキュリティ設定の組合せは、予期しない結果をもたらします。 |
ホスト・システムから送信されるリクエストごとに、ローカル・ドメインが会話型通信起動リクエストからリモートのユーザーIDまたはユーザーIDおよびパスワードを抽出し、ドメイン・セキュリティ表を確認します。この表には、サービスごとに保守されるローカル・プリンシパル・ユーザーIDおよびリモート・ユーザーIDのペアが含まれています。リモート・ユーザーIDはローカル・プリンシパル・ユーザーIDにマップされています。ローカル・プリンシパル・ユーザーIDとパスワードは、UBBCONFIGファイルに指定されている詳細なACLチェックに使用されます。直接ユーザーIDマッピング・オプションが指定されている場合、リモート・ユーザーIDはローカル・プリンシパル・ユーザーIDとして使用されます。
ローカル・ドメインは、ホスト・システムからリクエストを受信すると、ローカル・サービスのDMCONFIGファイルのACLをチェックし、リモート・ドメインからのリクエストが許可されているか確認します。DMCONFIGファイルにACLが含まれない場合、サービスはすべてのリクエストからアクセス可能です。
ローカル・ドメインからのアウトバウンド・リクエストごとにローカル・ドメインとホスト・システムの両方によってセキュリティを実行する場合は、次の設定を行う必要があります。
UBBCONFIGファイルのSECURITYパラメータをUSER_AUTH、ACLまたはMANDATORY_ACLのいずれかに設定する必要があります。 DMCONFIGファイルの DM_LOCAL_DOMAINSセクションのSECURITYパラメータをDM_USER_PWに設定する必要があります。 DMCONFIGファイルのDM_SNALINKSのSECURITYパラメータをIDENTIFYまたはVERIFYに設定する必要があります。IDENTIFYまたはVERIFYの適切なパラメータを使用して構成する必要があります。ATTACHSECレベルを、DMCONFIGファイルのDM_SNALINKSのSECURITYパラメータと一致するよう、IDENTIFYまたはVERIFYに設定する必要があります。 表4-2は、アウトバウンド・リクエストに対するローカル・ドメインとホスト・システムのセキュリティの組合せを実現するために必要な、UBBCONFIGおよびDMCONFIGファイルのSECURITYパラメータの設定を示します。
| 注意: | 表に示されていないセキュリティ設定の組合せは、予期しない結果をもたらします。 |
ホスト・システムに送信されたリクエストに対して、ローカル・プリンシパル・ユーザーIDがドメイン・セキュリティ表で特定され、関連するリモートのユーザーIDまたはユーザーIDおよびパスワードが、会話型通信起動スクリプトに配置された後で、LU6.2会話型通信で送信されます。このような状況が発生するのは、DMCONFIGファイルのDM_SNALINKSセクションのSECURITYがIDENTIFYまたはVERIFYに設定されている場合です。直接ユーザーIDマッピング・オプションが指定されている場合、ローカル・プリンシパル・ユーザーIDは会話型通信起動リクエストに配置されます。
DMCONFIGファイルの3つのセクションには、ATMIローカル・ドメインへのアクセスに対するOracle Tuxedo Mainframe Adapter for SNAによる制御に影響するパラメータが含まれています。
| 警告: | dmloadcfコマンドを実行する前にDMCONFIGバイナリ・ファイルを削除しないでください。このファイルにはリモート・ユーザー、リモート・パスワードおよびリモート・マッピングの表が保管されています。削除すると、すべてのセキュリティ情報を再入力する必要が生じます。 |
このセクションのSECURITYパラメータ設定は、ATMIローカル・ドメインのUBBCONFIGファイルのRESOURCESセクション内のSECURITYパラメータと連動し、ATMIローカル・ドメインへのアクセスのOracle Tuxedo Mainframe Adapter for SNAによる制御方法を設定します。このパラメータは次の形式を取ります。
SECURITY = {value}なし
APP_PW
DM_USER_PW
このパラメータをNONEまたはAPP_PWに設定した場合は、ローカル・ドメインはセキュリティに関するアクションを実行しません。このパラメータをDM_USR_PWに設定した場合は、ローカル・ドメインはUBBCONFIGファイルの設定に従ってセキュリティを実行します(「DMCONFIGファイルのセキュリティ・パラメータの設定」を参照)。
このDMCONFIGファイルのセクションはOracle Tuxedo Mainframe Adapter for SNAパラメータ専用です。これはホスト・システムで実行されているセキュリティを記録します。これは接続リソース定義のATTACHSECパラメータに設定された値に関連付けられます。次のパラメータ定義において、リモートはATMIドメインを指し、ローカルはホスト・システムを指します。このパラメータは次の形式を取ります。
SECURITY_TYPE = {value}“LOCAL"
IDENTIFY
VERIFY
PERSISTENT
MIXIDPE
値LOCALとIDENTIFYは、DMCONFIGファイルのSECURITYパラメータのNONEおよびAPP_PWとほぼ等価です。
このセクションのローカルACLを使用して、ATMIローカル・ドメインがリモート・リージョンによるローカル・リソースへのアクセスを制限します。(Oracle Tuxedo 10.0または10gR3ドキュメントのATMIセキュリティ管理に関する項を参照してください。)各エントリは、ACL_NAMEリソース識別子および、そのリソースにアクセスできるリモート・ドメインを指定する必須パラメータのリストから構成されます。ローカル・サービスに対するエントリがない場合、サービスはすべてのリモート・ドメインからアクセス可能になります。
このファイルのRESOURCESセクションのSECURITYパラメータは、DMCONFIGファイルのSECURITYパラメータと連動し、ATMIローカル・ドメインへのアクセスのOracle Tuxedo Mainframe Adapter for SNAによる制御方法を設定します。このパラメータは次の形式を取ります。
SECURITY = {value}なし
APP_PW
USER_AUTH
ACL
USER_AUTHと基本的に同じですが、サービス名、キュー名およびイベント名について追加のアクセス制御チェックが行われる点が異なります。指定した名前に対するアクセス制御リスト(ACL)が存在しない場合は、アクセスが付与されます。
MANDATORY_ACL
UBBCONFIGファイルのSECURITYパラメータ設定は構成しなくても済む場合がほとんどですが、このファイルを確認することでOracle Tuxedo Mainframe Adapter for SNAによるセキュリティ実行方法を理解できるようになります。
このパラメータをNONEに設定した場合は、セキュリティは実行されません。APP_PWに設定した場合は、ローカルATMIドメインの認証サーバーはアプリケーションのパスワードの入力を求めます。USER_AUTH、ACLまたはMANDATORY_ACLに設定した場合は、指定したとおりの限定付きセキュリティが実行されます。
直接ユーザーIDマッピングを使用するには、GWSNAXプロセス起動コマンドライン・エントリで-mパラメータを使用します。このパラメータにより、ATMI/ホスト間ユーザーIDマッピングでなく直接ユーザーIDマッピングを設定できます。
| 注意: | ユーザーIDマッピングをバイパスする場合は、ローカル・ドメインとホスト・ドメインが同じユーザーIDを使用している必要があり、そうでないとセキュリティ・エラーが発生します。 |
たとえば、ゲートウェイ・サーバー・プロセスを設定することでユーザーIDマッピングをバイパスする場合は、次の形式でコマンドを入力します。
GWSNAX SRVGRP = <groupname> SRVID = <number> CLOPT = "-A -- -m"
詳細は、付録A「管理コマンド・リファレンス ページ」の「GWSNAX」を参照してください。
ATMI/ホスト間ユーザーIDマッピングを使用する際は、マッピングをBDMCONFIGファイル内に作成します。
| 注意: | 直接ユーザーIDマッピング・オプションを指定する場合は、BDMCONFIGファイルにマッピングを作成する必要はありません。BDMCONFIGファイルのマッピングはすべて無視されます。 |
ローカル・ドメインとホスト・システム間でのユーザーIDマッピングを構成するには、dmadminユーティリティのaddumap、addusr、delumap、modusrおよびdelusrコマンドを使用して次のタスクを完了します。
行ATMIコマンドの詳細は、付録A「管理コマンド・リファレンス ページ」を参照してください。
これらのコマンドを使用するには、システム・プロンプトでdmadminを入力します。dmadminの">"プロンプトで、説明されているとおりにコマンドを入力します。
ATMIローカル・ドメインのユーザーIDおよびパスワードをリモート・ドメインのユーザー/パスワード・ファイルに追加するには、addusr ATMIコマンドを使用します。次のコマンドを入力します。
addusr {-d} local_domain_id {-R} remote_domain_id {-u} remote_userid [{-w}]このコマンドの引数およびオプションは次のように定義されています。
-d
-R
-u
-w
ローカル・ドメインのプリンシパル・ユーザーID番号をリモート・ドメインのユーザー名にマップするには、addumap ATMIコマンドを使用します。ユーザーIDはマップする前に追加しておく必要があります。「ユーザーIDおよびパスワードの追加」の項を参照してください。次のコマンドを入力します。
addumap {-d} local_domain_id {-R} remote_domain_id
{-p} local_principal_userid {-u} remote_useridこのコマンドの引数およびオプションは次のように定義されています。
-d
-R
-p
-u
リモート・ドメインのユーザー名に対するローカル・ドメインのプリンシパル・ユーザーIDのマッピングを削除するには、delumap ATMIコマンドを使用します。次のコマンドを入力します。
delumap {-d} local_domain_id {-R} remote_domain_id
{-p} local_principal_userid {-u} remote_useridこのコマンドの引数およびオプションは次のように定義されています。
-d
-R
-p
-u
リモート・ドメインのユーザー/パスワード・ファイルからローカルATMIドメインのユーザーIDおよびパスワードを削除するには、delusr ATMIコマンドを使用します。ユーザーIDを削除する前に、ユーザーIDのマッピングを削除しておく必要があります。次のコマンドを入力します。
delusr {-d} local_domain_id {-R} remote_domain_id {-u} remote_useridこのコマンドの引数およびオプションは次のように定義されています。
-d
-R
-u
リモート・ドメインのユーザー/パスワード・ファイルに記録されたローカル・ドメイン・ユーザーのパスワードを変更するには、modusr ATMIコマンドを使用します。次のコマンドを入力します。
modusr {-d} local_domain_id {-R} remote_domain_id {-u} remote_userid [{-w}]このコマンドの引数およびオプションは次のように定義されています。
-d
-R
-u
-w
この項では、すでに構成されているアプリケーションでセキュリティを設定する場合の段階的手順を例で示します。
UBBCONFIGファイルを編集します。tmloadcfコマンドを入力してATMI構成をロードします(次はその例です)。tmloadcf -y ubbconfig.sna
tmloadcfコマンドにより要求されます。)tpusraddコマンドを使用してATMIドメインにユーザーを追加します。このコマンドにより、各ユーザーのパスワードを入力するよう要求されます(次はその例です)。tpusradd me
| 注意: | tpaddusrコマンドは使用しないでください。 |
tpinitコールにセキュリティ・パラメータを指定するようATMIクライアントを修正します。リスト4-1はこれを行うコードの例です。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);
}
dmloadcfコマンドを入力してドメイン構成をロードします。次はその例です。dmloadcf -y dmconfig.sna
tmbootコマンドを入力してATMIドメインを起動します(次はその例です)。tmboot -y
DMCONFIGファイルを編集してSNAドメインのセキュリティを構成します。dmadminを起動してaddumapコマンドを使用し、ローカル・ユーザーIDをリモート・ユーザーIDにマップしてリモート・ドメインにユーザー名マッピングを追加します。次はその例です。dmadmin
>addumap -d myldom -R myrdom -p localme -u REMOTEME
dmadminを起動してaddusrコマンドを使用し、リモート・パスワードを入力してリモート・ドメインのリモート・ユーザーIDにパスワードを追加します。次はその例です。dmadmin
>addusr -d myldom -R myrdom -u REMOTEME
エラー: リモート・ユーザーのパスワードを入力してください:)
エラー: リモート・ユーザーのパスワードを再入力してください:
ローカル・ドメインのセキュリティを構成するには、次のようにします。
メインフレームの接続定義のセキュリティを変更するには、次のようにします。
CEDA EX GR(MYCONNGRP) MYCONNGRPを、接続定義を含むグループの名前に置き換えます。
ATTACHSECの値をVERIFY に変更して、各接続定義のセキュリティを変更します。CEMT I CONN(MYCN)に対する照会を行って接続に移動し、INSエントリをOUTに変更して各接続のサービスを停止します。CEDA I GR(MYCONNGRP) MYCONNGRPを、接続定義を含むグループの名前に置き換えます。
前の例をIDENTIFYのセキュリティ・レベルに構成するには、次の手順を完了します。
分散ネットワークでのCommunication Resource Manager(CRM)とゲートウェイ(GWSNAX)間のセキュアな通信を確立するため、Oracle Tuxedo Mainframe Adapter for SNAではリンクレベルの暗号化プロセスを使用しています。
次の図に示すように、この暗号化機能はOracle Tuxedo Mainframe Adapter for SNA GatewayとCRM間のリンクにのみ適用されます。
| 注意: | 暗号化を有効にするには、適切なATMIセキュリティ・アドオン(40ビットまたは128ビット)を購入しておく必要があります。 |
| 注意: | CRMとゲートウェイの通信に暗号化を設定すると、システム・パフォーマンスが低下する可能性があります。暗号化レベルが高いほど、低下が発生する可能性が高くなります。 |
Oracle Tuxedo Mainframe Adapter for SNA Gatewayを構成するには、次のようにします。
minとmax)を決定します。UBBCONFIGファイルのGWSNAXエントリを編集し、-nオプションを追加して、目的のminとmaxを設定します。 付録A「管理コマンド・リファレンス ページ」の「GWSNAX」を参照してください。
minとmax)を決定します。minとmaxを設定します(詳細は付録A「管理コマンド・リファレンス ページ」の「SNACRM」を参照)。SNACRMサーバー・エントリを修正し、-nオプションを追加して目的のminとmaxを設定します(詳細は付録A「管理コマンド・リファレンス ページ」の「SNACRM」を参照)。 暗号化したCRMでcrmlkoff、crmlkonまたはcrmdownを使用する場合は、追加のコマンドライン引数は必要ありません。
暗号化に加えて、Oracle Tuxedo Mainframe Adapter for SNAでは認証プロセスを使用して、分散ネットワークでのCRMとGateway間のセキュアな通信を確立します。
表4-3は、認証をサポートするプロセスを示します。
次の図に示すように、この認証機能はゲートウェイとCRM間のリンクにのみ適用されます。
ゲートウェイがCRMへの接続を確立する際、次のイベントが行われます。
「GWSNAX」を参照)。[-u <keyfile>]
-u<keyfile>オプションを追加します(詳細は付録A「管理コマンド・リファレンス ページ」の「SNACRM」を参照)。SNACRMサーバー・エントリを修正し、-u<keyfile>オプションを追加します(詳細は付録A「管理コマンド・リファレンス ページ」の「SNACRM」を参照)。crmlkoff、crmlkonまたはcrmdownを使用する場合は、-u<keyfile>コマンドライン・オプションを使用します(詳細は付録A「管理コマンド・リファレンス ページ」の「SNACRM」を参照)。
Tuxedoセキュリティ・プラグインを使用すると、セキュリティ機能をカスタマイズしたり、代替のサードパーティ製セキュリティ・ソフトウェア実装を使用できます。Tuxedoセキュリティ・プラグインはTuxedoプラグインの構成時に設定します。この機能の詳細は、Tuxedoのドキュメントを参照してください。
  
|