| ドキュメントのダウンロード | サイトマップ | 用語集 | |
|
|||
| bea ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > Tuxedo > Tuxedo のセキュリティ機能 > セキュリティの管理 |
|
Tuxedo のセキュリティ機能
|
セキュリティの管理
以下の節では、BEA Tuxedo ATMI アプリケーションのセキュリティ方針を設定する方法について説明します。
セキュリティの管理とは
ATMI アプリケーションのセキュリティ管理とは、クライアント、サーバ・マシン、ゲートウェイ・リンクなどのアプリケーションのコンポーネントに対して、セキュリティの方針を設定し、適用することです。ATMI アプリケーションに対するセキュリティ方針はアプリケーション管理者が設定し、これらの方針は、ATMI アプリケーションの基盤となる BEA Tuxedo システムによって実行されます。
BEA Tuxedo システムには、次の ATMI 用のセキュリティ機能が用意されています。
アプリケーション管理者は、次の図に示すように、監査以外のすべてのセキュリティ機能を設定できます。
図 2-1 ATMI のセキュリティの管理
セキュリティ管理のタスク
セキュリティ管理には、次のタスクが含まれます。
関連項目
BEA Tuxedo レジストリの設定
1 つ以上のセキュリティ機能をカスタマイズして ATMI アプリケーションに組み込む場合、アプリケーション管理者は BEA Tuxedo レジストリについて知っておく必要があります。一方、デフォルトのセキュリティ機能だけを ATMI アプリケーションに組み込む場合は、BEA Tuxedo レジストリを変更する必要はありません。
BEA Tuxedo レジストリは、プラグイン・モジュールに関連する情報を格納しておくディスク・ベースのリポジトリです。このレジストリには、デフォルトのセキュリティ・プラグインに関する登録情報が最初に格納されています。
BEA Tuxedo レジストリの目的
BEA のほとんどのミドルウェア製品では、セキュリティなどのコア・サービスのセットで構成される、共通のトランザクション処理のインフラストラクチャ (TP インフラストラクチャ) が使用されています。ATMI アプリケーションでは、適切に定義されたインターフェイスを介して TP インフラストラクチャを使用できます。これらのインターフェイスを使って独自のサービス・コード・モジュールであるプラグイン・モジュール (プラグイン) をロードし、リンクすることにより、アプリケーション管理者は、TP インフラストラクチャのデフォルトの動作を変更できます。
プラグインをロードする最初の手順として、プラグインをホスト・オペレーティング・システムに登録します。プラグインを登録すると、プラグインのエントリが BEA Tuxedo レジストリに追加されます。BEA Tuxedo レジストリは、アクティブなプラグインの情報を格納するバイナリ・ファイルのセットです。レジストリは、BEA Tuxedo システムごとに用意されています。
ATMI アプリケーション内のすべてのワークステーション・クライアントとサーバ・マシンは、同じプラグイン・モジュールのセットを使用する必要があります。
プラグインの登録
カスタマイズしたプラグインを使用する場合、ATMI アプリケーションの管理者はこれらのプラグインを登録し、その他のレジストリ関連のタスクを実行する責任があります。BEA Tuxedo レジストリへのプラグインの登録は、ローカル・マシンからのみ可能です。つまり、管理者は、リモートからホスト・マシンにログオンしている間はプラグインを登録できません。
プラグインの管理では、次の 3 つのコマンドを使用できます。
これらのコマンドの使用方法については、『Developing Security Services for ATMI and CORBA Environments』を参照してください。(このマニュアルには、セキュリティ・プラグインの仕様、およびセキュリティ・プラグインのモジュールを動的にロードし、リンクするための BEA Tuxedo の プラグイン・インターフェイス の説明が掲載されています)。また、カスタマイズしたプラグインをインストールする場合、プラグインの提供元であるサードパーティ・ベンダは、これらのコマンドの使用方法を明記して、カスタマイズしたプラグインにアクセスするための BEA Tuxedo レジストリの設定方法を示す必要があります。
セキュリティ・プラグインの詳細 (インストール手順およびコンフィギュレーション手順を含む) については、日本 BEA システムズ (株) の営業担当者にお問い合わせください。
関連項目
セキュリティ用の ATMI アプリケーションのコンフィギュレーション
アプリケーションが非アクティブの場合、アプリケーション管理者は MASTER マシンで ATMI アプリケーションのセキュリティを設定します。アプリケーションが起動すると、基となる BEA Tuxedo システムにより、ATMI アプリケーション内のほかのマシンにコンフィギュレーション情報が複製転送されます。
管理者は、次のいずれかの方法でアプリケーションのセキュリティを設定できます。
セキュリティの種類 (認証、認可、リンク・レベルの暗号化、または公開鍵) およびセキュリティ・ソフトウェアの種類 (デフォルト版またはカスタマイズ版) に応じて、設定するセキュリティ・パラメータは異なります。
コンフィギュレーション・ファイルを編集する
UBBCONFIG コンフィギュレーション・ファイルを編集して、ATMI アプリケーションのセキュリティ方針を設定することができます。UBBCONFIG コンフィギュレーション・ファイルにはどのような名前を付けることもできますが、ファイルの内容は、『BEA Tuxedo のファイル形式とデータ記述方法』の UBBCONFIG(5) リファレンス・ページで指定された形式に準拠する必要があります。
UBBCONFIG ファイルおよび TUXCONFIG ファイル (バイナリ形式のコンフィギュレーション・ファイル) の詳細については、『BEA Tuxedo アプリケーションの設定』の 2-1 ページの「コンフィギュレーション・ファイルについて」および 3-1 ページの「コンフィギュレーション・ファイルの作成」を参照してください。
TM_MIB を変更する
TM_MIB でクラスのセットを定義することにより、ATMI アプリケーションの基本的な側面を設定し、管理することができます。クラスは、マシン、サーバ、ネットワークなど、コンポーネントごとに指定されます。管理要求の形式および管理応答の解釈については、管理情報ベース (MIB: Management Information Base) のリファレンス・ページである MIB(5) と TM_MIB(5) リファレンス・ページを両方参照してください。MIB のリファレンス・ページは、『BEA Tuxedo のファイル形式とデータ記述方法』で定義されています。
ACL_MIB、DM_MIB、WS_MIB など、ほかの MIB コンポーネントも ATMI アプリケーションのセキュリティ管理に関係があります。ACL_MIB(5) リファレンス・ページでは ACL_MIB、DM_MIB(5) リファレンス・ページでは DM_MIB、WS_MIB(5) リファレンス・ページでは WS_MIB を定義しています。
BEA Tuxedo の MIB の詳細については、まず『BEA Tuxedo のファイル形式とデータ記述方法』の MIB(5) を参照してください。『BEA Tuxedo システム入門』も参照してください。
BEA Administration Console を使用する
BEA Administration Console を使用して ATMI アプリケーションのセキュリティ方針を変更することもできます。BEA Administration Console は、アプリケーションをコンフィギュレーションし、監視し、動的に再コンフィギュレーションするための Web ベースのツールです。
BEA Administration Console の詳細については、『BEA Tuxedo システム入門』を参照してください。
関連項目
管理環境の設定
アプリケーション管理者は、アプリケーションのコンフィギュレーション作業の一貫として、ATMI アプリケーション用の環境変数をいくつか定義します。環境変数に定義される値は、BEA Tuxedo の実行可能ファイルおよびデータ・ライブラリを指す絶対パス名です。
ATMI アプリケーションを管理するには、これらのファイルにアクセスできなければなりません。たとえば、アプリケーションのセキュリティ管理に必要なコマンドは、すべて $TUXDIR/bin (UNIX ホスト・マシンの場合)、または %TUXDIR%¥bin (Windows 2000 ホスト・マシンの場合) に格納されています。
管理環境の設定の詳細については、『BEA Tuxedo アプリケーション実行時の管理』を参照してください。
関連項目
オペレーティング・システム (OS) のセキュリティ管理
アプリケーション管理者は、BEA Tuxedo システムの ATMI 環境のセキュリティのほか、オペレーティング・システムに組み込まれているセキュリティ機能を十分に活用して、ファイル、ディレクトリ、およびシステム・リソースに対するアクセスを制御する必要があります。
ほとんどの場合、ATMI アプリケーションは、アプリケーション管理者によって管理されます。アプリケーション管理者は、アプリケーションをコンフィギュレーションし、起動し、実行中のアプリケーションを監視し、必要に応じて動的に変更します。ATMI アプリケーションは、管理者が起動し、実行するため、サーバ・プログラムは、管理者のパーミッションで実行されます。これで、サーバ・プログラムは安全であり、「信頼できる」と見なされます。この方法は、基盤となるオペレーティング・システムのログイン・メカニズムとパーミッション設定 (ファイル、ディレクトリ、およびシステム・リソースに対する読み取り権と書き込み権の設定) に基づいています。
一方、クライアントを起動するのは管理者ではありません。クライアントは、自分自身のパーミッションを持つユーザによって直接実行されます。したがって、クライアントは信頼できるとは言えません。
さらに、ネイティブ・クライアント (つまり、サーバを実行中のマシンと同じマシンで実行中のクライアント) を実行するユーザは、コンフィギュレーション・ファイルにアクセスしたり、共用メモリ内の掲示板などのプロセス間通信 (IPC) のメカニズムにアクセスできます。BEA Tuxedo システムのセキュリティが追加されても、ネイティブ・クライアントを実行するクライアントは、常にこのようなアクセスを実現できます。
OS のセキュリティで推奨されている事項について
管理者は、次の一般的な方法に従うことにより、オペレーティング・システムのセキュリティ・レベルを高めることができます。
関連項目
認証の管理
認証とは、通信するプロセスどうしがお互いの ID を証明し合うことです。この機能は、これ以外のほぼすべてのセキュリティ機能の基盤となります。
この節で示す手順以外の認証の管理手順は、基となるアプリケーションの認証システムに依存します。カスタマイズした認証システムを管理する手順については、該当するシステムのマニュアルを参照してください。デフォルトの認証システムを管理する手順については、デフォルトの認証と認可の管理を参照してください。
次の図は、BEA Tuxedo リリース 7.1 以上のソフトウェアで使用される、高信頼性委託型認証モデルをしています。高信頼性委託型認証モデルでは、ワークステーション・ハンドラ (WSH) およびドメイン・ゲートウェイ (GWTDOMAIN) は、「信頼性のあるシステム・ゲートウェイ・プロセス」と呼ばれます。これについては、委任された信用認証についてを参照してください。
注記 相互認証は、ネイティブ・クライアントには適用されません。ネイティブ・クライアントを認証するのは、ネイティブ・クライアント自身です。 以下は、上の図のコンフィギュレーションの設定に必要な操作の一覧です。すべての操作で、認証と認可のプラグインが必要になります。
関連項目
プリンシパル名の指定
管理者は、次のコンフィギュレーション・パラメータを使用して、BEA Tuxedo リリース 7.1 以上のソフトウェアで作成した ATMI アプリケーションで実行するワークステーション・ハンドラ (WSH)、ドメイン・ゲートウェイ (GWTDOMAIN)、およびサーバ・プロセスのプリンシパル名を指定します。
SEC_PRINCIPAL_NAME は、コンフィギュレーションの階層のうち、次の 4 つのレベルのどこでも指定できます。
特定のコンフィギュレーション・レベルでのセキュリティ・プリンシパル名は、下位レベルで上書きできます。たとえば、mach1 というマシンに terri というプリンシパル名を指定し、mach1 上で動作する serv1 というサーバに john というプリンシパル名を指定したとします。この場合、mach1 のプロセスは次のように動作します。
システム・プロセスがクリデンシャルを取得する方法
アプリケーションの起動時に、ATMI アプリケーション内のそれぞれの WSH、ドメイン・ゲートウェイ、およびサーバ・プロセスが認証プラグインを呼び出して (1) セキュリティ・クリデンシャルを取得し、(2) 認可トークンおよび監査トークンを取得するとき、セキュリティ・プリンシパル名を引数として指定します。次の図は、この手順を示しています。
図 2-3 アプリケーションの起動時にクリデンシャルとトークンを取得する
アプリケーション内の各ドメイン・ゲートウェイ・プロセスは、認証プラグインをもう一度呼び出して、割り当てられた接続プリンシパル名のクリデンシャルとトークンを取得します。 システム・プロセスでクリデンシャルが必要な理由 WSH にはクリデンシャルが必要です。クリデンシャルがあれば、ワークステーション・クライアントを認証してアプリケーションに参加させ、認証されたワークステーション・クライアント用の認可トークンと監査トークンを取得することができます。WSH がリリース 7.1 より前のクライアント (BEA Tuxedo 6.5 以前のソフトウェアで動作するクライアント) からの要求を処理する場合、この WSH には、WSH 自身の認可トークンと監査トークンが必要です 。これらのトークンがあれば、WSH は認証プラグインを呼び出して、古いバージョンのクライアントの ID を確認できます。この動作については、相互運用性の方針の指定を参照してください。 ドメイン・ゲートウェイにも一組のクリデンシャルが必要です。クリデンシャルを取得すると、ドメイン間のリンクの確立で説明するように、リモート・ドメイン・ゲートウェイを認証し、ATMI アプリケーション間でリンクを確立することができます。認証されたリモート・ドメイン・ゲートウェイには、認可トークンも監査トークンも割り当てられません。ドメイン・ゲートウェイは、CONNECTION_PRINCIPAL_NAME パラメータで指定されたプリンシパル名で、これらのクリデンシャルを取得します。 ドメイン・ゲートウェイがリリース 7.1 より前のクライアントからの要求を処理する場合、つまり、認証プラグインを呼び出して、古いバージョンのクライアントの ID を確認する場合、このドメイン・ゲートウェイにはもう一組のクリデンシャルが必要です。この動作については、相互運用性の方針の指定を参照してください。これらのクリデンシャルは、ローカルのアクセス制御リスト (ACL: Access Control List) を適用する場合に ID を確認するときにも必要です (ACL 方針の設定を参照)。ドメイン・ゲートウェイは、SEC_PRINCIPAL_NAME パラメータで指定されたプリンシパル名で、これらのクリデンシャルを取得します。 システムまたはアプリケーション・サーバがリリース 7.1 より前のクライアントからの要求を処理する場合は、システムまたはアプリケーション・サーバ自身の認可トークンと監査トークンが必要です。これらのトークンがあれば、認証プラグインを呼び出して、古いバージョンのクライアントの ID を確認できます。この動作については、相互運用性の方針の指定を参照してください。 サーバは、サーバ・パーミッションのアップグレードを行うときにもサーバ自身のトークンを必要とします。サーバ・パーミッションのアップグレードは、クライアントから発信されサーバを経由して送信されるメッセージに対し、認可トークンおよび監査トークンが割り当てられるときに発生します。サーバのアップグレード機能については、クライアント・トークンとサーバ・トークンの交換を参照してください。 注記 アプリケーション・サーバは、認証プラグインを呼び出すことはできません。アプリケーション・サーバの認証プラグインは、基となるシステム・コードによって呼び出されます。 プリンシパル名を指定する UBBCONFIG のエントリ例 次の例は、UBBCONFIG の SEC_PRINCIPAL_NAME パラメータを使用してセキュリティ・プリンシパル名を指定する方法を示しています。CONNECTION_PRINCIPAL_NAME パラメータを使用して、DMCONFIG ファイルの接続プリンシパル名を指定する例については、リンクを確立するための DMCONFIG のエントリ例を参照してください。 関連項目
*RESOURCES
SEC_PRINCIPAL_NAME "Tommy"
.
.
.*SERVERS
"TMQUEUE" SRVGRP="QUEGROUP" SRVID=1
CLOPT="-t -s secsdb:TMQUEUE"
SEC_PRINCIPAL_NAME="TOUPPER"
相互運用性の方針の指定
管理者は、UBBCONFIG ファイルの CLOPT -t オプションを使用して、ATMI アプリケーション内の WSH、ドメイン・ゲートウェイ (GWTDOMAIN) およびサーバ・プロセスが、BEA Tuxedo リリース 7.1 より前 (6.5 以前) のソフトウェアを実行しているマシンと相互運用するように指定できます。また、WSINTOPPRE71 環境変数を使用して、ワークステーション・クライアントが BEA Tuxedo リリース 7.1 より前のソフトウェアを実行するマシンと相互運用するよう指定できます。次に、これらのプロセスの相互運用性を説明する 4 つの図を示します。
図 2-4 新しい WSH と古いワークステーション・クライアントの相互運用
上の図では、WSH がリリース 7.1 より前の古い認証プロトコルを使用してワークステーション・クライアントを認証し、内部の「代替ユーザ」関数を呼び出してクライアントの認可トークンと監査トークンを取得し、それらのトークンをクライアント要求に添付しています。WSH を制御するワークステーション・リスナ (WSL) に対して CLOPT -t オプションが指定されないと、新しい WSH と古いワークステーション・クライアントとの間の通信は実現できません。 注記 「代替ユーザ」関数は、認証プラグインを呼び出して、古いクライアントの ID を確認します。詳細については、古いクライアントの ID の確認を参照してください。 図 2-5 古い WSH と新しいワークステーション・クライアントの相互運用
上の図では、WSH がリリース 7.1 より前の古い認証プロトコルを使用してワークステーション・クライアントを認証します。クライアント要求は、認可トークンと監査トークンを受け取りません。ワークステーション・クライアントに WSINTOPPRE71 環境変数が設定されていない場合、またはこの環境変数が N に設定されている場合、古い WSH と新しいワークステーション・クライアントとの間の通信は実現できません。 図 2-6 サーバと古い ATMI アプリケーションの相互運用
上の図では、アプリケーション 1 のローカル・ドメイン・ゲートウェイ (GWTDOMAIN) が、リリース 7.1 より前の古い認証プロトコルを使用して、アプリケーション 2 のリモート・ドメイン・ゲートウェイを認証しています。ローカル・ドメイン・ゲートウェイは、リモート・クライアントからの要求を受け取ると、内部の「代替ユーザ」関数を呼び出してリモート・クライアントの認可トークンと監査トークンを取得し、それらのトークンをクライアント要求に添付します。アウトバウンドのクライアント要求 (アプリケーション 1 からアプリケーション 2 に送信される要求) の場合、要求に添付されたトークンは、ローカル・ドメイン・ゲートウェイで取り除かれ、要求はアプリケーション・キーとともにアプリケーション 2 に送信されます(アプリケーション・キーについては、アプリケーション・キーを参照してください)。 ドメイン・ゲートウェイに対して CLOPT -t オプションが指定されない場合、新しい ATMI アプリケーションと古い ATMI アプリケーションとの間の通信は実現できません。 図 2-7 サーバと古い BEA Tuxedo システムの相互運用
上の図では、まずマシン 1 にある送信先のサーバが内部の「代替ユーザ」関数を呼び出し、マシン 2 にあるリモート・クライアントの認可トークンと監査トークンを取得します。取得したトークンがクライアント要求に添付されると、サーバは、クライアントが認可チェックにパスしたと見なして要求を実行します。サーバに対して CLOPT -t オプションが指定されない場合、新しいサーバと古いクライアントとの間の通信は実現できません。 注記 また、上の図で、マシン 1 の WSH がマシン 2 のサーバ宛てのクライアント要求を受け取ると、WSH は要求に添付されたトークンを取り除いてから、その要求をクライアントのアプリケーション・キーとともにマシン 2 のサーバに送信します。同様に、マシン 1 のネイティブ・クライアントがマシン 2 のサーバに要求を送信した場合、ネイティブ・クライアントは、要求に添付されたトークンを取り除いてから、その要求をクライアントのアプリケーション・キーとともにマシン 2 のサーバに送信します。アプリケーション・キーについては、アプリケーション・キーを参照してください。 古いクライアントの ID の確認 WSH、ドメイン・ゲートウェイ (GWTDOMAIN)、またはサーバ・プロセスは、内部の「代替ユーザ」関数を呼び出して、古いクライアントの認可トークンと監査トークンを取得することにより、古いクライアントの ID を確認します。次の図は、この手順を示しています。 図 2-8 古いクライアントの認可トークンと監査トークンの取得
WSH 側で古いクライアントの ID を確認する CLOPT -t オプションが指定されている場合、WSH は、TPINIT バッファの usrname フィールドを使用するか (C の場合)、または TPINFDEF-REC レコードの USRNAME フィールドを使用して (COBOL の場合) 古いクライアントの ID を確認します。ATMI アプリケーションへの参加で説明するとおり、クライアントがアプリケーションに参加しようとすると、WSH はクライアントから TPINIT バッファまたは TPINFDEF-REC レコードを受け取ります。WSH は、「代替ユーザ」関数を呼び出すときにプリンシパル名としてユーザ名を使用します。 デフォルトの認証プラグインの場合、「代替ユーザ」関数は、ローカルの tpusr ファイルからユーザ名および関連するアプリケーション・キー (ユーザ識別子とグループ識別子の組み合わせ) を検索し、古いクライアント用に作成された認可トークンと監査トークンに、ユーザ名とアプリケーション・キーを両方とも組み込みます。tpusr ファイルについては、ユーザ・ファイルとグループ・ファイルの設定を参照してください。 ドメイン・ゲートウェイ側で古いクライアントの ID を確認する CLOPT -t オプションが指定されている場合、ドメイン・ゲートウェイは、リモート・ドメイン・アクセス・ポイントに対して設定された LOCAL_PRINCIPAL_NAME 文字列を使用して、古いクライアントの ID を確認します。ドメイン・ゲートウェイは、ローカルの BDMCONFIG ファイル (バイナリ形式の DMCONFIG(5) ファイル) の DM_REMOTE セクションで、リモート・ドメイン・アクセス・ポイントの LOCAL_PRINCIPAL_NAME 文字列を検索します。このオプションを指定しない場合は、リモート・ドメイン・アクセス・ポイントの ACCESSPOINTID 文字列がデフォルト値になります。ドメイン・ゲートウェイは、「代替ユーザ」関数を呼び出すときにプリンシパル名として LOCAL_PRINCIPAL_NAME 文字列を使用します。 デフォルトの認証プラグインの場合、「代替ユーザ」関数は、ローカルの tpusr ファイルから LOCAL_PRINCIPAL_NAME 文字列および関連するアプリケーション・キーを検索し、古いクライアント用に作成された認可トークンと監査トークンに、その文字列 (ID) とアプリケーション・キーを組み込みます。 サーバ側で古いクライアントの ID を確認する CLOPT -t オプションが指定されている場合、サーバは、クライアントに割り当てられたアプリケーション・キーを使用して、古いクライアントの ID を確認します。サーバが受信したクライアント要求には、クライアントに割り当てられたアプリケーション・キーが含まれています。サーバは、ローカルの tpusr ファイルからアプリケーション・キーと関連する名前を検索し、「代替ユーザ」関数を呼び出すときにプリンシパル名としてその名前を組み込みます。 デフォルトの認証プラグインの場合、「代替ユーザ」関数は、ローカルの tpusr ファイルから名前および関連するアプリケーション・キーを検索し、古いクライアント用に作成された認可トークンと監査トークンに、名前とアプリケーション・キーを組み込みます。 CLOPT -t オプションの動作のまとめ 次の表は、CLOPT -t オプションを使用して相互運用性を実現できる場合、または実現できない場合の WSH、ドメイン・ゲートウェイ、およびサーバ・プロセスの機能をまとめたものです。
相互運用性を指定する UBBCONFIG のエントリ例 次の例は、ワークステーション・リスナ (WSL) によって制御されるすべての WSH で相互運用性が実現できることを示しています。 関連項目
*SERVERS
WSL SRVGRP="group_name" SRVID=server_number ...
CLOPT="-A -t ..."
ドメイン間のリンクの確立
ドメイン・ゲートウェイ (GWTDOMAIN) が別のドメイン・ゲートウェイとのネットワーク・リンクを確立しようとすると、次のようなイベントが発生します。
管理者は、次のコンフィギュレーション・パラメータを使用して、BEA Tuxedo リリース 7.1 以上のソフトウェアを実行するドメイン・ゲートウェイ間にリンクを確立します。
次の図は、デフォルトの認証プラグインを使用して、ドメイン間のリンクを確立する方法を示しています。 図 2-9 デフォルトの認証を使用してドメイン間にリンクを確立する
注記 上の図の「クリデンシャル」は、ローカル・ドメイン・アクセス・ポイントに対して設定された CONNECTION_PRINCIPAL_NAME の ID を使用して、アプリケーションの起動時に、各ドメイン・ゲートウェイ・プロセスによって取得されます。 上の図で、イニシエータ側とターゲット側のドメイン・ゲートウェイ間で交換される情報には、ドメイン・ゲートウェイ用に指定された BDMCONFIG ファイルの CONNECTION_PRINCIPAL_NAME 文字列が含まれる点に注目してください。各認証プラグインは、リモート・ドメイン・アクセス・ポイントに割り当てられたパスワード (BDMCONFIG ファイルの DM_PASSWORDS セクションで定義) を使用して文字列を暗号化してから、それをネットワーク経由で送信し、ローカル・ドメイン・アクセス・ポイントに割り当てられたパスワード (BDMCONFIG ファイルの DM_PASSWORDS セクションで定義) を使用して受信した文字列を復号化します。このとき、暗号化アルゴリズムとして、56 ビットの DES (Data Encryption Standard) が使用されます。 暗号化および復号化の操作を成功させるため、ローカルの BDMCONFIG ファイルで指定された、リモート・ドメイン・アクセス・ポイント用のパスワードは、リモートの BDMCONFIG ファイルで指定されたローカル・ドメイン・アクセス・ポイント用のパスワードと同じでなければなりません。同様に、ドメインのセキュリティ・レベルが APP_PW に設定されている場合に暗号化および復号化の操作を成功させるには、各 TUXCONFIG ファイルのアプリケーション・パスワードが同じでなければなりません。認証プロセスを成功させるには、受信した文字列が、送信者の CONNECTION_PRINCIPAL_NAME 文字列と一致しなければなりません。 ドメイン・ゲートウェイがセキュリティ・チェックにパスすると、リンクが確立され、ゲートウェイは、確立されたリンクを介してサービス要求を転送したり、応答を受信することができます。 リンクを確立するための DMCONFIG のエントリ例 次の例は、ローカル・ドメイン・アクセス・ポイント c01 と、リモート・ドメイン・アクセス・ポイント b01 を使って接続を確立するときに、ローカルの DMCONFIG ファイルのコンフィギュレーションが使用されることを示しています。 関連項目
*DM_LOCAL
# <local domain access point name> <gateway group name> <domain type>
# <domain id> [<connection principal name>] [<security>]...
c01 GWGRP=bankg1
TYPE=TDOMAIN
ACCESSPOINTID="BA.CENTRAL01"
CONNECTION_PRINCIPAL_NAME="BA.CENTRAL01"
SECURITY=DM_PW
.
.
.*DM_REMOTE
# <remote domain access point name> <domain type> <domain id>
# [<connection principal name>]...
b01 TYPE=TDOMAIN
ACCESSPOINTID="BA.BANK01"
CONNECTION_PRINCIPAL_NAME="BA.BANK01"
ACL 方針の設定
管理者は、次のコンフィギュレーション・パラメータを使用して、BEA Tuxedo リリース 7.1 以上のソフトウェアを実行する ATMI アプリケーション間で、アクセス制御リスト (ACL: Access Control List) 方針の設定と制御を行います。
以下の 3 つの図は、ACL_POLICY の設定が、ローカル・ドメイン・ゲートウェイ (GWTDOMAIN) のプロセスの動作に与える影響を示します。 図 2-10 ローカルな ACL 方針の確立
上の図では、各ドメイン・ゲートウェイ (GWTDOMAIN) がインバウンドのクライアント要求 (リモート・アプリケーションからネットワーク経由で受信される要求) を変更しています。変更された要求は、リモート・ドメイン・アクセス・ポイントに設定された LOCAL_PRINCIPAL_NAME の ID を持つため、その ID に設定されたアクセス権も取得することになります。各ドメイン・ゲートウェイは、アウトバウンドのクライアント要求を変更しないで渡します。 このコンフィギュレーションでは、各 ATMI アプリケーションに ACL データベースがあります。このデータベースには、ドメイン内のユーザに関するエントリだけが格納されます。たとえば、リモート・ドメイン・アクセス・ポイントに対して設定された LOCAL_PRINCIPAL_NAME の ID を持つユーザです。 注記 以上の説明は、BEA Tuxedo リリース 7.1 より前のソフトウェアを実行する ATMI アプリケーションにも適用されます。ただし、システムでは、リモート・ドメイン・アクセス・ポイントに設定された ACCESSPOINTID の ID が使用されます。基本的に、BEA Tuxedo リリース 6.5 以前のソフトウェアでは、ローカルの ACL 方針はハードコーディングされています。 図 2-11 グローバルな ACL 方針の確立
上の図では、各ドメイン・ゲートウェイ (GWTDOMAIN) は、インバウンドとアウトバウンドのクライアント要求を変更しないで渡します。このコンフィギュレーションでは、各 ATMI アプリケーションに ACL データベースがあります。このデータベースには、ドメイン内のユーザに関するエントリのほか、リモート・ドメインのユーザの情報も格納されます。 図 2-12 一方向ローカルおよび一方向グローバルの ACL 方針の確立
上の図では、ATMI アプリケーション 1 のドメイン・ゲートウェイ (GWTDOMAIN) が、インバウンドのクライアント要求を変更しています。変更された要求は、ATMI アプリケーション 2 のリモート・ドメイン・アクセス・ポイントに設定された LOCAL_PRINCIPAL_NAME ID を持つため、その ID に設定されたアクセス権も取得することになります。アウトバウンドのクライアント要求は、変更されずに渡されます。ATMI アプリケーション 2 のドメイン・ゲートウェイ (GWTDOMAIN) は、インバウンドとアウトバウンドのクライアント要求を変更しないで渡します。 このコンフィギュレーションの ATMI アプリケーション 1 の ACL データベースには、ドメイン内のユーザに関するエントリだけが含まれています。たとえば、アプリケーション 2 のリモート・ドメイン・アクセス・ポイントに設定された LOCAL_PRINCIPAL_NAME の ID を持つユーザです。ATMI アプリケーション 2 の ACL データベースには、ドメイン内のユーザに関するエントリのほか、ATMI アプリケーション 1 のユーザのエントリも格納されています。 リモート・ドメイン・ゲートウェイの偽装化 ドメイン・ゲートウェイは、ローカルの DMCONFIG ファイルの ACL_POLICY パラメータに LOCAL (デフォルト) が設定されたリモート・ドメインからクライアント要求を受け取ると、次のタスクを実行します。
「代替ユーザ」関数の詳細については、古いクライアントの ID の確認を参照してください。
ACL 方針を指定する DMCONFIG のエントリ例
次の例では、リモート・ドメイン・アクセス・ポイント b01 を介した接続に対し、ローカルの DMCONFIG ファイルで ACL がグローバルに設定されています。つまり、ドメイン・アクセス・ポイント c01 のドメイン・ゲートウェイ・プロセスは、ドメイン・アクセス・ポイント b01 に対し、クライアント要求を変更しないで受け渡します。ACL がグローバルに設定されている場合、ドメイン・アクセス・ポイント b01 の LOCAL_PRINCIPAL_NAME エントリは無視されます。
*DM_LOCAL
# <local domain access point name> <gateway group name>
# <domain type> <domain id> [<connection principal name>]
# [<security>]...
c01 GWGRP=bankg1
TYPE=TDOMAIN
ACCESSPOINTID="BA.CENTRAL01"
CONNECTION_PRINCIPAL_NAME="BA.CENTRAL01"
SECURITY=DM_PW
.
.
.
*DM_REMOTE
# <remote domain access name> <domain type> <domain id>
# [<ACL policy>] [<connection principal name>]
# [<local principal name>]...
b01 TYPE=TDOMAIN
ACCESSPOINTID="BA.BANK01"
ACL_POLICY=GLOBAL
CONNECTION_PRINCIPAL_NAME="BA.BANK01"
LOCAL_PRINCIPAL_NAME="BA.BANK01.BOB"
関連項目
クリデンシャル方針の設定
管理者は、次のコンフィギュレーション・パラメータを使用して、BEA Tuxedo リリース 8.0 以上を実行する ATMI アプリケーション間で、クリデンシャル方針の設定と制御を行います。
認可の管理
認可とは、ATMI アプリケーション内のリソースまたは機能に対するユーザ・アクセスを、アプリケーション固有の規則に従って制限することです。認可は、ユーザが ATMI アプリケーションへの参加を認証された場合にのみ実行されます。
認可の管理手順は、基となる ATMI アプリケーションの認可システムによって異なります。カスタマイズした認可システムを管理する手順については、該当するシステムのマニュアルを参照してください。デフォルトの認可システムを管理する手順については、デフォルトの認証と認可の管理を参照してください。
関連項目
リンク・レベルの暗号化の管理
リンク・レベルの暗号化は、ATMI アプリケーション内のマシン間をつなぐネットワーク・リンク上で送受信されるメッセージの秘密性を保護します。リンク・レベルの暗号化によるセキュリティには、0 ビット (暗号化なし)、56 ビット (国際版)、128 ビット (米国およびカナダ版) の 3 つのレベルがあります。国際版の LLE では、0 ビットと 56 ビットの暗号化が可能です。米国およびカナダ版の LLE では、0 ビット、56 ビット、および 128 ビットの暗号化が可能です。
LLE は、BEA Tuxedo の次の種類のリンクで使用できます。
min 値と max 値について
ATMI アプリケーションに LLE を設定する前に、LLE の値(min 値および max 値) を知っておく必要があります。これらのパラメータのデフォルト値は次のとおりです。
たとえば、米国およびカナダ版の LLE のデフォルトの min 値と max 値は (0, 128) です。デフォルト値を変更するには、アプリケーションの UBBCONFIG ファイルで min と max に新しい値を割り当てます。
詳細については、LLE のしくみおよび暗号化キー・サイズの調整を参照してください。
インストール済みの LLE バージョンの確認
マシンにインストールされた LLE バージョンを確認するには、冗長モードで tmadmin コマンドを実行します。
tmadmin -v
ローカルの BEA Tuxedo lic.txt ファイルのキー行は、次のサンプルのようにコンピュータ画面に表示されます。エントリのサンプル STRENGTH=128 は、LLE のバージョンが米国およびカナダ版であることを示しています。
[BEA Tuxedo] VERSION=8.0
[LINK ENCRYPTION] VERSION=8.0
STRENGTH=128
.
.
.
BEA Tuxedo のライセンスは、UNIX ホスト・マシンの場合は $TUXDIR/udataobj/lic.txt ファイル、Windows 2000 ホスト・マシンの場合は %TUXDIR%¥udataobj¥lic.txt ファイルにすべて格納されています。
ワークステーション・クライアントのリンクに LLE を設定する方法
アプリケーションにワークステーション・クライアントが組み込まれている場合、管理者は、1 つまたは複数のワークステーション・リスナ (WSL) を設定して、ワークステーション・クライアントからの接続要求を監視する必要があります。各 WSL は、関連する 1 つまたは複数のワークステーション・ハンドラ (WSH) を使用して、ワークステーション・クライアントの負荷を管理します。各 WSH は、単一の接続を介して、特定のワークステーション・クライアントで処理されるすべての要求と応答を多重化することにより、複数のワークステーション・クライアントを管理できます。
管理者は、アプリケーションの UBBCONFIG ファイルの SERVERS セクションで WSL サーバを指定することにより、ワークステーション・クライアントに対して ATMI アプリケーションへのアクセスを許可することができます。LLE の min および max パラメータのデフォルト値を上書きするには、WSL サーバ用のコマンド行オプションである -z および -Z を指定する必要があります(詳細については、min 値と max 値についてを参照してください)。ただし、リンク・レベルの暗号化は、ローカル・マシンとワークステーション・クライアントの両方に LLE がインストールされている場合にのみ使用できます。
注記 ネットワーク接続の端にあるワークステーション・クライアントでは、TMINENCRYPTBITS および TMAXENCRYPTBITS の 2 つの環境変数を使用して、LLE の min および max パラメータのデフォルト値を上書きできます。
ワークステーション・クライアントのリンクに LLE を設定するには、次の手順に従います。
*SERVERS
WSL SRVGRP="group_name" SRVID=server_number ...
CLOPT="-A -- -z min -Z max ..."
上の例では、tmboot(1) を実行すると ATMI アプリケーションが起動し、"-A -- -z min -Z max" というコマンド行オプションが WSL サーバに渡されます。ワークステーション・クライアントと WSH との間でネットワーク・リンクを確立する場合、ワークステーション・クライアントと WSL は、双方でサポートされるキーの最大サイズが一致するまでキー・サイズの調整を行います。
詳細については、『BEA Tuxedo のファイル形式とデータ記述方法』の WSL(5)、WS_MIB(5)、および UBBCONFIG(5) を参照してください。
ブリッジ間のリンクに LLE を設定する方法
BEA Tuxedo システムのアーキテクチャでは、マルチ・マシン・アプリケーション (複数のマシンで構成されたアプリケーション) 内のマシン間に多重化したチャネルを確立して、ネットワーク通信を最適化します。BEA Tuxedo のメッセージは、このチャネルを通じて双方向に流れます。メッセージ・トラフィックは、ブリッジ・サーバと呼ばれる専用の BEA Tuxedo サーバによって管理されます。
管理者は、ブリッジ・サーバが置かれた ATMI アプリケーション内の各マシンに対して、UBBCONFIG ファイルの NETWORK セクションにエントリを作成します。LLE の min および max パラメータのデフォルト値を上書きする場合は、ブリッジ・サーバのオプションのランタイム・パラメータである MINENCRYPTBITS および MAXENCRYPTBITS を指定する必要があります (See (詳細については、min 値と max 値についてを参照してください)。ただし、ブリッジ間のリンク・レベルの暗号化は、ブリッジ・サーバが置かれたマシンに LLE がインストールされている場合にのみ使用できます。
ブリッジ間のリンクに LLE を設定するには、次の手順に従います。
*NETWORK
LMID NADDR="bridge_network_address" BRIDGE="bridge_device"
NLSADDR="listen_network_address"
MINENCRYPTBITS=min
MAXENCRYPTBITS=max
上の例では、tmboot(1) を実行すると、ATMI アプリケーションが起動し、ブリッジ・サーバは、TUXCONFIG ファイルを読み込んで、MINENCRYPTBITS や MAXENCRYPTBITS などのさまざまなパラメータにアクセスします。リモートのブリッジ・サーバとの間でネットワーク・リンクを確立する場合、ローカルとリモートのブリッジ・サーバは、双方でサポートされるキーの最大サイズが一致するまでキー・サイズの調整を行います。
詳細については、『BEA Tuxedo のファイル形式とデータ記述方法』の TM_MIB(5) および UBBCONFIG(5) を参照してください。
tlisten のリンクに LLE を設定する方法
tlisten(1) は、ネットワークに依存しないリスナ・プロセスであり、tmboot(1) などの管理ユーティリティを実行できるマルチ・マシン・アプリケーションのノード間の接続を確立します。アプリケーション管理者は、UBBCONFIG ファイルの NETWORK セクションで定義されたすべてのマシンに tlisten をインストールします。
tlisten リンクに LLE を設定するには、ブリッジ間のリンクに LLE を設定する方法で説明した手順に従います。必要に応じ、次のコマンドを入力して、ローカル・マシンで別個の tlisten のインスタンスを起動できます。
tlisten -l nlsaddr [-z min -Z max]
nlsaddr 値は、UBBCONFIG ファイルの NETWORK セクションでこのマシンの NLSADDR パラメータに指定した値と同じにする必要があります。詳細については、『BEA Tuxedo コマンド・リファレンス』の tlisten(1)、および『BEA Tuxedo のファイル形式とデータ記述方法』の TM_MIB(5) および UBBCONFIG(5) を参照してください。
ドメイン・ゲートウェイのリンクに LLE を設定する方法
ドメイン・ゲートウェイは GWTDOMAIN プロセスであり、複数の ATMI アプリケーション間でサービス要求とサービス応答を中継します。また、TCP/IP などのネットワーク・トランスポート・プロトコルを介して流れる、特別に設計されたトランザクション処理 (TP) プロトコルを使用して相互運用性を実現します。
ドメイン・ゲートウェイはドメイン・ゲートウェイ・グループに属します。各ドメイン・ゲートウェイ・グループには、別個の Domains コンフィギュレーション・ファイルが必要です。ドメイン・ゲートウェイ・グループは、1 つまたは複数のリモート・ドメイン・アクセス・ポイントと通信するローカル・ドメイン・アクセス・ポイントです。アプリケーションのコンフィギュレーション・ファイルである UBBCONFIG および TUXCONFIG と同様に、Domains のコンフィギュレーション・ファイルもテキスト形式で作成され、バイナリ形式に変換されます。テキスト形式の場合は DMCONFIG ファイル、バイナリ形式の場合は BDMCONFIG ファイルと呼ばれます。DMCONFIG ファイルと BDMCONFIG ファイル、および関連する環境変数については、『BEA Tuxedo のファイル形式とデータ記述方法』の DMCONFIG(5) を参照してください。
管理者は、各ローカル・ドメイン・アクセス・ポイント (リモート・ドメイン・アクセス・ポイントからローカル・サービスに対する要求を受け取るポイント) に対して、DMCONFIG ファイルの DM_TDOMAIN セクションにエントリを作成する必要があります。また、定義済みのローカル・ドメイン・アクセス・ポイントからアクセス可能なリモート・ドメイン・アクセス・ポイントに対してエントリを作成する必要もあります。LLE の min および max パラメータのデフォルト値を上書きする場合は、ドメイン・アクセス・ポイントごとに、オプションのランタイム・パラメータである MINENCRYPTBITS および MAXENCRYPTBITS を指定する必要があります (See (詳細については、min 値と max 値についてを参照してください)。ただし、ドメイン間のリンク・レベルの暗号化は、ドメインがあるマシンに LLE がインストールされている場合にのみ使用できます。
ドメイン・ゲートウェイのリンクに LLE を設定するには、次の手順に従います。
*DM_TDOMAIN
# Local network addresses
LDOM NWADDR="local_domain_network_address"
NWDEVICE="local_domain_device"
MINENCRYPTBITS=min
MAXENCRYPTBITS=max
.
.
.
# Remote network addresses
RDOM NWADDR="remote_domain_network_address"
NWDEVICE="remote_domain_device"
MINENCRYPTBITS=min
MAXENCRYPTBITS=max
.
.
.
上の例では、tmboot(1) を実行すると ATMI アプリケーションが起動します。各ドメイン・ゲートウェイは BDMCONFIG ファイルを読み込んで MINENCRYPTBITS や MAXENCRYPTBITS などのさまざまなパラメータにアクセスし、ローカル・ドメインおよびリモート・ドメインにそれらのパラメータを複製転送します。ローカル・ドメインがリモート・ドメインとのネットワーク・リンクを確立するとき、これらの 2 つのドメインは、双方でサポートされるキーの最大サイズが一致するまでキー・サイズの調整を行います。
詳細については、『BEA Tuxedo のファイル形式とデータ記述方法』の DMCONFIG(5) を参照してください。また、『BEA Tuxedo Domains コンポーネント』の2-47 ページの「Domains コンフィギュレーションのセキュリティの設定」“ も参照してください。
関連項目
公開鍵セキュリティの管理
分散型の ATMI アプリケーションの安全性を確保する最も効果的な方法は、リンク・レベルの暗号化と公開鍵による暗号化を組み合わせることです。公開鍵による暗号化は、公開鍵セキュリティの基盤となるフレームワークです。
公開鍵セキュリティにより、メッセージ・ベースのデジタル署名とメッセージ・ベースの暗号化を ATMI アプリケーションに統合することができます。これらの機能を組み合わせると、データの完全性と機密性が保たれます。これは、ATMI アプリケーションが外部の ATMI アプリケーションまたはワークステーション・クライアントと相互運用する場合に特に重要です。
公開鍵セキュリティで推奨されている事項について
公開鍵と秘密鍵の組み合わせの割り当て
アプリケーションの管理者と開発者は、公開鍵と秘密鍵の組み合わせ、および関連するデジタル証明書を認証するための認証局を選択する必要があります。次に、鍵の組み合わせを ATMI アプリケーションに割り当てる方法を決定する必要があります。鍵の組み合わせを割り当てる方法はたくさんあります。管理者は、次のうち、1 つまたは複数の方法で鍵の組み合わせを割り当てることができます。
アプリケーションの管理者と開発者は、鍵の組み合わせを割り当てる方法を選択し、実際に割り当てる責任があります。ただし、鍵の組み合わせを割り当てた後の管理作業を行う必要はありません。鍵の配布と管理は、公開鍵セキュリティのプラグインによって行われます。
デジタル署名方針の設定
管理者は、次のコンフィギュレーション・パラメータを使用して、ATMI アプリケーションのデジタル署名に関する方針を設定します。
デジタル署名のタイムスタンプに設定された将来の日付を制限する
SIGNATURE_AHEAD は、コンフィギュレーション階層のうち、ドメイン・レベルで指定されるため、このパラメータに割り当てた値は、ATMI アプリケーションで実行されるすべてのプロセスに適用されます。ドメイン全体にわたるパラメータは、UBBCONFIG ファイルの RESOURCES セクションおよび TM_MIB の T_DOMAIN クラスで設定されます。
SIGNATURE_AHEAD パラメータは、受信したメッセージ・バッファに添付されたタイムスタンプと、検証システムのローカル・クロックに表示される現在時刻との最大時間差を設定します。最小値は 1 秒です。最大値は 2147483647 秒です。デフォルトは 3600 秒 (1 時間) です。
デジタル署名のタイムスタンプが遠い将来の時刻を示す場合、その署名は無効と見なされます。このパラメータを設定すると、将来の日付が指定された署名を拒否できます。ただし、ローカル・クロックの時刻との間に多少ずれが生じていても、その分は無視されます。
将来の日付を制限する UBBCONFIG のエントリ例
*RESOURCES
SIGNATURE_AHEAD 2400
デジタル署名のタイムスタンプに設定された過去の日付を制限する
SIGNATURE_BEHIND は、コンフィギュレーション階層のうち、ドメイン・レベルで指定されるため、このパラメータに割り当てた値は、ATMI アプリケーションで実行されるすべてのプロセスに適用されます。ドメイン全体にわたるパラメータは、UBBCONFIG ファイルの RESOURCES セクションおよび TM_MIB の T_DOMAIN クラスで設定されます。
SIGNATURE_BEHIND パラメータは、検証システムのローカル・クロックに表示される現在時刻と、受信したメッセージ・バッファに添付されたタイムスタンプとの最大時間差を設定します。最小値は 1 秒です。最大値は 2147483647 秒です。デフォルト値は 604800 秒 (1 週間) です。
デジタル署名のタイムスタンプ値が遠い過去の時刻を示す場合、その署名は無効と見なされます。このパラメータを設定すると、リプレイ攻撃、つまり、署名付きの有効なバッファが再びシステムに送信されるのを阻止することができます。ただし、非同期通信を行うシステム、たとえばディスク・ベースのキューを使用するシステムでは、かなり古い署名が添付されたバッファが有効と見なされる場合があります。したがって、非同期通信を行うシステムでは、SIGNATURE_BEHIND の設定を増やしてください。
過去の日付を制限する UBBCONFIG のエントリ例
*RESOURCES
SIGNATURE_BEHIND 300000
受信メッセージに対する署名方針の適用
SIGNATURE_REQUIRED は、コンフィギュレーションの階層のうち、次の 4 つのレベルのどこでも指定できます。
特定のレベルで SIGNATURE_REQUIRED に Y (はい) を設定すると、下位レベルで動作するすべてのプロセスに署名が必要となります。たとえば、mach1 というマシンで SIGNATURE_REQUIRED に Y を設定すると、mach1 上で動作するすべてのプロセスは、デジタル署名が添付されたメッセージだけを受け付けます。
ドメイン全体にわたるレベル、マシン・レベル、グループ・レベル、またはサービス・レベルでは、SIGNATURE_REQUIRED=Y および ENCRYPTION_REQUIRED=Y を同時に指定することができます。ENCRYPTION_REQUIRED の詳細については、受信メッセージに対する暗号化方針の適用を参照してください。
制限
SIGNATURE_REQUIRED を指定するかどうかの方針は、アプリケーション・サービス、アプリケーション・イベント、およびアプリケーション・エンキュー要求に対してのみ適用されます。システム生成されたサービス呼び出しや、システム・イベントのポストには適用されません。
例
mach1 というマシンに SIGNATURE_REQUIRED を設定するには、次の手順に従います。
*MACHINES
mach1 LMID="machine_logical_name"
TUXCONFIG="absolute_path_name_to_tuxconfig_file"
TUXDIR="absolute_path_name_to_BEA_Tuxedo_directory"
APPDIR="absolute_path_name_to_application_directory"
SIGNATURE_REQUIRED=Y
上の例では、tmboot(1) を実行すると、ATMI アプリケーションが起動し、SIGNATURE_REQUIRED=Y パラメータが mach1 というマシンに渡されます。この時点で、mach1 によって宣言されたすべてのアプリケーション・サービスは、ゲートウェイ・プロセスによって宣言されたアプリケーション・サービスも含め、有効なデジタル署名が添付されたメッセージだけを受け付けることができます。mach1 によって制御されるプロセスが、有効なデジタル署名が添付されていないメッセージを受信すると、システム側では次のアクションが実行されます。
注記 NULL バッファ (空のバッファ) にデジタル署名を添付することはできません。したがって、デジタル署名を必要とするプロセスで受信された NULL バッファは、上記のいずれかの方法で、システム側で拒否されます。
イベント・ブローカの署名方針の適用
ポスト済みのメッセージ・バッファにデジタル署名が添付されると、これらの署名は保存され、メッセージ・バッファと共に、適切なイベントのサブスクライバに転送されます。
TMUSREVT(5) システム・サーバが、デジタル署名を必要とするドメイン、マシン、またはサーバ・グループで実行されている場合、このサーバは、コンポジット署名ステータスが TPSIGN_OK に設定されていないイベントを拒否します。詳細については、コンポジット署名ステータスについてを参照してください。
TMUSREVT サーバは、サービスの呼び出しやキューへのメッセージの登録などの、サブスクリプションに関する通知アクションを実行できます。有効なデジタル署名を必要とするサービスやキューに対して、有効なデジタル署名が添付されていないメッセージをポストすると、サブスクリプションの通知アクションは失敗します。
システム・イベント (システム側でポストされ、TMSYSEVT サーバで処理されるイベント) には、デジタル署名を添付することができます。デジタル署名に関する管理方針は、TMSYSEVT(5) サーバには適用されません。
/Q の署名方針の適用
キューに登録されたバッファにデジタル署名が添付されると、署名はキュー内に保存され、キューから取り出すプロセスの実行時に転送されます。また、メッセージが TMQFORWARD(5) によって処理され、サービスが呼び出されると、署名は保存されます。
TMQUEUE(5) システム・サーバが、デジタル署名を必要とするドメイン、マシン、またはサーバ・グループで実行されている場合、このサーバは、コンポジット署名ステータスが TPSIGN_OK に設定されていないエンキュー要求を拒否します。詳細については、コンポジット署名ステータスについてを参照してください。さらに、キュー・スペースに関連するサービス名に対してこのような方針が有効な場合、TMQUEUE サーバはデジタル署名を必要とします。
リモート・クライアントの署名方針の適用
ワークステーション・ハンドラ (WSH) が、デジタル署名を必要とするドメイン、マシン、またはサーバ・グループで実行されている場合、WSH は、コンポジット署名ステータスが TPSIGN_OK に設定されていない、アプリケーション・データを含むメッセージ・バッファを拒否します。詳細については、コンポジット署名ステータスについてを参照してください。
暗号化方針の設定
管理者は、次のコンフィギュレーション・パラメータを使用して、ATMI アプリケーションの暗号化方針を設定します。
|
パラメータ名 |
説明 |
設定 |
|---|---|---|
|
UBBCONFIG の ENCRYPTION_REQUIRED (TM_MIB の TA_ENCRYPTION_REQUIRED) |
受信側のプロセスで受け付けるメッセージ・バッファを、暗号化されたものだけに制限するかどうかを決定します。 |
Y (yes−暗号化が必要) または N (no−暗号化は不要) を指定します。デフォルト値は N です。 |
受信メッセージに対する暗号化方針の適用
ENCRYPTION_REQUIRED は、コンフィギュレーションの階層のうち、次の 4 つのレベルのどこでも指定できます。
特定のレベルで ENCRYPTION_REQUIRED に Y (はい) を設定すると、下位レベルで動作するすべてのプロセスに暗号化が必要となります。たとえば、mach1 というマシンで ENCRYPTION_REQUIRED に Y を設定すると、mach1 上で動作するすべてのプロセスは、暗号化されたメッセージだけを受け付けます。
ドメイン全体にわたるレベル、マシン・レベル、グループ・レベル、またはサービス・レベルでは、ENCRYPTION_REQUIRED=Y および SIGNATURE_REQUIRED=Y を同時に指定することができます。SIGNATURE_REQUIRED の詳細については、受信メッセージに対する署名方針の適用を参照してください。
制限
ENCRYPTION_REQUIRED を指定するかどうかの方針は、アプリケーション・サービス、アプリケーション・イベント、およびアプリケーション・エンキュー要求に対してのみ適用されます。システム生成されたサービス呼び出しや、システム・イベントのポストには適用されません。
例
STDGRP というサーバ・グループに ENCRYPTION_REQUIRED を設定するには、次の手順に従います。
*GROUPS
STDGRP LMID="machine_logical_name"
GRPNO="server_group_number"
ENCRYPTION_REQUIRED=Y
上の例では、tmboot(1) を実行すると ATMI アプリケーションが起動し、ENCRYPTION_REQUIRED=Y パラメータが STDGRP というサーバ・グループに渡されます。この時点で、STDGRP によって宣言されたすべてのアプリケーション・サービスは、ゲートウェイ・プロセスによって宣言されたアプリケーション・サービスも含め、暗号化のエンベロープで保護されたメッセージだけを受け付けることができます。STDGRP によって制御されるプロセスが、暗号化されていないメッセージを受信すると、システム側では次のアクションが実行されます。
注記 NULL バッファ (空のバッファ) は暗号化できません。したがって、暗号化を必要とするプロセスで受信された NULL バッファは、上記のいずれかの方法で、システム側で拒否されます。
イベント・ブローカの暗号化方針の適用
ポスト済みのメッセージ・バッファが暗号化されると、これらの署名は保存され、暗号化されたメッセージの内容と共に、適切なイベントのサブスクライバに転送されます。
TMUSREVT(5) システム・サーバが、暗号化を必要とするドメイン、マシン、またはサーバ・グループで実行されている場合、このサーバは、暗号化されていないメッセージを拒否します。
TMUSREVT サーバは、サービスの呼び出しやキューへのメッセージの登録などの、サブスクリプションに関する通知アクションを実行できます。入力する情報の暗号化を必要とするサービスやキューに対して、暗号化されていないメッセージをポストすると、サブスクリプションの通知アクションは失敗します。また、サブスクライバが適切な復号化キーを保持していない場合も、イベント通知アクションは失敗します。
システム・イベント (システム側でポストされ、TMSYSEVT サーバで処理されるイベント) は、暗号化できます。暗号化に関する管理方針は、TMSYSEVT(5) サーバには適用されません。
/Q の暗号化方針の適用
キューに登録されたバッファが暗号化されると、このステータスはキュー内に保存され、バッファは、キューから取り出すプロセスの実行時に暗号化された形式で転送されます。また、メッセージが TMQFORWARD(5) によって処理され、サービスが呼び出されると、暗号化のステータスは保存されます。
TMQUEUE(5) システム・サーバが、暗号化を必要とするドメイン、マシン、またはサーバ・グループで実行されている場合、このサーバは、暗号化されていないエンキュー要求を拒否します。さらに、キュー・スペースに関連するサービス名に対してこのような方針が有効な場合、TMQUEUE サーバは、暗号化を必要とします。
リモート・クライアントの暗号化方針の適用
ワークステーション・ハンドラ (WSH) が、暗号化を必要とするドメイン、マシン、またはサーバ・グループで実行されている場合、WSH は、暗号化されていないアプリケーション・データ・バッファを含むメッセージ・バッファを拒否します。
プラグインによる復号化キーの初期化
管理者は、次のコンフィギュレーション・パラメータを使用して、アプリケーション内で動作するシステム・プロセスのプリンシパル名と復号化キーを指定します。
上記の 3 つのパラメータは、コンフィギュレーションの階層のうち、次の 4 つのレベルのどこでも指定できます。
特定のコンフィギュレーション・レベルでのプリンシパル名および復号化キーは、下位レベルで上書きできます。たとえば、mach1 というマシンにプリンシパル名と復号化キーを設定し、mach1 上で動作する serv1 というサーバにプリンシパル名と復号化キーを設定したとします。この場合、mach1 のプロセスは次のように動作します。
ATMI アプリケーションが起動すると、設定された復号化キーは自動的にオープンします。次の図は、このプロセスのしくみを示しています。
図 2-13 復号化キーの初期化例
tmloadcf を呼び出してコンフィギュレーションをロードするたびに、SEC_PRINCIPAL_PASSVAR に設定した各復号化キーに対するパスワードの入力を求められます。各パスワードを手動で入力しないで済むようにするには、パスワードを自動的に入力するスクリプトを記述します。このスクリプトには、各パスワードの変数定義を組み込み、次の行で終了する必要があります。
tmloadcf -y ubbconfig_name < /dev/null
ATMI アプリケーションの起動時にオープンされた復号化キーをクローズするパーミッションは、アプリケーション・プロセスにはありません。復号化キーは、tmshutdown(1) コマンドを実行して ATMI アプリケーションをシャットダウンするまで、オープンしたままの状態になります。
プリンシパル名および復号化キーを指定する UBBCONFIG のエントリ例
*RESOURCES
SEC_PRINCIPAL_NAME "Tommy"
SEC_PRINCIPAL_LOCATION "/home/jhn/secsapp/cert/tommy.pvk"
SEC_PRINCIPAL_PASSVAR "TOMMY_VAR"
.
.
.
*SERVERS
"TMQUEUE" SRVGRP="QUEGROUP" SRVID=1
CLOPT="-s secsdb:TMQUEUE"
SEC_PRINCIPAL_NAME= "TOUPPER"
SEC_PRINCIPAL_LOCATION="/home/jhn/secsapp/cert/TOUPPER.pvk"
SEC_PRINCIPAL_PASSVAR= "TOUPPER_VAR"
障害のレポートと監査
この節では、デジタル署名とメッセージの暗号化で検出されたエラーがシステム側でどのように処理されるかを説明します。
デジタル署名のエラー処理
メッセージの改ざんが検出された場合、つまり、コンポジット署名ステータスが TPSIGN_TAMPERED_MESSAGE または TPSIGN_TAMPERED_CERT の場合 (コンポジット署名ステータスについてを参照)、システム側では次のアクションが実行されます。
有効期限が切れた証明書、取り消された証明書、有効期限が切れた署名、または古い日付の署名が検出された場合、システム側では次のアクションが実行されます。
SIGNATURE_REQUIRED=Y の設定に基づいて有効なデジタル署名を必要とするプロセスが、コンポジット署名ステータス TPSIGN_UNKNOWN が添付されたメッセージを受信した場合、システム側では次のアクションが実行されます。
暗号化のエラー処理
プロセスが、メッセージの暗号化エンベロープのいずれかと一致するオープンした復号化キーを持たない状態で、暗号化されたメッセージを受信した場合、システムは次のアクションを実行します。
ENCRYPTION_REQUIRED=Y の設定に基づいて暗号化された入力を必要とするプロセスが、暗号化されていないメッセージを受信した場合、システムは次のアクションを実行します。
関連項目
デフォルトの認証と認可の管理
デフォルトの認証および認可は、BEA Tuxedo システムで最初に実現された、BEA Tuxedo の従来の認証および認可と同じように機能します。
デフォルトの認証には、認証なし (NONE)、アプリケーション・パスワード (APP_PW)、ユーザ・レベルの認証を実行 (USER_AUTH)、という 3 つのセキュリティ・レベルが用意されています。デフォルトの認可には、2 つのセキュリティ・レベル、オプションのアクセス制御リスト (ACL) および必須のアクセス制御リスト (MANDATORY_ACL) があります。アクセス制御リストは、ユーザが ATMI アプリケーションへの参加を認証された場合にのみ有効になります。
セキュリティ・レベルの指定
管理者は、UBBCONFIG コンフィギュレーション・ファイルを編集するか、TM_MIB を変更するか、または BEA Administration Console を使用することにより、ATMI アプリケーションのセキュリティ・レベルを指定できます。
コンフィギュレーション・ファイルを編集してセキュリティを指定する
UBBCONFIG ファイルで、SECURITY パラメータに適切な値を設定します。
SECURITY {NONE | APP_PW | USER_AUTH | ACL | MANDATORY_ACL}デフォルト値は NONE です。SECURITY に USER_AUTH、ACL、または MANDATORY_ACL を設定すると、システム側で提供される認証サーバ AUTHSVR が起動し、ユーザごとの認証が行われます。
NONE 以外の値を選択した場合は、MASTER サイトで動作する各 ATMI アプリケーションに対して、一意の APPDIR 変数が設定されていることを確認します。セキュリティ機能を使用している場合、複数の ATMI アプリケーションが同じアプリケーション・ディレクトリを共有することはできません。
TM_MIB を変更してセキュリティを指定する
TM_MIB を使用してセキュリティ・レベルを指定するには、T_DOMAIN クラスの TA_SECURITY 属性に値を割り当てなければなりません。ATMI アプリケーションが非アクティブの場合、管理者は、TA_SECURITY に対して UBBCONFIG で有効な任意の値を設定できます。このタスクを完了するには、管理インターフェイス tpadmcall(3c) を実行します。
BEA Administration Console を使用してセキュリティを指定する
BEA Administration Console を使用してセキュリティ・レベルを指定することもできます。BEA Administration Console は、ATMI アプリケーションをコンフィギュレーションし、監視し、動的に再コンフィギュレーションするための Web ベースのツールです。
認証サーバの設定
BEA Tuxedo サーバである AUTHSVR は、認証を実行する 1 つのサービス (AUTHSVC) を備えています。セキュリティ・レベルが ACL または MANDATORY_ACL に設定されている場合、AUTHSVR サーバは、AUTHSVC を ..AUTHSVC として宣言します。
AUTHSVC を ATMI アプリケーションに追加するには、UBBCONFIG ファイルで、認証サービスとして AUTHSVC を定義し、認証サーバとして AUTHSVR を定義する必要があります。次に例を示します。
*RESOURCES
SECURITY USER_AUTH
AUTHSVC AUTHSVC
.
.
.
*SERVERS
AUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
パラメータと値の組み合わせである AUTHSVC AUTHSVC のエントリを省略すると、デフォルトで AUTHSVC が呼び出されます。
別の例を示します。
*RESOURCES
SECURITY ACL
AUTHSVC ..AUTHSVC
.
.
.
*SERVERS
AUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
パラメータと値の組み合わせである AUTHSVC ..AUTHSVC のエントリを省略すると、デフォルトで ..AUTHSVC が呼び出されます。
AUTHSVR は、ATMI アプリケーション固有のロジックをインプリメントする認証サーバと置き換えることができます。たとえば、広く使用されている Kerberos のメカニズムを使用して認証を行うため、認証サーバをカスタマイズすることもできます。
カスタマイズした認証サービスを ATMI アプリケーションに追加するには、UBBCONFIG ファイルで認証サービスと認証サーバを定義する必要があります。次に例を示します。
*RESOURCES
SECURITY USER_AUTH
AUTHSVC KERBEROS
.
.
.
*SERVERS
KERBEROSSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
注記 Tuxedo ユーザを認証するためのセキュリティ・データベースとして WebLogic Server を使用するには、認証サーバとして LAUTHSVR を使用して、シングル・ポイント・セキュリティ管理をインプリメントする必要があります。WebLogic Server と LAUTHSVR およびシングル・ポイント・セキュリティ管理については、シングル・ポイント・セキュリティ管理のインプリメントを参照してください。
関連項目
アプリケーション・パスワードによるセキュリティを有効にする方法
デフォルトの認証には、「アプリケーション・パスワード」というセキュリティ・レベルが用意されており、これは、コンフィギュレーション・ファイルの SECURITY APP_PW で指定すると有効になります。このセキュリティ・レベルでは、ATMI アプリケーションに参加するすべてのクライアントに対してアプリケーション・パスワードの入力が求められます。管理者は、ATMI アプリケーション全体に対して 1 つのパスワードを定義し、認可されたユーザだけにパスワードを通知します。
APP_PW のセキュリティ・レベルを有効にするには、次の手順に従います。
関連項目
ユーザ・レベルの認証によるセキュリティを有効にする方法
デフォルトの認証には、「ユーザ・レベルの認証」というセキュリティ・レベルが用意されており、これは、コンフィギュレーション・ファイルの SECURITY USER_AUTH で指定すると有効になります。このセキュリティ・レベルでは、ATMI アプリケーションに参加するため、各クライアントは、アプリケーション・パスワードのほか、有効なユーザ名とユーザ固有のデータ (パスワードなど) を提示しなければなりません。ユーザごとのパスワードは、tpusr ファイルに格納されている、ユーザ名とクライアント名の組み合わせに関連付けられたパスワードに一致しなければなりません。ユーザごとのパスワードと、tpusr 内のユーザ名/クライアント名およびパスワードとの照合は、認証サーバ AUTHSVR の認証サービス AUTHSVC によって実行されます。
USER_AUTH のセキュリティ・レベルを有効にするには、次の手順に従います。
これらの手順については、次の 2 つの節で説明します。
UBBCONFIG ファイルを設定する
*RESOURCES
SECURITY USER_AUTH
AUTHSVC AUTHSVC
.
.
.
*SERVERS
AUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
ユーザ・ファイルとグループ・ファイルの設定
デフォルトの認可システムで使用できる AUTHSVR とアクセス制御チェック機能では、tpusr というユーザ・ファイルが必要です。このファイルには、ATMI アプリケーションへの参加を許可されたクライアント・ユーザのリストが含まれています。アプリケーション管理者は、tpusradd(1)、tpusrdel(1)、および tpusrmod(1) の各コマンドを使用して tpusr を管理します。AUTHSVR サーバは、tpusr ファイルに格納されているクライアント・ユーザ情報を入力として受け取ります。AUTHSVR サーバは、この情報を使用して、ATMI アプリケーションに参加しようとするクライアントを認証します。
次は、tpusr ファイル内のサンプル・エントリです。
AUTHSVR とアクセス制御チェック機能には、tpgrp というグループ・ファイルも必要です。このファイルには、ATMI アプリケーションへの参加を許可されたクライアント・ユーザに関連付けられたグループのリストが含まれています。アプリケーション管理者は、tpgrpadd(1)、tpgrpdel(1)、および tpgrpmod(1) の各コマンドを使用して tpgrp を管理します。 AUTHSVC は、認証されたクライアント・ユーザにアプリケーション・キーを割り当てます。アプリケーション・キーには、USER_AUTH、ACL、または MANDATORY_ACL のセキュリティ・レベルに対するユーザ識別子および関連するグループ識別子が含まれています。アプリケーション・キーの詳細については、アプリケーション・キーを参照してください。 次は、tpgrp ファイル内のサンプル・エントリです。
管理者は、tpusr ファイルおよび tpgrp ファイルで、ユーザとグループのリストを定義しなければなりません。これらのファイルは、ATMI アプリケーションの APPDIR 変数で定義した最初のパス名によって参照されるディレクトリにあります。これらのファイルは、コロンで区切られたフラットなテキスト・ファイルであり、アプリケーション管理者だけが読み書きを行う権限を持ちます。 システムのセキュリティ・データ・ファイルを BEA Tuxedo のユーザ・ファイルとグループ・ファイルに変換する ホスト・システムには、ユーザとグループのリストを格納したファイルが既に存在する場合があります。これらのファイルを ATMI アプリケーションのユーザ・ファイルおよびグループ・ファイルとして使用するには、BEA Tuxedo システムで受け付けられる形式に変換する必要があります。ファイルを変換するには、次の手順例に示すように、tpaclcvt(1) コマンドを実行します。この手順例は、UNIX ホスト・マシン用に記述されています。
tpaclcvt -u /etc/password
注記 シャドウ・パスワード・ファイルを使用するシステムでは、ファイル内のユーザごとにパスワードの入力が要求されます。
ユーザおよびグループを追加、変更、または削除する
BEA Tuxedo システムでは、アプリケーション・ユーザのリストを tpusr というファイルで管理し、グループのリストを tpgrp というファイルで管理する必要があります。これらのファイルのエントリを変更するには、コマンドを発行するか、または ACL_MIB 内の適切な属性を変更します。
コマンドを使用してユーザおよびグループのエントリを変更する
次のいずれかのコマンドを実行すると、tpusr ファイルおよび tpgrp ファイルのエントリをいつでも追加、変更、または削除できます。
これらのコマンドを実行するには、次の手順に従います。
ACL_MIB を使用してユーザおよびグループのエントリを変更する
コマンド行インターフェイス以外の方法として、ACL_MIB(5) の T_ACLPRINCIPAL クラスの該当する属性値を変更して、tpusr のユーザ・エントリを追加、変更、または削除することができます。tpusradd(1) では一度に 1 人のユーザしか追加できないため、同時に複数のユーザ・エントリを追加する場合は、この方法の方がコマンド行インターフェイスより効率的です。
同様に、ACL_MIB(5) の T_ACLGROUP クラスの該当する属性値を変更すると、tpgrp のグループ・エントリを追加、変更、または削除できます。tpgrpadd(1) では一度に 1 つのグループしか追加できないため、同時に複数のグループ・エントリを追加する場合は、この方法の方がコマンド行インターフェイスより効率的です。
BEA Administration Console を使用すると、最も簡単に MIB にアクセスできます。
関連項目
アクセス制御リストによるセキュリティの有効化
デフォルトの認証には、サービスを実行し、イベントをポストし、アプリケーション・キューのメッセージをキューに登録 (または登録解除) するユーザを決定するアクセス制御リストの機能が備わっています。セキュリティ・レベルには、オプションのアクセス制御リスト (ACL) および必須のアクセス制御リスト (MANDATORY_ACL) があります。アクセス制御リストは、ユーザが ATMI アプリケーションへの参加を認証された場合にのみ有効になります。
アクセス制御リストを使用すると、管理者はユーザを複数のグループにまとめ、それらのグループに対して、メンバ・ユーザがアクセス権を持つオブジェクトを関連付けることができます。アクセス制御は、次の理由により、グループ・レベルで行われます。
アクセス制御のチェック機能は、アプリケーション管理者によって作成および管理される 3 つのファイルに基づいています。
クライアントのアプリケーション・キー (クライアントを有効なユーザおよび有効なグループ・メンバとして識別する情報を含む) を解析することによって、エンティティ (サービス、イベント、またはアプリケーション・キューなど) は、ユーザが属するグループを識別できます。tpacl ファイルをチェックすることによって、エンティティは、クライアントのグループにアクセス・パーミッションが付与されているかどうかを判定できます。
アプリケーション管理者、アプリケーション・オペレータ、およびアプリケーション管理者またはオペレータの権限で実行中のプロセスやサービス要求は、ACL によるパーミッションのチェックの対象にはなりません。
ユーザ・レベルの ACL エントリが必要な場合は、各ユーザのグループを作成し、そのグループを tpacl ファイルの該当するアプリケーション・エンティティにマッピングします。
オプションの ACL セキュリティを有効にする方法
デフォルトの認証には、「オプションのアクセス制御リスト (ACL)」というセキュリティ・レベルが用意されており、これは、コンフィギュレーション・ファイルの SECURITY ACL で指定すると有効になります。このセキュリティ・レベルでは、各クライアントは、ATMI アプリケーションに参加するため、アプリケーション・パスワード、ユーザ名、およびユーザ固有のデータ (パスワードなど) を提示しなければなりません。ターゲット・アプリケーションのエンティティに関連するエントリが tpacl ファイルになくても、ユーザはそのエンティティにアクセスできます。
管理者は、このセキュリティ・レベルを使用して、セキュリティを強化したいリソースに対してのみアクセス権を設定できます。つまり、すべてのユーザにアクセスを許可するサービス、イベント、およびアプリケーション・キューについて、tpacl ファイルにエントリを追加する必要はありません。ただし、tpacl ファイルにターゲット・アプリケーションのエンティティに関連するエントリがあり、ユーザがこれにアクセスしようとする場合、そのユーザは、そのエンティティへのアクセスを許可されたグループのメンバでなければなりません。そうでない場合、アクセスは拒否されます。
ACL のセキュリティ・レベルを有効にするには、次の手順に従います。
これらの手順については、次の 2 つの節で説明します。
UBBCONFIG ファイルを設定する
*RESOURCES
SECURITY ACL
AUTHSVC ..AUTHSVC
.
.
.
*SERVERS
AUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
ACL ファイルの設定
アクセス制御のチェック機能では、tpusr というユーザ・ファイル、tpgrp というグループ・ファイル、および tpacl という ACL ファイルが必要です。ACL ファイルには、グループとアプリケーション・エンティティのマッピングが含まれています。エンティティとは、サービス、イベント、またはアプリケーション・キューです。
次は、tpacl ファイル内のサンプル・エントリです。
管理者は tpacl ファイルでエントリを定義しなければなりません。tpacl ファイルは、ATMI アプリケーションの APPDIR 変数で定義した最初のパス名によって参照されるディレクトリにあります。これらのファイルは、コロンで区切られたフラットなテキスト・ファイルであり、アプリケーション管理者だけが読み書きを行う権限を持ちます。 tpacl ファイルの ACL エントリを変更するには、コマンドを発行するか、または ACL_MIB 内の適切な属性を変更します。 コマンドを使用して ACL エントリを変更する 次のいずれかのコマンドを実行すると、tpacl ファイルの ACL エントリをいつでも追加、変更、または削除できます。
これらのコマンドを実行するには、次の手順に従います。
ACL_MIB を使用して ACL エントリを変更する
コマンド行インターフェイス以外の方法として、ACL_MIB(5) の T_ACLPERM クラスの該当する属性値を変更して、tpacl の ACL エントリを追加、変更、または削除することができます。tpacladd(1) では一度に 1 つの ACL エントリしか追加できないため、同時に複数の ACL エントリを追加する場合は、この方法の方がコマンド行インターフェイスより効率的です。
BEA Administration Console を使用すると、最も簡単に MIB にアクセスできます。
必須の ACL セキュリティを有効にする方法
デフォルトの認証には、「必須のアクセス制御リスト」というセキュリティ・レベルが用意されており、これは、コンフィギュレーション・ファイルの SECURITY MANDATORY_ACL で指定すると有効になります。このセキュリティ・レベルでは、各クライアントは、ATMI アプリケーションに参加するため、アプリケーション・パスワード、ユーザ名、およびユーザ固有のデータ (パスワードなど) を提示しなければなりません。ターゲット・アプリケーションのエンティティに関連するエントリが tpacl ファイルにない場合、クライアントはそのエンティティにアクセスできません。 つまり、アクセスする必要のあるアプリケーション・エンティティのエントリが tpacl ファイルに存在していなければなりません。したがって、このレベルは「必須」と呼ばれます。
ただし、tpacl ファイルにターゲット・アプリケーションのエンティティに関連するエントリがあり、ユーザがこれにアクセスしようとする場合、そのユーザは、そのエンティティへのアクセスを許可されたグループのメンバでなければなりません。そうでない場合、アクセスは拒否されます。
MANDATORY_ACL のセキュリティ・レベルを有効にするには、次の手順に従います。
これらの手順については、次の 2 つの節で説明します。
UBBCONFIG ファイルを設定する
*RESOURCES
SECURITY MANDATORY_ACL
AUTHSVC ..AUTHSVC
.
.
.
*SERVERS
AUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
ACL ファイルの設定
ACL ファイルの設定を参照してください。
関連項目
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||