|
|
次の項では、Oracle Tuxedo ATMIアプリケーションのセキュリティ・ポリシーを設定する方法について説明します。
ATMIアプリケーションのセキュリティ管理とは、クライアント、サーバー・マシン、ゲートウェイ・リンクなどのアプリケーションのコンポーネントに対して、セキュリティ・ポリシーを設定し、適用することです。ATMIアプリケーションに対するセキュリティ・ポリシーはアプリケーション管理者が設定し、これらのポリシーは、ATMIアプリケーションの基盤となるOracle Tuxedoシステムによって実行されます。
Oracle Tuxedoシステムには、次のATMI用のセキュリティ機能が用意されています。
アプリケーション管理者はセキュリティ機能を構成できます(ただし、例外が1つあります)。その例外は監査で、図2-1に示すように監査は構成できません。
1つ以上のセキュリティ機能をカスタマイズしてATMIアプリケーションに構成する場合、アプリケーション管理者はOracle Tuxedoレジストリについて知っておく必要があります。一方、デフォルトのセキュリティ機能だけをATMIアプリケーションに構成する場合は、Oracle Tuxedoレジストリを変更する必要はありません。
Oracle Tuxedoレジストリは、プラグイン・モジュールに関連する情報を格納しておくディスク・ベースのリポジトリです。このレジストリには、デフォルトのセキュリティ・プラグインに関する登録情報が最初に格納されています。
Oracleのほとんどのミドルウェア製品では、セキュリティなどのコア・サービスのセットで構成される、共通のトランザクション処理のインフラストラクチャ(TPインフラストラクチャ)が使用されています。ATMIアプリケーションでは、適切に定義されたインタフェースを介してTPインフラストラクチャを使用できます。これらのインタフェースを使って独自のサービス・コード・モジュールであるプラグイン・モジュール(プラグイン)をロードし、リンクすることにより、アプリケーション管理者は、TPインフラストラクチャのデフォルトの動作を変更できます。
プラグインをロードする最初の手順として、プラグインをホスト・オペレーティング・システムに登録します。プラグインを登録すると、プラグインのエントリがOracle Tuxedoレジストリに追加されます。Oracle Tuxedoレジストリは、アクティブなプラグインの情報を格納するバイナリ・ファイルのセットです。レジストリは、Oracle Tuxedoシステムごとに用意されています。
ATMIアプリケーション内のすべてのワークステーション・クライアントとサーバー・マシンは、同じプラグイン・モジュールのセットを使用する必要があります。
カスタマイズしたプラグインを使用する場合、ATMIアプリケーションの管理者はこれらのプラグインを登録し、その他のレジストリ関連のタスクを実行する責任があります。Oracle Tuxedoレジストリへのプラグインの登録は、ローカル・マシンからのみ可能です。つまり、管理者は、リモートからホスト・マシンにログオンしている間はプラグインを登録できません。
これらのコマンドの使い方については、『Developing Security Services for ATMI and CORBA Environments』を参照してください (このドキュメントは、セキュリティ・プラグイン・インタフェース用の仕様を含んでおり、セキュリティ・プラグインのモジュールを動的にロードしてリンクすることを可能にするプラグイン・フレームワーク機能について説明しています。)また、カスタマイズしたプラグインをインストールする場合、プラグインの提供元であるサード・パーティ・ベンダーは、これらのコマンドの使用方法を明記して、カスタマイズしたプラグインにアクセスするためのOracle Tuxedoレジストリの設定方法を示す必要があります。
セキュリティ・プラグインの詳細(インストール手順および構成手順を含む)については、オラクル社の営業担当者にお問い合せください。
アプリケーションが非アクティブの場合、アプリケーション管理者はMASTERマシンでATMIアプリケーションのセキュリティを構成します。アプリケーションが起動すると、基底のOracle Tuxedoシステムにより、ATMIアプリケーション内のほかのマシンに構成情報が伝播されます。
管理者は、次のいずれかの方法でATMIアプリケーションのセキュリティを構成できます。
セキュリティの種類(認証、認可、リンク・レベルの暗号化、または公開鍵)およびセキュリティ・ソフトウェアの種類(デフォルト版またはカスタマイズ版)に応じて、設定するセキュリティ・パラメータは異なります。
UBBCONFIG構成ファイルを編集して、ATMIアプリケーションのセキュリティ・ポリシーを設定することができます。UBBCONFIG構成ファイルにはどのような名前を付けることもできますが、ファイルの内容は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のUBBCONFIG(5)のリファレンス・ページで指定された形式に準拠する必要があります。
UBBCONFIGファイルおよびTUXCONFIGファイル(バイナリ形式の構成ファイル)の詳細は、『Oracle Tuxedoアプリケーションの設定』の「構成ファイルについて」および「構成ファイルの作成」を参照してください。
TM_MIBでクラスのセットを定義することにより、ATMIアプリケーションの基本的な側面を構成し、管理することができます。クラスは、マシン、サーバー、ネットワークなど、コンポーネントごとに指定されます。管理リクエストの形式および管理応答の解釈については、汎用的な管理情報ベース(MIB: Management Information Base)のリファレンス・ページであるMIB(5)とTM_MIB(5)リファレンス・ページを両方参照してください。MIBのリファレンス・ページは、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』で定義されています。
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およびシステム・プロセス・リファレンス』の「MIB(5)」を参照してください。『Oracle Tuxedo ATMIの紹介』も参照してください。
Oracle管理コンソールを使用してATMIアプリケーションのセキュリティ・ポリシーを変更することもできます。Oracle管理コンソールは、アプリケーションを構成し、モニターし、動的に再構成するためのWebベースのツールです。
Oracle管理コンソールの詳細は、『Oracle Tuxedo ATMIの紹介』を参照してください。
アプリケーション管理者は、アプリケーションの構成作業の一貫として、ATMIアプリケーション用の環境変数をいくつか定義します。環境変数に定義される値は、Oracle Tuxedoの実行可能ファイルおよびデータ・ライブラリを指す絶対パス名です。
ATMIアプリケーションを管理するには、これらのファイルにアクセスできなければなりません。たとえば、アプリケーションのセキュリティ管理に必要なコマンドは、すべて$TUXDIR/bin (UNIXホスト・マシンの場合)、または%TUXDIR%\bin (Windows 2003ホスト・マシンの場合)に格納されています。
管理環境の設定の詳細は、『Oracle Tuxedoアプリケーション実行時の管理』を参照してください。
アプリケーション管理者は、Oracle TuxedoシステムのATMI環境のセキュリティのほか、オペレーティング・システムに組み込まれているセキュリティ機能を十分に活用して、ファイル、ディレクトリ、およびシステム・リソースに対するアクセスを制御する必要があります。
ほとんどの場合、ATMIアプリケーションは、アプリケーション管理者によって管理されます。アプリケーション管理者は、アプリケーションを構成し、起動し、実行中のアプリケーションをモニターし、必要に応じて動的に変更します。ATMIアプリケーションは、管理者が起動し、実行するため、サーバー・プログラムは、管理者のパーミッションで実行されます。これで、サーバー・プログラムは安全であり、「信頼性がある」と見なされます。この方法は、基盤となるオペレーティング・システムのログイン・メカニズムとパーミッション設定(ファイル、ディレクトリ、およびシステム・リソースに対する読取り権と書込み権の設定)に基づいています。
一方、クライアントを起動するのは管理者ではありません。クライアントは、自分自身のパーミッションを持つユーザーによって直接実行されます。したがって、クライアントは信頼性があるとは言えません。
さらに、ネイティブ・クライアント(つまり、サーバーを実行中のマシンと同じマシンで実行中のクライアント)を実行するユーザーは、構成ファイルにアクセスしたり、共有メモリー内の掲示板などのプロセス間通信(IPC)のメカニズムにアクセスできます。ATMIのセキュリティが追加されても、ネイティブ・クライアントを実行するクライアントは、常にこのようなアクセスを実現できます。
管理者は、次の一般的な方法に従うことにより、オペレーティング・システムのセキュリティ・レベルを高めることができます。
setuidユーティリティを使用して、信頼性のあるクライアント・プログラムを必ず管理者のパーミッションで実行します。
認証とは、通信するプロセスどうしがお互いのIDを証明し合うことです。この機能は、これ以外のほぼすべてのセキュリティ機能の基盤となります。
この項で示す手順以外の認証の管理手順は、基底のアプリケーションの認証システムに依存します。カスタマイズした認証システムを管理する手順については、該当するシステムのドキュメントを参照してください。デフォルトの認証システムを管理する手順については、「デフォルトの認証と認可の管理」を参照してください。
次の図は、Oracle Tuxedoリリース7.1以上のソフトウェアで使用される、高信頼性委任型認証モデルをしています。高信頼性委任型認証モデルでは、ワークステーション・ハンドラ(WSH)およびドメイン・ゲートウェイ(GWTDOMAIN)は、「信頼性のあるシステム・ゲートウェイ・プロセス」と呼ばれます。これについては、「委任された信用認証の理解」を参照してください。
| 注意: | 相互認証は、ネイティブ・クライアントには適用されません。ネイティブ・クライアントを認証するのは、ネイティブ・クライアント自身です。 |
次は、前述の図の構成の設定に必要な操作の一覧です。すべての操作で、認証と認可のプラグインが必要になります。
管理者は、次の構成パラメータを使用して、Oracle Tuxedoリリース7.1以上のソフトウェアで作成したATMIアプリケーションで実行するワークステーション・ハンドラ(WSH)、ドメイン・ゲートウェイ(GWTDOMAIN)、およびサーバー・プロセスのプリンシパル名を指定します。
SEC_PRINCIPAL_NAMEは、構成の階層のうち、次の4つのレベルのどこでも指定できます。
特定の構成レベルでのセキュリティ・プリンシパル名は、下位レベルでオーバーライドできます。たとえば、mach1というマシンにterriというプリンシパル名を構成し、mach1上で動作するserv1というサーバーにjohnというプリンシパル名を構成したとします。この場合、mach1のプロセスは次のように動作します。
| 注意: | セキュリティ・プリンシパル情報は、ネットワーク・アプリケーション(MPモード)構成のすべてのマシンに指定する必要があります。起動エラーが発生する場合は、エラーの原因について、エラーが発生した接続の両側のULOGファイルを確認してください。 |
アプリケーションの起動時に、ATMIアプリケーション内のそれぞれのWSH、ドメイン・ゲートウェイ、およびサーバー・プロセスが認証プラグインを呼び出して(1)セキュリティ資格証明を取得し、(2)認可トークンおよび監査トークンを取得するとき、セキュリティ・プリンシパル名を引数として指定します。図2-3は、この手順を示しています。
アプリケーション内の各ドメイン・ゲートウェイ・プロセスは、認証プラグインをもう一度呼び出して、割り当てられた接続プリンシパル名の資格証明とトークンを取得します。
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のSEC_PRINCIPAL_NAMEパラメータを使用してセキュリティ・プリンシパル名を指定する方法を示しています。CONNECTION_PRINCIPAL_NAMEパラメータを使用して、DMCONFIGファイルの接続プリンシパル名を指定する例については、「リンクを確立するためのDMCONFIGのエントリ例」を参照してください。
*RESOURCESSEC_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と古いワークステーション・クライアントとの間の通信は実現できません。
| 注意: | 「代替ユーザー」関数は、認証プラグインを呼び出して、古いクライアントのIDを確認します。詳細は、「古いクライアントのIDの確認」を参照してください。 |
上の図では、WSHがリリース7.1より前の古い認証プロトコルを使用してワークステーション・クライアントを認証します。クライアント・リクエストは、認可トークンと監査トークンを受け取りません。ワークステーション・クライアントにWSINTOPPRE71環境変数が設定されていない場合、またはこの環境変数がNに設定されている場合、古いWSHと新しいワークステーション・クライアントとの間の通信は実現できません。
上の図では、アプリケーション1のローカル・ドメイン・ゲートウェイ(GWTDOMAIN)が、リリース7.1より前の古い認証プロトコルを使用して、アプリケーション2のリモート・ドメイン・ゲートウェイを認証しています。ローカル・ドメイン・ゲートウェイは、リモート・クライアントからのリクエストを受け取ると、内部の「代替ユーザー」関数を呼び出してリモート・クライアントの認可トークンと監査トークンを取得し、それらのトークンをクライアント・リクエストに添付します。アウトバウンドのクライアント・リクエスト(アプリケーション1からアプリケーション2に送信されるリクエスト)の場合、リクエストに添付されたトークンは、ローカル・ドメイン・ゲートウェイで取り除かれ、リクエストはアプリケーション・キーとともにアプリケーション2に送信されます。(アプリケーション・キーについては、「アプリケーション・キー」を参照してください)。
ドメイン・ゲートウェイに対してCLOPT -tオプションが指定されない場合、新しいATMIアプリケーションと古いATMIアプリケーションとの間の通信は実現できません。
上の図では、まずマシン1にある送信先のサーバーが内部の「代替ユーザー」関数を呼び出し、マシン2にあるリモート・クライアントの認可トークンと監査トークンを取得します。取得したトークンがクライアント・リクエストに添付されると、サーバーは、クライアントが認可チェックにパスしたと見なしてリクエストを実行します。サーバーに対してCLOPT -tオプションが指定されない場合、新しいサーバーと古いクライアントとの間の通信は実現できません。
| 注意: | また、上の図で、マシン1のWSHがマシン2のサーバー宛てのクライアント・リクエストを受け取ると、WSHはリクエストに添付されたトークンを取除いてから、そのリクエストをクライアントのアプリケーション・キーとともにマシン2のサーバーに送信します。同様に、マシン1のネイティブ・クライアントがマシン2のサーバーにリクエストを送信した場合、ネイティブ・クライアントは、リクエストに添付されたトークンを取除いてから、そのリクエストをクライアントのアプリケーション・キーとともにマシン2のサーバーに送信します。アプリケーション・キーについては、「アプリケーション・キー」を参照してください。 |
WSH、ドメイン・ゲートウェイ(GWTDOMAIN)、またはサーバー・プロセスは、内部の「代替ユーザー」関数を呼び出して、古いクライアントの認可トークンと監査トークンを取得することにより、古いクライアントのIDを確認します。次の図は、この手順を示しています。
CLOPT -tオプションが指定されている場合、WSHは、TPINITバッファのusrnameフィールドを使用するか(Cの場合)、またはTPINFDEF-RECレコードのUSRNAMEフィールドを使用して(COBOLの場合)古いクライアントのIDを確認します。「ATMIアプリケーションへの参加」で説明するとおり、クライアントがアプリケーションに参加しようとすると、WSHはクライアントからTPINITバッファまたはTPINFDEF-RECレコードを受け取ります。WSHは、「代替ユーザー」関数を呼び出すときにプリンシパル名としてユーザー名を使用します。
デフォルトの認証プラグインの場合、「代替ユーザー」関数は、ローカルのtpusrファイルからユーザー名および関連するアプリケーション・キー(ユーザー識別子とグループ識別子の組合せ)を検索し、古いクライアント用に作成された認可トークンと監査トークンに、ユーザー名とアプリケーション・キーを両方とも組み込みます。tpusrファイルについては、「ユーザー・ファイルとグループ・ファイルの設定」を参照してください。
CLOPT -tオプションが指定されている場合、ドメイン・ゲートウェイは、リモート・ドメイン・アクセス・ポイントに対して構成されたLOCAL_PRINCIPAL_NAME文字列を使用して、古いクライアントのIDを確認します。ドメイン・ゲートウェイは、ローカルのBDMCONFIGファイル(バイナリ形式のDMCONFIG(5)ファイル)のDM_REMOTEセクションで、リモート・ドメイン・アクセス・ポイントのLOCAL_PRINCIPAL_NAME文字列を検索します。このオプションを指定しない場合は、リモート・ドメイン・アクセス・ポイントのACCESSPOINTID文字列がデフォルト値になります。ドメイン・ゲートウェイは、「代替ユーザー」関数を呼び出すときにプリンシパル名としてLOCAL_PRINCIPAL_NAME文字列を使用します。
デフォルトの認証プラグインの場合、「代替ユーザー」関数は、ローカルのtpusrファイルからLOCAL_PRINCIPAL_NAME文字列および関連するアプリケーション・キーを検索し、古いクライアント用に作成された認可トークンと監査トークンに、その文字列(ID)とアプリケーション・キーを組み込みます。
CLOPT -tオプションが指定されている場合、サーバーは、クライアントに割り当てられたアプリケーション・キーを使用して、古いクライアントのIDを確認します。サーバーが受信したクライアント・リクエストには、クライアントに割り当てられたアプリケーション・キーが含まれています。サーバーは、ローカルのtpusrファイルからアプリケーション・キーと関連する名前を検索し、「代替ユーザー」関数を呼び出すときにプリンシパル名としてその名前を組み込みます。
デフォルトの認証プラグインの場合、「代替ユーザー」関数は、ローカルのtpusrファイルから名前および関連するアプリケーション・キーを検索し、古いクライアント用に作成された認可トークンと監査トークンに、名前とアプリケーション・キーを組み込みます。
次の表は、CLOPT -tオプションを使用して相互運用性を実現できる場合、または実現できない場合のWSH、ドメイン・ゲートウェイ、およびサーバー・プロセスの機能をまとめたものです。
ドメイン・ゲートウェイは、リリース7.1より前のリモート・ドメイン・ゲートウェイとの接続を確立すると、リリース7.1より前の認証プロトコルを使用してそのリモート・ドメイン・ゲートウェイを認証し、ネットワーク接続を確立します。
|
||
次の例は、ワークステーション・リスナー(WSL)によって制御されるすべてのWSHで相互運用性が実現できることを示しています。
*SERVERS
WSL SRVGRP="group_name" SRVID=server_number...
CLOPT="-A -t..."
ドメイン・ゲートウェイ(GWTDOMAIN)が別のドメイン・ゲートウェイとのネットワーク・リンクを確立しようとすると、次のようなイベントが発生します。
min-max値を交換します。これらの値は、ゲートウェイ間のリンクにSSLまたはLLEを設定するために使用されます。SSLを使用している場合は、イニシエータおよびターゲットのドメイン・ゲートウェイも、SSL証明書を使用して相互に認証し合います。LLEについては、「リンク・レベルの暗号化」を参照してください。SSLの詳細は、「SSL暗号化」を参照してください。
どちらかまたは両方のドメイン・ゲートウェイがOracle Tuxedoリリース7.1より前のソフトウェアを実行している場合、ゲートウェイ・プロセスでは、リリース7.1より前の古い認証プロトコルを使って接続が確立されます。
管理者は、次の構成パラメータを使用して、Oracle Tuxedoリリース7.1以上のソフトウェアを実行するドメイン・ゲートウェイ間にリンクを確立します。
このパラメータが
DMCONFIGファイルのDM_LOCALセクション*にある場合、リモート・ドメイン・アクセス・ポイントとの接続を設定する際のこのパラメータの値は、ローカル・ドメイン・アクセス・ポイントのプリンシパル名になります。
デフォルトの認証プラグインで、ローカル・ドメイン・アクセス・ポイントの
CONNECTION_PRINCIPAL_NAMEに値を割り当てる場合、その値は、ローカル・ドメイン・アクセス・ポイントのACCESSPOINTIDパラメータ*の値と同じでなければなりません。これらの値が一致しないと、ローカル・ドメイン・ゲートウェイ・プロセスが起動せず、次のuserlog(3c)メッセージが生成されます。ERROR:クレデンシャルを取得できません。
|
||
このパラメータが
DMCONFIGファイルのDM_REMOTEセクション*にあり、特定のリモート・ドメイン・アクセス・ポイントを示す場合、ローカル・ドメイン・アクセス・ポイントとの接続を設定する際のこのパラメータの値は、リモート・ドメイン・アクセス・ポイントのプリンシパル名になります。
デフォルトの認証プラグインで、リモート・ドメイン・アクセス・ポイントの
CONNECTION_PRINCIPAL_NAMEに値を割り当てる場合、その値は、リモート・ドメイン・アクセス・ポイントのACCESSPOINTIDパラメータ*の値と同じでなければなりません。これらの値が一致しないと、ローカル・ドメイン・ゲートウェイとリモート・ドメイン・ゲートウェイの接続は失敗し、次のuserlog(3c)メッセージが生成されます。ERROR:ドメイン
|
||
図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文字列と一致しなければなりません。
ドメイン・ゲートウェイがセキュリティ・チェックにパスすると、リンクが確立され、ゲートウェイは、確立されたリンクを介してサービス・リクエストを転送したり、応答を受信することができます。
次の例は、ローカル・ドメイン・アクセス・ポイント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"
管理者は、次の構成パラメータを使用して、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を持つユーザーです。
| 注意: | 以上の説明は、Oracle Tuxedoリリース7.1より前のソフトウェアを実行するATMIアプリケーションにも適用されます。ただし、システムでは、リモート・ドメイン・アクセス・ポイントに構成されたACCESSPOINTIDのIDが使用されます。基本的に、Oracle Tuxedoリリース6.5以前のソフトウェアでは、ローカルのACLポリシーはハードコーディングされています。 |
上の図では、各ドメイン・ゲートウェイ(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の確認」を参照してください。
次のサンプルでは、リモート・ドメイン・アクセス・ポイント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つのレベルがあります。
ATMIアプリケーションにLLEを構成する前に、LLEの表記法(min, max)を知っておく必要があります。これらのパラメータのデフォルト値は次のとおりです。
たとえば、ライセンス・ファイルにSTRENGTH=128と指定されている場合、LLEのデフォルトのmin値とmax値は(0, 128)です。デフォルト値を変更するには、アプリケーションのUBBCONFIGファイルでminとmaxに新しい値を割り当てます。
詳細は、「LLEのしくみ」および「暗号化キー・サイズのネゴシエーション」を参照してください。
アプリケーションにワークステーション・クライアントが組み込まれている場合、管理者は、1つまたは複数のワークステーション・リスナー(WSL)を構成して、ワークステーション・クライアントからの接続リクエストをリスニングする必要があります。各WSLは、関連する1つまたは複数のワークステーション・ハンドラ(WSH)を使用して、ワークステーション・クライアントの負荷を管理します。各WSHは、単一の接続を介して、特定のワークステーション・クライアントで処理されるすべてのリクエストと応答を多重化することにより、複数のワークステーション・クライアントを管理できます。
管理者は、アプリケーションのUBBCONFIGファイルのSERVERSセクションでWSLサーバーを指定することにより、ワークステーション・クライアントに対してATMIアプリケーションへのアクセスを許可することができます。LLEのminおよびmaxパラメータのデフォルト値をオーバーライドするには、WSLサーバー用のコマンドライン・オプションである-zおよび-Zを指定する必要があります。(詳細は、「LLEのmin値とmax値の理解」を参照してください)。ただし、リンク・レベルの暗号化は、ローカル・マシンとワークステーション・クライアントの両方にLLEがインストールされている場合にのみ使用できます。
| 注意: | ネットワーク接続の端にあるワークステーション・クライアントでは、TMMINENCRYPTBITSおよびTMMAXENCRYPTBITSの2つの環境変数を使用して、LLEのminおよびmaxパラメータのデフォルト値をオーバーライドできます。 |
ワークステーション・クライアントのリンクにLLEを構成するには、次の手順に従います。
MASTERマシンで作業しており、アプリケーションが非アクティブであることを確認します。UBBCONFIGを開き、SERVERSセクションに次の行を追加します。*SERVERS
WSL SRVGRP="group_name" SRVID=server_number...
CLOPT="-A -- -zmin-Zmax..."
tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。 上の例では、tmboot(1)を実行するとATMIアプリケーションが起動し、"-A -- -z min -Z max"というコマンドライン・オプションがWSLサーバーに渡されます。ワークステーション・クライアントとWSHとの間でネットワーク・リンクを確立する場合、ワークステーション・クライアントとWSLは、双方でサポートされるキーの最大サイズが一致するまでキー・サイズの調整を行います。
詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「WSL(5)」、「WS_MIB(5)」、および「UBBCONFIG(5)」を参照してください。
Oracle Tuxedoシステムのアーキテクチャでは、マルチ・マシン・アプリケーション(複数のマシンで構成されたアプリケーション)内のマシン間に多重化したチャネルを確立して、ネットワーク通信を最適化します。Oracle Tuxedoのメッセージは、このチャネルを通じて双方向に流れ、メッセージ・トラフィックは、ブリッジ・サーバーと呼ばれる専用のATMIサーバーによって管理されます。
管理者は、ブリッジ・サーバーが置かれたATMIアプリケーション内の各マシンに対して、UBBCONFIGファイルのNETWORKセクションにエントリを作成します。LLEのminおよびmaxパラメータのデフォルト値をオーバーライドする場合は、ブリッジ・サーバーのオプションのランタイム・パラメータであるMINENCRYPTBITSおよびMAXENCRYPTBITSを指定する必要があります(詳細は、「LLEのmin値とmax値の理解」を参照してください)。ただし、ブリッジ間のリンク・レベルの暗号化は、ブリッジ・サーバーが置かれたマシンにLLEがインストールされている場合にのみ使用できます。
ブリッジ間のリンクにLLEを構成するには、次の手順に従います。
MASTERマシンで作業しており、アプリケーションが非アクティブであることを確認します。UBBCONFIGを開き、NETWORKセクションに次の行を追加します。*NETWORK
LMID NADDR="bridge_network_address" BRIDGE="bridge_device"
NLSADDR="listen_network_address"
MINENCRYPTBITS=min
MAXENCRYPTBITS=max
LMIDは、ブリッジ・サーバーが置かれた論理マシンであり、BRIDGEパラメータで指定されたネットワーク・デバイスに直接アクセスできます。
tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。 上の例では、tmboot(1)を実行すると、ATMIアプリケーションが起動し、ブリッジ・サーバーは、TUXCONFIGファイルを読み込んで、MINENCRYPTBITSやMAXENCRYPTBITSなどの様々なパラメータにアクセスします。リモートのブリッジ・サーバーとの間でネットワーク・リンクを確立する場合、ローカルとリモートのブリッジ・サーバーは、双方でサポートされるキーの最大サイズが一致するまでキー・サイズの調整を行います。
詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「TM_MIB(5)」および「UBBCONFIG(5)」を参照してください。
tlisten(1)は、ネットワークに依存しないリスナー・プロセスであり、tmboot(1)などの管理ユーティリティを実行できるマルチ・マシン・アプリケーションのノード間の接続を確立します。アプリケーション管理者は、UBBCONFIGファイルのNETWORKセクションで定義されたすべてのマシンにtlistenをインストールします。
tlistenリンクにLLEを構成するには、「ブリッジ間のリンクにLLEを構成する方法」で説明した手順に従います。必要に応じ、次のコマンドを入力して、ローカル・マシンで別個のtlistenのインスタンスを起動できます。
tlisten -lnlsaddr[-zmin-Zmax]
nlsaddr値は、UBBCONFIGファイルのNETWORKセクションでこのマシンのNLSADDRパラメータに指定した値と同じにする必要があります。詳細は、『Oracle Tuxedoコマンド・リファレンス』の「tlisten(1)」、および『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「TM_MIB(5)」および「UBBCONFIG(5)」を参照してください。
ドメイン・ゲートウェイはGWTDOMAINプロセスであり、複数のATMIアプリケーション間でサービス・リクエストとサービス応答を中継します。また、TCP/IPなどのネットワーク・トランスポート・プロトコルを介して流れる、特別に設計されたトランザクション処理(TP)プロトコルを使用して相互運用性を実現します。
ドメイン・ゲートウェイはドメイン・ゲートウェイ・グループに属します。各ドメイン・ゲートウェイ・グループには、別個のドメイン構成ファイルが必要です。ドメイン・ゲートウェイ・グループは、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を構成するには、次の手順に従います。
MASTERマシンで作業しており、ATMIアプリケーションが非アクティブであることを確認します。DMCONFIGを開き、DM_TDOMAINセクションに次の行を追加します。*DM_TDOMAIN# Local network addressesLDOMNWADDR="local_domain_network_address"
NWDEVICE="local_domain_device"
MINENCRYPTBITS=minMAXENCRYPTBITS=max.
.
.
# Remote network addressesRDOMNWADDR="remote_domain_network_address"
NWDEVICE="remote_domain_device"
MINENCRYPTBITS=minMAXENCRYPTBITS=max.
.
.
# TDomain network addressesRDOMNWADDR="remote_domain_network_address"
NWDEVICE="remote_domain_device"CONNECTION_POLICY=ON_STARTLACCESSPOINT="local_domain_access_point_identifier"FAILOVERSEQ=100MINENCRYPTBITS=minMAXENCRYPTBITS=max
LDOMis replaced with a local domain access point identifier, andRDOMis replaced with a remote domain access point identifier.
dmloadcfコマンドを実行すると、DMCONFIGが解析され、BDMCONFIG変数が指す場所にバイナリ形式のBDMCONFIGファイルがロードされます。 上の例では、tmboot(1)を実行するとATMIアプリケーションが起動します。各ドメイン・ゲートウェイはBDMCONFIGファイルを読み込んでMINENCRYPTBITSおよびMAXENCRYPTBITSなどの様々なパラメータにアクセスし、ローカル・ドメインおよびリモート・ドメインにそれらのパラメータを伝播します。ローカル・ドメインがリモート・ドメインとのネットワーク・リンクを確立するとき、これらの2つのドメインは、双方でサポートされるキーの最大サイズが一致するまでキー・サイズの調整を行います。
詳細は、『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「DMCONFIG(5)」を参照してください。また、『Oracle Tuxedo Domainsコンポーネントの使用』の「ドメイン構成のセキュリティの設定」も参照してください。
SSL暗号化は、ATMIアプリケーションにおいてマシン間で送受信されるメッセージのデータ機密性を保護します。SSL暗号化には、業界標準のTLS 1.0プロトコルが使用されています。ユーザーは、256ビット、128ビットおよび56ビットのSSL暗号を使用できます。
ATMIアプリケーションにSSLを構成する前に、SSLの表記法(min, max)を知っておく必要があります。これらのパラメータのデフォルト値は次のとおりです。
デフォルト値を変更するには、アプリケーションのUBBCONFIGファイルでminとmaxに新しい値を割り当てます。詳細は、「SSLプロトコルのしくみ」および「暗号化キー・サイズのネゴシエーション」を参照してください。
ワークステーション・クライアントのリンクにSSLを構成するには、次の手順に従います。
MASTERマシンで作業しており、アプリケーションが非アクティブであることを確認します。SEC_PRINCIPAL_NAME、SEC_PRINCIPAL_LOCATION、およびSEC_PRINCIPAL_PASSVARパラメータを指定する必要があります。これらのパラメータは、*RESOURCES、*MACHINES、*GROUPS、または*SERVERSセクションで指定できます。| 注意: | 通常、これらのパラメータにはできるかぎり大きな値を指定することをお薦めします。これは、UBBCONFIG内での情報の重複を避け、tmloadcfを対話的に実行した場合に複数のパスワード・プロンプトが表示されることを防ぐためです。 |
UBBCONFIGを開き、SERVERSセクションに次の行を追加します。*SERVERS
WSL SRVGRP="group_name" SRVID=server_number...
CLOPT="-A -- -zmin-Zmax-n <network_address> -S <secure port> [-a] [-R <renegotiation_interval>] ..."
ネットワーク・アドレスで使用されているポートをセキュア・ポートとして設定した場合、WSLはSSL接続のみを試行します。それぞれ別のポートが使用されている場合は、同じWSLが非SSL接続とSSL接続の両方を試行できます。
WSCは、SEC_PRINCIPAL_LOCATION、SEC_PRINCIPAL_NAME、SEC_PRINCIPAL_PASSWORD環境変数のいずれかまたは複数を状況に応じて設定する必要があります。
SSLを使用するすべてのワークステーション・クライアントは、WSHによって提供される資格証明の確認に使用するために、信頼性のある証明書のリストを指定する必要があります。従来のセキュリティ資格証明を使用する場合、場所はプラグイン・フレームワークのcertificate_validationインタフェースで指定されます。環境変数を設定する必要はありません。セキュリティ資格証明のためにOracle Walletを使用する場合、信頼性のある証明書はOracle Walletに格納されます。「実行時のOracle Walletの作成」で説明するように、ウォレットの場所を指定するためにSEC_PRINCIPAL_LOCATIONおよびSEC_PRINCIPAL_NAME環境変数が使用されます。SEC_PRINCIPAL_PASSWORD環境変数は、ウォレットを開くために使用されます。
| 注意: |
WSL -a (相互認証)オプションが使用されている場合、WSCは自らの証明書と秘密鍵の場所も指定する必要があります。従来のセキュリティ資格証明とOracle Walletのどちらが使用されるかにかかわらず、これらの資格証明にアクセスするにはSEC_PRINCIPAL_LOCATION、SEC_PRINCIPAL_NAMEおよびSEC_PRINCIPAL_PASSWORD環境変数を設定する必要があります。
tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。ブリッジ間のリンクにSSLを構成するには、次の手順に従います。
MASTERマシンで作業しており、アプリケーションが非アクティブであることを確認します。UBBCONFIGを開き、RESOURCESセクションとNETWORKセクションに次の行を追加します。*RESOURCES
OPTIONS SSL,LAN
SSL_RENEGOTIATION (optional) [value]
*NETWORK
LMID NADDR="bridge_network_address" BRIDGE="bridge_device"
NLSADDR="listen_network_address"
MINENCRYPTBITS=min
MAXENCRYPTBITS=max
SEC_PRINCIPAL_NAME、SEC_PRINCIPAL_LOCATION、およびSEC_PRINCIPAL_PASSVARは、*RESOURCESまたは*MACHINES (あるいはその両方の)セクションで指定する必要があります。
LMIDは、ブリッジ・サーバーが置かれた論理マシンであり、BRIDGEパラメータで指定されたネットワーク・デバイスに直接アクセスできます。
tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。 tlistenリンクにSSLを構成するには、「ブリッジ間のリンクにLLEを構成する方法」で説明した手順に従います。次のコマンドを入力する必要があります。
tlisten -lnlsaddr[-zmin-Zmax][-s][-c <sec_principal_location>][-n <sec_principal_name>][-p <sec_principal_passvar>]
| 注意: | -sオプションは、LLE接続ではなくSSL接続であることを示します。 |
| 注意: | -c、-n、および -pオプションは、SSLセキュリティ・プリンシパル情報を指定するためのもので、UBBCONFIGファイルのSEC_PRINCIPAL_NAME、SEC_PRINCIPAL_LOCATION、およびSEC_PRINCIPAL PASSVARと一致していなければなりません。 |
ドメイン・ゲートウェイのリンクにSSLを構成するには、次の手順に従います。
MASTERマシンで作業しており、ATMIアプリケーションが非アクティブであることを確認します。DMCONFIGをテキスト・エディタで開き、DM_TDOMAINセクションに次の行を追加します。*DM_TDOMAIN
# SSL
DEFAULT: NWPROTOCOL={SSL|SSL_ONE_WAY}
SSL_RENEGOTIATION = [value]
LDOM NWADDR="local_domain_network_address" NWDEVICE="local_domain_device" MINENCRYPTBITS=min
MAXENCRYPTBITS=max
# Remote network addressesRDOMNWADDR="remote_domain_network_address"
NWDEVICE="remote_domain_device"
MINENCRYPTBITS=minMAXENCRYPTBITS=max.
.
.
# TDomain network addressesRDOMNWADDR="remote_domain_network_address"
NWDEVICE="remote_domain_device"CONNECTION_POLICY=ON_STARTLACCESSPOINT="local_domain_access_point_identifier"FAILOVERSEQ=100MINENCRYPTBITS=minMAXENCRYPTBITS=max
LDOMis replaced with a local domain access point identifier, andRDOMis replaced with a remote domain access point identifier.
SEC_PRINCIPAL_NAME、SEC_PRINCIPAL_LOCATION、およびSEC_PRINCIPAL_PASSWORDを指定する必要があります。dmloadcfコマンドを実行すると、DMCONFIGが解析され、BDMCONFIG変数が指す場所にバイナリ形式のBDMCONFIGファイルがロードされます。TuxedoアプリケーションでSSLプロトコルを使用するための準備は、主に管理プロセスです。表2-2は、SSLプロトコルを使用できるようにインフラストラクチャを設定し、アプリケーション内のサーバーおよびクライアントでSSLプロトコルが使用されるように構成するための管理手順の一覧です。
管理手順の詳細は、『CORBAアプリケーションにおけるセキュリティの使用』の「公開鍵によるセキュリティ機能の管理」および「SSLプロトコルの構成」を参照してください。
管理手順を実行したら、パスワードによる認証と証明書による認証のどちらもTuxedoアプリケーションで使用できます。これらの手順は、CORBAアプリケーションの認証とよく似ています。詳細は、『CORBAアプリケーションにおけるセキュリティの使用』の「セキュリティを実装するCORBAアプリケーション」を参照してください。
| 注意: | Oracle CORBA C++ ORBをサーバー・アプリケーションとして使用している場合、ORBでもSSLプロトコルを使用するように構成できます。詳細は、『CORBAアプリケーションにおけるセキュリティの使用』の「SSLプロトコルの構成」を参照してください。 |
SSLプロトコルをパスワードによる認証で使用する場合、UBBCONFIGファイルのSECURITYパラメータを目的の認証レベルに設定し、必要であれば、認証サーバー(AUTHSRV)を構成します。パスワード認証の管理手順の詳細は、『ATMIアプリケーションにおけるセキュリティの使用』の「Password Authentication」を参照してください。
図2-13に、SSLプロトコルを使用するTuxedoアプリケーションの構成を示します。
Oracle Walletは次のいずれかの方法で作成できます。
orapkiを使用したOracle Walletの作成方法の詳細は、『Oracle Database Advanced Security管理者ガイド』のorapkiユーティリティに関する項を参照してください(インストールしているOracle Databaseのバージョンによってドキュメントのリンクは異なる場合があります)。
Oracle Tuxedoのウォレットにはパスワードが必要なため、「自動ログイン」オプションは使用できません。orapkiおよびowmを使用して新しい秘密鍵と証明書を持つウォレットを生成することはできますが、これらのツールの現行バージョンでは、以前使用されていた秘密鍵と証明書をウォレットにインポートできません。既存の秘密鍵と証明書のペアをウォレットにインポートする必要がある場合は、実行時変換、openssl、または別のサード・パーティ・ツールを使用してください。
次に、Oracle Walletの作成に使用できるopensslコマンドの例を示します。
openssl pkcs12 \
-export \
-chain \
-inkey private_key_file.pem \
-in certificate_file.pem \
-CAfile trusted_certificate_file.pem \
-out ewallet.p12 \
-passin pass:private_key_password \
-passout pass:wallet_password \
-export: PKCS 12ファイルを作成します。-chain: ユーザー証明書の証明書チェーン全体を含めるように指定します。-inkey: 秘密鍵ファイルを指定します。-in: 証明書チェーンでユーザー証明書および他の証明書を含むファイルを指定します。| 注意: | 秘密鍵および証明書チェーンが同じファイル内にある場合は、-inkeyおよび-inパラメータに同じファイルを指定します。 |
-CAfile: 信頼済証明書が格納されているファイルを指定します。-out: 出力ファイル名を指定します(Oracle Walletの場合はewallet.p12)。-passin: 秘密鍵ファイルのパスワードを指定します。-passout: 新しく作成したウォレットのパスワードを指定します。| 注意: | orapkiの実行時に他のユーザーが「ps」を実行する可能性がある場合は、-passinおよび-passoutパラメータを省略して、orapkiでパスワードを要求する必要があります。 |
SEC_PRINCIPAL_LOCATION構成パラメータまたはワークステーション・クライアントのSEC_PRINCIPAL_LOCATION環境変数がOracle Walletを指定しない場合、Tuxedoは従来のセキュリティ資格証明を探して、次のようにOracle Walletを作成しようとします。
SEC_PRINCIPAL_LOCATIONはプロセスの秘密鍵ファイルを指定します。秘密鍵ファイルは、SSL接続のサーバー側のプロセスで必須です。または、相互認証が使用されるときは接続のクライアント側のプロセスで必須です。一方向SSL接続のクライアント側のプロセスでは省略可能です。SEC_PRINCIPAL_PASSVAR構成ファイル環境変数(またはワークステーション・クライアントのSEC_PRINCIPAL_PASSWORD環境変数)の値が、秘密鍵を復号化するために使用されます。SEC_PRINCIPAL_NAMEの値を入力として渡すプラグイン・フレームワークによって取得されます(デフォルトのプラグイン・フレームワーク実装では、これはLDAPを使用します)。証明書チェーンは、SSL接続のサーバー側のプロセスで必須です。または、相互認証が使用されるときは接続のクライアント側のプロセスで必須です。一方向SSL接続のクライアント側のプロセスでは省略可能です。certificate_validationインタフェースのcaCertificateFileパラメータとして指定されるファイルに格納されますデフォルトのcaCertificateFileは$TUXDIR/udataobj/security/certs/trust_ca.cerです。信頼性のある証明書は、SSLサーバーとSSLクライアントに対して存在する必要があります。PKCS12ウォレット・ファイルは、プロセスの秘密鍵(ある場合)とユーザー証明書(ある場合)だけでなく、チェーンの他の証明書および信頼性のある証明書も使用して作成されます。
SEC_PRINCIPAL_LOCATIONがファイルの場合は、SEC_PRINCIPAL_LOCATIONが格納されるディレクトリとしてWALLET_DIRを定義し、SUBDIRをwallet.`basename SEC_PRINCIPAL_LOCATION`として定義します。
SEC_PRINCIPAL_LOCATIONがディレクトリの場合、または存在していない場合は、WALLET_DIRがSEC_PRINCIPAL_LOCATIONと等しくなるように定義し、SUBDIRをwallet.SEC_PRINCIPAL_NAMEとして定義します。
新しいウォレットはWALLET_DIR/SUBDIR/ewallet.p12に作成されます。
(WALLET_DIRはTuxedo構成パラメータも環境変数も表しません。説明のためのみに使用されていることに注意してください。)
SEC_PRINCIPAL_NAME="ISH_tuxqa"および
SEC_PRINCIPAL_LOCATION="/home/tuxedo/myapp/wallet"
/home/tuxedo/myapp/wallet/wallet.ISH_tuxqa/ewallet.p12
従来のセキュリティ資格証明のOracle Wallet形式への変換は、TUXCREATEWALLET環境変数の影響を受けます。これは、次のように設定されている可能性があります。
TUXCREATEWALLET=KEEP、TUXCREATEWALLET=YESまたはTUXCREATEWALLET設定解除: ウォレットが存在していないが、従来形式のセキュリティ資格証明が存在している場合、従来のセキュリティ資格証明をウォレットに変換します。これはデフォルトの動作です。ウォレットが作成されるディレクトリには700個の権限が格納されます。ewallet.p12ファイルには600個の権限が格納されます。ユーザーが既存のウォレットの読取りまたはウォレットの作成を行うには、適切な権限を持つ必要があります。ULOG_SSLINFO=yが設定されている場合は、次のメッセージが記録されます。 LIBTUX_CAT:6908: INFO: プリンシパル名のセキュリティ資格証明がOracle Wallet wallet_directoryに変換されました。
その後プロセスが呼び出されると、新たに作成されたウォレットが使用されるため、従来のセキュリティ資格証明を再作成する必要はありません。
TUXCREATEWALLET=TEMP: ウォレットが存在していないが、従来形式のセキュリティ資格証明が存在している場合、ウォレットを一時ディレクトリに作成し、開いたら一時ファイル・ウォレットを削除します。このオプションを使用するときNo LIBTUX_CAT:6908メッセージが記録されます。TEMPオプションは効率が低下しますが、次の場合に必要です。TUXCREATEWALLET=NOまたはTUXCREATEWALLET=anyothervalue: ウォレットが存在しない場合、エラーが報告されます。従来形式のセキュリティ資格証明は使用されません。 KEEPまたはTEMPの値は、大文字と小文字の区別はありませんが、これらの4文字で指定する必要があります。YESまたはNOの値は、Tuxedoの他の多くのYes/No環境変数と同じく、ローカル言語で指定することもできます。
環境変数TUXNZTRACE=8191が設定されると、TuxedoはプロセスのSSLトレースをtrace-process_id.logという名前のファイルに出力します。トレース出力には、SSLハンドシェイク・プロセスで送信される情報と、暗号化されたアプリケーション・データが含まれます。このトレースは、特定の証明書チェーンが有効とみなされない理由や、SSLハンドシェイク・プロセスに他のエラーがある理由を判別するときに特に役立ちます。
環境変数ULOG_SSLINFO=yesが設定されると、SSL接続が確立されるたびにTuxedoがメッセージをユーザー・ログに書き込みます。これには、ネゴシエーションされた暗号の名前が含まれます。
様々なツールを使用して、Oracle Wallet (PKCS12ファイル)に関する情報を表示できます。
opensslは、一部のオペレーティング・システムではOSディストリビューションに含まれています。その他のオペレーティング・システムでは、ソースをダウンロードしてコンパイルできます。
次のopensslコマンドは、Oracle Walletの証明書と秘密鍵を表示します。
openssl pkcs12 -in ewallet.p12
opensslでは、ウォレットを開くために使用するパスワードについてプロンプトが表示されます。(オプション-password pass:passwordを使用するとプロンプトが表示されませんが、このオプションを使用すると、同じマシンでpsコマンドを実行する別のユーザーがパスワードを見る可能性があります。)
opensslでは、秘密鍵を端末に表示するとき、復号化された秘密鍵を暗号化するためのパスワードについてもプロンプトが表示されます。オプション-nodesを使用すると、このプロンプトを表示せず、秘密鍵を暗号化されていない形式で表示できます。
openssl pkcs12の出力に含まれるすべての証明書は、別のファイルにコピーできます。また、次のコマンドを使用して、証明書のフィールドを表示できます。
openssl x509 -in certificatefile -text -noout
Oracle Databaseソフトウェアをインストールしているユーザーは、ウォレットに関する情報を表示するためにorapkiコマンドまたはowmグラフィカル・コマンドも使用できます。ウォレットの情報を表示するorapkiコマンドは次のとおりです。
orapki wallet display -wallet wallet_location
多くのSSLエラー・メッセージには、Oracle NZセキュリティ・レイヤーから返されるエラー・コード番号が含まれます。一部のエラー・メッセージでは、その後にNZエラー番号の短い説明文が続きます。NZエラー・コードの説明文が含まれないエラー・メッセージの場合、この情報はファイル$TUXDIR/locale/C/ORACLE.textを検索して取得できます。
Oracle Databaseソフトウェアをインストールしているユーザーは、特定のエラー番号に関連する文字列を判別するためにoerrコマンドを使用することもできます。
T_DM_TDOMAINクラスDM_TDOMAINセクションT_WSLクラス
分散型のATMIアプリケーションの安全性を確保する最も効果的な方法は、リンク・レベルの暗号化と公開鍵による暗号化を組み合せることです。公開鍵による暗号化は、公開鍵セキュリティの基盤となるフレームワークです。
公開鍵セキュリティにより、メッセージ・ベースのデジタル署名とメッセージ・ベースの暗号化をATMIアプリケーションに統合することができます。これらの機能を組み合せると、データの整合性と機密性が保たれます。これは、ATMIアプリケーションが外部のATMIアプリケーションまたはワークステーション・クライアントと相互運用する場合に特に重要です。
アプリケーションの管理者と開発者は、公開鍵と秘密鍵の組合せ、および関連するデジタル証明書を認証するための認証局を選択する必要があります。次に、鍵の組合せをATMIアプリケーションに割り当てる方法を決定する必要があります。鍵の組合せを割り当てる方法はたくさんあります。管理者は、次のうち、1つまたは複数の方法で鍵の組合せを割り当てることができます。
アプリケーションの管理者と開発者は、鍵の組合せを割り当てる方法を選択し、実際に割り当てる責任があります。ただし、鍵の組み合わせを割り当てた後の管理作業を行う必要はありません。鍵の配布と管理は、公開鍵セキュリティのプラグインによって行われます。
管理者は、次の構成パラメータを使用して、ATMIアプリケーションのデジタル署名に関するポリシーを設定します。
SIGNATURE_AHEADは、構成階層のうち、ドメイン・レベルで指定されるため、このパラメータに割り当てた値は、ATMIアプリケーションで実行されるすべてのプロセスに適用されます。ドメイン全体にわたるパラメータは、UBBCONFIGファイルのRESOURCESセクションおよびTM_MIBのT_DOMAINクラスで設定されます。
SIGNATURE_AHEADパラメータは、(1)受信メッセージ・バッファに添付されたタイムスタンプと、(2)検証システムのローカル・クロックに表示される現在時刻との最大許容時間差を設定します。最小値は1秒です。最大値は2147483647秒です。デフォルトは3600秒(1時間)です。
デジタル署名のタイムスタンプが遠い将来の時刻を示す場合、その署名は無効と見なされます。このパラメータは、同期されていないローカル・クロックとの間の許容時間差を受け入れつつ、将来の日付が設定された署名を拒否するのに便利です。
*RESOURCESSIGNATURE_AHEAD2400
SIGNATURE_BEHINDは、構成階層のうち、ドメイン・レベルで指定されるため、このパラメータに割り当てた値は、ATMIアプリケーションで実行されるすべてのプロセスに適用されます。ドメイン全体にわたるパラメータは、UBBCONFIGファイルのRESOURCESセクションおよびTM_MIBのT_DOMAINクラスで設定されます。
SIGNATURE_BEHINDパラメータは、(1)検証システムのローカル・クロックに表示される現在時刻と、(2)受信メッセージ・バッファに添付されたタイムスタンプとの最大許容時間差を設定します。最小値は1秒です。最大値は2147483647秒です。デフォルト値は604800秒(1週間)です。
デジタル署名のタイムスタンプ値が遠い過去の時刻を示す場合、その署名は無効とみなされます。このパラメータを設定すると、リプレイ攻撃、つまり、署名付きの有効なバッファが再びシステムに送信されるのを阻止することができます。ただし、非同期通信を行うシステム、たとえばディスク・ベースのキューを使用するシステムでは、かなり古い署名が添付されたバッファが有効とみなされる場合があります。したがって、非同期通信を行うシステムでは、SIGNATURE_BEHINDの設定を増やしてください。
*RESOURCESSIGNATURE_BEHIND300000
SIGNATURE_REQUIREDは、構成の階層のうち、次の4つのレベルのどこでも指定できます。
特定のレベルでSIGNATURE_REQUIREDにY (はい)を設定すると、下位レベルで動作するすべてのプロセスに署名が必要となります。たとえば、mach1というマシンでSIGNATURE_REQUIREDにYを設定すると、mach1上で動作するすべてのプロセスは、デジタル署名が添付されたメッセージだけを受け付けます。
RESOURCESセクションまたはT_DOMAINクラス)で設定すると、このパラメータは、ゲートウェイ・プロセスによって公開されるアプリケーション・サービスを含め、ドメイン内で公開されるすべてのアプリケーション・サービスに適用されます。デフォルトはNです。MACHINESセクションまたはT_MACHINEクラス)で設定すると、このパラメータは、ゲートウェイ・プロセスによって公開されるアプリケーション・サービスを含め、特定のマシンで公開されるすべてのアプリケーション・サービスに適用されます。デフォルトはNです。GROUPSセクションまたはT_GROUPクラス)で設定すると、このパラメータは、ゲートウェイ・プロセスによって公開されるアプリケーション・サービスを含め、特定のグループによって公開されるすべてのアプリケーション・サービスに適用されます。デフォルトはNです。SERVICESセクションまたはT_SERVICEクラス)で設定すると、このパラメータは、ゲートウェイ・プロセスによって公開されるインスタンスを含め、ドメイン内で公開される特定サービスのすべてのインスタンスに適用されます。デフォルトはNです。ドメイン全体にわたるレベル、マシン・レベル、グループ・レベル、またはサービス・レベルでは、SIGNATURE_REQUIRED=YおよびENCRYPTION_REQUIRED=Yを同時に指定することができます。ENCRYPTION_REQUIREDの詳細は、「受信メッセージに対する暗号化ポリシーの適用」を参照してください。
SIGNATURE_REQUIREDを指定するかどうかのポリシーは、アプリケーション・サービス、アプリケーション・イベント、およびアプリケーション・エンキュー・リクエストに対してのみ適用されます。システム生成されたサービス呼び出しや、システム・イベントのポストには適用されません。
mach1というマシンにSIGNATURE_REQUIREDを構成するには、次の手順に従います。
MASTERマシンで作業しており、ATMIアプリケーションが非アクティブであることを確認します。UBBCONFIGを開き、MACHINESセクションに次の行を追加します。*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
tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。 上の例では、tmboot(1)を実行すると、ATMIアプリケーションが起動し、SIGNATURE_REQUIRED=Yパラメータがmach1というマシンに渡されます。この時点で、mach1によって公開されたすべてのアプリケーション・サービスは、ゲートウェイ・プロセスによって公開されたアプリケーション・サービスも含め、有効なデジタル署名が添付されたメッセージだけを受け付けることができます。mach1によって制御されるプロセスが、有効なデジタル署名が添付されていないメッセージを受信すると、システム側では次のアクションが実行されます。
WARN (警告))。| 注意: | NULLバッファ(空のバッファ)にデジタル署名を添付することはできません。したがって、デジタル署名を必要とするプロセスで受信されたNULLバッファは、前述のいずれかの方法で、システム側で拒否されます。 |
ポスト済のメッセージ・バッファにデジタル署名が添付されると、これらの署名は保存され、メッセージ・バッファとともに、適切なイベントのサブスクライバに転送されます。
TMUSREVT(5)システム・サーバーが、デジタル署名を必要とするドメイン、マシン、またはサーバー・グループで実行されている場合、このサーバーは、コンポジット署名ステータスがTPSIGN_OKに設定されていないイベントを拒否します。詳細は、「コンポジット署名ステータスの理解」を参照してください。
TMUSREVTサーバーは、サービスの呼び出しやキューへのメッセージの登録などの、サブスクリプションに関する通知アクションを実行できます。有効なデジタル署名を必要とするサービスやキューに対して、有効なデジタル署名が添付されていないメッセージをポストすると、サブスクリプションの通知アクションは失敗します。
システム・イベント(システム側でポストされ、TMSYSEVTサーバーで処理されるイベント)には、デジタル署名を添付することができます。デジタル署名に関する管理ポリシーは、TMSYSEVT(5)サーバーには適用されません。
キューに登録されたバッファにデジタル署名が添付されると、署名はキュー内に保存され、キューから取り出すプロセスの実行時に転送されます。また、メッセージがTMQFORWARD(5)によって処理され、サービスが呼び出されると、署名は保存されます。
TMQUEUE(5)システム・サーバーが、デジタル署名を必要とするドメイン、マシン、またはサーバー・グループで実行されている場合、このサーバーは、コンポジット署名ステータスがTPSIGN_OKに設定されていないキュー・リクエストを拒否します。詳細は、「コンポジット署名ステータスの理解」を参照してください。さらに、キュー・スペースに関連するサービス名に対してこのようなポリシーが有効な場合、TMQUEUEサーバーはデジタル署名を必要とします。
ワークステーション・ハンドラ(WSH)が、デジタル署名を必要とするドメイン、マシン、またはサーバー・グループで実行されている場合、WSHは、コンポジット署名ステータスがTPSIGN_OKに設定されていない、アプリケーション・データを含むメッセージ・バッファを拒否します。詳細は、「コンポジット署名ステータスの理解」を参照してください。
管理者は、次の構成パラメータを使用して、ATMIアプリケーションの暗号化ポリシーを設定します。
ENCRYPTION_REQUIREDは、構成の階層のうち、次の4つのレベルのどこでも指定できます。
特定のレベルでENCRYPTION_REQUIREDにY (はい)を設定すると、下位レベルで動作するすべてのプロセスに暗号化が必要となります。たとえば、mach1というマシンでENCRYPTION_REQUIREDにYを設定すると、mach1上で動作するすべてのプロセスは、暗号化されたメッセージだけを受け付けます。
RESOURCESセクションまたはT_DOMAINクラス)で設定すると、このパラメータは、ゲートウェイ・プロセスによって公開されるアプリケーション・サービスを含め、ドメイン内で公開されるすべてのアプリケーション・サービスに適用されます。デフォルトはNです。MACHINESセクションまたはT_MACHINEクラス)で設定すると、このパラメータは、ゲートウェイ・プロセスによって公開されるアプリケーション・サービスを含め、特定のマシンで公開されるすべてのアプリケーション・サービスに適用されます。デフォルトはNです。GROUPSセクションまたはT_GROUPクラス)で設定すると、このパラメータは、ゲートウェイ・プロセスによって公開されるアプリケーション・サービスを含め、特定のグループによって公開されるすべてのアプリケーション・サービスに適用されます。デフォルトはNです。SERVICESセクションまたはT_SERVICEクラス)で設定すると、このパラメータは、ゲートウェイ・プロセスによって公開されるインスタンスを含め、ドメイン内で公開される特定サービスのすべてのインスタンスに適用されます。デフォルトはNです。ドメイン全体にわたるレベル、マシン・レベル、グループ・レベル、またはサービス・レベルでは、ENCRYPTION_REQUIRED=YおよびSIGNATURE_REQUIRED=Yを同時に指定することができます。SIGNATURE_REQUIREDの詳細は、「受信メッセージに対する署名ポリシーの適用」を参照してください。
ENCRYPTION_REQUIREDを指定するかどうかのポリシーは、アプリケーション・サービス、アプリケーション・イベント、およびアプリケーション・エンキュー・リクエストに対してのみ適用されます。システム生成されたサービス呼び出しや、システム・イベントのポストには適用されません。
STDGRPというサーバー・グループにENCRYPTION_REQUIREDを構成するには、次の手順に従います。
MASTERマシンで作業しており、ATMIアプリケーションが非アクティブであることを確認します。UBBCONFIGを開き、GROUPSセクションに次の行を追加します。*GROUPS
STDGRP LMID="machine_logical_name"
GRPNO="server_group_number"
ENCRYPTION_REQUIRED=Y
tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。 上の例では、tmboot(1)を実行するとATMIアプリケーションが起動し、ENCRYPTION_REQUIRED=YパラメータがSTDGRPというサーバー・グループに渡されます。この時点で、STDGRPによって公開されたすべてのアプリケーション・サービスは、ゲートウェイ・プロセスによって公開されたアプリケーション・サービスも含め、暗号化のエンベロープで保護されたメッセージだけを受け付けることができます。STDGRPによって制御されるプロセスが、暗号化されていないメッセージを受信すると、システム側では次のアクションが実行されます。
ERROR (エラー))。| 注意: | NULLバッファ(空のバッファ)は暗号化できません。したがって、暗号化を必要とするプロセスで受信されたNULLバッファは、前述のいずれかの方法で、システム側で拒否されます。 |
ポスト済のメッセージ・バッファが暗号化されると、これらの署名は保存され、暗号化されたメッセージの内容とともに、適切なイベントのサブスクライバに転送されます。
TMUSREVT(5)システム・サーバーが、暗号化を必要とするドメイン、マシン、またはサーバー・グループで実行されている場合、このサーバーは、暗号化されていないメッセージを拒否します。
TMUSREVTサーバーは、サービスの呼び出しやキューへのメッセージの登録などの、サブスクリプションに関する通知アクションを実行できます。入力する情報の暗号化を必要とするサービスやキューに対して、暗号化されていないメッセージをポストすると、サブスクリプションの通知アクションは失敗します。また、サブスクライバが適切な復号化キーを保持していない場合も、イベント通知アクションは失敗します。
システム・イベント(システム側でポストされ、TMSYSEVTサーバーで処理されるイベント)は、暗号化できます。暗号化に関する管理ポリシーは、TMSYSEVT(5)サーバーには適用されません。
キューに登録されたバッファが暗号化されると、このステータスはキュー内に保存され、バッファは、キューから取り出すプロセスの実行時に暗号化された形式で転送されます。また、メッセージがTMQFORWARD(5)によって処理され、サービスが呼び出されると、暗号化のステータスは保存されます。
TMQUEUE(5)システム・サーバーが、暗号化を必要とするドメイン、マシン、またはサーバー・グループで実行されている場合、このサーバーは、暗号化されていない受信エンキュー・リクエストを拒否します。さらに、キュー・スペースに関連するサービス名に対してこのようなポリシーが有効な場合、TMQUEUEサーバーは、暗号化を必要とします。
ワークステーション・ハンドラ(WSH)が、暗号化を必要とするドメイン、マシン、またはサーバー・グループで実行されている場合、WSHは、暗号化されていないアプリケーション・データ・バッファを含むメッセージ・バッファを拒否します。
管理者は、次の構成パラメータを使用して、アプリケーション内で動作するシステム・プロセスのプリンシパル名と復号化キーを指定します。
前述の3つのパラメータは、構成の階層のうち、次の4つのレベルのどこでも指定できます。
特定の構成レベルでのプリンシパル名および復号化キーは、下位レベルでオーバーライドできます。たとえば、mach1というマシンにプリンシパル名と復号化キーを設定し、mach1上で動作するserv1というサーバーにプリンシパル名と復号化キーを構成したとします。この場合、mach1のプロセスは次のように動作します。
ATMIアプリケーションが起動すると、構成された復号化キーは自動的にオープンします。図2-14は、このプロセスのしくみを示しています。
UBBCONFIGファイルの特定のレベルで、SEC_PRINCIPAL_NAME、SEC_PRINCIPAL_LOCATION、およびSEC_PRINCIPAL_PASSVARを定義します。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。map_proofプラグインにより、SEC_PRINCIPAL_NAME、SEC_PRINCIPAL_LOCATION、およびSEC_PRINCIPAL_PASSVARが読み込まれ、各パラメータの値が解析されます。次に、呼出しプロセスで、リクエストされた復号化キーに対するアクセス権が証明されたかどうかが判別されます。復号化キー、つまり秘密鍵にアクセスできるということは、プリンシパルのIDを所有することと同じです。SEC_PRINCIPAL_PASSVARに関連するパスワードが、SEC_PRINCIPAL_NAMEで指定されたプリンシパルに割り当てられたパスワードと一致する場合、map_proofプラグインは、プリンシパルの名前、位置、およびパスワードをPKi_initプラグインに渡します。PKi_initプラグインは、プリンシパルの名前、位置、およびパスワードを引数に指定し、tpkey_open(3c)を呼び出します。プリンシパルの復号化キー・ハンドルが返されます。 tmloadcfを呼び出して構成をロードするたびに、SEC_PRINCIPAL_PASSVARに設定した各復号化キーに対するパスワードの入力を求められます。各パスワードを手動で入力しないで済むようにするには、パスワードを自動的に入力するスクリプトを記述します。このスクリプトには、各パスワードの変数定義を組み込み、次の行で終了する必要があります。
tmloadcf -y ubbconfig_name < /dev/nullATMIアプリケーションの起動時にオープンされた復号化キーをクローズするパーミッションは、アプリケーション・プロセスにはありません。復号化キーは、tmshutdown(1)コマンドを実行してATMIアプリケーションを停止するまで、オープンしたままの状態になります。
*RESOURCESSEC_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の場合(「コンポジット署名ステータスの理解」を参照)、システム側では次のアクションが実行されます。
ERROR (エラー))。有効期限が切れた証明書、取り消された証明書、有効期限が切れた署名、または古い日付の署名が検出された場合、システム側では次のアクションが実行されます。
SIGNATURE_REQUIRED=Yの設定に基づいて有効なデジタル署名を必要とするプロセスが、コンポジット署名ステータスTPSIGN_UNKNOWNが添付されたメッセージを受信した場合、システム側では次のアクションが実行されます。
プロセスが、メッセージの暗号化エンベロープのいずれかと一致するオープンした復号化キーを持たない状態で、暗号化されたメッセージを受信した場合、システムは次のアクションを実行します。
ERROR (エラー))。 ENCRYPTION_REQUIRED=Yの設定に基づいて暗号化された入力を必要とするプロセスが、暗号化されていないメッセージを受信した場合、システムは次のアクションを実行します。
デフォルトの認証および認可は、Oracle Tuxedoシステムで最初に実現された、Oracle Tuxedoの従来の認証および認可と同じように機能します。
デフォルトの認証には、認証なし(NONE)、アプリケーション・パスワード(APP_PW)、ユーザー・レベルの認証を実行(USER_AUTH)、という3つのセキュリティ・レベルが用意されています。デフォルトの認可には、オプションのアクセス制御リスト(ACL)および必須のアクセス制御リスト(MANDATORY_ACL)という2つのセキュリティ・レベルがあります。アクセス制御リストは、ユーザーがATMIアプリケーションへの参加を認証された場合にのみ有効になります。
管理者は、UBBCONFIG構成ファイルを編集するか、TM_MIBを変更するか、またはOracle管理コンソールを使用することにより、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を使用してセキュリティ・レベルを指定するには、T_DOMAINクラスのTA_SECURITY属性に値を割り当てなければなりません。ATMIアプリケーションが非アクティブの場合、管理者は、TA_SECURITYに対してUBBCONFIGで有効な任意の値を設定できます。このタスクを完了するには、管理インタフェースtpadmcall(3c)を実行します。
Oracle管理コンソールを使用してセキュリティ・レベルを指定することもできます。Oracle管理コンソールは、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"
| 注意: |
LAUTHSVRを使用して、シングル・ポイント・セキュリティ管理を実装する必要があります。WebLogic ServerとLAUTHSVRおよびシングル・ポイント・セキュリティ管理については、「シングル・ポイント・セキュリティ管理の実装」を参照してください。XAUTHSVRを認証および認可サーバーとして使用する拡張可能なセキュリティ管理を実装する必要があります。XAUTHSVRおよび拡張可能なセキュリティ管理の詳細は、『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のXAUTHSVR(5)に関する項を参照してください。
デフォルトの認証には、アプリケーション・パスワードというセキュリティ・レベルが用意されており、これは、構成ファイルのSECURITY APP_PWで指定すると有効になります。このセキュリティ・レベルでは、ATMIアプリケーションに参加するすべてのクライアントに対してアプリケーション・パスワードの入力が求められます。管理者は、ATMIアプリケーション全体に対して1つのパスワードを定義し、認可されたユーザーだけにパスワードを通知します。
APP_PWのセキュリティ・レベルを有効にするには、次の手順に従います。
MASTERマシンで作業しており、ATMIアプリケーションが非アクティブであることを確認します。UBBCONFIGファイルのRESOURCESセクションのSECURITYパラメータにAPP_PWを構成します。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。tmadminのpasswdコマンドを使用して変更しないかぎり有効です。
デフォルトの認証には、ユーザー・レベルの認証というセキュリティ・レベルが用意されており、これは、構成ファイルのSECURITY USER_AUTHで指定すると有効になります。このセキュリティ・レベルでは、ATMIアプリケーションに参加するため、各クライアントは、アプリケーション・パスワードのほか、有効なユーザー名とユーザー固有のデータ(パスワードなど)を提示しなければなりません。ユーザーごとのパスワードは、tpusrファイルに格納されている、ユーザー名とクライアント名の組合せに関連付けられたパスワードに一致しなければなりません。ユーザーごとのパスワードと、tpusr内のユーザー名/クライアント名およびパスワードとの照合は、認証サーバーAUTHSVRの認証サービスAUTHSVCによって実行されます。
USER_AUTHのセキュリティ・レベルを有効にするには、次の手順に従います。
MASTERマシンで作業しており、ATMIアプリケーションが非アクティブであることを確認します。UBBCONFIGを開き、RESOURCESセクションとSERVERSセクションに次の行を追加します。*RESOURCES
SECURITY USER_AUTH
AUTHSVC AUTHSVC
.
.
.
*SERVERS
AUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
CLOPT="-A"を指定すると、tmboot(1)は、tmbootによってアプリケーションが起動するときに、"-A"で呼び出されたデフォルトのコマンドライン・オプションだけをAUTHSVRに渡します。デフォルトでは、AUTHSVRは、tpusrというファイル内のクライアント・ユーザー情報を使用して、ATMIアプリケーションに参加しようとするクライアントを認証します。tpusrは、ATMIアプリケーションのAPPDIR変数で定義する最初のパス名によって参照されるディレクトリにあります。
tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。tmadminのpasswdコマンドを使用して変更しないかぎり有効です。 デフォルトの認可システムで使用できるAUTHSVRとアクセス制御チェック機能では、tpusrというユーザー・ファイルが必要です。このファイルには、ATMIアプリケーションへの参加を許可されたクライアント・ユーザーのリストが含まれています。アプリケーション管理者は、tpusradd(1)、tpusrdel(1)、およびtpusrmod(1)の各コマンドを使用してtpusrを管理します。AUTHSVRサーバーは、tpusrファイルに格納されているクライアント・ユーザー情報を入力として受け取ります。AUTHSVRサーバーは、この情報を使用して、ATMIアプリケーションに参加しようとするクライアントを認証します。
AUTHSVRとアクセス制御チェック機能では、tpgrpというグループ・ファイルも必要です。このファイルには、ATMIアプリケーションへの参加を許可されたクライアント・ユーザーに関連付けられたグループのリストが含まれています。アプリケーション管理者は、tpgrpadd(1)、tpgrpdel(1)、およびtpgrpmod(1)の各コマンドを使用してtpgrpを管理します。
AUTHSVCは、認証されたクライアント・ユーザーにアプリケーション・キーを割り当てます。アプリケーション・キーには、USER_AUTH、ACLまたはMANDATORY_ACLのセキュリティ・レベルに対するユーザー識別子および関連するグループ識別子が含まれます。(アプリケーション・キーの詳細は、「アプリケーション・キー」を参照してください。)
管理者は、tpusrファイルおよびtpgrpファイルで、ユーザーとグループのリストを定義しなければなりません。これらのファイルは、ATMIアプリケーションのAPPDIR変数で定義した最初のパス名によって参照されるディレクトリにあります。これらのファイルは、コロンで区切られたフラットなテキスト・ファイルであり、アプリケーション管理者だけが読み書きを行う権限を持ちます。
ホスト・システムには、ユーザーとグループのリストを格納したファイルがすでに存在する場合があります。これらのファイルをATMIアプリケーションのユーザー・ファイルおよびグループ・ファイルとして使用するには、Oracle Tuxedoシステムで受け付けられる形式に変換する必要があります。ファイルを変換するには、次の手順例に示すように、tpaclcvt(1)コマンドを実行します。この手順例は、UNIXホスト・マシン用に記述されています。
| 注意: | シャドウ・パスワード・ファイルを使用するシステムでは、ファイル内のユーザーごとにパスワードの入力が要求されます。 |
Oracle Tuxedoシステムでは、アプリケーション・ユーザーのリストをtpusrというファイルで管理し、グループのリストをtpgrpというファイルで管理する必要があります。これらのファイルのエントリを変更するには、コマンドを発行するか、またはACL_MIB内の適切な属性を変更します。
次のいずれかのコマンドを実行すると、tpusrファイルおよびtpgrpファイルのエントリをいつでも追加、変更、または削除できます。
コマンドライン・インタフェース以外の方法として、ACL_MIB(5)のT_ACLPRINCIPALクラスの該当する属性値を変更して、tpusrのユーザー・エントリを追加、変更、または削除することができます。tpusradd(1)では一度に1人のユーザーしか追加できないため、同時に複数のユーザー・エントリを追加する場合は、この方法の方がコマンドライン・インタフェースより効率的です。
同様に、ACL_MIB(5)のT_ACLGROUPクラスの該当する属性値を変更すると、tpgrpのグループ・エントリを追加、変更、または削除できます。tpgrpadd(1)では一度に1つのグループしか追加できないため、同時に複数のグループ・エントリを追加する場合は、この方法の方がコマンドライン・インタフェースより効率的です。
Oracle管理コンソールを使用すると、最も簡単にMIBにアクセスできます。
デフォルトの認可には、サービスを実行し、イベントをポストし、アプリケーション・キューのメッセージをキューに登録(または登録解除)するユーザーを決定するアクセス制御リストの機能が備わっています。アクセス制御によるセキュリティには、オプションのアクセス制御リスト(ACL)と必須のアクセス制御リスト(MANDATORY_ACL)の2つのレベルがあります。アクセス制御リストは、ユーザーがATMIアプリケーションへの参加を認証された場合にのみ有効になります。
アクセス制御リストを使用すると、管理者はユーザーを複数のグループにまとめ、それらのグループに対して、メンバー・ユーザーがアクセス権を持つオブジェクトを関連付けることができます。アクセス制御は、次の理由により、グループ・レベルで行われます。
アクセス制御のチェック機能は、アプリケーション管理者によって作成および管理される3つのファイルに基づいています。
クライアントのアプリケーション・キー(クライアントを有効なユーザーおよび有効なグループ・メンバーとして識別する情報を含む)を解析することによって、エンティティ(サービス、イベント、またはアプリケーション・キューなど)は、ユーザーが属するグループを識別できます。tpaclファイルをチェックすることによって、エンティティは、クライアントのグループにアクセス・パーミッションが付与されているかどうかを判定できます。
アプリケーション管理者、アプリケーション・オペレータ、およびアプリケーション管理者またはオペレータの権限で実行中のプロセスやサービス・リクエストは、ACLによる権限のチェックの対象にはなりません。
ユーザー・レベルのACLエントリが必要な場合は、各ユーザーのグループを作成し、そのグループをtpaclファイルの該当するアプリケーション・エンティティにマッピングします。
デフォルトの認証には、「オプションのアクセス制御リスト(ACL)」というセキュリティ・レベルが用意されており、これは、構成ファイルのSECURITY ACLで指定すると有効になります。このセキュリティ・レベルでは、各クライアントは、ATMIアプリケーションに参加するため、アプリケーション・パスワード、ユーザー名、およびユーザー固有のデータ(パスワードなど)を提示しなければなりません。ターゲット・アプリケーションのエンティティに関連するエントリがtpaclファイルになくても、ユーザーはそのエンティティにアクセスできます。
管理者は、このセキュリティ・レベルを使用して、セキュリティを強化したいリソースに対してのみアクセス権を構成できます。つまり、すべてのユーザーにアクセスを許可するサービス、イベント、およびアプリケーション・キューについて、tpaclファイルにエントリを追加する必要はありません。ただし、tpaclファイルにターゲット・アプリケーションのエンティティに関連するエントリがあり、ユーザーがこれにアクセスしようとする場合、そのユーザーは、そのエンティティへのアクセスを許可されたグループのメンバーでなければなりません。そうでない場合、アクセスは拒否されます。
ACLのセキュリティ・レベルを有効にするには、次の手順に従います。
MASTERマシンで作業しており、ATMIアプリケーションが非アクティブであることを確認します。UBBCONFIGを開き、RESOURCESセクションとSERVERSセクションに次の行を追加します。*RESOURCES
SECURITY ACL
AUTHSVC ..AUTHSVC
.
.
.
*SERVERS
AUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
CLOPT="-A"を指定すると、tmboot(1)は、tmbootによってアプリケーションが起動するときに、"-A"で呼び出されたデフォルトのコマンドライン・オプションだけをAUTHSVRに渡します。デフォルトでは、AUTHSVRは、tpusrというファイル内のクライアント・ユーザー情報を使用して、ATMIアプリケーションに参加しようとするクライアントを認証します。tpusrは、ATMIアプリケーションのAPPDIR変数で定義する最初のパス名によって参照されるディレクトリにあります。
tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。tmadminのpasswdコマンドを使用して変更しないかぎり有効です。 アクセス制御のチェック機能では、tpusrというユーザー・ファイル、tpgrpというグループ・ファイル、およびtpaclというACLファイルが必要です。ACLファイルには、グループとアプリケーション・エンティティのマッピングが含まれています。エンティティとは、サービス、イベント、またはアプリケーション・キューです。
管理者はtpaclファイルでエントリを定義しなければなりません。tpaclファイルは、ATMIアプリケーションのAPPDIR変数で定義した最初のパス名によって参照されるディレクトリにあります。これらのファイルは、コロンで区切られたフラットなテキスト・ファイルであり、アプリケーション管理者だけが読み書きを行う権限を持ちます。
tpaclファイルのACLのエントリを変更するには、コマンドを発行するか、またはACL_MIB内の適切な属性を変更します。
次のいずれかのコマンドを実行すると、tpaclファイルのACLエントリをいつでも追加、変更、または削除できます。
コマンドライン・インタフェース以外の方法として、ACL_MIB(5)のT_ACLPERMクラスの該当する属性値を変更して、tpaclのACLエントリを追加、変更、または削除することができます。tpacladd(1)では一度に1つのACLエントリしか追加できないため、同時に複数のACLエントリを追加する場合は、この方法の方がコマンドライン・インタフェースより効率的です。
Oracle管理コンソールを使用すると、最も簡単にMIBにアクセスできます。
デフォルトの認証には、「必須のアクセス制御リスト」というセキュリティ・レベルが用意されており、これは、構成ファイルのSECURITY MANDATORY_ACLで指定すると有効になります。このセキュリティ・レベルでは、各クライアントは、ATMIアプリケーションに参加するため、アプリケーション・パスワード、ユーザー名、およびユーザー固有のデータ(パスワードなど)を提示しなければなりません。ターゲット・アプリケーションのエンティティに関連するエントリがtpaclファイルにない場合、クライアントはそのエンティティにアクセスできません。つまり、アクセスする必要のあるアプリケーション・エンティティのエントリがtpaclファイルに存在している必要があります。したがって、このレベルは「必須」と呼ばれます。
ただし、tpaclファイルにターゲット・アプリケーションのエンティティに関連するエントリがあり、ユーザーがこれにアクセスしようとする場合、そのユーザーは、そのエンティティへのアクセスを許可されたグループのメンバーでなければなりません。そうでない場合、アクセスは拒否されます。
MANDATORY_ACLのセキュリティ・レベルを有効にするには、次の手順に従います。
MASTERマシンで作業しており、ATMIアプリケーションが非アクティブであることを確認します。UBBCONFIGを開き、RESOURCESセクションとSERVERSセクションに次の行を追加します。*RESOURCES
SECURITY MANDATORY_ACL
AUTHSVC ..AUTHSVC
.
.
.
*SERVERS
AUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
CLOPT="-A"を指定すると、tmboot(1)は、tmbootによってアプリケーションが起動するときに、"-A"で呼び出されたデフォルトのコマンドライン・オプションだけをAUTHSVRに渡します。デフォルトでは、AUTHSVRは、tpusrというファイル内のクライアント・ユーザー情報を使用して、ATMIアプリケーションに参加しようとするクライアントを認証します。tpusrは、ATMIアプリケーションのAPPDIR変数で定義する最初のパス名によって参照されるディレクトリにあります。
tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。tmadminのpasswdコマンドを使用して変更しないかぎり有効です。「ACLファイルの設定」を参照してください。
一般的なLDAPベース・セキュリティには、ユーザー・レベルの認証とアクセス制御セキュリティが含まれます。
このセキュリティ・メカニズムにより、認証と認可は、TUXEDO "..ATNSVC"および"..ATZSVC"の管理サービスを呼び出すことで実行されます。これにより柔軟性が向上し、Oracle Tuxedoユーザーはセキュリティ情報を独立したリポジトリに格納して、それらのセキュリティ情報に"..ATNSVC"サービスと"..ATZSVC"サービスからアクセスできるようになります。Oracle Tuxedoでは、これら2つの管理サービスを公開するXAUTHSVRサーバーのデフォルト実装が提供されます。この実装では、セキュリティ情報(TuxedoユーザーID、パスワード、サービス・アクセス権限など)はLDAPリポジトリに格納されます。
各クライアントは、ATMIアプリケーションに参加するために有効なユーザー名とユーザー固有のパスワードを提供する必要があります。ユーザーのパスワードは、LDAPリポジトリに格納されているパスワードと一致する必要があります。各クライアントには適切な権限が付与され、その後、Tuxedoサービスに正常にアクセスできます。
デフォルトのXAUTHSVR実装でLDAPベースのセキュリティを有効にするには、次の手順を実行します。
* RESOURCES
SECURITY ACL
AUTHSVC ..AUTHSVC
OPTIONS EXT_AA*SERVERS
XAUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y
XAUTHSVRサーバー構成ファイルを使用してXAUTHSVRがLDAPリポジトリを探します。デフォルトの構成ファイルtpldap.xauthは$TUXDIR/udataobjディレクトリに格納されています。"-f"オプションを使用してカスタマイズした場所をXAUTHSVRサーバーに指定できます。XAUTHSVRサーバーでは、認証情報と認可情報を別のLDAPリポジトリに格納できます。それぞれ"-n"オプションと"-z"オプションを使用してATN構成ファイルを指定できます。これらすべての構成ファイルの形式は同じです。
表2-3は、XAUTHSVR構成ファイルのキーワードを示しています。
LDAPリポジトリのセキュリティ情報の概要は次のとおりです。
inetOrgPerson: このオブジェクト・クラスは、ユーザーを表すエントリを保持します。定義は、属性"uid"の長さが30文字以内に制限されることを除き、RFC 4519および2798標準に従います。各Oracle Tuxedoユーザーはこのクラスのエントリとして保存されます。ユーザーIDとユーザー・パスワードを含むこの情報は、ユーザーレベル認証で使用されます。groupOfUniqueNames: このオブジェクト・クラスは、名前付きオブジェクトのセットを表すエントリを保持します。セットの目的や保守に関連する情報も含まれます。この定義はRFC 4519標準に従います。このクラスにより、特定の種類の権限を付与されるユーザーのリストがグループ分けされます。グループはネストできます。親グループに付与される権限は子グループにも適用されます。Orcljaznpermission: このオブジェクト・クラスは、表2-4に示す属性で構成されるtuxedo権限オブジェクトを保持します。このオブジェクトは2つの部分で構成されます。1つは権限です。これは、リソース・タイプ、ターゲット・リソース、ターゲット・リソース上のアクションを示します。もう1つは、この権限が付与される、割当て済のグループまたはユーザーです。 表2-4に、orcljaznpermissionクラスの属性の定義を示します。
ATZパフォーマンスを向上させるために、新しいATZメカニズムとしてロールアップ・キャッシュが導入されています。このキャッシュには、すべてのTuxedoサーバーに対する特定のユーザーIDの権限が格納されます。様々なATZの要件を満たすために、このキャッシュは各Tuxedoサーバー・レベルで柔軟に構成できます。
3つの環境変数を使用して、キャッシュの基本動作を制御します。TUXCONFIGで特定のサーバー・エントリについてENVFILEパラメータを定義した後で、UBBCONFIGのSERVERSセクションで各Tuxedoサーバー・エントリにこれらの環境変数を定義できます。
TMATZPRIVILEGEMAXの値は、TMATZRESOURCEMAXの値以上に設定する必要があります。そうしないと、TMATZPRIVILEGEMAXはTMATZRESOURCEMAXと等しい値に設定されます。 有効値の範囲は0 - 32767です。ATZキャッシュ内の1つのリソースエントリのサイズは約148バイトです。 この環境変数が0に設定されると、TuxedoサーバーのATZキャッシュは無効になり、すべてのATZリクエストはATZサービスにディスパッチされます。
TMATZRESOURCE値は10、MAX TMATZPRIVILEGEMAX値は1000と仮定します。 使用メモリー・サイズの計算式([リソース・エントリの最大数] * [リソース・エントリのサイズ] + [権限エントリの最大数]*[権限エントリのサイズ])に従うと、この場合の結果は次のようになります。
Kerberosは、ネットワーク認証プロトコルです。このプロトコルは、シークレット・キー暗号を用いて、クライアント/サーバー・アプリケーション用に強力な認証機能を実現するために設計されました。Kerberos認証プロトコルでは、ネットワーク接続を開始する前に、クライアントとサーバー、または2つのサーバーの間の相互認証メカニズムを利用できます。このプロトコルは、クライアントとサーバーの間の初期トランザクションが、ほとんどのコンピュータが物理的に安全ではない開かれたネットワーク上で発生することを前提にしています。また、ネットワーク上を行き来するパケットを任意に監視および変更できることを前提にしています。
Kerberosを使用してクライアントとサーバーのIDを承認したら、その通信を暗号化してプライバシとデータの整合性を確保できるようになります。Kerberosの詳細は、「関連項目」を参照してください。
以降の項では、Tuxedoに付属のKerberos認証プラグイン機能について説明します。
Tuxedoでは、カスタマイズ可能な一般的なセキュリティ・フレームワークを利用できます。このフレームワークにKerberosプラグインを組み込むと、セキュリティを強化できます。
現在、Kerberosプラグインは次のプラットフォームで使用できます。
Kerberosプラグインは、TuxedoシステムとKerberos認証サーバー(KAUTHSVR(5))に登録する必要がある動的ライブラリです。KerberosプラグインのTuxedo実装は次をサポートしています。
| 注意: | Tuxedoワークステーション・クライアントとワークステーション・ハンドラのセキュリティ・プロトコル間の認証、2つのドメイン・ゲートウェイとCORBAコンポーネントの間の認証はサポートされていません。 |
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
| 注意: | Windowsプラットフォームでは、プラグインのKRB5_CONFIGおよびKRB5_KDCパラメータは不要です。このパラメータは、UNIXプラットフォームでKerberos関連の構成ファイルを特定する場合に使用します。KAUTHSVRPRINCはKAUTHSVRサーバーのプリンシパル名を指定し、Tuxedoクライアントはサーバー・プリンシパル名としてそれを使用します。 |
| 注意: | UNIXプラットフォームでは、GSS形式を使用します。Microsoftは標準的なGSS名表現をサポートしていないので、KAUTHSVRPRINCパラメータには、完全なKerberosレルム名を指定する必要があります。 |
| 注意: | 名前の形式は次のとおりです。 |
| 注意: | KAUTHSVRPRINCは、環境変数として設定することもできます。 |
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
| 注意: | リスト2-4では、libtux.soを例として用います。ファイル名libtuxにプラットフォーム固有の動的ライブラリの拡張子を付ける必要があります。 |
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"
| 注意: | -kオプションを使用すると、KAUTHSVR Kerberosキー表ファイルの場所を指定できます。 |
| 注意: | -pオプションは、KAUTHSVRプリンシパル名を示します。 |
| 注意: | UNIXプラットフォームで動作しているKAUTHSVRではGSS形式を使用する必要があります。 |
*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"
| 注意: | -pオプションは、KAUTHSVRプリンシパル名を示します。 |
| 注意: | Windowsプラットフォームでは、-kオプションのかわりに次の2つの引数を使用する必要があります。 |
| 注意: | Windowsプラットフォームで動作しているKAUTHSVRでは、完全なKerberosレルム名を使用する必要があります。 |
Kerberosを有効にしたTuxedoネイティブ・クライアントを使用するには、kinitまたはそれに類似したコマンドを使用して、最初にKDCから有効なTGTを取得する必要があります。
プログラミングAPIは必要ありません。また、USER_AUTHを指定している場合は、tpusrファイルでTuxedoユーザー名を指定する必要もありません。ただし、ACLおよびMANDATORY_ACLのセキュリティ・レベルでは、ユーザー名が必要です。
epif*コマンドでTuxedoに登録されているシステムでのみ動作します。libkrb5atnがTuxedoに登録されていない場合でも、デフォルト・プラグインおよびデフォルトTuxedoセキュリティ・メカニズムは有効です。KAUTHSVRでは、Kerberos認証に加えて、完全なAUTHSVR機能を使用できます。| 注意: | Tuxedoワークステーション・クライアントとワークステーション・ハンドラのセキュリティ・プロトコル間の認証、2つのドメイン・ゲートウェイとCORBAコンポーネントの間の認証はサポートされていません。 |
Cert-CベースのPKI (Public Key Infrastructure)プラグインは、公開鍵暗号化アルゴリズムを使用して次の機能を実現します。
以降の項では、Tuxedoに付属のCert-C PKI暗号化機能について説明します。
Tuxedo Cert-C PKI暗号化プラグインは、外部からアクセス可能なユーザー証明書のストレージ・メカニズムとしてLDAPバージョン2以降を使用します。LDAPは、ネットワーク・ディレクトリ・サービスでは広く使われているメカニズムです。
Tuxedo Cert-C PKI暗号化プラグインを使用するには、次のシステム要件を確認してください。
このプラグインを使用するには、デフォルトPKIプラグインとしてこのプラグインを使用するようにTuxedoを構成するコマンド・スクリプトを実行する必要があります。
Tuxedo Cert-Cプラグインは、Tuxedo Security PIFの4つのインタフェース・グループを使用し、PIFレジストリ・コマンドで構成されます。次のインタフェース・グループが必要です。
Tuxedo環境では、プラグインの実行時にユーザー名のみが使用可能です。適切な検索情報を取得するために、LDAPに格納されている証明書(cn=user nameを入力済)がTuxedoユーザー名であることが前提となっています。
このインタフェース・グループは、ユーザー証明書がLDAPサーバーにあるものとみなし、ユーザー証明書を読み取るためのアクセス権を持っています。証明書ルックアップ・インタフェースには、構成が必要なパラメータが4つあります。次に、各パラメータについて説明します。
ldapUserCertificate
LDAP:URLです。例:
ldapUserCertificate=ldap://sagamore:389 この例では、LDAPサーバーが「sagamore」というマシンにあり、ポート389でリスニングしていることをCert-Cプラグインに通知します。
ldapBaseObject
ldapBaseObject="ou=Engineer Test,o=ABC Company,c=US" この例では、ディレクトリ情報ツリー"ou=Engineer Test, o=ABC Company, c=US"から検索を開始します。
ldapFilterAttribute
ldapBaseDNAttributeと同じ構文で指定します。例:
ldapBaseDNAttribute
ldapBaseDNAttribute="c, o, ou, cn" この例では、DNを検索用に構築する際に"c"、"o"、"ou"、"cn"の属性を使用するようにCert-Cプラグインに通知します。
OpenLDAPをX.509証明書ルックアップに対応させるには、リスト2-7のコマンドを実行して、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'.| 注意: | 場合によっては、$TUXDIR/udataobj/securityにあるbea_ldap_filter.datファイルを変更する必要もあります。 |
リスト2-8に、フィルタの例を示します。
"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"
秘密鍵の場所は、キー管理インタフェース用に指定する必要がある構成パラメータでのみ指定します。
オプション・パラメータ。暗号化された秘密鍵情報の形式でラップされた秘密鍵を復号化するためのパスワードをCert-C PKI暗号化プラグインに提供する文字列変数です。例:
プラグインでは、秘密鍵情報ファイルが"<subject_name>.epk"ネーミング方式に従っていることを前提にします。
| 注意: | decPasswordとprivateKeyDirをオーバーライドするには、tpkey_open(3c)のidentity_proofパラメータとlocationパラメータを使用します。 |
ファイル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ファイルのみが検索対象になります。
証明書解析インタフェースを使用する際に、特別な構成パラメータは必要ありません。自動的に初期化されます。
| 注意: | 証明書は、DER形式のX.509互換にする必要があります。 |
証明書解析インタフェース・グループを使用すると、Cert-C PKI暗号化プラグインは、信頼性のある認証局、信頼性のチェーン、証明書取消しリストを基に証明書を検証し、その有効性を判定できます。証明書の検証に関連付けられている構成パラメータには、次の2つがあります。
ファイルURL形式の文字列変数構成パラメータ。公開キーがユーザーによって信頼されている単一の証明書を示します。証明書は自己署名形式でも構いません。証明書チェーンが、信頼性のあるこの証明書を検証すると、証明書は「適切」と見なされます。
| 注意: | 存在する証明書検証チェーン・レベルは1つだけです。つまり、すべてのユーザー証明書は、caCertificateFileで構成されたルートCAによって直接発行されます。 |
caCertificateFile=file:///c:\home\certs\root.cer
この例では、信頼性のあるルート証明書はc:\home\certsというディレクトリにあるroot.cerという名前のものです。
ファイルURL形式の文字列変数構成パラメータ。生成された証明書パスの検証に使用する単一のCRLを示します。つまり、対象の証明書が発行者によって呼び出されたものかどうかが判定されます。例:
crlFile=file:///c:\home\certs\revoke.crl
この例では、証明書が発行者によって呼び出されていない場合、どのCRLが判定に使用されるかを示します。
次に、WindowsプラットフォームでCert-C PKI暗号化プラグインを使用してTuxedoレジストリ・データベースを変更するサンプル・コマンドを示します。
| 注意: | UNIXプラットフォームでは、次のように置き換える必要があります。 |
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
"cn"属性は、証明書ルックアップ用のキーとして使用されるので、DNには"cn="属性を含める必要があります。tpkey_getinfo()属性は、Cert-C PKI暗号化プラグインを使用してENCRYPT_ALG、ENCRYPT_BITS、SIGNATURE_ALG、またはSIGNATURE_BITSの情報を取得することができません。TPKEY_SIGNATURE: ENCRYPT_ALG、ENCRYPT_BITSを取得できません。TPKEY_ENCRYPT: SIGNATURE_BITSを取得できません。TPKEY_AUTOSIGN: ENCRYPT_ALG、ENCRYPT_BITSを取得できません。 TPKEY_AUTOENCRYPT: SIGNATURE_BITSを取得できません。| 注意: | TPKEY_DECRYPT: ENCRYPT_ALG、ENCRYPT_BITS、SIGNATURE_ALG、またはSIGNATURE_BITSの情報を取得できます。ENCRYPT_ALG、ENCRYPT_BITS、SIGNATURE_ALG、またはSIGNATURE_BITSの情報を取得できます。 |
  
|