Oracle Tuxedo のセキュリティ機能

セキュリティの管理

以下の節では、Oracle Tuxedo ATMI アプリケーションのセキュリティ ポリシーを設定する方法について説明します。

セキュリティの管理とは

ATMI アプリケーションのセキュリティ管理とは、クライアント、サーバ マシン、ゲートウェイ リンクなどのアプリケーションのコンポーネントに対して、セキュリティ ポリシーを設定し、適用することです。ATMI アプリケーションに対するセキュリティ ポリシーはアプリケーション管理者が設定し、これらのポリシーは、ATMI アプリケーションの基盤となる Oracle Tuxedo システムによって実行されます。

Oracle Tuxedo システムには、次の ATMI 用のセキュリティ機能が用意されています。

アプリケーション管理者は、次の図に示すように、監査以外のすべてのセキュリティ機能をコンフィグレーションできます。

関連項目

セキュリティ管理のタスク

セキュリティ管理には、次のタスクが含まれます。

関連項目

Oracle Tuxedo レジストリの設定

1 つ以上のセキュリティ機能をカスタマイズして ATMI アプリケーションにコンフィグレーションする場合、アプリケーション管理者は Oracle Tuxedo レジストリについて知っておく必要があります。一方、デフォルトのセキュリティ機能だけを ATMI アプリケーションにコンフィグレーションする場合は、Oracle Tuxedo レジストリを変更する必要はありません。

Oracle Tuxedo レジストリは、プラグイン モジュールに関連する情報を格納しておくディスク ベースのリポジトリです。このレジストリには、デフォルトのセキュリティ プラグインに関する登録情報が最初に格納されています。

Oracle Tuxedo レジストリの目的

Oracle のほとんどのミドルウェア製品では、セキュリティなどのコア サービスのセットで構成される、共通のトランザクション処理のインフラストラクチャ (TP インフラストラクチャ) が使用されています。ATMI アプリケーションでは、適切に定義されたインタフェースを介して TP インフラストラクチャを使用できます。これらのインタフェースを使って独自のサービス コード モジュールであるプラグイン モジュール (プラグイン) をロードし、リンクすることにより、アプリケーション管理者は、TP インフラストラクチャのデフォルトの動作を変更できます。

プラグインをロードする最初の手順として、プラグインをホスト オペレーティング システムに登録します。プラグインを登録すると、プラグインのエントリが Oracle Tuxedo レジストリに追加されます。Oracle Tuxedo レジストリは、アクティブなプラグインの情報を格納するバイナリ ファイルのセットです。レジストリは、Oracle Tuxedo システムごとに用意されています。

ATMI アプリケーション内のすべてのワークステーション クライアントとサーバ マシンは、同じプラグイン モジュールのセットを使用する必要があります。

プラグインの登録

カスタマイズしたプラグインを使用する場合、ATMI アプリケーションの管理者はこれらのプラグインを登録し、その他のレジストリ関連のタスクを実行する責任があります。Oracle Tuxedo レジストリへのプラグインの登録は、ローカル マシンからのみ可能です。つまり、管理者は、リモートからホスト マシンにログオンしている間はプラグインを登録できません。

プラグインの管理では、次の 3 つのコマンドを使用できます。

これらのコマンドの使い方については、『Developing Security Services for ATMI and CORBA Environments』を参照してください (このマニュアルには、セキュリティ プラグインの仕様、およびセキュリティ プラグインのモジュールを動的にロードし、リンクするための Oracle Tuxedo のプラグイン インタフェースの説明が掲載されています)。また、カスタマイズしたプラグインをインストールする場合、プラグインの提供元であるサード パーティ ベンダは、これらのコマンドの使用方法を明記して、カスタマイズしたプラグインにアクセスするための Oracle Tuxedo レジストリの設定方法を示す必要があります。

セキュリティ プラグインの詳細 (インストール手順およびコンフィグレーション手順を含む) については、Oracle 社の営業担当者にお問い合わせください。

関連項目

セキュリティ用の ATMI アプリケーションのコンフィグレーション

アプリケーションが非アクティブの場合、アプリケーション管理者は MASTER マシンで ATMI アプリケーションのセキュリティをコンフィグレーションします。アプリケーションが起動すると、基底の Oracle Tuxedo システムにより、ATMI アプリケーション内のほかのマシンにコンフィグレーション情報が伝播されます。

管理者は、次のいずれかの方法でアプリケーションのセキュリティをコンフィグレーションできます。

セキュリティの種類 (認証、認可、リンク レベルの暗号化、または公開鍵) およびセキュリティ ソフトウェアの種類 (デフォルト版またはカスタマイズ版) に応じて、設定するセキュリティ パラメータは異なります。

コンフィグレーション ファイルの編集

UBBCONFIG コンフィグレーション ファイルを編集して、ATMI アプリケーションのセキュリティ ポリシーを設定することができます。UBBCONFIG コンフィグレーション ファイルにはどのような名前を付けることもできますが、ファイルの内容は、『Oracle Tuxedo のファイル形式とデータ記述方法』の UBBCONFIG(5) のリファレンス ページで指定された形式に準拠する必要があります。

UBBCONFIG ファイルおよび TUXCONFIG ファイル (バイナリ形式のコンフィグレーション ファイル) の詳細については、『Oracle Tuxedo アプリケーションの設定』の「コンフィグレーション ファイルについて」および「コンフィグレーション ファイルの作成」を参照してください。

TM_MIB の変更

TM_MIB でクラスのセットを定義することにより、ATMI アプリケーションの基本的な側面をコンフィグレーションし、管理することができます。クラスは、マシン、サーバ、ネットワークなど、コンポーネントごとに指定されます。管理要求の形式および管理応答の解釈については、汎用的な管理情報ベース (MIB: Management Information Base) のリファレンス ページである MIB(5) と TM_MIB(5) リファレンス ページを両方参照してください。MIB のリファレンス ページは、『Oracle Tuxedo のファイル形式とデータ記述方法』で定義されています。

ACL_MIB、DM_MIB、WS_MIB など、ほかの MIB コンポーネントも ATMI アプリケーションのセキュリティ管理に関係があります。ACL_MIB(5) リファレンス ページでは ACL_MIB、DM_MIB(5) リファレンス ページでは DM_MIB、WS_MIB(5) リファレンス ページでは WS_MIB を定義しています。

Oracle Tuxedo の MIB の詳細については、まず『Oracle Tuxedo のファイル形式とデータ記述方法』の「MIB(5)」を参照してください。『Oracle Tuxedo システム入門』も参照してください。

Oracle Administration Console の使用

Oracle Administration Console を使用して ATMI アプリケーションのセキュリティ ポリシーを変更することもできます。Oracle Administration Console は、アプリケーションをコンフィグレーションし、モニタし、動的に再コンフィグレーションするための Web ベースのツールです。

Oracle Administration Console の詳細については、『Oracle Tuxedo システム入門』を参照してください。

関連項目

管理環境の設定

アプリケーション管理者は、アプリケーションのコンフィグレーション作業の一貫として、ATMI アプリケーション用の環境変数をいくつか定義します。環境変数に定義される値は、Oracle Tuxedo の実行可能ファイルおよびデータ ライブラリを指す絶対パス名です。

ATMI アプリケーションを管理するには、これらのファイルにアクセスできなければなりません。たとえば、アプリケーションのセキュリティ管理に必要なコマンドは、すべて $TUXDIR/bin (UNIX ホスト マシンの場合)、または %TUXDIR%\bin (Windows 2003 ホスト マシンの場合) に格納されています。

管理環境の設定の詳細については、『Oracle Tuxedo アプリケーション実行時の管理』を参照してください。

関連項目

オペレーティング システム (OS) のセキュリティ管理

アプリケーション管理者は、Oracle Tuxedo システムの ATMI 環境のセキュリティのほか、オペレーティング システムに組み込まれているセキュリティ機能を十分に活用して、ファイル、ディレクトリ、およびシステム リソースに対するアクセスを制御する必要があります。

ほとんどの場合、ATMI アプリケーションは、アプリケーション管理者によって管理されます。アプリケーション管理者は、アプリケーションをコンフィグレーションし、起動し、実行中のアプリケーションをモニタし、必要に応じて動的に変更します。ATMI アプリケーションは、管理者が起動し、実行するため、サーバ プログラムは、管理者のパーミッションで実行されます。これで、サーバ プログラムは安全であり、「信頼性がある」と見なされます。この方法は、基盤となるオペレーティング システムのログイン メカニズムとパーミッション設定 (ファイル、ディレクトリ、およびシステム リソースに対する読み取り権と書き込み権の設定) に基づいています。

一方、クライアントを起動するのは管理者ではありません。クライアントは、自分自身のパーミッションを持つユーザによって直接実行されます。したがって、クライアントは信頼性があるとは言えません。

さらに、ネイティブ クライアント (つまり、サーバを実行中のマシンと同じマシンで実行中のクライアント) を実行するユーザは、コンフィグレーション ファイルにアクセスしたり、共有メモリ内の掲示板などのプロセス間通信 (IPC) のメカニズムにアクセスできます。Oracle Tuxedo システムのセキュリティが追加されても、ネイティブ クライアントを実行するクライアントは、常にこのようなアクセスを実現できます。

OS のセキュリティで推奨されている事項について

管理者は、次の一般的な方法に従うことにより、オペレーティング システムのセキュリティ レベルを高めることができます。

関連項目

認証の管理

認証とは、通信するプロセスどうしがお互いの ID を証明し合うことです。この機能は、これ以外のほぼすべてのセキュリティ機能の基盤となります。

この節で示す手順以外の認証の管理手順は、基底のアプリケーションの認証システムに依存します。カスタマイズした認証システムを管理する手順については、該当するシステムのマニュアルを参照してください。デフォルトの認証システムを管理する手順については、「デフォルトの認証と認可の管理」を参照してください。

次の図は、Oracle Tuxedo リリース 7.1 以上のソフトウェアで使用される、高信頼性委託型認証モデルをしています。高信頼性委託型認証モデルでは、ワークステーション ハンドラ (WSH) およびドメイン ゲートウェイ (GWTDOMAIN) は、「信頼性のあるシステム ゲートウェイ プロセス」と呼ばれます。これについては、「委任された信用認証について」を参照してください。

以下は、上の図のコンフィグレーションの設定に必要な操作の一覧です。すべての操作で、認証と認可のプラグインが必要になります。

関連項目

プリンシパル名の指定

管理者は、次のコンフィグレーション パラメータを使用して、Oracle Tuxedo リリース 7.1 以上のソフトウェアで作成した ATMI アプリケーションで実行するワークステーション ハンドラ (WSH)、ドメイン ゲートウェイ (GWTDOMAIN)、およびサーバ プロセスのプリンシパル名を指定します。

SEC_PRINCIPAL_NAME は、コンフィグレーションの階層のうち、次の 4 つのレベルのどこでも指定できます。

特定のコンフィグレーション レベルでのセキュリティ プリンシパル名は、下位レベルでオーバーライドできます。たとえば、mach1 というマシンに terri というプリンシパル名をコンフィグレーションし、mach1 上で動作する serv1 というサーバに john というプリンシパル名をコンフィグレーションしたとします。この場合、mach1 のプロセスは次のように動作します。

システム プロセスが資格を取得する方法

アプリケーションの起動時に、ATMI アプリケーション内のそれぞれの WSH、ドメイン ゲートウェイ、およびサーバ プロセスが認証プラグインを呼び出して (1) セキュリティ資格を取得し、(2) 認可トークンおよび監査トークンを取得するとき、セキュリティ プリンシパル名を引数として指定します。次の図は、この手順を示しています。

アプリケーション内の各ドメイン ゲートウェイ プロセスは、認証プラグインをもう一度呼び出して、割り当てられた接続プリンシパル名の資格とトークンを取得します。

システム プロセスで資格が必要な理由

WSH には資格が必要です。資格があれば、ワークステーション クライアントを認証してアプリケーションに参加させ、認証されたワークステーション クライアント用の認可トークンと監査トークンを取得することができます。WSH がリリース 7.1 より前のクライアント (Oracle 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) およびサーバ プロセスが、Oracle Tuxedo リリース 7.1 より前 (6.5 以前) のソフトウェアを実行しているマシンと相互運用するように指定できます。また、WSINTOPPRE71 環境変数を使用して、ワークステーション クライアントが Oracle Tuxedo リリース 7.1 より前のソフトウェアを実行するマシンと相互運用するよう指定できます。次に、これらのプロセスの相互運用性を説明する 4 つの図を示します。

上の図では、WSH がリリース 7.1 より前の古い認証プロトコルを使用してワークステーション クライアントを認証し、内部の「代替ユーザ」関数を呼び出してクライアントの認可トークンと監査トークンを取得し、それらのトークンをクライアント要求に添付しています。WSH を制御するワークステーション リスナ (WSL) に対して CLOPT -t オプションが指定されないと、新しい WSH と古いワークステーション クライアントとの間の通信は実現できません。

上の図では、WSH がリリース 7.1 より前の古い認証プロトコルを使用してワークステーション クライアントを認証します。クライアント要求は、認可トークンと監査トークンを受け取りません。ワークステーション クライアントに WSINTOPPRE71 環境変数が設定されていない場合、またはこの環境変数が N に設定されている場合、古い WSH と新しいワークステーション クライアントとの間の通信は実現できません。

上の図では、アプリケーション 1 のローカル ドメイン ゲートウェイ (GWTDOMAIN) が、リリース 7.1 より前の古い認証プロトコルを使用して、アプリケーション 2 のリモート ドメイン ゲートウェイを認証しています。ローカル ドメイン ゲートウェイは、リモート クライアントからの要求を受け取ると、内部の「代替ユーザ」関数を呼び出してリモート クライアントの認可トークンと監査トークンを取得し、それらのトークンをクライアント要求に添付します。アウトバウンドのクライアント要求 (アプリケーション 1 からアプリケーション 2 に送信される要求) の場合、要求に添付されたトークンは、ローカル ドメイン ゲートウェイで取り除かれ、要求はアプリケーション キーとともにアプリケーション 2 に送信されます (アプリケーション キーについては、「アプリケーション キー」を参照してください)。

ドメイン ゲートウェイに対して CLOPT -t オプションが指定されない場合、新しい ATMI アプリケーションと古い ATMI アプリケーションとの間の通信は実現できません。

上の図では、まずマシン 1 にある送信先のサーバが内部の「代替ユーザ」関数を呼び出し、マシン 2 にあるリモート クライアントの認可トークンと監査トークンを取得します。取得したトークンがクライアント要求に添付されると、サーバは、クライアントが認可チェックにパスしたと見なして要求を実行します。サーバに対して CLOPT -t オプションが指定されない場合、新しいサーバと古いクライアントとの間の通信は実現できません。

古いクライアントの ID の確認

WSH、ドメイン ゲートウェイ (GWTDOMAIN)、またはサーバ プロセスは、内部の「代替ユーザ」関数を呼び出して、古いクライアントの認可トークンと監査トークンを取得することにより、古いクライアントの ID を確認します。次の図は、この手順を示しています。

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) が別のドメイン ゲートウェイとのネットワーク リンクを確立しようとすると、次のようなイベントが発生します。

管理者は、次のコンフィグレーション パラメータを使用して、Oracle Tuxedo リリース 7.1 以上のソフトウェアを実行するドメイン ゲートウェイ間にリンクを確立します。

次の図は、デフォルトの認証プラグインを使用して、ドメイン間のリンクを確立する方法を示しています。

上の図で、開始側と対象側のドメイン ゲートウェイ間で交換される情報には、ドメイン ゲートウェイ用にコンフィグレーションされた 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 ポリシーの設定

管理者は、次のコンフィグレーション パラメータを使用して、Oracle Tuxedo リリース 7.1 以上のソフトウェアを実行する ATMI アプリケーション間で、アクセス制御リスト (ACL: Access Control List) ポリシーの設定と制御を行います。

以下の 3 つの図は、ACL_POLICY コンフィグレーションが、ローカル ドメイン ゲートウェイ (GWTDOMAIN) のプロセスの動作に与える影響を示します。

上の図では、各ドメイン ゲートウェイ (GWTDOMAIN) がインバウンドのクライアント要求 (リモート アプリケーションからネットワーク経由で受信される要求) を変更しています。変更された要求は、リモート ドメイン アクセス ポイントにコンフィグレーションされた LOCAL_PRINCIPAL_NAME の ID を持つため、その ID に設定されたアクセス権も取得することになります。各ドメイン ゲートウェイは、アウトバウンドのクライアント要求を変更しないで渡します。

このコンフィグレーションでは、各 ATMI アプリケーションに ACL データベースがあります。このデータベースには、ドメイン内のユーザに関するエントリだけが格納されます。たとえば、リモート ドメイン アクセス ポイントに対してコンフィグレーションされた LOCAL_PRINCIPAL_NAME の ID を持つユーザです。

上の図では、各ドメイン ゲートウェイ (GWTDOMAIN) は、インバウンドとアウトバウンドのクライアント要求を変更しないで渡します。このコンフィグレーションでは、各 ATMI アプリケーションに 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"

関連項目

資格ポリシーの設定

管理者は、次のコンフィグレーション パラメータを使用して、Oracle Tuxedo リリース 8.0 以上を実行する ATMI アプリケーション間で、資格ポリシーの設定と制御を行います。

認可の管理

認可とは、ATMI アプリケーション内のリソースまたは機能に対するユーザ アクセスを、アプリケーション固有の規則に従って制限することです。認可は、ユーザが ATMI アプリケーションへの参加を認証された場合にのみ実行されます。

認可の管理手順は、基底の ATMI アプリケーションの認可システムによって異なります。カスタマイズした認可システムを管理する手順については、該当するシステムのマニュアルを参照してください。デフォルトの認可システムを管理する手順については、「デフォルトの認証と認可の管理」を参照してください。

関連項目

リンク レベルの暗号化の管理

リンク レベルの暗号化は、ATMI アプリケーション内のマシン間をつなぐネットワーク リンク上で送受信されるメッセージの秘密性を保護します。リンク レベル暗号化 (LLE) セキュリティには、0 ビット (暗号化なし)、56 ビット (国際版)、および 128 ビット (米国およびカナダ版) の 3 つのレベルがあります。国際版の LLE では、0 ビットと 56 ビットの暗号化が可能です。米国およびカナダ版の LLE では、0 ビット、56 ビット、および 128 ビットの暗号化が可能です。

LLE は、Oracle Tuxedo の次の種類のリンクで使用できます。

LLE の min 値と max 値について

ATMI アプリケーションに LLE をコンフィグレーションする前に、LLE の表記法 (min, max) を知っておく必要があります。これらのパラメータのデフォルト値は次のとおりです。

たとえば、ライセンス ファイルに STRENGTH=128 と指定されている場合、LLE のデフォルトの min 値と max 値は (0, 128) です。デフォルト値を変更するには、アプリケーションの UBBCONFIG ファイルで min と max に新しい値を割り当てます。

詳細については、「LLE のしくみ」および「暗号化キー サイズの調整」を参照してください。

インストール済みの LLE バージョンの確認

マシンにインストールされた LLE バージョンを確認するには、冗長モードで tmadmin コマンドを実行します。

tmadmin -v

ローカルの Oracle Tuxedo lic.txt ファイルのキー行は、次のサンプルのようにコンピュータ画面に表示されます。サンプルの STRENGTH=128 というエントリは、インストールした Tuxedo に強力な暗号化がライセンス供与されていることを示します。

[Oracle Tuxedo] VERSION=10.0
[LINK ENCRYPTION] VERSION=10.0
STRENGTH=128
   .
   .
   .

Oracle Tuxedo のライセンスは、UNIX ホスト マシンの場合は $TUXDIR/udataobj/lic.txt ファイル、Windows 2003 ホスト マシンの場合は %TUXDIR%\udataobj\lic.txt ファイルにすべて格納されています。

ワークステーション クライアントのリンクに LLE をコンフィグレーションする方法

アプリケーションにワークステーション クライアントが組み込まれている場合、管理者は、1 つまたは複数のワークステーション リスナ (WSL) をコンフィグレーションして、ワークステーション クライアントからの接続要求をリスンする必要があります。各 WSL は、関連する 1 つまたは複数のワークステーション ハンドラ (WSH) を使用して、ワークステーション クライアントの負荷を管理します。各 WSH は、単一の接続を介して、特定のワークステーション クライアントで処理されるすべての要求と応答を多重化することにより、複数のワークステーション クライアントを管理できます。

管理者は、アプリケーションの UBBCONFIG ファイルの SERVERS セクションで WSL サーバを指定することにより、ワークステーション クライアントに対して ATMI アプリケーションへのアクセスを許可することができます。LLE の min および max パラメータのデフォルト値をオーバーライドするには、WSL サーバ用のコマンドライン オプションである -z および -Z を指定する必要があります (詳細については、「LLE の min 値と max 値について」を参照してください)。ただし、リンク レベルの暗号化は、ローカル マシンとワークステーション クライアントの両方に LLE がインストールされている場合にのみ使用できます。

ワークステーション クライアントのリンクに LLE をコンフィグレーションするには、次の手順に従います。

上の例では、tmboot(1) を実行すると ATMI アプリケーションが起動し、"-A -- -z min -Z max" というコマンドライン オプションが WSL サーバに渡されます。ワークステーション クライアントと WSH との間でネットワーク リンクを確立する場合、ワークステーション クライアントと WSL は、双方でサポートされるキーの最大サイズが一致するまでキー サイズの調整を行います。

詳細については、『Oracle Tuxedo のファイル形式とデータ記述方法』の「WSL(5)」、「WS_MIB(5)」、および「UBBCONFIG(5)」を参照してください。

ブリッジ間のリンクに LLE をコンフィグレーションする方法

Oracle Tuxedo システムのアーキテクチャでは、マルチ マシン アプリケーション (複数のマシンで構成されたアプリケーション) 内のマシン間に多重化したチャネルを確立して、ネットワーク通信を最適化します。Oracle Tuxedo のメッセージは、このチャネルを通じて双方向に流れます。メッセージ トラフィックは、ブリッジ サーバと呼ばれる専用の Oracle Tuxedo サーバによって管理されます。

管理者は、ブリッジ サーバが置かれた ATMI アプリケーション内の各マシンに対して、UBBCONFIG ファイルの NETWORK セクションにエントリを作成します。LLE の min および max パラメータのデフォルト値をオーバーライドする場合は、ブリッジ サーバのオプションのランタイム パラメータである MINENCRYPTBITS および MAXENCRYPTBITS を指定する必要があります (詳細については、「LLE の min 値と max 値について」を参照してください)。ただし、ブリッジ間のリンク レベルの暗号化は、ブリッジ サーバが置かれたマシンに LLE がインストールされている場合にのみ使用できます。

ブリッジ間のリンクに LLE をコンフィグレーションするには、次の手順に従います。

上の例では、tmboot(1) を実行すると、ATMI アプリケーションが起動し、ブリッジ サーバは、TUXCONFIG ファイルを読み込んで、MINENCRYPTBITS や MAXENCRYPTBITS などのさまざまなパラメータにアクセスします。リモートのブリッジ サーバとの間でネットワーク リンクを確立する場合、ローカルとリモートのブリッジ サーバは、双方でサポートされるキーの最大サイズが一致するまでキー サイズの調整を行います。

詳細については、『Oracle 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 パラメータに指定した値と同じにする必要があります。詳細については、『Tuxedo コマンド リファレンス』の「tlisten(1)」、および『Oracle Tuxedo のファイル形式とデータ記述方法』の「TM_MIB(5)」および「UBBCONFIG(5)」を参照してください。

ドメイン ゲートウェイのリンクに LLE をコンフィグレーションする方法

ドメイン ゲートウェイは GWTDOMAIN プロセスであり、複数の ATMI アプリケーション間でサービス要求とサービス応答を中継します。また、TCP/IP などのネットワーク トランスポート プロトコルを介して流れる、特別に設計されたトランザクション処理 (TP) プロトコルを使用して相互運用性を実現します。

ドメイン ゲートウェイはドメイン ゲートウェイ グループに属します。各ドメイン ゲートウェイ グループには、別個の Domains コンフィグレーション ファイルが必要です。ドメイン ゲートウェイ グループは、1 つまたは複数のリモート ドメイン アクセス ポイントと通信するローカル ドメイン アクセス ポイントです。アプリケーションのコンフィグレーション ファイルである UBBCONFIG および TUXCONFIG と同様に、Domains のコンフィグレーション ファイルもテキスト形式で作成され、バイナリ形式に変換されます。テキスト形式の場合は DMCONFIG ファイル、バイナリ形式の場合は BDMCONFIG ファイルと呼ばれます。DMCONFIG ファイルと BDMCONFIG ファイル、および関連する環境変数については、『Oracle Tuxedo のファイル形式とデータ記述方法』の「DMCONFIG(5)」を参照してください。

管理者は、以下の項目ごとに DMCONFIG ファイルの DM_TDOMAIN セクションにエントリを指定する必要があります。

LLE の min および max パラメータのデフォルト値をオーバーライドする場合は、ドメイン アクセス ポイントおよび TDomain セッションごとに、オプションのランタイム パラメータである MINENCRYPTBITS および MAXENCRYPTBITS を指定する必要があります (詳細については、「LLE の min 値と max 値について」を参照してください)。ただし、ドメイン間のリンク レベルの暗号化は、ドメインがあるマシンに LLE がインストールされている場合にのみ使用できます。

ドメイン ゲートウェイのリンクに LLE をコンフィグレーションするには、次の手順に従います。

上の例では、tmboot(1) を実行すると ATMI アプリケーションが起動します。各ドメイン ゲートウェイは BDMCONFIG ファイルを読み込んで MINENCRYPTBITS および MAXENCRYPTBITS などのさまざまなパラメータにアクセスし、ローカル ドメインおよびリモート ドメインにそれらのパラメータを伝播します。ローカル ドメインがリモート ドメインとのネットワーク リンクを確立するとき、これらの 2 つのドメインは、双方でサポートされるキーの最大サイズが一致するまでキー サイズの調整を行います。

詳細については、『Oracle Tuxedo のファイル形式とデータ記述方法』の「DMCONFIG(5)」を参照してください。また、『Oracle Tuxedo Domains コンポーネント』の「Domains コンフィグレーションのセキュリティの設定」も参照してください。

関連項目

SSL 暗号化の管理

SSL 暗号化は、ATMI アプリケーションにおいてマシン間で送受信されるメッセージのデータ機密性を保護します。SSL 暗号化には、業界標準の TLS 1.0 プロトコルが使用されています。128 ビット暗号化をライセンス供与されている場合は、256 ビット、128 ビット、56 ビット、および 0 ビットの SSL 暗号を使用できます。また、56 ビット暗号化をライセンス供与されている場合は、56 ビットおよび 0 ビットの SSL 暗号を使用できます。

SSL の min 値と max 値について

ATMI アプリケーションに SSL をコンフィグレーションする前に、SSL の表記法 (min, max) を知っておく必要があります。これらのパラメータのデフォルト値は次のとおりです。

たとえば、ライセンス ファイルに STRENGTH=128 と指定されている場合、SSL のデフォルトの min 値と max 値は (0, 256) です。256 ビット SSL 暗号化は、ライセンス ファイルに STRENGTH=128 と指定されている場合でも使用できます。ライセンス ファイルに STRENGTH=56 と指定されている場合、SSL と LLE の最大値は 56 になります。

デフォルト値を変更するには、アプリケーションの UBBCONFIG ファイルで min と max に新しい値を割り当てます。詳細については、「SSL プロトコルのしくみ」および「暗号化キー サイズの調整」を参照してください。

インストール済みの SSL バージョンの確認

マシンにインストールされている SSL のバージョンは、tmadmin -v コマンドを実行して確認できます。

tmadmin -v

ローカルの Oracle Tuxedo lic.txt ファイルのキー行は、次のサンプルのようにコンピュータ画面に表示されます。このサンプルの STRENGTH=256 というエントリは、ライセンス ファイルに STRENGTH=128 と指定されていることを示します。

INFO: Oracle Tuxedo, VERSION=10.0, 32-bit, Patch Level (none)
INFO: Serial #: 616351266349-2327268507960, Expiration 2007-11-13, Maxusers 1000
0
INFO: Acme Corporation
INFO: 128-bit Encryption Package
   .
   .
   .

Oracle Tuxedo のライセンスは、UNIX ホスト マシンの場合は $TUXDIR/udataobj/lic.txt ファイル、Windows 2003 ホスト マシンの場合は %TUXDIR%\udataobj\lic.txt ファイルにすべて格納されています。

ワークステーション クライアントのリンクに SSL をコンフィグレーションする方法

ワークステーション クライアントのリンクに SSL をコンフィグレーションするには、次の手順に従います。

ブリッジ間のリンクに SSL をコンフィグレーションする方法

ブリッジ間のリンクに SSL をコンフィグレーションするには、次の手順に従います。

tlisten のリンクに SSL をコンフィグレーションする方法

tlisten リンクに SSL をコンフィグレーションするには、「ブリッジ間のリンクに LLE をコンフィグレーションする方法」で説明した手順に従います。次のコマンドを入力する必要があります。

tlisten -l nlsaddr [-z min -Z max][-s][-c <sec_principal_location>][-n <sec_principal_name>][-p <sec_principal_passvar>]

ドメイン ゲートウェイのリンクに SSL をコンフィグレーションする方法

ドメイン ゲートウェイのリンクに SSL をコンフィグレーションするには、次の手順に従います。

SSL プロトコル用の開発プロセス

Tuxedo アプリケーションで SSL プロトコルを使用するための準備は、主に管理プロセスです。表 2-2 は、SSL プロトコルを使用できるようにインフラストラクチャを設定し、アプリケーション内のサーバおよびクライアントで SSL プロトコルが使用されるようにコンフィグレーションするための管理手順の一覧です。

管理手順の詳細については、『Tuxedo CORBA アプリケーションのセキュリティ機能』の「公開鍵によるセキュリティ機能の管理」および「SSL プロトコルのコンフィグレーション」を参照してください。

管理手順を実行したら、パスワードによる認証と証明書による認証のどちらも Tuxedo アプリケーションで使用できます。これらの手順は、CORBA アプリケーションの認証とよく似ています。詳細については、『Tuxedo CORBA アプリケーションのセキュリティ機能』の「セキュリティを実装する CORBA アプリケーション」を参照してください。

SSL プロトコルをパスワードによる認証で使用する場合、UBBCONFIG ファイルの SECURITY パラメータを目的の認証レベルに設定し、必要であれば、認証サーバ (AUTHSRV) をコンフィグレーションします。パスワード認証の管理手順の詳細については、『Oracle Tuxedo のセキュリティ機能』の「Password Authentication」を参照してください。

図 2-13 に、SSL プロトコルを使用する Tuxedo アプリケーションのコンフィグレーションを示します。

関連項目

公開鍵セキュリティの管理

分散型の 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 をコンフィグレーションするには、次の手順に従います。

上の例では、tmboot(1) を実行すると、ATMI アプリケーションが起動し、SIGNATURE_REQUIRED=Y パラメータが mach1 というマシンに渡されます。この時点で、mach1 によって宣言されたすべてのアプリケーション サービスは、ゲートウェイ プロセスによって宣言されたアプリケーション サービスも含め、有効なデジタル署名が添付されたメッセージだけを受け付けることができます。mach1 によって制御されるプロセスが、有効なデジタル署名が添付されていないメッセージを受信すると、システム側では次のアクションが実行されます。

イベント ブローカの署名ポリシーの適用

ポスト済みのメッセージ バッファにデジタル署名が添付されると、これらの署名は保存され、メッセージ バッファと共に、適切なイベントのサブスクライバに転送されます。

TMUSREVT(5) システム サーバが、デジタル署名を必要とするドメイン、マシン、またはサーバ グループで実行されている場合、このサーバは、コンポジット署名ステータスが TPSIGN_OK に設定されていないイベントを拒否します。詳細については、「コンポジット署名ステータスについて」を参照してください。

TMUSREVT サーバは、サービスの呼び出しやキューへのメッセージの登録などの、サブスクリプションに関する通知アクションを実行できます。有効なデジタル署名を必要とするサービスやキューに対して、有効なデジタル署名が添付されていないメッセージをポストすると、サブスクリプションの通知アクションは失敗します。

システム イベント (システム側でポストされ、TMSYSEVT サーバで処理されるイベント) には、デジタル署名を添付することができます。デジタル署名に関する管理ポリシーは、TMSYSEVT(5) サーバには適用されません。

/Q の署名ポリシーの適用

キューに登録されたバッファにデジタル署名が添付されると、署名はキュー内に保存され、キューから取り出すプロセスの実行時に転送されます。また、メッセージが TMQFORWARD(5) によって処理され、サービスが呼び出されると、署名は保存されます。

TMQUEUE(5) システム サーバが、デジタル署名を必要とするドメイン、マシン、またはサーバ グループで実行されている場合、このサーバは、コンポジット署名ステータスが TPSIGN_OK に設定されていないキュー要求を拒否します。詳細については、「コンポジット署名ステータスについて」を参照してください。さらに、キュー スペースに関連するサービス名に対してこのようなポリシーが有効な場合、TMQUEUE サーバはデジタル署名を必要とします。

リモート クライアントの署名ポリシーの適用

ワークステーション ハンドラ (WSH) が、デジタル署名を必要とするドメイン、マシン、またはサーバ グループで実行されている場合、WSH は、コンポジット署名ステータスが TPSIGN_OK に設定されていない、アプリケーション データを含むメッセージ バッファを拒否します。詳細については、「コンポジット署名ステータスについて」を参照してください。

暗号化ポリシーの設定

管理者は、次のコンフィグレーション パラメータを使用して、ATMI アプリケーションの暗号化ポリシーを設定します。

受信メッセージに対する暗号化ポリシーの適用

ENCRYPTION_REQUIRED は、コンフィグレーションの階層のうち、次の 4 つのレベルのどこでも指定できます。

特定のレベルで ENCRYPTION_REQUIRED に Y (はい) を設定すると、下位レベルで動作するすべてのプロセスに暗号化が必要となります。たとえば、mach1 というマシンで ENCRYPTION_REQUIRED に Y を設定すると、mach1 上で動作するすべてのプロセスは、暗号化されたメッセージだけを受け付けます。

ドメイン全体にわたるレベル、マシン レベル、グループ レベル、またはサービス レベルでは、ENCRYPTION_REQUIRED=Y および SIGNATURE_REQUIRED=Y を同時に指定することができます。SIGNATURE_REQUIRED の詳細については、「受信メッセージに対する署名ポリシーの適用」を参照してください。

制限

ENCRYPTION_REQUIRED を指定するかどうかのポリシーは、アプリケーション サービス、アプリケーション イベント、およびアプリケーション エンキュー要求に対してのみ適用されます。システム生成されたサービス呼び出しや、システム イベントのポストには適用されません。

使用例

STDGRP というサーバ グループに ENCRYPTION_REQUIRED をコンフィグレーションするには、次の手順に従います。

上の例では、tmboot(1) を実行すると ATMI アプリケーションが起動し、ENCRYPTION_REQUIRED=Y パラメータが STDGRP というサーバ グループに渡されます。この時点で、STDGRP によって宣言されたすべてのアプリケーション サービスは、ゲートウェイ プロセスによって宣言されたアプリケーション サービスも含め、暗号化のエンベロープで保護されたメッセージだけを受け付けることができます。STDGRP によって制御されるプロセスが、暗号化されていないメッセージを受信すると、システム側では次のアクションが実行されます。

イベント ブローカの暗号化ポリシーの適用

ポスト済みのメッセージ バッファが暗号化されると、これらの署名は保存され、暗号化されたメッセージの内容と共に、適切なイベントのサブスクライバに転送されます。

TMUSREVT(5) システム サーバが、暗号化を必要とするドメイン、マシン、またはサーバ グループで実行されている場合、このサーバは、暗号化されていないメッセージを拒否します。

TMUSREVT サーバは、サービスの呼び出しやキューへのメッセージの登録などの、サブスクリプションに関する通知アクションを実行できます。入力する情報の暗号化を必要とするサービスやキューに対して、暗号化されていないメッセージをポストすると、サブスクリプションの通知アクションは失敗します。また、サブスクライバが適切な復号化キーを保持していない場合も、イベント通知アクションは失敗します。

システム イベント (システム側でポストされ、TMSYSEVT サーバで処理されるイベント) は、暗号化できます。暗号化に関する管理ポリシーは、TMSYSEVT(5) サーバには適用されません。

/Q の暗号化ポリシーの適用

キューに登録されたバッファが暗号化されると、このステータスはキュー内に保存され、バッファは、キューから取り出すプロセスの実行時に暗号化された形式で転送されます。また、メッセージが TMQFORWARD(5) によって処理され、サービスが呼び出されると、暗号化のステータスは保存されます。

TMQUEUE(5) システム サーバが、暗号化を必要とするドメイン、マシン、またはサーバ グループで実行されている場合、このサーバは、暗号化されていないキュー要求を拒否します。さらに、キュー スペースに関連するサービス名に対してこのようなポリシーが有効な場合、TMQUEUE サーバは、暗号化を必要とします。

リモート クライアントの暗号化ポリシーの適用

ワークステーション ハンドラ (WSH) が、暗号化を必要とするドメイン、マシン、またはサーバ グループで実行されている場合、WSH は、暗号化されていないアプリケーション データ バッファを含むメッセージ バッファを拒否します。

プラグインによる復号化キーの初期化

管理者は、次のコンフィグレーション パラメータを使用して、アプリケーション内で動作するシステム プロセスのプリンシパル名と復号化キーを指定します。

上記の 3 つのパラメータは、コンフィグレーションの階層のうち、次の 4 つのレベルのどこでも指定できます。

特定のコンフィグレーション レベルでのプリンシパル名および復号化キーは、下位レベルでオーバーライドできます。たとえば、mach1 というマシンにプリンシパル名と復号化キーを設定し、mach1 上で動作する serv1 というサーバにプリンシパル名と復号化キーをコンフィグレーションしたとします。この場合、mach1 のプロセスは次のように動作します。

ATMI アプリケーションが起動すると、コンフィグレーションされた復号化キーは自動的にオープンします。次の図は、このプロセスのしくみを示しています。

次に、この図に示した操作の実行方法を詳しく説明します。

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 の設定に基づいて暗号化された入力を必要とするプロセスが、暗号化されていないメッセージを受信した場合、システムは次のアクションを実行します。

関連項目

デフォルトの認証と認可の管理

デフォルトの認証および認可は、Oracle Tuxedo システムで最初に実現された、Oracle Tuxedo の従来の認証および認可と同じように機能します。

デフォルトの認証には、認証なし (NONE)、アプリケーション パスワード (APP_PW)、ユーザ レベルの認証を実行 (USER_AUTH)、という 3 つのセキュリティ レベルが用意されています。デフォルトの認可には、オプションのアクセス制御リスト (ACL) および必須のアクセス制御リスト (MANDATORY_ACL) という 2 つのセキュリティ レベルがあります。アクセス制御リストは、ユーザが ATMI アプリケーションへの参加を認証された場合にのみ有効になります。

セキュリティ レベルの指定

管理者は、UBBCONFIG コンフィグレーション ファイルを編集するか、TM_MIB を変更するか、または Oracle 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) を実行します。

Oracle Administration Console を使用してセキュリティを指定する

Oracle Administration Console を使用してセキュリティ レベルを指定することもできます。Oracle Administration Console は、ATMI アプリケーションをコンフィグレーションし、モニタし、動的に再コンフィグレーションするための Web ベースのツールです。

認証サーバのコンフィグレーション

Oracle Tuxedo サーバである AUTHSVR は、認証を実行する 1 つのサービス (AUTHSVC) を備えています。セキュリティ レベルが ACL または MANDATORY_ACL に設定されている場合、AUTHSVR サーバは、AUTHSVC を ..AUTHSVC として宣言します。

AUTHSVC をアプリケーションに追加するには、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"

関連項目

アプリケーション パスワードによるセキュリティを有効にする方法

デフォルトの認証には、「アプリケーション パスワード」というセキュリティ レベルが用意されており、これは、コンフィグレーション ファイルの SECURITY APP_PW で指定すると有効になります。このセキュリティ レベルでは、ATMI アプリケーションに参加するすべてのクライアントに対してアプリケーション パスワードの入力が求められます。管理者は、ATMI アプリケーション全体に対して 1 つのパスワードを定義し、認可されたユーザだけにパスワードを通知します。

APP_PW のセキュリティ レベルを有効にするには、次の手順に従います。

関連項目

ユーザ レベルの認証によるセキュリティを有効にする方法

デフォルトの認証には、「ユーザ レベルの認証」というセキュリティ レベルが用意されており、これは、コンフィグレーション ファイルの SECURITY USER_AUTH で指定すると有効になります。このセキュリティ レベルでは、ATMI アプリケーションに参加するため、各クライアントは、アプリケーション パスワードのほか、有効なユーザ名とユーザ固有のデータ (パスワードなど) を提示しなければなりません。ユーザごとのパスワードは、tpusr ファイルに格納されている、ユーザ名とクライアント名の組み合わせに関連付けられたパスワードに一致しなければなりません。ユーザごとのパスワードと、tpusr 内のユーザ名/クライアント名およびパスワードとの照合は、認証サーバ AUTHSVR の認証サービス AUTHSVC によって実行されます。

USER_AUTH のセキュリティ レベルを有効にするには、次の手順に従います。

これらの手順については、次の 2 つの節で説明します。

UBBCONFIG ファイルの設定

ユーザ ファイルとグループ ファイルの設定

デフォルトの認可システムで使用できる 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 変数で定義した最初のパス名によって参照されるディレクトリにあります。これらのファイルは、コロンで区切られたフラットなテキスト ファイルであり、アプリケーション管理者だけが読み書きを行う権限を持ちます。

システムのセキュリティ データ ファイルを Oracle Tuxedo のユーザ ファイルとグループ ファイルに変換する

ホスト システムには、ユーザとグループのリストを格納したファイルが既に存在する場合があります。これらのファイルを ATMI アプリケーションのユーザ ファイルおよびグループ ファイルとして使用するには、Oracle Tuxedo システムで受け付けられる形式に変換する必要があります。ファイルを変換するには、次の手順例に示すように、tpaclcvt(1) コマンドを実行します。この手順例は、UNIX ホスト マシン用に記述されています。

ユーザおよびグループを追加、変更、または削除する

Oracle 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 つのグループしか追加できないため、同時に複数のグループ エントリを追加する場合は、この方法の方がコマンドライン インタフェースより効率的です。

Oracle Administration Console を使用すると、最も簡単に MIB にアクセスできます。

関連項目

アクセス制御リストによるセキュリティの有効化

デフォルトの認可には、サービスを実行し、イベントをポストし、アプリケーション キューのメッセージをキューに登録 (または登録解除) するユーザを決定するアクセス制御リストの機能が備わっています。アクセス制御によるセキュリティには、オプションのアクセス制御リスト (ACL) と必須のアクセス制御リスト (MANDATORY_ACL) の 2 つのレベルがあります。アクセス制御リストは、ユーザが ATMI アプリケーションへの参加を認証された場合にのみ有効になります。

アクセス制御リストを使用すると、管理者はユーザを複数のグループにまとめ、それらのグループに対して、メンバー ユーザがアクセス権を持つオブジェクトを関連付けることができます。アクセス制御は、次の理由により、グループ レベルで行われます。

アクセス制御のチェック機能は、アプリケーション管理者によって作成および管理される 3 つのファイルに基づいています。

クライアントのアプリケーション キー (クライアントを有効なユーザおよび有効なグループ メンバーとして識別する情報を含む) を解析することによって、エンティティ (サービス、イベント、またはアプリケーション キューなど) は、ユーザが属するグループを識別できます。tpacl ファイルをチェックすることによって、エンティティは、クライアントのグループにアクセス パーミッションが付与されているかどうかを判定できます。

アプリケーション管理者、アプリケーション オペレータ、およびアプリケーション管理者またはオペレータの特権で実行中のプロセスやサービス要求は、ACL によるパーミッションのチェックの対象にはなりません。

ユーザ レベルの ACL エントリが必要な場合は、各ユーザのグループを作成し、そのグループを tpacl ファイルの該当するアプリケーション エンティティにマッピングします。

省略可能な ACL セキュリティを有効にする方法

デフォルトの認証には、「オプションのアクセス制御リスト (ACL)」というセキュリティ レベルが用意されており、これは、コンフィグレーション ファイルの SECURITY ACL で指定すると有効になります。このセキュリティ レベルでは、各クライアントは、ATMI アプリケーションに参加するため、アプリケーション パスワード、ユーザ名、およびユーザ固有のデータ (パスワードなど) を提示しなければなりません。対象アプリケーションのエンティティに関連するエントリが tpacl ファイルになくても、ユーザはそのエンティティにアクセスできます。

管理者は、このセキュリティ レベルを使用して、セキュリティを強化したいリソースに対してのみアクセス権をコンフィグレーションできます。つまり、すべてのユーザにアクセスを許可するサービス、イベント、およびアプリケーション キューについて、tpacl ファイルにエントリを追加する必要はありません。ただし、tpacl ファイルに対象アプリケーションのエンティティに関連するエントリがあり、ユーザがこれにアクセスしようとする場合、そのユーザは、そのエンティティへのアクセスを許可されたグループのメンバーでなければなりません。そうでない場合、アクセスは拒否されます。

ACL のセキュリティ レベルを有効にするには、次の手順に従います。

これらの手順については、次の 2 つの節で説明します。

UBBCONFIG ファイルの設定

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 エントリを追加する場合は、この方法の方がコマンドライン インタフェースより効率的です。

Oracle Administration Console を使用すると、最も簡単に MIB にアクセスできます。

必須の ACL セキュリティを有効にする方法

デフォルトの認証には、「必須のアクセス制御リスト」というセキュリティ レベルが用意されており、これは、コンフィグレーション ファイルの SECURITY MANDATORY_ACL で指定すると有効になります。このセキュリティ レベルでは、各クライアントは、ATMI アプリケーションに参加するため、アプリケーション パスワード、ユーザ名、およびユーザ固有のデータ (パスワードなど) を提示しなければなりません。対象アプリケーションのエンティティに関連するエントリが tpacl ファイルにない場合、クライアントはそのエンティティにアクセスできません。つまり、アクセスする必要のあるアプリケーション エンティティのエントリが tpacl ファイルに存在していなければなりません。したがって、このレベルは「必須」と呼ばれます。

ただし、tpacl ファイルに対象アプリケーションのエンティティに関連するエントリがあり、ユーザがこれにアクセスしようとする場合、そのユーザは、そのエンティティへのアクセスを許可されたグループのメンバーでなければなりません。そうでない場合、アクセスは拒否されます。

MANDATORY_ACL のセキュリティ レベルを有効にするには、次の手順に従います。

これらの手順については、次の 2 つの節で説明します。

UBBCONFIG ファイルの設定

ACL ファイルの設定

「ACL ファイルの設定」を参照してください。

関連項目

Kerberos 認証プラグインの使用

Kerberos は、ネットワーク認証プロトコルです。このプロトコルは、シークレット キー暗号を用いて、クライアント/サーバ アプリケーション用に強力な認証機能を実現するために設計されました。Kerberos 認証プロトコルでは、ネットワーク接続を開始する前に、クライアントとサーバ、または 2 つのサーバの間の相互認証メカニズムを利用できます。このプロトコルでは、ほとんどのコンピュータが物理的に安全ではない開かれたネットワーク上で、クライアントとサーバの間の初期トランザクションが発生すること、およびネットワーク上を行き来するパケットを任意にモニタおよび変更できることを前提にしています。

Kerberos を使用してクライアントとサーバの ID を承認したら、その通信を暗号化してプライバシーとデータの整合性を確保できるようになります。Kerberos の詳細については、「関連項目」を参照してください。

以降の節では、Tuxedo に付属の Kerberos 認証プラグイン機能について説明します。

Kerberos プラグイン

Tuxedo では、カスタマイズ可能な一般的なセキュリティ フレームワークを利用できます。このフレームワークに Kerberos プラグインを組み込むと、セキュリティを強化できます。

Kerberos がサポートされるプラットフォーム

現在、Kerberos プラグインは以下のプラットフォームで使用できます。

Kerberos プラグインの機能

Kerberos プラグインは、Tuxedo システムと Kerberos 認証サーバ (KAUTHSVR(5)) に登録する必要がある動的ライブラリです。Kerberos プラグインの Tuxedo 実装は以下をサポートしています。

Kerberos プラグインの事前コンフィグレーション

Kerberos 認証を使用するには、以下のシステム要件が正しく設定されていることを確認する必要があります。

Kerberos プラグインのコンフィグレーション

ここでは、Kerberos プラグインの設定と実行に必要なコンフィグレーション情報について説明します。

これらの各手順については、それぞれに続くサブセクションでそれぞれ詳しく説明します。

Kerberos プラグインのコンフィグレーション

最初に Kerberos プラグインを UNIX および Windows プラットフォームに登録する必要があります。

Kerberos プラグインのコンフィグレーションには、EPIF コマンド epifreg および epifregedt を使用します。この 2 つのコマンドによって、プラグインは、UNIX と Windows の Tuxedo レジストリに自動的に追加されます。次に例を示します。

epifreg -r -p krb5/atn -i engine/security/authentication -o SYSTEM -v 1.0 \
-f $TUXDIR/lib/libkrb5atn.so \
	-e krb5_plugin_entry \
	-u KRB5_CONFIG=/etc/krb5.conf \
	-u KRB5_KDC=/etc/krb5.kdc\
	-u KAUTHSVRPRINC="krbauth@host.yourcomany.com"
epifregedt -s -k SYSTEM/interfaces/engine/security/authentication \
	-a Selector=native/security/authentication \
	-a native/security/authentication=krb5/atn

epifreg -r -p krb5/atn -i engine/security/authentication -o SYSTEM -v 1.0 \
	-f %TUXDIR%\bin\libkrb5atn.dll \
	-e krb5_plugin_entry \
	-u KAUTHSVRPRINC="krbauth/host.yourcomany.com@REALM"
epifregedt -s -k SYSTEM/interfaces/engine/security/authentication \
	-a Selector=native/security/authentication \
	-a native/security/authentication=krb5/atn

デフォルト プラグインを回復する

以下のコマンドでは、プラグインをデフォルトの状態に戻します。

epifreg -r -p bea/native/atn \
	-i engine/security/authentication \
	-v 1.0 -f libtux.so -e _ep_dl_atnlcl
epifregedt -s -k SYSTEM/interfaces/engine/security/authentication \

		-a Selector=native/security/authentication \

		-a native/security/authentication=bea/native/atn

KAUTHSVR のコンフィグレーション

KAUTHSVR は、TUXDIR/bin ディレクトリにある Tuxedo サーバです、この値は、UBBCONFIG ファイルで手動でコンフィグレーションする必要があります。KAUTHSVR は、クライアント セキュリティ トークンを検証してクライアント ID を認証します。UBBCONFIG ファイルでセキュリティ レベルが "USER_AUTH" 以上に設定されている場合は、Tuxedo ACL メカニズムに対処します。

次に、UBBCONFIG ファイルによる KAUTHSVR のコンフィグレーションについて、UNIX と Windows 双方の例を示します。

*RESOURCES
IPCKEY                  66666
MASTER                  SITE1
MODEL                   MP

SECURITY       MANDATORY_ACL

*SERVERS

KAUTHSVR SRVGRP=SECGRP SRVID=100 GRACE=0 MAXGEN=2 CLOPT="-A -- -k /etc/krbauth.kt -p krbauth@host.yourcomany.com"

*RESOURCES
IPCKEY                  66666
MASTER                  SITE1
MODEL                   MP

SECURITY       MANDATORY_ACL

*SERVERS

KAUTHSVR SRVGRP=GROUP3 SRVID=100 GRACE=0 MAXGEN=2
SEC_PRINCIPAL_NAME="kauthsvc" SEC_PRINCIPAL_PASSVAR=test CLOPT="-A -- -p
krbauth/host.yourcomany.com@REALM"

Tuxedo ネイティブ クライアントのコンフィグレーション

Kerberos を有効にした Tuxedo ネイティブ クライアントを使用するには、kinit またはそれに類似したコマンドを使用して、最初に KDC から有効な TGT を取得する必要があります。

プログラミング API は必要ありません。また、USER_AUTH を指定している場合は、tpusr ファイルで Tuxedo ユーザ名を指定する必要もありません。ただし、ACL および MANDATORY_ACL のセキュリティ レベルでは、ユーザ名が必要です。

制限事項

関連項目

Cert-C PKI 暗号化プラグインの使用

Cert-C ベースの PKI (Public Key Infrastructure) プラグインは、公開鍵暗号化アルゴリズムを使用して以下の機能を実現します。

以降の節では、Tuxedo に付属の Cert-C PKI 暗号化機能について説明します。

Cert-C PKI 暗号化プラグイン

Tuxedo Cert-C PKI 暗号化プラグインは、外部からアクセス可能なユーザ証明書のストレージ メカニズムとして LDAP バージョン 2 以降を使用します。LDAP は、ネットワーク ディレクトリ サービスでは広く使われているメカニズムです。

Cert-C PKI 暗号化プラグインの事前コンフィグレーション

Tuxedo Cert-C PKI 暗号化プラグインを使用するには、以下のシステム要件を確認してください。

Cert-C PKI 暗号化プラグインのコンフィグレーション

このプラグインを使用するには、デフォルト PKI プラグインとしてこのプラグインを使用するように Tuxedo をコンフィグレーションするコマンド スクリプトを実行する必要があります。

Tuxedo Cert-C プラグインは、Tuxedo Security PIF の 4 つのインタフェース グループを使用し、PIF レジストリ コマンドでコンフィグレーションされます。以下のインタフェース グループが必要です。

Tuxedo 環境では、プラグインの実行時にユーザ名のみが使用可能です。適切な検索情報を取得するために、LDAP に格納されている証明書 (cn=user name を入力済み) が Tuxedo ユーザ名であることが前提となっています。

証明書ルックアップのコンフィグレーション

このインタフェース グループは、ユーザ証明書が LDAP サーバにあるものと見なし、ユーザ証明書を読み取るためのアクセス権を持っています。証明書ルックアップ インタフェースには、コンフィグレーションが必要なパラメータが 4 つあります。次に、各パラメータについて説明します。

ldapUserCertificate

ldapBaseObject

ldapFilterAttribute

ldapBaseDNAttribute

X.509 証明書ルックアップに対応する OpenLDAP

OpenLDAP を X.509 証明書ルックアップに対応させるには、コード リスト 2-6 のコマンドを実行して、Tuxedo PKI プラグイン情報を変更します。

epifreg -r -p security/BEA/certificate_lookup -i engine/security/certificate_lookup -v 1.0 -f 'libplugin.<suffix>' -e _ep_dl_certlookup -u userCertificateLdap=ldap:/<ldap_host_name>:<ldap_port>/ -u ldapBaseObject='<your_ldap_base>' -u binaryCertificate='YES'.

各項目の説明は次のとおりです。

コード リスト 2-7 に、フィルタの例を示します。

'BEA_person_lookup'

   '.*'        ' '   '(|(objectClass=inetOrgPerson)(cn=%v))'       'username'

               '(|(objectClass=inetOrgPerson) (cn=%v*))'    'start of 
	username'

'BEA_issuer_lookup'
	'.*'                  ' '

'(&(objectClass=certificationAuthority)(cn=%v)(sn=%v))'     'exact match on 
sn, cn'

鍵管理のコンフィグレーション

プライベート キーの場所は、キー管理インタフェース用に指定する必要があるコンフィグレーション パラメータでのみ指定します。

decPassword

オプション パラメータ。暗号化されたプライベート キー情報の形式でラップされたプライベート キーを復号化するためのパスワードを Cert-C PKI 暗号化プラグインに提供する文字列変数です。次に例を示します。

decPassword="abc123"

プラグインでは、プライベート キー情報ファイルが "<subject_name>.epk" ネーミング方式に従っていることを前提にします。

privateKeyDir

ファイル URL 形式の文字列変数パラメータ。プライベート キー ファイルのデフォルトの場所を示します。次に例を示します。

privateKeyDir=file:///c:\home\certs\

この例では、c:\home\certs ディレクトリにあるプライベート キーを探すように Cert-C PKI 暗号化プラグインに通知します。プライベート キーは、PKCS #8 に準拠したバイナリ ファイルでも構いません。その場合、拡張子は .pvt または .epk にする必要があります。

パスワードが "decPassword" パスまたは tpkey_open(..., identity_proof, ...) で指定されている場合は、.epk ファイルが先に検索され、見つからなかった場合に .pvt ファイルが検索対象になります。パスワードが "decPassword" パスまたは tpkey_open(..., identity_proof, ...) で指定されていない場合は、.pvt ファイルのみが検索対象になります。

証明書解析のコンフィグレーション

証明書解析インタフェースを使用する際に、特別なコンフィグレーション パラメータは必要ありません。自動的に初期化されます。

証明書検証のコンフィグレーション

証明書解析インタフェース グループを使用すると、Cert-C PKI 暗号化プラグインは、信頼性のある認証局、信頼性のチェーン、証明書取り消しリストを基に証明書を検証し、その有効性を判定できます。証明書の検証に関連付けられているコンフィグレーション パラメータには、以下の 2 つがあります。

caCertificateFile

ファイル URL 形式の文字列変数コンフィグレーション パラメータ。公開キーがユーザによって信頼されている単一の証明書を示します。証明書は自己署名形式でも構いません。証明書チェーンが、信頼性のあるこの証明書を検証すると、証明書は「適切」と見なされます。次に例を示します。

caCertificateFile=file:///c:\home\certs\root.cer

この例では、信頼性のあるルート証明書は c:\home\certs というディレクトリにある root.cer という名前のものです。

crlFile

ファイル URL 形式の文字列変数コンフィグレーション パラメータ。生成された証明書パスの検証に使用する単一の CRL を示します。つまり、対象の証明書が発行者によって呼び出されたものかどうかが判定されます。次に例を示します。

crlFile=file:///c:\home\certs\revoke.crl

この例では、証明書が発行者によって呼び出されていない場合、どの CRL が判定に使用されるかを示します。

レジストリ コマンド ファイルの例

次に、Windows プラットフォームで Cert-C PKI 暗号化プラグインを使用して Tuxedo レジストリ データベースを変更するサンプル コマンドを示します。

REM **********************************************************
REM ** 検証インタフェースの変更 **
REM **********************************************************
epifreg -r -p bea/cert-c/certificate_validation -i engine/security/certificate_validation -v 1.0 -f certctux.dll -e _ep_dl_certc_validate_certificate -u caCertificateFile=file:///c:\home\certs\root.cer -u crlFile=file:///c:\home\certs\revoke.crl

epifreg -s -k SYSTEM/impl/bea/valfile -a InterceptionSeq=bea/cert-c/certification_validation

epifregedt -s -k SYSTEM/interfaces/engine/security/certificate_validation -a DefaultImpl=bea/valfile

REM **********************************************************
REM ** ルックアップ インタフェースの変更 **
REM **********************************************************

epifreg -r -p bea/cert-c/certificate_lookup -i engine/security/certificate_lookup -v 1.0 -f certctux.dll -e _ep_dl_certc_certificate_lookup -u ldapUserCertificate=ldap://sagamore:389 -u ldapBaseObject="ou=Engineer Test,o=ABC Company,c=US" -u ldapFilterAttribute="cn" -u ldapBaseDNAttribue="c,o,ou,cn"

epifregedt -s -k SYSTEM/interfaces/engine/security/certificate_lookup -a DefaultImpl=bea/cert-c/certificate_lookup

REM **********************************************************
REM ** キー管理インタフェースの変更 **
REM **********************************************************

epifreg -r -p bea/cert-c/key_management -i engine/security/key_management -v 1.0 -f certctux.dll -e _ep_dl_certc_key_management -u privateKeyDir=file:///c:\home\certs\

epifregedt -s -k SYSTEM/interfaces/engine/security/key_management -a DefaultImpl=bea/cert-c/key_management

REM **********************************************************
REM ** 証明書解析インタフェースの変更 **
REM **********************************************************

epifreg -r -p bea/cert-c/certificate_parsing -i engine/security/certificate_parsing -v 1.0 -f certctux.dll -e _ep_dl_certc_certificate_parsing

epifregedt -s -k SYSTEM/interfaces/engine/security/certificate_parsing -a DefaultImpl=bea/cert-c/certificate_parsing

制限事項

関連項目

tpkey_open(3c)