セキュリティとは、コンピュータ内のデータまたはコンピュータ間で送受信されるデータが損なわれないことを保証する技術のことです。ほとんどのセキュリティ機能では、パスワードおよびデータの暗号化を使用してセキュリティを実現します。パスワードとは、秘密の文字列であり、ユーザーは、これを入力することにより特定のプログラムやシステムにアクセスできます。データの暗号化とは、データを理解できない形式に変換することであり、変換されたデータは復号化のメカニズムがないと解読できません。
注意: | 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のドキュメントを参照してください。